In this piece
Is AI Bringing Waterfall Back? How Much Upfront Planning Is Enough?
You approve a detailed plan. Months pass before anybody can use the result. Priorities change. If AI compresses that window, the case against planning deserves another look.
AI makes a serious case for more deliberate upfront planning in software development. Faster implementation gives a good plan less time to become stale and makes clear decisions useful sooner. We would settle outcomes, constraints and acceptance criteria before each consequential build, while keeping assumptions open to evidence.
Upfront planning means resolving decisions before implementation. Waterfall project management organizes delivery into sequential phases. You can adopt the first without freezing every requirement until the final release.
Research status: 10 November 2026. This is an argument based on primary research and a worked hypothetical. We have not run a Wavect experiment comparing waterfall with Agile, and the 100× coding scenario below is an assumption, not a measured industry result.
Why does AI make upfront planning worth reconsidering?
AI strengthens the case for upfront planning when implementation becomes fast enough that unresolved decisions dominate delivery. An agent can act on an agreed requirement immediately. If nobody has decided what counts as correct, rapid implementation can produce work that someone must reject or rewrite.
For a customer export, two agents might build the interface and API in parallel. An agreed tenant boundary, schema and error contract let both work toward the same result. An instruction to “build the export” leaves those choices to separate guesses.
A change you can put in front of users this week faces less exposure to changing circumstances than one that takes a year to implement, assuming the same initial uncertainty. Shorter implementation can improve the economics of planning without making prediction perfect.
Our essay on AI, specifications and the return of the software factory covers the broader shift in engineering work. Here the decision is how much to settle before the next build.
Was slow coding the only problem with waterfall?
Slow implementation was one way a waterfall plan could become stale. Late discovery was another. Even an instant implementation can satisfy the wrong requirement. Planning therefore needs a way to expose mistaken assumptions before the team commits too much, and a way to revise decisions when evidence changes.
Royce’s 1970 paper already warned about discovering system constraints during late testing and described feedback between development stages. It is a poor foundation for defending an inflexible, single-pass process. See the original large-system development paper.
The Agile Manifesto also recognizes value in plans while placing greater weight on responding to change. Continuing to follow a plan after you have evidence against it can waste even a fast implementation.
Is AI implementation already 100× faster?
The studies reviewed here do not establish a general 100× increase in software implementation speed. Results depend on the task, developer, tool and measured outcome. Time to pass a programming task, code activity, releases and customer value answer different questions.
| Evidence | Reported result | Boundary |
|---|---|---|
| Copilot controlled experiment, conducted in 2022 | 95 programmers recruited; completers using Copilot took 55.8% less time. | One JavaScript HTTP-server task, not complete product delivery. |
| METR’s early-2025 experiment | 16 experienced maintainers, 246 issues; AI access increased completion time by 19%. | A specific repository setting and tool generation, not a current universal slowdown. |
| Writing Code vs. Shipping Code, September 2026 revision | Across over 500,000 GitHub developers, the observational study estimated a much larger rise in code activity than in releases. | Output counts are not elapsed speed or customer value. |
METR’s February 2026 follow-up says selection effects and concurrent-agent time measurement make its newer productivity estimate unreliable. The earlier slowdown should not be treated as a verdict on today’s tools.
We can take 100× seriously as a thought experiment: if a particular implementation becomes that much faster, how much does the whole project improve?
What would 100× faster coding change about the project?
In a hypothetical sequential project, 100× faster coding can make planning a larger share of delivery while leaving the total speedup far below 100×. The result depends on implementation’s original share and whether other work also accelerates. The arithmetic cannot determine the ideal planning budget.
Assume equal scope and acceptance standards, with 10 elapsed days of planning, 80 of implementation and 10 of verification and release. Only implementation accelerates. The stages do not overlap, and rework and queues do not change. These are illustrative inputs, not Wavect measurements or industry averages.
Total days = 10 + 80 / implementation speed multiplier + 10
| Implementation multiplier | Implementation days | Total days | Whole-project speedup | Planning share |
|---|---|---|---|---|
| 1× | 80 | 100 | 1× | 10% |
| 10× | 8 | 28 | 3.57× | 35.7% |
| 100× | 0.8 | 20.8 | 4.81× | 48.1% |
| Instant implementation, limiting case | 0 | 20 | 5× | 50% |
Planning occupies nearly half the 100× scenario without an extra day spent on it. Its share rose because implementation shrank. That does not establish that doubling the planning phase would help.
For your own delivery system, measure the critical path. Do not add durations that overlap. If AI also changes testing, review or rework, estimate those effects separately. The useful outcome is elapsed time to an accepted, usable change.
What should you plan before handing work to an agent?
Plan the decisions that would make a fast implementation expensive to undo: the user outcome, ownership, data boundaries, interfaces, failure behavior and acceptance criteria. Give each decision enough detail to constrain the next build. Avoid specifying harmless implementation choices merely because an agent can generate a long document about them.
For consequential changes, ask the responsible owner:
- Outcome and scope: whose problem changes, how you will observe success, and which adjacent requests are excluded.
- Constraints: which data and actions the system can access, what it must preserve, and which compatibility commitments already exist.
- Interfaces: what each component receives, returns and records when work fails.
- Acceptance and recovery: what evidence permits release, who judges it, and how you stop or recover from an unsuccessful rollout.
Epoch AI and METR’s April 2026 MirrorCode results demonstrate substantial autonomous reimplementation with executable reference behavior and detailed tests. That narrow benchmark supports the usefulness of checkable specifications; it does not establish waterfall superiority or a measured human speed multiplier.
“Handle failures gracefully” gives a reviewer little to check. “After an uncertain provider response, retain the operation identifier and reconcile status before another attempt” describes behavior that can be tested.
How much upfront planning does each change deserve?
Choose planning depth from uncertainty and the cost of reversing a decision. Settled requirements with expensive consequences deserve detailed preparation. Uncertain behavior that is cheap to change deserves an early experiment. When uncertainty and reversal cost are both high, first design a safe way to learn without committing the full system.
| Requirement uncertainty | Cost of reversal | Best next action | Example |
|---|---|---|---|
| Low | Low | Write a short acceptance contract and build. | A display change with an agreed example and no stored-data change. |
| Low | High | Resolve dependencies, failure cases and recovery before execution. | A migration that must preserve existing records and integrations. |
| High | Low | State a learning question and test a disposable version. | Two onboarding flows tested with representative users. |
| High | High | Reduce uncertainty through simulation or an isolated trial before commitment. | A new allocation policy evaluated on synthetic data before it can affect real accounts. |
If an agent can produce a safe prototype quickly, another week debating a speculative interface may be poor value. Faster building can increase the return on planning known constraints and decrease the return on predicting preferences you can observe directly.
Use reversal cost in its full sense: people affected, data lost, promises made, operational disruption and engineering effort. Cheap code generation does not make every consequence cheap. Hard security requirements remain constraints even when a spreadsheet makes a risky experiment look profitable.
When is the plan ready enough to start building?
Stop planning when the next implementation slice has an agreed outcome, explicit constraints, a responsible owner, observable acceptance criteria and a recovery path. Record remaining uncertainties and choose how to test them. Continue planning only when another decision is likely to prevent more avoidable loss than the time spent resolving it.
Consider this synthetic example: a support agent needs to request a full refund through a payment provider. Assume eligibility and approval policy are already agreed. If those policies conflict, first use the separate guide to resolving conflicting business rules before specification.
| Decision before implementation | A testable requirement |
|---|---|
| Authority | Only an authorized support role can request the approved refund for its own tenant. |
| Operation identity | Persist one stable idempotency key for the authorized refund and use a provider that supports that key across attempts. |
| Concurrency | Simultaneous clicks and duplicate deliveries cannot create separate refund operations for the same approved request. |
| Uncertain provider response | A timeout leaves the operation pending reconciliation. Do not issue a new operation merely because the response was lost. |
| Acceptance and recovery | Demonstrate authorization denial, duplicate requests and lost responses in a test environment; record how operators reconcile an unresolved outcome. |
That contract is enough to investigate provider behavior and build a bounded test integration. It is not an implemented or verified refund system. The agent can choose helper names; it cannot silently choose business rules or assume a timeout means no money moved.
What would another planning session decide that this safe implementation could not teach us more cheaply? If only document polish remains, start the bounded build.
How should a plan-first AI delivery cycle work?
A plan-first AI delivery cycle should keep implementation small enough to review and the specification easy to amend. Agree on a bounded change, implement it, test it against independently reviewed acceptance criteria, and inspect the result with its users or owner before the next build.
- Choose one outcome. Name the user, the observable change and the person who can accept it.
- Resolve costly ambiguity. Review the constraints and failure cases identified by the planning matrix.
- Generate a reviewable implementation. Split work at boundaries where you can verify behavior; record any departure from the approved contract.
- Check implementation and assumptions. Test correctness, inspect the diff and get evidence that the behavior helps its intended user.
- Update the specification. Keep the accepted behavior, rejected assumptions and next question visible before another build starts.
GitHub’s Spec Kit introduction describes evolving specifications and small, reviewable tasks. Our Spec Kit production guide covers the tooling. A structured specification still needs independent judgment about whether its assumptions are correct.
DORA’s small-batch guidance also emphasizes fast feedback for AI-assisted delivery. Keep the batch bounded by what you can verify, even when the agent can generate more.
How can you tell whether extra planning is paying off?
Judge extra planning by accepted delivery, rework and escaped defects. Measure from the start of clarification to an accepted release, including specification review and waiting. A shorter coding session is useful only if the surrounding work does not erase the gain or lower the acceptance standard.
For a proposed pilot, compare similar changes with a short task brief and with a more explicit upfront contract. Record size, uncertainty, reversal cost, team familiarity and tool versions. Randomize comparable tasks where practical; otherwise treat the comparison as descriptive and keep task differences visible.
Track elapsed lead time alongside human planning, implementation and review effort. Record reopened work, defects found after release and whether the change produced its intended user outcome. These are proposed measurements, not results from a pilot we ran.
Keep scope and quality criteria consistent: more generated lines reward volume, and more releases can reflect smaller packaging. Our AI MVP cost guide addresses project budgeting. Here, ask whether additional clarification earns its place in the delivery cycle.
Should you bring waterfall back?
Bring back serious upfront planning where requirements can be clarified and mistakes are expensive to reverse. AI makes that approach worth testing because a well-defined implementation may arrive while its assumptions are still useful. Keep scope bounded and revise the plan from evidence. Expand planning only when accepted delivery improves.
For a known workflow, we would prepare a precise specification before handing it to agents. For a product whose users or value proposition remain uncertain, we would plan the experiment and get evidence early.
If your team cannot yet agree on the outcome, constraints or acceptance owner, Wavect’s software discovery and requirements work addresses those decisions. The guide to a software discovery phase explains its scope. Our Quivr protocol delivery and migration case study provides adjacent engineering context, not evidence for an AI speed multiplier or a waterfall comparison.
Bring one proposed change to a discovery conversation. Decide what to settle before implementation and what evidence will let you release.