Waterfall development is back (and it's how I ship with AI)
In college, my MIS degree had three classes we referred to as “the gauntlet”: Systems Analysis, Project Planning, and Systems Implementation. Classic waterfall development. Design how it works and what it needs. Build preliminary ERDs and dataflow diagrams. Compile documentation. Move to detailed design in project planning, then build it in Systems Implementation.
They taught us agile was the future. Design, build, test, repeat. Each cycle was an iteration. The goal was to iterate as quickly as possible to get software into users’ hands, not spend 18 months designing and building only to discover users hated it or the software had an unfixable problem.
Ironically, the curriculum was unchangeably waterfall, but every project I’ve worked on professionally has been agile—tests, acceptance criteria, iterations.
I never thought I’d say this, but I now practice waterfall every single day with LLMs.
TL;DR: With AI coding agents, research and planning are higher leverage than writing code. The workflow is now: research → detailed planning → split work into isolated contexts → dispatch to disposable agents → audit the results. Entire waterfall cycles complete in hours or days instead of months.
From agile iterations to mini waterfalls
Where I used to spin up one agent and iterate (agile), with agent-deck and my co-creation with Hayden Kotelman—hive—the name of the game is context management.
I need to research, plan, and design as much as possible upfront so I can give the work to agents to perform. Research and planning are now the single highest leverage activities I can do, not writing code and iterating. Entire waterfall cycles are hours or days instead of 18 months.
Building context for agents
The first step is a synchronous research and planning phase. I use Claude to research and understand a domain. I spin up agents in the background to research specific things, come back with answers, and iterate on a plan.
Once I have a full markdown plan, I split it into beads. Then I create an epic with the full plan and have the LLM create all the subtasks with the context needed for an agent.
A key piece of this is acknowledging that agents get dumber as they have more context. You can read more about that in humanlayer.dev’s piece Getting AI to Work in Complex Codebases.
My goal is to have all the context needed to complete a task within a single bead and no more. I want agents to be disposable—able to create a new session at any time and pick the task back up.
It’s not about writing code
I’m not advocating for writing no code. Mechanically writing code is just significantly lower leverage than it used to be.
Besides research and planning, the second most important thing we do in production codebases is audit the code- make sure it’s legible, maintainable, and working correctly. I spend more time figuring out what acceptance criteria looks like ahead of time now, which is a muscle I haven’t flexed since I learned about TDD, and get consistently better results when I provide a way for LLMs to iterate and know if they have completed their task. I also spend more time reading code and making longer term decisions for style, maintainability, and correctness.
When to enter the loop
I like to read all PRs before submission, but I also review code generated in real-time. The less familiar I am with a domain, the more in-the-loop I want to be.
I enter the iteration loop when I want to learn or when the generated code doesn’t align with my sensibilities. If the LLM is going in the wrong direction, I coach it or fix the plan.
For small changes, you might think, “just have the LLM make the change—it’s most accurate at those.” But LLMs get slower and less accurate the more context they have. The mental overhead of typing out sentences describing variable naming, syntax changes, or documentation is rarely worth it when I can instantly see what needs to change.
For those, I open the code myself, make the change, and tell the agent to look at what I’ve done.
Building for this workflow
These principles led to the creation of hive. It’s still in alpha. We’re working on packaging sensible defaults, but it lets us dial in our workflow for rapid research and planning, agent dispatch with inter-agent communication, and rapid waterfall development.
I’m excited to talk more about this in a future post.
The nature of leverage
AI hasn’t just made us faster at agile development—it fundamentally changed what’s high leverage. Research, planning, and context management are now more valuable than writing code. Disposable agents working in isolated contexts with precisely scoped tasks complete entire development cycles in hours.
The waterfall “they” in the 2000’s is back. But instead of 18-month death marches, it’s mini waterfalls measured in hours and days. The cycle is: research deeply, plan precisely, split into contexts, dispatch to agents, and audit the results.
My job isn’t writing code anymore. It’s to think clearly, manage context, and verify correctness.