What it measures

Code churn tracks lines of code that are added and then changed or removed again soon after, typically within a few days to a couple of weeks. High churn means a developer wrote something, then went back and reworked the same lines repeatedly before the work stabilized. It is distinct from total volume of change: churn isolates the portion of work that did not stick the first time.

Churn is often read as a proxy for uncertainty or rework. A spike can mean unclear requirements, a hard problem, exploratory work, or quality issues surfacing late. It measures how settled the code is, not how much was produced.

How to measure it

From git history, you compute churn by comparing each line's authored date against when it was subsequently modified or deleted. A common method: for every changed line in a commit, check whether the line being replaced was itself written within a recent window, for example the last 14 days. The share of edits that touch recent code is the churn rate.

Practically, tools walk git log with line-level blame across commits and bucket changes into new work versus rework of recent work. You can scope churn by file, by author, by directory, or by time window.

Pull request data adds resolution. Heavy churn during review, or repeated force-pushes to the same branch, points to where the work kept moving after it was first proposed.

What it does not tell you

Code churn tells you that code is being rewritten. It does not tell you whether that rewriting is good or bad. High churn on a thorny algorithm can be exactly the right behavior, careful iteration toward a correct solution. Low churn can mean stable, well-understood work, or it can mean nobody is touching code that badly needs attention. The number alone cannot tell those apart, and reading it as a defect signal punishes the exact exploration that hard problems require.

More fundamentally, churn measures motion in the code, not direction of the work. It counts how much the lines moved, never what they were for or whether the rework served the initiative it belongs to. Two identical churn spikes can be one engineer thrashing on unclear requirements and another deliberately hardening a launch-critical path, and the metric reads them the same. That is the gap Execution Intelligence is built to close: reading what is actually being built and why, connecting the rework to the strategy it advances, rather than scoring teams on how much their code moved.

Churn is also easy to misattribute. A large refactor, a generated-file update, or a formatting pass can register as churn without representing real rework, so the raw number needs context before any conclusion holds.

How InteliG uses it

InteliG computes churn directly from real git history with no manual instrumentation, reading the same commits and pull requests your team already produces. Cognis then connects each churn pattern to the initiative the work belongs to, the contributors doing the rework, and the cost that rework carries, so a churn spike is read in context rather than as a bare number.

That lets a churn signal answer the question that matters to a CTO: is this rework moving a strategic initiative forward, or is it effort spent without direction. The metric becomes evidence in a chain from code to strategy to cost, not a standalone score.

Related terms

Code Ownership — Who owns and maintains a given area of the codebase
Technical Debt — Accumulated shortcuts and deferred quality work that slow future change
Execution Intelligence — Reading how an organization actually executes, connecting code to strategy and cost