AI Coding Tools Are Fast. That's the Problem.

AI Coding Tools Are Fast. That's the Problem.

AI coding tools are fast. Dangerously fast.

You type a requirement. Code appears. Tests pass. You merge.

Three weeks later you're untangling architectural decisions nobody reviewed, patterns that contradict your stack, and a codebase where every AI session starts from scratch because context lives in ephemeral chat — not your repo.

I've seen this at scale. When AI makes assumptions, you're not fixing a typo. You're losing days.

The root cause isn't the AI. It's the workflow.

These tools optimize for speed of generation, not correctness of outcome. They skip the step every senior engineer knows is non-negotiable — write the spec before you write the code.

This isn't new thinking. Google's engineering culture is built around it — design docs before touching anything, a practice documented in their own Software Engineering at Google book. Amazon calls it Working Backwards — write the press release and FAQ before a single line gets written. Jeff Bezos built this into Amazon's DNA, and Colin Bryar and Bill Carr documented the whole thing in Working Backwards. That discipline exists for a reason.

So I built Draft (GitHub)— distilling the same spec-first discipline that Google, Amazon, and Stripe have practiced for years into a workflow any team can drop into today, regardless of which AI tool they use.

Context-Driven Development. Treat context as a managed artifact alongside code, not something that lives and dies in a chat window.

What that looks like in practice:

  • Spec and plan live in your repo — git-tracked, PR-reviewable, just like code
  • AI does collaborative intake before touching anything. One question at a time. No assumptions.
  • Architecture documented once, consumed by every session, every tool, every new engineer
  • Nothing gets marked done without evidence. Tests run, output shown. No self-reporting.

AI becomes an executor of pre-approved work. Not an autonomous decision-maker winging it.

The thing that surprised me most — you catch design problems in a document, not a code review. Wrong architectural call costs a paragraph edit, not a module rewrite. That's the difference between 5 minutes and 2 days.

Google engineers figured this out decades ago. Amazon built entire product lines on it. Draft brings that same discipline into your AI coding workflow — not as a process tax, but as the thing that actually makes AI useful at scale.

This is the first post in a weekly series on Context-Driven Development — the methodology behind Draft. Next week: why spec-first eliminates the most expensive bugs before a single line gets written.

Context is the new code. Treat it like one.

getdraft.dev (GitHub)


#AIcoding #EngineeringProductivity #DevTools #SoftwareEngineering #ClaudeCode #ContextDrivenDevelopment #Draft #SpecFirst

Just came across this IBM video https://www.youtube.com/watch?v=mViFYTwWvcM on spec-driven development after publishing this. Didn't expect #IBM to validate the exact thesis the same week. 😄

Like
Reply

That's true! To that effect had worked out a tooling for sharing, summarising, and retrieving matched contexts across agents, for personal projects. This looks promising ngl.

Like
Reply

We are moving from prompt engineering -> context engineering

To view or add a comment, sign in

Others also viewed

Explore content categories