Agent Code Is Supposed to Rot in Three to Six Months. I Went Looking in My Own Repos.

Dex Horthy published 'Why Software Factories Fail' yesterday, and the part I could not let go is the honest one: he says models degrade codebase quality over time, and then says plainly that he cannot prove it and neither can you, because nothing measures this. He is right about that. What I had was three of my own projects, so I went looking. This is what I saw and what I think it means.

The Argument I Am Answering

Dex Horthy's Why Software Factories Fail is the best version of the case against agent-built software, because he goes all the way down to the training loop to explain why it happens. Coding models are scored by benchmarks that ask one question, did the tests pass. His line about that is the one everybody is quoting today, and it deserves it:

If the tests pass, we win, but there is no penalty for eroding codebase maintainability.

The reason nobody has fixed this, in his telling, is timing. Tests give a verdict in seconds, which is what makes millions of training loops possible. Bad architecture bills you much later, the first time somebody opens a file for a one-line change and finds they cannot make it in one line.

He has the scar tissue to go with the theory. HumanLayer went fully lights-off in July 2025, agents writing and shipping, nobody reading the code. It broke in production, the model could not find the cause however he prompted it, and he ended up digging through a codebase he had stopped reading months earlier. By the third time around, his cofounder rewrote the patterns by hand over two weeks in VS Code. Somewhere else in the post, in an aside about brownfield code, he puts a number on the general case:

it feels like an agent-built codebase starts to struggle after maybe three to six months, you start to slow down, and the way you approach adding new things has to change

I am not writing this to debunk him. I think the training argument is correct. I have watched agents write code that passes every check while being structurally awful, and the try/catch-around-everything screenshot in his post is a thing I have seen in my own diffs. What caught my attention is how honest he is about the state of the evidence. He cites an industry report showing review quality down and incidents up, then discounts it himself as a correlation signal rather than proof. And on the thing he actually wants to know, he says:

I can't prove this. You can't prove it either. There are no good benchmarks for a model's ability to maintain codebase quality.

He is right about benchmarks. But for months I have been running an OpenUP-derived process for coding agents, and it is worth saying what that means before anything else. OpenUP is a lightweight descendant of the Rational Unified Process, the heavyweight methodology of the late nineties, and my version of it replaces human policing with machine-enforced boundaries. That gives me repositories where agents did most of the work under a fairly heavy process. If agent-built code starts to struggle at three to six months, mine had the time to show it. So I went looking.

What I Looked At

Three codebases, all mine. Two are private products, so I will call them App A and App B. The third is the framework itself, which is public.

App A is close to a pure agent artifact: about 97% of its application commits are agent-authored, and the handful of human ones are ops work, secrets and DNS and Kamal config. Nobody hand-wrote a model or a controller in it. App B is the interesting one, thirteen months old, with two eras inside a single codebase. Seven months built by humans, then six months where agents did roughly half the commits. Same product, same stack, same team.

I should be careful about when the clock starts, because the test depends on it. Horthy's sentence is about the agent-built codebase, so the clock starts the day the agents take over, and his own timeline agrees: lights-off in July, wall hit around October. For App B that means six agent months, which puts it at the far edge of his window rather than past it. What App B does offer is the harder version of the problem, because the agents did not start from an empty directory. They inherited seven months of human code with almost no tests.

And since two of these repos are private, you cannot rerun anything against them. So I am giving you the shape of what I found and the few numbers that carry the argument, and leaving the rest of the decimals out, because precision nobody can check is decoration. Read this as a practitioner reporting on his own work.

What I Found

The most direct way to test "entropy accumulates" is to stop inferring it from commit behavior and just rebuild the codebase at the end of every month and look at it. So that is what I did with App B, over thirteen months and fourteen times growth:

month end	files	lines	median file	p90 file	over 400 lines
2025-06	69	7,926	45	382	8.7%
2025-09	143	20,073	58	393	9.1%
2025-12	200	28,069	70	392	9.5%
2026-02	753	104,512	77	333	7.6%
2026-07	813	110,464	75	315	7.4%

The codebase grew fourteen times and the big files did not pile up. God objects are the canonical symptom of the decay everyone predicts, and measured on the tree as it actually stood each month, they got proportionally rarer. I want to flag that word "proportionally", because plenty of small new files can improve a percentile without any existing file getting shorter. The check that settles it is to track only the files that were there at the start, and I owe you that one.

App A, the almost-entirely-agent one, does not move at all across its life. Median and p90 file length both end within a line or two of where they started, and its p90 sits at well under half what App B ran at during its human months. The most agent-built codebase I own has the smallest files, which is not the result I expected to be writing up.

The second prediction is shotgun surgery, Martin Fowler's term and the one Horthy picks: it gets hard to change one part of the system without breaking another. That shows up as changes touching more files in more places. I plotted files per commit for App B across all thirteen months and it is flat. It wanders inside a band and never picks a direction, and the agent months sit in the same band as the human ones. My framework repo shows the same thing measured per task rather than per commit.

I will raise the objection myself, because it is the one I would raise at somebody else. My process caps commit width on purpose: a lane declares which paths a change may touch, and a fence blocks the commit if the diff escapes them. Under that regime shotgun surgery would not appear as fat commits, it would appear as more tasks per feature. So this measurement is partly measuring my own tooling, and I would not lean on it alone.

The third one is where I actually learned something. Co-change coupling was the metric I most expected to catch a problem: if the architecture is degrading, files in different modules should increasingly move together. It did not climb. But when I looked at which pairs were most coupled, App A's strongest pair by a distance was this:

config/locales/en.yml  ~  config/locales/es.yml

It is a bilingual app. The English and Spanish translation files have to move together. That is not entropy, that is correctness. The next strongest pairs were locales with routes, model with schema, controller with routes, which is just the shape of a Rails feature.

