A Meta engineer was laid off for resisting AI coding—now he warns it builds fragile codebases

I think looking at AI usage for code and development from an engineering perspective is going to be an exercise in frustration. I'm a software engineer for 20+ years and I've pivoted to using AI for my code 100%. I find it invaluable about the only way to stay relevant and run a business nowadays. Happy for anyone to disagree with me, because I don't want to be right for the first time in my life.

That said, my experience tells me that enterprise and business coding has rarely ever been about stable or robust codebases. We engineers and a fraction of competent engineering managers and a vanishing small number of directors fought against business interests to ensure quality was priority when it came to code, but it was always an uphill battle and we were oftentimes disciplined for spending too much time on quality and design.

A timed cadence of release is anathema to quality code because you can't timebox it.

So, AI is just the extension of that. Do I try to ensure my agents design code I would consider to be good? Yes, absolutely! But I've fully outsourced it and I find it's also fully capable of fixing it's own mistakes. I've gone far beyond anything I individually or even with a team was ever capable of with AI assistance, so I believe I just have to apply my experience and skills into management and architecture rather than actual lines of code.

Time only will tell how this plays out.

Wallaahu aʿlam.

I've been saying this for a while. Programming has been unbelievably underestimated, almost as much as art (i.e. everyone thinks they are an artist when having opinions but rarely understand anything about it).

Programming is about engaging with high level mathematical abstractions.

To the extent AI can do this high level thinking, it is going to be able to do absolutely everything else humans can. Programming (when not underestimated) is as hard as the hardest cognitive task humans can do.

Code quality is not an issue.....until it is. Everyone will be happy if things seem to be working and moving fast, it's only until you start seeing symptoms like not being able to change things without breaking existing features or even seeing an increase in tokens burned for reading complex code bases that you will start caring about code quality (which i imagine now people will just have AI try to fix it's own mess).

I think we're going to see more efforts made in static analysis / linters.

> 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.

Alright, can static analysis find the mouseover JS events and fail a linter as a result? Maybe in the past this would have been overkill or would have triggered very rarely if ever, but in an AI-written codebase, this helps catch it and point the agent harness to rewrite it.

I'm not sure that "AI generates..." articles are going to age well.

My immediate question would be what kind of adversarial reviews and deterministic gates did the author write to capture the dimensions of maintainability (lack of DRY, cyclomatic complexity, unclear naming, poorly architected flows, etc) that they cared about.

Don't get me wrong. When I was speeding along at 200 PRs a day (personal projects - I would not have inflicted them on others) I pretty quickly slopped together a big ball of mud, but as I'm re-generating my estate (a) the models are a little better but (b) I'm adding a lot more rigor around verification (correctness, performance, security, operational costs and maintainability). It's not an easy problem to solve, but it feels to me like an engineering endeavor, not speculative rocket science.

I fully understand that many AI generated code bases do indeed suffer from more incidents and less maintainability, but I think it's important to distinguish between what is common and what is possible as the fix for one is improving the rigor of your verification whereas the fix for the other would be either accepting crappy code or giving up on LLMs.

I don't think this matters anymore. Software is becoming a black box and agents make it works, as long as you can provide some reasonable spec of what you want to do, and a bit of supervising and directions.

Right now, they're not great at following good software engineering principles. They do the job, with verbose code, lots of duplication, abstraction leaks, useless unit tests and so on.

Is it an issue? you could think that in the long term it'll be, that AI won't be able to handle the complexity it introduced, but I'm not really worried about it. Most software isn't that big, and agents are getting better by the day. And if you really care about design, it's not too hard to instruct your agent to follow your standards.

I wish it wasn't the case and that I could justify my experience and expertise for a few more years, but the facts are there.

I just went through development hell using AI. I'm creating a game as a side project, using codex, and I changed my mind about the name of the project a couple of days into the dev cycle. So I renamed it and all hell broke loose.

The moral of the story is try to have the final name of the product from the beginning. It took me a whole evening to resurrect upon renaming and it's still not fully cleaned up.

I don't disagree with the article but it may give some readers the impression that pre-AI hand-written code wasn't fragile.

Here's the famous commentary about Oracle RDBMS codebase of 25 million lines: https://news.ycombinator.com/item?id=18442941

Every big company codebase with millions of lines devolves into a similar state. The small codebase starts with clean conceptual integrity. It then inevitably decays into incomprehensible spaghetti code as more people are added to it. Various reasons for it including the later devs caring less about the code than the initial team of devs, deadlines, avoiding refactoring because of fear about breaking things, etc.

If you don't want AI to create fragile code, you have to apply the same quality gates that would have been applied to pre-AI hand-written code to keep everything clean. Most companies don't do that.

Pure speculation here, but this is a thought that occurs to me. I've often seen furniture used as an analogy for how quickly an automated process can displace craftpersons, but I think it might actually in one sense be an analogy for how craft can continue to survive and thrive even post-automation. Sure, Ikea sells a LOT more furniture than Ethan Allen; but Ethan Allen's handcrafted furniture is much higher quality and sells at a premium price.

Consumers benefit all round. Those who can afford to do so can buy the high quality handcrafted product; the majority who can't get cheap access to acceptable-quality furniture.

This is pure speculation but I wonder whether software will gradually evolve in this way with the availability of AI. For many basic tasks, consumers will be able to basically write their own software using some AI tool; it may not be high quality but at least it will be cheap and fast to produce and it will greatly reduce the barrier to access for the average computer user to do what they want to do on their machine. Meanwhile, a much smaller niche market for high-quality tools that have been at least partly handcrafted by experts to fill some special need where performance or a quality experience are crucial will continue to thrive. Either way, in this scenario, I would imagine the importance and prominence of SaaS will slowly decline.