Plan a feature before any agent touches code

A feature with an agent usually goes like this. You describe it in a sentence and the agent starts building. Twenty minutes in, you realize it needs a settings page, an email, and a migration that changes a table three other things depend on. The agent didn't know that either. It has been building the wrong thing for twenty minutes, confidently.

The fix is dull and it works. Find the surface area before anyone builds anything.

Talk it out

The first step isn't a spec. It's the conversation you'd have at a whiteboard with someone who knows the codebase.

Open Architect Chat with the repo imported and float the idea: "Users should be able to invite teammates." It comes back with what that implies in this codebase. For a typical app that means an invites table, an email, an accept flow, a decision about roles, changes to the members page, and a question about what happens when the invited person already has an account.

That last one is what you'd have discovered at minute twenty. Now you know at minute one.

Ask what you'd ask a person. What's the smallest version that's still useful? What does this touch that I'm not thinking of? Where is the edge case that will bite? What can we skip and add later without painting ourselves in? Each answer arrives as a proposed change to the plan. You preview it and apply it, or you don't.

Cut on purpose

Every feature has a version that ships this week and a version that ships in a month. The agent can't tell which one you want, so you have to say.

"What can we cut and still launch?" is the most useful question in the process. The answer should be concrete: move the role picker to a later module and ship with one role, drop the resend button, nothing else depends on either. Apply it and the plan gets smaller and the order gets clearer.

Cutting doesn't lose the idea. The later module is still in the tree with its tasks, waiting. You're choosing what comes first, not what exists.

Get the tree

Once the shape is right, you have a plan: a module for the feature, features inside it, tasks inside those. Each task has acceptance criteria, an estimate, and its dependencies, and each is sized for one agent session. "Build invites" is not a task. "Add the invites table and migration" is. So is "Send the invite email," and so is "Accept flow for an existing account."

Order is the part people skip. If the accept flow depends on the table, the agent shouldn't be able to start the accept flow first. In the plan it can't. It asks for the next ready task and gets one whose dependencies are done.

Hand it off

After that, the build is almost uneventful, which is the goal.

In your editor, your agent connects to the plan, pulls the next ready task with its criteria and everything you decided in chat, and works it. It writes status and notes back as it goes. Tomorrow, in a different editor, it picks up where it left off, because the state lives in the plan and not in yesterday's transcript.

Or queue the whole module to the cloud. Tasks run in order, each in a fresh VM, each ending in a pull request. Set a cap in tasks, dollars, or minutes. Approve each task, or let it run to the cap. A failed task pauses the queue instead of burning the rest, and a decision the agent shouldn't make alone comes back to you as a question on the task.

What ten minutes buys

A feature that's the size you meant rather than the size the agent guessed. Tasks an agent can finish, in an order that works. Edge cases found before they're bugs. A plan you can hand to any agent, or any person, and get the same build.

The alternative is finding all of that mid-build, one surprise at a time, while the agent keeps going.

Pick the feature you've been avoiding because it feels tangled. Import the repo, open the chat, and ask what it touches. If the answer is longer than you expected, that's the reason to plan it first.