This is a fallacy. Computers are very deterministic, a well designed program will not have any bugs or unforeseen failures at all. You're not planting a tree and going "oh god I hope it survives the winter", you're programming a human-made computer, made of hardware that undergoes such incredible scrutiny before it's ever powered on that you can trust that it executes the same code, the same way, every single time, for decades.
No idea why people who clearly don't understand the difference between poppy farms and computers come in here and claim the world isn't perfect and so we should all accept sloppy shit code that barely works. The world isn't perfect, but software CAN be quite close.
Every single instance of jank on computers is a bug that someone wrote, or an LLM wrote, that can be found, understood, and fixed. And only once you understand this, can you talk about software quality to other engineers. You need to understand that the baseline is that software is not fallible the way the rest of the world is.
See sqlite3 if you want to know what nearly bug-free software looks like. I can't point you to a potato farm or an artist who is perfect, but I can point you to that and say "this is where we go when humans do a good job".
> a well designed program will not have any bugs or unforeseen failures at al;
You can only say that of either a very simple program or perhaps one with formal verification (which is overkill for 99.99% of software that gets written).
Look at the Linux kernel, arguably a well designed system (unless you ask Tanenbaum) with top notch developers, and still is full of bugs and security holes.
I agree with your general sentiment on bugs. Id personaly go one step further and say:
Every system in the world has bugs and security holes. If its exists, its buggy because "bug" is very loosely defined as "doesnt exactly work as expected". The security topic is even more complicated.
But I also would like to point out that comparing the Linux Kernel quality and development to Claude Code is surely a joke. The former is an ocean of features, compatibility and history. The latter, in the end still one executable CLI tool calling endpoints.
I have never in my career seen a (useful) program without bugs. I'd go so far as to say that, at least for most software, the optimal amount of bugs is not zero - if you write your code carefully enough to never have bugs, you will ship far too slowly. The point of code is not to be beautiful and perfect and well designed - it is to solve problems in the real world.
By the way, all hardware has bugs too; we just don't see them often because the programmers building the stacks that we run our code on work around them.
I want to agree with you, but most software projects people work on are ridden with unknown bugs and people do in fact live with this. I'm not aware of any commercial software project that arrives at the goal "not having any bugs or unforeseen failures at all". And where this does happen (space probes?) it is very expensive.
IMO the issue with LLMs is they massively widen the "unknown unknowns" (skipping review makes this problem even worse). This is obviously much worse when an LLM is actually a part of the software rather than just producing software that is otherwise deterministic.
I think OP was a little too absolute but i agree with the premise. People who engineer buildings and bridges are not allowed (generally) to ship mistakes. Software "engineers," though, have just accepted it as standard practice.
I do think the world would be better if commercial software had to meet some professional standard of fitness, with meaningful repercussions if not. I also realize that ship apparently sailed before i was born, and I'm not paid to do serious engineering, I'm paid to ship features.
(Not even saying I'm qualified to do the former anyway, i just also think every time national air traffic is shut down or like in France the other day and hundreds of supermarkets lose all their frozen inventory, or i can't do my job because some service failed, or yes, claude code is slow and heavy age can't work right in every terminal, that maybe we shouldn't be writing the stuff that the whole world relies on to function every day with zero agreed upon professional standards)
> I'm not aware of any commercial software project that arrives at the goal "not having any bugs or unforeseen failures at all".
It's ludicrous that we have executives at tech companies that think this is possible.
One S&P 500 company I worked for signed a big contract to deliver bugless software for an enterprise web portal for the state of Minnesota. I was on the team that had to make that magic happen. I had to leave the company not long after that due to nearly life-ending burnout.
So I would throw scorn at the ivory tower inhabitants here who should know better than to suggest that anything of substantial complexity can be bug free
Exactly! That's my point. It's already a problem, and it's not "fine" just because it's the status quo, but at least we can chalk it up to "humans are fallible". LLMs 100x the amount of mistakes a programmer can make in a day, and that's inexcusable to not take seriously, that's my point. We don't need to chase perfection, but we can't pretend like whatever Claude one-shots is any good at all.
> LLMs 100x the amount of mistakes a programmer can make in a day
1. Have you seen that? If so, which agent+model?
2. Is “per day” intentionally used instead of per implementation - i.e a coding agent may A) be far faster tok/s than a human, and B) work more hours per day, so it’s similar bug rate per implementation? Or did you mean bugs per implementation?
1. Are you referring to LLMs handling 100x as many patches as a human can, or that LLM implementations are 100x as long as a human's implementation?
2. In my experience, LLM implementations are often 2-4x as long, largely because they have a lot more error handling than I would have chosen to implement. However, I don't find they have correspondingly X times as many mistakes.
3. Part of how agents seem to avoid many mistakes or even catch mistakes is by testing things. For example, it caught issues in Pester functions on certain Pester versions, or will even analyze binaries to verify the right config settings to use, etc.
4. If you are seeing 100x as many bugs, which agent+model?
LLM is clearly not 100xing the mistakes as we have witnessed Anthropic’s success. Otherwise the system would not have been functional. It’s not like their system is not tested.
The thread is about jankiness, lack of feature cohesion and code quality.
What we are discussing here is: is it acceptable to accept poor code quality and trade it off with delivery?
> What we are discussing here is: is it acceptable to accept poor code quality and trade it off with delivery?
I found that people that lean towards the latter also favor profits over customer satisfaction. Then they will try to defend themselves with a black and white view “it’s either this scrap or no delivery”.
> This is a fallacy. Computers are very deterministic, a well designed program will not have any bugs or unforeseen failures at all.
I don't know where you think you've found a fallacy. Computing systems are expected to interact in various ways with the outside world, which does include poppy farms, and people, and other decidedly imperfect things.
Yes! But they can behave deterministically for any kind of input data. Of course they interact with the outside world, and I'm not saying you can't have errors, I'm saying they're not random and driven by god's will, they're programmed explicitly.
In my first class of Software Engineering, I was taught that software is designed for changes. Even if software the fully deterministic, it interfaces with a world that is constantly changing: requirements change, customers change, political systems change.
Unless the chip has a bug or manufacturing error; I've worked with several fleets where small numbers of chips had stochastic errors. I doubt there is any fleet which does not periodically have some level of corruption, which typically goes unnoticed unless you have engineers paying close attention and some level of verification.
> Reporting bugs, patching systems, updating software is common to most software.
Yes, but this is a side-effect of trying to do good work and writing code that is understood and works.
When you ship sloppy, AI generated code, that no humans at the company have read and understood, you're missing the main part about engineering and are skipping straight to the life-support stage of the software, and you treat the (previously) side effect as your main job. Reporting bugs and shipping patches becomes your job, instead of engineering software, which happens to also come with that task.
I expect people who are skillful and enjoy writing good code, are among those who dislike code generated with AI tools, and perhaps feel they have had a role or pleasure denied to them.
Those who write shit code, now feel that can produce vastly better software in a fraction of the time, and feel a sense of accomplishment.
Not sure how that maps to software engineering at all. Seems more like a straw man, did you read my comment at all or just the first words? My point is that the mostly deterministic machine is very much not "imperfect" and doesn't need to be cuddled and watered to work. You simply write code, and if you're like a LITTLE BIT careful, it works super well. It's really not rocket science.
Nobody has to make the perfect program, but we can't chalk it up to "the world isn't perfect" when I click the windows start menu and it opens empty (an existing bug btw)
This is a category error. "memory" is not a computer, so the existence of ECC proves nothing about computers. Concrete is not deterministic in the real world either, and we're still able to control the shape of structures and make them last for centuries.
This is a fallacy. Computers are very deterministic, a well designed program will not have any bugs or unforeseen failures at all. You're not planting a tree and going "oh god I hope it survives the winter", you're programming a human-made computer, made of hardware that undergoes such incredible scrutiny before it's ever powered on that you can trust that it executes the same code, the same way, every single time, for decades.
No idea why people who clearly don't understand the difference between poppy farms and computers come in here and claim the world isn't perfect and so we should all accept sloppy shit code that barely works. The world isn't perfect, but software CAN be quite close.
Every single instance of jank on computers is a bug that someone wrote, or an LLM wrote, that can be found, understood, and fixed. And only once you understand this, can you talk about software quality to other engineers. You need to understand that the baseline is that software is not fallible the way the rest of the world is.
See sqlite3 if you want to know what nearly bug-free software looks like. I can't point you to a potato farm or an artist who is perfect, but I can point you to that and say "this is where we go when humans do a good job".