Evan Merz: AI coding agents generate a fragile codebase, and the incident curve proves it

Evan X. Merz says he generated at least 90% of his code with AI in his last months at Meta, which he describes as the minimum for a decent rating, and he suspects his resistance to going further is part of why he was laid off in May. Now at another large tech company, he writes 100% of his code with AI because that is the expectation. His essay published November 7 is not a complaint about the tools. It is a claim about what they produce: a codebase that gets more fragile the more you lean on them, and a set of symptoms he says show up on a delay.

The core mechanism is a context window. Merz argues AI solves the problems that fit inside it very well and is “totally oblivious to the long term issues that can’t be understood in that relatively small frame.” That is the whole thesis in one sentence, and it is worth taking seriously because it is not a claim about model capability. It is a claim about scope. A coding agent sees the diff, the file, the failing test. It does not see the abstraction you will regret in eighteen months, or the second user segment your end-to-end tests never modeled.

The four failure modes

Merz lists four ways AI usage makes a codebase fragile. First, shallow tests. Agents write lots of coverage for getters and setters, which need little testing, and their e2e tests tend to cover only the cases already covered. The gaps are invisible because line-level coverage still looks green. Second, over-complex code. He says AI reaches for two or three helper methods where one would do, and applies DRY “to a fault,” adding structure that makes debugging harder for the humans who inherit it. Third, eroding understanding. The longer a team leans on agents, the fewer developers can reason about the data structures and algorithms well enough to catch a pull request that introduces an abstraction that fights the existing ones. Fourth, velocity outrunning review. Each PR arrives faster than the last and gets less review time, so developers skim, and small defects accumulate into what he calls “a morass of spaghetti code.”

None of these are exotic. They are the ordinary failure modes of fast-moving teams, compressed. The difference is that AI removes the natural brake. When a human writes the code, the writing is the review. When an agent writes it, the review is the only human contact left, and Merz says the pace is squeezing that contact toward zero.

The symptoms show up late

The more useful half of the essay is the diagnostic. Merz says the damage is not visible at first. Early on, “the PRs came and were merged and everything seemed alright.” Then a p0 lands at the end of the month. Then two SEVs the next month. Then more. “After a year or two of agentic coding, it seems like there’s an incident every weekend.”

That timeline matters for anyone evaluating AI coding tools on short-horizon metrics. A benchmark that measures whether the agent’s code passes the tests will not catch this, because the tests are part of the problem. Line coverage will not catch it either. The signal Merz points to is incident frequency and, just as important, time to mitigate. Once humans understand the codebase less, recovery from an outage takes longer, because the people debugging are “entering unfamiliar territory.” More incidents that each cost more is a bad curve, and it is the kind of curve that does not show up in a quarter.

AI solves the problems that fit inside its context window very well, but it is oblivious to the long term issues that can’t be understood in that small frame.

His fourth symptom is the sharpest and the hardest to measure: errors that only users see. If no human is in the code ensuring the agent instruments analytics and catches errors properly, the team loses sight of how real people actually use the product. The automated tests pass because they test the users the agent imagined. The failures surface in production, to people who were never in the test suite.

Where the argument is strong, and where it needs data

The essay is a practitioner’s account, not a study. Merz is candid that he is speculating about his layoff, and his incident curve is his own observation, not a dataset. We cannot verify the Meta numbers or the incident trend at his current employer, and he does not supply them. Treat the specifics as one engineer’s experience.

But the mechanism is testable, and it lines up with what the industry is starting to report. The interesting question is not whether AI writes brittle code. It is whether the brittleness is a property of current models or of how teams deploy them. Merz’s answer leans toward deployment: the problem is the missing human brake, the review that got skimmed, the understanding that was never built. That is a process problem dressed as a model problem, which means it is fixable, and also means the fix is unpopular, because the fix is slower.

There is a real counterargument he does not engage. If the agent can read the whole codebase and the incident history, some of the scope problem shrinks. Retrieval over a large repo, longer context, and agents that can run the test suite and reason about failures are exactly the tools aimed at the “small frame” he describes. Whether they close the gap or just widen the frame without changing the shape of the failure is an open question, and one the next year of agentic coding will answer.

What it means for builders

The practical read for teams shipping with agents is to stop trusting the metrics the agents optimize. Coverage goes up while the tests get shallower. PR throughput goes up while review depth goes down. The leading indicators Merz offers are incident rate, time to mitigate, and the share of the codebase any given engineer can actually explain. If those are trending the wrong way while your velocity charts look great, the velocity is borrowed.

Merz closes on a claim about craft: high-quality software will keep a human touch, and the cheapest products will be the ones left to the machines. That is a bet about which segment of the market tolerates fragility. The near-term version is less romantic. The teams that win the next two years may be the ones that use agents hardest and still keep a human who understands the system well enough to fix it at 3 a.m. The incident that arrives a year after the merge is the one that tells you which kind of team you built.