Why FDE Delivery Looks Like Waterfall Per Increment

There is a moment, early in an AI-heavy engagement, when someone proposes the familiar fix: more standups, denser backlogs, thicker role maps, a “proper” Agile operating model. It feels like control. It is often a category error.

The control system they are installing was built for a production function that no longer binds. When implementation was scarce, expensive, and slow, coordinating human coders was rational. When agentic tools can draft large volumes of software and workflow logic in hours, the expensive mistakes move earlier: misframed intent, soft architecture, unclear authority, and verification that still trusts the builder’s smile.

This piece extends the already-published cadence of Waterfall Per Increment — small complete slices with a waterfall shape inside the increment and learning across increments.¹ It does not re-teach that parent. It grounds the same economics in forward-deployed engineering (FDE) delivery: situated judgment, gated generation, and proof before autonomy.

The bottleneck moved. Most operating models did not.

For decades, software process optimised the scarce resource: human implementation. Agile’s durable gifts — short feedback loops, working software, responsiveness to evidence — attacked the right problem for that era. What many enterprises layered on top was different: elaborate coordination machinery whose premise was that coding capacity was the thing you had to ration and schedule.

Agentic coding changes that premise. Generation becomes comparatively cheap. A large wrong system can appear as quickly as a large right one. The binding work shifts upstream toward problem framing, intent, architecture, acceptance criteria, governance, evaluation, and the judgment of what should be built at all.

That is why serious FDE delivery starts to look like waterfall per increment rather than like an infinite planning theatre or an ungoverned prompt free-for-all:

Each increment can still be short. Feedback can still be rapid. What you refuse is the pretence that coordinating scarce human typing is still the main risk control once machines can type abundantly.

Large-scale session analysis of agentic coding points the same way without proving every causal claim: in a typical Claude Code session, people still make most of the planning decisions (what), while the agent makes most of the execution decisions (how); higher domain expertise correlates with more agent work per instruction and with higher rates of verified success — where “verified” leans on signals such as passing tests, matching commits or pull requests, and explicit user confirmation. The authors cannot observe real downstream business outcomes and partly rely on transcript classifiers, so this is supporting texture for the operating rule, not a controlled proof of delivery method.⁷

This is not a declaration that Agile is dead. Short loops and empirical learning remain load-bearing. It is a declaration that ceremony whose economic foundation was scarce implementation should have to re-earn its keep.

What an FDE is actually buying you

The market has started to price the role correctly. OpenAI’s Deployment Company is organised around embedding Forward Deployed Engineers who identify where AI can matter, redesign critical workflows, and design, build, test, and deploy production systems against real customer data, tools, controls, and processes.² AWS has put a billion-dollar Forward Deployed Engineering motion behind the same idea for customers and partners, emphasising reusable delivery harnesses rather than one-off heroics.³

Strip the corporate language and the job is recognisable: someone owns the path from messy operational reality to a system that carries responsibility. Discovery is not a workshop souvenir. Design is not a slide. Build is not a demo. Evaluation is not a vibe. Learning is not optional exhaust.

In practice that lifecycle is already a gated cascade: audit and discovery, solution framing, business case where needed, architecture and security and governance, stakeholder-specific artefacts from a joined ground truth, then build, test, deploy, evaluate, and write validated learning back. The wiki, the prior code, the receipts — those raise fidelity. They do not replace gates.

The skipped-framing failure (generalised)

Observed A pattern that keeps recurring in large enterprises: a transformation programme launches by reconciling inherited artefacts — a strategy recommendation, an outsourced “Agile way of working,” a governance pack expressed as yet another circle on a Venn diagram — and labels the overlap the “holy grail.” The room is asked to implement the settlement between documents. Nobody is asked the adult questions with evidence:

• What is failing today, with local proof?
• What mechanism will change that outcome?
• What baseline and success threshold would falsify the plan?
• Which inherited recommendations survive contact with reality, and which should be rejected?

Worse, the operating model can be a year old and still treat AI as off-stage while AI is already changing the production function the model claims to govern. You end up installing coordination machinery for expensive human implementation at the exact moment cheap generation is rearranging the economics.

That is not a methods argument. It is a framing failure. When generation is fast, skipped framing is not a soft delay — it is a multiplier on wrong work. Generalise the private details; keep the structural lesson: artefacts are inputs to be assessed, not commandments to be overlapped until a shape appears.

A concrete comparison — without inventing metrics

The proof burden asks for a comparison between old coordination and a gated increment on elapsed time, rework, defects, and governance outcomes. Four evidence layers are available. Only the first is a strong company case for time and bottleneck shift — and even that case is not an A/B against ceremony-heavy coordination.

Condition A — old coordination (scarce-coder assumptions)

• Rough intent in tickets and ceremonies.
• Implementation capacity managed through roles, standups, backlog grooming, and handoffs.
• “Done” often means a human team reported progress, or an agent reported success in natural language.
• Governance and acceptance appear late — after a large surface already exists.

Condition B — gated increment (FDE / Waterfall Per Increment)

