Code as an artifact means treating the source you commit as a regenerable output of a process — the prompts, plans, and agent context that produced it — rather than the durable end product of software development. When AI agents generate most of your code, the spec and the conversation become the real artifact, and versioning must capture both the code and the process behind it. This guide explains why traditional Git falls short, how to attribute every line to AI or human, and which workflows and tools keep AI-generated code trustworthy at scale.
What Does “Code as an Artifact” Actually Mean?
For most of software history, code was the end product. You wrote it, reviewed it, shipped it, and it lived on as the canonical record of what your system does. Agentic LLMs have inverted that relationship. As one widely shared argument puts it, “Agentic LLMs have changed what ‘code’ means — it used to be the end product of the software lifecycle, but now LLMs write code and the spec becomes the durable artifact.”
The shift is stark. In August 2026, Elon Musk argued that “source code is on the verge of becoming like assembly. The next step is getting rid of source code entirely and just making an efficient binary directly with AI.” Whether or not you agree that source code will disappear, the direction is clear: the human-authored, durable layer is moving up the stack. Your instructions, your prompt, and your context become the “code” — one higher level of abstraction, but still code.
This reframing matters for versioning. If code is a regenerable output, then committing only the output is like saving a compiled binary without the source. You lose the ability to understand why a change happened, to reproduce it, and to audit it. The artifact you should be versioning is the full chain: the intent, the plan, the prompt, the agent’s reasoning, and the resulting diff.
Why Programming Languages Won’t Disappear
A common objection is that if AI writes everything, we can skip languages entirely. But programming languages exist to reduce ambiguity in natural-language specification — they make execution unambiguous. LLMs can trivially generate binaries, but what you assert the binary will do still depends on “code” at a higher level. Languages are the precision layer that lets a machine (or an agent) execute intent without guessing. So the artifact hierarchy becomes: intent → spec → prompt → code → binary, and each layer is a candidate for versioning.
Why Traditional Git Falls Short for AI-Generated Code
Git was designed to version the artifact — the code — not the process that produced it. That worked when a human authored each commit and the commit message captured intent. With AI agents, the gap becomes critical.
| Capability | Traditional Git | What AI Code Needs |
|---|---|---|
| Captures the code diff | Yes | Yes |
| Captures the prompt that produced it | No | Yes |
| Captures the plan and agent reasoning | No | Yes |
| Attributes lines to AI vs. human | No | Yes |
| Survives squash, rebase, cherry-pick | Partially | Must preserve causality |
| Explains “why” behind a change | Via commit message | Via full exchange record |
The core problem: Git captures the artifact but not the process. A PR summary cannot capture the tradeoffs, alternatives, and dead ends an agent explored. When natural language (prompting and planning) becomes the new “programming language,” only putting the generated code up for review is incomplete — you are reviewing the output of a process you cannot see.
The Squash Problem
Git’s history-flattening operations — squash, rebase, cherry-pick — destroy the micro-steps that explain how code evolved. For human code this was acceptable because the final commit message summarized intent. For AI code, the intermediate steps often contain the reasoning that makes the final diff comprehensible. A provenance system must survive these operations, which is why the design goal is to preserve causality before commit flattening happens.
The Provenance Problem: Who Changed This Line, AI or Human?
The most concrete new requirement is line-level attribution. Teams need to answer a simple question: “Who changed this line, AI or human, and why?” This is not just an audit nicety — it drives review priority, liability decisions, security triage, and debugging.
The Dual-Layer Provenance Model
Git-native provenance systems like SpecStory recommend a dual-layer data model:
- Attribution map — stored in Git Notes for a fast blame path. This answers “who touched this line” in milliseconds without slowing down normal Git operations.
- Exchange records — the explainability path. These capture the full agent exchange: the prompt, the tool calls, the reasoning, and the resulting change.
These two layers are backed by always-on micro-versioning (a journal plus checkpoints) and a deterministic correlation engine that matches agent activity to the final committed lines.
How Attribution Is Computed
A scored deterministic matcher correlates agent exchanges with committed lines using several signals:
- Path match — which file the agent touched
- Content hash continuity — whether the line content traces back to an agent’s output
- Time-window proximity — how close the agent action was to the commit
- Session affinity — whether the same agent session produced the change
- Change-type compatibility — whether the edit type matches the agent’s operation
The hybrid capture stack uses explicit agent hooks plus provider watchers and parsers, all normalized into a single exchange-event schema. This is the practical answer to “git blame for AI code.”
Standards You Should Know
Provenance is converging on existing standards rather than inventing new ones:
- C2PA (Coalition for Content Provenance and Authenticity) — content provenance for media, extending to code
- SLSA (Supply-chain Levels for Software Artifacts) — integrity of build and release chains
- in-toto — attestation of the software supply chain steps
- OpenTelemetry GenAI semantic conventions — tracing agent and model calls
These give you a vocabulary and tooling base for recording who or what produced each artifact.
The Review Bottleneck: Trusting Code You Didn’t Write
The bottleneck in software engineering has shifted from writing code to trusting it. AI generation speed has surpassed human review capacity — you can produce more code in an hour than a team can meaningfully review in a day.
This is not a new problem made worse; it is an old problem finally exposed. Humans never truly scaled code review. Reviewers overloaded with backlogs approve PRs with critical bugs, often focusing on style rather than substance. Code review — human or LLM — was not designed for autonomous coding. It does not verify that the code accomplishes what was prompted or aligns with the spec.
Even five-axis best practices (correctness, architecture, security, readability, performance) fall short of verifying the original acceptance criteria. The question is not “is this code good?” but “does this code do what we asked, and can we prove it?”
The Missing Context Problem
LLM-written code is an artifact of the process that created it. Reviewing only the generated artifact misses the context of how it was produced. The missing piece is the plans, prompting, and full dialog behind a change. PR summaries do not capture the tradeoffs and alternatives the agent considered. This is why provenance and review must be coupled: you cannot meaningfully review AI code without the process record.
Practical Workflows for Versioning AI-Generated Code
Theory is useful, but teams need concrete patterns. Here are the workflows that are actually working in production.
The Backwards Build
One proven approach inverts the traditional order. Start with business slides → PRD → documentation → tests → then code. Generate code only after the product makes human sense. This ensures the durable artifacts (spec, docs, tests) exist before the regenerable output (code) is produced — which is exactly the “code as an artifact” philosophy applied to workflow.
The Four-Phase Pipeline with Plan Scoring
A 6-month-old startup running a 300k-line Next.js monorepo with 3-6 AI coding agents in parallel across git worktrees — and zero traditional SWE backgrounds among founders — enforces a four-phase pipeline:
- Discussion — align on intent
- Plan — produce a concrete plan
- Implement — generate code
- Review — verify before merge
They use custom Claude Code slash commands and score every plan 1-10 for one-pass implementation confidence. Plans scoring below a threshold go back for revision before any code is written. This is a lightweight, enforceable version of “spec first, code second.”
Verification Gates
Require AI to produce tests, docs, and diagrams with mandatory human review before proceeding. Do not let an agent’s code merge without its supporting artifacts. This turns the review bottleneck into a structured gate rather than an open-ended slog.
Size Limits and Conventions
Standardize aggressively: minimal invention, strong typing, follow existing conventions, strict linting with no exceptions. Enforce size limits — for example, 50 lines per function and 200 lines per file. Keep the whole chain in sync daily and run human-AI joint code reviews. Small, conventional, well-attributed changes are far easier to trust than large generated diffs.
Human-AI Joint Review
Do not replace human review with AI review. Run both. The human verifies intent and acceptance criteria; the AI verifies consistency, style, and mechanical correctness. The human is the only party that can confirm the code matches the original prompt’s intent.
Tooling and Standards for AI Code Provenance
The tooling landscape is maturing quickly. Here is what to look for when building your stack.
| Tool / Standard | What It Solves | When to Use |
|---|---|---|
| Git Notes-based attribution map | Fast line-level blame | Always, as the base layer |
| Exchange records (SpecStory-style) | Explainability of agent actions | When you need “why” behind a change |
| Micro-versioning (journal + checkpoints) | Survive squash/rebase/cherry-pick | For high-churn agent workflows |
| C2PA | Content provenance | For media and generated assets |
| SLSA + in-toto | Supply-chain integrity | For release and build chains |
| OpenTelemetry GenAI semconv | Trace agent/model calls | For observability and debugging |
The key insight: do not bolt provenance on after the fact. It must be captured at the moment the agent acts, before commit flattening destroys the causal chain. Always-on micro-versioning is the mechanism that makes this possible.
Building a Versioning Strategy That Scales with AI Agents
A versioning strategy for AI-generated code is not a single tool — it is a layered system. Here is a practical blueprint.
Layer 1: Capture the Process
Instrument your agents to record every exchange: the prompt, the plan, the tool calls, the reasoning, and the resulting diff. Normalize these into a single event schema. This is the raw material for everything else.
Layer 2: Attribute the Output
Correlate agent exchanges with committed lines using the scored matcher (path, content hash, time window, session affinity, change type). Store the attribution map in Git Notes for fast blame, and keep exchange records for deep explainability.
Layer 3: Gate the Review
Make review a structured gate, not a backlog. Require tests, docs, and diagrams. Score plans before implementation. Enforce size limits and conventions. Run human-AI joint review with the human owning intent verification.
Layer 4: Preserve Causality
Use micro-versioning so that squash, rebase, and cherry-pick do not destroy the causal chain. The goal is to survive history-flattening operations while keeping the process record intact.
Layer 5: Standardize the Vocabulary
Adopt C2PA, SLSA, in-toto, and OpenTelemetry GenAI conventions so your provenance is interoperable and auditable by external tools and future systems.
Conclusion: Code as a Means, Not an End
The paradigm shift is real: code is no longer the end product — the spec, prompt, and context are the durable artifact, and code is a regenerable output. This changes everything about how you version, review, and trust software.
The practical takeaway is that versioning AI-generated code requires capturing the process, not just the output. Attribute every line to AI or human, preserve causality across history-flattening operations, and gate review with structured verification. The teams that treat code as an artifact — a means to an end, backed by full provenance — will be the ones that can trust the code they did not write.
FAQ
What does “code as an artifact” mean?
It means treating source code as a regenerable output of a process — the prompts, plans, and agent context that produced it — rather than the durable end product. The spec and the conversation become the real artifact that needs versioning.
How do you version AI-generated code?
Version both the code and the process: capture agent exchanges (prompts, plans, reasoning), attribute lines to AI or human via a Git Notes-based attribution map, preserve causality with micro-versioning, and gate review with structured verification.
Why is traditional Git insufficient for AI code?
Git captures the artifact but not the process. It cannot record the prompt, plan, or agent reasoning behind a change, and history-flattening operations like squash and rebase destroy the causal chain that explains how AI code evolved.
How do you attribute code to AI vs. human?
Use a scored deterministic matcher over path match, content hash continuity, time-window proximity, session affinity, and change-type compatibility, backed by always-on micro-versioning. Store the attribution map in Git Notes for fast blame.
What are the best practices for reviewing AI-generated code?
Use a backwards build (spec, docs, tests before code), enforce a four-phase pipeline with plan scoring, require verification gates (tests, docs, diagrams), enforce size limits and conventions, and run human-AI joint review where the human verifies intent and acceptance criteria.