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.

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.

Disclaimer: I have no SaaS platform, it's a mobile app.

In my experience maintenance does not suffer long term with codebase size, if anything it became easier with model advances.

Most people talking about suboptimal implementation, fragility, and maintenance burden seem to theorize and extrapolate with no actual experience in implementing a large project with AI.

I can't blame them, I see the same in my day job, but the results after 500h+ on a separate project show that the concerns do not manifest in practice.

My code has never been stronger.

1 - Done does not mean DONE. 2 - The code gets over-engineered, and you will not know about it. Unless you have a large team reviewing the AI's work. Which defeats the whole purpose. 3 - AI reviewing the code can over-review. It chases unrealistic edge cases and kills your project. 4 - Maintainability is not native to AI. It builds code nobody can maintain later.

I built a machine around the agents that takes care of these issues, and I can safely say that vibe coding made me a better builder of solutions (not a better coder).

LLM code is verbose, and often quite inflexible, but that rigidity and verbosity tends to come from the AI being very thorough about ensuring the code does exactly what’s expected, and it seems to leave much less room for error as a result. It acts as a really good forcing function for specificity on requirements, and for thinking through "what if" scenarios.

AI is great at following patterns and loves to write tests. Start with good patterns that most teams would not have the discipline to write by hand and it is possible to get very robust code.

> Shopping for clothes from a website always results in worse fits than shopping in person.

Knowing how one brand's clothes fit means that this isn't always true, and you just adjust depending on the brand. I don't understand what is trying to be conveyed here.

[0] https://news.ycombinator.com/item?id=50439062

AI is a force multiplier in whatever you apply it to. Most software companies output binaries with new features, whether it runs locally or on a server. Binaries with new features. None of the business owners give a shit about what is in the binary. It may be extremely fragile and only work for one type of user, but if they only have one type of user nobody cares. Most software doesn't keep evolving forever and at some point gets rewritten as a 2.0 version or whatever, so the quality was never as important.

It doesn't have to be that way. You can use AI just as effectively to produce quality source code as you can slop binaries. It depends on the business priorities and what is actually important.

The caveat is if you are the one engineer on the team trying to use AI the right way to produce quality source instead of binaries as fast as possible, you might get left behind or let go since your work no longer aligns with the business.

I say that as a frustrated slop fighter.

Also, stuff like JavaScript event instead of using CSS like :hover is easy to catch and fix. You just can't start being lazy

What do you do? You provide guidance, support and tooling so they can write better tests and code. You supervise and help them meet the standard. It is the same with AI agents (including the challenge of how to carry that knowledge around and transfer it). You are responsible.

You are also responsible for the understanding part: know what is being worked on, glance at changes, inspect the outcomes, cross-check specifications, tests, product requirements. The 'moving too quickly' idea is the other side of the same coin; it is your responsibility to keep track of things and decide what's worth intervention. The exact same thing happens in a project where you have ten developers (or 200) working together — you cannot possibly read all of the code they write.

Seeing all of these as downsides is a choice.

Every six months, the number of people capable of writing code better than AI is halved! :D

It would be nice if the listed symptoms (which have their own issues, e.g. "AI writes overly complex code" - overly complex for who?) were backed up with numbers or at least case studies, rather than stating "this is how you can recognize that X is happening", then stating "X is happening" in the title.

100% this is my experience; I frequently am telling the agent 1) "this way is simpler", or 2) "why are you doing X instead of Y, which is simpler"

If the article is correct: AI generated codebase creates incidents that are more severe and take longer to recover from, companies will dial it back after they get burned bad enough.

If it's a skill issue: Maybe some coders can push the frontier out even a lot more than others before such things happen. Then the problem is the human in front of the screen.

If you can’t measure the problem, is it really a problem? A lot of assertions about code fragility seem to merge in with bike shedding arguments about style and what one person sees as readable.

But in the end if you have 100k of slop but we can know with high levels of certainty it does what it needs to - does it matter?

If you feed back everything you had to fix with abominable intelligence generated code into your memory files, you'll end up with a pretty good prompt baseline that will steer the given model towards proper code generation.

It's good he gave an example because I frequently encounter these "fragility" arguments at work and it invariably turns out to be a giant F nothingburger. This was way before AI as well. Some type of people just cannot see the forest for the trees and this is a good example of that.

No mention of where this mouse handling took place but in my experience It Just Does Not Matter, but let's say it does. Let's say it's some super important bit of UX that suffers terribly from this approach.

