The most common way to fail a feature with an agent is to say "write it" right away and get a mountain of code that's easier to throw out than to untangle. Experienced work goes differently: first you think (brainstorm and plan), then you write by the plan. The agent is strong at both stages, but their roles differ.

Brainstorm first

Before writing code, it's worth clarifying the task itself — and here the agent is a good interlocutor, not an executor. At this stage you don't ask for code, you work through:

  • What exactly we're building and why — which user problem the feature solves.
  • Edge cases and forks — "what if the payment goes through twice?", "what about cancellation after shipping?". The agent is good at throwing out variants that are easy to miss.
  • Approaches — 2–3 ways to do it, with pros and cons. You make the decision, but seeing the alternatives helps.

The key rule of brainstorming: don't let the agent write code until the task is clear. Early code locks in unconsidered decisions.

Then the plan

Having clarified the task, ask the agent (or draft together) an implementation plan — before the code. A good plan:

  • breaks the feature into vertical slices — not "first all the models, then all the controllers", but "slice 1: one operation end to end, from input to database and test; slice 2: the next". Each slice can be built and checked;
  • names concrete files, steps, and a way to verify each;
  • is visible as a whole, and can be corrected before a single line is written.

The plan is the cheap point where mistakes of intent are caught. Changing a plan item is minutes; rewriting implemented code is hours. It's the same principle as spec as code: agree on what you're building before you build it.

Then the code — by the plan, in slices

Only now — implementation, and it follows the basic loop of working with an agent: one slice → build → test → lock in → the next. The plan keeps the agent from spreading, and you from losing the thread on a long task.

If the plan turns out wrong along the way — that's normal: you go back to the plan, fix it, continue. What's bad isn't "the plan was imprecise" but "there's already a mountain of code, and the intent is off".

Why it's faster, even with more steps

It seems brainstorming and planning are extra stages slowing down the start. Over the distance it's the opposite: they remove the most expensive rework — when the fact that what was written is off gets discovered at the end. An hour on the plan saves a day of untangling code that solved the wrong task. The agent makes these stages cheap: it quickly throws out variants, drafts the plan, keeps it in front of you.

What this means in practice

Developing a feature with an agent is "think, then write", not "write right away". A product engineer spends the first turns on brainstorming and a plan (where decisions are cheap to change), slices the work into vertical slices, and only then lets the agent write — slice by slice, each verifiable. Judgment about what and how to build stays with the human; the volume falls to the agent.

What's next

The code is written — next it needs checking and cleanup: finding and fixing bugs, then review and testing.