Going into this piece, I expected an analogy where the user is like an out-of-touch wealthy person, who builds a shallow model of the world from what they hear from their LLM chauffeur or golf-caddy.
That is something I fear will spread, as people give too much trust to the assistant in their pocket, turning to it at the expense of the other sources of information.
> That's when it hit me: this is going to change everything; but not in the utopian "everything is magical" sense, but in the "oh, God, what have we done" sense.
I think of it like asbestos, or leaded-gasoline. Incredibly useful in the right situation, but used so broadly that we regret it later. (Or at least, the people who didn't make their fortunes selling it.)
satisfice · 98d ago
The repeated use of the phrase “it works” is unhelpful. What the author means is “it appears to work.”
There is a vast difference between actually working and looking superficially like it works.
This is a massive testing problem.
rglover · 98d ago
That's the thing, though, it does work. Does it need a fair amount of hand holding to get there for non-trivial tasks? Yes. But if you have a basic skill set and some patience, you can get impressive results with a shocking number of common problems.
You're right that the "working" is superficial in a one-shot sense. But if you spend the time to nudge it in the right direction, you can accomplish a lot.
satisfice · 95d ago
As a software tester who takes pride in his vocation, I need to use words more carefully. I hope you will, too.
You are saying "it does work" for something that often seems to work, and for which you almost never carefully check to see that it is working (because that would be expensive). "Does" implies that it almost always actually works. That's not been my experience, nor, as I look around, does it seem to be anyone else's.
rglover · 94d ago
> you almost never carefully check to see that it is working (because that would be expensive)
I don't know about you, but I test everything thoroughly, whether I wrote it myself or used an LLM.
I think you're nitpicking over language here when what I said is clear. It can and does work with the proper amount of attention and effort, but that doesn't mean that it will just magically work with a one-shot attempt (though simpler code certainly can—e.g., "write me a debounce function").
As a software tester, you seem to be personalizing what I'm saying as encouraging developers to be a burden to you. Instead, I'm looking at it purely from a productivity standpoint. If your own team is just willy nilly dropping code that maybe works on your lap (with limited to no testing of their own), it might be time to find a new team. Being a tester in that type of environment will always be stressful, irrespective of how the code is written.
andy99 · 98d ago
This makes me think of eternal September which I'd say the author would argue we've reached with respect to coding.
rglover · 98d ago
I wasn't thinking about that when I wrote this but that's an accurate take.
anon373839 · 98d ago
I think this author makes the mistake, as many people do when they project AI trends forward, of ignoring the feedback mechanisms.
> Third, and I think scariest: it means that programming (and the craft of software) will cease to evolve. We'll stop asking "is there a better way to do this" and transition to "eh, it works." Instead of software getting better over time, at best, it will stagnate indefinitely.
“Eh, it works” isn’t good enough in a competitive situation. Customers will notice if software has weird bugs, is slow, clunky to use, etc. Some bugs can result in legal liability.
When this happens, other firms will be happy to build a better mousetrap to earn the business, and that’s an incentive against stagnation.
Of course, the FAANG type companies aren’t very competitive. But their scale necessitates serious engineering efforts: a bad fuck-up can be really bad, depending on what it is.
rglover · 98d ago
> Customers will notice if software has weird bugs, is slow, clunky to use, etc. Some bugs can result in legal liability.
I'd like to believe this, but some ~30 years into the popular internet, we still have bug-riddled websites and struggle to build simple software that's both usable (UX) and stable. You're right that if a company offers an SLA they're liable, but there's a wide range of software out there that isn't bound by an SLA.
That means that as this thing unfurls, we either get a lot of broken/low quality stuff, or even more consolidation into a few big player's hands.
> When this happens, other firms will be happy to build a better mousetrap to earn the business, and that’s an incentive against stagnation.
I agree this is likely, but the how is important. The hypothetical cost reduction of doing away with competent staff in favor of AI-augmented devs (or just agents) is too juicy for it to not become the norm (at least in the short-term). We're already seeing major players enforce AI-driven development (and in some cases, like Salesforce, impose hiring freezes under the assumption that AI is enough for most tasks).
The optimist in me agrees with what you're saying, but my gut take is that there will be a whole boatload of irrational, careless behavior before we see any meaningful correction.
Going into this piece, I expected an analogy where the user is like an out-of-touch wealthy person, who builds a shallow model of the world from what they hear from their LLM chauffeur or golf-caddy.
That is something I fear will spread, as people give too much trust to the assistant in their pocket, turning to it at the expense of the other sources of information.
> That's when it hit me: this is going to change everything; but not in the utopian "everything is magical" sense, but in the "oh, God, what have we done" sense.
I think of it like asbestos, or leaded-gasoline. Incredibly useful in the right situation, but used so broadly that we regret it later. (Or at least, the people who didn't make their fortunes selling it.)
There is a vast difference between actually working and looking superficially like it works.
This is a massive testing problem.
You're right that the "working" is superficial in a one-shot sense. But if you spend the time to nudge it in the right direction, you can accomplish a lot.
You are saying "it does work" for something that often seems to work, and for which you almost never carefully check to see that it is working (because that would be expensive). "Does" implies that it almost always actually works. That's not been my experience, nor, as I look around, does it seem to be anyone else's.
I don't know about you, but I test everything thoroughly, whether I wrote it myself or used an LLM.
I think you're nitpicking over language here when what I said is clear. It can and does work with the proper amount of attention and effort, but that doesn't mean that it will just magically work with a one-shot attempt (though simpler code certainly can—e.g., "write me a debounce function").
As a software tester, you seem to be personalizing what I'm saying as encouraging developers to be a burden to you. Instead, I'm looking at it purely from a productivity standpoint. If your own team is just willy nilly dropping code that maybe works on your lap (with limited to no testing of their own), it might be time to find a new team. Being a tester in that type of environment will always be stressful, irrespective of how the code is written.
> Third, and I think scariest: it means that programming (and the craft of software) will cease to evolve. We'll stop asking "is there a better way to do this" and transition to "eh, it works." Instead of software getting better over time, at best, it will stagnate indefinitely.
“Eh, it works” isn’t good enough in a competitive situation. Customers will notice if software has weird bugs, is slow, clunky to use, etc. Some bugs can result in legal liability.
When this happens, other firms will be happy to build a better mousetrap to earn the business, and that’s an incentive against stagnation.
Of course, the FAANG type companies aren’t very competitive. But their scale necessitates serious engineering efforts: a bad fuck-up can be really bad, depending on what it is.
I'd like to believe this, but some ~30 years into the popular internet, we still have bug-riddled websites and struggle to build simple software that's both usable (UX) and stable. You're right that if a company offers an SLA they're liable, but there's a wide range of software out there that isn't bound by an SLA.
That means that as this thing unfurls, we either get a lot of broken/low quality stuff, or even more consolidation into a few big player's hands.
> When this happens, other firms will be happy to build a better mousetrap to earn the business, and that’s an incentive against stagnation.
I agree this is likely, but the how is important. The hypothetical cost reduction of doing away with competent staff in favor of AI-augmented devs (or just agents) is too juicy for it to not become the norm (at least in the short-term). We're already seeing major players enforce AI-driven development (and in some cases, like Salesforce, impose hiring freezes under the assumption that AI is enough for most tasks).
The optimist in me agrees with what you're saying, but my gut take is that there will be a whole boatload of irrational, careless behavior before we see any meaningful correction.