← Back to all posts

Verification Is the Bottleneck

The headline finding from Martin Fowler's Future of Software Development Retreat: "Code generation is no longer the bottleneck — verification is." The industry's most respected voice just validated the thesis.

verificationharness-engineeringmartin-fowleragentssoftware-engineeringcorrectness

Martin Fowler published his notes from the second Future of Software Development Retreat today. The retreat gathers senior engineers and executives from across the industry to assess where software development is heading. Fowler's notes are worth reading in full. The headline findings are worth sitting with, because they converge on a thesis this blog has been building across multiple posts.

The Thoughtworks report from the retreat surfaced five headline findings. Three of them are directly about the topics we've been covering:

"Code generation is no longer the bottleneck — verification is."

This is the exact argument from the Sonar AC/DC post: the verifiers are king. It's the argument from the harness engineering post: evaluation infrastructure matters more than model intelligence. It's the argument from the data-driven design post: you can't improve what you don't measure. And now it's the headline finding from a room full of industry leaders at a retreat convened by the most respected voice in software engineering.

When a thesis shows up independently in product form (Sonar's AC/DC), in academic framing (harness engineering as a discipline), and in Fowler's retreat consensus, it's no longer a prediction. It's a description of where the industry is now.

"'Harness engineering' is emerging as a distinct, ownable discipline."

This blog has been arguing for harness engineering as a first-class discipline since May 2026. Fowler's retreat now names it as an emerging field. The recognition matters because "distinct, ownable discipline" is the language of organizational design. When something becomes a distinct discipline, it gets budget, headcount, career tracks, and dedicated tooling. Harness engineering crossing that threshold means the teams that already have harness engineers are ahead, and the teams that don't are about to discover they need them.

"Legacy modernization is the clearest, most defensible near-term value pool."

This is less obvious but equally important. The retreat found that the most defensible use case for AI coding agents isn't greenfield development — it's modernizing legacy systems. Agents can ingest old codebases, understand their structure, and systematically refactor them in ways that would take human teams years. The value is measurable, the risk is bounded (the old system already works, so you can compare), and the alternative cost is known (maintaining the legacy system indefinitely).

The other two findings are about organizational dynamics rather than technical architecture, but they're equally revealing:

  • "Organizations are colliding with a real apprenticeship crisis." If agents write the boilerplate and seniors only review, how do juniors learn? The apprenticeship pipeline that produced every senior engineer reading this post is being disrupted in real time, and nobody has a convincing answer for what replaces it.
  • "The executive/engineer expectation gap is a bigger risk than any technical limitation." Boards see 3-5x productivity claims and expect headcount reduction. Engineers see the bugs, the security issues, and the unrequested features agents insert. The gap between those perspectives is wider than any model capability gap.

The most telling detail

Fowler shares a story about a team that spent three days investigating a feature an agent inserted that nobody asked for. Three days trying to figure out who requested it, what it was supposed to do, and whether anyone wanted to keep it. Three days of engineering time consumed by code that should never have been written.

This is the productivity paradox in microcosm. The agent saved someone 30 minutes of typing and cost the team three days of investigation. Net productivity: negative.

Fowler also notes that agents don't learn. The best they can do is update context. Every mistake an agent makes, it will make again unless the harness explicitly prevents it. Every unrequested feature it inserts, it will insert again unless the guide constraints explicitly block it. The agent is not getting better on its own. The harness has to get better around it.

The law professor experiment

One of the most striking anecdotes in Fowler's notes is unrelated to software engineering but deeply relevant to how we should think about LLM output. Law professors evaluated answers to contract law questions — some written by professors, some by LLMs. The professors rated LLM answers higher than their peers 75% of the time. LLM answers were flagged as harmful 3.5% of the time. Human professor answers: 12%.

LLMs outperform domain experts on short-form domain questions judged by those same domain experts. And they produce fewer actively harmful answers.

This doesn't mean LLMs should replace law professors. It means the quality bar for agent-generated output is higher than most skeptics assume — and the error rate of human experts is higher than most humans assume. Verification isn't just for AI output. It's for all output. The difference is that humans have been dodging systematic verification for decades, and agents make the need undeniable.

DSLs as the bridge

Fowler discusses work by Unmesh Joshi and Spencer Nelson on using Domain-Specific Languages as an interface layer between LLMs and systems. The idea: design a small, token-efficient language with hard security boundaries. The LLM generates DSL code. A deterministic runtime executes it. The DSL constrains what the LLM can express, which constrains what it can break.

This is pledge(2) for agents — a restricted interface that makes the wrong thing impossible. If the DSL has no way to express "drop this table," the agent cannot drop a table, no matter how badly it hallucinates.

Fowler notes that LLMs have historically lowered the barrier to building DSL parsers and tooling, which was the main obstacle to DSL adoption. But his more interesting point is that the DSL is just a projection of a semantic model — and the semantic model is what matters. LLMs may let us explore new ways to project those models.

The LLM voice problem

Fowler closes with a personal reflection on what he calls "LLM miasma" — the recognizable stylistic signature of AI-generated prose that triggers what he describes as intellectual nausea. He's reversing his earlier position that non-professional writers should use AI to polish their prose. The LLM voice is now so pervasive that it discredits writing before the reader engages with the content.

His antidote: read your drafts aloud. Speech patterns are closer to your authentic voice. If it doesn't sound like something you'd say, rewrite it until it does.

This matters for agent-era engineering in a way that isn't immediately obvious. If LLM-generated code comments, commit messages, and documentation all carry the same stylistic signature, teams will develop the same antibodies Fowler describes. They'll stop reading. The code will compile but the knowledge transfer won't happen. Authentic voice isn't just a writing concern — it's a knowledge-sharing concern in a world where agents produce most of the text.

What this means

Fowler's retreat didn't produce new ideas. It produced independent confirmation. The people in that room — senior engineers, executives, thought leaders — converged on the same conclusions that teams on the ground have been reaching through trial and error: verification is the bottleneck, harness engineering is the discipline, legacy modernization is the beachhead, and the gap between what executives believe and what engineers experience is enormous.

If you're building agent systems, these findings are your strategy document. Verification infrastructure. Harness engineering as a dedicated function. Legacy systems as the proving ground. Closing the expectation gap with data, not demos. And writing — code, docs, commits — in a voice that doesn't trigger the antibodies.

The industry's most respected voice just said what this blog has been saying for months. The difference is that when Martin Fowler says it, organizations listen.

References: