Codebase

Every program ultimately consists of text. Humans write this text in a programming language, that is, in a fixed notation that a computer can understand unambiguously. All these text files that belong to a product together are called the codebase. For a small mobile app, this might be just a few thousand lines. For an operating system or an online banking system, it can be many millions of lines, spread across tens of thousands of files. The codebase is therefore not the finished program, but the blueprint from which the program is newly generated each time.

Why companies treat their codebase like an asset

For many technology companies, the codebase is the single most valuable possession they have. There are often no factories, warehouses, or machines at all. What makes up the company is contained in these text files. That’s why, when a company is acquired, buyers carefully examine the condition of the code.

The condition determines speed. A tidy codebase makes it possible to build a new feature in days. A neglected one takes months for the same feature, because nobody can say for certain anymore what a change elsewhere might break. In the industry, this accumulated backlog is called technical debt: you worked quickly in the past and pay for it later with delays.

On top of that comes the risk. A single error in a single line can open a security vulnerability through which attackers can access customer data. Such incidents regularly cost companies hundreds of millions and are one reason why stock prices fall after a data breach.

How thousands of developers work on the same files

To prevent everyone from writing over each other, the codebase is kept in version control. This is a program that records every single change along with its timestamp and author. The standard for this is called Git. It allows you to jump back to an earlier state at any time, similar to the version history of an online document, only much more precise.

The usual workflow is always the same. A developer copies the current state, changes something in a separate branch, and then proposes the change for inclusion. At least one colleague reads through it — this step is called a code review. In parallel, automated tests run, i.e., small check programs that verify everything still works. Only after that does the change move into the main branch.

Large companies organize this differently. Google puts almost all its code into a single, enormous directory, known as a monorepo. Others split their codebase into many small, separately managed parts. Both approaches have advantages and disadvantages: a monorepo makes it easy to make changes across many places at once, but it quickly becomes unwieldy in size.

Codebases in tech news and in AI products

The term comes up whenever open source is discussed. Open source means that the codebase is publicly visible and anyone may propose changes. The Linux kernel, the core of many servers and all Android phones, is the best-known example. Platforms like GitHub make such codebases accessible to everyone.

In the AI discussion, the codebase plays a dual role. First, language models were trained on huge amounts of public code, which has led to disputes over copyright. Second, tools like GitHub Copilot or Cursor intervene directly in the codebase and suggest changes. Some companies report that a significant portion of their new code is now generated by machines.

A common misconception is that a large codebase is a good sign. The opposite tends to be true. Experienced teams are happy when they can delete lines, because every line has to be maintained, tested, and understood. Less code for the same functionality means less attack surface and lower costs.