Why Code Repositories Became AI's Most Wanted Asset

Ask the buy side of the training-data market what it wants most and the answer has been stable for years: production code with real history. Not another mirror of public open source, which every lab already holds, but the private record of software being built, maintained, broken, and repaired by teams who had to live with the consequences. This essay is about why that happened, and why it makes the ordinary company codebase one of the most saleable assets a business quietly owns.

The open-source ceiling

Coding models were raised on public repositories, and it worked: the open corpus taught syntax, idiom, and the standard library of human solutions. But the ceiling arrived quickly, for three reasons. The public corpus skews toward what people choose to publish, which means libraries, frameworks, and demos rather than the applications businesses actually run. It is one-shot: every lab trains on the same commits, so it differentiates no one. And its licensing has become contested enough that clean provenance now carries a premium of its own.

Above the ceiling sits a different kind of question. Not whether the model can write a function, but whether it can work on software: navigate a codebase it did not write, honor decisions made years earlier, fix without breaking, review without flattering. The material that teaches those behaviors was never on the open web.

What production history contains

A production repository is not a pile of code. It is a record of engineering process. An issue is filed and argued over. A branch carries attempts. A review pushes back. A commit lands, is reverted, and lands again corrected. A migration reshapes the data model over months. An incident produces a fix, and then the test that makes the fix stick. Public open source shows finished answers; production history shows the working, and the working is what a model must learn before it can be useful inside real software organizations.

This is why buyers describe repository data as process data rather than text. The value sits in the sequence of decisions, not in the final state of the files.

There is a second use that has grown as fast as training: evaluation. To measure whether a system can really do engineering, buyers need codebases where hard tasks have verifiable answers, a failing test to make pass, a reported bug with a known fix, a feature whose acceptance criteria live in the ticket that requested it. Public benchmarks go stale the moment they are published, because models memorize them. Private repositories, never seen in any training run, are how the frontier keeps its exams honest, and that demand alone would sustain the department.

What buyers evaluate

When a repository is reviewed, five properties dominate. Intact history: an imported snapshot with the history squashed away has lost most of its worth, which is why the first advice to any seller is to touch nothing. Contributor plurality: many hands over years means real collaboration, review, and disagreement in the record. Longevity: a codebase maintained across years carries maintenance reality no fresh project can fake. Travelling context: issues, reviews, and internal docs that move with the code multiply what the history can teach. And genuine use: software that ran in production, with the scars to prove it, outvalues polished exercises every time.

Notice what is missing from that list: beauty. Buyers want real engineering, including the mess. The embarrassing commit is not a defect in the asset. It is the asset.

Sellers consistently misjudge which of the five they hold. The ones who apologize for a tangled history are usually sitting on the most valuable property in the estate, and the ones proudest of a freshly cleaned monorepo have often deleted the very record buyers wanted. When in doubt, describe. Do not curate.

Context multiplies value

The published bands make the effect visible. Our code department currently prints these ranges:

The top tier is not simply bigger. It is deeper: thousands of commits, many contributors, years of history. A modest codebase with pristine, complete history and its tickets intact can outperform a much larger one that arrives as a bare snapshot. Line count decides which band you enter; history and context decide where in the band you land.

The strongest consignments are estates rather than repositories: the code together with the issue tracker that shaped it, the review threads that argued over it, and the internal documentation that explained it. Each layer of context cross-references the others, and buyers pay for the cross-referencing, because that is precisely what cannot be reconstructed from any public source.

If you hold one

Every company with a real product holds this asset, and almost none of them think of it as one. The path from here is short. Keep the history intact and the originals untouched. Describe the estate rather than the repository alone: the tickets, the docs, the years. Understand that the deal is a license for training and evaluation, not a transfer: you keep the code, the product, and the business built on both. And let the range be discovered rather than guessed. The instant estimate is free, and refining it is what specialists are for.

Two refinements from the sale floor. First, think in estates: if your company runs several repositories that share tickets, people, and history, describe them together, because the connections between them are themselves an asset. Second, do not let dormancy stop you. A retired product's repository licenses on the same terms as a live one, and often more easily, because nothing about the current business is exposed by licensing the past.