Thoughtworks CTO says devs are wary of agentic coding because production is not the same as built

A senior developer who tells her manager she is wary of agentic coding is often told she fears change. Rachel Laycock, CTO at Thoughtworks, posted an essay on Martin Fowler's site on 29 October. The post pushes back on that framing. It is titled "Why are good developers so wary of agentic development?" The post reached 72 points on Hacker News.

The piece names the hesitation and gives it a reason. "Built is not the same as working in production", Laycock writes. The gap between a build that passes CI and a system that works in production is the point. A developer who has seen a system fail at 2am knows that gap matters. That gap is where the agentic workflow has not yet earned trust, Laycock argues.

Where the production gap sits

Laycock's argument has three legs. The first is that production readiness is not a side property of a build. It is the real test. An agent that passes a test suite may still produce a system that falls over in production. The data a user actually sends may be different. The region the test did not cover may be the one that breaks. An experienced developer treats those questions as the real ones.

The second leg is that the hesitation is not resistance. It is pattern recognition from previous incidents. Laycock points at DORA's 2025 research. The report, she writes, linked higher AI adoption to higher delivery throughput and to lower delivery stability. Faster output, less reliable release. The developers reading that report are not resisting the throughput number. They have already lived the stability number.

The third leg is about where the real work sits. A Thoughtworks internal experiment measured developer time, Laycock writes. About two thirds went on design and framing. One third went on implementation and the harnesses around it. The agent only helps the smaller third. Design, test strategy, operational plan and service shape are the other two thirds. The agent cannot write those without a human already knowing the answer.

What the post asks managers to do

The essay closes on a question of leadership, not of tool choice. A manager who pushes agentic workflows without measuring delivery stability is choosing one number and ignoring the other. Laycock asks managers to measure both. Count merged pull requests. Count mean time to recover. Count revert rate. Count the number of production incidents a release caused.

The frame matters because the public argument sits one level up from the technical one. A manager hears "my devs are afraid of AI". The devs are not afraid. They are reading one of two numbers the manager has not been asked to look at.

What a team does with this

A team using agentic coding tools has a measurement to run on itself. Pull the last quarter's deployment data. Split pull requests by whether an agent wrote the bulk of them. Compare mean time to recover and revert rate. If the numbers favour the human-written code, the hesitation Laycock describes is a measured outcome. The team's answer is a seven-layer review process or something like it. If the numbers favour the agent-written code, the hesitation has lost that round and the team has evidence to use.

The post does not say agents are bad for software. It says production readiness is not solved by faster release. Every senior developer the post describes has walked out of a 2am outage.

Source

Why are good developers so wary of agentic development?, Rachel Laycock on Martin Fowler's site, 29 October. Discussion: Hacker News thread, 72 points.