What’s actually true in it
Vagueness is more expensive than it used to be. Give a person a fuzzy request and they follow-up by asking what you meant. Give an agent the same request and it fills the gap with a confident guess, then keeps building on top of the guess. I said in the last post that vague items are more dangerous now for exactly this reason, and I still think so.
So yes, be clear. Write down what you want, what done looks like, and the constraints we have to live inside. After years of “working software over comprehensive documentation” being read as “don’t write anything down,” written intent is coming back, and I think that’s a good thing.
But clear isn’t the same as complete. Being specific about the item in front of you is one job. Knowing everything about item forty before you start item one is a completely different job, and it’s the one waterfall asked for. Mixing those two up is where this whole argument goes wrong.
Waterfall is a gate, not a document
What makes something waterfall isn’t that the requirements got written down. It’s the sequence and the sign-off. You don’t build until scope is frozen, and changing it afterward costs you a change request.
Nobody I know who’s actually building with AI works that way. Here’s what it looks like for me. I write a spec and start building against it, and within the hour the spec is wrong. An ambiguity shows up that nobody could see on paper, or an approach turns out dumber than it looked, or the data won’t support what the spec promised. So I update the spec and keep going.
That’s discovery happening inside development, while the work is moving. It’s the same document waterfall would have produced, with the opposite lifecycle. Waterfall says discovery finishes before building starts, and building with AI keeps proving it can’t.
Why being wrong got more expensive
Waterfall didn’t fail because people typed requirements too slowly. It failed on the things nobody can know in advance: what people actually do with the thing once it exists, how the legacy system really behaves, what the data looks like when you finally open it, and what compliance says when they finally see a screen.
AI didn’t remove any of those. It writes code faster. It doesn’t tell you whether anyone wants it.
So think about what a big batch means now. Before AI, a big batch meant months of building before anybody saw anything, and months to discover you’d built the wrong thing. That hurt, but at least the slowness put a ceiling on how much wrong you could produce. Now an agent can build a large, coherent, extremely plausible-looking wrong thing in an afternoon. If your feedback still arrives at the end of the batch, you’ve built a lot more of the wrong thing by the time anyone tells you.
And it won’t look wrong. Agent output arrives polished and confident whether or not it’s correct. A rough human draft warns you to read it closely, where a big polished batch invites everybody to nod it through.
AI made the car faster. It didn’t make the map any better, and a faster car with the old map just gets you to the wrong place sooner.
Up-front certainty piles work on your constraint
In the last post I argued that in a lot of AI-assisted delivery, the constraint has moved to getting work ready. The decision, the approval, the answer that belongs to somebody outside your team. Building isn’t what holds work up anymore.
Now look at what “know all the requirements up front” asks you to do. It asks for more of that getting-ready work, for more items, before any of them can start. That’s stacking work in front of the exact step that’s already your constraint. The queue there gets longer, the first piece of real feedback gets pushed further out, and the speed you gained on building sits idle waiting for the batch to clear.
So the up-front approach takes the slowest part of your system and makes it carry more, while the fastest part waits.
Small items are how you control the risk
If being wrong is the risk, the size of the item is the size of the bet. A small item is a small bet. You find out quickly whether it was right, and if it wasn’t, you’ve lost very little. A big item is a big bet, and with AI it’s a bigger bet than it used to be, because more got built before anyone looked.
That’s what right-sizing is for. Before you pull an item past your Start line, check it against your SLE and give one of three answers: it fits, it’s too big so slice it, or you can’t size it yet. An item that fits your SLE is an item that puts real feedback in front of you inside a timeframe you already know.
“Can’t size it yet” is the honest answer for a lot of what the up-front approach is trying to pin down. It means there’s something to figure out first. Figuring it out is real work, and it belongs on your board where you can see it age, not in a requirements document that has to be finished before anything moves.
And keep the spec alive. Write it for the item in front of you and expect to rewrite it. A spec that changes once the build starts is the process working, not the process failing.
Run this on your own numbers
If knowing everything up front were working, you’d see it on your board. Items would finish inside your SLE, your cycle times would be stable, and your forecasts would land.
So go look. If your teams have moved to bigger batches since the agents showed up, here’s where I’d check.
Your cycle time scatterplot. Look at the top of it. A tail of items that took far longer than your SLE is what big bets look like after the fact.
Work Item Age on what’s in progress right now. Items aging past your SLE are the ones still waiting to find out whether they were right.
Items going backwards. Work that moves back to an earlier column, or gets reopened after it was done, is rework. Rework is just feedback that arrived later than it should have.
And if someone in your organization is making the waterfall argument, ask them one question. Of the features you built that way, how many got used the way you expected? If the answer is “not many,” the up-front certainty was never certainty. It was just written down with confidence.
The part I’d want you to take away
AI made building cheap. It didn’t make learning any faster, and the only way I know to learn faster is to finish smaller things and look at them. So write things down, be specific about the item in front of you, and keep your items small enough that being wrong costs you an afternoon instead of a quarter.
Next post: what a Definition of Workflow looks like when your team is people and agents working together.
This is the third post in a series on what actually changes when AI lands in a delivery organization. The first is AI, Kanban, and a restructure. You can prove something moved, not what moved it, and the second is AI boosted your throughput. Your strategy didn’t move.
Liz Rettig is a Professional Kanban Trainer and the founder of Lil Agile Monster, which makes delivery predictable using Kanban, flow metrics, and forecasting. Learn more at lilagilemonster.com.
