Code Half-Life
Code Half-Life is the time it takes for half of a batch of AI-written code to be rewritten or deleted.
Generation speed tells you how fast code arrives. Half-life tells you how long it stays. Take the lines an AI tool wrote in one period, follow that exact cohort forward, and read off the moment 50% of it is gone. That single figure, reported per tool and per model, is the durability of your AI-generated code.
What it measures
Survival analysis, applied to a cohort of AI-authored lines.
Code Half-Life borrows the method epidemiologists and reliability engineers use for time-to-event data: a Kaplan-Meier style survival analysis. You define a cohort, the AI-authored lines committed in a given period, and then follow that exact set forward in time. At each later point, every line in the cohort either still exists or has been rewritten or deleted.
The survival curve is the fraction of the original cohort still present as time passes. It starts at 100% and falls. The Code Half-Life is simply the elapsed time at which the curve crosses 50%: the point where half of what that tool wrote is gone. Lines still alive at the end of the observation window are censored, not counted as deaths, which keeps the estimate honest for recent cohorts.
Because attribution is resolved per change and per session, the same analysis runs separately for each tool and each model. The output is not one blended durability number but a set of curves you can compare side by side.
A worked example
Reading a survival curve, with illustrative numbers.
The numbers below are illustrative, chosen to show how the method works. They are not a measured benchmark or a real customer result.
| Week | Lines surviving | Share of cohort |
|---|---|---|
| 0 | 1,000 | 100% |
| 3 | 720 | 72% |
| 6 | 510 | 51% |
| 10 | 300 | 30% |
Half the cohort is gone by about week 6, where the curve passes 51%. So in this example the Code Half-Life is roughly 6 weeks. Note that this is not the average lifetime of a line: the half-life reads off the median of the cohort, so the long tail of code that survives well past week 10 does not pull the figure up.
Half-Life vs Code Yield
One measures duration, the other measures return. They are companions.
It is easy to conflate the two because both touch durability. The distinction is sharp: Code Half-Life answers how long AI code lasts, while Code Yield answers what return that code delivered per dollar.
A duration
Measured in time: weeks or days until half a cohort is rewritten or deleted. It is a single survival figure, vivid and easy to track, that tells you whether output is durable or churning. It says nothing about cost.
A return
A rolled product of Ship, Last, and Matter set against spend. It folds durability into a wider picture that also weighs cost and whether surviving code was load-bearing. Survival is one input, not the whole answer.
In practice you read them together. A short half-life is one of the signals that pulls down the survival rate feeding the Last gate of Code Yield. Half-life tells you something is decaying fast; Code Yield tells you whether that decay, plus its cost, is eating your return.
What the number implies
Short versus long half-life, read per tool and per model.
A blended half-life across every tool hides the decision you actually make. Tools and models are pointed at different work, and their output decays at different rates. Reporting per tool and per tool yield comparison lets you see which generator produces code that lasts, on which kind of task, rather than averaging durable scaffolding against throwaway snippets.
A short half-life on production logic is a churn signal. Code that is rewritten within days was either wrong, unclear, or generated faster than it could be verified. That rework carries a verification tax: human time spent reading, testing, and correcting output that did not survive. The faster a tool generates code that then decays, the more of that tax it quietly imposes.
A long half-life on load-bearing code is the durable outcome you want, but only when paired with survival rate so you are not just rewarding code that persists because nobody dares touch it. This is also where uncosted token use shows up: a model can run up spend producing high-churn output, a pattern of tokenmaxxing that only becomes visible once you can see both survival and cost per tool.
For instance, say a 30-engineer team runs two AI tools on similar backend work. If one tool's AI-authored code shows a half-life of about 3 weeks and the other about 12 weeks, the first is generating roughly four times the rewrite churn for the same surface area. That gap, not the raw line count either dashboard reports, is what tells you where the rework is going. Figures illustrative.
Where it fits
One durability lens in the wider Return on Code picture.
Code Half-Life sits inside the broader question of how to measure AI coding ROI honestly. Codelitics computes it repo-locally from your own git history and AI activity, so every curve is traceable to how it was derived. You control which repositories and tools are in scope, and every figure is exportable and traceable to how it was computed.
The same survival method underpins the durability signals on the per-tool pages. You can read how it plays out for Claude Code, GitHub Copilot, and Cursor, each of which exposes its own usage but cannot tell you how long its code survived in your codebase relative to another tool.
Code Half-Life FAQ
Common questions about measuring AI code survival.
- What is Code Half-Life?
- Code Half-Life is the elapsed time at which half of a cohort of AI-authored lines has been rewritten or deleted. You take the lines an AI tool wrote in a given period, follow that exact cohort forward, and read off the point where 50% of it is gone. It expresses durability as one figure, for example six weeks, and is reported per tool and per model.
- How is Code Half-Life calculated?
- It uses survival analysis, the same Kaplan-Meier style method used to study time-to-event data. Each AI-authored line in the cohort is an observation that either survives or is removed at each subsequent point. The survival curve is the fraction still present over time, and the half-life is where that curve crosses 50%. Lines still alive at the end of the window are censored rather than counted as failures.
- What is a good Code Half-Life?
- There is no published industry benchmark for AI-code survival yet, so we do not quote a target number. What matters is the trend and the comparison: whether a tool's or model's half-life is rising or falling on your own codebase, and how it compares against another tool on similar work. A half-life of days on production logic signals churn and rework; a long half-life on load-bearing code signals durable output.
- How is Code Half-Life different from Code Yield?
- They measure different things and are companions, not substitutes. Code Half-Life measures duration: how long AI-authored code lasts before it is rewritten. Code Yield measures return: the realized value per dollar, as Ship times Last times Matter rolled into one product. A short half-life is one of the signals that drags down the Last gate in Code Yield, but Code Yield also accounts for cost and whether the surviving code mattered.
- Why report Code Half-Life per tool and per model?
- A blended average hides the decision you actually make. Different tools and models are often pointed at different work, and their output decays at different rates. Reporting half-life per tool and per model lets you see which generator produces code that lasts on which kind of task, instead of a single number that averages durable scaffolding against throwaway snippets.
- Does Code Half-Life rank individual developers?
- The reported Code Half-Life is a team and tool level figure and does not rank individuals. Individual-level views exist but are opt-in, sit outside the conformant Return on Code score, and are governed by your own policy.