AI models that work with software learn from code. To get better at reading a codebase, writing new features and fixing bugs, they need to study how real teams did those things. The most instructive material is not tidy sample code. It is real production code, written under deadlines for real users, together with its history, its tests and the tickets that explain why it changed.
That is the reason Odys AI Labs, the research and development arm of Odys, buys the source code of software people no longer use. It uses that code for AI training and R&D. This article explains why real-world code matters, what it teaches that tutorials cannot, and why private codebases from products that stopped have become valuable.
What do models learn from source code?
A model trained on code learns patterns at many levels. At the smallest, it learns syntax and common idioms in each language. Further up, it learns how functions, modules and services are organized, how data flows through an application and how errors are handled. At the highest level, it learns how software changes: what a bug looks like, what the fix looks like, and how a team decides between two designs.
Code also helps beyond programming. A study titled To Code, or Not To Code? found that code in training data improves a model’s reasoning, not just its coding. The authors reported relative gains in natural language reasoning and world knowledge as well as code performance. Code is structured, precise and logical, and those qualities carry over.
Why is public code no longer enough?
Most training so far has drawn on public material. For text, researchers at Epoch AI estimate the effective stock of public human-written text at about 300 trillion tokens and project that models will fully use it between 2026 and 2032. Public text is a finite resource.
For code, there is no comparable estimate of how much is left, but the public pool is well mapped. The largest open code dataset, The Stack v2, contains over 3 billion files in more than 600 programming and markup languages, drawn from 104.2 million GitHub repositories and derived from the Software Heritage archive. Software Heritage itself aims to collect and preserve all publicly available source code. That is a huge body of work, and it has been studied heavily.
Public code datasets also come with license terms and opt-outs, which is right and fair. What they do not contain is private code: the software companies and founders built and never published. That gap is where the most useful new material sits.
What does production code teach that tutorials cannot?
Tutorials, course exercises and showcase projects are written to be clear. Production code is written to work, under pressure, for real users. The difference shows up everywhere:
| Tutorial or sample code | Real production code |
|---|---|
| A single happy path | Edge cases, error handling, retries and timeouts |
| Toy data models | Data models that grew and changed over years |
| One clean commit | Hundreds or thousands of commits, including mistakes and reverts |
| No real integrations | Payments, email, auth, third-party APIs and their quirks |
| No tests, or trivial ones | A test suite that captures what the business needed |
| No context | Tickets, reviews and docs that explain why |
A model that only sees tidy examples learns what code looks like when nothing goes wrong. A model that sees production code learns how software behaves when real requirements, real users and real deadlines push on it. That second kind of learning is what helps a model fix code it has never seen before.
Why does history matter as much as the code?
The final state of a codebase shows what the software became. The git history shows how it got there. Each commit pairs a change with a message, and a good message says why. Pull requests and code reviews add discussion: what a reviewer questioned, what was changed in response and what was rejected.
For learning how to fix software, this sequence is the most valuable part. A bug report in a ticket, a failing test, a commit that fixes it and a review that approves the fix together form a complete lesson. Our guide on why git history makes old code worth more explains how to check you still have it, and the guide to docs, tests, tickets and designs covers the material around the code.
Why does code from products that stopped matter?
Products stop for business reasons: funding runs out, a market shifts, a company changes direction. The code does not stop being instructive. A SaaS that shut down after four years has four years of real engineering in it. A mobile app removed from the store still shows how a team handled offline sync, push notifications and app review rules. A shelved game still has its engine code, tools and build scripts.
This is also why the owners of such code are often surprised. A product that never made money can still be a complete, original and well-documented codebase. Revenue is not one of the factors that make code useful for research. Our pillar guide on what old source code is still worth explains what does.
The same things that make code instructive make it valuable: how much original code there is, how complete the product is, how much history comes with it, whether tests and docs exist, and whether the rights are clear. Our pillar on how codebase value is measured walks through each one and how to check it without sharing code.
What happens to code bought for AI training and R&D?
At Odys AI Labs, the process is set out in writing before anything moves:
- A signed agreement comes first. No code changes hands before a written agreement is signed, and we never ask anyone to install or run anything on their computer.
- Cleaning before transfer. Secrets, keys and personal data are removed before transfer, and we help the seller do it.
- No user data. We never take databases, user records, customer data or chat logs.
- What the code is used for. Odys AI Labs uses the code for AI training and R&D after cleaning. We may also work on it with research partners.
- No brand, no relaunch. We never use the seller’s brand or name and never relaunch the product as theirs.
- Confidential. We do not publish who we buy from.
A safety point that applies to any buyer: never run a stranger’s script on a machine that holds your code or credentials, and remember that a fair buyer does not need your code before a contract. More about the lab itself is on the Odys AI Labs page.
What to do next
- Check that your repositories still exist with full history, and note what docs, tests and tickets survive.
- Rotate any key that was ever committed, even in an archived repository.
- Send us a few details for a free code valuation: no code, no obligation, a cash offer after review if it fits.
Frequently asked questions
What does it mean to use code for AI training?
It means using source code as material a model learns from, so it gets better at reading, writing and fixing software. The model studies patterns: how functions are structured, how bugs are introduced and fixed, how tests describe intended behavior. At Odys AI Labs, code is cleaned first, with secrets, keys and personal data removed, and is used for AI training and R&D, not to run or relaunch the original product.
Why not just use public code from GitHub?
Public code is useful and has been used heavily. The largest open code dataset is built entirely from public repositories, and public datasets come with license terms and opt-outs. Private production code was never published, so it is not in those datasets at all. It also tends to show different things: business logic, real integrations and the messy fixes that public showcase projects rarely include.
Will my product or brand appear in an AI model?
We never use the seller's brand or name and never relaunch the product as theirs. Code is cleaned before use, and secrets, keys and personal data are removed before transfer. The aim is for models to learn general skills, such as how to fix a bug or structure an API, from many codebases, not to reproduce or promote any one product. We also do not publish who we buy from.
Is code from a failed product less useful for research?
Usually not. Whether a product succeeded commercially says little about how much its code can teach. A failed product may still have years of careful engineering, real bug fixes and good tests. For research use, what matters is that the code is original, complete and comes with history and documentation, which a failed product can have as much as a successful one.
Find out what your old code is worth right now.
Tell us about the product in about a minute. No code needed. We review the details and come back with a cash offer or a plain no.
Get my free code valuation →