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.

This reads like a piece of content written a year ago. Things have radically changed since then.

"AI writes shallow tests" - used to be true, not true anymore since Astra and Fable 5.1 / Opus 5.5.

"AI writes overly complex ccode" - only if you let it. A "do not overengineer it" or "Pareto, 80% result with 20% of effort" go a long long way.

"Reliance on AI decreases human understanding" - human understanding does not decrease, it just moves up a level or two. The same way you do not really understand how the Linux kernel works, nor do you know how assembly really works (with probably a bunch of exceptions here given this is the HN crowd!). And then there is hardware and physics too.

Understanding code, algorithms and data structures becomes a rarer need than it used to be.

"AI moves too quickly to maintain a high quality bar" - if you are stuck with the mantra that humans must review the code today, then obviously that statement becomes true. The problem is the assumption, not the observation. The good news about AI progressing fast is that coding AND reviewing get better and better with each release.

I know it is tough to let go. But as a software engineer, the sooner you do it, the quicker you will learn to yield a much, much more powerful weapon.

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.

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

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

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.

One of the things AI reduces is curious engineers futzing around in the codebase, which is a great way to find dead code, suboptimal structures, etc. With AI that's all gone.

After 7 months and a 500k LOC codebase I can say that in my experience the fragility is inconsequential.

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.

I read it and I wish I could agree with the points in the post, but I can’t. I love coding, I love typing my solutions by hand, but I also switched couple of months ago to AI generated code. If you do that in a targeted way, where it doesn’t have to build a "world model" of your codebase then it writes much better code than an average human being would. My codebase at work is about 220k lines of Python, Rust, C++ and some Bash. I can tell for Python it’s the best, for Rust, compiler helps a lot (some sneaky logic errors are still there though), for C++ it’s horrible (bloated sheeeet) and for Bash (well who cares about Bash ). So, what I am trying to say is, that it matters how you work with your setup and what the volumes are and if you can still keep up with proper reviews or not. I see literally two ways going forward, either full control and tiny gradual, marginal changes (like before AI) or full vibe-coding. There is nothing in between.

Code quality is no longer a concern to almost anyone since about 6 months ago. Software is a black box now, get used to it

Try using a statically typed language, refined types, and functional programming. Your tests become limited to things that are hard or impossible to assert with the type system.

My code has never been stronger.

Vibe coding taught me the hard way. These principles confirmed it: AI made it easier to create software. It didn't make production easy.

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

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.

Yes, but it’s now your job to write the standards and enforce the checks so the code doesn’t end up fragile. That’s how building with AI works. It’s been compared to moulding clay. The first pass looks rough, the second pass maybe looks a little better, and eventually you hopefully end up with something nice looking.

Whatever issues you have with AI generated code can definitely be resolved if you implement checks that provide a feedback loop.

It works differently than the additive, bottom-up way we used to write code. You will get the hang of it.

Magnus is on the record saying that even though he will lose to frontier chess engines pretty much every time, he never uses them to study because the way the engine arrives to the best move, a human can't really follow that much less emulate it.

This was somewhat the case for the proofs produced of the math problems, that leading mathematicians found them quite unreadable and abstruse; and it's been my experience when programming.

I guess there is a kind of a happy middle ground where I can more or less follow what it is doing, still having an abstract overview, and if needed, could go in the weeds to inspect something.

But people tend to opt for easy and fast, and companies will cater to that market. So who knows what's to come

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.

This is absolutely right because AI lacks Fingerspitzengefühl: https://architecturenotes.co/p/the-cost-of-ai-in-code-goodby...

I think shallow tests is the the most important issue on this list. AI works well if there's a good feedback loop. Without very good test cases and/or some kind of formal specification, the feedback loop is a haphazard, unrepeatable mess and code quality will inevitably decline.

Unsupervised AI generates a fragile codebase.

If you don't pay attention to the code, yeah, it will write code that you don't like. If you review the changes, you can prompt it to make changes that result in good code. I call that "my code".

The typing was never the meaningful part of programming.

I'm unsure if working in an area that's still cautious with respect to AI production code (aerospace) will be good or bad for me. Of course I expect that, should I stay employed in this field, I'll also be largely done with hand-written flight software within 12-18 months at most.

I sympathise with the author, but the problem is not that the agents do that, the problem is that they haven't been told explicitly what to do and what not to do.

I had to define the ideal test in my project and from then on the agents wrote exactly the tests that were needed.

And this doesn't stop at tests, but extends to all aspects of the codebase. How should code be structured, what not to do, how should the process go, tests before code or not, etc.

Over a year I arrived at a setup where I only once every few weeks have to change how an agent should do something specific. My last change was regarding how it should decide on naming buttons when creating new features. There is now a standard, a list of preferred content for specific situations and a rule on how to decide (incl. some leeway).