• Intent, baseline, green path, architecture interfaces, authority, and acceptance stabilise first.
• Generation runs with method latitude inside that envelope.
• Independent compile/tests/smoke/evals and recovery checks decide readiness.
• Autonomy expands only after evidence; learning returns into the next slice.

(a) EXECUTED company case — elapsed time estimate and bottleneck shift

Executed OpenAI’s engineering report on building an internal product in an agent-first harness is the best concrete company case currently public.⁴ Key facts, as OpenAI states them:

• Internal daily users and external alpha testers; the team reports no manually written application code — agents produced product code, tests, CI, docs, and tooling under human steering.
• OpenAI estimates development took about one-tenth the time hand-coding would have taken. That is the company’s own estimate, not a controlled RCT and not a measurement against Condition A above.
• About five months after the first commit: on the order of one million lines, roughly 1,500 merged pull requests; initially three engineers driving agents (later seven); product used by hundreds internally.
• Early progress was slower than expected because the environment was underspecified — missing tools, abstractions, and structure for agents to pursue high-level goals.
• As code throughput increased, human QA capacity became the bottleneck. Their response was harness work: depth-first small building blocks, per-worktree bootable apps, browser/UI and observability made legible to agents, custom linters, structural tests, and feedback/review loops — not denser standup theatre.

Read carefully what this does and does not prove. It supports the article’s economic story: when generation throughput rises, the scarce resource becomes specification of the environment, feedback loops, and human judgment at review — not more coordination of scarce typists. It does not show that OpenAI tested Condition A against Condition B. It does not report comparative rework tickets, escaped defects, or governance outcome deltas versus a ceremony-heavy control arm.

(b) EXECUTED research — rejects a universal speed claim

Executed An early-2025 randomised trial found that experienced open-source developers working their own large repositories took longer on AI-allowed tasks than on AI-disallowed ones — about 19% longer in that setting — even though developers expected speedup.⁵ A later METR measurement wave shows mixed signals and is limited by selection effects as developers become unwilling to work without AI.⁶ Together these results block the lazy inference “agents always make everyone faster, so process no longer matters.” Speed is setting-dependent and still evolving. That is compatible with the OpenAI case: high throughput is possible under a heavy harness investment; it is not a free property of tool access alone.

(c) OBSERVED practitioner harness patterns

Observed From designated field turns (not client-published KPIs): clean-context builders are useful, but completion is external — deterministic compilation, full tests, live smoke paths. Green path first; then failure modes such as missing data, dead APIs, duplicates, partial completion, unsafe continuation, retry, and resume. The builder proposes; the harness disposes. Parent doctrine adds that regeneration from better intent often beats surgery on near-miss code.¹

(d) DESIGNED — residual gap for rework, defects, governance

Either way, the FDE’s leverage is upstream intent, environment design, and hard verification — not more coordination theatre for a scarce coding pool that agentic throughput has already begun to dissolve.

Pre-generation gate: what must stabilise before anyone generates

Before generation, the increment should be able to answer — in artefacts, not vibes — at least the following. Think of these as conjunctive: missing one is a stop, not a partial score.

1. Intent / outcome. Who is this for, what changes in the world, and what would make the result genuinely wrong?
2. Baseline. How the work is actually done today — including exceptions that live in one person’s head — with enough evidence to compare later.
3. Evidence already in hand. What has been opened, observed, or measured; what is still inference.
4. Green path. The minimum complete happy path and how it will be proven with a real harness, not a staged demo.
5. Architecture and interfaces. Systems touched, data contracts, side effects, and seams where deterministic software should own the path instead of an LLM.
6. Authority boundaries. What the system may do alone, what requires a person, and who is accountable for irreversible actions.
7. Acceptance tests / evals. Executable or graded cases for normal, edge, incomplete, ambiguous, and high-risk situations — held independently of the builder where it matters.⁹
8. Rollback / recovery. How to stop, resume, undo, or contain partial completion before it becomes production archaeology.
9. Named unknowns. Explicit absences and probes. Unknowns that are not named become silent assumptions inside generated code.

This is the “waterfall” part people misread. It is not a six-month requirements freeze. It is the discipline of making a small slice coherent before you spend machine throughput on it. Specification quality is now a production input, not paperwork — the same lesson OpenAI reported when early agent progress lagged until the environment was specified enough to be useful.^1,4

Supporting doctrine, not a new religion: tight intent resembles the North Star move of stating excellence criteria and returning method latitude to the model,¹⁰ while evaluation-driven development insists that behaviour earns its way through gates rather than through narrative confidence. Anthropic’s plan/execute split is a population-level rhyme of the same rule: humans own more of the “what,” agents more of the “how,” and success claims should prefer verifiable signals over self-congratulation.⁷

Inside the build: loose method, fresh workers, no self-certification

Once the pre-generation gate passes, loosen the leash on implementation. Prescribe outcomes and constraints; do not micromanage every file edit. Let agents and humans explore paths. Prefer regeneration from improved intent over endless surgery on near-miss code when the slice still fits in one coherent envelope.¹

