Insights · 6 min read

Why Version History Is Worth More to AI Than a Code Snapshot

A snapshot is the answer sheet. The history is the exam, the attempts and the marking.

Bearish AI · October 21, 2026

Imagine handing someone a finished building and asking them to learn how to build. You have given them the result. What they need is the sequence: the plan, the first attempt, the problem found on site, the fix. A code snapshot is the finished building. Version history is the sequence. For AI training, the sequence is where most of the value sits.

What a snapshot can and cannot teach

A snapshot shows code as it stands on one day. A model can learn style and structure from it, much as it does from public repositories. What it cannot learn is how a change happens: what was broken, what was tried, what the reviewer objected to, what the test looked like before the fix. Those are the things an agent has to do when it works on real software.

How researchers turn history into training tasks

The best-known coding benchmark, SWE-bench, was built from history. It contains 2,294 software engineering problems drawn from real GitHub issues and the pull requests that resolved them, across 12 popular Python repositories. A model gets the codebase and an issue description and must produce the fix. None of that is possible from a snapshot, because the task is defined by a before state, a stated problem and an after state.

Another team used commits directly. Their dataset, built from Git commits, pairs each code change with the human-written message that describes it, and the compiled collection runs to 4 terabytes across 350 programming languages. They used it to teach code models to follow instructions, because a commit message is a natural instruction and the diff is the answer.

Commercial history works the same way. The authors of a harder benchmark, built from startup codebases, report that they contacted the companies and purchased their engineering repositories. Human reviewers then checked the tests that fail before a fix and pass after, and engineers built runnable environments for the repositories. All of those steps need the change history, not just the final files.

One commit, turned into a lesson

Here is how a single ordinary change becomes training material. Suppose a commit fixes a rounding bug in an invoice total and adds a test. A task builder takes the version of the code just before the commit as the starting state. The issue or ticket text becomes the instruction. The test added in the commit becomes the grader: it fails on the starting state and passes once the bug is fixed. The commit’s actual change is the reference solution, and the reviewer’s comments say what a good solution looks like. One commit, five usable parts.

A snapshot has none of these parts, because it has no “before”. That is the core of the difference, and it is why benchmark authors build tasks from history and why the grading step is also where most of the human effort goes.

Snapshot versus history

Wrong turns are part of the lesson

A finished codebase hides every mistake that was fixed on the way to it. History keeps them: the approach that was tried and reverted, the test that caught a regression, the review comment that said “this will break when the list is empty.” Models trained on finished code rarely see what a wrong turn looks like. An agent that is meant to work on real software will make wrong turns, and needs to have seen how people recognise and undo them. This is an argument from how the data is structured, not a measured result, but it is why history tends to be the first thing a task builder asks for.

What weakens a history

• Squashed commits. Collapsing a year of work into one commit throws away the steps. Do not squash an archive you may want to sell.
• Empty messages. A history full of “update” and “wip” still has diffs, but loses the natural instruction.
• Broken links. If ticket numbers in commits point to a tool you cancelled, the context is gone unless you exported it.
• Secrets in old commits. Deleting a password from the latest version does not remove it from earlier ones. Scrubbing must cover the whole history.
• Rewritten history. Forced pushes and repository migrations can silently drop commits.

Is history always worth more?

Not automatically. A long history of trivial changes is still thin, so size and age are not the whole story. What helps is history that is dense with real problems and fixes, ideally linked to the tickets and conversations that explain them, as described in /insights/linked-data-code-tickets-chat.

How to preserve it

If you are winding down a product, migrating hosting providers or just tidying up, take a full mirror of every repository, including all branches and tags, before changing anything. Keep a copy of pull request and review text, which often lives outside the repository itself. Store it somewhere that survives the cancellation of your accounts. None of this commits you to selling anything; it keeps the option open.

The estimate at /estimate asks how many years your records cover and how many people produced them, because longer, busier histories give more to work with. It is free and conservative, and it will show how much linking more sources could add.