When told nothing, I feel the agents take it as "its fine any way, may as well be lazy".

A fragile codebase *today. What happens when the new generation models come out? Taking on debt today to move faster makes a lot more sense because the "interest rates", if you will, make the math such that new AI models can pay the debt their predecessor left. Bad tests were harmful because I had to hand fix them which meant spent time, today it just means 5 seconds for the AI model.

Every once in a while something comes up that proves beyond a doubt that 99% of human beings on planet earth cannot think for themselves. And most sensible things that human beings do, they do by following the herd or "instructions".

Easy way to start: ask AI to make the codebase more robust. Modern models are quite good at finding areas of fragility.

So many of these complaints suggest that people are accepting that the first attempt by a model is the best it can possibly do. Yes, it takes effort to guide and correct the model's output, but not that much effort.

You may not want that to be your job, which I understand. And AI isn't great at everything, and has gaps, etc. But if you are going to give AI a fair shot, don't hamstring it by using it poorly and then claiming your bad results are representative.

I understand the concern fully. I believe this is mainly because software development is currently in transition.

There was a time when all tables were made by hand. Carpentry was often seen as an art form. Every table was unique and carried something special from its creator. Then the industrialisation came; factories started making tables. The first ones had issues, but over time, they started producing high-quality tables at high volume. Today, "hand-made " still has a special place in our hearts, but it is usually seen as a niche/luxury product. When a company wants to buy tables or desks for an office, they rarely go to a carpenter to get them made.

I am sure master carpenters found (and still find) factory-made tables inferior, and perhaps they are, if we are looking for a special human touch. Unfortunately, the free economy demands cheaper, factory-made tables, so they are very popular.

Software development is just in the middle of this transition, and it is painful. It will get better soon, but the bitter taste will linger. There will definitely be niche development tasks where we ask master developers to get the job done manually. Software for flight control systems comes to mind, where every low-level instruction matters.

What do we do now? Given that the trend and demand are obvious, we can focus our efforts on making the factories better. If I may reference a couple of points from the post:

AI makes shallow tests:

The opportunity here is improving test-writing skills (AI skills) to ensure tests written have enough depth.

AI writes overly complex code

I found that TDD helps greatly here. Write failing tests first, then write the minimum amount of code to make them pass.

For me, these are how we can make the factory better. I don't think the two organisations mentioned that expect code to be developed 80 or 100%, respectively, would mind developers spending some of their time improving the team's shared skills library.

Perhaps it helps to see this not as "stopping writing code", but as "going one more level up in the abstraction hierarchy". It's similar to going from assembly to higher-level languages, although I appreciate it is not a perfect analogy.

Some of these issues can be mitigated by using strict quality checks. I'm using Uncle Bob's quality gates, which includes mutation testing, CRAP score and a couple of other things. I don't know yet if this is enough. Time will tell. I remain skeptical.

The most interesting engineering challenge of 2026 onwards is how to use AI coding tools to create a more robust codebase, avoiding the default which is a lean towards fragility.

Has anyone found a good way to make AIs generate useful tests and/or longer horizon changes like a skill or asking for antagonistic review subagents? These are the main issues behind AI code besides the unavoidable "you don't know what you didn't write as well as what you did"

So do bad developers. So do very junior developers. So do PMs when they think they can start slinging code.

You still need systems in place to ensure quality.

That in turn requires you describe what 'quality' means to you.

Then you need to design your AI-driven token factory in a way where it converges on something resembling that definition.

Otherwise, yeah. You're gonna have a bad time, until the models get significantly better.

But if you can figure that out, you can build some INCREDIBLE software. (Just look at Rex!)

My experience has been sort of the opposite. In the past 6 months I don’t think I’ve introduced a single production bug through my work, which is unheard of (for me, at least).

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.

We just need new Software Engineering books that explain how to build software in the AI age.

The test one I have seen too, one way I have had some luck with is to get an agent to write a plan, then another agent to plan the tests for that plan.

For this agent it is told to think of it as a graph and each “if” or function call, import etc as a new node.

They generate pretty detailed graphs this way. Seems to really help them with the “depth” issue.

AI in software development should be limited to security scans and maybe occasional bug-fixing. We'll have the best of all worlds: more secure code bases, happier & not unemployed developers, human understanding of what the code does, and far less money for companies that are hijacking our future by developing a god-like artificial super-intelligence.

it doesn't have to.

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.

It can generate a fragile codebase because it can leave gaps if you're not thorough.

The old adage of software development still stands "Computers do what you say, not necessarily what you mean."

But as a software engineer, this is ideal.

It would be horrible if it didn't follow the spec exactly as written because then all projects would converge on the exact same designs based on the AI's taste and it would be impossible to steer it away from slop.

If your codebase is simple, if you use a well designed foundation, the code it generates will be simple. I know because I've worked on both kinds of projects.

