Code Churn

Programs consist of text that humans write: line by line, instructions for the computer. These lines don’t stay the same forever. Some are reworked after months, others are deleted again after just a few days. Code Churn refers to exactly this second case: freshly written lines that are changed or removed again shortly afterward. Typically, everything that is touched again within two to three weeks of its creation is counted for this. The result is a percentage: How much of a week’s work did not survive?

What a high churn rate reveals about a project

A certain amount of rewriting is completely normal and even healthy. No one gets every decision right on the first try. Typical projects have a churn rate of about 10 to 20 percent. If the value rises significantly above that, it’s a warning sign. In that case, a lot of work time is being put into results that end up in the trash shortly afterward.

The cause rarely lies with the programmers themselves. Usually the requirements are unclear: the client doesn’t yet know exactly what the software is supposed to do. So it gets built, discarded, and rebuilt. Sometimes a developer is also stuck, trying solution after solution and finding none that holds up. High churn values are therefore mainly a reason for a conversation, not a reprimand.

It is important to distinguish this from the sheer volume of code written. Someone who produces many lines doesn’t automatically work well. And someone who deletes a lot again doesn’t automatically work poorly. Code Churn says something about the process, not about the quality of an individual person.

How the number is calculated

Almost every software project today uses a version control system, usually Git. This system stores every change to the code with a timestamp and author. So you can look up at any time when a particular line was created. This gives you all the data needed for the calculation.

An analysis program goes through the changes of recent weeks. For each deleted or overwritten line, it checks the age. If the line was younger than the chosen time period, it counts as churn. In the end, this amount is divided by the total work done in the period. Common tools for this are GitPrime, Waydev, or LinearB.

A comparison helps with understanding: an author is writing a novel. That he reworks chapters from the first draft a year later is craft. That he tears up every page the very same evening and starts over suggests that he doesn’t know where the story is supposed to go. This is exactly the difference that Code Churn measures.

From developer dashboards to AI assistants

In larger companies, the metric appears on dashboards for team leads, alongside figures such as time to delivery. There it serves as an early warning system for projects that are getting out of hand. It becomes controversial when superiors use it to evaluate individual employees. Someone who knows their churn is being measured simply stops deleting their own bad code — and that harms the software.

The term gained new attention through AI coding assistants like GitHub Copilot. These tools automatically suggest lines of code that developers can adopt with a keystroke. A widely cited analysis by the company GitClear, based on millions of lines of code, showed that the share of short-lived lines has risen significantly since 2021. Suggested code is accepted more quickly and then, naturally, also discarded more quickly.

Whether this is a genuine quality problem is being debated in the industry. Critics of the study counter that quick trial and discard can also be a legitimate way of working. In tech news, then, you mainly encounter Code Churn in reports about whether AI assistants are really making software development better, or just faster.