How Much Is a Codebase Worth for AI Training?

Why AI developers want private code

Coding models have learned a great deal from public open-source repositories. But public code has a particular character: it is often libraries and tools, written for a wide audience, with discussion happening in the open. Most commercial software looks different. It is built for a specific business, under deadlines, with internal conventions, legacy constraints and trade-offs that never get written up publicly.

Models that are meant to work as coding agents inside real companies need to learn from that kind of work. Private repositories show how teams handle large codebases, how they respond to changing requirements, and how they fix production problems. That perspective is scarce, and scarcity is a large part of value.

More than source code

A codebase is most useful when it comes with the record of how it was built. Each of the following adds context that a model can learn from, and together they show the full path from a requirement to working, tested software.

• Historical PRDs and planning documents that explain what was meant to be built and why
• Commit history showing how the code changed over time, in small reviewable steps
• Issues and bug reports that describe problems in plain language
• Code reviews and pull request discussions showing how engineers critique and improve each other's work
• Test suites that define what correct behaviour looks like
• Release records and changelogs linking changes to shipped outcomes
• Architecture and design documents explaining structure and constraints

Factors that raise a codebase's value

Linked history is the first thing to look for. When an issue can be traced to the commits that addressed it, the review that approved them and the tests that confirm the fix, the codebase contains many complete, verifiable tasks. That is exactly the shape of data used to train and evaluate coding agents.

Other factors also matter. Long-lived projects with years of maintenance show how software evolves. Uncommon languages, frameworks or domains, such as older enterprise stacks, embedded systems or niche industry software, are less represented in public data. Good test coverage makes outcomes checkable. And clear documentation helps a model connect intent to implementation.

Factors that reduce it

Some codebases are worth less than their size suggests. Repositories made largely of generated code, vendored third-party libraries or copied boilerplate add little. History that was squashed into a few large commits loses the step-by-step detail. Projects with no issues, reviews or tests show the result but not the process.

Ownership questions can also limit value or remove code from scope entirely. If your company built software for clients under contracts that assign intellectual property to them, that code is not yours to sell. Open-source components inside your repositories remain under their own licences. These are not reasons to give up, but they need to be identified during scoping.

What a complete task looks like in a repository

It helps to picture the unit of value. Imagine a bug report filed by a support engineer describing a failure in the invoicing module. A developer picks it up, comments on the likely cause, opens a branch, writes a failing test that reproduces the problem, makes a fix across three files, and opens a pull request. A colleague reviews it, asks for a change to error handling, and approves the revised version. The tests pass in CI and the fix ships in the next release.

Every step of that story is recorded somewhere in a well-run engineering organisation. Together, they form one complete, verifiable task: a clear objective, real tool use, visible reasoning and an outcome that can be checked automatically. A codebase with thousands of tasks like this, spread across years and different kinds of problems, is much more useful than a snapshot of the final code, even if the snapshot is larger.

A quick self-assessment

You can get a sense of where your codebase stands by answering a few questions before any conversation. The answers also make the initial value assessment faster and more accurate.

• How many years of commit history does each repository have, and is it intact?
• Are issues, pull requests and reviews still available, or were they lost in a migration?
• Do PRDs, specs or design docs exist for major features, and where are they stored?
• What proportion of the code has automated tests?
• Which languages, frameworks and domains does the code cover?
• Is any of it owned by clients or subject to restrictive agreements?
• Are there secrets, credentials or customer data committed anywhere in the history?

How valuation actually happens

Value is assessed case by case. At Momentra, you start by sharing contact, company, industry and interests, with no code required. The initial value assessment covers data type, completeness, scarcity and the tasks the codebase could support. Before any sample is reviewed, an NDA sets confidentiality, permitted use, retention and security. A proposal and contract follow, and the code is then de-identified, with secrets, names and customer identifiers detected and removed or replaced, before secure transfer.

The deal structure also affects value. Licensing, outright purchase and custom project partnerships each trade off control, exclusivity and effort differently, and the right one depends on what you want from the arrangement.