Rendered at 18:16:18 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
basilgohar 23 hours ago [-]
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.
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!
soperj 18 hours ago [-]
the thing I've found that's produced the most productivity is actually reducing the size of our code base. Makes it way more manageable and easier to add features/fix bugs.
I'd guess most code bases you could reduce by about 50% without losing anything at all.
nxobject 8 hours ago [-]
With luck, SWE culture will change towards caring about large-scale rearchitecture (and reward those who care enough to refactor and polish, polish, polish.)
HPsquared 6 hours ago [-]
It's all about massaging out those tight spots and untangling knots. A bit like kneading dough, perhaps, or annealing metal.
0x696C6961 5 hours ago [-]
I don't think this will ever be appreciated or rewarded.
HPsquared 5 hours ago [-]
Yeah that's basically craft. Craft and beauty aren't usually rewarded unless it can be used for marketing.
everforward 6 hours ago [-]
I’ve toyed with the idea of splitting a deeply nested tree of code into separate libraries for this.
First impression is that it’s a net negative. It gets a lot better at working within that library, and much worse at making it work within the project as a whole.
rcxdude 6 hours ago [-]
I think the opposite is probably the way to go: strip out some layers of abstraction, try to keep them to only the really valuable ones. In my experience LLMs are better at dealing with more concrete codebases.
It's also a lot cheaper to experiment with different abstractions within a codebase to really get them right, and especially to evolve them as the codebase changes.
BobbyTables2 14 hours ago [-]
I recently found Opus is pretty good at consolidating very-similar-but-different codebases.
Sure, I had to tell it to so, but it trudged through and did it fairly independently… Was especially nice as refactoring test infrastructure code isn’t always very exciting…
dimitrios1 18 hours ago [-]
Which again is ironic, because I've been doing that for most of my career whenever I am introduced to a legacy code base: The first thing I try to do is delete code. I think it's just good engineering practice to try and delete code as much as possible.
Cthulhu_ 8 hours ago [-]
Yeah, the best practices for software engineering haven't changed, it just feels like a lot of people forgot about them for a while.
rustystump 12 hours ago [-]
You would lose something but it is because the trade off in complexity isnt worth it. This is the key to keep code low. If there is a thing that is barely used but is 60% of the code, maybe it can go? Ai will try and keep it backward comp forever.
HPsquared 5 hours ago [-]
Backwards compatibility is the biggest source of complexity, I think. Although it does alleviate another type of complexity that results from incompatibility.
AI also produces very brittle code through overfitting. A human will look at an issue and produce a generalized solution, an AI will look at it, in vastly more depth than a human can, and see that in combination with this over here and this there and that over there and this thing and that value, here's a fix that will work. However if any of the other conditions that it's identified ever get changed in the future, the whole thing will break. I've seen this overfitting again and again, solutions that cleanly fix the problem but depend on so much of the rest of the code base and/or data being in a particular form that it breaks if anything changes.
hgomersall 10 hours ago [-]
Right, the thing I find it does really often is to replicate policy through more than one mechanism. For example, this week, I was working on a const structure in rust that i needed to be able to serialize in a const context. It implemented the calculation of the serialized string length independently from the serialization string. It would certainly have worked, and probably for a long time, but it opened a potential bug route that I never would have created. This was on a single module.
eddythompson80 8 hours ago [-]
Just last month I asked someone on the team to add some alerts. We like everything to be declaratively defined in the repo and we push metrics, and we have an alerting system. We just needed some plumbing to be able to define alerts that get created or updated on every deployment. I said to start lets add an alert for X metric, then we can take it from there.
He took the instructions, plopped them into an agent, generated ~400 lines of change that add the alert. The problem was the entire 400 lines were custom for that X metric. Meaning if we needed to add a second alert, it’s another 400 lines. The entire thing is generic plumbing and defining resources. Any reasonable engineer would make it so that the second alert to add would be 2 or 3 line change to just define the metric and its alerting threshold (and whatever other parameters for the alert) not re-do the entire setup every time for every metric. I felt stupid having to explain that to another senior engineer.
tonyedgecombe 5 hours ago [-]
To be fair to your colleague (and the LLM) making things generic too early is a bit of an anti-pattern as well.
szundi 20 hours ago [-]
[dead]
hmry 11 hours ago [-]
>The part that actually hurts is who is left.
Another AI-generated post complaining about AI? Or maybe the author just started writing like Claude themselves
myk9001 7 hours ago [-]
That reddit post is written from the perspective of someone who's actually pro AI ("It felt great for about 6 months ...") and only realizes retrospectively they ended up in a mess. So there's no internal inconsistency in the narrative.
Anyway most of reddit is dead internet and that post is just engagement farming... As is most of hn.
Digit-Al 9 hours ago [-]
The author specifically claims to have written the article themselves and not used AI, so you are basically accusing them of being a liar. You might want to be a bit more cautious about committing direct defamation. Just sayin' :-)
geodel 21 hours ago [-]
Since AI agents are free and unlimited in a sense. Companies would be assigning a dedicated agent to a service full time that would keep a long term memory of project design, decisions, history and all. It'd be 10x cheaper and 10x faster (at least thats the thought). They will have their own titles Agent, Sr Agent, Principal Agent, Staff Agent and so on.
pennomi 5 hours ago [-]
At least leave the bureaucracy to humans. It’s the only thing we have left.
discreteevent 20 hours ago [-]
Most of the comments encouraging people to disregard quality are from accounts only a few months old.
FWIIW Quality was always cheaper and quicker for anything but a prototype. This is just as true now. The problem was that many people were too lazy and unfocused to make quality work and those people are only too happy to agree with these comments
xyzal 11 hours ago [-]
There is too many businessmen and too few hackers in here
hypfer 10 hours ago [-]
If it is even that and not just someone's LLM pretending to be one.
senordevnyc 18 hours ago [-]
What exactly are you implying with your strawman here?
csomar 9 hours ago [-]
> Most of the comments encouraging people to disregard quality are from accounts only a few months old.
I noticed that too about a year or so ago. It's unbearable that made me pretty much leave the conversation. I am yet to see a codebase written by LLMs that is half decent. Also, I am unable to generate any decent codebase with LLMs without massive handholding and later refactoring. But maybe that's a skill issue and am holding the genius wrong.
I suspect many people are under AI-psychosis, conflict of interest or were simply introduced to tech very recently.
gmueckl 6 hours ago [-]
One thing I learned is to establish as much guidance up front as possible. One shotting something more than a few lines of change isn't sustainable without additional guidance. The best flow for me is to have it generate a draft plan in a file, add copious inline comments, have the same session process them, repeat until plan is detailed and only then give the go signal.
It still goes wrong when there hidden gaps that I don't spot in the plan or when the LLM decides to abandon the plan halfway through (rarer these days). But it's still not as bad as giving a single prompt and hoping for the best.
Of course, all of this only works if you know what you're doing and what you want and can/cannot accept in your codebase.
ChrisLTD 4 hours ago [-]
Sounds reasonable to me. And that’s very different from the parent and grandparent comments that assert they don’t look at any of the code at all and just have agents buzzing around writing and fixing everything autonomously.
seizethecheese 13 hours ago [-]
Are you suggesting anyone who doesn’t agree with you is a shill? Generally a convenient and comfortable fiction. (There are shills here, when my tin foil hat is on I sense geopolitical ones, but advocacy for AI coding is pretty widespread.)
t43562 9 hours ago [-]
There's no need to be a shill to have a different perspective on something from the people that do it. Management do usually forget about how programming works even when they did it themselves before - I know because it happened to me.
Businessmen are what ycombinator is about and there must be some of them here. Their motivation is to sell and AI is one of the sauces they can put on their business-burger to make it sell better. Why wouldn't they be enthusiasts?
qudat 18 hours ago [-]
I think AI is an invaluable tool as well. I also think it’s an addicting tool that dramatically changes how we think, some positive, some negative. For example, outsourcing all your thinking to gen ai has already burned colleagues.
This tool, like anything that has addictive engagement loops, need to be used with discipline.
I’m already hearing whispers of corpos reining in ai spend. What happens when your budget goes from 2k/mo to 200 per eng? What happens when that 200/mo cost turns into 500?
There is absolutely no way that becoming addicted to gen ai is good for the individual or the collective ecosystem.
I’m confident we are in a hype cycle and things are going to level out once we fully grasp its limitations and see it as great for knocking out boilerplate and tedious tasks
keybrd-intrrpt 16 hours ago [-]
> What happens when your budget goes from 2k/mo to 200 per eng? What happens when that 200/mo cost turns into 500?
Models are getting more capable while becoming cheaper every day.
New open-source or open-weight models are being released every few months, and are very cheap on cloud providers or can be self-hosted.
Hybrid multi-agent workflows or developer/reviewer work styles have already emerged and proven to produce great code quality while driving down costs.
Not everything is about one-shotting the latest OpenAI or Anthropic model on xhigh.
qudat 16 hours ago [-]
Agreed but if the industry moves to local models, 1T valuations go pop and with it the economy.
I find it hard to predict what will happen to swe after that.
chii 12 hours ago [-]
> industry moves to local models
that would be an ideal outcome.
Today's cloud-locked models you pay a subscription to to use is akin to the old AOL internet.
crimsoneer 5 hours ago [-]
I find it slightly mad that people are arguing this. Do you maintain a local datacentre for hosting? Do you store all your data locally? If you're a business of any size, the answer is probably not, because it's inefficient for some random company to manage servers. That is not going to suddenly change with LLMs and GPUs.
keybrd-intrrpt 14 hours ago [-]
1. That's an entirely different problem
2. They try to make up for it in volume. Which is why they want to wedge AI-usage into every aspect of work and life.
You don't need 1 dev spending $2000/mo if you can get 2000 people spending $1+ per month
t43562 9 hours ago [-]
They must be spending some of those hundreds of billions on trying to convince people to do this. Advertising has to work at least a bit until everyone works out whether or not the product is really that tasty. So it's imaginable that we could be in a hype cycle because there's a gigantic economic engine that has an interest in us being in one.
dv_dt 8 hours ago [-]
I hope it pops and gets put on a more organic growth path. Locking up sales for RAM and storage more for monopolizing purposes is a sign that they were overcapitalized to the point that they didn't know what to do with the money. Same with building datacenters but taking community utility capacity. The shortcuts that are enabled are insufferable self-harming strategies that aren't that effective for moving adoption forward faster.
kylecazar 17 hours ago [-]
"I’m already hearing whispers of corpos reining in ai spend. What happens when your budget goes from 2k/mo to 200 per eng? What happens when that 200/mo cost turns into 500?"
That's interesting. I've also witnessed the reigning in of AI spend. What if the measure of a good developer becomes one who is an effective steward of tokens?
automatic6131 11 hours ago [-]
Are all developers going to have to be trusted to manage spend? I find that hard to imagine from our existing managerial system
And not to mention, the interests aren't aligned: a hypothetical engineer will always want to spend the max to impress: I delivered this project solo (and all it took was $2k per day on Galactos Swarm mode v9.9).
And we must, must consider what the most enshittified era of LLM AI will look like. Will they be holding your codebase to ransom? Yeah you can have an improvement but it will cost you. What are you going to do, read the code yourself?
fhd2 8 hours ago [-]
Of course developers should be held responsible for managing costs and other resources. We do it all the time, from infrastructure spending to client-side memory usage.
There's growth phases, where cost doesn't matter as much, sometimes to a seemingly unreasonable degree. And then after that, it really does.
I guess that differentiates us from "real" engineers, who can't make the bridge they're designing cheaper later, they think about it upfront. But we think about it, too.
pjc50 8 hours ago [-]
It was an incredible bull indicator for AI that, like AWS, it lets engineers spend unlimited company money without advance approval.
(we've already had the $2k/month max imposed, although I was nowhere near that it seems that people who have gone fully agent-brained were using a lot more. But not necessarily for more results ...)
vorticalbox 23 hours ago [-]
I would love to hand code way more but truth is when you have a small team of developers and they are all in on AI for coding then it’s actually hard to hand code. At a certain point the project ends up being only workable by AIs which is kinda sad. Coding is fun.
LtWorf 6 hours ago [-]
No worries, you will soon reach a point where fixing anything is impossible.
dasil003 21 hours ago [-]
The issue is there are multiple dimensions of quality, and people mean different things when they talk about it. Personally I think code quality for its own sake has always been a false flag that only gained currency because of skill moat of software development. On the other hand, user experience and fitness for purpose has always mattered a great deal, all the moreso when code is cheap, and this is definitely tied to code quality. The connection is even more stark when you talk about evolution of a system over time and data integrity. Here, the tacit assumptions, invariants and external interfaces chosen have a huge impact on the quality of the system and fitness for purpose over time. Every choice made affects the future, and it's very easy to box yourself in with bad choices, which ultimately depend on the offline human concerns that system is impacting.
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.
riffraff 19 hours ago [-]
I always loved the idea of perl measuring kwalitee.
It sounds like quality, and you can measure it and make decisions as it's well defined, but of course it's not quality.
In my experience (15+ years), the biggest trade-off is a lack of technical innovation. Current AI is unable to innovate. Humans can, but doing so requires
spending extended periods deep in the code and building a solid mental model of the system.
icantevenhold 23 hours ago [-]
Just like GPs argument about quality; the majority of businesses doesnt need innovation and often even fights it.
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.
zeroonetwothree 22 hours ago [-]
Businesses in a competitive market need some kind of innovation to do better than their competition. This doesn't have to be software of course, but often software does play some part in it. And it doesn't mean it's their in-house software, but someone has to develop it after all.
bertmuir 18 hours ago [-]
Most of the "innovation" I'm seeing is coming out of non-engineering teams vibe coding solutions or operational harnesses based on their non-engineering domain expertise.
It is fairly mortifying to watch them build solutions in hours or days that are designed better than the projects they were prescribing to product engineering teams to take literal months to spike, PRD, build - then maintained and governed better - with no real understanding of how it works.
Obviously lots of caveats to be made here, but fascinating to watch it play out (at least in places where infosec is robust enough to give a sales manager access to Claude Code).
LtWorf 6 hours ago [-]
I find it interesting how we want to make war on russia and china while our entire society relies more and more on completely unsecured software that they can take down and disrupt us with very little effort.
In my mind we should be much more defensive before we even think about doing anything offensive.
ambicapter 17 hours ago [-]
No, they don't. There are multiple businesses doing the same thing serving the same market in all kinds of industries.
pixl97 21 hours ago [-]
>the biggest trade-off is a lack of technical innovation.
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.
zbentley 15 hours ago [-]
There’s certainly more software being made now than before, which necessarily increases the number of (security) bugs. There are also a lot more users and use cases (e.g. smartphones).
But I’m not at all convinced that 30 years ago things were appropriately secure or usable.
dionian 5 hours ago [-]
Or in the enterprise world it's given us billions of dollars of waste by re implementing the wheel
deadbabe 23 hours ago [-]
Most innovation is pointless, because a lot of it revolves around just making code easier to maintain and understand for humans, it’s not like you’re innovating radical new algorithms for a CRUD app or making performance modifications that people will actually notice.
But since AI writes everything anyway, innovations that improve “developer experience” are pointless, and all the other low hanging fruit has been taken.
stackbutterflow 21 hours ago [-]
What I wonder then is...is it going to be the final word on the evolution of software development? AI has been trained on practices that were developed by people, by professionals and amateurs, by discussions on discussion boards, at tech events, through written books and then disseminated across open source projects. If no one writes code anymore then how to write and build software projects will never evolve beyond the 2022 state of affairs.
musebox35 14 hours ago [-]
That data goes into pretraining the initial model. The agentic post-training relies on the model making stochastic exploration. So in a sense it learns via trial and error. By the accounts I have read, this second stage is the dominant reason we have seen the increase in model capabilities in the past year. It is still not clear how innovative the models can be, but they are not just relying on static data.
zeroonetwothree 22 hours ago [-]
It seems like we have more innovation around "developer(=agent) experience" than ever. Look at all the people building various agent control plane systems, containers, isolation, issue tracking, project management etc.
ozim 12 hours ago [-]
That’s software engineering bubble.
Go out to a bakery, tire shop see how much they innovate. Then go one rung up to services they consume like insurance and banking. All of this chain is super conservative.
Quarrelsome 21 hours ago [-]
innovation is about being able to reach for better solutions to problems where previously it would "take too long". e.g. DSLs.
crq-yml 20 hours ago [-]
I think it'll be fine as long as we aim for software to be finished and replaced instead of indefinitely extended. Best practices have followed the tradition of reuse and abstraction for so long because that lets us approach software with the "building the Pyramids" mindset - a indefinite march to create functionality one brick at a time within a scarcity of working code.
The agents will often propose bypassing reusage of existing code in favor of generating a new thing - there is no fear of "NIH". That's scary at the surface - human programmers like having something that looks like a reusable brick that they can dwell upon - but attractive in other respects since it lets the organizational needs express themselves directly. Working fully top-down like this is novel within software. There are plenty of unknowns to it, but it means that relatively more of what was a library that you learned and trusted but rarely verified instead becomes a requirements document, reused and iterated on project to project.
codebje 18 hours ago [-]
Ahaha we're going to re-learn a lot of the hard-won lessons of development over the next few years. Just because AI will tackle any job doesn't mean bad choices made now won't lead to time and cost blow-outs down the line. It'll just be token spend blow-outs instead of programmer hours.
On the bright side, since every LLM is completely ignorant of your project's history and minutiae, the "mythical man month" doesn't have an AI equivalent and you can slap on more and more agents to convert time blow-outs to cost blow-outs.
senordevnyc 17 hours ago [-]
since every LLM is completely ignorant of your project's history and minutiae
It’s a good thing no business ever has to hire a new developer and get them up to speed on such things!
LtWorf 6 hours ago [-]
Business who fire entire teams and hire new replacements have much more costs and failure than people who keep the teams going and slowly rotate them yes.
flatline 23 hours ago [-]
> A timed cadence of release is anathema to quality code because you can't timebox it.
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.
greenowl 22 hours ago [-]
We fought for quality code mostly for selfish reasons. Because it sucked to work in a messy, fragile codebase.
But AI doesn't care. It can, and it will, happily churn through a messy codebase.
sunaurus 21 hours ago [-]
> 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.
greenowl 19 hours ago [-]
Actual effectiveness aside, the comment is more about willingness to even work with messy codebases. No matter how messy the code gets, agents can and will continue to push forward. While humans would just get fed up. In the past I've known multiple devs who literally quit and switched jobs from working with messy codebases (you can't always tell what you're walking into during the interview stage).
brlewis 18 hours ago [-]
[dead]
discreteevent 20 hours ago [-]
[flagged]
randysalami 19 hours ago [-]
Dang can you confirm if this is true?
greenowl 19 hours ago [-]
What a bizarre conclusion. Read my comments you'll actually find they trend toward the opposite.
redwall_hp 13 hours ago [-]
Good old Garbage In Garbage Out. Only Non Garbage In produces n% garbage on each iteration, so you eventually regress to GIGO.
codebje 18 hours ago [-]
"Good, fast, cheap" never changes.
Messy, fragile codebases have a greater cost of change and a greater likelihood of errors with every change. AI tokens might be cheaper than developer hours but you'll still burn more of them working on a messy code base, and still have the reputational impacts of a high error rate.
If "fast" and "cheap" are the main drivers, you'll get "bad". And I think it's a great deal easier for developers to follow the path of least resistance and allow "bad" to deliver faster and cheaper when it's AI that's reading the code.
adrianN 14 hours ago [-]
Of course it changes. Compare clothing before and after the industrial revolution. We definitely have good, fast, cheap clothes now, to the point where the second hand market for clothes is pretty much dead and clothes are seen as disposable objects. The same can happen to software. There is nothing preventing disposable software, indeed the number of one-of Python scripts that I use and discard has exploded. With further cost reductions I can totally see the disposability barrier to climb to larger software systems.
codebje 13 hours ago [-]
Tailored suits vs. off the shelf ones? Cheap imports that fall apart after a few dozen wash cycles? You absolutely still pick two (at most) for clothing.
The industrial revolution may have changed the bounds, but it didn't change the relationship.
Your one-off Python scripts are a bit like handkerchiefs. You can make a one-off hanky by cutting a square off an old sheet, fast and cheap, but it's clearly not as good as a re-usable one and you'll throw it out after using it once or twice. That sort of idea simply doesn't scale with complexity. A "good enough" pair of pants needs a lot more than just snipping out a shape. Even a one-off pair of pants, like for a costume, requires time and effort. So too with larger programs. They require more time and effort.
AI changes the bounds: it's cheaper and faster to produce software than it was, but it's not cheaper or faster to make something good than it was, not by an appreciable amount. It remains to be seen if software turns into cheap clothing advertised on buses that is barely fit for purpose... but the industry's track record isn't anything to praise, so probably, it will.
adrianN 12 hours ago [-]
For an hour at minimum wage I can buy a t shirt that lasts a year or two before it needs mending. That’s ridiculously cheap compared to pre industrial garments, which is why mending rarely happens. Even tailored clothes are extremely cheap because machines weave the cloth and machines do the sewing. Imagine you had to pay minimum wage to cotton pickers, people operating a manual loom and people sewing by hand.
somenameforme 14 hours ago [-]
But I think it does. For instance your comment is not all that different than ones I read, what feels like not 'that' long ago, back when hand-crafted assembly was often still significantly better than compiler produced code in many cases. I'd point there not only to the eventual outcome, but also the fact that we're having this debate when there's every reason to expect LLMs to continue significantly improving, much in the same way that these debates of the past were also being held at a time when compilers were still rapidly improving.
codebje 13 hours ago [-]
Better tools doesn't change the relationship between time, quality and cost. It just changes the bounds on those values. You can use a compiler to compile shoddily written high-level code just as easily as you can use it to compile well-written high-level code. The cost of writing the high-level code is cheaper than the cost of writing equivalent assembly, but the time and cost of writing good code remains higher than the time and cost of writing bad code.
Then, too, hand-crafted assembly still beats compiled output, if you consider the only upper limit on quality. The gap in quality is much, much smaller, and the gap in time and cost is much, much bigger, though, so it's almost never worth the trade-off.
Let's say that AI-generated software eventually (or already, if you like) produces better quality software than people can produce, given the same time and cost restrictions. You can still spend more time and cost to get a better result, or accept a worse result to save time and cost. Or take more time to get a good result but more cheaply using off-peak pricing (tokens or power, take your pick). Or throw more parallel agents at the problem to get a good result faster, but at higher cost.
Pick two. Always.
somenameforme 12 hours ago [-]
Upper limits don't matter when humans can't realistically achieve them. There are exactly 0 humans alive today who can write better assembly for any complete program, of a minimum complexity, than a compiler.
matwood 10 hours ago [-]
Yeah, code humans can read is quickly just becoming another intermediate language for the AI to work on. We are quickly moving up another abstraction layer. I think part of the challenge for ICs is now we’re all becoming managers, which isn’t something everyone wanted.
strus 11 hours ago [-]
> But AI doesn't care. It can, and it will, happily churn through a messy codebase.
Even if that will be true (currently it's not in the long run), messy codebase will make you spend much more on tokens. So unless agents become so cheap that it won't matter, having a mess will be bad for the business in the long run.
dnautics 20 hours ago [-]
Yeah but if you don't keep tabs on it, you might not know what to prompt it to fix. For example, early on I established in my fun proof assistant project, that I did NOT want total functions (1/0 should not be permitted, 3-4 not permitted in N), and it seems to have forgotten that along the way and it took a 2 day struggle session to remove total functions from the standard library.
Managed to get it in time to have an accurate claim that "stdlib has no total functions" prior to presenting it to someone semifamous, who doesn't like that lean has total functions
sandeepkd 21 hours ago [-]
I think you are underestimating the spiral effect. Working with a documented and structured code makes it easier to understand and reason with even for LLMs. At the end of the day its working with patterns, grammar, trying to deduce and implement intent. Its possible where we enter the era of blackbox applications where no one knows the internal, and yet for the required inputs it provides the expected outputs. Every failure would re-trigger the evaluation of the whole application to accomodate that one failure in requirement.
ozgung 10 hours ago [-]
> We fought for quality code mostly for selfish reasons.
Also what does quality mean really? Because recent AI audits show that we humans have been generating low-quality software in terms of security.
Readability and maintainability is less of a problem for AI. One can argue that they’re potentially better for writing and running tests. Same for writing performant code.
Additionally, all those arguments about tabs vs spaces, position of the curly brace or different naming conventions have zero meaning now.
t43562 9 hours ago [-]
... and now the people who wrote that low quality software are potentially the ones who can't see when AI generated code has its own problems.
mostertoaster 22 hours ago [-]
I agree. And while AI does better when there is less tech debt, at the same time paying down tech debt has gotten immensely cheaper.
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.
jdpigeon 22 hours ago [-]
I think the second part of the blog post speaks to exactly how this will play out: more incidents, longer recovery times, and a poorer user experience. Overall, a more fragile and worse ecosystem of software (even if there's more software overall).
keybrd-intrrpt 16 hours ago [-]
AI models and tools are only as good as the people who use them.
If you don't prioritize what is important to you, it isn't going to magically build it.
It can't read your mind.
"We don't know what's in the code base" - Where is your design spec that says what should be built?
"The tests are too shallow" - How are you asking it to make tests? What are your test metrics
"more incidents" - Why don't you have tests or scans against these.
IMO- there's basically no excuse for these things anymore. If I want to be really harsh - the people that are complaining or naysaying the most are just code monkeys. Maybe they ARE hot-shit programmers that can code circles around me, but how much do they contribute to a team? Do they get out of their own head and actually write down designs? Specs? Have they documented how things are supposed to work or do they "just know" ?
Why would recovery take longer? To me, that means you didn't code-up a failure and recovery plan, which your LLM agent will help you make. To mean that means you never thought to actually stress test anything.
And pre-LLM, those were still inexcusable but at least understandable - development time was limited. Now, how is there any excuse except for you didn't think to write these things down or event prompt for them. That's on YOU now. 100%
lelanthran 5 hours ago [-]
> AI models and tools are only as good as the people who use them.
What does this (and the rest of your comment) have to do with parent's assertion of "I think the second part of the blog post speaks to exactly how this will play out: more incidents, longer recovery times, and a poorer user experience. "
After all, if 99 out of every 100 developers are getting a fragile codebase by doing $FOO, the fact that it is possible to do $FOO safely is not a defense of $FOO.
matwood 10 hours ago [-]
> AI models and tools are only as good as the people who use them.
Bingo. People notice slop because the people using the tool didn’t care or weren’t very good. There is way more AI usage going on than people realize, but you won’t notice when it’s used by someone skilled.
skydhash 7 hours ago [-]
> the people that are complaining or naysaying the most are just code monkeys. Maybe they ARE hot-shit programmers that can code circles around me, but how much do they contribute to a team? Do they get out of their own head and actually write down designs? Specs? Have they documented how things are supposed to work or do they "just know" ?
The complaints is that we are not seeing any of those being done. And when you point it out, you go slop thrown back.
The thing about nice code, is that it can be its own design doc, what you need mostly after that is just a high level explanation. No need to write the small details twice.
> Now, how is there any excuse except for you didn't think to write these things down or event prompt for them. That's on YOU now. 100%
I can do that and hope that the LLM do a good job for them, or I can just get it done. The two are roughly equal in time taken if I’m looking to do a good work, but LLM usage is more mentally taxing.
NewJazz 20 hours ago [-]
That said, my experience tells me that enterprise and business coding has rarely ever been about stable or robust codebases.
Meanwhile certain open source communities are renowned for their adherence to strict standards, and many are using AI to tighten up their codebases rather than balloon functionality.
NewLogic 7 hours ago [-]
The difference is that every PR is still heavily scrutinised for correctness. Companies are moving in the direction of LGTM reviews.
autoexec 6 hours ago [-]
wait for the Looks Good To AI trend.
rlander 16 hours ago [-]
Interesting. Which ones?
NewJazz 15 hours ago [-]
Postgresql, linux come to mind. As well as rust.
zamalek 18 hours ago [-]
I've said this before around here: I'm starting to realize that the high costs associated with pre-AI dev were a feature the majority of the time. I can't find that old cURL UI which had infinite toggles and options - but that's where cheap development leads software:
* Adding too many features to existing software making it impossible to find where to do important routine tasks.
* Once-off projects that behave much like the first, by virtue of the user having to figure out which of the 15 apps do what they need.
* Usage rotting and bit rotting features. Someone builds something for a once-off and it sits there forever.
Enterprise software not being about quality was always a problem, and AI hasn't made that go away; it has made it worse. Disciplined PM and the word "no" is how great software is made (in terms of usability, I'm avoiding talking about performance), and AI rewards the opposite.
matwood 10 hours ago [-]
That’s not an AI problem, but a software/product design problem. The adage that what someone says no to is more important than what they say yes to, comes to mind. We can no longer be lazy and say we don’t have time to build a feature, we must do the hard work and make decisions.
zamalek 2 hours ago [-]
> That’s not an AI problem
> [Mine] Enterprise software not being about quality was always a problem
mvcosta91 23 hours ago [-]
Seconding that.
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.
lconnell962 17 hours ago [-]
When we look at wider enshitification patterns being pushed in some industries I can't exactly see AI being a problem for those specific sectors. Similarly I don't see a problem in areas that want to create adversarial customer interactions. At least as long as someone is on the hook to quality control that adversarial relationship in the shareholder's favor.
That's the patern I'm unfortunately expecting for developers. Developers on the hook for auditing the AI slop code. People hired entirely to get around to plugging the holes the AI makes. It probably will be a full time job as the AI pushes new features, UI updates, and otherwise opens new bugs.
From the outside as someone who isn't playing with AI generated code for work currently it seems like it will be the same kind of problem space as a developer inheriting a legacy codebase. In some ways it will be worse, that AI "developer" probably won't be any more useful than the legacy developer who retired for figuring out "why" something was set up a specific way. It will most likely still be around fiddling with your code though, but if your company is locked in to one model it might be easier to learn to read... at least until they change models and you need to learn the style of the new "developer" you can't fathom.
raxxorraxor 9 hours ago [-]
I agree completely and I wish I was wrong as well. Luckily I don't develop software in a company that sells software (aside a few support utilities). What I see is that everyone is starting vibe coding and my job is to create a harness now. Within a year there is a software pipeline for a 500 people company that would rival a huge enterprise just a few years/months ago while still offering the flexibility of "agile/unplanned" development.
I have a huge backlog of reviewing code. Luckily most apps stay internal, but the desires to even host services on the net growths daily.
Last year december I had about 10 repositories with internal code bases. Now I have 100+. I constantly have to "renovate" apps that spawn CVS left and right. This was a pivot for me to develop myself to become a kindergarden teacher.
I don't have fears to be replaced, I have more problems with huge work loads... And software that was previously bought to solve a problem is now just vibe coded and copied by people that seriously don't understand the system they are developing. Well, interesting times...
amelius 20 hours ago [-]
> Time only will tell how this plays out.
I can tell you: your management skills will be copied by the AI (thanks to your input!)
joquarky 18 hours ago [-]
Yep, I worked for an S&P 500 company that gradually moved from quality to quantity while I was there.
I kept wanting to fix underlying problems rather than applying band aids and my insistance on quality for important things like court schedules, administrative portals, accurate billing, and tracking jail release dates ultimately resulted in them handing me my hat by assigning me to the least desirable maintenance group where I burned out spectacularly.
I'm sure that this company now produces a plurality of privately owned government software.
ratelimitsteve 23 hours ago [-]
it's about dynamic tension. we as engineers should want to do things the right way even if it means spending infinite money and never releasing. the corporate side should want to do things the wrong way because it's cheap and gets to market faster. we should argue with one another til we're blue in the face about it every day, and the actual thing that gets delivered should exist at that perfect little goldilocks zone in the middle where both sides hate it and blame the other for its shortcomings.
rapind 23 hours ago [-]
Widespread misconception. There are plenty of product managers / executives who also want quality and plenty of engineers who want to ship. I'd wager most engineers would rather ship and get their creation in front of users than spend eternity perfecting it.
tonyedgecombe 3 hours ago [-]
Yes, whenever I’ve seen sloppy work it’s come from the programmer. Management rarely seems to care either way.
ratelimitsteve 23 hours ago [-]
of course we can never speak of an entire population in absolutes, only tendencies, but if you're going to argue against the tendency i'd like to see a bit more depth to the argument than "I'd wager". I also don't think my overall point suffers at all if you substitute "engineers" with "some people" and "corporate side" with "other people", so i'm going to politely request that we do that going forward so we can address the substance of the discussion rather than the makeup of the two sides of it.
slowdownappssuc 15 hours ago [-]
> I find it invaluable about the only way to stay relevant and run a business nowadays.
And this is precisely where you lost me. Because. No. That's a lie you tell yourself to justify the state of things. But it's as far from the truth as it could be.
Features is how you win the wind up of your business. But features do fuckall in user retention, while feature maintenance does. Tell me, name a SINGLE, one teensy tiny ass feature youtube has added to its service in the 6 months. Last year being when they began their 100% AI mandate, and the last 6 months being when AI has got its "good enough to engineer most of an app" acceptance.
I can name the few features, I know creators. But YOU are not a creator. I do not believe you can pass this challenge. And yet youtube remains the video streaming titan. The only feature most people on here can even probably name that their clients got all come from the morphe app. Custom play thumb and custom playbar colors is cool, but google would NEVER, despite having zero need for direct coding manhours anymore.
In other words.
Google is privileged enough to slow down.
And yet, you espouse the the opposite. Can't stop, won't stop! The MARKET demands it!
I don't buy it. You're mismanaged.
keybored 19 hours ago [-]
AI Inevitability is Business Inevitability in a trench-coat.
God knows but money decides.
behringer 20 hours ago [-]
Exactly what I'm seeing. The AI does even seem to do quality code, but you have to give it a heavy hand on the engineering side of it. Track small, test-driven changes, highly detailed documentation, a way to programmatically access the application and debugging features, high quality logging, design and implementation approvals, and frequent full audits. The quality it provides is heavily dependent on your quality as an engineer and how well you can keep it on track.
intended 23 hours ago [-]
I suspect the code being generated ends up falling into a local maxima, and only much later will the cost of extracting be apparent.
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.
swat535 22 hours ago [-]
What you're missing in your calculus is that by the time the local maxima is reached, the business has either pivoted to something else or is throwing money at the problem to make it go away.
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.
intended 15 hours ago [-]
Yes! I definitely know this is reality, but I’m not quite sure what’s a shorter and simpler model/term that captures this behavior.
codeugo 16 hours ago [-]
Very true!
rixed 22 hours ago [-]
Agreed 100%, especially with the sentiment that a lot of people have been telling themselves stories about the importance of quality in the industry (it was quite obvious, long before AI, that quality was not a concern unless marginaly in the rare cases where it mattered for competing. But quality for the sake of customers? No way, not now, not in the past, never.
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.
dominotw 22 hours ago [-]
oh classic "its better than humans that suck". Truth is that enterprise software development is mostly jobs program for the middle class. Software jobs building random internal tools are obviously bullshit jobs.
Using AI to generate something that had no value in first place is just silly.
waffletower 21 hours ago [-]
[dead]
dools 18 hours ago [-]
We already went through this when everyone started “outsourcing” in the 2010s.
I realised then when I became more of a manager than a coder that then types of code quality issues engineers obsess over are practically irrelevant.
nik282000 16 hours ago [-]
> I realised then when I became more of a manager than a coder that then types of code quality issues engineers obsess over are practically irrelevant.
Until you find out your TLS key is 4 or that a 255 char password will bypass your auth system. Management is a necessary evil that needs to be kept in check by knowledgeable and skilled people.
rubikscube09 23 hours ago [-]
code is disposable now.
Slartie 22 hours ago [-]
Code has an invisible attribute "confidence" associated with it. All code has it. So-called "battle-tested" codebases have a high value, newly-written stuff starts at low values, and the only two ways of increasing it are 1) rigorous testing and 2) actual usage in production scenarios at scale.
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.
bunderbunder 22 hours ago [-]
I’d argue that code was always disposable. What was valuable was always the specifications and test cases, which more directly represent useful knowledge with lasting business utility.
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.
jamesfinlayson 17 hours ago [-]
Agreed.
I have heard of a company trying to build a new app by using AI to generate a detailed specification from the old app's code. We'll see how it turns out but the app is talking a bunch of APIs that, like you said, have little documentation besides the code itself.
diegolas 23 hours ago [-]
_some_ code is disposable, but robust, proven solutions that fit the case of massive userbases will keep existing and get maintained. at a certain point it makes no sense to rebuild everything each time.
22 hours ago [-]
matwood 10 hours ago [-]
> but robust, proven solutions
As AI has been highlighting, maybe this idea has always been an illusion.
iagooar 21 hours ago [-]
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.
pizza234 21 hours ago [-]
> "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.
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.
mceachen 19 hours ago [-]
I've found several solutions to avoid agents from building complexity -- the first is to not use Astra or Fable/Mythos unless absolutely required. The second is to use effort level "high", not "xhigh". The last idea would be to edit your AGENTS.md to be short, and start it with something like:
Contributors to this project must follow YAGNI, DRY, KISS, and principle of least astonishment, both from user-visible surfaces, and backend design.
Code is a liability. Do not build anything not expressly asked for.
pif 9 hours ago [-]
> if you are stuck with the mantra that humans must review the code today,
It's not a mantra, it's the reality of the business: if I must bear responsibility of the code facing a customer, then I have to understand the code. The AI can be a wonderful tool, but people are still calling me to fight fires.
kuboble 8 hours ago [-]
Idk. Do you ship your own crypto, your own cloud or design your own chips?
At some point technology becomes so good that it's a reasonable choice to give up understanding. And in opinion of many, that point is now for agenting coding.
zelphirkalt 7 hours ago [-]
The comparison with shipping your own crypto does not hold up. Is crypto the core of your business? If not, then you don't ship crypto. But the core of your business, you need employees, who understand what's actually going on, or risk being unable to fix things, when they go wrong.
kuboble 6 hours ago [-]
and these employees with technical understanding can be Llms. And baring the risk of being cut off from the models how is that different from hiring humans?
you are probably smarter and more skillful then I am, but despite coding all my life for a living I feel that AI is vastly better than me in every single skill that I thought are my strongest skills.
I also think that the risk for a small company is larger that their only programmer who understand the code base quits than the ai not being able to fix issues in its own code.
The only point of disagreement is if llms are already good enough. And for a lot of people this is already true today.
pif 6 hours ago [-]
It depends on which responsibilities you can offload when facing your customers.
"You were hacked because the well known, respectable crypto lib I bundled with my binaries actually got a bug" is fine.
"You lost one day of productivity and I can't tell you when I'll be able to propose you a fix because I shipped you a lazy copy/paste" is not.
lelanthran 5 hours ago [-]
> Idk. Do you ship your own crypto, your own cloud or design your own chips?
Of course not - I use battle-tested options. Why would I pivot from battle-tested, production software that's had bugs shaken out for years to brand-new never-used-in-anger software that an LLM spat out?
kuboble 5 hours ago [-]
[dead]
spacechild1 11 hours ago [-]
> human understanding does not decrease, it just moves up a level or two.
It absolutely does. You lose understanding of the code, but what kind of understanding do you actually gain in turn? AFAICT it is purely a tradeoff between velocity and understanding.
perlgeek 20 hours ago [-]
> "AI writes shallow tests" - used to be true, not true anymore since Astra and Fable 5.1 / Opus 5.5.
You can also tell it what kinds of tests to write. (Assuming you're still interested in details of the codebase).
> "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.
Also, if it wrote a complex solution, tell it write a simple one instead.
In my experience, good AI adjusts pretty well to an existing code base, and produces roughly similar abstractions to the ones it finds.
nomel 16 hours ago [-]
> and produces roughly similar abstractions to the ones it finds.
This is a pretty severe issue I have. Give it a bad codebase, and it'll happily carry on the awful, ignore failed unit tests, omit documentation, not fixing existing problems just to, and I quote, "follow precedence".
It seems these models have been (probably for the better) trained to not rock the boat too much, to somewhat keep the work to a minimum. I think we're going to end up get stuck in de-risked "just make it work" sort of mode in the near term, with all the "less good" code that's was generated relative to newer/future models. At some point, there's going to need to be a shift to just rewrite/replace bad code, without excessive, and very often forgotten, instructions to do so.
nprateem 12 hours ago [-]
Ok and do you run a few dedicated rounds to improve quality and refactor, add tests and docs etc?
Staying inline with the codebase is the right thing to do. It's down to you to tell it when it's time to re-engineer.
nomel 11 hours ago [-]
> It's down to you to tell it when it's time to re-engineer.
> without excessive, and very often forgotten, instructions to do so.
It forgets, within long sessions. I'm still seeing Opus 5.5 implement workarounds for bugs it created within its own session, even with explicit, and plentiful, instructions and global memories that it's time to re-engineer.
But to your point, yes, multiple rounds are required. My point is that this strong affinity for what exists is going to eventually hold development back.
nprateem 7 hours ago [-]
Just don't use long sessions and always start a new one to check for bugs/divergence before you commit.
makeitdouble 9 hours ago [-]
> The same way you do not really understand how the Linux kernel works, nor do you know how assembly really works
Thing is we don't write kernel code nor assembly.
It would be an issue if for every API request handler we write we'd also ship a kernel patch or some kernel level helper. That's the situation we're stuck in with agents, they produce a bunch of low level code that we have to either trust or thoroughly review, even as our goal is at a higher level.
IMHO we really need high level and proven solid frameworks that the agents can rely on, and get in exchange high level code that is succinct, simple and readable enough to be properly understood.
kykeonaut 2 hours ago [-]
> "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.
Or my personal favourite: "if you overengineer it, my grandma dies"
agnishom 13 hours ago [-]
> you will learn to yield a much, much more powerful weapon.
and that is a means to which end, again? I very much enjoyed the engineering bits of programming: having a deep mental model of how the software works, understanding the architecture, the data structures, the algorithms.
nprateem 12 hours ago [-]
Shipping code, which is what most of us are paid to do.
FearNotDaniel 6 hours ago [-]
Nobody’s going to stop you continuing to enjoy your hobby on your own time. Plenty of amateur blacksmiths, fletchers and chandlers out there having fun. You just need to find a paying job based on a marketable skill with enough leisure time left over to think about that deep mental model.
eluru 11 hours ago [-]
Well to ship the product of course, the thing we are paid to do so
tripleee 14 hours ago [-]
> The same way you do not really understand how the Linux kernel works
uhm.. what? The reason I don't understand how the kernel works is because I'm not working on it. The people working on it understand how it works. What kind of logic is this?
pnt12 9 hours ago [-]
I agree with the abstractions, but there's still criticism to make - someone must fix the bugs in the layers below. If the code is messy, and the llms aren't getting there (they aren't infallible!), you have the risk to have put yourself into a corner.
kodebach 18 hours ago [-]
> 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
Sure I don't have a deep understanding of the Linux kernel, but some human(s) somewhere do(es). If a whole company switches to LLM development for their (closed source) product, nobody has a deep understanding of the code anymore. That could become an issue real quick, if AI doesn't do what you want anymore.
(Not saying AI is gonna go sentient, just saying taking AI for granted is a problem in and of itself)
thepunisher3 8 hours ago [-]
> The same way you do not really understand how the Linux kernel works, nor do you know how assembly really works
Those are really bad examples to quote tho. I'm not making a change in the Linux kernel nor am I releasing it or debugging it or maintaining it or getting pinged at 1am by Pagerduty because of it. Nobody is asking me how it works or what would it mean to add feature X to it.
I think the bigger point is that you still do need to understand what is up in your codebase, relying on agents 100% of the time for absolutely everything is going to be preposterous in the long term.
pasteleft 16 hours ago [-]
You don't have to understand how the Linux kernel works because we're stupid and some really smart guys are maintaining Linux kernel instead of us.
If I take ownership of the Linux kernel and refactor it into Rust with a "thorough test" using Astra/Fable, will you use it?
mitxela 11 hours ago [-]
FYI the Linux kernel isn't that smart. It's just not your project. If it was your project you'd understand it.
fallingbananna 8 hours ago [-]
Ah yes, the usual arguments:
- You are using it wrong! You don't know how to prompt!
- And if you do, then you are using cheap models! You aren't spending enough!
- And if you are, then you care too much! The quality doesn't matter anymore!
- And if it does, then the models will get exponentially better! The problem will be solved in a few months!
*Edit*: I use AI and find it great, but I don't think we should be dismissing any negative feedback as user error.
onlyrealcuzzo 19 hours ago [-]
> Things have radically changed since then.
No, AI is still absolutely terrible at design.
It doesn't matter if they are good at implementation.
If you ask for a car and they build you an awesome surfboard, it's basically worthless.
Sure, if you're building rapid prototypes where it doesn't matter if anything is coherent or works, AI crushes it.
If it's a 99% derivative small greenfield project, AI crushes it.
For anything real, it is still a painfully awful experience to extract juice from the squeeze.
techmunky 21 hours ago [-]
And here we are back in 2024 prompt engineering stage of "you're not using it right." Wake me up when we get back to the loops and harnesses phase.
bigstrat2003 18 hours ago [-]
> This reads like a piece of content written a year ago. Things have radically changed since then.
We've been hearing this claim for years. It wasn't true then, it isn't true now.
globular-toast 11 hours ago [-]
Yeah, everything in the article seems just as true now as it always was. I think maybe what we see is it's gradually passing more and more developers' thresholds for quality. So I suppose in the end nothing changes: people who turned out shoddy code before turn out shoddy code now. The scary thing is they're doing it quicker than ever.
forgetfreeman 21 hours ago [-]
There have been spontaneous demonstrations amongst the workers voicing their joy and gratitude at our happy new way of life...
sleight42 11 hours ago [-]
Many of us can't afford to wield Fable or Astra with any regularity.
bbvvc 21 hours ago [-]
Blah, blah. They told us the same in 2025, 2024, 2023: "This is fixed in the latest frontier model!!!"
bigwheels 21 hours ago [-]
Coding agents have only been really working for about 12-18 months at most. It's easy to forget!
genidoi 21 hours ago [-]
And even in that short time range, the difference in capabilities 18 months versus 3 months ago is so massive that the expectation of what it means for them to 'work' has changed.
deepfriedbits 21 hours ago [-]
You honestly don't notice any improvements in terms of model capabilities?
bigstrat2003 18 hours ago [-]
Not the same person, but I don't. I have noticed a slight improvement from GPT-3.5 until now, but not a marked improvement like people say. And I didn't notice any of the claimed massive improvements along the way either. Every model I use, even the very latest, is still fundamentally very stupid and cannot be trusted to do its own thing.
TeriyakiBomb 10 hours ago [-]
Same here. At certain tasks, you can see a marked improvement in code quality. I think it’s just focus during training that produces this. In terms of fundamentals, they’re just as likely to fumble things at random, over abstract, duplicate, overfit and fail in the same ways. A lot of people who spend a lot of time poking at AI slowly stop thinking critically about it too.
I see it like someone walking through a minefield safely after not noticing the signs.
“What do you mean it’s a minefield? MY legs didn’t get blown off.”
ChrisRR 7 hours ago [-]
Sounds like it's getting better with each release then
genidoi 21 hours ago [-]
Even 'technical debt' seems outdated... better models are coming that will fix the shortcomings of todays models.
g-b-r 6 hours ago [-]
Maybe they'll even invent a time machine and fix every problem they ever caused.
techdebtgoingaw 15 hours ago [-]
I like this take for the same reason I liked the <AI is forcing us to pay back decades of tech debt> articles.
Even if AI did indeed make worse architectural decisions, that just means we have to be more on top of it in preventing them to make those decisions.
We've already managed to successfully convince everyone that you should tell AI to always produce tests for your changes. But we were ALWAYS meant to ALWAYS have test. Why did we ever not do that? Oh right, lack of time, different priorities, etc. etc. AI gives us the time back so now we're no longer allowing excuses. Weird how the standards only change with a complete lack of care and naive trust of AI?
The article also mentions that AI produces code that doesn't scale. Well? Why aren't you running a profiler and looking for places to optimize then? You were ALWAYS meant to do that. You were ALWAYS meant to ~prove~ the scalability of your architecture. This was ALWAYS a responsibility of engineers. Why are you just trusting it to do whatever instead of putting in the work doing all those things and improving? Where the hell did your responsibilities go, and why are we having a discussion on AI instead of on the fact the human is avoiding their job-description responsibilities?
I am an engineer. It is my job to produce good code. And I am proud of that, and of what that means. And right now, that means looking at AI doing a half baked job, and either baking the other half myself, or telling the AI how to.
Knock knock. That's all the shitty engineering of the last decades. It isn't dead. It's just called vibecoding now. Don't blame the AI. Unmask it, and blame shitty engineers.
And companies that enable them. If they're that shitty and the code will implode that much, unseat them. They will be paying that debt, while you soar.
monjerry 24 hours ago [-]
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).
proc0 22 hours ago [-]
Yes. This is the result of the industry being led by only managers and non-technical people who scuff when engineers who talk about taking more time to do things properly as if they are just fulfilling their own personal creative needs. As a result the engineers who are just willing to make leadership happy are the ones who end up making technical decisions, usually short-sighted that leads to compounding complexity and lots of headaches down the line.
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.
Seattle3503 11 hours ago [-]
> 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.
How can this be judged from the outside, eg in an interview?
proc0 9 hours ago [-]
You mean from the candidate's POV? I would ask about their process and priorities. I would ask how engineer performance is measured and make sure there are are clear technical achievements for the role. If they only look at vague things like "impact", that could be a red flag that they just want engineers to be "productive" at any cost.
miguel-muniz 24 hours ago [-]
There are plenty of decades old codebases written in old guard languages that were suffering the same fate pre-ai. What is old is new again.
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.
proc0 22 hours ago [-]
This pattern is somewhat self-inflicted. There's very few reasons for software to change, IF it is properly developed. A reasonable life span should be in the order of decades, not years, or I bet now with AI it will be months. Do we really want a constantly changing software landscape that requires unlimited Internet connectivity to function? THat seems like such a waste of electricity and bandwidth, but as you say that has been the norm.
jamesfinlayson 16 hours ago [-]
Agreed, but it's a very big if that I haven't seen in practice much. By January, 50% of major codebases that I've worked on will no longer be running.
Something that I'm working on for my day job is essentially 32 years old though (been through a couple of big upgrades along the way) and that's how it should be, unless the underlying technology would be better off being replaced (like a COBOL or Fortran codebase).
proc0 8 hours ago [-]
That's great, and the main reason I'm moving away from Web and more into Systems level. It could very well be correlated to the domain.
B4uler5 23 hours ago [-]
Yeah, but why are we accepting that? Do we envision a scenario where code will be so black boxed that software creators will be pinching pennies and cutting corners so they can eek out a profit margin over the cost of development? It seems insane that we’ve willingly taken this route, the power when using LLMs is immense, but the power we’re giving up is all we had.
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”.
mschuster91 6 hours ago [-]
> 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.
React + Electron "won" because it was the best "bang for the buck". You get cross platform compatibility for all relevant desktop OSes out of the box thanks to Electron, and thanks to React you get access to an effectively infinite pool of developers (at least compared to Qt or other native UI frameworks).
20k 22 hours ago [-]
I think unfortunately companies are going to have to learn the extremely hard way what happens when your engineers no longer understand any of your code. The drive to eliminate institutional knowledge to create a perfectly replaceable worker was always dumb at best, and just leads to car crshes
zombot 9 hours ago [-]
The danger is that by then the managers have converted development to completely AI-based and going back became prohibitive.
ern 19 hours ago [-]
I have used Agentic AI for both really sloppy vibe coded personal projects (big balls of mud with tons of integrations- huge HTML pages with tons of JS slop doing and NodeJs that I wouldn't ever care to look at) and well-engineered, carefully crafted systems for work and I haven't seen significant regressions in either group.
peterbell_nyc 23 hours ago [-]
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.
PaulMorel 22 hours ago [-]
I'm the author of the article. I like your comment. I wanted to answer your question.
> "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.
zmmmmm 21 hours ago [-]
> I don't necessarily think it really solves the problem, although I'm unsure about the reason
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.
StefanSko 11 hours ago [-]
[dead]
killiancarroll 21 hours ago [-]
I strongly agree with your sentiment here. Building both deterministic and non-deterministic verification processes are the way to build sustainable software projects rather than focusing on every line of code.
jasode 1 days ago [-]
I don't disagree with the article but it may give some readers the impression that pre-AI hand-written code wasn't fragile.
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.
This is actually a perfect depiction of what "bug-driven development" looks like, which is basically where the current generation of AI-only codebases are headed.
cyberax 23 hours ago [-]
> Every big company codebase with millions of lines devolves into a similar state.
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.
Krei-se 1 days ago [-]
So the argument is that because before AI some code was bad it's ok that now all code is bad?
delbronski 1 days ago [-]
No I think the argument is more like… on average the code AI produces is better than what the majority of developers were producing before AI. Don’t forget HN crowd is the exception. The people that post here are like 1% of total programmers that like this as more than just a job. The industry at large, 99%, is just people doing their job writing average to poor code and going home. AI does that better now.
christophilus 1 days ago [-]
I doubt we're really the exception, and I think a good developer from the before times can still guide AI to produce a reasonably maintainable codebase over time. Most likely, a bad developer from the before times will still be able to guide AI to produce a mess. But yeah. It seems to me that the latest models produce above average code, based on the messes I've seen (and helped produce) over the last 25 years or so. It's not as good as what I'd build by hand these days, but it's good enough, when in the right hands.
runarberg 1 days ago [-]
There was a time we all on HN agreed that contracting out the code was a bad idea. That ownership of the code was important, and if you sent your code out to a one off contractor it would come back as unmaintainable liability.
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.
keeda 23 hours ago [-]
There is also the possibility that a lot of HN hated outsourcing to contractors for the same reason a lot of HN hates AI: they were taking our jobs ;-)
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.
mitxela 11 hours ago [-]
HN doesn't hate AI.
waffuldrop 1 days ago [-]
where is the code that was universally accepted to be good?
momojo 9 hours ago [-]
The term "injection molded coding" has been bouncing around my head lately. I empathize and have personally experienced the fragility and opaqueness the OP describes. But I wonder if we're like master carpenters, grieving as we inspect a warm plastic chair leg, fresh from the injection mold, wondering what the future of furniture making will look like when each chair leg is mass-produced, and not lovingly carved by hand.
rjbwork 5 hours ago [-]
It seems a lot of us are coming to a similar kind of analogy recently. But in this case we can still be the experts involved in building those molds.
> But in this case we can still be the experts involved in building those molds.
The idea of hand-typing the code that goes into those molds is going to seem foreign to us. We're going to look at monoliths and hand-written infra the same way we look back at the masonry of the cathedrals. We'll marvel. We'll find it beautiful. But we won't want to go back when pouring concrete is far easier.
makeitdouble 9 hours ago [-]
That's a really good analogy.
Perhaps another angle could be an IKEA product designer looking at the molded plastic and lamenting it's efficiency and cost.
momojo 10 minutes ago [-]
haha the analogy actually came to me while strolling IKEA
yodsanklai 1 days ago [-]
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.
softwaredoug 1 days ago [-]
The experience still matters.
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)
ffsm8 1 days ago [-]
Fwiw, that's not what the parent was talking about.
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
lilbigdoot 24 hours ago [-]
For me it's really hard to find a balance with LLMs. Even trying one to add .NET IR codegen to my compiler that already had a working C++, JS, and C# backend for it to use as a reference. It just kept doing really odd stuff and when we got to generics it had done such a bad job with the prior work it struggled to collect the information it needed from .NET to do generic calls correctly, and mid session decided to just make everything reflection based with no notice to me. It had a doc of the AST with notes on what the nodes mean and how different constructs are represented, it's a pretty typical ML family language. Plus a working C# backend to reference.
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
23 hours ago [-]
rsfern 1 days ago [-]
Expectations and goals can be technically nonsensical. Agents have gotten really good, but they can’t magically solve intractable problems. If you’re out of your technical depth it can be easy to set unrealistic expectations without realizing it
ffsm8 1 days ago [-]
Then you're still middle-roading it from my perspective. Treating it as a black box means you're only specifying what comes out, essentially.
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.
rsfern 1 days ago [-]
I think we are talking past each other a bit? I’m curious about GP’s perspective here
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
hugeBirb 21 hours ago [-]
Yeah I think this is the main issue at play. Bad engineers are now 10x bad engineers with the ability to hide behind the mask cause they can output something that looks right, but they don't understand it. You can "make" an agent do ANYTHING. There is no rigor, there is no taste, there is no risk. Anecdotally I have seen this play out IRL. I worked with a 3-month boot-camper that somehow stumbled into a software developer role at a small company. The amount of slop that he was creating was unprecedented. No formal training, no idea of abstraction, letting/making the agent reinvent the wheel for everything. The LLM was doing the whole "you're absolutely right" so he was also under the impression that he was a real engineer doing the "right thing". Concretely he convinced our manager that we need to re-write our web-app in Go because it was so much faster(0 users btw) and safer than python. He had an agent build out this test suite and there was a metric like Go vs Python DB operations, Go being 107x better. Seemed sus, looked into it and he(his agent) removed connection pooling for the python side but for the Go side, 100 concurrent connections, 10 idle and a connection lifespan of 1 hour. His reason for that was that the python code kept crashing every time his agent adding pooling so he had the agent removed it. This sheet got printed as is and distributed to our C-suite to much praise. I know this is a very specific example but I fear this is happening at some level everywhere. Where in the past a bad engineer to this degree would stick out like a sore thumb if they were surrounded by competent people that have rigorous standards. An LLM/AI doesn't have to worry about what happens if things don't work and when it's confirming that YOU are a genius every step of the way. It's going to be a disaster when the reckoning comes. I am not a AI luddite but software engineering is just as much as a culture as it is art and science. Without that backstop I just think that we will see a huge degradation in quality because there is no incentive for LLMs/AI to write "good software".
kyleee 13 hours ago [-]
Sounds like that colleague is on track for a Distinguished AI Builder title and promotion
hugeBirb 11 hours ago [-]
Hopefully this is sarcasm cause if so, haha. Otherwise seek help :P
snapcaster 1 days ago [-]
Sure theoretically. practically this isn't a real problem for me or anyone else i know
dwaltrip 1 days ago [-]
In the black-box approach, how do you know what is a reasonable task to give it? Just ask the agent about that also?
q4y2u35uk 23 hours ago [-]
You don't give it tasks. You give it what you want. It decides the tasks, and then executes. Then you give it feedback. "black-box approach" here is just a fancy word for vibe coding.
laszlokorte 14 hours ago [-]
I want to be rich, healthy, happy, young, smart, beautiful. Same for all my friends and family please. How many tokens?
PS: make no mistakes and tell me in advance if I forgot anything that I could regret later.
Or on a more technical side: I would like all problems that any app/company/product could solve to be solved in the best possible way, so that nobody has to even think about what kind of problems even could be solved. Go iterate on that but do not make any mistake, do not ask any questions, be done by tomorrow, do not interpret what I said in any bad way.
mhitza 1 days ago [-]
Might be true in your company, your culture, or in Big Tech.
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).
yodsanklai 1 days ago [-]
> Might be true in your company, your culture, or in Big Tech.
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.
kyleee 13 hours ago [-]
And they’ll drown you in complexity and lines of code
megak1d 1 days ago [-]
This is what I came to post.
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.
lelanthran 5 hours ago [-]
> 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.
Those new skills come pre-devalued already - they're simple and quick to acquire so if that's the new value prop, you can expect it to be a minimum wage value prop in just a few years.
geertj 1 days ago [-]
I think I agree with all you said. But I can’t let go of a clean codebase yet. It’s stronger than me. And I’m not sure I should. Or at least not yet, not until the agent can better understand what I actually want.
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.
skydhash 23 hours ago [-]
> 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
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.
drewbeck 21 hours ago [-]
Choosing readability is absolutely a practical decision.
utilize1808 1 days ago [-]
That's right. I call it "organic software" --- software that behaves like living organisms --- lots of glitches and flaws but are constantly being fixed by AI agents. 99.8% of users never run into catastrophic issues, and for those who do, a dedicated human/agent will handle it manually.
adamddev1 23 hours ago [-]
That only (sort of) works on the VERY top level - with user-facing apps.
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.
nxobject 9 hours ago [-]
> That only (sort of) works on the VERY top level - with user-facing apps.
It still leaves me with a bad taste in my mouth -- the Codex desktop client's rich text editor had a fun "bug of the week" for a bit... at one point the bottom of the control/view was occluded by blank space, at another point selecting a region and scrolling "un-selected" the region.
catdog 23 hours ago [-]
For some uses cases I think this might even work out well enough if you figure out and apply the right guardrails and boundaries. That's quite a big if though...
scott_weber 23 hours ago [-]
Funny, "organic software" is a mental label I have for how most human written software is produced/functions: software that could not be rebuilt from scratch, because it's construction was highly path dependent and dependent on implicit know-how distributed across irreplaceable individuals; an accumulation of unprincipled designs and patches.
adamddev1 23 hours ago [-]
You think it doesn't matter because you can get away with making an app that is "good enough" or "works" satisfiably.
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.
hoppp 1 days ago [-]
I can write succinct code slowly, agents can write verbose code fast.
Depends on use case
catdog 22 hours ago [-]
You can push the agent to write succinct code by working in small steps, going back and forth. You push the agent in the right direction but also the other way round because it finds a lot of stuff you might have missed, esp. in complex areas. It also oftentimes does quite reasonable things actually.
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.
softwaredoug 1 days ago [-]
I have a Stackoverflow mode for my agents (essentially a tutor) and sometimes I spend time hand coding but heavily guided by an agent. It helps A LOT to make careful tradeoff when succinct and line by line care matters.
vkgcr 1 days ago [-]
So you're essentially willingly becoming 100% dependent on AI, while praying that hopefully they'll become good enough to save you from the slopocalypse down the line.
Doesn't seem like a good strategy to me.
hoppp 1 days ago [-]
It boils down to architecting systems.
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.
vkgcr 1 days ago [-]
I don't think there will ever be a way to "steer" an LLM such that it produces the correct output 100% of the time. You can certainly context engineer your way to better outputs, but you can never reduce to 0 the possibility of the LLM making a mistake, due to inherent limitations of the LLM (perhaps what you ask of it wasn't RL'd during its training), but especially due to the fact that it will often misunderstand requirements and make unjustified assumptions.
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.
hoppp 1 days ago [-]
Not correct but you can plan in the mistakes.
E.g: I designed a modular monolith where each module is strongly decoupled so an LLM can work on it individually and if it breaks it can be ripped out and replaced without damage to the rest of the system.
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
vkgcr 1 days ago [-]
Sure but that means accepting the cost of having faulty modules running in production (and there is no guarantee that your LLM could fix a faulty module, perhaps it will just replace it with a module with different bugs. There's no way to know!)
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...
hoppp 1 days ago [-]
There are code reviews. At no point did I write no reviews, that's something you inferred.
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.
anal_reactor 1 days ago [-]
> I don't think there will ever be a way to "steer" an LLM such that it produces the correct output 100% of the time.
You cannot do that with humans either.
EPWN3D 1 days ago [-]
The difference with humans is that you can incentivize them to try and do the right thing via money. Humans are error-prone and slow, but they don't have an alignment problem, and the types of mistakes they'll make are pretty much understood. There are entire programming languages designed to minimize those types of mistakes.
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.
anal_reactor 1 days ago [-]
> The difference with humans is that you can incentivize them to try and do the right thing via money.
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?
bigstrat2003 18 hours ago [-]
No, but humans are capable of learning and improving. LLMs are not. Humans also make mistakes at a much lower rate than LLMs do.
senordevnyc 17 hours ago [-]
Really? Because my LLMs have improved more in the last couple years than any human I’ve met, and while their skills are jagged (like all humans), they routinely exceed the best engineers I’ve worked with once speed and cost are taken into account (as they should be for any true engineering project).
insane_dreamer 1 days ago [-]
> If you architect well what you generate then it stops being slop
the problem is that the "architect well" part is also being left to the LLMs
snapcaster 1 days ago [-]
[flagged]
greenowl 22 hours ago [-]
Um, yes?
That's exactly the strategy that most companies have adopted by now.
Once you go 100% AI code generation, there's no going back.
insane_dreamer 1 days ago [-]
> Is it an issue? you could think that in the long term it'll be
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.
titzer 1 days ago [-]
> Is it an issue? you could think that in the long term it'll be
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.
senordevnyc 17 hours ago [-]
Which has happened many times already under the control of the humans…
mpalmer 1 days ago [-]
Agents are decidedly not getting better at architecture by the day, but soon they'll be the best by default because we'll all be drooling idiots (speaking in terms of technical capability).
arm32 1 days ago [-]
So the agents aren't getting smarter, but rather we're just getting dumber?
mpalmer 1 days ago [-]
Both, the former more slowly than the latter.
Picture a foolish person falling out of a hot air balloon.
"Gosh," they think, plummeting, "the balloon is going upwards SO fast!"
skydhash 23 hours ago [-]
That reminds me of the usual argument by AI hypers:
“it would have taken me days/weeks/years/… to learn and produce something by myself”.
They forget that often what you need to know can be learned quickly, it’s just mastering (solving the general case) that takes a long time. Learning the piano takes years, learning how to play “Happy birthday” can be done in a few minutes.
zombot 1 days ago [-]
Meanwhile overlooking all the strategic implications of handing off your production to an external service provider, with built-in total surveillance and industrial espionage. All the software shops are turning into lemmings. Running faster into the abyss is called increased productivity. Full speed ahead!
proc0 22 hours ago [-]
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.
markasoftware 21 hours ago [-]
I used to think this too, but AI capabilities over the last couple years prove it completely wrong. The skills are more specialized per domain than I thought (though there is still a lot in common between fields)
And further, surely you know some very strong programmers who are very bad at art, or math, or human relationships?
proc0 21 hours ago [-]
Every new model is only marginally better than the last, since last year, and I'm sure they are throwing all the compute at every new model, which means it's hit diminishing returns.
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.
eluru 10 hours ago [-]
companies do not care about you doing hard programming, god they care about good programming only laterally
proc0 8 hours ago [-]
They care to the extent they don't want hard programming because it's more unpredictable and hard to hire for. The flip side is software builds complexity anyway and what I've seen is companies spending tons of money rewriting their codebases, or maintaining a disaster of a legacy system.
a34729t 1 days ago [-]
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.
mvgoogler 24 hours ago [-]
I'm finding it to be just the opposite - futzing around in the codebase is more effective than ever, it just looks different.
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.
eluru 10 hours ago [-]
check for dead code, duplicated, SOLID, DRY, and KISS are now enforced on every push as part of our CICD, other agent does this of course, no one can check so many code, still better than before when we where trusting some energetic programmer would do
jvanderbot 24 hours ago [-]
It's all gone if you don't take time for it, sure.
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.
dist-epoch 24 hours ago [-]
> great way to find dead code, suboptimal structures, etc. With AI that's all gone.
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
svieira 19 hours ago [-]
> the quality
Measured by?
curt15 1 days ago [-]
How do engineers internalize the codebase now? Do they just ask Claude and nod their head "because Claude said so"?
fernandotakai 6 hours ago [-]
yup. and it's incredibly annoying, specially when a new joiner is writing a PR that a more experienced employee is reviewing.
i had to argue with someone, more than once, that "cursor is wrong about this assumption because i originally wrote this" because they just accepted whatever model they used as truth.
emoII 24 hours ago [-]
Yes, and osmosis
simonjgillespie 21 hours ago [-]
+Coneheads and Telepathy.
solatic 22 hours ago [-]
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.
beastman82 1 days ago [-]
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.
drooby 1 days ago [-]
Step 2: Prompt the agent to comment out the "when" code and check if the tests fail. (If tests don't fail it's a poor test)
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.
stingraycharles 1 days ago [-]
It’s also a great way for AI to keep creating backwards compatible bloat code when refactoring and whatnot because “tests are failing” when those tests are testing absolutely silly stuff (LLMs have a tendency to want to validate exact output rather than behavior).
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.
drooby 1 days ago [-]
What do you mean "exact output rather than behavior"?
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.
stingraycharles 1 days ago [-]
It would add tests for exact error messages, for example. It would add tests that the process exited with very specific error codes. Basically tests that I would never ever write myself.
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.
drooby 1 days ago [-]
That feels like a pretty uncharitable interpretation of my original comment.
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.
stingraycharles 1 days ago [-]
Yeah I just don’t consider adding more or better tests as a solution to fragile code, which is the topic of the conversation.
I think it has much more to do with overall architecture and design, and as for now, human oversight.
TheCoelacanth 22 hours ago [-]
LLM's are way better at generating realistic tests than any engineer I've ever worked with as long as you are pedantic about asking for it and making sure it follows it.
zeroonetwothree 14 hours ago [-]
I find this level of testing to have many downsides. For example, it means changing behavior "breaks" 100s of tests. The LLM doesn't have a good sense of what behavior is important to cement via tests and what isn't.
stingraycharles 1 days ago [-]
I feel this is a nice theory but needs even more ruthless oversight in order for the LLM to pick the correct abstractions and types, as your tests are now effectively your higher level type system choices.
agumonkey 1 days ago [-]
which one did you use ? ocaml ? haskell ? scala ?
just curious, and tempted to do the same, so far I don't like the code made by llms in dynamic languages codebases
sausagefeet 1 days ago [-]
We do this with OCaml, and it works pretty great. I have a particular style that I like and it takes some working of skill files to ensure it adheres to it, but in terms of just writing OCaml, despite being a relatively unpopular language, I have not had issues in any model that I've used.
hk__2 1 days ago [-]
Meh, if the LLM has a flawed logic it’ll implement bad code _and_ bad tests. Tests will pass, but the logic will still be broken.
a115ltd 1 days ago [-]
How's that different from a regular human dev doing the same thing? Or an entire team of them.
hologramofham 1 days ago [-]
> How's that different from a regular human dev doing the same thing?
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.
hoppp 1 days ago [-]
LLMS definitely improve but it's the model updates.
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.
bcrosby95 23 hours ago [-]
LLMs will do things no human developer will ever do. There are unspoken default assumptions a human will not violate that an LLM will.
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.
onion2k 1 days ago [-]
There's an implicit assumption that humans will get things wrong, which is why we invented pull requests, code reviews, design sessions, unit tests (with separate reviews for those), etc.
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.
sham1 1 days ago [-]
You can't hold an LLM accountable, that's a big one. Nevertheless I foresee some people trying to shift blame to the LLM if something breaks. "Claude told me..." and so on.
lelanthran 1 days ago [-]
> How's that different from a regular human dev doing the same thing? Or an entire team of them.
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.
fergonco 1 days ago [-]
I haven't ever seen a human developer inventing requirements.
Not saying it's better or worse. But it's definitely different.
onion2k 1 days ago [-]
I haven't ever seen a human developer inventing requirements.
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.
nemo44x 1 days ago [-]
AI does it at scale.
dimbletimbers 1 days ago [-]
Can you provide any evidence for your claim?
beastman82 1 days ago [-]
I enjoy a thin veil of anonymity.
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.
DIE_DIE_DIE 1 days ago [-]
[dead]
skydhash 1 days ago [-]
> Your tests become limited to things that are hard or impossible to assert with the type system
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.
haolez 1 days ago [-]
Haskell?
thatsabadlook 1 days ago [-]
Really? Am I the only one who finds most ai code beyond boiler plate to more or less suck? Oh right it's hn, people here just don't care anymore.
user43928 1 days ago [-]
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.
glimshe 1 days ago [-]
Tell us more. What I'm gathering from your comment is that you have a personal monster project (500k LOC) fully/mostly developed by AI and you're having no problems maintaining it. Can you understand anything in the codebase? Has the maintenance cost (in AI tokens) been going up as the project keeps growing? Are users happy?
Also, sharing a link would be great if you're comfortable with the idea.
user43928 1 days ago [-]
No, I'm not comfortable linking my HN account to my name and home address.
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.
lewispollard 1 days ago [-]
> I'm still in the process of launching the app, it went live just two weeks ago.
Sorry, but at this point you have no idea what the maintenance looks like.
eluru 10 hours ago [-]
Using your own app has nothing to do with maintaining it after real users come in
user43928 1 days ago [-]
You think that after my 500h of work and daily usage of my own app, I have no idea about what 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.
hologramofham 1 days ago [-]
> You think that after my 500h of work and daily usage of my own app, I have no idea about what maintenance looks like.
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.
user43928 1 days ago [-]
I have been QA testing, fixing bugs, and adding new features near full-time for the last seven months.
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.
scott_weber 23 hours ago [-]
Not sure if you're trolling at this point but: the previous comment defined "maintenance" for you: "responding to real usage". The things you list are plainly not that.
"Maintenance" does not mean "development after the first week".
user43928 21 hours ago [-]
I'm not even sure why I bother discussing on HN, only to always get these comments from people who seem to think they know better than me about the maintainability of my own app.
I did not ask for your opinion.
globular-toast 11 hours ago [-]
Nobody knows about the maintainability of your own app, that's all they're saying. Come back when it's actually used by real people for real stuff. That's when the real problems start.
user43928 7 hours ago [-]
I find it irritating how any discussion about my extensive experience in agentic development of a large codebase deteriorates into the same boring discourse where you lot make dismissive arguments about my app not being in production for years or having millions of users.
4 hours ago [-]
warmedcookie 1 days ago [-]
Having a similar code base size for a mobile app, I believe you. No noticable issues with its size.
hackersnooze1 1 days ago [-]
[flagged]
hackersnooze1 1 days ago [-]
ok its pretty clear you have no idea what you are saying
arm32 1 days ago [-]
I can now see why you don't want to link your HN to your identity!
user43928PLUS1 11 hours ago [-]
> seem to theorize and extrapolate with no actual experience
This was you two posts ago
> it went live just two weeks ago. So far only 30 users
This is you now.
I won't read further.
thisisit 1 days ago [-]
Tell me you know nothing about maintenance without saying you know nothing about maintenance. The best part is that you call others about not knowing what they are talking about.
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.
Krei-se 1 days ago [-]
There will never be a link!
nahumfarchi 1 days ago [-]
I recently spent a couple of hours reducing 1k lines of code produced by an LLM to about 100. Purely extrapolation, but imagine what if your project was 50k instead of 500k?
user43928 1 days ago [-]
If we scale that effort up from 1k lines to 500k, I'd be spending a few thousand hours optimizing the implementation.
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.
nahumfarchi 9 hours ago [-]
I think that taming complexity might be a big part of getting agentic development to work. Entropy always wins :)
22 hours ago [-]
hologramofham 1 days ago [-]
You want to reduce lines of code? Next you'll be trying to reduce the number of PRs, then what will you use for productivity metrics?
nahumfarchi 9 hours ago [-]
I was trying to reduce the complexity of an overengineered solution, not to measure productivity.
Topfi 1 days ago [-]
sits down around the campfire
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...
grim_io 1 days ago [-]
That's a bit silly to assume the LLM will 10x all of the code.
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.
marcosdumay 23 hours ago [-]
> That's a bit silly to assume the LLM will 10x all of the code.
Oh, for sure.
I'm assuming the GGP's system can be expressed in 5k to 1k lines of Java or Kotlin.
hologramofham 1 days ago [-]
> That's a bit silly to assume the LLM will 10x all of the code.
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..)
grim_io 1 days ago [-]
Yeah you can 10x the code, if you are not required to review it thoroughly.
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.
jvidalv 1 days ago [-]
Same, I maintain a really healthy mountaineering app (6K users), I started it where we where still pasting into chat-gpt, and now fully autonomous with Claude Code.
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.
FAO Claude, the site randomly changes language as you navigate, and then gave this:
<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>
user43928PLUS1 11 hours ago [-]
I like the implication here that you're trying to talk to Claude and treating the middleman as merely a meat based proxy.
quantiq 10 hours ago [-]
At what point do we just admit, "my codebase has never been healthier" is just AI psychosis in practice?
quietbritishjim 1 days ago [-]
> In my experience maintenance does not suffer long term with codebase size, if anything it became easier with model advances.
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.
Topfi 1 days ago [-]
Purely for the models running your code base, have you ever ran an assessment of what that fragility costs you? Tool call error frequency, unnecessary test failures that the model then addresses but wouldn’t in a more parsable code base, inefficiency in navigation, anything of that sort? A model landing changes doesn’t mean it does it well.
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.
user43928 1 days ago [-]
No, since it seems difficult to assess, it's not like I have a handcrafted version of the same project to compare against.
Topfi 1 days ago [-]
Try another model just looking through the harness history and commits for blockers and errors, often eye opening.
gonzalohm 1 days ago [-]
7 months is not long term...
emehex 1 days ago [-]
Available in the AppStore? Would love to see it!
insane_dreamer 1 days ago [-]
> the fragility is inconsequential.
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.
user43928 1 days ago [-]
You'd know the answer if you bothered reading the thread before posting the one hundredth 'you need a million users to judge maintainability' comment I receive on HN.
insane_dreamer 1 days ago [-]
> if you bothered reading the thread
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
sashank_1509 22 hours ago [-]
I think the fact that you have 500K LoC is a problem already. It could have been 50k without AI.
chrisra 22 hours ago [-]
I agree with the 50k comment, but depressingly, it might not actually be a problem.
win311fwg 22 hours ago [-]
I did an analysis on the code I'm currently working on pre-AI and post-AI. There is no appreciable difference in implementation code size before and after, but the total LoC has grown substantially from having a lot more test code.
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).
sashank_1509 22 hours ago [-]
I strongly disagree AI generates codebases of the same size as humans excluding test code. You can just look at Codex, codebase that is almost millions of lines of Rust Code (source) for a desktop app/ Terminal UI’s. I saw a lab employee somewhere cope on X by saying their terminal UI is as complex as a game engine, but last I checked, they just need to generate some 2D pixels, not entire 3D worlds with physics and sounds that is done with ~500k lines of code.
win311fwg 21 hours ago [-]
LLMs are laughably bad at writing code in some languages and shockingly good in others, so I can see that being the case if you chose poorly. But, especially when you have decided that you aren't even going to look at it, why would you use a shitty language?
hk__2 1 days ago [-]
Was it a preexisting 500k LOC codebase, or has the whole codebase been generated by LLMs?
user43928 1 days ago [-]
I started the project during 'copy snippets from ChatGPT web' days, so technically not entirely generated, but I don't think much is left of those days.
hk__2 1 days ago [-]
Then the number of lines of code doesn’t mean anything.
keeda 23 hours ago [-]
Why? It’s not like the AI one-shot 500K lines of code.
ActionHank 1 days ago [-]
“I have 500k line of slop”
“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”
user43928 20 hours ago [-]
I'm confident that it's a better product than anything you produced, and I don't see why I should continue taking these kind of comments.
ActionHank 6 hours ago [-]
Weird to be butthurt over people mocking your ai output.
user43928 5 hours ago [-]
I'm passionate about my work, and this is a forum for discussing technology and entrepreneurship. You can take your mockery elsewhere.
thatsabadlook 1 days ago [-]
Nah, Ive seen sloppy code bases. They really are hazards to the operations and companies they support. I'm not anti ai, but people opting to lose complete control of their own products so there engineers don't have to think are suffering from it, and it will get worse and worse and worse.
slopinthebag 24 hours ago [-]
it's really hard to judge because depending on what the app does it could be reasonable or total slop.
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 :)
madaxe_again 1 days ago [-]
I have a similar position - maintainability of code written by AI no longer matters in any meaningful way, as as the models advance, one simply rewrites.
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.
rsfern 1 days ago [-]
Interesting analogy choices. Aren’t straight razors still the highest quality shave? We go with electric and cartridge because it’s faster and cheaper and takes less skill to get a decent result
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
madaxe_again 1 days ago [-]
Yup - I think there will remain a space for artisanal code for a decent while yet, particularly in things like scientific computing, safety critical systems, and similar - but for most purposes, the cartridge shave will be good enough, more convenient, and much, much cheaper.
hackersnooze1 1 days ago [-]
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
missingcolours 24 hours ago [-]
Unfortunately the fact that you can't see (or understand) the quality of the components that make up your car doesn't make it less important. And low quality components can look like they're working fine until they blow up in your face.
OtherShrezzing 24 hours ago [-]
Having contracted in a company that tipped over from subscription token pricing to API token pricing recently, there’s still extremely good reason to keep your software a transparent.
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.
catdog 21 hours ago [-]
Yep, fully leaning onto those subsidized subscriptions and closed models is dangerous. At the very least keep it at a level where you can fallback to some cheaper, preferably open model which has predictable pricing you can actually afford.
mrbombastic 23 hours ago [-]
this is kind of blowing my mind, have engineers here peeked at a bill for a medium to large size orgs token usage? growing all the time and yet everyone's solution to the inevitable issues that come from letting go of the wheel is to have Fable 12 come and rescue you. have fun tying your destiny to unpredictable recurring costs, or we could just be engineers and understand the things we build.
wpietri 23 hours ago [-]
Agreed! And unpredictable recurring costs that could easily end up being controlled by monopoly/oligopoly players who have investors with expectations that run from aggressive to hallucinatory.
hand2note 1 days ago [-]
Product quality still matters which is a result of code quality rather than the number of features you've shipped in the last week.
leptons 24 hours ago [-]
You are both correct.
We'll have to wait and see how many companys get hurt by overuse of AI coding, the one I work at included.
truncate 24 hours ago [-]
I don't give code quality a consideration at my job, as that is the expectation. I'm on-paper delivering more projects and "more productive".
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.
catdog 22 hours ago [-]
That's a big problem I think. We should use those tools to improve applying our practices. Along the way we might figure out that we can and should do things differently. But just throwing everything away, hoping for the best, does sound like a recipe for disaster.
chasd00 23 hours ago [-]
The agents are pretty good at documentation too. You can point them at existing codebases and have decent docs generated (way better than you're average dev can produce). You can also very quickly re-generate them from the ground up whenever a round of changes are done.
"An agent wrote the code" is not an excuse for failing to understand how the system works and fits together.
tensor 18 hours ago [-]
That's ridiculous. If you're not considering code quality as part of your agentic review you're "doing it wrong." Even if it's just the AI reviewing it's own code, you absolutely should be considering code quality. Both in test coverage, security, correctness that might have been missed, and hygiene.
If you do multiple review passes you almost always end up picking up numerous issues in the first two passes, sometimes quite crucial.
ionetan 23 hours ago [-]
I think there is more to it than that. Even if we don't read all the code, it is still essential to comprehend the core structures that carry the weight of the program. Wrote something up on that subject some time ago, arguing that agentic code is a little like a fabric, in need of structural support to be practical at scale. In case it interests anyone:
Software was always a black box to non-coding execs, but quality still mattered to them, at least indirectly via feature velocity, user experience, reliability, and operational cost. That hasn't changed.
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.
jarjoura 24 hours ago [-]
I guess that’s an advantage for engineers who are curious and continue to know how the thing actually works.
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.
unrented7977 23 hours ago [-]
Refusing or being unable to understand the problem does not mean there is no problem.
jryan49 24 hours ago [-]
I've found if the code quality gets bad enough LLMs even get stuck trying to edit it. Can use LLMs to refactor it, but LLM will never suggest that if it gets stuck in loops :)
I think we're being set up to be corn kings. A corn king is someone who the tribe makes the king, obey his every command, lavish him with wealth and pampering, all as long as things are going well. As soon as the corn harvest comes in a little bit short, we sacrifice the corn king to the gods in order to regain their favor and fix the harvest. No one cares about code quality and I can spend my days being richly rewarded for telling Claude what to do and then blindly shipping its output til we have a major prod outage or security breach, whereupon I am taken out back and shot.
Seattle3503 10 hours ago [-]
I've heard that called a moral crumple zone in the context of AI.
nxobject 8 hours ago [-]
Or perhaps in a more "enlighted society" you get taken to the benchmark/post-training material writing gulag, and suffer the indignities of having to teach AI how not to make your mistakes. Confess your sins to GPT-225 Galaxias for the honor of RAM Altman!
ndiddy 24 hours ago [-]
Over time the codebase will get more and more bloated, and making changes will take longer and cost more tokens. You'll start losing your grasp on how the codebase works, to the point where you can't even tell if the agent is doing the right thing or not. You'll be lulled into thinking that the code is correct from the tens of thousands of AI generated unit tests and the 100% line coverage, then you'll start noticing bugs pop up when you actually try to use the product. You tell the agent to fix the bug. It makes a patch and adds another dozen regression tests. You re-test the product. The bug has been fixed, but now there's a new bug. This is your life now.
And Anthropic will happy sell you the newest model, tuned specifically for these problems. At a premium of course.
adamors 1 days ago [-]
Code quality was a concern maybe at tech companies, in every other industry it was never a concern, in fact you were shunned if you mentioned code quality because then you were not doing Product Thinking™
jhallenworld 22 hours ago [-]
I've been thinking recently about this. Given that it's a black box: I think it's better to have the LLM write Rust code than Python, node.js or anything else. You might as well use the strictest possible language to improve the chances that the code the LLM writes is safe even maybe if you are not a Rust specialist.
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.
JohnMakin 23 hours ago [-]
says person who has never been on a pager
edgarvaldes 23 hours ago [-]
This view is defeatist, and one hundred percent correct. The programming profession as we once knew it no longer exists. Artisanal programmers will soon occupy the same niche that Emacs users did in the past (with the occasional "Why I still code by hand" blog post). The greybeards will gradually fade away, while new code generators (human or artificial) will get the job done, with no regard for how things were done just two or three years ago.
chasd00 22 hours ago [-]
My son brought up a good analogy using blacksmiths. They use to be the experts in manufacturing tools and other useful things then factories came along and at first the quality and output wasn't that great. Factories started improving and pretty soon no one needed blacksmiths and no blacksmith could match the output of a factory. When the blacksmiths weren't getting any work people would probaly say "well go work for the factory" to which a blacksmith would reply "but a blacksmith is who i am, i don't want to just pull a lever and push a button and out comes a part. How can you truly know it was made with care unless i do it myself by hand?".
I thought it was a pretty insightful point coming from a 16 year old boy (being a former 16 year old boy myself).
catdog 21 hours ago [-]
> "but a blacksmith is who i am, i don't want to just pull a lever and push a button and out comes a part. How can you truly know it was made with care unless i do it myself by hand?".
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.
drewbeck 21 hours ago [-]
> they only cared about the manual part of the job
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.
skydhash 20 hours ago [-]
> 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.
That argument has been repeated so much while all the experienced developers keep saying that coding was not the hardest part of the job. The hardest part was adding the new changes while ensuring the system doesn't break and that it's still easy to modify later. In the latter case, intuition plays a big role into labeling what is a core truth of the system (unlikely to change) and what is a transitory need.
Coding was just something you do (and relax while doing so), not something you put your whole being into. When I code, I mostly think about the system. Which is why I look at the docs and my notes often to check the semantics of whatever symbols I want to use. I don't think about the actual typing of the code.
That's the actual argument against agentic coding. No one is checking semantics, it's hope and prayers that the software is correct.
win311fwg 21 hours ago [-]
> no one needed blacksmiths
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?
jolt42 23 hours ago [-]
I've see agents get confused by a human's code comment and muck it up, so just get agent to rewrite from scratch.
sarchertech 22 hours ago [-]
Why so defensive? People who are secure in their positions don’t have to say things like “get used to it”.
spacechild1 23 hours ago [-]
I can't speak for commercial software development, but that's very much not true for open source software. Personally, I don't want to use software that is a black box. That's the reason why I'm using FOSS in the first place.
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".
whateveracct 24 hours ago [-]
how can you confidently evaluate this sort of thing on a 6mo timescale
mpalmer 1 days ago [-]
Code quality is no longer a concern to almost anyone
If that's true (and it is not), it's only because almost anyone is "making" code now. That they don't understand the importance of code quality means nothing; it remains important without them. And professionals certainly don't need to pay attention to these inane oversimplifying takes of "what software is now".
CuriouslyC 4 hours ago [-]
In terms of code organization/cleanliness, these models are getting very good at untangling sloppy messes, to the point that assumptions about the cost/benefit tradeoffs of well designed software don't really hold anymore. Good architecture still matters though.
leptons 24 hours ago [-]
My company is all-in on agentic coding. We've been building a new product with it for the last 4 months. They talk about "AI governance" but I think nobody knows what that means. They have the AI writing the code and doing code reviews and everything really.
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.
yyx 19 hours ago [-]
> found one file was 20,000 lines long. It was an awful mess with too much going on.
If that's the worst you can say, then it's done a pretty good job.
realusername 23 hours ago [-]
We're going to the same direction in my company, AI produces and AI reviews it which I feel is kind of like shaking your own hand.
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
dawnerd 23 hours ago [-]
I'm still holding down keeping a human in the mix where I'm at now but it's a tough battle. Other problem with AI review is it will try to find issues that are not issues and you can get in this loop of an agent fixing something, triggering another review, fixing those findings and basically going in a circle. Has happened multiple times now which ends up with a massively overbuilt task that would have taken a human a few minutes to just do to begin with.
realusername 23 hours ago [-]
Yes indeed, we have the same problem. You can run these agents 10 times and 10 times they will find different issues. It makes me trust the AI reviews even less, is the new feedback accurate if the previous one didn't catch it?
whateveracct 20 hours ago [-]
I was holding it down (getting plus performance reviews even!) by hand..but then my skip level said I couldn't get a promotion unless I was AI native.
I immediately stopped writing any code by hand. If they wanna pay me more to do a worse job, more power to them :)
zquzra 23 hours ago [-]
What did change? It's always been like this: ship fast, fill your pockets, wait a while, then enshittify. Nothing's changed in this industry.
throwayay58373 24 hours ago [-]
When was code quality ever a concern?
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.
throw-the-towel 23 hours ago [-]
I feel that before LLMs I could smuggle quality code in, without the managers knowing. Now, I cannot -- I'm visibly too slow if I'm trying to.
spacechild1 20 hours ago [-]
In many open source software projects.
abalgir 1 days ago [-]
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).
AI doesn't "lack" it, it just may have less of it, and the gap is closing. Like it or not.
dofm 1 days ago [-]
An LLM can't have intuition itself.
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.
amelius 1 days ago [-]
> 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.
I'm sure the training data of LLMs contains a lot of those things, though.
dofm 1 days ago [-]
It contains the averaged written ghosts of the outcomes of those things (as well as, I am sure, some descriptions of those experiences, attached to descriptions of the outcomes — "so I was sitting on the bench on the common and…" would be routine in a training set derived from me!)
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.
Leynos 1 days ago [-]
Coming soon: language models trained on 2000 years of tactile, proprioceptive, spatio-temporal, calorific, olfactory, gustational, humidity, temperature and barometric data.
The downside: the model doesn't always have words to describe what it's feeling.
dofm 1 days ago [-]
But it knows to blame it on the dog :-)
krige 1 days ago [-]
It may contain writings about these things, not the actual things. That's more like saving a jpg at high compression over and over if you want catchy metaphors.
dofm 1 days ago [-]
FWIW, I guess it probably doesn't always matter too much in a tool where you want a logical, correct, standard, robust outcome like agentic coding.
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.
mitxela 11 hours ago [-]
An LLM is nothing but itchy brain feeling. Its neural network is trained to output "there is a solution" whenever there is a solution, before "knowing" what the solution is.
kelseyfrog 1 days ago [-]
I employ a qualia harness that provides these cases to the LLMs I use.
amelius 1 days ago [-]
Is that harness connected to a human?
gonzalohm 1 days ago [-]
You think that AI understands your code deeply, and the purpose and context that exists outside your code?
menaerus 1 days ago [-]
Yes, it does, much more than the person sitting next to you or yourself. I wrote probably 1-2 MLoC in C and C++, and I literally see no reason why would I not be using the AI to produce code when it's already much better than I am, and much better than pretty much anyone I know or have worked with.
amelius 1 days ago [-]
For all intents and purposes, yes.
(as it would apply to a human software engineer also)
1 days ago [-]
kelseyfrog 1 days ago [-]
Humans still havent't accepted The Bitter Lesson[1].
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.
Its disturbing how some humans consider themselves flesh clankers
pen2l 22 hours ago [-]
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
iforgotmypasswo 6 hours ago [-]
What do you want to know about your code?
Are you really not capable of writing a test or a linter that shows you the patterns you care about?
Imagine you had a team of 100 developers and you needed to enforce controls over the software and how it operates. Would you do that with trust? Could that survive an audit?
Yes, if you just throw prompts at AI and assume natural language is enough to properly influence how the code is built, the code base will be a fragile ball of mud.
If you consider your new job to be deterministically constraining the output and creating visibility for all items that really matter, then this doesn’t have to be the case.
fauigerzigerk 1 days ago [-]
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.
sirius87 1 days ago [-]
Has anyone figured out a good way to fix shallow tests with AI? Intuitively, in webapps, there are many minute UX things folks on the team used to manually dev-test. not saying that was done consistently across all team members or always done, but it existed.
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.
sadilek 1 days ago [-]
For UX specifically, I have good experience with letting the agent record a demo video for me. It regularly finds issues itself while doing this and fixes them, and I get a chance to very efficiently see the UX w/o having to start a dev server and navigate somewhere and create a certain state before I can see the UX.
softwaredoug 1 days ago [-]
I spend most of my time structuring code to be meaningfully verifiable. To me that usually means turning a large functional area into a CLI. So for example I have a pipeline of processing and enriching products for search. Thats a CLI whereas before it might be a module in my larger codebase.
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.
sirius87 1 days ago [-]
thanks. I guess the problem is more acute in larger codebases, where the code AI writes takes "inspiration" from existing human-written code (i.e. conforms to earlier human opinions), so it doesn't go out of its way to write meaningfully verifiable new code - because that would stick out like a sore-thumb in a code-review.
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.
hatch_q 12 hours ago [-]
This is simply lack of guidelines. If you didn't take the effort to write rules/tests.md (or ask llm to do it for you), the blame is on you not on AI.
happy_dog1 23 hours ago [-]
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.
orthogonal_cube 22 hours ago [-]
Someone made a comment the other day about how silly it would be for people to continue using hand tools when the electric motor was invented.
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.
perlgeek 20 hours ago [-]
Note that "hand-crafted" furniture is usually still built using power tools: electric planers, electric saws, routers etc.
The real difference is that a carpenter actually talks to you when you order your furniture, and builds something custom to your specification. The quality of the finished cupboard wouldn't improve if your craftsman only used hand tools.
I suspect something similar will happen for software: For some applications, vibe code is good enough. For others, a human will do software design (possibly with machine assistance), hand-writes some parts, delegates other parts to an AI but still reads it.
Purely-human-written code will be akin to furniture built using only hand tools: a piece of art, or maybe product of a hobby or a religious ceremony rather than a practical necessity or a practical advantage.
zeroonetwothree 22 hours ago [-]
Average people aren't going to be writing their own software, even with AI tools. They will use AI tools to achieve goals directly and perhaps it will write software in the background (but that would be an implementation detail).
happy_dog1 22 hours ago [-]
Yes, thanks, that's what I meant / was trying to say. They want to do X on their computer and formerly they would have had to purchase software to do so; in the future perhaps they will instead ask the AI tool to do X and it will write whatever code is needed to do X. This will work well enough until it doesn't (which is where the "premium" market for handcrafted special-purpose tools might continue to thrive).
francisofascii 5 hours ago [-]
AI gives us the ability the rapidly speed up development. Great, now we have more time to devote to code quality. Except that is not what is happening. We need to be going 10 - 100x speed. Code quality is no longer a real goal. It seems like the developers who pushed for code quality before AI are simply getting railroaded by the people who quietly never believed in it in the first place.
soon_to_be_sb 1 days ago [-]
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".
Simmer down lad, you are sounding like a Redditor.
soon_to_be_sb 1 days ago [-]
Am I?
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...
arstep 21 hours ago [-]
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.
geon 21 hours ago [-]
> much better code than an average human being would.
Assuming you mean an average software developer, that's still an incredibly low bar.
frodowtf2 20 hours ago [-]
I honestly don't understand what your intention with this statement is.
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?
geon 5 hours ago [-]
Exactly. ”And?”
That the ai is better means nothing. It is still pretty bad.
danmcr 6 hours ago [-]
I 100% disagree with this take, AI has made it much easier to reduce incidents, expedite resolutions and clean up messes that took place before AI was a thing.
I feel that a lot of folks that have worked at FAANG or tech first orgs overestimate how good the average company repo is.
1 year ago, I'd 100% be on your side, but we can't ignore the progress that models have made over the last 10 months.
iotage 11 hours ago [-]
My contention is that we are really observing a human programmer issue. An attribute of our so called “engineering” based profession.
An AI is arguably capable of refactoring a ball of mud into something better, or not writing one in the first place, if we could show them how. I suggest we don’t know how to, other than slogans like “clean code”?
xphos 16 hours ago [-]
I don't like AI that said everything this guy says is basically true of human code too. Humans use bad abstractions, write crummy tests, don't understand what actually happens, make things too complex. You are desribing things a human does. No AI's are not human's but its really ineffective use this line of reasoning I think because the issues are not that AI can mess up in these ways but rather that people don't believe you or you cannot make an effective statement against this.
armanckeser 1 days ago [-]
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.
yurish 1 days ago [-]
What will happen if leading AI labs go belly up tomorrow?
perlgeek 20 hours ago [-]
You can improve the quality of an existing code base even with existing open-weight models.
armanckeser 1 days ago [-]
What happens if an asteroid hits earth?
bigstrat2003 17 hours ago [-]
Well, the current models haven't delivered any meaningful improvement over the previous models, so one would expect the new generation to be similarly unimpressive.
cedws 20 hours ago [-]
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.
karim79 21 hours ago [-]
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.
dgunay 21 hours ago [-]
This isn't uncommon in the gaming industry, or at least, I'd assume it isn't based on how many game executables and debugging tlm/logs appear to bear the name of a working title or codename instead of the game's actual release title.
karim79 21 hours ago [-]
Yep. I'm only an aspiring game developer at this stage, and I had to learn this lesson the hard way. I'm not blaming the AI.
mitxela 11 hours ago [-]
As a human couldn't you just find/replace/review?
olives 17 hours ago [-]
This resonates with me in my work, and it's not the AI usage that is making our codebases fragile. It is the lack of code review or use of AI to essentially "automate" code review that is the major culprit.
Among myself and all the colleagues that I work with, I am the only person remaining who reviews every line of code to make sure I at least understand what the written code is doing. And when I review AI-written code in this manner, I almost always find flaws-- overchecking of weird edge cases, underchecking of conditions that might lead to ambiguity, importing a whole new library to handle one special case that happens <1% of the time, etc.
This is disappointing to me because just a few years ago, at my last job, thorough code reviews were the norm. And it resulted in good, maintainable code.
retrac98 1 days ago [-]
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.
pamcake 1 days ago [-]
in order to make sense of this comment it would help to know what kind of codebase(s) you are referring to like what language and application(s).
retrac98 1 days ago [-]
In this instance, a monolithic rails API for a series of iOS apps with a few million daily active users. But I also work on some other TypeScript projects and have felt similar benefits there.
soon_to_be_sb 1 days ago [-]
> tends to come from the AI being very thorough about ensuring the code does exactly what’s expected..
So terse and flexible code can't be made to do exactly what is expected?
mr_big_bowls 7 hours ago [-]
I'd ask for a second alert in the same PR. If adding it means copying another 400 lines, you've got a pretty good reason to clean up the first one.
luckystarr 23 hours ago [-]
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".
stickfigure 22 hours ago [-]
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.
luisgvv 22 hours ago [-]
> Each pull request comes faster than the prior one and has to be reviewed in even less time. This leads to developers skimming the code and missing crucial details that result in long term tech debt.
Eventually unsupervised code leaks because you stop reading the 3rd (+1200, -350) pull request
stickfigure 3 hours ago [-]
This comes from making stories too large.
You have to decide if you're going to vibe code or not. If you are going to keep humans in the loop, the chunks need to be manageable. You can have shallow changes to lots of files, or you can have deep changes to few files, but you can't have both.
The AI will do this for you. It'll even break down stories into manageable chunks for you. You just have to ask.
amelius 1 days ago [-]
We just need new Software Engineering books that explain how to build software in the AI age.
gonzalohm 1 days ago [-]
And people will ask AI to read it for them
amelius 1 days ago [-]
Those techniques could in turn help agents, yes.
aryehof 12 hours ago [-]
> I've fully made the switch to generating 100% of my code using AI because that's the expectation today.
I’m confused how to reconcile this with the conclusions presented. Is a fragile code base therefore inevitable? Perhaps the point is that expectations should/will eventually change?
lf88 1 days ago [-]
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.
CharlieDigital 1 days ago [-]
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.
catmanjan 1 days ago [-]
Read his first point bro
CharlieDigital 1 days ago [-]
AI will write tests to the level of depth that you ask it to.
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
What's useful is to have a second agent that reviews the tests impartially and trim the ones that are low signal.
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.
I disagree. A human can orchestrate AI to produce code better than if it was written by a human. For sure, a complex system requires more design thought but when has that ever been different.
shermantanktop 22 hours ago [-]
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.
skc 11 hours ago [-]
If anything, AI is exposing just how fragile pre-AI codebases actually are
cagz 23 hours ago [-]
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.
cesarb 22 hours ago [-]
> There was a time when all tables were made by hand. [...] Then the industrialisation came; factories started making tables. [...] Software development is just in the middle of this transition, [...]
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.
mitxela 11 hours ago [-]
It was when tape readers replaced toggle switches. Then it was when assemblers replaced hand-written machine code. Then it was when compilers replaced hand-written assembly. Then it was when FormMaker and Visual Basic replaced hand-written code. Then it was when HTML replaced hand-positioned GUI widgets. Then it was when React replaced HTML. The whole industry is replacing a thing with another thing and then discovering the new thing isn't a panacea either.
And nobody ever hired an army of programmers to write assembly. These improvements in capability have always resulted in more demand for programmers, not less, via Jevon's paradox. Is this also true with AI? Remains to be seen, but it's arguable we had too many bad programmers before AI since they were shoved through React bootcamps, and most tech products are useless, and some culling is overdue.
_ink_ 1 days ago [-]
The question is, is it really a problem when letting agents rewrite everything better costs not that much.
NewLogic 1 days ago [-]
Sounds like constant shotgun surgery.
simonw 23 hours ago [-]
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.
martythemaniak 23 hours ago [-]
I'm dealing with this now because I'm working on something that is very far outside my familiar domains so even if I had the time to hand-code it, I wouldn't be able to do it.
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.
amatheus 14 hours ago [-]
I see lots of people taking the challenge of creating software without looking at the code. Do you think this is at odds with what you've said about creating a more robust codebase? Is your robustness criteria satisfied by not looking at the code but doing other things like testing or do you think looking at the code is necessary for robustness?
simonw 12 hours ago [-]
I don't think looking at the code is the only way to a robust codebase these days - at least not at the line-by-line level.
What matters more is the higher level architecture, and the testing strategy, backed up by tooling like fuzzers and maybe even formal proofs.
LLMs open up all sorts of tooling that wasn't feasible to use for most projects.
mkarliner 23 hours ago [-]
well said,
and it's the position I'm taking, using AI to be more considered, more willing to refactor, more prepared to be scrupulous about clean architecture .
1 days ago [-]
mgdev 24 hours ago [-]
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!)
Nekorosu 1 days ago [-]
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.
vkgcr 1 days ago [-]
Product quality is an emergent property of code quality.
Nekorosu 1 days ago [-]
Code base is an emergent property of a product (that can have no code at all in practice). I'd even argue that the less code a product needs, the better — with no code being the ideal.
jakeinspace 20 hours ago [-]
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.
microsoftedging 1 days ago [-]
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.
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.
KylerAce 22 hours ago [-]
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"
robotburrito 16 hours ago [-]
I think people will stop caring about quality as the layoff culture keep chugging along. Maybe many will say “who cares I won’t be here in 6 months anyway” and just YOLO the code base.
mcv 22 hours ago [-]
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.
snarfy 1 days ago [-]
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.
mydreamof 24 hours ago [-]
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
shantnutiwari 8 hours ago [-]
Nobody commenting on the real fcuked up shit in the blog?
" I generated at least 90% of my code using AI in my last few months there, which was the minimum for a decent rating"
"I've fully made the switch to generating 100% of my code using AI because that's the expectation today."
This is really sad? Am I the only one who feels so????
jasonm23 14 hours ago [-]
AI ONLY usage, and without engineer SKILLS generates a fragile codebase, as does an uninstructed Jr dev.
CurleighBraces 1 days ago [-]
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.
tarkin2 1 days ago [-]
It seems obvious--and correct me if I'm wrong--that using AI requires less mental effort; and a less exerted mind is a weaker mind. A weaker mind will continue to create more and more fragile code.
thisisnotgreat 1 days ago [-]
Well, it's a nice thought-stopper by now, but IME it requires more and I can see the oldschool devs struggling with it every day.
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.
jansport123 1 days ago [-]
we'll recalibrate eventually based on understanding what level of abstraction we can operate on. If these code bases become unmanageable then the trend will correct itself.
n4r9 1 days ago [-]
I can't imagine a broad movement of devs using AI more thoughtfully without a widespread incentivisation from employers. And I can't imagine the latter at all. We'll probably just have to cope with more brittle/fragile codebases.
epihelix 1 days ago [-]
> We'll probably just have to cope with more brittle/fragile codebases.
Is this not incentive enough to use AI more thoughtfully?
n4r9 1 days ago [-]
It's tricky when it comes to performance evaluation. Metrics like token usage or story point "velocity" are easy to conjure up even though they mean little. The kind of careful work that goes into building robust, maintainable code drags such metrics down, and it's very hard to quantifiably gauge their positive effects.
w4der 1 days ago [-]
Not when many companies still think that they'll die if they don't ship enough new features.
soon_to_be_sb 1 days ago [-]
>we'll recalibrate eventually based on understanding what level of abstraction we can operate on...
This would be at the level of helper functions < 10 lines of code.
duskdozer 1 days ago [-]
I doubt this if the patterns of tech/software over the last <x> years remain. We'll just get buggier, worse-functioning, more expensive products/software built by fewer, more burned out developers. But your manager will love the sales presentation, so all will be well.
lynx97 1 days ago [-]
> I say that as a frustrated slop fighter.
That part was obvious, no need to explain it.
NegativeLatency 23 hours ago [-]
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.
jvreeland 15 hours ago [-]
Most code isn't run most of the time. If you're working in a closed codebase with defined flows no one really gives a shit. As your company and your users usecases become varied you code get better. Open Source is great lots of high quality code. There are equal and better internal codebases at the high end of usage imo primarily because of exposure and the culture that has brought.
I think at the end of the day people want to believe they're writing programs proofs but outside of very specific use cases most people are implementing good enough until shit hits the fan.
damowangcy 23 hours ago [-]
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.
latentsea 22 hours ago [-]
>Coding itself is deterministic, but code quality and the product aren't.
Unless you have a definition you can articulate well enough to enforce on pre-commit hooks and at compile time.
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.
jdpigeon 22 hours ago [-]
These rules are so true they sound obvious. It's time to start pushing back on leadership to make them aware of them.
rurban 29 minutes ago [-]
Only if you suck, yes.
In my cases AI usage generated better and more stable codebases, without exception.
klaussilveira 5 hours ago [-]
Most points outlined in this article already have plenty of solutions available. Shallow tests: mutation testing, BVA, fuzz testing. Overly complex code: Cyclomatic complexity, halstead, npath complexity (all automated with SonarQube/Lizard/NDepend and similar).
All these issues were already an issue with humans. No one did TDD "the right way". No one did BDD "the right way".
I find it amazing that fancy markov chain machines had to start generating code for us to even consider caring about automated testing and automated code quality analysis using proper code metrics.
mikewarot 16 hours ago [-]
Let's look at this from an engineering perspective: (Disclaimer: I'm not an Engineer, but I have been a technician, and a programmer)
When you're building a structure of any type, you need to get the foundation right. You have to use qualified materials that have tested and predictable characteristics. You can't just use any random truckload of dirt as filler for concrete, for example.
AI generated code is random fill, and we don't even have a good way to screen it yet, to get out the old tires, construction debris, Jimmy Hoffa's body, etc. You can't have a person judging every cubic inch of fill for quality, it's not scalable, but that's what we're collectively trying to do with AI code.
cmiles8 9 hours ago [-]
While I don’t disagree with the headline, my first reaction would be “have you ever seen the typical codebase produced by a corporate dev team?” The bar is incredibly low.
hn_submit 14 hours ago [-]
I'm biding my time and continue to code everything by hand. At some time the technical debt that A.I.s create will become unworkable and unmanageable and the "programmers" won't be able to fix it leading to a failure of the company.
Either that or I'll end up a dinosaur in a world of primates.
volkanvardar 11 hours ago [-]
I don't think it generates more fragile codebases than humans do. But definitely faster. You can create a fragile codebase 10x faster.
rokkamokka 1 days ago [-]
AI Without Oversight Considered Harmful :)
IvanK_net 1 days ago [-]
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
jhatemyjob 14 hours ago [-]
That's a great analogy, especially when you consider the struggles with transistor density that started cropping up 20 years ago.
Kinda like the struggles with getting the context window bigger than 2Mtok... for the past 3 years...
t43562 10 hours ago [-]
...and of course now we're going to hear at length why nothing matters other than maintaining the show of being highly productive.
We of course know that human code often isn't that good anyhow...and the people who wrote it similarly are not likely to see why AI code isn't great - after all they judged what they did before as being ok.
Nowadays if you don't use enough AI you get told off by your boss. If it's so great why the pressure? Why is any objection or even minute qualification rolled over? Why is it scary to point out the slightest problem in a meeting?
It's all cast as a race and everyone is scared to loose the race whether it's companies or individuals so everything is to the max and consequences be damned. How wonderful for the AI companies!
ntnsndr 16 hours ago [-]
I'm gonna give my agent this article as a prompt to review my codebase.
flossly 14 hours ago [-]
I do not really agree... Point by point.
> 1. AI writes shallow tests
I've seen test coverage go up a lot for some companies I have insight in. Some test may be shallow, but all in all there are a lot more tests and in general better test. TDD is on for LLMs in all those projects.
Try having your LLMs critique/improve your test code by telling it to: look for bad tests, look for ways to speed up the tests, make the test code more accessible to humans, look for test gaps (coverage tool helps here), etc. I've only seen test code in general do better, but it takes a bit of time writing CLAUDE.md instructions to have it your way.
Also: Architecture tests. I have soooo many of these now, because they restrict architecture mistakes LLMs (and humans) can make. I even have architecture tests for my test code!
> 2. AI writes overly complex code
I have a clear definition of "complicated code", and that it inspired by functional programming. Classes are more complex than records and functions; result types (usually some kind of sum-types) are easier than exceptions. I instruct my LLM to use the least complex construct to fix something. I tell it to do it in functional programming style unless it becomes awkward.
So mocking/stubbing/etc is forbidden in favor of fakes. So dependency injection frameworks are forbidden in favor of just passing the dependencies as parameters.
Since it's a SaaS it is usually doing something that has already been done. I've supervised it a lot more some time back, and when cleaning up the code. Now the example is clean and clear, the LLM often follows suit properly in my opinion.
> 3. Reliance on AI decreases human understanding
I do not have to understand everything, all at the same time. But the architecure is very clear and many rules are set in the LLM and human instructions that have been developed along the project. Documentation is MUCH more up to date since using LLMs in the project I saw. Even if only because though documentation we instruct the LLM, AND the LLMs tell you when docs do not match your envisioned approach or some existing piece of code.
> 4. AI moves too quickly to maintain a high quality bar
This is a business decision. Big projects (with many devs collaborating) had this problem before LLMs. Learn from how they've been doing it... You simply have something very akin to a much bigger team. It could be that you just like wokring in small teams: that's alright.
exabrial 23 hours ago [-]
No. The lack of a good architecture and design blueprints do. This is literally the exact same problem before AI.
hintymad 23 hours ago [-]
> 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.
ricardobeat 1 days ago [-]
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.
cassianoleal 1 days ago [-]
When I guide a junior engineer, I'm helping a human being become a better version of him/herself, who also helps me grow as a human being and will contribute with their unique ideas and world view, to the team, the organisation, the industry and society.
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.
ernst_klim 1 days ago [-]
> You provide guidance
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.
ricardobeat 1 days ago [-]
How do you suppose project leads, principal engineers, EMs provide guidance? You don’t have to read the code being written by entire teams/departments for that.
ernst_klim 1 days ago [-]
They don't. They manage highly autonomous very well educated senior engineers, who can do the work autonomously. LLMs can't, they are closer to interns with dementia (and occasional genious revelations).
majorbugger 1 days ago [-]
And you end up rewriting this stuff yourself.
ako 1 days ago [-]
If you are a bad senior, yes. If you are a good senior you train the junior so his output will improve and you train the agent so its output will improve.
bahung1221 8 hours ago [-]
[flagged]
gonzalohm 1 days ago [-]
So what's the point of the tool then? So much for saving time, if I have to mentor it like a junior I much rather have a person to mentor
hhjinks 1 days ago [-]
That was how I understood "code was never the bottleneck". If I need a deep understanding of the code, I might as well write it myself. It won't increase the time I need for the task appreciably.
gonzalohm 1 days ago [-]
Exactly, same thing with considering AI a higher level language. If I have to think of all the corner cases and design choices in plain English, then I much rather use a programming language whose main purpose is exactly to define cases and behavior of your design
23 hours ago [-]
fxwin 1 days ago [-]
> 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.
gnegggh 10 hours ago [-]
pasted the article to fable along with "pls fix".
ur-whale 6 hours ago [-]
> And that's the third issue with AI codebases: Humans don't understand them.
How many devs read the compiler output or care how understandable it actually is?
I know there are some (I am one of them), but TBH, how often does that happen?
The point I'm trying to make: LLMs have made actual code basically irrelevant in day-to-day dev work. Whether it is readable / understandable to humans matters very little.
The fact that it does what it should is what matters, and in that space, brand new techniques must be developed beyond the traditional ones to verify with a high degree of certainty that the code does what it's supposed to.
And yes, I am aware the the folks working on testing methodologies haven't been asleep at the wheel for the past 50 years.
What I'm saying is: with LLMs, it's all that remains: writing proper specs (assuming you know what you program should actually do), and proving the code produced by the LLM meets those specs.
The technical solutions we have for both these things are not yet, from a software engineering perspective, ready IMO.
dreambigwrkhard 1 days ago [-]
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.
insane_dreamer 1 days ago [-]
> 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"
keeda 24 hours ago [-]
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.
killix 19 hours ago [-]
[flagged]
Magicrafter13 23 hours ago [-]
To the surprise of literally 0 people who are actually honest about the field and not suffering from AI psychosis.
socketcluster 20 hours ago [-]
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.
moarfaj 5 hours ago [-]
[flagged]
_boffin_ 14 hours ago [-]
A lot of what i see in this article can be fixed / improved by mechanical checks in the repository. enforce boundaries, direction, testing breadth and types, complexity, duplicates, and so much more. Use skills; detail how you want things done.
Why make the agent think more than it needs to? yell at it when it strays rather than you finding out that it has strayed.
jgalt212 17 hours ago [-]
Is every engineering-heavy org AI-pilled these days?
Is there no push back from senior management, or have they all been bought off?
softwaredoug 1 days ago [-]
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?
1 days ago [-]
chrisrickard 17 hours ago [-]
this article sounds like it was written in november 2025
vinyl7 23 hours ago [-]
This thread seems to be a great example of the dead internet theory.
crnkofe 9 hours ago [-]
There's so much of an aggressive AI FOMO push on the web that every article starts with a disclaimer "of course I use AI, not claiming that I don't" to avoid getting flamed and trolled into oblivion. Seems its no longer possible to have a normal discussion about the subject.
cobbzilla 18 hours ago [-]
Once again I reach for the Perl analogy.
Back in the day, if you were a responsible Perl expert, you could work magic that few others could, and it would even be maintainable and overall great. But, in fact, most actual Perl code looked like line noise and was unmaintainable spaghetti.
14 hours ago [-]
johnwheeler 14 hours ago [-]
This is all ego. The machines are better than us now, guys.
blurbleblurble 22 hours ago [-]
At this point I'm finding these kinds of generalizations very annoying
scotty79 1 days ago [-]
AI is farming. It produces lower quality crop (for now) but in abundance. So it wins.
lofaszvanitt 1 days ago [-]
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.
jojobas 1 days ago [-]
AI non-usage brings about irrelevance under pressure from competitors with fragile codebase.
bigstrat2003 17 hours ago [-]
There is zero evidence whatsoever to suggest that will be the case. The only reason people say that is FOMO, not actual business sense.
d_tr 14 hours ago [-]
I guess it's early to tell. Thankfully I can write code however the fuck I want in my job. I am not even searching for anything else right now because of this alone.
jojobas 8 hours ago [-]
Vibe-coded adobe clones are only the beginning. Existing codebase moats have decreased significantly over the last year. Going forward green field protein buildouts will have a very tough time justifying to their boards why they want to be slower than competition.
1 days ago [-]
shevy-java 7 hours ago [-]
"I generated at least 90% of my code using AI in my last few months there, which was the minimum for a decent rating."
AI is killing people. It is time for an extra-tax against AI using companies.
They can not destroy jobs, drive up RAM prices willy-nilly and think the rest
of society should pay for that.
"I can only speculate as to the reasons why I was laid off from Meta in May"
Well - you already worked for Evil there. People made these companies stronger
and now their jobs are killed by AI. That's the double irony.
I remember years ago people were happy with working at Google, for instance.
That has now totally disappear in the AI slop vibe age. It's quite fascinating
to see, actually.
Also, I am not sure I agree entirely with the article as such.
Personally I don't use AI, my code base will remain AI free (I think), but if you look at the ruby programming language, claude is now the main designer. Now I think this change was also incredibly stupid by the ruby core team, but objectively one could reason that it led to elimination of some bugs. If true then this is, I would think, a positive change aka an improvement. I still think the total net cost is worse (no real human wants to "interact" with AI slop spam programmers), but one can not say that AI use per se leads to a decaying code base. In a way when ruby transitioned into embracing claude as the new overlord, the decision making is still largely done by a human, e. g. what is changed and how, even if they AI slop spam things out. So AI is mostly a tool in this regard - granted, a horrible one, but you can not say that a fork has only negative use cases if it is just a fork. AI just is more flexible. It is the any-tool (anything-tool).
vatsachak 1 days ago [-]
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
stackzero 15 hours ago [-]
1yr ago i'd agree. now this is cope. build the processes to ensure quality and iterate
thisisnotgreat 1 days ago [-]
> 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.
bcrosby95 23 hours ago [-]
I agree with a lot of your points but I think you undersell the problem with the "1%" cases.
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.
popkkksidhd 1 days ago [-]
> It causes issues in practice and not just in theory (which is IME 1% of cases), well, redo them
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.
ratelimitsteve 23 hours ago [-]
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.
elzbardico 1 days ago [-]
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.
Topfi 1 days ago [-]
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.
kuro124 1 hours ago [-]
[flagged]
MotoriX 6 hours ago [-]
[flagged]
9 hours ago [-]
TokenLat 13 hours ago [-]
[flagged]
enesmalik02 22 hours ago [-]
[flagged]
shipsafestack 24 hours ago [-]
[flagged]
sshadmand 1 days ago [-]
[flagged]
fk202611 1 days ago [-]
[dead]
quiet_ledger44 20 hours ago [-]
[flagged]
Ontologyto 21 hours ago [-]
[flagged]
josefritzishere 1 days ago [-]
[dead]
gtsop 11 hours ago [-]
[dead]
tappio 1 days ago [-]
[dead]
taspeotis 1 days ago [-]
Early 2025 Copilot + GPT 4o energy here.
cyanydeez 1 days ago [-]
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.
fragmede 1 days ago [-]
> Elon musk reinventing public transportation several times ignorantly.
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.
cyanydeez 1 days ago [-]
Right, but he happily wasted time and money in Las Vegas on the rediculous single car tesla tube.
As much as he's malicious, he's also rediculously stupid in conception.
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!
I'd guess most code bases you could reduce by about 50% without losing anything at all.
First impression is that it’s a net negative. It gets a lot better at working within that library, and much worse at making it work within the project as a whole.
It's also a lot cheaper to experiment with different abstractions within a codebase to really get them right, and especially to evolve them as the codebase changes.
Sure, I had to tell it to so, but it trudged through and did it fairly independently… Was especially nice as refactoring test infrastructure code isn’t always very exciting…
Discussion (though topic has been flaged): https://news.ycombinator.com/item?id=50433079
He took the instructions, plopped them into an agent, generated ~400 lines of change that add the alert. The problem was the entire 400 lines were custom for that X metric. Meaning if we needed to add a second alert, it’s another 400 lines. The entire thing is generic plumbing and defining resources. Any reasonable engineer would make it so that the second alert to add would be 2 or 3 line change to just define the metric and its alerting threshold (and whatever other parameters for the alert) not re-do the entire setup every time for every metric. I felt stupid having to explain that to another senior engineer.
Another AI-generated post complaining about AI? Or maybe the author just started writing like Claude themselves
Anyway most of reddit is dead internet and that post is just engagement farming... As is most of hn.
FWIIW Quality was always cheaper and quicker for anything but a prototype. This is just as true now. The problem was that many people were too lazy and unfocused to make quality work and those people are only too happy to agree with these comments
I noticed that too about a year or so ago. It's unbearable that made me pretty much leave the conversation. I am yet to see a codebase written by LLMs that is half decent. Also, I am unable to generate any decent codebase with LLMs without massive handholding and later refactoring. But maybe that's a skill issue and am holding the genius wrong.
I suspect many people are under AI-psychosis, conflict of interest or were simply introduced to tech very recently.
It still goes wrong when there hidden gaps that I don't spot in the plan or when the LLM decides to abandon the plan halfway through (rarer these days). But it's still not as bad as giving a single prompt and hoping for the best.
Of course, all of this only works if you know what you're doing and what you want and can/cannot accept in your codebase.
Businessmen are what ycombinator is about and there must be some of them here. Their motivation is to sell and AI is one of the sauces they can put on their business-burger to make it sell better. Why wouldn't they be enthusiasts?
This tool, like anything that has addictive engagement loops, need to be used with discipline.
I’m already hearing whispers of corpos reining in ai spend. What happens when your budget goes from 2k/mo to 200 per eng? What happens when that 200/mo cost turns into 500?
There is absolutely no way that becoming addicted to gen ai is good for the individual or the collective ecosystem.
I’m confident we are in a hype cycle and things are going to level out once we fully grasp its limitations and see it as great for knocking out boilerplate and tedious tasks
Models are getting more capable while becoming cheaper every day.
New open-source or open-weight models are being released every few months, and are very cheap on cloud providers or can be self-hosted.
Hybrid multi-agent workflows or developer/reviewer work styles have already emerged and proven to produce great code quality while driving down costs.
Not everything is about one-shotting the latest OpenAI or Anthropic model on xhigh.
I find it hard to predict what will happen to swe after that.
that would be an ideal outcome.
Today's cloud-locked models you pay a subscription to to use is akin to the old AOL internet.
2. They try to make up for it in volume. Which is why they want to wedge AI-usage into every aspect of work and life.
You don't need 1 dev spending $2000/mo if you can get 2000 people spending $1+ per month
That's interesting. I've also witnessed the reigning in of AI spend. What if the measure of a good developer becomes one who is an effective steward of tokens?
And not to mention, the interests aren't aligned: a hypothetical engineer will always want to spend the max to impress: I delivered this project solo (and all it took was $2k per day on Galactos Swarm mode v9.9).
And we must, must consider what the most enshittified era of LLM AI will look like. Will they be holding your codebase to ransom? Yeah you can have an improvement but it will cost you. What are you going to do, read the code yourself?
There's growth phases, where cost doesn't matter as much, sometimes to a seemingly unreasonable degree. And then after that, it really does.
I guess that differentiates us from "real" engineers, who can't make the bridge they're designing cheaper later, they think about it upfront. But we think about it, too.
(we've already had the $2k/month max imposed, although I was nowhere near that it seems that people who have gone fully agent-brained were using a lot more. But not necessarily for more results ...)
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.
It sounds like quality, and you can measure it and make decisions as it's well defined, but of course it's not quality.
https://qa.perl.org/phalanx/kwalitee.html
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.
It is fairly mortifying to watch them build solutions in hours or days that are designed better than the projects they were prescribing to product engineering teams to take literal months to spike, PRD, build - then maintained and governed better - with no real understanding of how it works.
Obviously lots of caveats to be made here, but fascinating to watch it play out (at least in places where infosec is robust enough to give a sales manager access to Claude Code).
In my mind we should be much more defensive before we even think about doing anything offensive.
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.
But I’m not at all convinced that 30 years ago things were appropriately secure or usable.
But since AI writes everything anyway, innovations that improve “developer experience” are pointless, and all the other low hanging fruit has been taken.
Go out to a bakery, tire shop see how much they innovate. Then go one rung up to services they consume like insurance and banking. All of this chain is super conservative.
The agents will often propose bypassing reusage of existing code in favor of generating a new thing - there is no fear of "NIH". That's scary at the surface - human programmers like having something that looks like a reusable brick that they can dwell upon - but attractive in other respects since it lets the organizational needs express themselves directly. Working fully top-down like this is novel within software. There are plenty of unknowns to it, but it means that relatively more of what was a library that you learned and trusted but rarely verified instead becomes a requirements document, reused and iterated on project to project.
On the bright side, since every LLM is completely ignorant of your project's history and minutiae, the "mythical man month" doesn't have an AI equivalent and you can slap on more and more agents to convert time blow-outs to cost blow-outs.
It’s a good thing no business ever has to hire a new developer and get them up to speed on such things!
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.
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.
Messy, fragile codebases have a greater cost of change and a greater likelihood of errors with every change. AI tokens might be cheaper than developer hours but you'll still burn more of them working on a messy code base, and still have the reputational impacts of a high error rate.
If "fast" and "cheap" are the main drivers, you'll get "bad". And I think it's a great deal easier for developers to follow the path of least resistance and allow "bad" to deliver faster and cheaper when it's AI that's reading the code.
The industrial revolution may have changed the bounds, but it didn't change the relationship.
Your one-off Python scripts are a bit like handkerchiefs. You can make a one-off hanky by cutting a square off an old sheet, fast and cheap, but it's clearly not as good as a re-usable one and you'll throw it out after using it once or twice. That sort of idea simply doesn't scale with complexity. A "good enough" pair of pants needs a lot more than just snipping out a shape. Even a one-off pair of pants, like for a costume, requires time and effort. So too with larger programs. They require more time and effort.
AI changes the bounds: it's cheaper and faster to produce software than it was, but it's not cheaper or faster to make something good than it was, not by an appreciable amount. It remains to be seen if software turns into cheap clothing advertised on buses that is barely fit for purpose... but the industry's track record isn't anything to praise, so probably, it will.
Then, too, hand-crafted assembly still beats compiled output, if you consider the only upper limit on quality. The gap in quality is much, much smaller, and the gap in time and cost is much, much bigger, though, so it's almost never worth the trade-off.
Let's say that AI-generated software eventually (or already, if you like) produces better quality software than people can produce, given the same time and cost restrictions. You can still spend more time and cost to get a better result, or accept a worse result to save time and cost. Or take more time to get a good result but more cheaply using off-peak pricing (tokens or power, take your pick). Or throw more parallel agents at the problem to get a good result faster, but at higher cost.
Pick two. Always.
Even if that will be true (currently it's not in the long run), messy codebase will make you spend much more on tokens. So unless agents become so cheap that it won't matter, having a mess will be bad for the business in the long run.
Managed to get it in time to have an accurate claim that "stdlib has no total functions" prior to presenting it to someone semifamous, who doesn't like that lean has total functions
Also what does quality mean really? Because recent AI audits show that we humans have been generating low-quality software in terms of security.
Readability and maintainability is less of a problem for AI. One can argue that they’re potentially better for writing and running tests. Same for writing performant code.
Additionally, all those arguments about tabs vs spaces, position of the curly brace or different naming conventions have zero meaning now.
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.
If you don't prioritize what is important to you, it isn't going to magically build it.
It can't read your mind.
"We don't know what's in the code base" - Where is your design spec that says what should be built?
"The tests are too shallow" - How are you asking it to make tests? What are your test metrics
"more incidents" - Why don't you have tests or scans against these.
IMO- there's basically no excuse for these things anymore. If I want to be really harsh - the people that are complaining or naysaying the most are just code monkeys. Maybe they ARE hot-shit programmers that can code circles around me, but how much do they contribute to a team? Do they get out of their own head and actually write down designs? Specs? Have they documented how things are supposed to work or do they "just know" ?
Why would recovery take longer? To me, that means you didn't code-up a failure and recovery plan, which your LLM agent will help you make. To mean that means you never thought to actually stress test anything.
And pre-LLM, those were still inexcusable but at least understandable - development time was limited. Now, how is there any excuse except for you didn't think to write these things down or event prompt for them. That's on YOU now. 100%
What does this (and the rest of your comment) have to do with parent's assertion of "I think the second part of the blog post speaks to exactly how this will play out: more incidents, longer recovery times, and a poorer user experience. "
After all, if 99 out of every 100 developers are getting a fragile codebase by doing $FOO, the fact that it is possible to do $FOO safely is not a defense of $FOO.
Bingo. People notice slop because the people using the tool didn’t care or weren’t very good. There is way more AI usage going on than people realize, but you won’t notice when it’s used by someone skilled.
The complaints is that we are not seeing any of those being done. And when you point it out, you go slop thrown back.
The thing about nice code, is that it can be its own design doc, what you need mostly after that is just a high level explanation. No need to write the small details twice.
> Now, how is there any excuse except for you didn't think to write these things down or event prompt for them. That's on YOU now. 100%
I can do that and hope that the LLM do a good job for them, or I can just get it done. The two are roughly equal in time taken if I’m looking to do a good work, but LLM usage is more mentally taxing.
Meanwhile certain open source communities are renowned for their adherence to strict standards, and many are using AI to tighten up their codebases rather than balloon functionality.
* Adding too many features to existing software making it impossible to find where to do important routine tasks.
* Once-off projects that behave much like the first, by virtue of the user having to figure out which of the 15 apps do what they need.
* Usage rotting and bit rotting features. Someone builds something for a once-off and it sits there forever.
Enterprise software not being about quality was always a problem, and AI hasn't made that go away; it has made it worse. Disciplined PM and the word "no" is how great software is made (in terms of usability, I'm avoiding talking about performance), and AI rewards the opposite.
> [Mine] Enterprise software not being about quality was always a problem
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.
That's the patern I'm unfortunately expecting for developers. Developers on the hook for auditing the AI slop code. People hired entirely to get around to plugging the holes the AI makes. It probably will be a full time job as the AI pushes new features, UI updates, and otherwise opens new bugs.
From the outside as someone who isn't playing with AI generated code for work currently it seems like it will be the same kind of problem space as a developer inheriting a legacy codebase. In some ways it will be worse, that AI "developer" probably won't be any more useful than the legacy developer who retired for figuring out "why" something was set up a specific way. It will most likely still be around fiddling with your code though, but if your company is locked in to one model it might be easier to learn to read... at least until they change models and you need to learn the style of the new "developer" you can't fathom.
I have a huge backlog of reviewing code. Luckily most apps stay internal, but the desires to even host services on the net growths daily.
Last year december I had about 10 repositories with internal code bases. Now I have 100+. I constantly have to "renovate" apps that spawn CVS left and right. This was a pivot for me to develop myself to become a kindergarden teacher.
I don't have fears to be replaced, I have more problems with huge work loads... And software that was previously bought to solve a problem is now just vibe coded and copied by people that seriously don't understand the system they are developing. Well, interesting times...
I can tell you: your management skills will be copied by the AI (thanks to your input!)
I kept wanting to fix underlying problems rather than applying band aids and my insistance on quality for important things like court schedules, administrative portals, accurate billing, and tracking jail release dates ultimately resulted in them handing me my hat by assigning me to the least desirable maintenance group where I burned out spectacularly.
I'm sure that this company now produces a plurality of privately owned government software.
And this is precisely where you lost me. Because. No. That's a lie you tell yourself to justify the state of things. But it's as far from the truth as it could be.
Features is how you win the wind up of your business. But features do fuckall in user retention, while feature maintenance does. Tell me, name a SINGLE, one teensy tiny ass feature youtube has added to its service in the 6 months. Last year being when they began their 100% AI mandate, and the last 6 months being when AI has got its "good enough to engineer most of an app" acceptance.
I can name the few features, I know creators. But YOU are not a creator. I do not believe you can pass this challenge. And yet youtube remains the video streaming titan. The only feature most people on here can even probably name that their clients got all come from the morphe app. Custom play thumb and custom playbar colors is cool, but google would NEVER, despite having zero need for direct coding manhours anymore.
In other words.
Google is privileged enough to slow down.
And yet, you espouse the the opposite. Can't stop, won't stop! The MARKET demands it!
I don't buy it. You're mismanaged.
God knows but money decides.
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.
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.
I realised then when I became more of a manager than a coder that then types of code quality issues engineers obsess over are practically irrelevant.
Until you find out your TLS key is 4 or that a 255 char password will bypass your auth system. Management is a necessary evil that needs to be kept in check by knowledgeable and skilled people.
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.
I have heard of a company trying to build a new app by using AI to generate a detailed specification from the old app's code. We'll see how it turns out but the app is talking a bunch of APIs that, like you said, have little documentation besides the code itself.
As AI has been highlighting, maybe this idea has always been an illusion.
"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.
Contributors to this project must follow YAGNI, DRY, KISS, and principle of least astonishment, both from user-visible surfaces, and backend design.
Code is a liability. Do not build anything not expressly asked for.
It's not a mantra, it's the reality of the business: if I must bear responsibility of the code facing a customer, then I have to understand the code. The AI can be a wonderful tool, but people are still calling me to fight fires.
At some point technology becomes so good that it's a reasonable choice to give up understanding. And in opinion of many, that point is now for agenting coding.
you are probably smarter and more skillful then I am, but despite coding all my life for a living I feel that AI is vastly better than me in every single skill that I thought are my strongest skills.
I also think that the risk for a small company is larger that their only programmer who understand the code base quits than the ai not being able to fix issues in its own code.
The only point of disagreement is if llms are already good enough. And for a lot of people this is already true today.
"You were hacked because the well known, respectable crypto lib I bundled with my binaries actually got a bug" is fine.
"You lost one day of productivity and I can't tell you when I'll be able to propose you a fix because I shipped you a lazy copy/paste" is not.
Of course not - I use battle-tested options. Why would I pivot from battle-tested, production software that's had bugs shaken out for years to brand-new never-used-in-anger software that an LLM spat out?
It absolutely does. You lose understanding of the code, but what kind of understanding do you actually gain in turn? AFAICT it is purely a tradeoff between velocity and understanding.
You can also tell it what kinds of tests to write. (Assuming you're still interested in details of the codebase).
> "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.
Also, if it wrote a complex solution, tell it write a simple one instead.
In my experience, good AI adjusts pretty well to an existing code base, and produces roughly similar abstractions to the ones it finds.
This is a pretty severe issue I have. Give it a bad codebase, and it'll happily carry on the awful, ignore failed unit tests, omit documentation, not fixing existing problems just to, and I quote, "follow precedence".
It seems these models have been (probably for the better) trained to not rock the boat too much, to somewhat keep the work to a minimum. I think we're going to end up get stuck in de-risked "just make it work" sort of mode in the near term, with all the "less good" code that's was generated relative to newer/future models. At some point, there's going to need to be a shift to just rewrite/replace bad code, without excessive, and very often forgotten, instructions to do so.
Staying inline with the codebase is the right thing to do. It's down to you to tell it when it's time to re-engineer.
> without excessive, and very often forgotten, instructions to do so.
It forgets, within long sessions. I'm still seeing Opus 5.5 implement workarounds for bugs it created within its own session, even with explicit, and plentiful, instructions and global memories that it's time to re-engineer.
But to your point, yes, multiple rounds are required. My point is that this strong affinity for what exists is going to eventually hold development back.
Thing is we don't write kernel code nor assembly.
It would be an issue if for every API request handler we write we'd also ship a kernel patch or some kernel level helper. That's the situation we're stuck in with agents, they produce a bunch of low level code that we have to either trust or thoroughly review, even as our goal is at a higher level.
IMHO we really need high level and proven solid frameworks that the agents can rely on, and get in exchange high level code that is succinct, simple and readable enough to be properly understood.
Or my personal favourite: "if you overengineer it, my grandma dies"
and that is a means to which end, again? I very much enjoyed the engineering bits of programming: having a deep mental model of how the software works, understanding the architecture, the data structures, the algorithms.
uhm.. what? The reason I don't understand how the kernel works is because I'm not working on it. The people working on it understand how it works. What kind of logic is this?
Sure I don't have a deep understanding of the Linux kernel, but some human(s) somewhere do(es). If a whole company switches to LLM development for their (closed source) product, nobody has a deep understanding of the code anymore. That could become an issue real quick, if AI doesn't do what you want anymore.
(Not saying AI is gonna go sentient, just saying taking AI for granted is a problem in and of itself)
Those are really bad examples to quote tho. I'm not making a change in the Linux kernel nor am I releasing it or debugging it or maintaining it or getting pinged at 1am by Pagerduty because of it. Nobody is asking me how it works or what would it mean to add feature X to it.
I think the bigger point is that you still do need to understand what is up in your codebase, relying on agents 100% of the time for absolutely everything is going to be preposterous in the long term.
If I take ownership of the Linux kernel and refactor it into Rust with a "thorough test" using Astra/Fable, will you use it?
- You are using it wrong! You don't know how to prompt!
- And if you do, then you are using cheap models! You aren't spending enough!
- And if you are, then you care too much! The quality doesn't matter anymore!
- And if it does, then the models will get exponentially better! The problem will be solved in a few months!
*Edit*: I use AI and find it great, but I don't think we should be dismissing any negative feedback as user error.
No, AI is still absolutely terrible at design.
It doesn't matter if they are good at implementation.
If you ask for a car and they build you an awesome surfboard, it's basically worthless.
Sure, if you're building rapid prototypes where it doesn't matter if anything is coherent or works, AI crushes it.
If it's a 99% derivative small greenfield project, AI crushes it.
For anything real, it is still a painfully awful experience to extract juice from the squeeze.
We've been hearing this claim for years. It wasn't true then, it isn't true now.
I see it like someone walking through a minefield safely after not noticing the signs.
“What do you mean it’s a minefield? MY legs didn’t get blown off.”
Even if AI did indeed make worse architectural decisions, that just means we have to be more on top of it in preventing them to make those decisions.
We've already managed to successfully convince everyone that you should tell AI to always produce tests for your changes. But we were ALWAYS meant to ALWAYS have test. Why did we ever not do that? Oh right, lack of time, different priorities, etc. etc. AI gives us the time back so now we're no longer allowing excuses. Weird how the standards only change with a complete lack of care and naive trust of AI?
The article also mentions that AI produces code that doesn't scale. Well? Why aren't you running a profiler and looking for places to optimize then? You were ALWAYS meant to do that. You were ALWAYS meant to ~prove~ the scalability of your architecture. This was ALWAYS a responsibility of engineers. Why are you just trusting it to do whatever instead of putting in the work doing all those things and improving? Where the hell did your responsibilities go, and why are we having a discussion on AI instead of on the fact the human is avoiding their job-description responsibilities?
I am an engineer. It is my job to produce good code. And I am proud of that, and of what that means. And right now, that means looking at AI doing a half baked job, and either baking the other half myself, or telling the AI how to.
Knock knock. That's all the shitty engineering of the last decades. It isn't dead. It's just called vibecoding now. Don't blame the AI. Unmask it, and blame shitty engineers.
And companies that enable them. If they're that shitty and the code will implode that much, unseat them. They will be paying that debt, while you soar.
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.
How can this be judged from the outside, eg in an interview?
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.
Something that I'm working on for my day job is essentially 32 years old though (been through a couple of big upgrades along the way) and that's how it should be, unless the underlying technology would be better off being replaced (like a COBOL or Fortran codebase).
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”.
React + Electron "won" because it was the best "bang for the buck". You get cross platform compatibility for all relevant desktop OSes out of the box thanks to Electron, and thanks to React you get access to an effectively infinite pool of developers (at least compared to Qt or other native UI frameworks).
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.
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.
This is actually a perfect depiction of what "bug-driven development" looks like, which is basically where the current generation of AI-only codebases are headed.
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.
https://news.ycombinator.com/item?id=49850305#49853149
https://news.ycombinator.com/item?id=49839664#49848367
The idea of hand-typing the code that goes into those molds is going to seem foreign to us. We're going to look at monoliths and hand-written infra the same way we look back at the masonry of the cathedrals. We'll marvel. We'll find it beautiful. But we won't want to go back when pouring concrete is far easier.
Perhaps another angle could be an IKEA product designer looking at the molded plastic and lamenting it's efficiency and cost.
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 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
PS: make no mistakes and tell me in advance if I forgot anything that I could regret later.
Or on a more technical side: I would like all problems that any app/company/product could solve to be solved in the best possible way, so that nobody has to even think about what kind of problems even could be solved. Go iterate on that but do not make any mistake, do not ask any questions, be done by tomorrow, do not interpret what I said in any bad way.
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.
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.
Those new skills come pre-devalued already - they're simple and quick to acquire so if that's the new value prop, you can expect it to be a minimum wage value prop in just a few years.
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.
It still leaves me with a bad taste in my mouth -- the Codex desktop client's rich text editor had a fun "bug of the week" for a bit... at one point the bottom of the control/view was occluded by blank space, at another point selecting a region and scrolling "un-selected" the region.
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.
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.
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.
Picture a foolish person falling out of a hot air balloon.
"Gosh," they think, plummeting, "the balloon is going upwards SO fast!"
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.
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
Measured by?
i had to argue with someone, more than once, that "cursor is wrong about this assumption because i originally wrote this" because they just accepted whatever model they used as truth.
> 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.
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.
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.
This was you two posts ago
> it went live just two weeks ago. So far only 30 users
This is you now.
I won't read further.
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.
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.
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>
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.
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
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).
“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”
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 :)
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
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.
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.
"An agent wrote the code" is not an excuse for failing to understand how the system works and fits together.
If you do multiple review passes you almost always end up picking up numerous issues in the first two passes, sometimes quite crucial.
https://epiq.sh/blog/the-soft-fabric-of-agentic-code
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.
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.
That argument has been repeated so much while all the experienced developers keep saying that coding was not the hardest part of the job. The hardest part was adding the new changes while ensuring the system doesn't break and that it's still easy to modify later. In the latter case, intuition plays a big role into labeling what is a core truth of the system (unlikely to change) and what is a transitory need.
Coding was just something you do (and relax while doing so), not something you put your whole being into. When I code, I mostly think about the system. Which is why I look at the docs and my notes often to check the semantics of whatever symbols I want to use. I don't think about the actual typing of the code.
That's the actual argument against agentic coding. No one is checking semantics, it's hope and prayers that the software is correct.
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?
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".
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.
If that's the worst you can say, then it's done a pretty good 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 immediately stopped writing any code by hand. If they wanna pay me more to do a worse job, more power to them :)
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.
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).
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.
1. https://en.wikipedia.org/wiki/Bitter_lesson
2. https://en.wikipedia.org/wiki/God_of_the_gaps
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
Are you really not capable of writing a test or a linter that shows you the patterns you care about?
Imagine you had a team of 100 developers and you needed to enforce controls over the software and how it operates. Would you do that with trust? Could that survive an audit?
Yes, if you just throw prompts at AI and assume natural language is enough to properly influence how the code is built, the code base will be a fragile ball of mud.
If you consider your new job to be deterministically constraining the output and creating visibility for all items that really matter, then this doesn’t have to be the case.
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.
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.
The real difference is that a carpenter actually talks to you when you order your furniture, and builds something custom to your specification. The quality of the finished cupboard wouldn't improve if your craftsman only used hand tools.
I suspect something similar will happen for software: For some applications, vibe code is good enough. For others, a human will do software design (possibly with machine assistance), hand-writes some parts, delegates other parts to an AI but still reads it.
Purely-human-written code will be akin to furniture built using only hand tools: a piece of art, or maybe product of a hobby or a religious ceremony rather than a practical necessity or a practical advantage.
[1] https://www.youtube.com/watch?v=vWAGrSgEB4A
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...
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?
That the ai is better means nothing. It is still pretty bad.
I feel that a lot of folks that have worked at FAANG or tech first orgs overestimate how good the average company repo is.
1 year ago, I'd 100% be on your side, but we can't ignore the progress that models have made over the last 10 months.
An AI is arguably capable of refactoring a ball of mud into something better, or not writing one in the first place, if we could show them how. I suggest we don’t know how to, other than slogans like “clean code”?
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.
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.
Among myself and all the colleagues that I work with, I am the only person remaining who reviews every line of code to make sure I at least understand what the written code is doing. And when I review AI-written code in this manner, I almost always find flaws-- overchecking of weird edge cases, underchecking of conditions that might lead to ambiguity, importing a whole new library to handle one special case that happens <1% of the time, etc.
This is disappointing to me because just a few years ago, at my last job, thorough code reviews were the norm. And it resulted in good, maintainable code.
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?
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".
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
You have to decide if you're going to vibe code or not. If you are going to keep humans in the loop, the chunks need to be manageable. You can have shallow changes to lots of files, or you can have deep changes to few files, but you can't have both.
The AI will do this for you. It'll even break down stories into manageable chunks for you. You just have to ask.
I’m confused how to reconcile this with the conclusions presented. Is a fragile code base therefore inevitable? Perhaps the point is that expectations should/will eventually change?
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:
What's useful is to have a second agent that reviews the tests impartially and trim the ones that are low signal.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.
[0] https://github.com/zeeq-ai/zeeq-biome
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.
And nobody ever hired an army of programmers to write assembly. These improvements in capability have always resulted in more demand for programmers, not less, via Jevon's paradox. Is this also true with AI? Remains to be seen, but it's arguable we had too many bad programmers before AI since they were shoved through React bootcamps, and most tech products are useless, and some culling is overdue.
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.
What matters more is the higher level architecture, and the testing strategy, backed up by tooling like fuzzers and maybe even formal proofs.
LLMs open up all sorts of tooling that wasn't feasible to use for most projects.
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!)
> 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
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 is a force multiplier in whatever you apply it to. Most software companies output binaries with new features, whether it runs locally or on a server. Binaries with new features. None of the business owners give a shit about what is in the binary. It may be extremely fragile and only work for one type of user, but if they only have one type of user nobody cares. Most software doesn't keep evolving forever and at some point gets rewritten as a 2.0 version or whatever, so the quality was never as important.
It doesn't have to be that way. You can use AI just as effectively to produce quality source code as you can slop binaries. It depends on the business priorities and what is actually important.
The caveat is if you are the one engineer on the team trying to use AI the right way to produce quality source instead of binaries as fast as possible, you might get left behind or let go since your work no longer aligns with the business.
" I generated at least 90% of my code using AI in my last few months there, which was the minimum for a decent rating"
"I've fully made the switch to generating 100% of my code using AI because that's the expectation today."
This is really sad? Am I the only one who feels so????
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.
I think at the end of the day people want to believe they're writing programs proofs but outside of very specific use cases most people are implementing good enough until shit hits the fan.
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.
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.
In my cases AI usage generated better and more stable codebases, without exception.
All these issues were already an issue with humans. No one did TDD "the right way". No one did BDD "the right way".
I find it amazing that fancy markov chain machines had to start generating code for us to even consider caring about automated testing and automated code quality analysis using proper code metrics.
When you're building a structure of any type, you need to get the foundation right. You have to use qualified materials that have tested and predictable characteristics. You can't just use any random truckload of dirt as filler for concrete, for example.
AI generated code is random fill, and we don't even have a good way to screen it yet, to get out the old tires, construction debris, Jimmy Hoffa's body, etc. You can't have a person judging every cubic inch of fill for quality, it's not scalable, but that's what we're collectively trying to do with AI code.
Either that or I'll end up a dinosaur in a world of primates.
Every six months, the number of people capable of writing code better than AI is halved! :D
Kinda like the struggles with getting the context window bigger than 2Mtok... for the past 3 years...
We of course know that human code often isn't that good anyhow...and the people who wrote it similarly are not likely to see why AI code isn't great - after all they judged what they did before as being ok.
Nowadays if you don't use enough AI you get told off by your boss. If it's so great why the pressure? Why is any objection or even minute qualification rolled over? Why is it scary to point out the slightest problem in a meeting?
It's all cast as a race and everyone is scared to loose the race whether it's companies or individuals so everything is to the max and consequences be damned. How wonderful for the AI companies!
> 1. AI writes shallow tests
I've seen test coverage go up a lot for some companies I have insight in. Some test may be shallow, but all in all there are a lot more tests and in general better test. TDD is on for LLMs in all those projects.
Try having your LLMs critique/improve your test code by telling it to: look for bad tests, look for ways to speed up the tests, make the test code more accessible to humans, look for test gaps (coverage tool helps here), etc. I've only seen test code in general do better, but it takes a bit of time writing CLAUDE.md instructions to have it your way.
Also: Architecture tests. I have soooo many of these now, because they restrict architecture mistakes LLMs (and humans) can make. I even have architecture tests for my test code!
> 2. AI writes overly complex code
I have a clear definition of "complicated code", and that it inspired by functional programming. Classes are more complex than records and functions; result types (usually some kind of sum-types) are easier than exceptions. I instruct my LLM to use the least complex construct to fix something. I tell it to do it in functional programming style unless it becomes awkward.
So mocking/stubbing/etc is forbidden in favor of fakes. So dependency injection frameworks are forbidden in favor of just passing the dependencies as parameters.
Since it's a SaaS it is usually doing something that has already been done. I've supervised it a lot more some time back, and when cleaning up the code. Now the example is clean and clear, the LLM often follows suit properly in my opinion.
> 3. Reliance on AI decreases human understanding
I do not have to understand everything, all at the same time. But the architecure is very clear and many rules are set in the LLM and human instructions that have been developed along the project. Documentation is MUCH more up to date since using LLMs in the project I saw. Even if only because though documentation we instruct the LLM, AND the LLMs tell you when docs do not match your envisioned approach or some existing piece of code.
> 4. AI moves too quickly to maintain a high quality bar
This is a business decision. Big projects (with many devs collaborating) had this problem before LLMs. Learn from how they've been doing it... You simply have something very akin to a much bigger team. It could be that you just like wokring in small teams: that's alright.
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.
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.
How many devs read the compiler output or care how understandable it actually is?
I know there are some (I am one of them), but TBH, how often does that happen?
The point I'm trying to make: LLMs have made actual code basically irrelevant in day-to-day dev work. Whether it is readable / understandable to humans matters very little.
The fact that it does what it should is what matters, and in that space, brand new techniques must be developed beyond the traditional ones to verify with a high degree of certainty that the code does what it's supposed to.
And yes, I am aware the the folks working on testing methodologies haven't been asleep at the wheel for the past 50 years.
What I'm saying is: with LLMs, it's all that remains: writing proper specs (assuming you know what you program should actually do), and proving the code produced by the LLM meets those specs.
The technical solutions we have for both these things are not yet, from a software engineering perspective, ready IMO.
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"
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.
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.
Why make the agent think more than it needs to? yell at it when it strays rather than you finding out that it has strayed.
Is there no push back from senior management, or have they all been bought off?
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?
Back in the day, if you were a responsible Perl expert, you could work magic that few others could, and it would even be maintainable and overall great. But, in fact, most actual Perl code looked like line noise and was unmaintainable spaghetti.
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 is killing people. It is time for an extra-tax against AI using companies. They can not destroy jobs, drive up RAM prices willy-nilly and think the rest of society should pay for that.
"I can only speculate as to the reasons why I was laid off from Meta in May"
Well - you already worked for Evil there. People made these companies stronger and now their jobs are killed by AI. That's the double irony.
I remember years ago people were happy with working at Google, for instance. That has now totally disappear in the AI slop vibe age. It's quite fascinating to see, actually.
Also, I am not sure I agree entirely with the article as such. Personally I don't use AI, my code base will remain AI free (I think), but if you look at the ruby programming language, claude is now the main designer. Now I think this change was also incredibly stupid by the ruby core team, but objectively one could reason that it led to elimination of some bugs. If true then this is, I would think, a positive change aka an improvement. I still think the total net cost is worse (no real human wants to "interact" with AI slop spam programmers), but one can not say that AI use per se leads to a decaying code base. In a way when ruby transitioned into embracing claude as the new overlord, the decision making is still largely done by a human, e. g. what is changed and how, even if they AI slop spam things out. So AI is mostly a tool in this regard - granted, a horrible one, but you can not say that a fork has only negative use cases if it is just a fork. AI just is more flexible. It is the any-tool (anything-tool).
Also, stuff like JavaScript event instead of using CSS like :hover is easy to catch and fix. You just can't start being lazy
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.