Evan X. Merz

I can only speculate as to the reasons why I was laid off from Meta in May, but I suspect that one of the reasons is that I was a little bit more resistant to adopting AI/LLMs as coding tools than some of my peers. Don't get me wrong, I generated at least 90% of my code using AI in my last few months there, which was the minimum for a decent rating. But AI didn't 10X the amount of code I was writing. It didn't even 2X it.

I was focused on code quality. I saw the code being pushed by some of my peers who were heavily reliant on AI, and I saw that it was brittle code. There were many subtle issues that would lead to tech debt in the long term, and even some glaring issues were ignored by very good programmers. For instance, I saw one of the best programmers on my team try to merge code that used javascript events for mouseover CSS effects rather than using the :hover selector, which is a totally unscalable way of writing mouseovers.

Now I'm employed at another large tech company and I've fully made the switch to generating 100% of my code using AI because that's the expectation today. Still, I can see lots of people becoming aware that this isn't a sustainable way to continue development of a large scale SaaS product. 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.

In this post I'm going to list four ways that AI usage results in a fragile codebase that isn't resilient to the demands of highly available and highly scalable SaaS applications.

By the way, every word of this article was written by a human. Even though the following image was generated by AI, this article isn't AI slop.

Four ways AI makes codebases fragile

Here are the four most common ways that I have seen AI generating a fragile codebase.

1. AI writes shallow tests

One of the most obvious failures of modern LLMs is that they tend to write simplistic automated test cases that don't cover the things that matter to humans. Frequently I see AI agents writing lots of tests of get/set methods which are trivial and don't typically require much testing. When AI writes e2e tests, they tend to only cover the cases which are already covered in the codebase. In other words, the AI writes tests only covering one type of user, or only covering surface level interactions. This creates massive gaps in the test coverage that are invisible to developers because they aren't captured by the line level coverage metric.

2. AI writes overly complex ccode

AI also tends to write overly complex code. It frequently uses two or three helper methods when a single one would suffice. It tries to follow coding guidelines, such as DRY, to a fault, without realizing that the added complexity of that rigidity makes the code more difficult for human developers to debug or understand.

3. Reliance on AI decreases human understanding

And that's the third issue with AI codebases: Humans don't understand them. The longer a company relies on AI agents to generate the code, the fewer developers are going to understand the codebase. This means that developers can't do the things that are necessary to build a resilient codebase. They don't understand the data structures and algorithms well enough to see when a pull request contains a new abstraction that doesn't work with the pre-existing structures.

4. AI moves too quickly to maintain a high quality bar

AI moves too quickly for human developers to maintain a high quality bar. Each pull request comes faster than the prior one and has to be reviewed in even less time. This leads to developers skimming the code and missing crucial details that result in long term tech debt. Small quality issues like testing gaps and poorly named variables accrue in the codebase until it becomes a morass of spaghetti code.

Four signs that you have a fragile codebase

If you're unsure whether coding agents are harming your codebase or not, then you might look for the following symptoms of a fragile, AI-generated codebase.

1. AI generated codebases have more incidents

When you switched the department over to agentic coding did the number of incidents slowly start rising? At first when we were all using agents to generate massive amounts of code, it didn't seem that different from traditional coding. The PRs came and were merged and everything seemed alright. But oh, there was that one p0 that came in at the end of the month, then there were two SEVs the following month. Then even more the next month. Now, after a year or two of agentic coding, it seems like there's an incident every weekend. AI coding agents are the reason why there are more incidents impacting customers.

2. Recovery from incidents takes longer in AI codebases

Not only are there more incidents, but the incidents take longer to be mitigated. The fact is that the human developers on your team now have a more shallow understanding of the codebase. If your coding agent can't find the issue that your customers are facing, then humans are going to have to dig through a codebase that is highly complex and poorly tested. They will essentially be entering unfamiliar territory, so it takes longer for them to figure out what is going wrong. Hence, companies lose more and more money to incidents that take longer to resolve.

3. AI generated codebases create errors that are only visible to users

When humans don't spend time in the code, they fail to see all of the use cases. They fail to understand how actual humans are using the code because they aren't ensuring that the AI is instrumenting analytics and catching all the errors properly. Hence, invisible errors start appearing in the codebase. Errors are uncaught and only visible to real world users, as opposed to the types of users that are being tested in automated tests or in developer manual testing.

4. AI results in a poor user experience

And that leads to the ultimate problem with AI codebases: they weren't made for humans. AI codebases are software made by AI for AI. They aren't being tailored to the way that human users use the product, and they aren't being tailored for the way human developers need to maintain the product. The experience degrades on both the user and the developer side, leading to a vicious cycle of enshittification.

Products made for humans require a human touch

The fact of the matter is that for a product to satisfy human customers, it has to be informed by a human perspective. Nobody likes ordering from machines at a restaurant. Shopping for clothes from a website always results in worse fits than shopping in person. The same is true of SaaS products. Any time you leave your SaaS product in the hands of a machine, you are losing the human touch that is valuable to your users and your developers. This may work for the cheapest products that only compete on price, but high quality software products will continue to have a human touch. The best, most expensive products will be tailored for human users by human developers. They will be charming and enjoyable to use. They won't be fragile because they won't be primarily developed by AI.