Methodology
Requirements Dialogue
How software requirements come about when an AI does not merely write them down but genuinely understands them.
Software projects rarely fail because of bad code. They fail because nobody knew precisely enough what was actually needed — and because that gap only surfaces late, when correcting it is already expensive. Scrum tried to defuse the problem with short cycles. Waterfall tried to solve it with thorough planning up front. Both share the same blind spot: they rely on people holding a growing body of requirements in their heads without contradiction — and beyond a certain size, that never works reliably. Requirements Dialogue takes a different route: a continuous, recorded conversation between a human and an AI that sharpens each requirement until it genuinely holds, and checks automatically whether it fits everything else already settled.
The core thesis
Most development methods solve two problems at once without separating them: how people coordinate with one another, and how you actually know what is needed. When most of the coordination moves to AI agents, the first problem disappears — but the second remains exactly as important as before. Requirements Dialogue starts precisely there: one AI conducts the actual requirements dialogue, a second, unbiased AI instance checks every statement for contradictions without compromise, and every decision stays documented and traceable — not as rigid up-front planning and not as a frantic sprint rhythm, but as something that keeps growing and refining for as long as the product itself is alive.
The three-axis framework
Every development method can be measured against three questions that the usual debate almost always conflates. Considered separately, they explain why previous methods have run into their limits at different points — and why something is shifting right now.
- 01
Coordination cost
The effort of aligning several people so that their individual work fits together. In human teams this effort grows considerably faster than the team itself — more people means disproportionately more paths of coordination.
- 02
Prior knowledge
The degree to which a system's actual requirements are known or knowable at the outset. This uncertainty comes from the subject matter itself, not from the process — it cannot be planned away, only resolved step by step through real contact with reality.
- 03
Consistency cost
The effort of keeping a growing body of decisions and requirements free of contradictions while it changes over time. Historically this axis was tightly bound to the first, because the same person who did the coordinating also had to check consistency — with the same capacity limits. That coupling was never a law of nature, only a consequence of the tools available so far.
Where it sits
| Method | Coordination cost | Prior knowledge | Consistency cost |
|---|---|---|---|
| Waterfall | Not addressed | Gathered up front, but barely correctable later | Left to human discipline |
| Scrum | Made manageable through short cycles and fixed roles | Actively improved through fast feedback | Rather aggravated by slicing work up |
| SAFe | Scaled through additional process layers, not reduced | As in Scrum, but slowed down by overhead | Unsolved, requires yet another layer |
| Requirements Dialogue | Close to zero once AI coordinates the implementation | Deliberately kept open — remains the human's job | Checked technically by a second, unbiased AI instance |
Tool
CCIDE
In active development
Requirements Dialogue is not a theory waiting for an application. The methodology is taking shape directly on a real software project: CCIDE, a tool that orchestrates several AI instances to make software development visible and steerable — and that is being built by its own rules while those rules are still emerging. Every defect the methodology would not have caught counts against it; every gap that becomes visible flows back into the methodology itself. CCIDE is currently in active development.
Early access and conversation
The approach is documented openly and under continuous development. If you want to use the methodology on a project of your own, join the discussion on the substance, or simply be there early when CCIDE becomes usable — get in touch.
To the contact form