Insights · 6 min read
Is Legacy Code Valuable for AI Training? Three Questions
Age alone does not make code valuable. A few specific properties do.
Owners of old systems often assume that decades of code must be worth something. Sometimes it is. Sometimes it is a pile of files no buyer can use. The difference comes down to three questions about the code, and they have little to do with how old it is.
Question one: how well do models already know this language?
Models are strongest in languages that appear heavily in public code. Researchers describe code models as doing well on widely used languages such as Java, Python and JavaScript while struggling with low-resource languages with little training data, such as OCaml and Racket. They built a method to translate code into those languages with generated tests, which tells you something: the shortage is real enough that people invest to fix it.
COBOL shows the same pattern. A 2026 study reports that existing models struggle to generate and translate COBOL correctly. On a COBOL coding benchmark, one general-purpose model scored 16.4 on pass@1, while a model fine-tuned on curated, compiler-validated COBOL data reached 49.33. In other words, careful COBOL data moved the result a long way.
The practical reading: if your legacy code is in a mainstream language that public repositories already cover heavily, it adds less. If it is in an uncommon language, especially an enterprise or industrial one, it may be scarce, which is the situation the research above describes. The test is not how old the code is but how little of its kind exists in public, and whether you can show it works.
Question two: can anyone check the result?
Agent training needs tasks with outcomes that can be confirmed. Practitioners interviewed by Epoch name robustness against reward hacking as the top quality criterion, and note that many tasks lack clean verification beyond unit tests. Legacy code often has no tests, and may not build at all on modern machines. Each task in a benchmark made from purchased startup code needed a built environment with the right packages and dependencies, and human review of its tests. Old systems whose dependencies have disappeared make that step expensive.
Question three: did the history survive?
Many legacy systems have lived through several tools. Version control may have started after the system did, or lost earlier years in a migration. A system with a full change history and linked tickets is a different asset from one with a single imported snapshot. See /insights/why-version-history-worth-more-than-code-snapshot.
Migrations are a special case
Many legacy systems have been, or are being, rewritten in newer languages. Where the old and new versions both exist, with tests that pass on both, you hold something rare: matched pairs showing how real logic in an old language maps onto a modern one. The same COBOL study introduces a translation benchmark between COBOL and Java and reports that general-purpose models score near zero on Java-to-COBOL translation, while its fine-tuned model reached about 35 on the same measure. Pairs like that are hard to find in public. If you ran a migration, keep both sides and the test results.
Documentation counts too
Legacy systems often come with specifications, runbooks, design notes and the tickets of people who maintained them. These explain why the code does what it does, which the code itself rarely says. An old system with its documentation and maintenance history is a stronger asset than the same system with only its source files.
Quick triage
| Legacy code looks like | Likely value | Why |
|---|---|---|
| Mainstream language, no tests, snapshot only | Low | Plentiful public equivalents, nothing to grade, no history |
| Mainstream language, long history, good tickets | Moderate to good | History and links make tasks even if the language is common |
| Uncommon language, buildable, with tests | High | Scarce, checkable, teaches what models lack |
| Uncommon language, no tests, partial history | Moderate | Scarce, but needs work before it can be used |
| Generated or vendored code | Very low | Not made by your people; often public |
A niche has few buyers
Scarcity cuts two ways. A rare language means models are weak at it, but it also means fewer teams care. Our reading, not a published figure, is that the number of buyers who need a given niche language is small, and that the best outcomes come when legacy code is combined with other material, such as documentation and migration pairs, so that a buyer can build something larger from it. Be realistic about timing too: a niche asset may take longer to place than a mainstream one.
Hidden risks in old code
- Credentials. Old systems often contain hard-coded passwords and keys in early commits. These must be found and removed from the whole history.
- Customer data. Test data and fixtures may hold real names and records left behind years ago.
- Third-party code. Libraries and vendor components carry their own licenses. Separate your code from theirs.
- Contractor work. Code written by outside parties may not be yours to license. A lawyer can check.
These risks are the reasons legacy archives need preparation before a buyer will look. Ownership and privacy checks come first; see /insights/data-ownership-rights-before-selling-data-to-ai-companies. This is general information, not legal advice.
What to do
Take an inventory by language, by presence of tests and by how far back the history goes. Note any parts that still build. Archive everything before systems are retired, including ticket and chat exports. Then use the free estimate at /estimate, which asks how many years your records cover, how many people produced them and which sources you hold. It is conservative by design, and will tell you if the archive looks small.
Questions we get
- Is old code worth anything to AI companies?
- Sometimes. Code in less common languages, that still builds, has tests and keeps its history can be scarce and useful. Old code in a mainstream language with no tests or history usually adds little.
- Is COBOL code valuable for AI training?
- Research reports that general models struggle with COBOL, and that models trained on curated, compiler-validated COBOL improve a lot. That suggests well-prepared COBOL data is scarce and useful, but value still depends on tests, rights and history.
- Does my legacy code need to compile to have value?
- Not strictly, but code that builds and has tests can be turned into checkable tasks, which is where most of the value sits. Code that cannot build needs more work first.
- What are the risks of selling legacy code?
- Hard-coded credentials, customer data in test fixtures, third-party licenses and unclear authorship of contractor work. Review all of them with a lawyer before sharing.
What is your data worth?
Sources
- Cassano et al., “Knowledge Transfer from High-Resource to Low-Resource Programming Languages for Code LLMs” (2023)
- Dau et al., “COBOL-Coder: Domain-Adapted Large Language Models for COBOL Code Generation and Translation” (2026)
- Epoch AI, “An FAQ on reinforcement learning environments” (2026)
- Deng et al., “SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks?” (2025)