Code repositories as training data: what buyers look for

If your company wrote software, its repositories are probably the most obviously technical asset in its archive. Founders often assume buyers want clean, well-architected code. In practice, AI labs care less about how good the code is and more about how it got that way: the history, the reviews, the reverted changes and the tickets that explain why each change was made.

A repository at a single point in time is a pile of files. A repository with its full history is a long record of decisions. Each commit shows a change, who made it, when and, ideally, why. Each pull request shows a proposal, the discussion around it and what changed before it was merged.

That is the material agents learn from. A coding agent that has only seen finished code knows what software looks like. One trained on histories learns how software changes: how a bug is narrowed down, how a fix is reviewed, how a refactor is broken into steps and how a mistake is undone.

So the first thing buyers ask is how far back the history goes and whether it is intact. A repository that was squashed into a single initial commit during a migration has lost most of what made it useful.

Beyond history, a few features make a codebase stand out.

• Pull requests with real review. Comments, requested changes, follow-up commits and approvals show how a team reasons about code. A repository where everything was pushed straight to the main branch carries less of that.
• Links to tickets. Commit messages and branch names that reference ticket IDs let a buyer connect a code change to the issue that prompted it. That link is what turns a commit into a task with a goal.
• Tests and CI results. Test suites and build histories give graders something objective to check. An agent's change can be run against the same tests the team used.
• Bugs and fixes. Real defects, found and fixed, are some of the most useful sequences in any repository. They show diagnosis, not just construction.
• Variety. Application code, infrastructure, data pipelines, scripts and configuration each reflect different kinds of work.
• Ordinary code. Internal tools, admin panels and glue code are what most professional engineers actually write. Buyers want that as much as anything clever.

Programming language matters less than sellers expect. Popular languages are already well represented in public code. What is scarce is the surrounding context, which brings us to the rest of the archive.

A repository on its own is one system. The same repository connected to the ticket tracker, the team chat and the support inbox is a set of complete trajectories: a customer reports a problem, a ticket is filed, engineers discuss it, a pull request fixes it and the customer is told. Buyers value that connection depth above raw size, which is why a mid-sized codebase with linked tickets and chat can be worth more than a much larger repository with nothing around it. From ticket to pull request walks through one such trajectory in detail.

Anonymization preserves those links. Every person, company, email address and account becomes a consistent token across every tool, so the developer who authored a commit is the same token who commented in chat and closed the ticket.

Code repositories carry specific risks, and the anonymization process treats them seriously.

Secrets come first. Credentials, API keys, tokens and connection strings are removed outright, including from old commits where someone pasted a key and deleted it a day later. History is exactly where those leftovers hide. Secrets in the archive explains why they are removed rather than tokenized.

Names and identities come next. Commit authors, reviewers, email addresses in commit metadata and personal details in comments are replaced with consistent tokens.

Then there is scope. You decide what is in and what is out, and your exclusions are annexed to the contract before any data moves. Common exclusions for code include:

• repositories built for a specific client under terms that give the client ownership;
• forks of third-party code that your company did not write;
• repositories containing regulated data, such as production database dumps checked in by mistake;
• anything you simply prefer to leave out.

Client work deserves particular care. If your company built software for clients, check what your contracts say about ownership and confidentiality before including that code. Exclusions and customer confidentiality clauses cover the usual questions. This is general information, not legal advice, so involve your own counsel on contract questions.

The evaluation is read-only and takes under an hour of your time. It counts what you have: repositories, history depth, pull requests, linked tickets and the other systems that connect to them. Anonymization happens in house, with no third party touching the raw data, and you review an anonymized sample before anything is delivered. The raw archive is deleted within 30 days of sign-off, with a deletion certificate.

The licence permits training and evaluation only. Buyers may not market to, contact, profile or re-identify anyone in the data, and may not resell it for marketing or people search. Payment goes to the company entity, and licences typically range from $20K to more than $400K, depending on connection depth, years of history, headcount and number of systems. Nobody can give a firm number before counting.

If your company's code history is sitting in an archive, book a 15-minute intro call to find out what it is worth.