Man.. just code, let people build, design, adjust. Who cares? Who are these people writing these posts? Why should we give anything they have to say warrant? These posts are getting old, very quick.
It's a product of the times. You have some folks who are really passionate about the craft of software, some folks to whom it's just a job, and an entire culture that promotes and incentivizes engagement through raw emotional connection (outrage, passion, pick an emotion).
What you don't see from most perspectives are the silent masses who simply don't engage, don't care about the discussion, and/or are too busy doing what they enjoy.
I think too many people (very much including me) who are "passionate about the craft of software" allowed themselves to become too focused on the code itself as if that were the first order concern of the craft. But the craft has always been about the quality of the software, including how its quality changes as a function of time and adaptation. Code quality is only in support of that concern, it is not itself the primary concern.
It has been a fairly painful experience for me to shift my thinking on this, but it's a much better mindset. I still care about many of the same code quality concerns I always have, but I'm thinking a lot more about why I care than I once did.
To analogize coding to sculpting - you're in the "toddler with playdough" phase. At some point you might want to make something other people will find pleasing and maybe even worth putting on display, the rules of composition, the details of materials, and the techniques for not wasting expensive materials suddenly become important.
If you're just writing code to fuck around or automate a small part of your life, whatever. But if you're making a big system or wanting other people to use your product, these things about how to make good software become more relevant.
I work in an industry where software bugs can cause real harm to real people. I care that my coworkers are producing more bugs than ever because they don't take the time to think about the code anymore.
Then where are your industrial controls to catch bugs before they are introduced to the product? Where is the feedback loop to the developers running the AI to control the situation?
LLMs should not touch these technologies. Keep your slop factories in webdev. We have missles, planes and pacemakers to make still. If you ever feel like using your brain again, theres plenty of work to be done that llms cannot touch.
Surely those industries are not relying on humans writing "good code" to make sure faults are not introduced, right? There are static analysis and automated testing and rigorous QA processes, surely?
I think that we should realistically expect that even a very rigorous testing and validation process is not fool proof, just as we anticipated that the code isn't.
I don't think my comment implied that any testing and validation process will be fool proof. There are two claims in the comment I replied two, first that people are creating "more bugs than ever". I take that to mean more bugs per line of code or more bugs per unit of functionality or something like that. If that's the case, then I think it implies that testing and validation has gotten worse per that same unit, which I think suggests that it could be improved, without expecting it to become fool proof. Then there is a causal claim, that these bugs are because people are not thinking about the code. Maybe so, but to me, it seems more likely to be caused by inadequate validation.
> I don't think my comment implied that any testing and validation process will be fool proof.
It does by, attributing a change in quality to a "testing and validation problem".
If there is a change in programming methodology, as far as we know no change in testing and validation methodology and at the same time an increase in the production of bugs, it's not reasonable to attribute that increased error rate to testing and validation getting worse.
It's like adding spinning saw blades to the fronts of cars and then attributing the increased fatality rates to pedestrians not wearing safety reflectors.
If it happened as you describe, with no change in the testing and validation processes, then it exposed an existing weakness in those processes, which should be improved.
In your analogy, what I would say is that the saw blades on the front of cars situation exposed a weakness in the regulatory regime for what can be put on the front of cars, which should be improved.
> If it happened as you describe, with no change in the testing and validation processes, then it exposed an existing weakness in those processes, which should be improved.
I remind you that the belief you are defending is that an increase in the number of bugs produced per some unit of implementation "implies that testing and validation has gotten worse", not the general idea that you can or should improve software quality by improving testing and validation.
If we adopt the realistic perspective that the testing and validation process can only catch some fraction of bugs, then an increase in the number of bugs produced in the implementation stage is bad irrespective of what that fraction is. You can improve the testing and validation process so as to minimize the fraction of bugs that get past QA, but when you multiply that by the number of bugs produced in implementation you will be worse off if you produce 7 bugs per month during implementation than if you produce 5 bugs, regardless of whether you can also improve the testing and validation process. You will on average, over time, have fewer bugs in production if you produce fewer bugs during implementation given any testing and validation process that isn't completely fool proof.
No, what I'm defending is my initial comment in this thread:
> Isn't this a testing and validation problem?
One way for it to be that kind of problem is by exposing weakness in the existing approach. Another way would be if the approach was worsened. But both things fit my original contention.
I don't disagree with your concluding paragraph at all. But what I think is that there is no reason that implementing with llm based tooling implies an increased defect rate. Rather, I think it implies that there are existing or new holes in the quality process.
You could also just remove the product from the market. That will guarantee a reduction of bugs in production to 0. That exposes a weakness in the existing approach to marketing and overall product design, meaning the problem is in marketing and product design.
> Who cares? Who are these people writing these posts? Why should we give anything they have to say warrant? These posts are getting old, very quick.
Anyone could say the same about any post they don't agree with, doesn't seem very helpful.
I don't know, we spent the last few years with tons of posts telling us "coding is dead" and the biggest companies in the world telling us our jobs are going to go extinct.
That mindset has also deteriorated my working environment due to some coworkers buying into it.
So it's kind of nice to see some sanity checks that align with my beliefs too. I can share articles like this with my teammates. I can see that I'm not alone in thinking most LLM code is slop.
I think too junior devs NEED to see this. My team had a couple of promising juniors who are now completely brain rotted by AI and can't even write "Hello World" without consulting Claude anymore.
Yeah I agree. We're still swinging this pendulum. We haven't found the stable equilibrium yet. It's useful for people to keep having this debate.
peterpanhead · · focus · HN ↗
ill-ion · · focus · HN ↗
mathgeek · · focus · HN ↗
What you don't see from most perspectives are the silent masses who simply don't engage, don't care about the discussion, and/or are too busy doing what they enjoy.
sanderjd · · focus · HN ↗
It has been a fairly painful experience for me to shift my thinking on this, but it's a much better mindset. I still care about many of the same code quality concerns I always have, but I'm thinking a lot more about why I care than I once did.
kkapelon · · focus · HN ↗
Also a confirmation to people who have the same inner thoughts and are ashamed to admit in public that they think the exact same thing.
I think we need such kind of posts to combat the influx of AI news.
sophacles · · focus · HN ↗
If you're just writing code to fuck around or automate a small part of your life, whatever. But if you're making a big system or wanting other people to use your product, these things about how to make good software become more relevant.
goda90 · · focus · HN ↗
[deleted] · · focus · HN ↗
[deleted]
pixl97 · · focus · HN ↗
physicallyIllfr · · focus · HN ↗
sanderjd · · focus · HN ↗
sanderjd · · focus · HN ↗
boomlinde · · focus · HN ↗
With that in mind, writing bad code is bad.
sanderjd · · focus · HN ↗
boomlinde · · focus · HN ↗
It does by, attributing a change in quality to a "testing and validation problem".
If there is a change in programming methodology, as far as we know no change in testing and validation methodology and at the same time an increase in the production of bugs, it's not reasonable to attribute that increased error rate to testing and validation getting worse.
It's like adding spinning saw blades to the fronts of cars and then attributing the increased fatality rates to pedestrians not wearing safety reflectors.
sanderjd · · focus · HN ↗
In your analogy, what I would say is that the saw blades on the front of cars situation exposed a weakness in the regulatory regime for what can be put on the front of cars, which should be improved.
boomlinde · · focus · HN ↗
I remind you that the belief you are defending is that an increase in the number of bugs produced per some unit of implementation "implies that testing and validation has gotten worse", not the general idea that you can or should improve software quality by improving testing and validation.
If we adopt the realistic perspective that the testing and validation process can only catch some fraction of bugs, then an increase in the number of bugs produced in the implementation stage is bad irrespective of what that fraction is. You can improve the testing and validation process so as to minimize the fraction of bugs that get past QA, but when you multiply that by the number of bugs produced in implementation you will be worse off if you produce 7 bugs per month during implementation than if you produce 5 bugs, regardless of whether you can also improve the testing and validation process. You will on average, over time, have fewer bugs in production if you produce fewer bugs during implementation given any testing and validation process that isn't completely fool proof.
sanderjd · · focus · HN ↗
> Isn't this a testing and validation problem?
One way for it to be that kind of problem is by exposing weakness in the existing approach. Another way would be if the approach was worsened. But both things fit my original contention.
I don't disagree with your concluding paragraph at all. But what I think is that there is no reason that implementing with llm based tooling implies an increased defect rate. Rather, I think it implies that there are existing or new holes in the quality process.
boomlinde · · focus · HN ↗
sanderjd · · focus · HN ↗
bakugo · · focus · HN ↗
Anyone could say the same about any post they don't agree with, doesn't seem very helpful.
zxor · · focus · HN ↗
That mindset has also deteriorated my working environment due to some coworkers buying into it.
So it's kind of nice to see some sanity checks that align with my beliefs too. I can share articles like this with my teammates. I can see that I'm not alone in thinking most LLM code is slop.
I think too junior devs NEED to see this. My team had a couple of promising juniors who are now completely brain rotted by AI and can't even write "Hello World" without consulting Claude anymore.
sanderjd · · focus · HN ↗