I understand, I'm a dev. I'm familiar with how little things can matter. So sure, the mouseovers are implemented in a strange way. It causes issues in practice and not just in theory (which is IME 1% of cases), well, redo them. You think that takes more than an hour? If so, I question your ability to function in this job. Actually, document how mouseovers should be handled because apparently it's so important. This will never happen again. Think about the process, think about how you can prevent this. Don't focus on tiny little instances in time causes by tiny specific human beings, focus on the general, the universals. Everything you wrote shows me you are severely incapable of doing that. The fact you even focus on mouseovers and not on bigger issues shows me you have a questionable ability to allocate your scarce - it's scarce in all of us - cognitive capital.

Your fragility points all can be handled by skilled use of AI tooling. It's really F easy as well. "AI writes overly complex code", really? That's your point? Come on. Tell it not to. Instruct it, shape the process. Define your terms, document your ideal code style. I guarantee you it's better at it than you are once it knows what you want.

In my practical experience your points are all false:

1) Our AI-driven products have less incidents 2) They are (way) easier to reason about 3) I don't even know what point 3 is going on about because devs famously only look at code and don't think about the end-user at all resulting in famous dev UIs 4) They all have a (much) better user experience, we're talking orders of magnitude like a different - more capable - company produced them

Sure, I hear ya'll geniuses shouting in unison our devs suck and you all could have done this in 5 seconds and are so, so superior, but guess what? Even if what you say is true, and it's not, you are few and far away and out of reach for us lowly regular businesses.

On code readability, shallow tests and general quality, I can agree emphatically, though not universally. In other words, there are models which write the densest, hardest (for me) to parse code and tests that break with the lowest load/timing deviations yet proof less than nothing.

These do that regardless of how much one ships in my experience however so I wouldn’t attribute this to the velocity and more poor data at the heart.

I know this reads a bit like “you are using the wrong model” and I understand if someone testing e.g. an OpenAI models understandably extrapolates across all models and considers poor parse-ability in code a likely result of velocity, but you can always step back and work slower, plus, for what it’s worth, I struggle to parse OpenAI code when running their models through my evals after step 7 which is still a fairly measured in scope code base.

Essentially, I have seen LLMs, even the newest frontier, produce barely legible slop when building simple CRUD and I have seen a massive rewrite of the existing Firefox code base using APZ to enable an infinite canvas of browser tiles grow in a manner where, even at this stage having replaced a lot outside Places and Gecko, I can walk through changes made and explain the logic, as well as look at any part I haven’t been in for a while and find my bearing even without assistance.

Whatever model you use, however much you trust it, if you can get a grip and explain what something does, that puts you in great shape. It also, for what it’s worth, helps future changes by better models to land with higher token efficiency and accuracy. I have put Opus 5.5 into a GPT-6 Astra written code base and it could land features, but the rework the model did along the way was eye opening. I then repeated, explicitly enforcing no changes beyond the initial scope which Opus 5.5 still could succeed in, but took far longer, far more tool calls and significantly more tokens then that change should have taken. I also have examples where any model can be more error prone and slower than myself, though those are unique and I myself have been told I was using the wrong model and sucked at prompting.

Use models like any tech if you want for what you feel comfortable for or don’t, both can yield good or bad outcomes. I was and still am an enthusiastic Flutter/Dart dev, which with pub.dev meant I drew in a lot of external packages of dubious quality and compatibility, that I never read. LLM output, I do read and can go beyond my manual contributions in understanding because of it. Doesn’t mean model use doesn’t enable me to do more. Code was, for me, always a means to an end, enabling something. That hasn’t changed and never needed more LOC or massive scope.

I think speed is the biggest flaw though. If i could get variable speed while planning vs building, thatd change some things. I run local models, so i am mostly in the slow lane. When patching these flaws, i want it to read the code parts and diagnose quickly.

When its coding, i want to see the problems its encountering with the prompt. I usually observe its thinking a few rounds and if it misunderstands, i redirect.

But in all of this, i want a dial that just speeds up once i feel its doing the right thing.

SOTA today, to me, would put a model floor like qwen3.8-flash-next on a platform i can dial up the speed. Thats all. I think many of us will bring our own harness, so the only hard point is how dumb the engineers tools are.

Since im building local, my tools do a lot more management. So.e of tge opinions i see on HN trigger a "skill issue" reflex because we have a whole shopping mall now if tools and the incurious seem oblivious to how these models are used by cloud providers.

Learning about the raw capabilities of LLMs makes getting them to "do the right thing" is now just a job description.

Lastly, the last decade of tech oligarchy exposes how little education elites had about humanity and wicked problems. Elon musk reinventing public transportation several times ignorantly. The fact that a social program requires the consent of the people it helps. LLMs are a stark lesson in the difficulty of knowing all the constituent parts and still being unable to predict outcomes.

Welcome to Socioligy 101 tech nerds.