Martin Fowler's fragments from July 21, notes from Thoughtworks' second Future of Software Development Retreat, land on a claim worth sitting with: code verification, not code generation, is now the primary bottleneck in AI-assisted development. When generating a working function takes seconds, the constraint shifts entirely to confirming that function is correct, safe, and consistent with everything else in the codebase — and that confirmation step hasn't gotten proportionally faster.
This article covers why verification became the bottleneck once generation stopped being one, the board-versus-engineer expectation gap the retreat surfaced, and what "vibe-coding" governance risk actually looks like inside an organization.
Generation got fast; verification didn't
For most of software history, writing code was the slow part and reviewing it was comparatively quick — a senior engineer could read a diff far faster than the author took to write it. LLM-assisted development inverts that ratio. A model can produce a plausible, syntactically correct implementation in seconds; a human still has to read it, trace its logic against requirements, check it against edge cases, and confirm it doesn't quietly break an invariant somewhere else in the system.
Think of it like a fast-food kitchen that can now cook a dish instantly but still has to send every plate through a full quality inspection before it reaches a customer — the kitchen's throughput used to be limited by cooking time; now it's limited by however fast the inspector can work, and the inspector didn't get faster just because the stove did.
When generation is instant, the codebase's actual throughput ceiling is set entirely by how fast trust in the output can be established.
The board-engineer expectation gap
The retreat identified a divide between executives, who see AI primarily as a cost-cutting lever, and engineers, who are more focused on the security risks introduced by AI-assisted code. This isn't a disagreement about whether AI helps — it's a disagreement about what "helping" is actually worth once verification costs are counted. Executives measuring success by lines shipped or headcount reduced are optimizing a different variable than engineers measuring success by defect rate or security exposure.
That gap matters operationally: a team pressured to hit AI-driven velocity targets set by leadership, without a matching investment in verification tooling, is being asked to absorb the verification bottleneck as unpaid overtime or accepted risk — neither of which shows up in the metrics driving the original pressure.
Vibe-coding as a governance problem
The retreat also flagged "vibe-coding" — non-engineers or junior engineers shipping AI-generated code with minimal review — as a shadow-IT-style governance risk. This isn't new in shape (unreviewed code entering production is an old problem) but it's new in scale, because the barrier to producing plausible-looking code has dropped dramatically while the barrier to verifying it has not moved.
Organizations that don't have an explicit answer to "who verifies AI-generated code, and against what standard" are effectively letting that answer default to "whoever felt confident enough to merge it" — a policy no one actually chose but many teams are running on anyway.
What this means for builders
If your team has adopted AI-assisted coding, audit where your verification capacity actually sits — automated test coverage, static analysis, security scanning, human review bandwidth — against the volume of AI-generated code now entering your pipeline. If generation volume has grown faster than verification capacity, that gap is your real bottleneck regardless of what velocity metrics say, and it's the gap most likely to produce an incident before it produces a dashboard warning.
Conclusion
The retreat's core finding reframes the AI coding conversation: the interesting problem isn't "can models write good code" anymore, it's "how fast can an organization verify what models write." Teams and leadership optimizing for generation speed without a matching investment in verification are measuring the wrong bottleneck — and the board-engineer expectation gap the retreat identified is largely a disagreement about which bottleneck actually matters.