Insights · 7 min read

How to Value a Codebase for AI Training: A Practical Checklist

Lines of code are the wrong unit. The right unit is how many trustworthy tasks the code can produce.

Bearish AI · October 21, 2026

A codebase feels like the most obvious asset a software company has. But when AI teams look at one, they do not count lines. They ask what they can build from it. A buyer interviewed by MIT Technology Review described valuing data through “research theses” about how many useful tasks a corpus yields, for example per 100,000 lines of code. That is the logic to adopt when you price your own.

Start with the reported prices

A founder in the MIT Technology Review report sold a codebase for roughly $25,000, with workspace data pending at about $15,000. Reports on shut-down startups describe $10,000 to $100,000 per company, covering code and workplace data together. Graded software engineering tasks are mostly priced at $200 to $2,000 each in Epoch AI’s interviews, with about $20,000 reserved for rare, very complex ones. Those are the realistic anchors for a private codebase from a small or mid-size team.

Why private code is interesting at all

Public code is already inside the models. Researchers found models could identify the file to fix from an issue description alone up to 76 percent of the time on a popular public benchmark, against up to 53 percent on repositories outside it, and suggest the gap reflects memorization. Private code cannot have been memorized.

The SWE-Bench Pro paper shows the effect. On its commercial set, built from 18 proprietary repositories, the best model scored 17.8 percent pass rate in the paper’s table. The best public-set results listed were 43.6 percent. A buyer who wants a test that models cannot already know has a reason to want your code.

A checklist to score your own codebase

What turns a repo into tasks

The SWE-Bench Pro paper describes the work: human-written problem statements and requirements, environments built by professional engineers, and each fail-to-pass test reviewed for relevance and breadth. A fail-to-pass test is one that fails before a change and passes after it, which gives a task an objective answer. A repository with working tests and a clean build can feed that process. One that does not build is expensive to use.

Epoch’s interviewees also wanted tasks neither impossible nor trivial: a minimum pass rate around 2 to 3 percent, and tasks near 70 percent may be retired. A large codebase of simple, repetitive changes yields fewer valuable tasks than a smaller one with hard, varied problems.

Write a one-page codebase profile

Before you talk to anyone, put the facts on one page. A buyer will ask for them, and writing them down shows you where the gaps are.

• Languages and frameworks. What the code is written in, and anything unusual.
• Age and activity. First commit, last commit, and how steady the activity was.
• Contributors. How many people, and how many were employees rather than contractors.
• Tests and builds. Whether tests run, how long a clean build takes and whether anyone can reproduce it.
• Linked context. Whether pull requests, reviews and tickets are kept and tied to commits.
• Exposure. Whether any of it was ever public, and whether secrets or customer data ever entered the history.

Common mistakes

Squashing history before export, which throws away the sequence of changes that makes tasks. Exporting only the main branch and losing the reviews. Leaving credentials in old commits. Including test fixtures that hold real customer records. Assuming that because the code compiles, it is ready to hand over. Each of these either lowers the value or creates a risk the buyer will price in.

Rights and secrets come first

• Ownership. Check employment and contractor agreements. Code written by contractors may not be yours to license.
• Third-party code. Open-source components keep their own licenses, and copyleft terms can complicate what you are able to license.
• Secrets. Keys, tokens and passwords committed in history must be found and removed, including in old commits.
• Customer data. Test fixtures and logs often hold real data. Remove it before any export.
• Customer contracts. Some forbid reuse of anything derived from their data.

None of this is legal advice. A lawyer should confirm what you can license before anyone sees a line of code.

A rough way to think about the number

Multiply the number of engineers by the years of continuous history, then adjust for how much of it links to discussion and tickets, how much has working tests, and how clean the rights are. That is the same shape as the factors buyers describe, and the free estimate at /estimate asks for the same inputs. Do not expect a precise figure from any method: buyers quote widely different prices for the same body of data.

Small teams with short histories should expect modest numbers. If your codebase is two years old, built by three people, with few tests, it may be worth little alone, and more as part of a larger package. For what is reported across the wider market, see /insights/how-much-do-ai-companies-pay-for-training-data.