The anatomy of the cost, and the two ways understanding gets lost.

Every system gets built in the same order

Peel the labels off any methodology and the sequence underneath is always the same. Someone writes down what should be true, the requirements. Someone figures out what that means for the system, analysis and design. Then come build, test, review, release.

Waterfall does the whole pass once. Agile breaks it into short loops. Refinement, planning, the definition of ready. These are just requirements work wearing different names. The evidence still leans toward the loops. In a study of 1,002 projects, more agile planning tracked with higher success rates and schedules that held up better.

Treat the numbers carefully, though. No one runs the same project twice, so no study cleanly compares the cost of one method against another. The well-known claim that agile succeeds three times as often comes from the Standish reports, and IEEE Software dismantled their definitions back in 2010. What still stands is simpler and more useful. The work has to happen somewhere, and doing it late costs more than doing it early.

No method skips the order. And that order carries a consequence that shapes everything downstream. Each phase feeds on the output of the one before it. Requirements sit at the top with nothing above them to catch a mistake.

Errors flow downhill and grow

Write a wrong requirement and watch the rest of the chain. Design implements it faithfully. Code implements the design correctly. Tests confirm the wrong behavior with green checks. Review signs off because everything matches what was written.

Every phase did its job. The system is still wrong, and nobody notices until the users do.

That is why the oldest numbers in software engineering focus on the start. Boehm and Basili measured it. A defect fixed after delivery can cost up to 100 times one caught at requirements time (later studies show a smaller gap for small, simple changes, and enterprise changes are rarely either). Avoidable rework swallows 40 to 50 percent of effort, and most of that rework is simply correct execution of an incorrect start.

The AI era produced its own version of the same finding. A 2026 benchmark of 1,304 coding tasks tested what models do when a requirement is ambiguous. Every model got worse, the most advanced ones got worse the most. They produced different implementations of the same unclear requirement and could not spot or resolve the ambiguity on their own. The model does not raise its hand. It picks a reading and builds it.

Cutting analysis is not a saving. The hours you skip at the start come back in review, testing and rework, and they come back larger. This is also where the old iron-triangle squeeze lands. When scope, deadline and budget are all fixed, the first thing to go is the analysis, because it is the only work nobody can see being skipped. The cut does not cancel the work. It simply moves it downstream, where it costs more.

In a landmark field study, developers spent 58 percent of their time understanding rather than writing. The real money in software was never in the typing.

That measurement came before agents, and the share has not dropped. It has only moved. The reading is now mostly of code a model wrote. That is the shift the next section measures.

And the gaps between the phases

A wrong start is only half the story. The other half is what happens to a right one while it travels.

A requirement is written by someone who understood the business need. An analyst turns it into a specification. An architect turns that into a design. A developer reads a ticket. A tester reads acceptance criteria. Every step is a re-telling, and every re-telling keeps the instruction while dropping the reasoning.

What falls into the gaps is always the same. Why the rule exists, what must not change, which edge cases were already argued and settled. None of it is in the ticket, so the constraints that were obvious to the person who asked become invisible to the person building it.

This has been measured too. A Lund University case study of large-scale development traced communication gaps between requirements and the later phases to unmet expectations, quality problems and wasted effort. The same group’s work on distances in requirements communication found that the further apart the roles sit, the more effort a shared understanding takes.

Agents do not close these gaps. They inherit them. A brief is just one more re-telling, and an agent begins each task with no memory of the last one, so the gap between phases becomes a gap between prompts.

AI made every phase faster, except the one that matters

Agents now draft the design, write the code, generate the tests, even summarize the review. Every downstream phase got faster. The first one did not get more accurate.

An agent gives you exactly what you asked for. If the requirement is wrong, or written against a stale picture of the system, the agent builds the wrong thing with perfect confidence, and at speed.

The record shows what that produces. METR’s randomized trial found experienced developers 19 percent slower with AI on mature codebases, even while feeling faster. Faros AI’s telemetry from 22,000 developers shows tasks completed up 33.7 percent, review time up 441.5 percent, and incidents per pull request up 242.7 percent. When Stanford’s productivity group analyzed commits from more than 100,000 engineers, the net gain settled near 15 to 20 percent. AI helps most where little context is needed, and least where deep understanding is required.

A 2026 review of the evidence put it bluntly. What limits AI-assisted delivery is how well the system is specified, not how smart the model is. Garbage in, garbage out has survived every model generation. It just got faster.

Why the start keeps being wrong

To write a correct requirement for a change, you need a correct picture of the system as it is today. That picture is the problem.

A change request lands on a system older than the team that runs it. An agent sweeps the code and returns a confident summary in minutes. The wiki was refreshed by AI last month and still describes a rule deleted in the spring. The copilot’s answer is almost right. So somebody books the one architect who still remembers why the discount logic checks the calendar before the price, because that architect is the only source anyone will put their name under.

In 1985 Peter Naur argued that a program is a theory. It is the understanding, held by people, of how the code and the business fit together. The code alone cannot carry it. Teams write that understanding down, file it, and believe it is kept. But the system keeps changing underneath the pages, and nothing checks them against the code. Keeping an unchecked copy feels like keeping the knowledge. It is not.

Every phase can only be as right as the requirements. And the requirements can only be as right as the picture of the system they were written against.

You can see the cost in current data. Atlassian’s 2025 developer experience report found two-thirds of developers saving ten or more hours a week with AI, half losing ten or more to organizational friction, and finding information at the top of the friction list, ahead of technical debt for the first time. The hours AI hands back are spent rebuilding the picture, change after change.

Start right, and everything downstream inherits it

There is a way to make the first phase trustworthy. Keep the picture of the system as a living model. Every rule, screen and interface is written down as a statement, every statement is linked to the code that implements it, and every link is checked automatically.

Requirements for the next change then start from a verified picture instead of stale pages and one architect’s memory. Design consumes correct requirements. Code consumes correct design. Tests check the intended behavior. Review compares what was approved against what was delivered. The whole chain inherits the correction from the top.

An afternoon with your tracker

None of this requires believing our percentages. Pull the last twenty closed change requests and trace every hour of rework to its origin. Was it a requirement that was wrong, a picture of the system that was stale, or a genuine change of mind?

If most of it traces to the first two, your delivery does not have a coding problem. It has a starting problem, and no amount of AI downstream will fix it.

What this looks like with POLYREQ

This is the problem we built POLYREQ for. It holds the picture of your system as a specification graph. Every requirement, rule, screen and interface is a statement, every statement is linked to the code that implements it, and every link is re-checked as the code moves, so drift shows up as a signal instead of a surprise.

That changes the first phase. A new change request is written against the current state of the system rather than a document someone hopes is still true. The impact map is a query, so the affected rules, screens, integrations and owners appear in minutes, and the change can be priced before anyone commits to a date.

It also closes the gaps between the phases. Nobody re-tells the change down a chain, because business, analysts, engineers and agents all read the same graph. The reasoning travels with the statement, so what must not change is attached to the thing being changed rather than remembered by whoever wrote the ticket.

Agents then get briefs instead of guesses. What to change, what must not change, what evidence to bring back. When the work lands, approved and delivered are compared against the same graph, so the record stays current because it was never separate from the work.

The phases themselves do not change. Requirements, analysis, build, review, test. What changes is that the first one starts from something checked, and everything after it inherits that.

That 30 percent is a model, not a measurement. The rework cut carries most of it, so if you halve that cut the number lands near 40. Either way, fixing the start and closing the gaps is worth more than accelerating everything after them.