Most teams still run the loop we all inherited.

  1. Product writes a doc
  2. Engineering interprets the doc
  3. Code gets written
  4. Then rewritten
  5. Then reviewed
  6. Then the team forgets half the context and starts over next sprint

It works until it doesn’t. And when it fails, it fails predictably.

Industry surveys say 47% of projects miss their goals because of poor requirements management. Another common metric: 16–35% of all production defects originate directly from unclear or incomplete requirements.

None of this is surprising if you’ve ever tried to implement a feature from a doc that reads like a horoscope.

The plan decays faster than the code. The code pays the price.

The Old Loop

If you drew the system, it would look something like this:

flowchart LR
    A[Product Writes Doc] --> B[Devs Interpret / Guess]
    B --> C[Code Written]
    C --> D[Code Reviewed]
    D --> E[Context Lost]
    E --> A

The part we never talk about: the drag

Most defects don’t start in the code. They start earlier. In the guessing.

The hidden cost

Developers lose hours each week drifting between their editor, Slack threads, and half-finished specs. One study puts the cost of context-switching at a 40% productivity loss across knowledge work.

Another found that teams regularly spend half their total effort on avoidable rework, much of it caused by misalignment in the earliest phase.

What it feels like

You can feel it on bad days: the start-stop rhythm, the small hesitations before committing because you’re not sure what the original intent really was.

The fatigue that comes from building something twice—once to interpret the spec, once to implement it.

This is the part of the job no one celebrates. The part that wears people down.

The shift: planning becomes code

The change didn’t arrive as a methodology. It arrived the morning I reread a product brief for the third time and still couldn’t reconcile its three competing definitions of the same state.

Instead of scheduling a meeting, I opened Claude Code and rewrote the feature as if I were describing an architectural change:

  • Constraints
  • Inputs and outputs
  • Invariants
  • Edge cases
  • Failure modes
  • The parts that break under load

Claude turned it into a structured plan, shaped like a diff. Something I could review. Something others could comment on. Something that made ambiguity visible before it metastasized into code.

The surprising part

Once the plan looked like code, the team treated it like code.

  • We left comments
  • We requested changes
  • We argued over invariants instead of intentions
  • We tightened the edges before touching the repository

“Failing to write a spec is the single biggest unnecessary risk you take in a software project.”

— Joel Spolsky

He wasn’t being dramatic. He was being precise.

Letting the model carry the mechanical weight

Once the plan held water, handing implementation to the model stopped feeling risky. It felt… appropriate.

What AI does well

AI coding assistants aren’t magic. But they are fast and consistent.

GitHub’s controlled experiment showed developers with AI assistance finished a task 55% faster and were more likely to produce a working solution.

Not better engineers—just engineers no longer burning time on boilerplate, scaffolding, and the hundred tiny cuts that make software development slower than it needs to be.

The division of labor

Claude takes the validated plan and generates the dull parts: module scaffolding, glue code, migrations, tests that aren’t testing insight.

Humans handle the rest: taste, architecture, the parts that require judgment and the scars earned in production. The parts AI shouldn’t own.

The New Loop

If you drew the new workflow, it would look like this:

flowchart LR
    P[Plan with Claude Code] --> R[Review Plan Like a PR]
    R --> I[Iterate & Clarify]
    I --> A[Model Implements Mechanical Work]
    A --> H[Human Polishes & Integrates]
    H --> S[Ship]

What changes

It feels quieter than the old loop. Fewer dropped threads. Less rework. Fewer “wait, what did product actually mean here?” moments.

You stay in flow longer. You argue about edges instead of intentions.

You debug less because the plan already debugged the shape of the feature before the first line of code was written.

Why it works

“When software projects fail, it’s rarely bad coding. It’s poor planning.”

— Elkhan Shabanov

Shifting the planning into a reviewable, executable form doesn’t eliminate the uncertainty. But it does contain it.

And when the heavy work of early clarification is done well, the rest of the process feels… lighter.

The speed is nice. The clarity is better.

Feels less like AI. More like removing sand from the gears.