Codebase

Every program ultimately consists of text. Humans write this text in a programming language, a kind of very strict artificial language that a computer can execute. These text files are called source code. The codebase is the collection of all these files belonging to a particular program or company. Usually there are also auxiliary files: tests, configurations, descriptions. For a small app that’s a few hundred lines, at Google it’s several billion.

Why a codebase becomes a problem over the years

A codebase is not a finished product but a place where work is constantly ongoing. Every new feature, every fixed bug, and every adjustment ends up there. Over time, hundreds of people work on the same files, and many of them eventually leave the company. The code remains, but the knowledge about it is partly lost.

This is where the term technical debt comes in. It refers to parts that were built quickly and sloppily because a deadline was looming. They work, but they make every later change more expensive. Eventually a small adjustment takes weeks, because no one can say for certain what it will break elsewhere.

That’s why the codebase is both a real asset and a real risk for companies. During company acquisitions, buyers examine the code closely. A well-maintained codebase can be developed further. A rotten one has to be expensively replaced.

Folders, versions, and the path to a running program

A codebase lives in a repository, a shared storage location for all files. It is almost always managed with Git, a version control program. Git records every change individually, with date, author, and reason. This means you can always jump back and see who changed which line and when.

The comparison with a Google Doc fits fairly well. There too, there’s a version history, and several people can write at the same time. The difference: with code, everyone first works in their own copy, the branch. Only once the change has been reviewed is it merged into the main version.

The text itself doesn’t run yet. A further step, the build, translates the files into an executable program. Before that, automated tests run to check that everything still works as expected. If a test fails, the change doesn’t make it into the main version. In large projects, this happens hundreds of times a day.

Why AI companies keep talking about codebases of all things

The term currently keeps popping up constantly in announcements from AI assistants. Tools like GitHub Copilot, Cursor, or Claude Code advertise that they understand an entire codebase and not just individual lines. That’s the crucial difference. A suggestion is only useful if it fits with the remaining thousands of files.

This is exactly what the debate about the context window hinges on, meaning the amount of text a model can survey at once. Even large models can’t take in an entire company codebase in one go. That’s why the tools first search out the matching excerpts and present only those.

A common misconception: codebase and software are not the same thing. The software is what runs on the phone. The codebase is the blueprint behind it that users never see. In open-source projects like Linux, this blueprint is publicly viewable; in commercial products, it’s one of a company’s most closely guarded secrets.