Part I of a two-part series on version control for the AI SDLC.

Part II will go deeper into the protocol design: repositories, commits, branches, merges, diffs, reviews, evaluation history, and context snapshots.

Git remains one of the most successful engineering tools ever created.

It solved a hard problem exceptionally well: distributed collaboration on source code with integrity, history, branching, merging, and auditability. The Pro Git book describes Git’s model around snapshots of a filesystem, content addressing, and local operations. That model became the foundation for modern code review, CI/CD, release management, security scanning, and compliance workflows.

Nothing about AI-assisted development makes that foundation less valuable.

Source code still needs history.

Changes still need review.

Builds still need reproducibility.

Teams still need traceability.

The question is not whether Git is obsolete.

The more useful question is:

If AI is now part of the software development lifecycle, is source code still the only engineering artifact that deserves first-class versioning?

I do not think this is a prediction question.

It is a design question.

Git Solved Code Collaboration

Git was built around a clear abstraction:

A repository is a history of content snapshots.

That abstraction is powerful because source code has concrete structure. Files can be added, removed, renamed, compared, branched, merged, and restored. Git does not need to understand the business domain to preserve the history of a service.

That separation is one reason Git worked so well.

It did not try to model the whole organization.

It modeled changes to files.

Then the software industry built everything around that model:

  • pull requests,
  • branch protection,
  • status checks,
  • code owners,
  • release tags,
  • deployment automation,
  • security scanning,
  • audit trails.

Git became more than a storage format. It became the substrate underneath software delivery.

GitHub’s pull request workflow, for example, centers collaboration around proposed source-code changes, review comments, status checks, and merge decisions. That workflow remains extremely useful because implementation remains a critical artifact.

But implementation is not the only artifact.

It never was.

Software Has Always Been More Than Code

Experienced engineers know that source code tells only part of a system’s story.

To safely change a service, an engineer usually needs more than the current files:

  • product intent,
  • customer behavior,
  • domain vocabulary,
  • architecture decisions,
  • service ownership,
  • operational constraints,
  • security requirements,
  • data assumptions,
  • previous incidents,
  • rollout expectations,
  • team conventions.

Some of that knowledge lives in the repository.

Some lives in issue trackers.

Some lives in design documents.

Some lives in chat history.

Some lives only in people’s heads.

That has always been true. AI did not create the need for context.

AI simply makes the dependency more visible.

Human engineers can accumulate context slowly through team membership, repeated incidents, code review conversations, and memory. AI systems do not join a team for three years and develop institutional intuition. They receive context through prompts, files, retrieval systems, tool outputs, repository instructions, tests, and other explicit artifacts.

That means weak engineering context becomes visible in a new way.

Vague requirements were always a problem.

Hidden conventions were always a problem.

Outdated architecture documents were always a problem.

AI-assisted development makes those problems easier to reproduce because the system can only use the context it can access.

The Engineering Artifact Is Getting Larger

Traditional development often pretended the lifecycle looked like this:

Idea
Code
Software

Real engineering was always richer:

Business need
Requirements
Architecture
Constraints
Implementation
Tests
Deployment
Operations
Learning

AI-assisted development makes the richer version harder to ignore.

When an engineer asks an agent to implement a feature, the agent needs more than a file path. It needs the intent behind the work, the constraints around the change, the standards that apply, the tests that matter, and the verification criteria that make the output acceptable.

That turns many previously informal assets into operational inputs.

Repository instructions are not just documentation.

Specifications are not just planning artifacts.

Architecture decisions are not just historical notes.

Evaluation results are not just CI output.

They become part of the engineering substrate that produces software.

This is the same direction I explored in Hierarchical Context. AI-native engineering does not only need more context. It needs context with structure, ownership, inheritance, and routing.

Version control is one place where that structure can become explicit.

From Versioning Code to Versioning Engineering

Git versions implementation history.

AI-assisted development raises the value of engineering history.

