AI development punishes teams that confuse iteration with improvisation. If every sprint can redefine the user problem, data model, evaluation criteria, model behavior, and launch path, the team is not agile. It is wandering.
The process that works better is closer to interactive waterfall: a deliberate sequence of decisions, each made just deeply enough to unlock the next layer, with feedback loops built into every stage. It is not old-school waterfall where requirements are frozen and handed over. It is structured discovery with working software as the proof.
Why AI needs more sequence than normal software
Traditional software can often tolerate late product decisions. AI systems cannot. A vague user promise becomes a vague prompt. A vague data model becomes unreliable retrieval. A vague success metric becomes a model that looks impressive in demos and unmeasurable in production.
- →The product thesis has to come first: who is this for, what decision does it improve, and what behavior must the user trust?
- →The data shape has to come early: what facts does the system need, where do they live, and which fields are authoritative?
- →The eval has to exist before prompt polishing: otherwise every iteration is judged by vibe.
- →The failure modes need to be designed before launch: refusal, fallback, degraded mode, and human escalation are product flows.
The interactive waterfall loop
- 01Frame the product bet. Write the user, job, outcome, risk, and non-goals on one page.
- 02Model the domain. Name the entities, permissions, source-of-truth fields, and lifecycle states before screens are built.
- 03Prototype the AI behavior. Use thin UI and real examples to test whether the model can perform the job with the available context.
- 04Build the eval. Capture good, bad, edge, and adversarial cases so quality can be measured instead of argued.
- 05Design the operating path. Logging, review queues, fallbacks, cost controls, and support workflows become part of the product spec.
- 06Ship the smallest coherent version. Iterate quickly, but inside the decisions already made visible.
Where the interaction happens
The word interactive matters. Each phase produces something testable: a product brief, a schema sketch, a prompt harness, a clickable flow, an eval set, a preview deploy. Stakeholders react to artifacts, not abstractions. The plan changes when evidence changes. What does not happen is a silent handoff from strategy to design to engineering to launch.
This is why the method works well for AI: the high-level decisions are made in order, but the team still learns from working software every week. The structure prevents churn. The interaction prevents fantasy.
What it prevents
- →Prompt-first development where the model is asked to compensate for an unclear product.
- →Demo-driven scope creep where each impressive output adds another half-feature.
- →Late data discoveries that force the team to rebuild retrieval, permissions, or tenancy.
- →Launches with no evals, no fallback behavior, and no way to tell whether quality improved or regressed.
AI development should be iterative. It should not be directionless. Interactive waterfall gives the work a spine: product thesis, data model, AI behavior, evals, operations, launch. Inside that sequence, move fast.