From Waterfall to Agents

Before agents joined the lifecycle, the history of shipping software was already a history of compressing the cycle. Every era attacked the same enemy — the time between "we should build this" and "a customer is using it" — and every era left one thing untouched: a human at the keyboard, doing the work by hand.

The conveyor and its discontents

Waterfall ran like a one-way conveyor: requirements → planning → build → test → ship, each phase sealed before the next began. Break something mid-stream and there was no going back — and no feedback loop between teams. A customer request that arrived mid-cycle simply waited for the next cycle. Months later.

Agile broke the conveyor into sprints. Cross-functional teams, customer feedback loops, features admitted mid-flight. Better — but simple features still took months to reach production, because building faster and shipping faster are different problems.

DevOps attacked the shipping half. Before it, dev threw builds over a wall — "works on my machine" — and ops threw them back, because environment drift meant it didn't work on theirs. DevOps unified the two and automated the pipeline: CI/CD, infrastructure as code, deploys measured in days instead of quarters.

Shift-left noticed that the unified pipeline had left security bolted on at the end, and baked it into every phase instead. Alongside it came internal developer platforms — self-serve golden paths so developers stopped filing tickets to get a database.

Why agile only got so far

It is worth pausing on the second era, because the reason it stalled is the reason the sixth one exists.

Raja SP's diagnosis, from AWS's year of running lifecycle experiments, is not that teams practised agile badly. It is that the sprint length did the damage on its own: "the sprints were longer — two weeks, four weeks — and that led to natural sequencing of work." A developer waits for the product manager to release the story. QA waits for the developer to cut a build. Nobody designed a queue; a queue is simply what a two-week batch size produces.

That reframes every era on the bar above. They were not really attacking duration — they were attacking batch size, and each one got it down by an order of magnitude until it hit the floor set by how fast humans can hand work to each other. Agile could not go below a sprint, because a sprint is roughly how often a group of people can realistically re-synchronise.

Then the model showed up

AI-assisted engineering put a copilot in the editor: autocomplete, codegen, explain-this-function, write-my-tests. Developers stayed in control; the LLM was a very fast pair of hands. This is where most teams live today.

In the wild

The arc is visible in tooling names alone: Jenkins and Travis (DevOps), Snyk and Dependabot (shift-left), Backstage and Port (internal platforms), Copilot, Codex, and Claude Code (AI-assisted). Each generation of tools is the previous era's manual work, productized.

Two ways to be stuck in this era

"Where most teams live today" deserves more detail than one line, because AWS's survey of it — a year of experiments, more than a hundred engagements — found teams settling into two failure shapes rather than one, and they fail in opposite directions.

Over-delegation. Hand the model a large, ambiguous problem and wait: build me an e-commerce platform. Raja SP is blunt about the ceiling — it "seldom works except for very small prototyping scenarios." Production work involves hundreds of design decisions, and an ambiguous brief means the model makes all of them silently. What arrives is a large volume of code the developer must now put their name on without having read. The velocity gain is real at the keyboard and evaporates at review.

Under-delegation. The senior engineer, having been burned by the above, takes it all back: I will do the breakdown, I will plan it, and I will hand AI narrow slots — write this function, check this snippet for injection. Output quality goes up markedly. But "the intellectual heavy lifting is done by the humans, which is the same as before AI also" — and the surrounding process is still the pre-AI one, so whatever the narrow slots saved is spent back in the meetings.

Read that way, the copilot era is not an era of AI doing the work. It is the era in which we found out that making the typing faster does not move the constraint — and, in both of its shapes, the constraint is the same: a human is still the only thing in the system that establishes intent and confirms it was met.

The center hasn't moved — yet

Through five eras, one constant survived: the human is the execution engine. Humans wrote the code, opened the tickets, provisioned the infra, watched the dashboards. Everything else — process, pipeline, platform — existed to serve the person typing.

Agentic engineering is the first era that moves the center. Agents become first-class citizens of the lifecycle: humans set the goal and review the work, agents execute at every phase from planning to shipping. Cycle time drops from months to hours — not because anyone types faster, but because most of the lifecycle stops waiting for a human at all.

There is a real dispute inside that last paragraph, and this pillar should name it rather than smooth it over. The AWS position is stronger than "inherits and extends": they argue the method has to be redrawn rather than fitted, that you do not "retrofit AI into existing agile," and that the sprint itself has to collapse from weeks to hours or less. On their account, the sixth era is not the fifth with agents added — it is what you get when batch size is no longer set by how often humans can meet.

Either way the same question arrives next, and it arrives with a number attached: if coding is a fifth of the work, what exactly is the other four-fifths, and why did making the fifth faster not help?