alt Hacker NewsI don't see how this is an AI-specific issue or an issue at all. We solved it already. It's called software development best practices.
> A diff can show what changed in the artifact, but it cannot explain which requirement demanded the change, which constraint shaped it, or which tradeoff caused one structure to be chosen over another.
That's not true... diffs would be traceable to commits and PRs, which in turn are traceable to the tickets. And then there would be tests. With all that, it would be trivial to understand the whys.
You need both the business requirements and the code. One can't replace the other. If you attempt to describe technical requirements precisely, you'll inevitably end up writing the code, at very least, a pseudocode.
As for regenerating the deleted code out of business requirements alone, that won't work cleanly most of the time. Because there are technical constraints and technical debt.
Replies
I'm not sold on the idea that commits and PRs are always easily tied back to tickets. Ideally, sure. In practice? Not always.
Agree...
Look at “Managing the Development of Large Software Systems” (Royce 1970) Figure 10 on scanned page 338:
https://www.praxisframework.org/files/royce1970.pdf
Whatever you do, do not stop on Figure 2's infamous waterfall!
Understand Royce understood Figure 4, and in Figure 7 proposed prototyping with code to inform the product (and iterate the product).
This was elaborated in the Spiral Model (Boehm 1988):
https://en.wikipedia.org/wiki/Spiral_model#/media/File:Spira...
And then '90s DSDM (under various stripped-down flavors clustered around agile claiming to be True Agile™) turned into basically WGLL spanning 2 decades going into LLMs:
https://en.wikipedia.org/wiki/Dynamic_systems_development_me...
Note that DSDM purports to "fix" cost but not through estimation per se, but rather by flexing the backlog cutoff:
“DSDM fixes cost, quality and time at the outset and uses the MoSCoW prioritisation of scope into musts, shoulds, coulds and will not haves to adjust the project deliverable to meet the stated time constraint.”
Cost is just headcount, quality should be in your + user's success criteria, and time is (generally) driven by some real-world requirement (event, opportunity, runway, competition, whatever). Varying scope means you didn't plan and roadmap every task up front.
Most everything since are variations on this, tailoring to the needs of the variant's author.
Doing all of this in text-as-code (Markdown, Mermaid, etc.) makes it machinable. Any number of shops were already doing this in text-as-code before the LLMs, giving them a spec-driven LLM context leg up.