Former Meta engineer argues AI-written code makes SaaS codebases fragile

The post is an opinion essay by a software engineer, whose name the text does not give. The author says they were laid off from Meta in May and now work at another large tech company. They can only speculate about the reason for the layoff, but suspect it was partly because they were a little more resistant than some peers to adopting AI and LLMs as coding tools.

The author does not claim to be an AI refusenik. In the last few months at Meta they generated at least 90% of their code with AI, which they describe as the minimum for a decent rating. At the new employer they generate 100% of their code with AI, because that is the expectation today. Still, they say AI did not 10X the amount of code they wrote, and did not even 2X it. They focused on code quality, and saw peers who leaned heavily on AI push brittle code with subtle issues that would become long-term tech debt. Even very good programmers let glaring problems slide. One example: one of the best programmers on the author's team tried to merge code that used JavaScript events for mouseover CSS effects instead of the :hover selector, which the author calls a totally unscalable way to write mouseovers.

The central claim is that AI solves problems that fit inside its context window very well, but is oblivious to long-term issues that cannot be understood in that small frame. The author then lists four ways AI makes a codebase fragile for highly available, highly scalable SaaS applications.

First, AI writes shallow tests. It produces many tests of trivial get/set methods, and its end-to-end tests cover only cases the codebase already covers, such as one type of user or surface-level interactions. That leaves large coverage gaps that line-level coverage metrics do not reveal. Second, AI writes overly complex code: two or three helper methods where one would do, and guidelines such as DRY followed to a fault, which makes the code harder for humans to debug or understand. Third, reliance on AI lowers human understanding. The longer a company relies on AI agents to generate code, the fewer developers understand it, including the data structures and algorithms needed to spot a pull request whose new abstraction does not fit the existing ones. Fourth, AI moves too fast for a high quality bar. Each pull request arrives faster than the last and must be reviewed in less time, so developers skim and miss details. Small issues such as testing gaps and poorly named variables pile up into spaghetti code.

The author then gives four signs of a fragile, AI-generated codebase. One: more incidents. The post sketches a pattern in which a p0 at the end of one month is followed by two SEVs the next and more after that, until, after a year or two of agentic coding, there seems to be an incident every weekend. The author states flatly that AI coding agents are the reason for more customer-impacting incidents. Two: slower recovery. Humans now understand the code less well, so if the coding agent cannot find the customer-facing problem, they must dig through highly complex, poorly tested code, and companies lose more money. Three: errors visible only to real-world users, because humans who are not in the code fail to ensure the AI instruments analytics and catches errors. Four: poor user experience. The author calls AI codebases software made by AI for AI, not tailored to human users or to human maintainers, which leads to a vicious cycle of enshittification.

The essay closes with a prediction. Products that satisfy human customers need a human perspective, the author argues, and leaving a SaaS product to a machine loses the human touch. That may work for the cheapest products that compete only on price, but the best and most expensive products will be built by human developers and will not be primarily developed by AI. The author also notes that every word of the article was written by a human, while an image in it was generated by AI.

Key facts

• The author says they were laid off from Meta in May and only speculates about why; they suspect resistance to AI coding tools played a part.
• They generated at least 90% of their code with AI at Meta, the minimum for a decent rating, and now generate 100% at another large tech company, yet say AI did not even 2X their output.
• Four causes of fragility: shallow tests, overly complex code, fewer developers who understand the codebase, and review that cannot keep pace with AI speed.
• Four symptoms: more incidents, slower recovery, errors visible only to real users, and a degrading experience for users and developers.
• No data or study is cited; every claim rests on the author's personal observation.

Why it matters

Many companies now expect engineers to generate most or all of their code with AI. The author reports that expectation from the inside: at least 90% at Meta as the bar for a decent rating, 100% at the current employer. The post argues the long-term cost shows up later, as tech debt, incidents and a codebase fewer people understand. It is a first-hand account of a worry that many engineering teams share.

Who it affects

The argument is aimed at engineers and managers running large, highly available SaaS products. Reviewers feel it first, since the author says pull requests arrive faster and must be reviewed in less time. On-call staff are affected too: the author says incidents take longer to resolve when humans understand the code less. Companies that mandate AI code generation are the implied target.

How to use it

Treat the two lists as a checklist for a team's own codebase. The causes point to things to inspect: whether AI-written tests only touch trivial get/set methods or already-covered cases, whether helper methods and abstractions are heavier than needed, and whether reviewers have time to read each pull request. The symptoms point to what to track: incident count, time to mitigate, errors that only users report, and whether analytics and error handling are in place. The post offers no tool, price or formal method.

How solid is it

Weak as evidence, useful as testimony. The author's evidence is personal observation: no data, study, statistics or incident metrics are cited. Several claims are stated flatly, such as that AI coding agents are the reason for more customer-impacting incidents, with no figures behind them. The incident timeline is an illustrative sequence, not a measured case. The author also says the layoff reason is only speculation. The text does not name the AI tools or models used.

Risks and caveats

The author has a stake in the story: a layoff they link, tentatively, to their stance on AI tools, and a current job that requires 100% AI-generated code. The main example, the JavaScript mouseover code versus :hover, is a single anecdote, and the text does not say whether that code was merged. The closing prediction that high quality, expensive software will not be primarily developed by AI is a forecast, not a finding. Readers should weigh the essay as one engineer's view.

“AI tends to solve the problems that can fit within its context window very well, but it's totally oblivious to the long term issues that can't be understood in that relatively small frame.”

— The post's author, on evanxmerz.com