These rules are so true they sound obvious. It's time to start pushing back on leadership to make them aware of them.

I don't agree with arictle. For example regarding test cases, I find that it creates better tests that most ppl and it is not lazy (lazy people didn't write tests). Also it can write more tests than me, I can just give it the cases

On the other hand I've fixed some really amazingly hard technical debt issues with AI that have made my codebases less fragile, also written up end to end test pipelines, automated QA etc.

The question is, is it really a problem when letting agents rewrite everything better costs not that much.

Some comments claim that "models are getting better over time" misses the point.

What does "better" even mean? Better at following instructions, or better at fixing everything on their own? If it's the latter, it's not progress, it's the model's behavior matching your preference.

Coding itself is deterministic, but code quality and the product aren't. A better model per se might solve the former, but there's no single better solution for code quality or product because it requires judgment per case, and that judgment depends on context that is unwritten or lives in people's heads.

Code quality matters. A coding agent is faster than a human at pattern matching, but a bad codebase is going to slow it down or, worse, point it in the wrong direction.

So a better model won't be enough. We need better processes.

The article seems to repeatedly confuse product quality with code quality, as if they're interchangeable. They're not, and that confusion pretty much undermines the entire argument.

I agree with most of this, but the market will solve itself[0]. I do think the last analogy diminishes the point.

> 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 Without Oversight Considered Harmful :)

No. The lack of a good architecture and design blueprints do. This is literally the exact same problem before AI.

Business incentives create fragile codebases.

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.

> AI writes overly complex ccode

Not just complex code. AI tends to add new code. After all, AI predicts what code to write, so it happily spew out all kinds of code that do not make sense but definitely look like belonging to the code base.

I suspect that sooner or later we will run into some outage that AI can't fix because there's just so many inter-dependencies that fixing an issue turns into an infinite game of Whac-A-Mole. The question is, is such scenario going to happen in a frontier lab first or in a random company. If it's the latter, at least we can blame that the company didn't use AI well.

Imagine a junior engineer in the same position: they write shallow tests, they write overly complex code.

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.

No it actually doesn’t if you know what you’re doing.

Humans not using their own brains and relying on AI to think for them creates a fragile code base.

I say that as a frustrated slop fighter.

I can agree with the premise, but not all the details. Like, I’ve never seen a shallow test, even with models from 2 years ago. On the contrary they often think of edge cases I have missed, and sometimes go overboard in what they test for. I also have not seen them use inappropriate APIs for effects, like JS instead of hover. Maybe this is an artifact of different models? EG I’ve never used open source models for serious coding. (Interestingly, until a couple weeks ago I’d never paid for AI, all this was on free tiers; so these were not frontier models either.)

From my experience, the biggest problem is overcomplicated, over-paranoid and redundant code, especially for large code changes, like a whole feature built end-to-end by agents. If I step back, it’s like code written in a large company where dozens of engineers are writing code but no one engineer can have all the context or the code base in their heads. Which describes agents pretty well, really.

And so you get tons of near-duplicate abstractions, and dozens of guards for conditions that would never happen (but they don’t know that, and they won’t voluntarily stipulate reasonable invariants), and Rube Goldberg contraptions to fetch some data or use some abstraction when there is a convenient alternative a few source files away. In fact I see the opposite of DRY that TFA observes.

But this is also the reason why developers lack understanding… it’s just too painful to review that code. Especially if you get mountains of it, because every line of code that surprises you entails a lengthy back-and-forth with the agent, and it usually has a good reason for it, just that it doesn’t matter. And so Im not surprised that most engineers just blind ship it.

And this compounds in a big company because the next PRs that agents pile on are influenced by these changes, and so they have to handle extra edge cases, and deal with competing or conflicting abstractions, and follow similar patterns because they simply don’t know better.

On the other hand, I can also see how this won’t matter for anything but critical infrastructure code. As I said, this looks like code at any other big company and none of them have collapsed because, in addition to the always under-appreciated customer indifference, they rely on other built in processes (like customer service and security pen testers, say) to deal with the inevitable issues. And these processes are also eminently outsourceable to AI.

I do think these issues can be prevented by more sophisticated usage of agents (like adversarial review by other models) and tooling, but people are still figuring that out.

> Here are the four most common ways that I have seen AI generating a fragile codebase. / Four signs that you have a fragile codebase

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.

I think there is a new Moores law!

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

The market will fix itself.

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.

At this point I'm finding these kinds of generalizations very annoying

> 2. AI writes overly complex ccode

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"

AI coding requires a lot of care to observability and verification.

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?

Early 2025 Copilot + GPT 4o energy here.

This thread seems to be a great example of the dead internet theory.

To the surprise of literally 0 people who are actually honest about the field and not suffering from AI psychosis.

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.

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

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

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.

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.