What I learned running AIDLC
We ran AIDLC with a novel’s worth of docs stacked to feed the process. The slog wasn’t the room or the ritual. It was how much was still unclear before we started.
We ran AIDLC by the book, with real PRDs and architecture notes in the loop. Everyone was wiped by the end.
The useful part wasn’t a verdict on any one meeting format. It was how clearly the bolt exposes thin planning.
What the bolt actually asks for
AIDLC wants proactive clarity. Design choices, requirements, edge cases, dependencies. These are the kinds of decisions you hope are already settled on before going into inception.
When that layer is hazy, nothing downstream saves you. The model doesn’t magically resolve a missing product decision. It will ask you to choose, or it will guess and keep going, and either path costs you in time and rework.
We leaned on long documents as context, which helped when the writing was specific and hurt us when the context window filled every couple of prompts and we bounced to a fresh chat. A lot of motion and a lot of text is still not the same thing as a tight spec.
The pattern that was already there
Under-documented spec starts don’t feel empty at first because humans paper over gaps in conversation. You sync, you clarify, you sync again, and you end up in a long chain of meetings that never quite nail the nitty gritty.
The new version of the same gap
Code generation is fast now, so it is tempting to skip the slow part. Fewer structured reviews, thinner briefs, “we’ll just iterate in the tool.”
If the details still aren’t there, the gaps are still there, they just show up in a different shape. Instead of a standing meeting that slowly grinds toward clarity, you get a long session with a lot of people watching an assistant stall on questions the docs should have answered already. You still depend on the same prep. You are just sitting in a different room while the gap shows itself.
So the risk isn’t “too much collaboration” or “not enough collaboration.” It is starting the bolt without rigorous enough inputs.
Stopping the gap before it hits the model
Treat vague docs as a blocker, not a vibe.
If the HLA or requirements are still moving, the bolt will churn because gaps do not get skipped. They get interrogated, which is healthy early on and expensive once you are deep in implementation.
Dependencies and assumptions need names.
If the agent fills in blanks and the room nods to keep momentum, you ship guesses, and some of those guesses will be wrong. The fix is not pushing through faster on gut feel. It is writing the assumptions down and checking them before generation runs hot.
Match sync to the work.
Planning and pre-flight benefit from more heads, but long code-generation stretches are mostly async work. A big group does not make each token arrive faster. It mostly spreads the waiting across more people.
My take
To me, AIDLC isn’t a bypass for hard thinking, and it isn’t broken. It’s a stress test for how complete the plan already was before we handed implementation to the model.
The bottleneck was never the meeting or the process itself. It was preparation, detail, and spec. Moving faster changes the shape of the room where the gaps surface. It does not remove the need for rigor upstream.