Observed In delivery programmes that take this seriously, “fresh” or clean-context builders are useful precisely because they do not carry yesterday’s rationalisations — but they are not allowed to declare victory. Completion is external: deterministic compilation, full test suites, live smoke paths against real dependencies. The builder proposes; the harness disposes.

That separation is the difference between autonomy and cosplay. Hidden acceptance checks and independent review exist so that a capable producer cannot Goodhart the rubric it is scored on.⁹ If your Definition of Done is still “the agent said it works,” you do not have a Definition of Done.

Pre-autonomy gate: what must pass before autonomy expands

After a vertical slice works on the green path, the FDE’s job is not to flip a global autopilot. It is to earn the next unit of autonomy against failure space.

1. Deterministic compilation and tests. The system builds cleanly; automated tests that encode acceptance actually pass under an independent runner.
2. Live smoke paths. Real services, real credentials boundaries, real browser or API journeys — not only mocked happiness.
3. Eval evidence. Graded runs across normal and adversarial cases with retained failure artefacts; pass rates and failure categories are inspectable.
4. Failure modes and recovery. Explicit behaviour for missing data, malformed responses, dead APIs, timeouts, duplicates, partial completion, unsafe continuation, retry, and resume.
5. Observability and audit trail. Prompts, tool calls, decisions, outputs, errors, and timestamps sufficiently reconstructable for incident review.
6. Security, governance, authority. Permissions, data boundaries, approval rules, and non-bypassable stops for high-risk actions.
7. Rollback. A tested way to remove or disable the change without heroics.
8. Human escalation. Named points where the system must pause; people who will actually answer; no silent fall-through.

OpenAI’s description of running Codex safely inside its own estate sharpens the autonomy ladder without proving third-party outcomes: keep the agent inside clear technical boundaries; make low-risk everyday actions frictionless; make higher-risk actions explicit and reviewed; combine sandboxing, approvals, managed network and identity configuration, and agent-native telemetry so behaviour is reconstructable.⁸ That is control design, not a published incident-reduction trial — but it is the right shape of pre-autonomy discipline.

Only then expand autonomy: shadow → assist → narrow auto → wider auto, on the smallest useful action first. Deployment integrates with systems the organisation already runs. The edge is rarely “migrate everything to a new stack so the demo looks pure.” The edge is a system that carries operational responsibility inside the existing mess — with evidence.

Rapid feedback is not optional — it is the shape of the increment

If someone hears “waterfall” and imagines a year-long requirements freeze, they have left the method. Waterfall Per Increment keeps the feedback economics that mattered in Agile and throws away the parts that only made sense when humans were the scarce compilers.

• Small slices. One complete path, not a platform rewrite as the first move. OpenAI’s agent-first build likewise stressed depth-first building blocks rather than one unbounded generation pass.⁴
• Short cycles relative to the programme. Increments stay small and complete so feedback can arrive before the next slice commits; exact calendar length is context-specific, not a universal “always days” guarantee.
• Real users and real baselines. Deploy, observe, compare; then choose the next increment with receipts.
• Learning write-back. Failure shapes, evals, and architecture decisions become reusable — so engagement two starts higher than engagement one.

The loop is deliberate: audit → build → evals → deploy → observe → improve. Each stage earns the next. That is feedback with teeth, not feedback as a weekly meeting name.

What to reject — and what to keep

Reject coordination whose main product is reassurance: role proliferation without authority clarity; backlog theatre without acceptance harnesses; transformation Venn diagrams that never state a falsifiable outcome; “the model is confident” as a release criterion.

Keep everything that preserves learning under uncertainty: short increments, working software in real context, user evidence, the right to change direction after a slice, and human judgment on placement — where intelligence belongs, and where it does not.

Custom software in an agentic era still needs verification as a first-class discipline, not an afterthought bolted on when the demo becomes a dependency.¹¹ Elastic assurance — controls that match live risk rather than permanent ceremony — pairs with the bounded-risk / reviewed-risk pattern above when the gates themselves are real.^12,8

A Monday-morning sequence for the next increment

1. Write the parent intent and the wrongness criteria in one page.
2. Capture baseline and named unknowns.
3. Specify the green path and the independent harness that will prove it.
4. Lock architecture interfaces and authority boundaries for this slice only.
5. Generate with method latitude.
6. Run compile, tests, smoke, and evals you do not let the builder own.
7. Expand failure paths; prove recovery and rollback.
8. Deploy the smallest useful autonomy; observe against baseline.
9. File receipts and choose the next slice from evidence.

That is FDE delivery that looks like waterfall per increment: not nostalgia for Gantt charts, and not hostility to Agile’s empirical core. It is an economic adjustment. Generation got cheap. Framing, architecture, governance, and verification did not. Put the hard work where the bottleneck actually is — and keep the loops short enough that reality can still talk back.

Related prior coverage: Waterfall Per Increment owns the cadence this extender applies to FDE economics.¹ North Star prompting and evaluation-driven development appear only as supporting doctrines for intent and gates — not as full re-explanations.