One vague prompt, seven upgrades, all eight prompts in full. Four add information; three change the process — and only one of those failures is easy to spot.

Every phase of the software lifecycle now has an AI assistant pointed at it. Business analysts draft user stories with one. Architects sketch options with another. Developers generate code, testers generate cases, reviewers get automated comments.

And yet, at the level of the whole delivery pipeline, throughput has barely moved.

AI writes requirements fast. Give it a paragraph of business context and it returns twenty user stories with acceptance criteria in under a minute.

So why do projects still rework their requirements, over and over?

Session 2 answers that, and the answer reframes how you use the tool: the highest-value thing AI does in requirement engineering is not answering — it is asking.

One task at a time, tests that check behaviour rather than implementation, and a review where AI reports but never fixes.

A team ships fast for three months. In month four the requirement changes — loan applications now need video verification of the borrower. Two weeks of work. Not because the change is hard, but because the main workload is understanding the code the AI wrote.

That is the failure Session 4 is about. The team moved quickly and left no trail to come back along.

A quality gate is sufficient evidence, not a green test run — plus five review rules for code no human wrote.