clines 7.0 — measuring change, not commits

15 August 2026 · covers 7.0.0

clines refactor has always rested on a well-supported idea: complexity alone ranks a file you never open above one you edit weekly, so weigh it by how often the file actually changes. The research backs that — Nagappan and Ball discriminated fault-prone binaries at 89% accuracy from churn measures alone.

The problem was the counting. git log --name-only, one tally per path, every commit worth the same. This release fixes four things about that number and adds the analysis it was missing.

Most hotspot commits are not people

A study of 91 GitHub repositories found that automated bots account for 73.9% of hotspot-related commits. Administrative changes were 53.6% of all hotspots; version bumps alone 26%, formatting churn 9%. Their recommendation is blunt: filter bot commits to surface the human-driven changes.

So clines does, by default. Dependabot, Renovate, github-actions and the rest are dropped before anything is counted, and --include-bots brings them back. In a repository with an active dependency bot this changes the ranking outright.

Three more corrections to the same number

The Re-read column is deliberately not weighted. It is a factual claim about tokens already spent, and decaying it would make it a different, vaguer thing.

clines coupling

refactor tells you a file is expensive. It has never been able to tell you why. Change coupling can: a busy file that always changes alone is merely busy, while one that always changes alongside three others is a missing abstraction or a wrong module boundary. 

Files that keep changing together
  File                            Changes with   Shared   Strength
  ────────────────────────────────────────────────────────────────
  src/cli/program.ts      test/program.test.ts       20        95%
  src/cli/run.ts          src/core/pipeline.ts       13        84%

Strength is shared commits over the pair's average revision count, so it cannot exceed 100%. The thresholds follow CodeScene's documented defaults — 10+ revisions each, 10+ shared commits, 50%+ strength — which are strict on purpose. Below them a co-change is as likely to be coincidence as design. On a young repository they return nothing, so clines says which flags to lower instead of printing an empty table.

One guard matters more than it sounds: commits touching more than 30 files are skipped entirely. A sweep across 53 files mints 1,378 pairs, all of them meaningless. Coupling analysis without that filter mostly rediscovers your last big refactor.

A file coupled to its own test is expected and healthy. Coupling across module boundaries is the finding.

clines agent

Which files are safe to hand to a coding agent unattended? Recent work found that a one-standard-deviation improvement in code health raised the odds of a non-breaking AI refactoring by 20–40%, with 15–30% lower break rates in healthy code. Separately, a study of five agents across 86 projects found their refactorings are overwhelmingly cosmetic — over 91% annotation-related for one agent — and mostly do not improve design, with one agent measurably increasing smells.

So clines rates each file safe, review or human from four signals it already had: branchy logic, size in tokens, duplication (an agent fixes one copy and leaves the rest), and whether the complexity is concentrated anywhere you could safely edit.

Thresholds pair a repository quantile with an absolute floor, which was not the original design. Quantiles alone flag a quarter of any repository by construction — a one-line file in a tidy tree came out "risky" because something has to sit at the 75th percentile. The floors are 10 cx per 100 lines and 2,000 tokens.

It is worth being straight about the evidence: the supporting study used 5,000 competitive-programming Python files, which is a weak stand-in for production code, and both it and the code-health work come from the vendor that sells the metric. The output says so. It is a reading order, not a permission system.

Also in 7.0

← All posts