For most of its history, LangChain shipped a new release roughly every 30 minutes. By the end of the window I analyzed, releases were coming once every six days, and a CI build that historically took about 10 seconds was taking 55 minutes β 889 times the repo's own baseline, and still 27 standard deviations above normal at the last measurement.
None of this is judged against an external standard, a linter rule, or anyone's opinion of what a "healthy" repo looks like. It's LangChain measured against LangChain: 38 months of its own commit history (January 27, 2023 to March 14, 2026), with every number below tied to a specific commit you can look up.
I picked LangChain deliberately. It's one of the few major codebases whose entire git history sits inside the AI-assisted era β it was born the same quarter the world started pair-programming with LLMs. To be clear about what that means: I cannot tell you which of its commits were written by humans and which by AI tools. Nobody can, from the outside. What I can measure is what happened to the repository's structural rhythms over those 38 months β how big commits got, how builds behaved, how releases moved, which files changed together. Here is what the data says.
1. Builds: 10 seconds β 55 minutes, and still elevated
The headline number, because it's the one that hasn't gone away.
LangChain's typical build duration across its history: 9.5 seconds. Observed at the end of the window: 3,306 seconds β about 55 minutes. That is 889x the repo's own baseline, and unlike most deviations in this analysis, it did not settle back down: at the last measurement it was still 27.6 standard deviations above normal.
Some of this is the honest cost of growth β LangChain became a large monorepo with many packages, and monorepos pay CI taxes. But the shape matters: the analysis found build-time growth statistically entangled with two other signals (commit size and file-pairing novelty β see below), escalated because independent measurements kept converging on the same story. Slow builds weren't an isolated infrastructure problem. They moved together with how the code itself was changing.
2. Releases: every 30 minutes β every 6 days
Historical norm between releases: 0.5 hours. Observed: 145.8 hours β a bit over six days. That's 220x the baseline.
If you followed LangChain in 2023, you remember the joke that it released faster than you could pip install it. The data confirms the joke, then shows it ending. One honest caveat, and it's important: unlike the build-time finding, this deviation later returned to baseline β the release rhythm recovered. Whether the slowdown was a bottleneck, a deliberate maturation of the release process, or a stabilization push is a question the maintainers could answer in one sentence and I can't. The measurement only says: for a while, the repo's release heartbeat ran 220x slower than its own normal, and the change correlated with commits touching more files than usual.
3. Commit size: 2 files β 131 files
Typical files changed per commit, across 38 months of history: 2. Observed: 131 β 87x the baseline.
The trigger commit is public and you can check it yourself: 4e9a1eb2 β "chore: delete CLI (#34855)", 131 files in one commit. Deleting a whole CLI is a legitimate thing to do; the point is not that this commit was bad. The point is that a repo whose median commit touches two files developed a recent window where hundred-file commits stopped being exceptional. Large commits are where review quality goes to die quietly β not because reviewers are lazy, but because no human meaningfully reviews 131 files.
4. Novelty of file pairings: 0.99 β 0.00
This is the strangest one, and I want to present it carefully, because the honest reading is less dramatic than the number.
"Co-change novelty" asks: of the file combinations changed together in a commit, what fraction has never been seen together before? LangChain's historical norm is 0.99 β nearly every commit combined files in some new way, which is what a rapidly evolving codebase looks like. In the recent window it hit 0.0000: commits touching only file combinations the repo had seen many times before.
The trigger commit is cdf140e7 β "release(core): 1.2.17 (#35527)", a two-file version bump. So a big driver here is release automation: bots bumping the same two files over and over. That's the honest explanation, and I'm giving it to you rather than hiding it. But it's worth sitting with what it means in aggregate: an increasing share of this codebase's commit stream is repetition β the same well-worn file pairs, again and again. If that sounds familiar, it should: GitClear's research on AI-era code found the same directional story in a different metric β copy-pasted and duplicated code rising while refactoring (moved code) falls. Two independent measurement approaches, same rhyme: more repetition, less novel restructuring. I'd call that a trend worth watching rather than a verdict.
5. The signals converge
Any one of these numbers alone is a curiosity. What made me write this up is the convergence: the analysis matched 23 known cross-signal patterns (from a library of 44 validated across 200+ open-source repos), and several were escalated specifically because independent signals kept moving together β file-pairing novelty with build time, commit size with release frequency, change focus with both. When one metric drifts, it's noise. When five drift in a correlated way, the repository's development rhythm has genuinely changed.
Methodology, honestly
Because this kind of analysis is easy to do badly, here's exactly what was and wasn't done:
- Baselines are per-repo. Every "typical" value is computed from LangChain's own history using robust statistics (median-based measures β MAD and IQR β which resist being skewed by outliers). No comparisons to other repos, no universal thresholds.
- The deviation window is compared against a baseline of 20 prior commits. That's short by design β it answers "is this abnormal for this repo right now," not "is this a bad codebase."
- Some deviations later returned to baseline (release cadence; commit size at its trigger). Build duration did not β it was still 27.6Ο elevated at last measurement. I've marked which is which above.
- Units: build duration in seconds; release cadence in hours between releases.
- Every finding names its trigger commit by hash and PR number. Please check them β that's why they're included.
- All data is public. The analysis ran locally against the public git history, GitHub Actions, and GitHub Releases data.
- What this can't tell you: which commits were AI-written, whether any individual change was a mistake, or anything about the correctness of individual lines. It measures structural rhythm, not code quality line-by-line.
The full interactive report β every metric, every trigger commit, all 23 matched patterns β is here: codequal.dev/reports/langchain.
Measured with Evolution Engine, a drift detector I built.
I'm Rostislav Alpin, owner of CodeQual. I spent 20 years in QA before building measurement tools, so my bias is exactly what you'd expect: I trust instruments over vibes, and I distrust my own instruments until someone else has kicked them.
Which is the real reason this post exists. One repo is an anecdote. If you want to know what your repository's baseline looks like β and whether the last few months broke it:
Want this run on your repo? Reply.
