First-person write-ups on what measuring code actually turns up — the argumentative companions to the technical papers. Every number in them traces back to a paper you can re-run.
A mechanically selected cohort — nobody picks the packages — scanned monthly on public infrastructure with a public engine. The findings: the young AI agent stack is enormous exposed surface, thirteen credential alarms that all proved to be deliberate fixtures (including a detector that detected a detector), one build hook read and cleared, zero remote fetchers — and the limits stated as plainly as the results.
Read the article →A routine cleanup script, an adversarial safety check the agent ran on itself, and one variable holding two meanings — 700 GB and a week’s work erased by the very test written to prevent it. Why this is a recurring class, not a freak accident; what no scanner honestly prevents; and why the repository was the only thing left standing.
Read the article →In July 2026 a swarm of autonomous AI agents ran a multi-day intrusion against Hugging Face — roughly 17,600 recorded actions, entered through a config file in a repository. Their own AI security stack saw the attack and failed to raise the alarm’s criticality; humans caught it late. What the incident record actually says, what a swarm needs from your code — nests, eggs, durable footholds — and how to take every one of them away.
Read the article →In July 2025 Ukraine’s CERT caught malware, tied to Russian military intelligence, that carries no attack code at all — it asks a hosted AI model for its commands and runs whatever comes back. Then the first AI-powered ransomware, an AI running an espionage campaign, and the xz backdoor no review could see. What a code gate honestly catches — and the one defence that still works.
Read the article →Nobody photographs the scaffolding. The part of an application everyone praises stands on things nobody looks at — generated files, vendored libraries, lockfiles, the code an agent wrote at three in the morning — and that is where the grubs are. On npm/cli v10.9.0→v11.0.0, 80.1% of all measured churn came from one generated file. How to look at the timber: TRUE_CHURN, the Code Browser, the Agent Scan.
Read the article →An LLM never revises - it generates once, at the customer's expense, and moves on. Observe an LLM coder for an afternoon and you can't miss it: the AI never edits a line in place. Mature human-maintained projects rework around one statement in six; an intensively agent-built codebase measured one in five hundred (CHG_LLOC). Every term defined in-page, every figure sourced - and a straight answer to "maybe repair is obsolete".
Read the article →In npm/cli v10.9.0 to v11.0.0, 80.1% of measured churn came from package-lock.json alone. TRUE_CHURN separates authored change from generated churn — deterministically, auditable by named rules, nothing hidden.
Read the article →Your security walls all face outward — firewall, code review, dependency audit. AI agents live inside them: code that calls a model and acts on whatever comes back. Nobody recruited them — they accreted through SDKs, library updates and transitive dependencies — and nobody keeps a list of them. Last July one deleted a production database during a code freeze and misreported the recovery. This piece is about the list: finding every place your software touches a model, with file and line numbers, before policy is possible.
Read the article →There's a product category that will point at a file, and by extension at the person who committed it, and declare it AI-written. I read the field's own research to see if anyone can actually do that. Short answer: no — and the detail that convinced me is that the strongest signal these classifiers found is the comments. This piece walks through the evidence, then shows the measurement that does hold up, with a standing offer: the hashes are printed, break my numbers.
Read the article →5.3 million logical statements of churn across twelve yearly windows. Hypergrowth at REWORK 0.5% — one statement edited in two hundred; the great 2017 shedding, the only year deletions beat additions; and a decade-long climb to an all-time-high 11.6% in 2026 — with no AI-era bend in the curve. Every row reproduces from two public commit hashes, printed in the article.
Read the article →It started with a mailer script and a habit that was impossible to unsee: the AI never edits a line of code in place — it deletes the block and writes a new one. That observation leads through the detection literature (brittle, and mostly answering the wrong question), to a process signature measurable with plain arithmetic — established projects rework one churned statement in six, an agent-built application one in five hundred — and ends at the question with real teeth: never mind who wrote the code, is there an AI inside it?
Read the article →The trio moves your code from commit to cluster, and none of the three can tell you what actually changed on the way through — how much of the diff a developer wrote, how much a lockfile or an AI agent produced, and whether that should block the merge. Working recipes for slotting that measurement into the pipeline as one container image.
Read the article →A colleague asked for a churn history of Erlang/OTP. The standard tooling came first, like everyone reaches for — and three of seven windows aborted outright, 4,046 files were set aside silently, and real Erlang defeated its comment detection. Then OTP broke our own engine too, twice. What broke, what got fixed, and the 2026 number that came out the other side: REWORK 22.6%, OTP's deepest repair regime on record.
Read the article →I build a churn-measurement engine, and I have become addicted to pointing it at famous codebases. The biggest scan so far is a full year of Chromium — 87 million lines through the engine, on a laptop. Name a public codebase you want measured, and the results get published here.
Read the article →