Today Rachel Laycock, CTO at Thoughtworks, published a post on martinfowler.com: Why are good developers so wary of agentic development?. It is a good read. But while reading it, I had the feeling that I was reading something from 2025.
The post asks the right questions. The problem is that many of these questions already have answers. We have been working on them for more than a year under the name Spec-Driven Development.
In this post, I want to show what Rachel describes, why it feels a bit late, and where I fully agree with her.
Two thirds at the whiteboard is not a surprise #
Rachel describes an experiment. A team of senior engineers, infrastructure people and product people worked for one week on an airline application. Nobody wrote code. Agents wrote everything.
The interesting result: the team spent about two thirds of their time at the whiteboard. They worked out the domain, drew boundaries and made plans the agents could act on. The other third went into the harness: tests, contracts, architecture checks and the pipeline. And the product person committed more feature code than anyone else.
For me, this is not a surprise. This is Spec-Driven Development. When the agent writes the code, the human work moves to the left: to requirements, to the domain model, to the use cases, and to the checks that verify the result. The specification becomes the main artifact. The code becomes something the agent produces from it. The fact that the product person committed the most code is also no surprise. If the specification is good, the person who knows the business best is the one who can drive the agent best.
So the experiment confirms what many of us have seen in real projects. It is a good confirmation. But it is not a new discovery.
The open questions have answers #
Rachel lists several questions the team discussed. She writes that nobody settled them in a week, and that she would not trust anyone who claims they had. I understand this. But we are not at zero. Here is how the AI Unified Process answers them.
| Question from the post | Answer in the AI Unified Process |
|---|---|
| What role does TDD play when the agent writes the tests together with the code? | The specification is the oracle, not the code. Tests are derived from the use case specification: main scenario, alternative flows and business rules. If a test and the code disagree, the test stays red. The agent is not allowed to change the test to make the build green. |
| How do we know the tests check the right thing? | Every test carries the id of the use case it verifies. A coverage check shows which steps, flows and rules have code and tests behind them, and which do not. |
| How much design should we do before the agent starts? | Enough to make the use case unambiguous. Requirements, glossary, entity model and the use case specification come first. A use case is only implemented when its status is Approved. Open questions go into one central file, and the agent must not guess. |
| Where do acceptance and contract tests give the most confidence? | At the boundaries the use case defines. End-to-end test cases chain several use cases into one user journey. Non-functional requirements live in the architecture document and become tests too. |
| What is the right batch size? | The use case. Not a story, not an epic, and no task layer in between. A use case is small enough to review and test, and big enough to deliver real value. |
None of this is magic. It is old knowledge from the Unified Process and Use-Case 2.0, adapted for coding agents. That is exactly the point: we do not need to invent everything new. Many practices we learned the hard way still work. They just get more important.
Where Rachel is right #
I don’t want to only criticize. Three points in the post are important, and I fully agree with them.
Built is not the same as working in production. This is the strongest point of the post. We don’t yet have systems that were mostly built by agents and then ran in production for years, survived many changes and stayed maintainable. Nobody can fake this experience. We have to earn it. This is why traceability matters so much to me: when something breaks in two years, you must be able to find the requirement behind the code.
A red build must mean something. The team often had a red build while the application was running. Many agents working in parallel, changes arriving faster than the checks can finish. If people start to ignore red builds, continuous integration loses its value. I agree with Rachel that continuous delivery and DevOps will get a second wave of attention because of agents.
Batch size. Rachel hears that teams move from stories to epics because agents are fast. This is dangerous. Bigger batches mean longer feedback loops, harder reviews and more red builds. Speed in writing code does not help if the pipeline and the humans cannot keep up. Smaller units of work are the answer, not bigger ones.
She also makes a fair point about experienced developers. They are not laggards. They see the risks because they have been woken up at 3 a.m. by a production issue. Their judgment is exactly what we need.
Conclusion #
Rachel ends her post with the idea that nobody will hand us a map. I see it a bit differently. The map is not complete, but large parts are already drawn. Spec-Driven Development, use cases, traceability, the specification as the test oracle: these are not experiments anymore. They work in real projects today, also in brownfield projects.
Good developers are not wary. They ask the right questions. And in late 2026, we should stop asking only whether to work with agents. The real question is how. My answer is simple: start with the requirements, make the specification the main artifact, and let the agent do what it does best.
If you want to learn more, have a look at the AI Unified Process.