The clarification step is the one I see skipped most often, so it is good to see it named as work rather than overhead. I keep the questions and their answers in the spec itself, and the agent checks back against them as it builds. A surprising amount of review argument disappears when the ambiguity was settled in writing first.
Adam, that's a good point. Keeping the questions and their answers in the specification makes it a living reference instead of something everyone read once and then worked from memory.
I've also found that many code review discussions aren't really about code. They're about intent that was never made explicit.
Most of the review arguments I've sat through were two people discovering they'd assumed different requirements, so settling that in the spec first has cut most of them off. I've written up how I approach it here: https://prickles.org/tenet/spec-first-execution/P2
Read through it. The "most popular implementation, not what the business needs" line is exactly the failure mode I mean. And you've already pre-empted the obvious objection: the risk isn't AC first, it's AC without the conversation.
Thanks for the pointer btw. Bookmarking the rest of your canon.
Adam Lewis
Product Engineer/Architect navigating the AI revolution
The clarification step is the one I see skipped most often, so it is good to see it named as work rather than overhead. I keep the questions and their answers in the spec itself, and the agent checks back against them as it builds. A surprising amount of review argument disappears when the ambiguity was settled in writing first.