The Missing Row in the History of Software Development

Why orchestrated agents may be the fifth model after Waterfall, Agile, AI shaping, and vibe coding.

The Missing Row in the History of Software Development

There's a chart going around that made me stop scrolling. Four rows, four ways to build software, each drawn as a vehicle being assembled: Waterfall (plan long, arrive late), Agile (usable at every step), AI shaping (generate something terrifying, then refine it), and Vibe coding (no process — a car that slowly disappears under a pile of junk). It closes with a line I haven't stopped thinking about:

"You can't own what you don't understand."

Credit where due — the chart is from The AI OS ("Master the machine. Stay human."), and it's the sharpest one-page summary of our industry's history I've seen. But I think it's missing a row. Let me make the case.

Four rows, four verdicts

Waterfall gave us predictability and handed us obsolescence: by the time the car rolls out, the road has changed. Agile fixed that — ship a skateboard, then a bike, then a car — value at every step. It's still the best thing we've ever agreed on as an industry.

Then AI arrived, and the chart gets honest. AI shaping — generate a monster on day one, carve it down — actually works, but you're sculpting something you didn't build, hoping you find every tumor. And vibe coding is the cliff: prompt, accept, prompt, accept… it's exhilarating for a week. Then someone asks "why does this function exist?" and nobody — not you, not the model — can answer. The junk pile in the drawing isn't the code failing. It's ownership failing.

The chart ends at a cliff

Here's what bothers me: row 04 is where most AI-assisted development actually happens right now. The chart diagnoses the disease and stops. But the answer to "AI without process is chaos" cannot be "less AI" — the speed is real, and nobody is giving it back.

So what would row 05 have to look like? Read the first four rows as requirements:

  • Keep the machine speed of row 04.
  • Keep the incremental value of row 02.
  • Keep planning — but small and continuous, not row 01's monolith.
  • Keep generation — but decompose BEFORE generating, not row 03's carve-after.
  • And add the one thing none of them have: a written trail that preserves understanding.

Row 05: Orchestrated agents

I'd call the missing row orchestrated agents — some people say "structured agentic development." Whatever the name, the class has four signatures:

  1. Decompose before you generate. An audit produces findings; findings become a task table; only then does an agent write code. No monsters to carve.
  1. Separate the roles. Planner, Worker, Validator, Mechanical — different kinds of thinking, assigned to different agents (even different models). The one that writes the code is never the one that approves it.
  1. "Done" is not "valid." An agent saying "done" means nothing. A separate verification step — run the tests, re-audit the folder — flips a second checkbox. Two columns, not one.
  1. Every step writes a file. Plans, audits, task reports, standups — dated, diff-tracked, sitting in the repo next to the code. That trail is not bureaucracy. It's the mechanism that keeps a human able to answer "why does this function exist?" six weeks later.

That last one is the whole point. The original chart's tagline says you can't own what you don't understand. Row 05's answer: then make the process write the understanding down.

What this looks like in practice

I didn't arrive at this by theorizing — I arrived at it by needing it. I maintain a 12-package open-source monorepo (the WBC-UI ecosystem) alone, with AI agents doing much of the work. Vibe coding at that scale isn't a risk; it's a guarantee of collapse.

So I built wb-flow: 33 commands, one loop, run every session — Orient → Plan → Execute → Validate → Commit → Close. Every command is a template (same input, same shape of output), and every output is a markdown file under .wb/workflows/reports/, dated and diff-trackable.

A real wb-flow plan after execution and independent validation

The plan table above is a real file from my repo — after execution. Look at the columns: every task links to its own execution report, names the file it changes and the command that verifies it, and lists which model built it and which model reviewed it. "Done" and "Valid" are two different checkboxes, flipped by two different commands — and Valid comes with a score (9/10, 8/10, 10/10), because an agent saying "done" is an opinion; a validator's score is a verdict. When the next session starts, the agent re-reads that folder and picks up exactly where we left off. Nothing lives only in a chat window.

To be clear about the claim: I'm not saying wb-flow is "the next methodology." Waterfall and Agile earned their rows over decades and thousands of teams; wb-flow is one founder's implementation, validated on one real portfolio. I'm claiming the row exists — and that its signatures (decompose first, separate roles, verify separately, write everything down) will be recognizable in whatever the industry eventually standardizes on.

Two objections, answered honestly

"Isn't this just Agile with robots?" — It inherits Agile's ceremonies, deliberately: standup, plan, review. But the cadence is a session, not a sprint; the team is a set of models, not people; and the ceremonies produce files, not meetings. Agile optimized human-to-human coordination. This optimizes human-to-agent memory.

"Isn't the process overhead?" — Yes: a few minutes of file-writing per session. That's the price of being able to answer "why is this here?" in month three. Compare it to the alternative in row 04 — archaeology on a codebase nobody understands, including its author. The overhead IS the ownership.

The row will be drawn eventually

Every previous row was named after teams had already been living it for years. Right now, thousands of developers are independently inventing pieces of row 05 — spec-first prompting, agent roles, verification loops, plan files. The chart just hasn't caught up.

You can't own what you don't understand. But you can build a process where understanding is a by-product of the work — written down, one file at a time.

—

wb-flow is open source: flow.wbc-ui.com · npmjs.com/package/wb-flow · github.com/wissemb11/wb-flow

Chart concept inspired by The AI OS's methodology illustration — the four-row version is theirs; the fifth row is my argument.

</div>