GitHub shipped Spec Kit. You write a spec, review it, turn it into a plan, review that, break the plan into tasks, and only then let the agents start coding. A human signs off before each handover.
Amazon shipped Kiro, an IDE that centers on requirements, design, tasks, and approvals.
Thoughtworks placed spec-driven development on their Technology Radar.
8090 operates a software factory that took apart an 18-million-line COBOL billing engine — one nobody fully understood anymore — and reverse-engineered it into more than 100,000 plain-English rules in 40 days. Requirements recovered first, construction after.
Phases. Documents. Sign-offs before construction.
Describe this workflow to an engineer in 2015 and they would have named it immediately, then lowered their voice before anyone heard them.
Waterfall is back.
The bottleneck keeps moving
Each software methodology is an economic assumption about which resource will run out first.
In the 1970s and 80s, construction was the scarcest resource. Computer time was expensive, programmers were scarce, and compiling took forever. Defects were costly to correct, too: Barry Boehm's research found that fixing a problem after delivery often cost a hundred times more than catching it during requirements and design. When construction is costly, the money should be spent on specifications and reviews prior to construction. At those prices, the paperwork was cheaper than the mistakes.
Every other type of engineering is still priced like that. Civil engineers don't just go and build a bridge. Surveys, load calculations, blueprints, reviews, approvals... and only then, after all that, concrete — because concrete doesn't un-pour. The design carries the risk on paper first. Programming in the 80s was a lot closer to this world.
Agile was a bet that the prices had flipped. By 2001, the cost of programming was cheap and getting lower. The real challenge was figuring out what users really needed. Requirements became outdated before we even had a chance to turn in the documents. More was learned from a working increment shown to real users than from a beautifully approved specification that ended up sitting in a cabinet collecting dust.
When iteration is cheap and knowledge is scarce, we ship something small, learn, and adjust. That was the right trade too. Agile was the correct choice, and it won.
Then, construction became free.
Not cheap — free, effectively. In the time it used to take a team to ship one sprint, a coding agent generates the same result. And that exposed the fine print on the agile bet: iteration was only cheap because a human understood each increment along the way. Take that away, and every free iteration stuffs the codebase with code that no one got a chance to read.
The bottleneck moved again, from creating to comprehending. This brilliant article put it well: generation is a wide mouth, verification is a narrow neck, and speeding up the mouth just leads to a deeper pile.
I guess software is the only engineering field where construction costs have collapsed — twice. The day robots pour concrete the way agents write code, civil engineers will be engaged in the same debate.
Output is booming. Everything else is complicated.
DORA's 2025 report found AI tooling close to universal, at about 95 percent of developers, and most developers reported productivity gains. Yet organization-level delivery metrics remained flat. DORA's conclusion was restrained but important: AI amplifies the system it enters. It does not repair that system for you.
Faros AI's telemetry tells the less restrained version. After adoption, tasks completed per developer rose by about 21 percent and merged pull requests nearly doubled. Bugs per developer also rose by 54 percent, incidents per pull request by more than 240 percent, and median review time by more than 400 percent.
GitClear studied 623 million lines of changed code from 2023 to 2026 and found the identifiable signs of code written faster than it is understood. Block duplication surged 81%. Copy-and-paste increased by 41%. Refactoring — the changes people make to code they understand well enough to improve — fell from a 2022 level of 21% to under 4%. Constructs that mask errors increased by 47%.
Comprehension debt continues to accumulate while the tests keep passing.
But rest assured, these findings do not indicate that agents are bad coders. They are often very good coders.
The problem is we put nearly free construction into processes whose entire safety model was a human understanding each change on the way through.
What the new waterfall actually looks like
The classic diagram — requirements, then design, then code, then test, in one straight line with no way back — comes from Winston Royce's 1970 paper. What almost nobody remembers is that Royce drew it as a warning. He wrote that building software in a single pass "is risky and invites failure," then spent the rest of the paper adding feedback loops between the phases to make it survivable.
Here is what those phases look like when agents do the construction.
First, one writes down the intent in terms the business can understand, and confirms it before construction begins. That document is now the boundary between human judgment and machine labor.
Then the design is reviewed by experienced engineers. The intent is made clear before the agents write a line of code.
Construction comes next. This is the nearly free part, so let the agents do their work rapidly while ensuring they adhere to the boundaries people agreed upon.
Finally, confirm that the outcome matches the documents. "Done" should mean "matches the confirmed intent," not "the tests passed and everyone looked the other way."
Requirements, designs, tasks, changes, reviews, and test evidence can also live in one knowledge graph, where every merge records which requirement it serves. Once this connection is made, tooling can walk the graph and show the moment something has strayed from the intent.
Iteration can be implemented where it makes the most sense: in small changes made within the confirmed intent, and in the next version of the documents.
What is no longer feasible is assuming a human understands each change simply because the work arrived in small increments. Agents dispelled this assumption.
We spent two decades getting good at shipping fast. The next skill to relearn is older: being right before we build.
I build and run Conveyor, an open-source software factory that implements exactly this: confirmed specs, staged checkpoints, agents on the line, every merge traced to the requirement it serves.
Top comments (0)