Provenance Emerges as Core Concern in AI-Generated Code Systems

The increasing capability of AI systems to regenerate functional code from specifications challenges foundational assumptions in software engineering. Traditional version control systems like Git track changes to text files under the implicit assumption that code edits reflect human design decisions. When AI agents generate implementations from higher-level specifications, this link between code artifacts and original intent breaks.

Regenerable systems—where components can be deleted and faithfully recreated from stored requirements, constraints, and decisions—shift the fundamental unit of change. As Chad Fowler notes, "When code can be thrown away and recreated, the unit of change is no longer lines of code. It's reasons." This transformation makes diffs increasingly inadequate as historical records. While diffs still show what changed in generated artifacts, they fail to capture which requirement drove the change, which constraints shaped the solution, or which trade-offs informed design choices.

In regenerable architectures, specifications evolve from passive documentation to executable inputs that directly drive system implementation. Consider an email validation function specified to accept standard addresses while rejecting whitespace and avoiding RFC complexity. When requirements shift to include internationalized domain names, traditional version control would show only the altered regex pattern. An intent-centric system would instead record:

• Requirement node: "Accept IDN in domain portion"
• Constraint node: "Maintain no-RFC-compliance rule"
• Plan node: "Extend regex pattern"

The resulting code change becomes a downstream consequence of these modified intent nodes. This approach requires structured, content-addressed graphs where nodes represent discrete requirements, constraints, plans, and decisions, connected by explicit causal relationships. Each node contains canonical content and dependencies, with the entire graph deriving a content-based hash that serves as the system's true version identifier.

Existing systems hint at components of this model. Build tools like Bazel use hashed inputs for reproducible builds, while formal methods communities have long pursued precise specifications. The innovation lies in coupling these concepts into generative provenance systems where specification graphs actively drive implementation. Unlike previous traceability efforts that relied on manual documentation (and frequently failed due to maintenance overhead), regenerable systems embed provenance directly in the generation mechanism—the links exist because regeneration requires them.

Significant challenges remain:

1. Canonicalization: Natural language specifications may produce semantically equivalent but textually different nodes
2. Implicit assumptions: Agents may rely on unrecorded contextual knowledge
3. Non-determinism: Identical intent graphs might generate varying code outputs

These aren't fatal flaws but design constraints requiring explicit management. Ambiguity surfaces at the intent layer rather than being buried in code diffs. As Fowler observes, "The cost of re-deriving code keeps falling, while the cost of rediscovering intent does not." Version control systems must evolve to track what actually matters: the requirements, constraints, and decisions that give systems their current form. Tools supporting this paradigm remain nascent, but the architectural pressure is unmistakable—when code becomes regenerable artifact rather than authored artifact, preserving intent becomes the essential version control problem.