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 can imagine things like this happening very easily mid/long term: https://www.reddit.com/r/ClaudeCode/comments/1xq2n3t/a_year_....
As of 2026, I think LLMs still lack vision, and long term, tend to build a very scattered codebase, if maintainers don't pay a lot of attention.
LLMs do have cognitive limits as well!
Discussion (though topic has been flaged): https://news.ycombinator.com/item?id=50433079
But AI doesn't care. It can, and it will, happily churn through a messy codebase.
Do you have examples of where this actually worked for you? How large was the codebase, how long did you have agents generate the mess in it?
I ask because my experience is pretty different, even with Opus 5.5 and Astra - unleashing agents on a messy, vibe coded repo only seems to increase the mess. The agents just slow down more and more as they keep generating further mess, they make more and more incorrect assumptions based on bad code previous agents left behind, and I grow more disappointed in their capabilities every day.
Actually reviewing all agent output thoroughly is the only effective way I've personally found of working with agents. In order to ensure that every line of code they add is actually there for a good reason, and not organized in a way that future agents will miss it, or misinterpret it. It's the only way I can prevent them from producing worse results as the repo grows.
I find myself desiring simplifying a codebase just because I still need to make so many decisions and the cognitive load of that has gone up with how much I can do in parallel and still keep track of.
The promise of Agile is that you can release quality code on a regular tempo. The features may not yet be fully polished but you can drive small incremental releases with some set of correct+desired behavior and focus on improvements to critical areas and robustness in longer arcs as long as the core does the thing you really need it to do. Sometimes you have to come up with an equally incremental path towards the Big Refactor you want, setting up dominoes cycle after cycle till you can knock them down at once, but it can and has been done. You still need to prioritize quality and may have to be political about how you do it, and you still need management buy-in because you will not move as fast as a team throwing things against the wall -- but you'll also never actually hit a wall, or if you do it will be more of a speed bump, which is the selling point.
Edit this really has nothing to do with AI. This can be done 100% by hand, 100% by massively parallel agentic swarms, or anywhere in between. It's about process, planning, and the people (yes exclusively people) involved.
I don't think any of this changes with AI, the only thing is that it's possible to handle much more incidental complexity. Ultimately I expect it to land on a similar equilibrium in terms of software quality that is gated by what the users of the system will tolerate. The more things change, the more they stay the same.
Most businesses and developers shouldn't be innovating, but instead providing secure solutions to their clients. The last 30 years of "innovation" has given us countless security bugs.
I’ve been in the industry for a much shorter period than both of you; but the companies I worked for didnt really innovate anything.
But since AI writes everything anyway, innovations that improve “developer experience” are pointless, and all the other low hanging fruit has been taken.
I still code by hand on some personal projects and for CodeCrafters to keep myself somewhat sharp, but when it comes to paid work, my soul is devoted to Orca and running multiple Claude sessions in parallel.
My partners are happy.
Right now, management has velocity so it’s happy.
Earlier they got the code understanding as a default, and it was never something that made a difference to their metrics.
The success of the LLM Code model then relies entirely on the ability of tech debt to be cheaper to solve in the future.
My biggest issue with AI is not really technical debt, it's engineers losing sight of the system's internal working. This can make it difficult to reason about the code, fix bugs or security issues.
I just don't think we have the tools right now for engineers to accept software becoming a black box.
AI can generate "confidence" only in very limited amounts. It can help with testing, but that becomes very expensive and hard once we leave the realm of tests that can be simply written with code, like unit tests. At some point, the only way to increase the confidence in a codebase is actual testing with actual, real user interaction. And once that's maxed out, the only way to further generate more confidence is to get it into production and let real users (not test users, production users) find the remaining bugs no tester and no AI ever managed to hit.
This is the sole reason why AI doesn't make code "disposable" - yes, it can rewrite any codebase far more quickly than any human, but that new code will start at low confidence values - AI cannot transfer the confidence that the old codebase achieved simply due to being smashed against reality in production use to the new code it writes.
This is also the reason why it still makes sense to maintain libraries, even though AI could not just theoretically, but also practically write a lot of functionality from scratch that we usually import into projects via open-source libraries: the newly written stuff doesn't come with the same confidence as the already-battle-tested library does.
The problem is that oftentimes code is the only real record of the system design and specification. That creates problems because it’s harder to replace obsolete code and modules. You can try to reverse engineer a spec from current behavior, but that always leaves uncertainty about what behavior is intentional and what behavior is accidental and changeable, and because when the system behaves in surprising ways there’s no clear source of truth on if it was supposed to do that.
What I see with LLM coding is that it makes it easy for people to “at of one” a project, and armies of one tend to produce few artifacts other than the code itself. This, ironically, makes code less disposable by eliminating any sort of thoughtful, detailed record of design intent. The code itself becomes the only record, so modifying or replacing the code needs to either replicate the original code as close as possible, warts and all, or take extra care in reverse engineering and analyzing the original code to try and understand if any simplifying changes can safely be made. Which doesn’t actually happen very often because it’s a lot of generally unenjoyable work.
Which, in turn, is why LLM codebases tend to accumulate bloat at a higher rate.
But that's only valid in the industry though. Most of the software I'm using are free software, created by passionate people who used to care about quality because that's their name on the label, their reputation as an individual, their badge of honor, and also that's what makes us all feel good at the end of the day.
So, if I have few expectations from the quality of commercial software, I'm genuinely worried that open source authors would adopt AI generators too. Of course they will, I know I did. It's hard to resist. The speed gives you the fun you've lost writing good code your way.
Is code generation going to ruin the quality of open source software? I actually don't think so. I believe the benefits in terms of finding bugs (next postgres release will be the best when it lands!), conversions into better techs (finally, that old buggy python tool that's so convenient will be rewritten to rust or something), and we will have more new ideas, more people trying more things, being more ambitious etc.
Actually, it reminds me of when I transited from assembly to C, and even more from C to OCaml, for my personal projects: for a while, it was not fun! I was unhappy with the memory layout, with the GC, with the 31 bits integers, I could hear the bytes screaming at me: "come back and take care of us" and felt guilty. But, on the other hand, I was no longer typing kilometers of repetitive boilerplate, and had more time to think. Coding was no longuer typing at the keyboard, but more about thinking about designs and abstractions, and it felt both wrong to leave so much in the dark but also appealing to be able to think bigger.
And that's a bit of the same when driving an LLM: you have to spent much more time than usual designing, specifying, spelling out everything that matters; in one hand you feel that it would be faster to type the code yourself, but it's actually not true because you have an LLM to discuss the design with; whereas left to your own devices you would type and type for nights a design that you will revise several times over, rewriting most of everything several times. Now "coding" starts with a lengthy process of arguing with Claude until a good design is written down, recursively down to some good amount of details, until you can unleash the agents and voilà, you have it all done and working the next morning.
And there is some pleasure in that, too.
I'm worried for the users, for the workers, for the citizens, for myself, but not for the programmers part of us: machines will still be fun.
Using AI to generate something that had no value in first place is just silly.
"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.
No doubt code quality increased substantially, but I've been wrestling overengineering for a long time, with both GPT/Claude - they will take any small chance to write excess code/documentation/specifications, anything - they seem to love reinventing the wheel. Heck, even prompts sent to subagents are walls of text.
Explicitly requiring simple solutions works for simple problems, but for more complex ones, complexity quickly creeps in. I even ask the alternative model to challenge the complexity of solution, but doesn't work really well.
There is a perverse incentive for AI companies to train models to be verbose, as it increases the tokens consumption.
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.
> "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."
I wrote a tool at Meta to use AI to solve all those issues at scale. I don't necessarily think it really solves the problem, although I'm unsure about the reason (perhaps that's why they got rid of me!). There's something about codebase brittle-ness that isn't captured with those well-known, easy-to-catch quality issues. It could be related to architecture, design patterns, or something else that's a little larger than even the largest LLM context windows right now.
I think code validation is an interesting problem. It's like judging "rightness", which is an inherently subjective thing in all except the trivial cases.
It would only be part of the answer but the most striking thing to me is that AI lacks the inherent sense of minimalism most humans have because creating code is so hard for them. It's so hard that a large part of our initial thinking will simply be to minimise the solution down to the least possible change from current state.
AI tools do have a little bit of this but I think it's heavily in conflict with more recent efforts to increase their persistence and the scope they can undertake and length they can work on something. All these have been optimised to hill climb coding benchmarks, but put against the benchmark of "are you sure you really need this at all? Couldn't we do it a simpler way? What if we just did it X way and then we only need to change 10 lines of code" - they are not even being tested against this metric.
I've always thought that good engineering should go smoothly by definition. You shouldn't be juggling a ton of bugs and broken develompent pipelines. The problem is justifying this in a work culture that doesn't care about quality and is stuck looking at numbers that can be immediately justified.
We will just repeat the same pattern, have the latest and greatest frontier models rewrite the software just like how many desktop monoliths moved to React SPAs.
The real winners are frontier labs, we pay them to write black box software and we pay them to rewrite the software.
I saw a youtube comment a few months ago that has stuck in my head, can’t remember the exact wording but it was something along the lines of “I’ve never seen an industry so excited to cuck itself out of a good wage”.
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.
And further, surely you know some very strong programmers who are very bad at art, or math, or human relationships?
Even after all of the resources it takes, it still needs human guidance. At the very least the conclusion is that it's not doing what humans are doing. They might know all the programming languages and all kinds of domains but then it needs to be told basic things to not fail at simple prompts.
Part of the problem is that this is very hard to talk about and describe. It requires a long conversation, probably better in real-time, to explain exactly how AIs are not really living up to the hype, and are actually introducing long-term risk by using them.
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.
For a different perspective, the european peers in my developer network, while never outspoken against their company, like, and redistribute content that circle around the same points. Some have fixed mandates to use AI, in order to use AI, working more to keep the product stable (even outside normal work hours), or complains about the divide between management and developer's perspective on these tools.
There is also some consideration about compliance issues and liability when you're stamping commits with your name (luckily for almost all software enginners there is no malpraxis law to punish gross negligence).
For context, I work in a big tech company with virtually unlimited tokens on the best models, and a lot of tools integrated in our workflows. The culture makes it impossible to go against the wind. Even if you don't want to use AI as much as others, you won't be able to prevent them to do so.
I have had experiences out of my technical depth where I’ve instructed an agent to do something technically nonsensical. The agent tried to do it, creating a mess. Nothing works, I get frustrated, only to realize I have a fundamental misunderstanding of something technical.
A similar thing happens when you ask for something, but the complexity for the perfect solution is 10 x the complexity of a simpler, 90% solution. And sometimes you only realize that looking at code (or feeling lots of brittleness)
You're trying to middle road it. He was talking about actually treating it as a black box, so just give the model your expectations and goals it needs to meet, not tell it a rough solution for it to apply in detail.
The expectation/goal approach in a ai edited project works better then the middle road since opus5.5 ime. Depending on your project structure, it may not be viable however without large refactorings
Other times it will one shot things near perfectly that I was expecting to just use as a reference. Demo pages for work I've done its so fast and gets good enough right out the door
Every time I've tried to use it to write something small in my compiler? :"( pain. It's the perfect intersection of looks good and covers 90% of cases fine but explodes far away because some subtle invariant is wrong. I can't always think of the invariants up front without writing the code myself
But to preempt a "I can't do that in my brownfield distributed monolith I'm maintaining at $dayjob": yes, that's why I said it may not be possible without refactoring.
My point is that you can ask for unrealistic outputs even if you’re treating the system as a black box. This is the classic case of higher level managers asking for infeasible results from their engineering team because they haven’t considered they’re trying to solve the wrong problem. Depends what you’re doing but I don’t think agents tend to push back on badly specified goals unless you’re proactive about it
But what happens when your Node runtime, OS, compilers, or even libraries start regressing to the same lower-quality level? Everything starts collapsing and falling apart. That matters.
For the last 20 years of my career, I have prided myself on keeping a clean codebase, making 'art-not-science' decisions of when and what to abstract, scope boundaries, then implementing them cleanly, specifically to be easily grok'd by other developers. But after building, from scratch, and operating an (essentially) vibe coded software solution (in typically a very engineer led/low level space) over the last 9 months, I am still able to move at super-human speeds in terms of delivering features, investigating and fixing any issues (there aren't many, certainly less than most human teams I've been in) - whether that's because of AI advances or just their innate quality of being able to tackle the dross coding tasks that always got avoided by humans in my past I'm not sure but I'll stick with it until a better approach becomes apparent!
I feel my specialist skills (coding, debugging, devops) has been devalued - I can't justify holding those as my value-add proposition any more - but new skills are replacing those (context/AI/agent engineering) in equal measure.
And you’re right, with a bit of direction and further prompting it’s quite easy to get your code in a reasonable shape. So that is what I do now: the agent does all the work but I still whip the output in shape.
Mostly my hope is that at some point soon the agents will start writing clean code. But then again, maybe clean code for a galaxy brained agent is not the most optimal code from a all-in token efficiency perspective.
That’s more of an artist thinking than an engineering thinking, favoriting elegance (cleanness, readability) over practicality. This was not really valuable even though you prided yourself on doing so. It’s like endlessly gushing on the design aspect of the report (the medium) instead of just providing a well-written one (the message).
Code is a medium, and being an artist about it can feel good, but the information processing mechanism (the message), is what’s important. If, after using AI, you can’t reason about the mechanism (nothing about code, files,…), you can’t essentially justify anything about what happens in the software. Meaning data given to it has a non-zero chance of giving garbage answer.
> but new skills are replacing those (context/AI/agent engineering) in equal measure
This is still highlighting surface activities, not anything pertaining to engineering.
No one is going to want "organic software" for their Node runtime, their web browser, or their OS. Some things just need to work, and work efficiently, 99.999999% of the time.
Depends on use case
You definitely can use those things to improve both speed and code quality at once. But then your speedup is while quite noticeable not astronomical of course. Also the work isn't easier (apart from less typing), just different.
Doesn't seem like a good strategy to me.
Using AI is one element for a pipeline that produces code.
If you architect well what you generate then it stops being slop and starts behaving like a cohesive system where code is produced automatically.
So, no, you will never be able to produce code automatically. You can and certainly should use AI as a code assistant to write code faster, but the human should always 1) make all important architectural decisions and 2) carefully review the outputted code
The human bottleneck is necessary.
So the system accounts for mistakes and has protocols for removing bad modules/code.
If part of the system go down the rest will remain functional
Edit: and yes audits are part of the pipeline
This obviously won't fly for "serious" software such as airplane software, but I'm willing to guess that even customers of a low-stakes SaaS would get pissed off if your product regularly turns up new bugs.
I think it's easier to just do code reviews...
Both me and LLMs are constantly auditing software.
In-fact auditing and QA is mainly what I do now and human audits become much easier when it's scoped to modules.
You cannot do that with humans either.
The types of mistakes LLMs will make are failures of alignment, that is, basically unpredictable. They could fuck up anything. Where a human fucks up by introducing a crash, the LLM fucks up by just not solving the problem you asked it to solve.
It will happen less and less as they get better and better, but as the volume of software output keeps growing, it will happen with a consistent defect rate. And we won't be able to catch it prior to shipping, because humans won't be able to review all the code or verify all the tests.
I don't think anyone's started taking this seriously yet.
Gen Z has learned that usually, your dedication to work is not tied to the monetary reward.
> Where a human fucks up by introducing a crash, the LLM fucks up by just not solving the problem you asked it to solve.
Have you ever done a group work project at school?
the problem is that the "architect well" part is also being left to the LLMs
That's exactly the strategy that most companies have adopted by now.
Once you go 100% AI code generation, there's no going back.
Picture a foolish person falling out of a hot air balloon.
"Gosh," they think, plummeting, "the balloon is going upwards SO fast!"
“it would have taken me days/weeks/years/… to learn and produce something by myself”.
reminds me of all the PHP spaghetti code that would float around because it was "quick and easy" -- eventually that all becomes brittle and someone has to come in and rearchitect it from scratch
you may not pay the price, but your successor will
but then again, you could say that's your employer's problem, not yours (and you'd be right)
the biggest problem is the future, not the present. Presently, we -- you, I, others -- still have the skill and experience to look inside the box and understand it, guide the LLM to make smarter decisions, etc.
not only will those skills atrophy in ourselves, but the younger generation won't even develop them in the first place. eventually you have almost no one who understands anything about how things work, they just know how to issue high level commands. It's like if eventually everyone working at CERN just knows how to push the buttons on the LHC but doesn't understand much beyond that. That's where we are heading.
This raises alarm bells. It's a deeply unserious take on software development that I hope doesn't spread (but I know will). YOLO it all.
We absolutely will regret the slop AI, as it will become load-bearing (ahem) in short order. There will be critical outages and people will die.
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.
Not really? A lot of companies have comparable codebases that are kept in check.
Service-oriented architecture helps at this scale by forcibly creating boundaries.
The shift in thinking leads me to believe that the real reason HN hated contracting out the code was the fact that you had to pay the contractors for their work.
And I think the outcome will be the same in both cases: we figure out how to outsource effectively. In fact, many of the same strategies we developed then are applicable now.
> 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.
Assuming you mean an average software developer, that's still an incredibly low bar.
Todays companies are full with average software devs but they take 10x more hours to implement something, then miss 3x more edge cases while costing way more money.
So yes... and?
My futzing around is now at a higher level and involves enlisting the help of agents to dig through the code and logs and other sources to help solves problems.
Right now I am working an effort to reduce the amount of "build friction" across our code base. Even scoping this out would have taken a non-trivial amount of time and fixing it would never have been funded. With the help of AI tools, I can now attach this problem and make the lives of hundreds of engineers better.
A good lithmus test I've noticed is "I want to do this thing the system should do", and if claude identifies a major refactor - well that's a sign the code needs a human touch first.
it's not gone, it's literally a prompt away. I run "tech debt" loops all the time, ask it to simplify the code and architecture, remove left over code from previous refactors.
the quality of the resulting code is better than ever
We'll have to wait and see how many companys get hurt by overuse of AI coding, the one I work at included.
I also don't think this is the right way. We are giving away practices and lesson learned over decades, in just over 6 months without fully understanding long term implications both technical and non-technical. And that is based on very optimistic bet that models will be able to handle all those potential issues that we might be concerned about in present. All the arguments/counter-arguments are mostly speculative, and I think only time will tell. My speculation is that this all BS will at some point self-correct at some point, it wont be like pre-LLM but it wont be crazy vibe-code don't look at code (or pretend we review code) either.
I thought it was a pretty insightful point coming from a 16 year old boy (being a former 16 year old boy myself).
I think this is the place where a lot of "coders" are now, they only cared about the manual part of the job which is gone.
What's different in software is that developing software always kinda was building and designing factories spitting out copies at the end (while actually creating and distributing the copy increasingly being the easy part). So in this profession you have a split between people who were actually only in for the manual part of building the factory while you have others for whom the manual part always was just a means to an end. With the purely manual part gone there is still a shitton of work left which is in the end a lot more complex and challenging than mere button pushing but it's different work.
I think this is a very small part of the population, if anybody. Craftspeople, perhaps definitionally, are people who care about the work of making AND the results. This is true for many many devs.
But they do still need the job shop machinist which fill essentially the same niche using slightly different tools (mills and lathes rather than forges and hammers). Is your 16 year old implying that LLMs are the programming equivalent of a mill/lathe in metal working?
The bill for the API usage was _hundreds_ of times higher than the subscriptions. Companies with a few hundred engineers, but without sky-high margins, simply cannot afford not to understand their codebases.
"An agent wrote the code" is not an excuse for failing to understand how the system works and fits together.
We all may end up ignoring the source code most of the time. But for a few years at least, we won't be able to ignore the quality of it, because nobody knows how to use "AI" in a way that has stable high quality over years of changes.
Being able to speak to what’s possible or not will definitely be a valuable skill.
Hopefully when the cost of tokens rises and your company can no longer afford to pay for it at the level needed that someone will be willing to keep it running.
Also: syntax is for humans, might as well use LISP AST syntax for all future languages since no human is going to read it anyway.
Another note: some software has a history of multiple decades. In fact, I happen to work on such software. IMO it would be irresponsible to turn the code into an incomprehensible slop fest just because some AI boosters want me to believe that "coding is solved" or "software is dead".
Code quality is no longer a concern to almost anyone
Well, one engineer decided to take a look at the code and found one file was 20,000 lines long. It was an awful mess with too much going on. So much for "AI governance". I knew this was going to happen but these guys don't want to hear anything about being cautious with AI. The solution is always more AI.
I am looking for a new job.
For now there's still human reviews but soon it will be all automated. I estimate that the AI review (latest Opus) is around 15% to 20% accurate
I remember the "software craftsmanship" movement of the early and late oughts. Refactoring patterns, clean architecture and all that--nobody outside a tiny group gave a single sh*t about it.
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.
Also, sharing a link would be great if you're comfortable with the idea.
I'm still in the process of launching the app, it went live just two weeks ago. So far only 30 users, I have not yet started the ad campaign.
Basically I don't look at the codebase at all, I have long stopped using the IDE or doing code reviews.
From a product perspective, there have been no big surprises. Only once I was surprised to see a feature I thought I implemented only on a specific screen being available on a different screen too, hidden behind a drag gesture, spawning an UI component I totally did not expect.
While that seems like a loss of control, it's not too different from enterprise work with many contributors where I am also not aware of all changes.
About maintenance cost, no, I do not think so. It generally became easier over time since Opus 5.5 delivers better results than GPT-5.5 did.
From a token perspective, a large part of the resources go into translating to 30 languages and checking the screenshots for layout regressions.
Sorry, but at this point you have no idea what the maintenance looks like.
Can you explain to me how I would develop the project for 7 months and grow the codebase to 500k LOC without maintaining it at all?
The argument seems nonsensical to me, but I've been getting that comment a few times on HN.
At 30 users you have no idea what maintenance looks like. That's literally what maintenance is - responding to real world usage.
Come back with your experience when you have lots of users that stick with your app, you're putting out fires and implementing new features. Your experience will be meaningful after 6 months to a year.
I'll wager that right now you have a PoC that needs a lot of work to be something that retains users. That's not a criticism, that's just how it works for every startup.
I have a pretty good idea about what maintenance looks like. Particularly so about the technical aspects of how effective the models are at refactoring or fixing bugs.
Even if I were to accept the argument that users would have entirely different expectations for my app than I do, it hardly changes the fact that I already know I can easily implement large changes in the code base.
"Maintenance" does not mean "development after the first week".
I did not ask for your opinion.
Come back after running your mobile app for at least 6 months in the real world with real users and then we will talk about maintenance.
Codebase has never been better and healthier, and any tech debt that has been accumulated after a few releases can be removed in a few prompts when you are out of product ideas and have some free tokens to spare.
(I added US mountains and trails btw: https://fescims.com )
<Error> <Code>NoSuchKey</Code> <Message>The specified key does not exist.</Message> <Key> releases/e17a06bd04efe2b18bb38c0ae905a4d7db7ac863-42361807812-1/en/challenges.html </Key> <RequestId>7RNT6H476HS6B22H</RequestId> <HostId> YZf8hkSztCkLmtCZ01b7L4ufaujln4rD7qmakrvPWcIqTpmUwexzkW9UJWta5YJnszCS7qkdGmPFyfC9na3L6As7skPPnu2f </HostId> </Error>
Even if I ended up with a project of 50k lines, that would take multiple times the effort it took me to get this app ready for the initial release.
Realistically, I wouldn't have finished the project at all.
Let me tell you the story of the developer trying to reduce the number of tokens they use. It was a moonlit night, only the faint spinning of a Noctua fan audible and our intrepid developer...
It doesn't happen often to me. If it does, I find it often handles extra edge cases I only would have found by using the customer as a guinea pig.
Oh, for sure.
I'm assuming the GGP's system can be expressed in 5k to 1k lines of Java or Kotlin.
Where else did you think they came up with the "10x developer" thing?
(Yes I know LoC is a useless productivity measure, that's just a joke. Obviously it's number of PRs..)
But in doing so, you will also 10x the features delivered. Maybe 5x, who knows?
But you definitely won't have to go through and decimate the generated code as a rule.
This reminds me of Moore's law in the 1990s.
If you program ran slowly, or used too much RAM, you could spend six months optimising it (or removing features). Or you could just sit on it for six months and release it as it is - hardware moved on so fast that, by then, it probably ran successfully.
Your suggestion is a bit like this: don't worry, the pace of model understanding will catch up faster than the code will get disorganised.
I'm not saying I agree but it's an interesting idea.
I have seen all those when running a fairly new eval inspired by something I read in the ts-rust repo, giving a simple GPT-6 Astra code base to Opus 5.5.
Implementation accuracy was higher and token usage lower when Opus 5.5 got a Fable 5.1 built code base of the same feature set and coverage compared to the fragile GPT one. Incidentally I struggled to parse the latter but not the former.
Yes, a modern model will happily work on the most unmaintainable slop (doesn’t even need to be LLM derived slop, we have all seen bad Human written code) and that is great if you have an old code base to maintain. But if one can avoid it, even if one uses only models and never looks at the code, being efficient has value. Heck, rewrites are doable and affordable now, I have restarted projects and the gains were quickly apparent, even if we just look at model usage efficiency gains.
So you're right. Without AI the average lazy developer would write 50k implementation lines of code and 0 lines of test code, and now they have 450k lines of test code in addition to their 50k of implementation code. It might not be great test code, but I know which I'd still rather have (hint: the tests).
how many users do you have and how long has your app been out there?
unless that number is very large, then you have no idea whether your app is fragile or not
example: I own a Polestar 4. Great car, love it. I have non-deterministic SW glitches. Other people have non-deterministic SW glitches, but they're not the same ones as me. Other people never encounter any glitches. Others have tons of glitches that I don't have. Every new car that is sold, is another edge case. We had a Tesla for years, and the SW was rock solid, great stability. Why? Because their SW has been out there for over a decade with millions of experience points, and they have a large team that are aggressive about fixing and rolling out updates almost daily. Until you get to that point, you can't judge whether your vibe-coded app is stable or not.
I did; that's why I wrote what I did
> the one hundredth 'you need a million users to judge maintainability' comment
make you should take it that there might be some truth to it then
“It’s not a code base that warrants that size, it’s a mobile app”
“Fragility is inconsequential to me and I am blind to my users dealing with it”
At the current pace, the very idea of maintaining software will become as relevant as the idea of trimming wicks, stropping razors - or making every frame you take with a camera count.
When the marginal cost of replacement drops to a sufficiently low level, the entire paradigm changes.
I say this as someone with 30+ years of development experience, who built everything to be maintained until the heat death of the universe. I just don't think it's a relevant question in this brave new world.
Digital cameras are another interesting one. Since capturing images is so cheap we just snap a bunch of frames without a lot of thought towards composing them carefully, with a side effect that we get an overwhelming amount of mediocre frames and a few good ones, but we have to sift through.
I’m still not convinced I want to make this tradeoff in programming. But I work in scientific computing where I think it’s (still) really important to understand what modeling assumptions you are making through code
i'm working on a fairly complex application and it's not even near 200k loc. but this is the second version - the first was vibe coded and was over 400k and full of bugs/issues that were slowing down development. i rewrote it and it's half the size, half the dependencies, and much faster & more robust.
is it more complex than your app? hard to say since neither of us want to disclose our identities :)
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.
This felt very out of touch for the reason you brought forth: hand-crafted products very often become more valuable in an industry where production is done at-scale. (Provided the hand-crafted product is of high quality.)
We’ve discovered a way to take what someone asks for and generate a lot of relevant code at a significantly lower cost than what it would take to contract out. Maybe for small requests this could be fine for users in the future, but inevitably people will prefer carefully-crafted codebases that provide robust experiences or high reliability.
My code has never been stronger.
Step 3: Prompt the agent to write mutation tests to harden the suite
Step 4: Prompt the agent to write property-based tests.
Step 5: Prompt the agent for 100% code coverage
Step 6: Keep a look out for small issues with steps 2-5 above and refine a Skill or Rule to package the workflow and plug gaps in the model's current shortcomings.
Step 7: Dedicate some time to manually reviewing and thinking about interesting edge cases worth testing.
---
If you follow these steps, you will have better test coverage than 99.9% of any code an engineer ever wrote pre-AI... and it will be almost completely automated.
My team's incidents and bugs are DOWN this year while we're shipping more.
Leveraging AI effectively requires a new paradigm of interaction. The name of the game is to use techniques and strategies and guardrails that create an environment that produce good software.
I don’t think anyone has figured out the proper solution yet, I personally try to get the LLM to write code similar as I would have written it myself.
If you mean asserting against hardcoded literals, then that is the preferred testing shape in most cases. And for good reason.
If you change production code and a unit test fails, that is useful. Idk why that's silly. If you want to test more complex interaction write a UITest or integration test.
I honestly think we're all living in different worlds. There's probably large differences in capability on a per-language, per-team, per-codebase, per-engineer environment that are producing wildly different perceptions in output quality.
And yes everyone works in different domains. I work at a database vendor myself, so mostly lower-level work.
I’m very happy and successful with LLMs, I just don’t think that these “just move all your tests to your type system!” or “get 100% test coverage” rules are an answer in the long term as we haven’t yet figured out how to do this well.
I personally treat tests as components that need to be well architected, maintained, and adding them risks increasing technical debt and needs to be treated as such.
I was describing general strategy, that when applied in concert is more than the sum of its parts.
E.g I mentioned property-based testing, that is another angle at which a test avoids assertions that are too fine grained.
I think it has much more to do with overall architecture and design, and as for now, human oversight.
just curious, and tempted to do the same, so far I don't like the code made by llms in dynamic languages codebases
Another of the shallow arguments thrown around, similar to "we don't check compiler output so..."
People learn and improve. LLMs don't learn, they follow instructions to a degree.
A human has to wrestle with it to work how you want, ergo humans are necessary already.
You can't fire the LLM and hire a competent one. The few available is all there is, they're all copies of the same thing.
You don't have a team. If you think 10 LLMs = a team of 10 people, then you don't know what a team is, how different skills and views make a big difference to outcomes.
LLMs can't innovate. They can't come to you with a great idea they came up with. They don't have ideas.
If none of these things are worth anything in your particular case, then that's ok. But let's not actually lose our minds and forget why people are intrinsically better than machines.
There are only a few arguments to support using LLMs, all of which are from people who a) want to spend less on salaries or b) sell you LLMs.
Teams are often hierarchical where the leaders define everything and people under them have less things to say about it. Not much different than an LLM team.
I do a lot of LLM coding and I catch about one of these per week. But I still look at the code after the LLM writes and reviews it. So I'm going slower than most on here, so my default assumption would be theirs are doing this more often that once/week. Whether or not it matters depends upon your project.
My favorite one from the last month was the LLM designed monster hit points in a way that everyone is healed to full between combat. No, it was not intentional, HP were just stored in a way that the structure storing it completely disappeared outside actual combat.
The belief that AI can do all that without the gates is throwing away something useful where people get to understand how the system is changing. If you keep the gates but use AI to generate all the code you either slow AI down to the speed of humans or you end up with a massive backlog of stuff to review.
This is a hard problem.
They aren't going to be creating 100 liabilities/hour?[1]
--------------------
[1] Each line of code added is a liability. We appear to have forgotten that.
Not saying it's better or worse. But it's definitely different.
My first startup was building requirements management software for small businesses to solve that exact problem. Devs add things in all the time. It's usually referred to as 'gold plating' or scope creep.
In general any type system is designed to prove things. So all I'm really saying is "use strong types to prove more" which is irrefutable.
Type systems are not a panacea. You still have to be logical and careful about them, especially around boundaries where types are just assumptions and not logical inferences. Then you have functions that switch type, but only a subset of the input is actually valid (string -> int for a number parser). Checking for NaN is like checking for Null.
Type systems does help, but they need the same attention as code to be actually helpful.
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).
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.
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.
Eventually unsupervised code leaks because you stop reading the 3rd (+1200, -350) pull request
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
It can only simulate the written outcomes of intuition in its training set.
For sure, some of those written outcomes are a good guide to reaching the outcomes of intuition.
But the likely uncloseable gap is that some intution is unspoken, literally felt by the brain's default mode network and by parts of the prefrontal cortex.
LLMs basically never shower, do the washing up, kick their foot in the dirt while sitting on a park bench with a coffee: the domain of the default mode network. And they never sit frustrated looking at things, guided by their long experience, with the itchy brain feeling that there is a solution before they can even say the words.
A lot of this stuff happens to us deep down, way outside of the reach of words. And as a result, some aspects of intuitions are just never described in words.
I'm sure the training data of LLMs contains a lot of those things, though.
But they are not the things themselves — they are incomplete representations; just words that approximately describe the application of that intuition to the problem at hand.
Think about how you visualise complex code projects in your mind — how it's not quite diagrams or buildings or words but multiple things in a sort of multi-dimensional, itchy space that is satisfied when a really good implementation appears. Think about how often the code you have built retains that wordless shape long after you wrote it down. Think about how impossible it is to adequately describe it.
The downside: the model doesn't always have words to describe what it's feeling.
Those outcomes are more easily averaged and we are after all talking about artificial intelligence. And for a coding agent… perhaps this is the right tradeoff.
I just think it's important to note, every now and then, that words aren't feelings or thoughts, and that an author's next book cannot be calculated from only the words of their previous books, etc. Basically we should understand that the reasons why we can't generalise from "it can design processors, write code and solve maths" to "so human-expert-quality writing and web design should be easy enough" are probably rooted in differences like these.
(as it would apply to a human software engineer also)
Compute > Insight. Every time.
We can keep searching for essential human characteristics that humans have and AI lacks, but every attempt increasingly resembles an ego-preserving negotiation with the inevitable march. It's reminiscent of the God of the Gaps[2], but for human exceptionalism. As AI competency encroaches on more and more of human ability, we'll retreat into smaller and smaller gaps - foxholes of inimitablity.
As long as human value is justified by ability, quality, or characteristic, this problem will endure. The one escape hatch is the classical liberal idea that human value isn't tied to anything, that, by virtue of being human, people have universal, inalienable worth.
We should stop the project to attempting to substantiate human value by other means.
Now it's gone. Spec-driven dev isn't the answer either, some of the UX bugs areas are simply not something that ever existed in the regression suite.
Then in that CLI I have a thin front end that just parses args and calls the backend that does the work.
I test around this backend. As a kind of behavioral test.
I rarely mock, and only at some external API boundaries. I may enumerate those (they’re only 2-3 things) the tests call my code via the backend, and I can verify more easily visually the test measures something meaningful. Moreover they map cleanly to the business logic of this module.
If testing becomes brittle I can converse with my agent and show it a bug via the CLI. It can repro more easily, and with a cleaner mapping between the CLI and my tests, I can confirm it tested what I expected.
Writing modular, verifiable code was always an engineering tenet - but the use of AI in codebases that ignored those foundations ends up having several gaps.
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".
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.
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.
Sorry, but that transition already happened. A long time ago. It was when compilers replaced hand-written assembly.
What we're talking about would be more like the design phase, where someone prepares the molds and tooling which will be used by the factories to make the tables. Even that has already been partially automated, with CAD/CAM on physical manufacturing, and IDEs in software development.
The current usage of LLMs for software development, has AFAIK no analogue on the physical manufacturing side, so we can't reason by analogy there.
Tell me again where there is NO widespread automatic consensus about how imperative is that one HAVE TO use these things from a sandbox?
The last time this happened was when the whole world agreed that it is alright to take a device with multiple cameras, mics AND 24x7 internet connectivity to our most private places...
My answer so far is to dedicate a substantial token budget to continual polishing, refactoring, debugging, cleanup and explanation. Some practical steps:
1. output has to be perfect. Anything that looks even slightly off get's logged and a session is started to investigate, this usually leads to a bunch of other issues.
2. Ask the AI if the code works the way you think it does -- you should still have some model of how the software works in your head
3. Ask for documentation and explanation around interfaces and make sure you understand the interfaces. It's ok if something's a black box, as long as you have a good understanding of what goes in and what goes out.
4. continually ask for performance improvements and assessments.
5. In addition to agents and readmes, maintain an ADR so all decisions and past constraints are readily available to be enforced on new code.
6. Put in as many hard rules as you can about things that need your explicit approval.
Fundamentally, my current job as a "AI-native builder" (cringe) is way more similar to my previous position as EM than anything resembling an IC.
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!)
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.
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.
So terse and flexible code can't be made to do exactly what is expected?
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.
>Coding itself is deterministic, but code quality and the product aren't.
I agree quality matters, but the writing is on the wall. It's only a matter of time before the frontier labs are training ultra-long-horizon software engineering tasks using agent teams in RL training loops that help the models essentially figure out what they're currently missing. It's going to happen. I think human judgement is needed today, but not in the limit. It's learnable. The only thing is figuring out the training loop to teach it. That's all.
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.
Try:
- Clearly identify the invariant being tested focus on exercising the invariant
- High volume, low signal tests increase CI and build times
- Avoid low signal tests; raw coverage is not the objective
- Avoid write-then-read tests when risk is low (no transformations, no business logic in application code on write or read path)
- Use explicit test execution [Explicit] when test code is used to exercise code in local environments only and should not run in CI
You also need to understand why agents write high volume, low value tests: because other ways of exercising the code (e.g. Playwright, E2E, curl) are even more expensive and not as consistent. So you have some recourse here by: 1) giving agents another way to exercise the code (e.g. provide it a REPL to your code) or 2) tell it to write some unit tests as explicit only (does not run in CI).
For our tests, we also added a small helper library[0] that cleans up tests to make them easier to read (smaller context for both humans and agents) as well as to write. Agents write average code by default. Your job as an engineer in this age is to help agents write good code.
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.
> 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.
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.
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.
I say that as a frustrated slop fighter.
Every once in a while I go "manual". It's restful and entertaining to write syntax by hand. It has this peculiar dare I say autistic delight, sorting the colored blocks and getting a little kick out of it. I understand the nostalgia but the progress is breathtakingly slow - as expected. You cannot do 6502 assembly by hand and expect to be fast in any meaningful sense of the word.
I usually juggle four, five active projects at a time and make days worth of manual progress on them in a morning. Support calls and colleagues questions interject occasionally. It's much more work than before, but I like it because dev work is super boring and now it's getting more interesting.
Like many people try to say AI is raising the bar. What we call normal software now will be childrens' toys tomorrow. The world expects ambitious projects, stuff that is hard and stands out.
Is this not incentive enough to use AI more thoughtfully?
This would be at the level of helper functions < 10 lines of code.
That part was obvious, no need to explain it.
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.
When I do the same with an LLM, I'm just repeating the same guidance over and over again out of frustration just to get something done.
Comparing an LLM to a junior engineer is frankly a disgrace.
For that you need to actually read the code and it's somehow in odds with the whole vibecode idea.
Plus it won't give you the 10x boost the management expects. Only not looking at the code will.
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.
Every six months, the number of people capable of writing code better than AI is halved! :D
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.
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 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?
Also, stuff like JavaScript event instead of using CSS like :hover is easy to catch and fix. You just can't start being lazy
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.
The problem isn't fixing it. The problem is detecting it's a problem in the first place.
Stack this with dozens of over "1%" cases and you're in for a world of hurt.
So yes it doesn't matter. But it also does.
This reminds me a bit of security at our company. "Technically I don't need to escape that because it's just an integer." My response always is: technically you don't have to, but technically every dev who reads it needs to check that its an integer. Make the code obviously correct.
You often find issues “in practice” when your users find them. User trust is a limited resource that does not currently scale with LLM code generation rates.
> 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.
I (somewhat, it will choose its own path at odd times) agree, but the rate that it generates code dwarfs mine, so it’s generating issues “in practice” at levels I could never reach. AI + human is going to beat either in isolation in all cases, and I don’t see this ever changing until they can read our minds.
At my company, we have a “10x” AI team that doesn’t read the code. They had a lot of clout until they launched and were reprimanded for a staggering number of issues ranging from technical bugs to weird UX choices.
I’m not sure if their issues were caused by not reading the code or not knowing what they don’t know. Based on personal experience, if I stopped reading the code it would cause similar issues in my app, so I still read the code.
> hear ya'll geniuses shouting in unison our devs suck
The software world is huge. I’ve worked with devs who spent their whole careers in relational dbs and never heard of isolation levels. Entire modes of failure they don’t even know exist. I imagine they’d see code and claim it’s great where others would see the holes. And both could be right: there are business domains where it doesn’t actually matter.
The range of takes on LLMs is downstream of this diversity.
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.
In interviews, he admitted that the Hyperloop was intended to mess up the California High Speed Rail project because trains are boring. It's the opposite of ignorance, it's malice. Hanlon's inversion.
As much as he's malicious, he's also rediculously stupid in conception.