Laid-off Meta engineer argues heavy AI code generation breeds fragile codebases

A first-person account from Evan Merz, a software engineer who says he was laid off from Meta in May, is drawing attention after reaching the Hacker News front page. His central argument: heavy use of AI code generation did not multiply his productivity, and it actively produced brittle software that becomes harder to run reliably over time.

The account from inside Meta

Merz is careful to label his explanation for the layoff as speculation, but he suspects that being less enthusiastic about AI coding tools than some peers played a part. By his own description, he was no holdout: in his final months at the company he generated at least 90 percent of his code with AI, which he says was effectively the floor for earning a decent performance rating. The payoff, in his experience, was limited — the tools never even doubled his output, far short of the larger multipliers often advertised.

Quality is where he saw the cost. Code from heavily AI-dependent colleagues, he writes, carried subtle defects destined to become long-term technical debt, and obvious problems sometimes slipped past very capable reviewers. His example: one of the strongest programmers on his team tried to merge code that handled mouse hover effects with JavaScript events instead of the CSS :hover selector — an approach that will not scale.

Merz frames the root limitation as one of scope: models handle whatever fits inside their context window well, but they are blind to longer-term problems that cannot be understood within that narrow frame.

Four ways AI weakens a codebase

According to the post, the damage shows up in four recurring patterns:

• Shallow tests. AI writes many trivial tests, such as ones exercising simple getters and setters, while its end-to-end tests tend to re-cover scenarios the codebase already handles. The resulting gaps stay invisible because line-level coverage metrics look healthy.
• Overbuilt code. AI frequently splits logic across two or three helper functions where a single one would do, applying principles like "don't repeat yourself" so rigidly that the added indirection makes the code harder for humans to debug and understand.
• Shrinking human understanding. The longer a company leans on agents to write code, the fewer developers genuinely know the system. Reviewers lose the familiarity needed to notice when a pull request introduces an abstraction that clashes with existing data structures and algorithms.
• Review speed overtaking depth. Each pull request arrives faster than the last and gets less scrutiny, so reviewers skim, miss crucial details, and let small defects accumulate into serious debt.

The symptoms in production

Merz also lists warning signs that agentic coding is harming a codebase. He recalls incident frequency creeping upward after adoption: a single P0 near the end of one month, two severe incidents (SEVs) the following month, and — after a year or two of agentic coding — what felt like an incident every weekend.

Recovery slows too, he writes. With only shallow familiarity with the code, engineers responding to an outage are effectively navigating unfamiliar territory, dragging out mitigation and raising the cost of each incident. He adds that errors increasingly surface only for real users, because nobody verifies that analytics and error handling were instrumented correctly, and that the experience degrades for both users and the developers maintaining the product. His conclusion is that such codebases lose the human perspective that quality software depends on, and that products built this way serve neither the people using them nor the people maintaining them.

Worth noting

The post is anecdotal: a single engineer's observations, offered without supporting metrics, and Merz himself presents his layoff explanation as a guess. Notably, he says he now generates 100 percent of his code with AI at his new employer — another large tech company — not by preference but because that is today's expectation, which underscores how entrenched the practice has become regardless of his concerns.

Why it matters

Even as one person's account, the piece names failure modes that engineering organisations adopting AI agents can check for directly: coverage metrics that flatter weak tests, review bandwidth shrinking as pull request volume grows, and institutional knowledge draining out of teams. Those dynamics compound quietly and tend to surface late — as rising incident counts and slower recovery — which is precisely what makes AI-driven fragility easy to dismiss until it is expensive. If Merz's figures reflect broader norms, with near-total AI generation now the baseline expected of engineers, the defensibility of a codebase depends almost entirely on the testing, review and instrumentation standards a team chooses to enforce around it.