Dave Farley, founder of the Modern Software Engineering channel and a historic figure of Continuous Delivery, argues here that the public conversation about AI and software development overlooks a decisive variable: continuous delivery. Without it, AI-assisted development is not just risky, it's a trap — a complexity bomb with a delayed fuse.
His central argument unfolds in four parts. First, code has never been the bottleneck of software engineering. The difficulty has always lain elsewhere: understanding the problem, designing it, testing it, integrating it, deploying it. AI accelerates precisely the part that was not the problem.
Second, the Jevons paradox applies: when producing code becomes cheap, more of it gets produced. More code means more complexity, more integration points, more behaviors to evaluate, more maintenance. And probably less time to understand the problem. This is not a productivity gain, it is a time bomb.
Third, AI tends toward big leaps, whereas good engineering demands small, reversible steps with fast feedback. Farley cites Bob Martin ("the only way to go fast is to go well") and recounts a project where the abrupt arrival of 200 consultants on a Monday morning destroyed eighteen months of progress.
Fourth, Continuous Delivery is defined as "working so that our software is always in a releasable state". The mechanics: small increments, fast automated tests, a deployment pipeline that arbitrates releasability. The pipeline does not care who wrote the code — human or AI, it's the same standard.
Farley illustrates this with his own experience: he now teaches his AI assistant Acceptance Test-Driven Development, specifies at the acceptance level, and moves in hours through what used to take weeks — with confidence that the direction is correct. He also describes how his pipeline detected a silent schema mismatch: the AI was updating the test database but not the production database. All tests passed, the app crashed in production. The pipeline spoke up, not the AI.
His closing line sums it up: "AI doesn't replace the need for software engineering. It exposes teams that were never really doing engineering in the first place." The question is not whether AI can write code, but whether your engineering practices are robust enough to absorb code from any source — human or machine — and ship software that works.