AI usage generates a fragile codebase

Early 2025 Copilot + GPT 4o energy here.

Why would the author use an AI slop image for this article. A literal house of cards. What?

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

AI is farming. It produces lower quality crop (for now) but in abundance. So it wins.

People the very least need to learn how to write memory prompts for their specific use case... Seemingly everyone is running with defaults or 100k+ stars skill abominations. My granma used this because important AI person said it is the way, look man it has 100k stars, it mussbegood!

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.

AI non-usage brings about irrelevance under pressure from competitors with fragile codebase.

I am literally right now undoing a bunch of slop code because of this. We had a gateway/bff pattern (basically, bff when we only have a single frontend atm but plan on developing others in the future), and this service's whole job was querying CRUD APIs on other services, marshalling/trimming their responses to just what the frontend needs and serving it. One of our other devs has been Claudehopping around, too focused on shitting out new features as quickly as possible and not paying attention to how it's done, and now several of the calls to the gateway have it accessing the DB directly via repository classes while others are calling existing services. That's fine except I have to change the way we filter things now. Had he and Claude actually stuck with the pattern it would be a single change in one of the services behind the gateway but now I need a bucket and a mop for this WET ass programming because I have to change it at the gateway level AND at the service level.

> used javascript events for mouseover CSS effects rather than using the :hover selector, which is a totally unscalable way of writing mouseovers

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.

We shouldn't worry about that. We should be grateful about the mountains of technical debt, because that will be the social security of the post boomers generations: working till death fixing the last hurrah of the boomers.

I do agree with some parts but not others. Reverting a flawed changed, e.g. should have never been as difficult as I have seen it been in some orgs before the advent of LLMs. Same for poor UX landing, both are issues that sure, may be thrown into sharper relief now, but were issues in some code bases and not others and remain that way today. More over, they are issues which can be permanently addressed in the former and in the later are one of the key sources of differentiation today.

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.

The silent part is "undirected". You can patch these holes by observing them and the author us aware. By itself, these are the flaws.

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.

[flagged]

[flagged]

[dead]

[dead]

[dead]