Yeah, but "<company> at <ridiculously inflated price> is not far-fetched" is a great way to get people to think "it's not there now, but it will be", which is almost explicitly an attempt to boost stock prices.
Not everything is about stock prices, but some things are.
> if anything, LLMs/agents are rapidly eroding some of the practical premises his arguments depended on, IMO
As someone who also remembers classic Slashdot, it's staggering how many of the things Stallman was writing about back then came true. Software is centralized and subscription based, and largely not under the consumer's control. I fail to see how LLMs make any of these situations better, care to elaborate?
> Software is centralized and subscription based, and largely not under the consumer's control.
Is it really though? I'll grant that you might have a point with iOS/Android and things like banking apps (no problem with the apps existing, it's when there's no web-based alternative is where the real issue lies). But there's more (F)OSS code out in the wild then there's ever been, more (F)OSS alternatives to most major software, Steam runs on Linux, major companies like Google and Nintendo putting licensing notices where you can read them). Not to mention the rise of open source hardware, the whole makersphere, etc.
> I fail to see how LLMs make any of these situations better, care to elaborate?
By driving the cost of software to zero. I've had great success over the past year or so constructing a whole range of system software, the original "no driver for this printer" complaint Stallman had would be solved with an evening of Claude/Codex/etc usage now (and to prove my point, we just had someone crank out a Linux GPU driver for M4 Apple Silicon using LLMs)
> For example Hacker News learns my password to this web site every single time I sign in because that's just a secret.
I don't know the details of the login system for Hacker News, but i would expect they learn "a hash of your password and some salt" for every login, and your password isn't just transmitted to them. If they're doing things correctly, they're only storing a hash of your password, and can't work backward to get it -- that's a big If, and lots of places get it wrong.
> I don't know the details of the login system for Hacker News, but i would expect they learn "a hash of your password and some salt" for every login
No. That would be a terrible idea and so that's not what they do. You can go see for yourself, it's an HTML form, the text field with your password in it is submitted to their web server, much in the same way this larger field full of comment text was sent.
If you think a bit harder you'll realize why your approach would be a bad idea. A bad guy who has obtained the password hashes (for example by dumpster diving, or an SQL extraction) can just play back a hash they've seen without ever knowing your password, you've rendered the knowledge of the password useless.
Yes, that means if you've been around long enough, sites which had passwords but did not use TLS or before that SSL, were sending your actual password, unencrypted, for any snoop to see. That might seem crazy, but because I'm an old man when I first used the Internet it was normal to send your password, letter by letter in plain text, to connect to a remote Unix machine. The "Secure Shell" you take for granted today did not exist until July 1995.
That's not a bad idea and I believe it is how any modern not-a-website password based authentication works. Agreed that it does not address the attack vector of someone sniffing your password for site A and then logging into site A with it. However a key stretching algorithm (as opposed to just a hash) combined with salt does protect against an attacker logging into site B if the user reused his password.
Of course for a website and assuming TLS then in practice it doesn't make much difference whether the hashing takes place client side or server side since an attacker sitting on the server could presumably serve up a compromised frontend. And without TLS a MITM could again compromise the frontend. But hashing client side does at minimum prevent the service operator from accidentally logging plaintext passwords, and anyway not all services are web apps. An attacker can't trivially change out the frontend if it's an app on my phone.
I've never actually found a site that computes the hash client-side and sends the finished hash to the server, the vast majority just send the regular password to the backend to be hashed and compared (and HN is no exception).
And if you think about it, there's really no advantage to sending the hash every time anyway. An attacker that MITMs your traffic once can just resend the static post-computed hash to the backend anyway.
The only advantage would be preventing an attacker from seeing a password string you may re-use for other sites, but so long as it's unique for HN alone (surely we all use password managers on here? :-) ) it doesn't matter.
I don't think popularity is a goal for Anthropic or OpenAI. They merely want to have a product that they control and you depend on, and don't care about anything else.
They are identifying with this new powerful technology, because it makes them feel as if they're powerful also.
Like how drivers of monster trucks get a rush from feeling like the power of the machine is their own. Some users of LLMs exhibit the same kind of arrogance of being on the side of a powerful force, like the law enforcement or military. I imagine some gun owners get that rush too. When you take away the gun or the truck, suddenly they feel vulnerable.
I don't think he was calling everybody that is using LLMs a bunch of noobs. I think he was calling the people using LLMs to submit code they don't understand a bunch of noobs. I think if the patches were well reasoned and could be talked about in detail by their submitters, he'd have much less of a complaint.
20 years of being tech support for countless family members and acquaintances says that nothing can possibly make people care about "digital hygiene". An iPad, Chromebook, or similar inflexible device is perfect for most people, and marketing more flexible devices to them has been a mistake since the beginning.
> we would have to live in a world where software engineering didn't matter.
As an engineer who works very hard to do the right thing, I'm beginning to worry that software engineering doesn't matter. I write code that i think about a lot, understanding every line. It's not perfect, but I try to make sure my code is maintainable and well structured. I work much slower then my colleagues who produce unmaintainable slop at an alarming rate. In my career, no customer has ever complained about code structure or quality. It feels like I'm sinking in quicksand in an industry that's dying.
Of course customers do not care about code quality in and of itself. Just like they don't inherently care about the type of seam used for a garment. But they do care if their clothes fall apart after two washes. People care if software is buggy or slow or becomes harder to use or more expensive over time. And the way we know how to mitigate that is by ensuring code quality (it's definitely not the only factor, but an important one).
It's not about what the customer complains or notices at short term, is about having a quality system that can be augmented without accumulating same kind of debt. I can give a simple example. I have a coder here that filled the crontab of a server with periodic tasks. One of them was doing +200 failed requests per second and shutdown one of our routers. The router wrote so much logs that it changed the health of its internal disk from 15% to 85%. He doesn't even know what the crontab is. This kind of stuff is bound to happen more and more because the more you use AI to vibe, the more disconnected you get from the technology. And that's why I say, the only way that yolo vibecoding could work is if the base stuff didn't matter.
> It's not about what the customer complains or notices at short term, is about having a quality system that can be augmented without accumulating same kind of debt.
I agree with this wholeheartedly, but convincing nontechnical management of this fact has been extremely difficult. It was hard in the days of the stackoverflow copy-paste monkeys, and it's even harder in the age of LLMs.
Some people cannot be convinced of this, but some can, as long as you don't use technical language to describe the issue. Essentially, instead of saying "we need to prevent technical debt and have a maintainable software architecture" one needs to say stuff like "software quality enables a faster time-to-market for new features and less customer churn". i.e. put it in business-y terms.
Yes, but then it's really important to demonstrate that this is true. If they invest in what you propose, time to market for new features needs to actually become faster, or customer churn needs to actually decrease. It's not enough to put the proposal in business-y terms, it has to actually effect the claimed improvements to the business.
You have to pick metrics to show management that they understand the importance of, and then be able to demonstrate degradation in those metrics when you don't do what you propose, and improvements when you do. Accomplish this and you'll build trust.
Too often, what happens is that the proposed benefit is vague and not empirical, and then the benefit is not actually realized by a large investment into it, destroying trust.
Sometimes it matters and sometimes it doesn't. The hard part is figuring out which is which. The most effective engineers are those who maximize the amount of time they spend picking the right point in the trade-off at the right times. Choosing a preferred point on the continuum and sticking to that at all times simplifies decision making (itself a useful thing!) but it's not the optimal strategy.
There are a couple ways out of this conundrum. One is to try to get really good at picking the right point on the continuum as much as possible, which is essentially a forecasting problem (and thus it's really hard!). I think the somewhat easier choice is to pick roles that align well with your style. If you have a deliberate and near-perfection preference, you can seek to work on projects where there is no question of the importance of correctness. If you prefer the opposite, you can work on prototypes and zero-to-one type projects, and that will be more satisfying (and less catastrophic).
There have always been software companies that care about quality, and those that don't.
Many who don't care about quality exist because their products are forced onto their users. (Due to footholds from enterprise relationships, regulation, etc.) I bet slop will abound in these kinds of companies, but their codebases and products were already terrible anyways.
---
But research reliably shows users do care about things Just Working™ and feeling polished. With few exceptions, if software feels at all buggy or doesn't look visually amazing, you won't acquire/retain that many users.
Natural selection will teach hard lessons to the industry. Customers will notice things feeling "off" on products where AI slop is allowed to abound, and they'll flee to companies with sane approaches.
A sane approach: Humans actually guide the direction of the code which means they have to understand + review the code and course correct bad decisions. This doesn't mean agentic coding goes away, but it means this mad rush for insane velocity goes away.
---
Compare vibe-coded apps you've interacted with against world-class polished apps like Spotify, Gmail, Slack, etc. Those apps aren't obviously showing signs of AI slop, because the organizational structure is in place in those companies to prevent engineers from just throwing slop over the fence. Those engineers are doing agentic coding but are being forced to go at a sustainable pace.
The industry will eventually be forced (by the reality of business results) to recognize that this is the only approach that will lead to success.
Not everything is about stock prices, but some things are.
reply