When I mention that most of my code is now written by coding agents, the follow-up question is almost always the same: which prompt do you use?
The honest answer is unspectacular. The prompt is the least important part.
Between a requirement and a change running in production there are eight steps in the way I work. The agent that writes the code works in exactly one of them. The other seven decide whether what it writes becomes software or just more code. Agents appear once more, in review, but with a different job: there they do not write, they check.
This article describes the process as I actually use it: what each step does, what happens without it and what stays with people. At the end there is the order in which I would start in a team that is only just beginning with agents.
How the specifications themselves are structured, with templates for features, bug fixes and maintenance, is covered in Agentic coding with spec-driven development. This article is about the whole route, not a single stop.
Eight steps, and the agent works in one
- Requirement. What should be built, in the words of whoever needs it. Whether and when is decided by a person.
- Specification. What done means, before a single line of code exists.
- Architecture context. Documented decisions that the agent receives as binding.
- A bounded task. A clear cut, its own working environment, its own clone of the repository.
- Implementation. This is where the agent works: analysis, code, tests, refactoring, documentation.
- Automated checks. Tests and linting in CI. Red goes back to the agent.
- Review. In several stages, against the architecture rules, also carried out by agents, which write nothing here and only check.
- Integration. Through a pull request, with a staging environment before production.
What stands out is how little of this is new. Specification, review, CI, pull requests: this is software engineering as good teams have practised it for years. Anyone who already does it properly has less to change for agents than the debate suggests.
What has shifted
What is new is how the steps relate to each other.
Step 5 used to be the expensive one. Writing a change cost days; today it costs a fraction of that. Everything else in the process was designed to make good use of that scarce time. Requirements could be vague because the developer would ask while implementing. Reviews were thorough because every line had been written by hand and someone had it in their head.
Today step 5 is the cheapest. That moves where mistakes are made. No longer while writing, but before and after: in a requirement that can be read two ways, in an architecture rule that is written down nowhere, in a review that only checks whether something runs.
An agent does not ask when something is unclear. It decides. And it decides so convincingly that the result does not give it away.
Anyone who only introduces step 5 therefore gets more code. Not more software. The speed comes from the agent. The quality comes from the other seven steps.
1. Requirement: prioritization stays product work
It starts with what someone wants to get done, in their own words. Not “build an endpoint for filters” but “I can't find my open cases”.
Whether that gets built, and when, is not decided by a model. That sounds obvious, but it no longer is now that agents read tickets, make suggestions and deliver the implementation along with them. Hand the order of work to the agent and you get the order that is easiest to implement. That is rarely the one that delivers the most.
Prioritization is product work. It needs knowledge about users, revenue and risk that is in no repository.
2. Specification: whatever is missing, the agent invents
Before an agent writes a line, it is settled what will be built and how you can tell it is done. This is the step where my own work has changed most. I type less and decide more.
For a user interface that means every state. List, empty state, detail, edit, success, error. It feels pedantic until you see what happens without it. If the empty state is missing, the agent builds one anyway. It looks plausible and matches nothing else in the system. In review it only stands out if someone is looking for exactly that.
Just as important is the section most people leave out: out of scope. An agent happily drifts into neighbouring functionality. A filter quickly gains a sort order, an export and a new database column. Well meant, none of it ordered, and all of it now has to be tested and operated.
For bugs I ask for a hypothesis about the cause before anything is changed. An agent without a hypothesis changes code until the symptom disappears. That is not debugging. That is guessing at very high speed, and it leaves behind changes nobody can explain.
The agent is not doing anything wrong. It fills gaps because it has to fill gaps. The only question is who makes the decision: me in the specification, or the agent while implementing. Whatever is not specified, the agent decides. And it does not ask first.
3. Architecture context: decide once
An agent without architecture rules makes its own decisions in every task. Each one is reasonable on its own. After a hundred tasks the system has a hundred architectures.
That is not a model problem. An agent does not know last quarter's decisions. It does not know that amounts of money are stored as whole cents and never as floating-point numbers. Or that retries against an external provider belong in the layer that talks to that provider, not in the application logic. It optimizes for the task in front of it, not for the system a year from now.
The obvious reaction is to put such rules in the prompt. That lasts exactly one session. In the next, half of them are missing, and which half depends on who wrote the prompt.
So I treat architecture decisions like code. They are documented, live in the repository and go to the agent with every task as binding context. Whatever a single task also touches is in its specification: which modules it may change, which boundaries it must not cross. The agent does not renegotiate these rules in every task. It applies them.
The side effect is almost more valuable than the purpose. To write a rule down for an agent, you first have to be able to state it clearly. In systems that have grown over years, that is often the first time anyone has done so.
How I store knowledge and decisions so that agents can work with them reliably is covered in An agent is only as good as its context.
4. A bounded task: one cut, one clone
One task, one clear cut. The agent changes the part of the system the task is about, not the whole of it. The smaller the cut, the easier it is to check what it did, and the cheaper it is to throw a task away and start again.
Several tasks run in parallel for me, and each one gets its own working environment with its own clone or worktree of the repository. I did not set this up on principle but after one day without it. In my own knowledge repository two sessions ran in the same directory. Twice, one of them picked up the other's staged changes and committed them under its own commit message. Once, a whole section would have been lost because a session wrote back a file the other had extended seconds earlier. It was only noticed because the diff showed dozens of deletions where only additions were expected.
Git does not warn you in that situation. For human developers this separation has been a given for years. Parallel agents are parallel developers and need the same isolation.
5. Implementation: the fast part
This is where the agent works: it reads the existing code, implements, writes tests, refactors and documents. I use more than one agent for this, depending on the task, and switch tools when another is better at a particular kind of work. The choice is interchangeable. The process around it is not.
What matters is what does not happen in this step. The agent decides nothing that was not already decided in steps 2 and 3. If it runs into an open question, that is a finding for the specification, not an invitation to be creative.
The step is fast. That is exactly why it does not belong at the centre. A team that equips itself with agents and stops here has increased the speed of writing without taking along the ability to check what was written.
What an agent can do in a grown codebase and where it fails is covered in Coding agents in a legacy codebase.
6. Automated checks: a condition, not a recommendation
Tests and linting run in CI, on my own runners. The result is a condition for acceptance, not a recommendation. If a check fails, the task goes back to the agent. It never reaches review.
Acceptance is decided by exit codes, not by whether an agent considers itself finished. An agent reliably reports success. Whether that report is true is answered by a command that ends with a non-zero value when something is wrong.
These checks grow out of incidents. In my knowledge repository a formatting rule was written in four places, in every instruction file each agent reads at the start. Two days later a single clean-up run added twenty lines that broke exactly that rule. Phrasing the rule more forcefully would not have helped: an agent that skips a rule also skips the stronger version. Since then a hook checks before every commit and blocks it with a reason.
That has become my most important rule for this step: whatever can be expressed as a check, I do not write down as an instruction. I build the check.
Which checks an existing system needs before agents can work in it safely, and why old code is often at an advantage, is covered in Is your code too old for coding agents?.
7. Review: a different question from CI
After the automated checks comes review, in several stages and also carried out by agents. If it finds something, the task goes back to the agent that implemented it, with the finding as new input.
The separation between steps 6 and 7 is the real point. A review used to be both at once: bug hunting and architecture discussion in a single comment thread. Bug hunting usually won, because it is more concrete and reaches a result faster.
With agents that becomes dangerous. Far more changes arrive than before, and every one of them looks tidy. A review that only checks whether something works waves architecture through by the dozen.
Whether the code runs has been answered by the checks. Review does not need to ask again. It asks something else: does this change fit the system that should still exist a year from now? It checks against the rules from step 3, not against the reviewer's taste.
In short: tests check whether it runs. Reviews check whether it may stay.
8. Integration: traceable rather than green on a laptop
Changes are merged through pull requests. That makes every change traceable: reason, specification, checks, review. When someone asks in three months why a piece of code looks the way it does, the answer is in one place and not in a chat session nobody can find.
Delivery runs through a pipeline, with its own staging environment before production. That something works on one machine is not a criterion. That has always been true for people. For agents it is doubly true, because an agent will adjust its local environment until it is green.
What stays with people
The division in my work is clear.
What stays with people: what gets built, in which order, which architecture applies and which rules everything is checked against. In other words product decisions, architecture, prioritization and the standards.
The agents speed up analysis, implementation, tests, refactoring and documentation. They check each other. But they do not set their own standards.
That is also the difference from what is currently being sold as vibe coding. There, the agent gets a wish in one sentence and decides the rest. In my process it gets a specification and an architecture context, and what it delivers is accepted when it passes checks and review, not because it runs locally. The speed comes from the agent. The discipline comes from the process, and it is not negotiable when things are urgent.
Where I would start in a team
Not with the agent. The order I would recommend:
- Step 6 first. One command that runs tests, static analysis and linters and turns red in CI. Without it, every further step is a matter of trust.
- Then step 3. Write down the five architecture decisions that are broken most often. Not all of them, just the ones that hurt.
- Then step 2. A specification template with a mandatory “out of scope” field and, for bugs, a mandatory field for the suspected cause.
- Then step 7. A review that explicitly checks against the rules from step 3, not against taste.
- Only then more agents. Parallelism pays off once every task has its own environment.
That sounds like a lot of preparation. In practice it is a few days, and it pays off in the first week with agents, when you no longer have to read every pull request yourself in order to trust it.
Frequently asked questions
Isn't this process too heavy for small changes? The steps stay, their size shrinks. A specification for a typo is one sentence. Steps 6 and 7 must never be dropped, though, because small changes are the ones least often looked at.
Is an agent review worth it if a person looks anyway? Yes, because it does different work. The agent review checks every change against every rule, including the fiftieth change of the day. The person checks whether the rules are still the right ones.
Which model is best for implementation? That changes every few months, which is exactly why it is the least important decision in the process. If your quality depends on one particular model, you rebuild it with every switch.
Does this work in a system that has grown over years? Yes, often better than in a new one, because the edge cases are already known. The effort lies in steps 3 and 6: writing down rules that so far only existed in people's heads, and getting checks running again that were switched off at some point.
The agent is one of eight steps. Leave out the other seven and you get more code. Take them seriously and you get software, faster than ever before.
How a process like this is introduced in an existing team is described under Introducing Claude Code.
