Are those not the exact same workflows, just replacing "I spent time learning" with claude?
I find that if you don't skip the learning step, you can then use the tool more efficiently(e.x. you learn to measure twice and verify so you can iterate in 1-2 prints instead of 3-4)
I am not averse to learning (I spent hours learning Sketchup many years ago when redesigning my garage).
But the time freed up not learning Fusion360 freed up time to learn about different kinds of fasteners, clasps, how to arrange magnets, etc, so I moved the learning to a different place.
Plus avoiding the "wife is angry cuz this project I over-engineered has gone on for weeks unsolved" factor is always a nice bonus.
It's also known as "commodification of labour", and AI is just the latest and greatest tool to do it.
Luddites complained that the trajectory of technology was to allow less skilled workers to mass produce goods via machines owned by factory owners, as opposed to helping skilled workers build up and use their skills while passing them on.
Now we have a lot of money and time focused on LLMs owned by a few companies, making it easier for them to monetize low skill labour(prompting versus art/research/artisanry)
> Luddites complained that the trajectory of technology was to allow less skilled workers to mass produce goods via machines owned by factory owners, as opposed to helping skilled workers build up and use their skills while passing them on.
And their complaint was valid from their perspective, but the end result of that process is that now you can have functional and pretty clothing for pennies.
It's true that a lion's share of the gain was pocketed by people who owned the mechanized looms. Now imagine how much more of an advantage it would have been without those people.
Same thing here. We can - and should - get rid of all the megacorp leeches. But the benefits of cheap automation remain regardless, and it's still the same equation - removing the gatekeeping harms those who relied on it to keep the products of their labor priced high, while benefitting everyone else.
You're glossing over the fact that they assumed youtube would want to assign a UUID to each pixel in a 4k@60fps video as the use case that this would fail for...
I don't think they're discounting that distrust can be legitimate, they're questioning whether it's useful to distrust somebody when it's not your job to micromanage them or they're providing adequate output.
If anything that to me strengthens the equivalence.
Do you think we will ever be able to stamp out phishing entirely, as long as humans can be tricked into following untrusted instructions by mistake? Is that not an eerily similar problem to the one we're discussing with LLMs?
Edit: rereading, I may have misinterpreted your point - are you agreeing and pointing out that actually LLMs may be worse than people in that regard?
I do think just as with humans we can keep trying to figure out how to train them better, and I also wouldn't be surprised if we end up with a similarly long tail
Are you not worried that anthropomorphizing them will lead to misinterpreting the failure modes by attributing them to human characteristics, when the failures might not be caused in the same way at all?
Why anthropomorphize if not to dismiss the actual reasons? If the reasons have explanations that can be tied to reality why do we need the fiction?
> Are you not worried that anthropomorphizing them will lead to misinterpreting the failure modes by attributing them to human characteristics, when the failures might not be caused in the same way at all?
On the other hand, maybe techniques we use to protect against phishing can indeed be helpful against prompt injection. Things like tagging untrusted sources and adding instructions accordingly (along the lines of, "this email is from an untrusted source, be careful"), limiting privileges (perhaps in response to said "instructions"), etc. Why should we treat an LLM differently from an employee in that way?
I remember an HN comment about project management, that software engineering is creating technical systems to solve problems with constraints, while project management is creating people systems to solve problems with constraints. I found it an insightful metaphor and feel like this situation is somewhat similar.
Because most people talking about LLMs don't understand how they work so can only function in analogy space. It adds a veneer of intellectualism to what is basically superstition.
We all routinely talk about things we don't fully understand. We have to. That's life.
Whatever flawed analogy you're using, it can be more or less wrong though. My claim is that, to a first approximation, LLMs behave more like people than like regular software, therefore anthropomorphising them gives you better high-level intuition than stubbornly refusing to.
> But I would be pretty irritated if the government stepped in and mandated they make my searches public and linkable to me.
Who is calling for this? Are you perhaps taking an absolutist view where "not destroying evidence" is the same as "mandated they make my searches public and linkable to me"? That's quite ridiculous.
Discovery routinely leaks. Handing over every chat from every user to opposing council has both human, technical, and incentive issues that make it far more likely that something I told ChatGPT with an understanding of its privacy limitations will appear in a torrent.
I don't understand your logic. Should security reports never be published that say "hash the password before storing it in the DB". Boring research is boring most of the time, that doesn't make it unimportant, no?
No, but it's not the database's fault if you don't hash your password. Same here, it's human error, not "MCP vulnerability". It's not that GitHub MCP needs fixing, but rather how you use it. That's the entire point of my reasoning for this "exploit."
I find that if you don't skip the learning step, you can then use the tool more efficiently(e.x. you learn to measure twice and verify so you can iterate in 1-2 prints instead of 3-4)
reply