By engineering history, I mean the connected record of:

  • what was requested,
  • why it mattered,
  • which constraints applied,
  • which architecture decisions were relevant,
  • which context was available,
  • which implementation was produced,
  • which evaluations passed,
  • which human approvals were given,
  • which operational observations followed.

Today, these artifacts often exist, but they are weakly connected.

A pull request may link to a ticket.

A ticket may link to a design document.

A design document may reference an ADR.

An ADR may mention a standard.

A test run may live in CI.

Production observations may live in dashboards or incident tools.

The information is present, but the lineage is fragile.

For a human, that fragility is annoying.

For an AI-assisted workflow, it becomes a quality problem.

If the system cannot tell which requirement produced which implementation, which architecture decision constrained it, and which verification proved it safe enough, the workflow becomes harder to audit and harder to improve.

The next version-control abstraction should not discard Git’s strengths.

It should apply version-control discipline to more of the engineering lifecycle.

Spec-Driven Development Makes This Concrete

The clearest version of this shift is already visible in spec-driven development.

In The Fantastic 4, I described the loop as:

human-written spec → AI generation → human review → deploy → feedback → updated spec

The human bookends are the point. People write the spec and update it from real-world feedback. AI turns the spec into code.

That inverts an old assumption. For decades, source code was the artifact humans authored directly, and everything else described it after the fact. In a spec-driven loop, the spec is the artifact humans author, and the code is generated from it.

If the code is generated, then the code is closer to a build output than to the source of truth.

Git versions that generated code with full rigor: history, review, branching, integrity. The spec that produced it often lives in a document, a ticket, or a prompt, with none of that discipline.

That is the gap. The artifact humans reason about is versioned casually, while its generated output is versioned carefully.

A spec is not a planning note to discard once the code exists. In a spec-driven loop it is the thing that gets re-run when a model improves, when a requirement changes, or when the generated code drifts.

An artifact that can regenerate the system deserves the same engineering-grade treatment as the system.

What Should Stay

Any serious evolution of version control should preserve what Git got right.

Immutable history

Engineering teams need a durable record of what changed.

AI should not weaken auditability. If anything, AI-assisted changes need stronger traceability because more work can be produced faster and with less direct human typing.

Integrity

Git’s content-addressed model is one of its strongest ideas. A history object should be identifiable, verifiable, and resistant to silent mutation.

An AI-native version-control layer should preserve that principle for code, specifications, evaluations, context snapshots, and approvals.

Branching

Branches are useful because they isolate change.

The idea should stay.

The branch contents may become richer.

A branch might contain a specification change, context update, implementation, test plan, and evaluation history as one unit of engineering work.

Merging

Software collaboration requires reconciliation.

Merging remains essential.

The thing being reconciled may expand from file changes to requirement changes, policy changes, architecture changes, and evaluation changes.

Distributed work

Local work matters.

Offline work matters.

Fast local operations matter.

An AI-oriented protocol should not assume that every useful operation requires a central server or vendor-controlled platform.

Review

Review remains central.

The review target expands.

Instead of only asking, “Does this code look correct?” teams also need to ask:

  • Does this implementation satisfy the stated intent?
  • Does it align with the current architecture?
  • Did it use the right context?
  • Did the evaluation actually test the risk?
  • Did the agent make an assumption that should be written down?

Code review becomes engineering review.

What Should Evolve

The parts that need evolution are mostly not Git’s core strengths.

They are the conventions built around Git.

Repository

Today, repository usually means file tree plus history.

For AI-assisted development, repository should also mean operational knowledge boundary.

It should answer:

  • What does this service own?
  • Which standards apply?
  • Which architectural decisions constrain changes?
  • Which agents are allowed to operate here?
  • Which evaluations define acceptable behavior?
  • Which context does this repository inherit from the team or organization?

That does not require abandoning files.

It requires treating knowledge assets as peers of code.

Commit

