Live data from Hacker News

Thoughts on slowing the fuck down

mariozechner.at

241–250 of 505 posts

Re: Thoughts on slowing the fuck down

#241
post #16

> You installed Beads, completely oblivious to the fact that it's basically uninstallable malware. Did I miss something? I haven't used it in a minute, but why is the author claiming that it's "uninstallable malware"?

Have a read through everything that's needed for a full uninstall: https://gist.github.com/banteg/1a539b88b3c8945cd71e4b958f319...

Minimalist alternative with no hooks or dependencies for the curious: https://github.com/wedow/ticket

Re: Thoughts on slowing the fuck down

#242

Earlier quoted context omitted.

In my lifetime software has given us: * the ability to find essentially any information ever created by anyone anywhere at anytime, * the ability to communicate with anyone on Earth over any distance instantaneously in audio, video, or text, * the ability to order any product made anywhere and have it delivered to our door in a day or two, * the ability to work with anyone across the world on shared tasks and project…

I have watched artists thoughtfully integrate digital lighting and the like at a scale I'd never seen before the LLMs rolled up and made it possible to get programs to work without knowing how to program. The fundamental ceiling of what an LLM can do when connected to an IDE is incredible , and orders of magnitude higher than the limits of any no-code / low-code platform conceived thus far. "Democratizing" software -…

Emacs can be configured with no code written by the user and Linux can be controlled with minimal user knowledge of the command line. Still some knowledge is necessary in most cases, but nowhere near what was required a handful of years back.

Re: Thoughts on slowing the fuck down

#243

Earlier quoted context omitted.

This is a good point. I've seen people with really complex AI setups (multiple agents collaborating for hours). But what are they building? Are they building a react app with an express backend? A next js app? Which itself is a layer on top of an abstraction? I haven't tried this myself but I'm curious if an LLM could build a scalable, maintainable app that doesn't use a framework or external libraries. Could be dang…

When it comes time to debug would you rather ask questions about and dig through code in a popular open source library, or dig through code generated by an LLM specifically for your project?

The copout answer is it depends. I've debugged sloppy code in React both before and after LLMs were commonly used. I've also debugged very well-written custom frameworks before and after LLMs.

I think with proper guardrails and verification/validation, a custom framework could be easier to maintain than sloppy React code (or insert popular framework here).

My point is that as long as we keep the status quo of how software is built (using popular tools that male it fast and easy to build software without LLMs that often were unperformant), we'll keep heading down this path of trying to solve the problems of frameworks instead of directly solving the problems with our app.

