Thoughtworks Shares: Why Senior Developers Remain Wary of Coding Agents

Why do good developers remain wary of Coding Agents?

Built ≠ ready for production! A share from @rachellaycock: https://t.co/oq44nHaY4o

Rachel found that many senior developers who have always loved trying new things—even inventing their own tools and practices—are instead cautious about agentic development. The simple explanations (loves writing code, fears losing their job) hold for some people, but she thinks there's something else behind it. After the September Technology Radar open discussion pushed agents to their limits, she saw that layer of concern clearly.

Thoughtworks has always emphasized "do the right thing, do the thing right": it works, it can still be changed next year, and it doesn't fall over in production. Continuous integration, pairing, automated testing, continuous delivery, microservices and the like were adopted or championed by them early on for exactly this reason. Early coding agents easily produced code that "should never go anywhere near production," and developers don't necessarily understand the gap between "building it" and "running it safely." The tools have improved enormously, but senior developers are still asking: Is the behavior right? Are the boundaries right? Can it evolve? What happens when it fails? Can another team take it over? At a larger level, we still have almost no long-term production experience with building systems this way. The vast majority of systems online today were still built the old way, by human hands; the new way has not yet truly been "lived in."

She stresses: these people are not refusing assistants, they are refusing to take their hands completely off the steering wheel; they haven't yet seen enough guardrails to dare let agents run wild on their own.

A whiteboard experiment Giles Alexander, CTO for the European region, led senior engineers, infrastructure consultants and product colleagues through a one-week experiment: no one writes code, it's all handed to agents. The goal was not to prove that an aviation-related application could be built in a week (they got to about 80%, and the author jokes, "you know what that means"), but to observe "what team work becomes when coding is entirely handed to agents."

What struck her most: people spent most of their time at the whiteboard, clarifying the domain, drawing boundaries, deciding next steps, and giving agents executable plans; agents, meanwhile, kept churning out code after hours. People were also designing feedback loops: tests, contracts, architecture checks, delivery pipelines, and writing what they learned into the harness so the next round of building and testing would be more stable. Interestingly, the person who ended up committing the most feature code was the product colleague. They roughly estimated: about 2/3 of the time at the whiteboard, 1/3 on the harness—which may hint at the future division of labor, but she immediately pours cold water on it: the story isn't over yet.

The app runs, but the build is often red The app runs, but the build is often red, and "it works on my machine" is back. A frequently red build numbs alerts: red no longer means "stop, investigate, fix"; and when checks can't be trusted, green no longer gives peace of mind either. This is exactly the uncertainty continuous integration was meant to eliminate. The cause may be parallel agents stepping on each other's changes, the system not being modular enough, changes outrunning the checks, or several of these combined. She believes continuous delivery / DevOps will face a round of re-examination in the agent era; DORA 2025 also notes: AI adoption is associated with higher throughput, but with lower delivery stability.

There's still debate internally: when people don't read code line by line and tests are generated by agents alongside the code, what role does TDD play? How do acceptance, contracts and boundary checks provide confidence without being brittle? How much design should be done before starting? How big should batches be—many teams are expanding from Story to Epic—and can CI keep up? Two rounds of the experiment didn't give complete answers either; she would rather senior developers take part in such experiments to figure out which old practices still hold up and where new practices are needed.

The skiing metaphor (and where it falls short) She compares beginners to kids charging down the mountain without a care; senior developers are like people who learn to ski as adults—they know the cost of breaking a leg, and haven't yet learned to turn and brake. Martin Fowler points out the flaw in the metaphor: on a ski slope countless people make it down safely, and instructors have taught thousands; agent development is more like unknown wilderness: it's still unclear which skills matter most, almost no one has safely completed the whole route, and feedback is slow and sparse. Whether a system really works has to wait until it has run in production for a while, survived a few rounds of changes, and not sent all the planes to Aberystwyth—built ≠ works in production. Charity Majors' line is also cited: staging is just an "advanced laptop," only production is production. So when leaders describe caution as "not curious, falling behind," they are often looking at the wrong thing: these people are not trembling on a beginner slope everyone can handle, they are looking at an uncharted map and asking whether the route makes sense.

Challenges for both sides Leaders need to distinguish "useful worry" from "simple resistance to change," and give real room for experimentation: time, permission to make mistakes, and not using "how much code the agent produced" as the success metric. Developers need to bring their experience into the experiments, and also be ready to admit that some old assumptions no longer hold. Some practices will become more important, some need to change shape; no one will hand out a ready-made map first. If you care about doing things right and doing them solidly, this caution is exactly what the new way of working needs—set out with vigilance.