Why Your Agent Starts Coding Before You Finish Talking

You give an agent a one-sentence task. It immediately writes code. The code is plausible. It is also not what you wanted, because the one sentence did not carry the half of your intent.

The agent is not being lazy. It is being efficient in the way it was trained to be. Models get rewarded for producing output fast. The reward signal teaches them to skip the part where they confirm what you actually meant.

The discipline that fixes this is the one teams skip first. Brainstorm before code. No exceptions.

The hard rule

Do not write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it.

This applies to every project regardless of perceived simplicity. Todo apps. Single-function utilities. Config changes. All of them.

"Simple" projects are where unexamined assumptions cause the most wasted work. The agent hears "build a todo app" and starts writing React. You wanted a CLI tool. The agent hears "add auth" and starts integrating OAuth. You wanted a session cookie. The mismatch costs a day.

The hard rule forces the mismatch to surface before code exists. Fixing a wrong design takes minutes. Fixing wrong code takes hours.

Phase one: explore project context

Before any clarifying question, the agent checks the current state of the project.

Files. Docs. Recent commits. What is already there. What is missing. What the request implies about the existing code.

Then it assesses scope. If the request describes multiple independent subsystems, it flags this immediately. "Build a blog platform" is not one task. It is content modeling, authoring workflow, rendering, deployment, and SEO. The agent helps decompose into sub-projects before any of them starts.

Skipping this phase is what produces "I built the whole thing in one PR" output. The output is always wrong because no single PR can correctly address five subsystems at once.

Phase two: clarifying questions

Questions come one at a time.

The agent prefers multiple choice when possible. Multiple choice forces specificity. "Should auth use JWT or session cookies?" is more useful than "tell me about auth".

Each question focuses on one of three things. Purpose: what is this for. Constraints: what can it not do. Success criteria: how do we know it is done.

If a topic needs more exploration, it becomes multiple questions. The agent does not bundle five questions into one prompt and hope you answer all of them.

This phase feels slow. It is faster than the alternative. The alternative is the agent guessing wrong on questions you would have answered in ten seconds.

Phase three: two or three approaches

Once the agent understands the idea, it proposes two or three approaches with trade-offs.

Not one approach. The agent's first idea is rarely the best. Forcing alternatives surfaces options you would not have considered.

Not five approaches. That is analysis paralysis. Two or three is enough to see the design space.

Each approach comes with trade-offs, not just benefits. "Approach A is faster to build but harder to maintain. Approach B is the opposite. Approach C is a middle ground that risks being neither."

The agent leads with a recommendation and explains the reasoning. Then it asks which you want.

This is not the agent picking for you. It is the agent making the design space visible. You pick.

Phase four: the design document

The design is presented in sections scaled to their complexity.

Straightforward sections get a few sentences. Nuanced sections get up to three hundred words. After each section, the agent asks whether it looks right so far.

The design covers architecture. Components. Data flow. Error handling. Testing. Anything that affects the implementation.

The section-by-section approach catches misunderstandings early. If section two is wrong, you fix it before the agent writes section three on top of the wrong assumption.

This is the opposite of "let me write the whole design document and you tell me what is wrong". That approach hides misunderstandings until the document is finished. By then, the agent has committed to a structure that is hard to undo.

Phase five: write the spec

Once you approve the design, the agent writes a spec document. Commits it. Runs a self-review checking for placeholders, contradictions, and ambiguity.

Then it asks you to review the written spec. Not the chat summary. The actual document.

The spec is the artifact the rest of the work runs against. If it is wrong, the work is wrong. The review is where you catch the wrongness before it becomes code.

Only after your final approval does the agent invoke the planning step.

When brainstorming is theater

For a typo fix, brainstorming is theater. There is nothing to design.

For a one-line config change, brainstorming is theater. The decision is already made.

For a refactor with no behavior change, brainstorming is theater. The behavior is the spec.

The judgment is whether the task introduces design decisions. If yes, brainstorm. If no, just do the work.

The mistake is brainstorming everything. The bigger mistake is brainstorming nothing. Most non-trivial work lies between, and most non-trivial work benefits from a design step before code.

What teams skip and regret

The piece teams skip is the hard rule. They let the agent start coding because the task "seemed simple". The agent produces output fast. The output misses intent. The team reviews, finds ten issues, asks for changes, repeats. Three rounds later, the work is correct, but the cost was three times what a brainstorm would have been.

The discipline is refusing to let the agent code before you have seen and approved a design. The agent will push back. The pushback is the signal. The discipline has to come from you.

Confirm intent before code exists. Every non-trivial task. No exceptions.