Live data from Hacker News

Thoughts on slowing the fuck down

mariozechner.at

471–480 of 505 posts

Re: Thoughts on slowing the fuck down

#471
post #458

Earlier quoted context omitted.

Vendor lock-in is real and it’s scary. You are helpless to the constant price increases and each passing renewal you get deeper and deeper into the lock-in. Here’s to the day when someone clever with AI can disintermediate this situation. You don’t have to vibecode your own CRM but imagine a deterministic harness that lets you lego-block CRM functions like lead management, opportunity tracking, contact list, campaign…

Moving the vendor lock-in to the AI provider and exponentially increasing the pain of migration by locking all teams and all services in at once.

[deleted]

Re: Thoughts on slowing the fuck down

#472

Earlier quoted context omitted.

Software packages are more complicated than you make them out to be. Off the top of my head: - license restrictions, relicensing - patches, especially to fix CVEs, that break assumptions you made in your consumption of the package - supply chain attacks - sunsetting There’s no real “set it and forget it” with software reuse. For that matter, there’s no “set it and forget it” in civil engineering either, it also requi…

I have talked to colleagues who wrote software running on microcontrollers a decade ago, that software still runs fine. So yes there is set and forget software. And it is all around us, mostly in microcontrollers. But microcontrollers far outnumber classical computers (trivially: each classical computer or phone contain many microcontrollers such as SSD controllers, power management, wifi, ethernet, cellular,... And…

True, using a library in a cheap coffee maker you can maybe set it and forget it. I have an old TI-85 calculator that’s never needed to update its OS, while Apple has obsoleted multiple generations of applications in its never ending upgrade cycle.

But for mission critical applications the bar is a little higher. Isn’t this why we have the ongoing dialogue about OTA updates for Teslas etc and the pros and cons of that approach? Because if you can’t OTA patch a bug, you have to issue a recall [0]. But if you have internet connectivity, as you rightly point out, then you have a whole new attack surface to consider.

I just don’t think it’s all that simple.

[0]: https://www.cbsnews.com/amp/news/ford-recall-lincoln-explore...

Re: Thoughts on slowing the fuck down

#473

Earlier quoted context omitted.

I remember thinking of him as a skillful writer and a sometimes incisive thinker, back then. Apparently my taste has significantly improved in the interim; for a piece ostensibly about complexity, this is an embarrassingly superficial analysis from priors that already don't make any sense. I'm not going to knock a guy today based on an almost twenty-year-old piece, especially on subjects (cannabis legalization, the q…

I haven't read it in at least ten years myself - maybe it's not as good as I recall. I do remember that I appreciated his grasp of the fact that if you aren't deep in the weeds, you really cannot understand just how complex a system really is. I also appreciated the slow build to the actual point, which I think could help people who wouldn't hear a direct explanation understand what he was getting at. "'Shit's Easy'…

Well, sure. Trying to plan events at incomprehensibly large scale is like that, as the 20th century collectivist states failed largely in consequence of too late discovering. You have to retain a sense of scale in these things, not to say humility. Meanwhile, cannabis legalization in the US proceeds apace as a fifty-state patchwork, with simple possession still a major felony some places, while commercial distribution in others is a wholly legitimate storefront affair, and someone will eventually reap a small political windfall through federal recognition of the situation in being. No one is really planning anything. It is the assumption someone must that I'm criticizing, because for all the decades of planning indulged by the interminable old-times legalization advocates, their desideratum in practice looks nothing like they ever came close to seriously imagining or predicting.

To his dubious credit, I think Yegge has in the interim learned this lesson, possibly at the cost of some others. Looking at his "Gas Town" makes the hair stand up on the back of my neck, not least for that I once had ferrets and I know what chaos they embody and wreak (and how f—ing expensive they are!); I'm sure he was intentional in his choice of the metaphor, but he's always been one of those for whom consensus reality and good sense are likewise mostly optional. So in entire fairness I have to admit I really can't see any just criticism that he's planning too much these days. But the value in such a swing from one extreme to another, versus something more closely resembling moderation, charitably has yet to be demonstrated.

(As a programmer of both fintech and actual finance experience, btw, it's very comical to me to see the Big Design Up Front approach being applied in this way to this specific example, precisely because it so little resembles how anyone genuinely approaching the task does so. It is very much how I would expect the Google of 2009 to look at things. It isn't that much like how a bank or a startup does. But I said I wasn't going to beat up on old work, and I can't pretend I had so broad a perspective myself so long ago.)

Re: Thoughts on slowing the fuck down

#474

What the article doesn't touch on is the vendor lock-in that is currently underway. Many corps are now moving to an AI-based development process that is reliant on the big AI providers. Once the codebase has become fully agentic, i.e., only agents fundamentally understand it and can modify it, the prices will start rising. After all, these loss making AI companies will eventually need to recoup on their investments.…

If only the AI understands your code, then vendor lock-in and exposure to price hikes will be the least of your problems. I don't think that you will be able to add Claude as the Dev-On-Call to your pagerduty schedule. If you are in an industry that requires due diligence and you get sued for bugs that cause material damage and human suffering, then I don't think the "blame it on Claude" defense is going to land well in court. I cover these topics on https://www.exploravention.com/blogs/soft_arch_agentic_ai/ which is a blog I wrote recently.

Re: Thoughts on slowing the fuck down

#475
post #458

Earlier quoted context omitted.

Vendor lock-in is real and it’s scary. You are helpless to the constant price increases and each passing renewal you get deeper and deeper into the lock-in. Here’s to the day when someone clever with AI can disintermediate this situation. You don’t have to vibecode your own CRM but imagine a deterministic harness that lets you lego-block CRM functions like lead management, opportunity tracking, contact list, campaign…

Moving the vendor lock-in to the AI provider and exponentially increasing the pain of migration by locking all teams and all services in at once.

Not really. Mixture of models and mixture of experts have been around. It’s easy to switch a project harness from Codex to Claude to Gemini and to open models. You’re not locked in to a model, you’re more concerned about competitive token cost.

Re: Thoughts on slowing the fuck down

#476

What the article doesn't touch on is the vendor lock-in that is currently underway. Many corps are now moving to an AI-based development process that is reliant on the big AI providers. Once the codebase has become fully agentic, i.e., only agents fundamentally understand it and can modify it, the prices will start rising. After all, these loss making AI companies will eventually need to recoup on their investments.…

> Once the codebase has become fully agentic, i.e., only agents fundamentally understand it What exactly do we mean this? Because it is obviously common for human coders to tackle learning how an unfamiliar and complex codebase works so that they can modify it (new hires do it all the time). I can think this means one of two things: * The code and architecture being produced by agents takes approaches that are abnorm…

For your points:

- Garden path approaches are definitely a thing, but I don't think this is necessarily catastrophic. A lot depends on the language and framework in question, and also the driver of the change.

- I think it's that plus the fact it's easy to just generate ever more code. Solutions scale in every dimension until they hit a limit where it's not feasible to go further. If AI tools will allow you to write a project with a million or 10 million lines of code, you can bet it will eventually happen. Who's ever gonna fix that?

Re: Thoughts on slowing the fuck down

#477

Earlier quoted context omitted.

> But it's largely done now Somehow I doubt that. The monkey is never satisfied.

If that were true there wouldn’t be so many layoffs in the industry. Sure there is still some residual need for new software or modifying existing software. But it’s far less than it was say 30 years ago.

I suspect the layoffs are for financial reasons, not because software is "done".

It still takes incredible amounts of resources just to build and operate even modest piles of spaghetti. The industry is basically just layers of duct tape being applied all the time to hold things together. The average user can barely operate a computer. There's no consensus for handling identity or distributed computing. We still have a long way to go.

Re: Thoughts on slowing the fuck down

#478
post #387

Earlier quoted context omitted.

I wonder how Peter's views might have changed in the last three months.

Are you implying his incentives might have shifted?

I think he's working at OpenAI now, so the priority would shift from MVP that gets people excited, to "make it actually reliable for a billion people".

Re: Thoughts on slowing the fuck down

#479
post #182

It occurred to me on my walk today that a program is not the only output of programming. The other, arguably far more important output, is the programmer. The mental model that you, the programmer, build by writing the program. And -- here's the million dollar question -- can we get away with removing our hands from the equation? You may know that knowledge lives deeper than "thought-level" -- much of it lives in mus…

> The recent trend is to increase the output called programs, but decrease the output called programmers. That doesn't exactly bode well. Perhaps on a related note, I've noticed that a lot of the positive talks about AI are about quantity. On the other hand, there is disproportionately very little deep discussion about quality. And I mean not just short term, local quality, but more long term and holistic quality (e.…

> Perhaps on a related note, I've noticed that a lot of the positive talks about AI are about quantity. On the other hand, there is disproportionately very little deep discussion about quality.

and to me this is so weird, because from what I can tell, quantity hasn't been the winning factor for a very long time now

Re: Thoughts on slowing the fuck down

#480

Earlier quoted context omitted.

> What exactly do we mean this? Because it is obviously common for human coders to tackle learning how an unfamiliar and complex codebase works so that they can modify it (new hires do it all the time). I agree with you, BUT: I find it much harder to get my head around a medium sized vibe coded project than a medium size bespoke coded project. It's not even close. I don't know what codebases will look like if/when th…

And is "model collapse" a thing when LLMs are trained on 100% LLM-generated code? Fun times ahead.

What examples in history can be learned from here?
Post reply on HN