(BTW, it was your comment to my comment that inspired my comment, talk about meta! https://news.ycombinator.com/item?id=47512874 )

Re: Thoughts on slowing the fuck down

#244
post #217

Earlier quoted context omitted.

If the LLM doing it, it doesn't matter, isn't that the point? Not saying I personally believe in this scenario, but everything I've heard supports the idea that code is no longer for humans to consume.

You are going to allow a product from a company you have no reason to trust write important software for you and put it into production without checking the code to see what it does?

A lot of us use software written by other people we have no reason to trust and we haven't reviewed - most of open source libraries.

Re: Thoughts on slowing the fuck down

#245
post #168

Earlier quoted context omitted.

> What are you building? This x1000. The last 10 years in the software industry in particular seems full of meta-work. New frameworks, new tools, new virtualization layers, new distributed systems, new dev tooling, new org charts. Ultimately so we can build... what exactly? Are these necessary to build what we actually need? Or are they necessary to prop up an unsustainable industry by inventing new jobs? Hard to sha…

> Are these tools necessary to build what we actually need? I think the entire software industry has reached a saturation point. There's not really anything missing anymore. Existing tools do 99% of what we humans could need, so you're just getting recycled and regurgitated versions of existing tools... slap a different logo and a veneer on it, and its a product.

The tools are mostly there, but there is a lot of need. Quality can be much better. Quality is UI, reliability, security, and a bunch of other similar things I can't think of offhand.

Re: Thoughts on slowing the fuck down

#246

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.…

I have similar concerns.

We will miss SaaS dearly. I think history is repeating just with DVD and streaming - we simply bought the same movie twice.

AI more and more feels the same. Half a year ago Claude Opus was Anthropics most expensive model - boy, using Claude Opus 4.6 in the 500k version is like paying 1 dollar per minute now. My once decent budgets get hit not after weeks but days (!) now.

And I am not using agents, subagents which would only multiply the costs - for what?

So what we arrive more and more is the same as always: low, medium, luxury tier. A boring service with different quality and payment structures.

Proof: you cannot compensate with prompt engineering anymore. Month ago you fixed any model discrepancies by being more clever and elaborate with your prompts etc.

Not anymore. There is a hidden factor now that accounts for exactly that. It seems that the reliance on skills and different tiers simply moves us away from prompt engineering which is considered more and more jailbreaking than guidance.

Prompt engineering lately became so mundane, I wonder what vendors were really doing by analyzing the usage data. It seems like that vendors tied certain inquiries with certain outcomes modeled by multistep prompting which was reduced internally to certain trigger sentences to create the illusion of having prompted your result while in fact you haven't.

All you did was asking the same result thousands of user did before and the LLM took an statistical approach to deliver the result.

Re: Thoughts on slowing the fuck down

#247
post #6

I think the core idea here is a good one. But in many agent-skeptical pieces, I keep seeing this specific sentiment that “agent-written code is not production-ready,” and that just feels… wrong! It’s just completely insane to me to look at the output of Claude code or Codex with frontier models and say “no, nothing that comes out of this can go straight to prod — I need to review every line.” Yes, there are still iss…

Not having a code review process is archaic engineering practice at this point(at any point in history, really), be it for human written or AI written code.

Re: Thoughts on slowing the fuck down

#248
post #217

Earlier quoted context omitted.

If the LLM doing it, it doesn't matter, isn't that the point? Not saying I personally believe in this scenario, but everything I've heard supports the idea that code is no longer for humans to consume.

You are going to allow a product from a company you have no reason to trust write important software for you and put it into production without checking the code to see what it does?

had another thought on my drive just now. nextjs is really fantastic with LLM usage because there's so much body of work to source from. previously i found nextjs unbearable to work with with its bespoke isomorphic APIs. too dense, too many nuances, too much across the stack.

with LLMs it spit it out amazingly fast. but does that make nextjs the framework better or worse in design paradigms, that LLM is a requirement in order to navigate?

Re: Thoughts on slowing the fuck down

#249
post #6

I think the core idea here is a good one. But in many agent-skeptical pieces, I keep seeing this specific sentiment that “agent-written code is not production-ready,” and that just feels… wrong! It’s just completely insane to me to look at the output of Claude code or Codex with frontier models and say “no, nothing that comes out of this can go straight to prod — I need to review every line.” Yes, there are still iss…

The article didn't say to read every line though. Just the interesting ones. If you don't know where the interesting ones are, you have already lost.

Re: Thoughts on slowing the fuck down

#250

I suppose everyone on HN reaches a certain point with these kind of thought pieces and I just reached mine. What are you building? Does the tool help or hurt? People answered this wrong in the Ruby era, they answered it wrong in the PHP era, they answered it wrong in the Lotus Notes and Visual BASIC era. After five or six cycles it does become a bit fatiguing. Use the tool sanely. Work at a pace where your understand…

> What are you building? Does the tool help or hurt?

> People answered this wrong in the Ruby era, they answered it wrong in the PHP era, they answered it wrong in the Lotus Notes and Visual BASIC era.

I'm assuming you're saying these tools hurt more than help?

In that case I disagree so much that I'm struggling to reply. It's like trying to convince someone that the Earth is not flat, to my mental model.

PHP, Ruby and VB have more successful code written in them than all current academic or disproportionately hyped languages will ever have combined.

And there's STILL software being written in them. I did Visual Basic consulting for a greenfield project last week despite my current expertise being more with Go, Python, C# and C. And there's a RoR work lined up next. So the presence gap between these helpful tools and other minor, but over index tools, is still increasing.

It's easy to think that the languages one see mor often in HN are the prevalent ones but they are just the tip of the iceberg.

Post reply on HN