Nobody Has It Figured Out — Notes from Martin Fowler's Fragments
Martin Fowler published his latest collection of fragments from the Thoughtworks Future of Software Development Retreat. The event brought together experienced practitioners to discuss how AI is reshaping software work. These are the ideas I found most worth pulling out.
The Honest Starting Point
Annie Vella, one of the attendees, said it plainly:
I walked into that room expecting to learn from people who were further ahead. Some of the sharpest minds in the software industry were sitting around those tables. And nobody has it all figured out. There is more uncertainty than certainty.
This tracks with everything I'm seeing. The people doing the most with AI coding tools are also the most candid about what they don't understand yet. The retreat's 17-page summary put it this way: the practices, tools, and organizational structures built for human-only software development are breaking in predictable ways under AI-assisted work. The replacements are forming, but they are not yet mature.
AI Amplifies What You Already Have
Rachel Laycock, in an interview with The New Stack:
AI is really just an accelerator of whatever you already have. The 2025 DORA report places AI's primary role as that of an amplifier — a funhouse mirror that reflects back the good, bad, and ugly of your whole pipeline. AI is proven to be impactful on the speed of writing code. But, since writing code was never the bottleneck, if traditional software delivery best practices aren't already in place, this velocity multiplier becomes a debt accelerator.
This is the most important sentence in the whole piece: if writing code was never the bottleneck, making it faster doesn't fix your actual problems. Teams without solid delivery practices aren't getting faster. They're accumulating technical debt faster than ever.
Adam Tornhill's research on code health and agentic development found that LLMs performed consistently better in healthy codebases. The risk of defects was 30% higher in less-healthy code. And that was with code that wasn't anywhere near the worst of real legacy systems. The relationship is almost certainly non-linear. The worse the code, the more AI amplifies the mess.
Four Ideas Ready for Broader Conversation
The retreat surfaced four concepts the organizers consider ready for wider discussion:
| Idea | What It Means |
|---|---|
| Supervisory engineering middle loop | A new category of work between writing code and reviewing it: guiding and correcting AI-generated output |
| Risk tiering | Treating risk assessment as the core engineering discipline |
| TDD as prompt engineering | Test-Driven Development is the strongest mechanism for steering LLM output toward correct behavior |
| Agent experience over developer experience | Investment in developer tooling needs to account for AI agents as primary users, not just humans |
The TDD point keeps coming up. Fowler notes hearing it from heavy LLM users directly:
Thank you for all your advocacy of TDD. TDD has been essential for us to use LLMs effectively.
Tests are an unambiguous, machine-verifiable specification. They constrain the solution space in ways that natural language prompts can't. Tell an LLM "build me a function that does X" and the results vary wildly. Give it a test suite that defines X precisely and the output quality is on a different level.
Open Questions the Industry Hasn't Answered
Several threads from the retreat are unresolved:
Will specialist developers survive? LLMs are eating specialty skills. The LLM-driving skills are becoming more important than deep platform knowledge. This could elevate expert generalists or it could mean LLMs just code around existing silos without eliminating them.
What happens when token subsidies end? Nobody has visibility into the true cost of tokens right now. It could end up so cheap that nobody cares, or expensive enough to force careful rationing. Entire business models depend on which way this goes.
Do specifications lead back to waterfall? The natural impulse of business stakeholders is "don't bother me until it's finished." LLMs could enable that impulse, pushing teams back toward big-batch, specification-heavy development. Fowler's instinct (which I share) is that LLMs don't change the value of building and releasing small slices of capability. If anything, the promise is to increase the frequency of that cycle.
Why is nobody paying attention to security? The security session at the retreat had a small turnout. Fowler's comparison to other engineering disciplines sticks: a bridge designer bakes in a significant safety factor. Software teams are building AI-enabled systems without equivalent rigor. Platform teams need to create fast but safe paths — "bullet trains," not "move fast and break things."
Adapting, Not Resisting
Stephen O'Grady's framing of the profession's anxiety is worth reading alongside the retreat notes. Grady Booch — not exactly an AI hype man — recently described himself as "gobsmacked" by Claude's abilities. His advice to developers: "Be calm. Take a deep breath." AI is another step in the industry's long history of abstractions.
O'Grady's conclusion:
Whether one wants those doors opened or not ultimately is irrelevant. AI isn't going away any more than the automated loom, steam engines or nuclear reactors did. What's left to decide is how we best maximize its benefits while mitigating its costs.
The retreat landed in a similar place. Not debating whether AI changes software development, but figuring out how to make the transition go well. Testing, delivery discipline, clean code, thoughtful architecture. These mattered before and they matter more now. AI raises the stakes on getting them right.