Today, a commit usually contains author, timestamp, message, tree, and parent references.

For AI-assisted development, an engineering change benefits from richer metadata:

  • intent,
  • requirement reference,
  • context snapshot,
  • implementation diff,
  • generated artifacts,
  • evaluation results,
  • policy checks,
  • human approvals,
  • agent identity,
  • reviewer notes.

The commit becomes a knowledge object, not only a code snapshot.

Diff

Git’s line diff is still useful.

It is not sufficient for all engineering questions.

A version-control layer for AI-assisted work should also support:

  • requirement diffs,
  • architecture diffs,
  • policy diffs,
  • behavior diffs,
  • evaluation diffs,
  • context diffs.

The line diff says what changed in text.

The engineering diff says what changed in meaning.

Merge

Text conflicts are only one class of conflict.

AI-assisted workflows can produce clean text merges that still conflict semantically:

  • two changes interpret the same business rule differently,
  • one implementation violates an architecture decision,
  • a test update weakens the evaluation contract,
  • a generated migration assumes outdated data ownership,
  • two agents update related services using different policy versions.

The merge system should detect more than same-line edits.

Blame

git blame answers an important question:

Who last changed this line?

AI-assisted development needs additional questions:

  • Which requirement introduced this behavior?
  • Which design decision justified it?
  • Which context snapshot was used?
  • Which evaluation accepted it?
  • Which incident later challenged it?

The useful answer is no longer only authorship.

It is lineage.

The Direction Already Has Momentum

This is not only a thought experiment. Several tools already extend version control past the line diff, each from a different angle.

sem puts a semantic layer on top of Git, reporting which functions and classes changed rather than which lines, and exposing that to coding agents. Diversion is a version-control system built for agent-assisted work that captures prompts, reasoning, and intent alongside file changes. Backstage models services, systems, ownership, and docs as connected, first-class entities in a catalog teams extend deliberately.

Each covers one slice. None yet unifies code, intent, context, and verification into a single versioned engineering history. Backstage, notably, models current state rather than history: what a service is and who owns it now, not the reasoning that produced each change.

The useful signal is not that any tool has solved this.

It is that independent teams, starting from different places, are moving in the same direction.

Why This Matters for AI SDLC

In The AI-Executable Ticket, I argued that tickets written for humans often rely on implicit context. When an AI agent reads the ticket, every missing assumption becomes a risk.

In Async by Default, I argued that cross-team communication should become structured, durable, and addressable.

In What Async Can’t Teach You, I argued that organizations still need human mechanisms for judgment transfer.

Versioning engineering connects those ideas.

The ticket expresses intent.

The context hierarchy supplies inherited knowledge.

The async protocol routes decisions and acknowledgments.

The apprenticeship layer improves human judgment.

Version control should preserve the trace between all of them.

Without that trace, AI-assisted development can produce more output while making causality harder to follow.

With that trace, the organization can ask better questions:

  • Which implementations came from which requirements?
  • Which context version was used?
  • Which standards were active?
  • Which evaluations passed?
  • Which assumptions later proved wrong?
  • Which learning should update the operational repository?

Those questions are already relevant today.

AI makes them more operational.

The Core Mental Model

The main shift is simple:

Version control should evolve from versioning code to versioning engineering.

That does not mean every chat message, draft, and discarded thought deserves permanent storage.

It means that the artifacts that materially shape implementation should be traceable, reviewable, and reproducible.

Code remains essential.

But code is downstream of intent, context, constraints, and verification.

If those upstream artifacts influence the software, they deserve engineering-grade treatment.

Closing Thoughts

Git captured what changed.

That remains necessary.

AI-assisted development makes another question harder to avoid:

What knowledge made that change possible?

Answering that question does not require replacing Git.

It requires broadening the design vocabulary around version control.

The first article in this series introduced the mental model: versioning engineering.

The second article turns that mental model into a more concrete design proposal.