I had been planning to build a coupling threshold gate into my process. This killed it. That gate's very first action would have been to flag the i18n invariant it is most important never to break. A coupling alarm in a conventional web framework mostly detects the framework.

What I Think Is Doing the Work

The finding I did not go looking for is the one I keep thinking about. I tracked App B's test-to-source ratio by month, and the two eras do not look like the same project. The seven human months sit at essentially zero. The six agent months sit around a half. Seven months of human-built code with almost no tests, and then agents arrived and the test suite arrived with them. App A was born with a test suite and has kept it.

Nobody should read that as agents spontaneously caring about coverage. The process makes them, and it makes them do a few other things too:

One task per run. A run completes exactly one roadmap task and stops. It does not "keep going". Scope creep counts as a process violation and the run ends there.
The spec is written before the code, and fixed first. If behavior changes, the specification changes first and the code follows. It sounds bureaucratic and it is the highest-leverage rule I have.
Each change declares its surface, and a machine checks it. A lane declares which paths it may touch, and a write-fence blocks the commit if the diff escapes them.
Nothing needed to continue the work lives in a conversation. Roadmap, status, run logs, decisions, all in the repo. Context does not evaporate when a session ends.

Horthy rules this whole approach out in advance, and it would be cheap of me to route around that. His thesis is that no amount of harness engineering solves what is fundamentally a model-training problem, and he has a section aimed squarely at people who reply "you're holding it wrong". So let me be exact about what I am not claiming. I am not claiming to hold it better, and I am not claiming that lanes and fences make the model write better code. They cannot. He describes review agents as raising the floor without moving the ceiling, and that is right. My claim is the narrower one: with the surface bounded and the floor raised, the ceiling never had to move. The model writes whatever it writes. What changes is how far that can spread before a human signs off.

He could reasonably answer that I have just described a more expensive harness, and that the code rots inside the lanes I allowed anyway. Six agent months does not settle that. What I have is a 90s methodology that got buried in 2005, with a write-fence bolted onto it, and the paperwork that killed RUP is the paperwork that makes this work.

Where He Is Still Right About Me

I would rather say this myself than have it said in the replies.

My sample is three repositories, one owner, one stack, one agent vendor. That settles nothing in general, and I am also grading a process I designed, with a script I wrote, on code I own. Nobody should mistake this for an independent evaluation.

Single-owner repositories may not be able to show the failure at all. HumanLayer is a company, with a cofounder and customers. If the real mechanism is coordination, several people and several agents building incompatible mental models of the same system, then my repos are structurally incapable of exhibiting it. That is the strongest argument against this post and I have nothing to answer it with.

My metrics are blind to the decay mode agents get accused of most. File size and change spread say nothing about duplication, dead code, or the same helper existing in three slightly different versions. A codebase can hold its file sizes steady while quietly tripling its own logic, and fourteen times line growth in thirteen months is the kind of number that should make anybody ask whether the product needs all of it.

And one comparison turned out to be unavailable. I tried to measure how many of the lines each cohort wrote still survive today. Agent code looked slightly worse, until I noticed the whole result rested on a single commit of about 25,000 lines of generated tests, surviving almost untouched because nobody edits generated tests again. It carries no Co-Authored-By trailer, so it counts as human while being almost certainly agent-written. Bulk-generated work keeps landing in git history dressed as high-quality human contribution.

Everything Here Has a Short Shelf Life

Whatever you take from this, give it three months before checking whether it still holds. That is roughly the half-life I see on my own practices, and I say that as somebody supposedly running a stable process.

My framework started in January as a little converter for 961 Eclipse OpenUP HTML files, and it is not that any more. In April I shipped the hardest enforcement I had built, blocking hooks with no bypass, and softened it to warnings the same afternoon because it made real work impossible. I moved the mechanical writing to a cheap Haiku scribe so the expensive model would stop billing me for bookkeeping. And in this very post I killed a coupling gate I had already designed.

Every quarter something lands that makes a piece of my process unnecessary. Subagents, skills, longer context, better tool use. Half of what I tuned last quarter now solves a problem the harness solves by itself. Horthy is in the same position and to his credit he wrote it down: one of the posts he links is called "Everything We Got Wrong About RPI". The people furthest ahead on this are revising their own advice every few months. We are all still working out how to do this.

My Bet

An opinion you cannot lose is not worth much, so here is mine, in a form a single repository can break:

An agent-built codebase with almost no tests will show its largest files getting longer and its modules getting more tangled within six active months of agent work.

All three of my repositories carry a real test suite, and none of them show either symptom. If you have an agent-built repository with real tests that decayed anyway, my bet is wrong and I would like to see it. If you have one without tests that decayed, then we agree, and we have found the variable that matters.

Which is why I think this disagreement is narrower than it looks. Horthy's part II is called "Turning the lights back on", so my guess is we land close to each other: the discipline has to come from outside the model. Where we will differ is on its shape. I have bet on written specs and machine-checked lanes. His title reads like a bet on putting humans back in front of the code at the moments that matter.

There is one number I still owe, though. App B carries around seventeen thousand lines of JavaScript with no JavaScript unit tests at all. It is exercised end to end by system tests driving a real browser, so "untested" would be the wrong word. But a system test tells me the page works. It does not fail when a controller quietly grows a second responsibility, which is exactly the shape of decay I went looking for. That directory is where I would look first, and I have never pointed a single measurement at it.

Horthy's post: Why Software Factories Fail, with a talk version on YouTube. My process and measurement scripts live in open-up-for-ai-agents. The framework repo is public and reproducible. The two applications are not, so on those you have my word and my scripts, which is exactly as much as that is worth.

TL;DR