Live data from Hacker News

Thoughts on slowing the fuck down

mariozechner.at

31–40 of 505 posts

Re: Thoughts on slowing the fuck down

#31

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…

People built a lot of great stuff with Ruby, PHP, Notes and VB. I don't know what the problem really is.

Personally I think that whole Karpathy thing is the slowest thing in the world. I mean you can spin the wheels on a dragster all you like and it is really loud and you can smell the fumes but at some point you realize you're not going anywhere.

My own frustration with the general slowness of computing (iOS 26, file pickers, build systems, build systems, build systems, ...) has been peaking lately and frankly the lack of responsiveness is driving me up the wall. If I wasn't busy at work and loaded with a few years worth of side projects I'd be tearing the whole GUI stack down to the bottom and rebuilding it all to respect hard real time requirements.

Re: Thoughts on slowing the fuck down

#32
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…

Were you not reviewing every line when a human wrote it before it went to prod? I think the output of these tools is about as good as a human would write - which means it needs thorough review if I’m going to be on the hook to resolve its issues at 2AM.

Re: Thoughts on slowing the fuck down

#33
post #27

Useful context here is that the author wrote Pi, which is the coding agent framework used by OpenClaw and is one of the most popular open source coding agent frameworks generally.

... people like that have a way of writing articles that don't seem to say anything at all.

Re: Thoughts on slowing the fuck down

#34

> it sure feels like software has become a brittle mess, with 98% uptime becoming the norm instead of the exception, including for big services As somebody who has been running systems like these for two decades: the software has not changed. What's changed is that before, nobody trusted anything, so a human had to manually do everything. That slowed down the process, which made flaws happen less frequently. But it w…

It also seems like massive consolidation has caused issues too. Everyone is on Github. Everyone is on AWS. Everyone is behind cloudflare. Whenever an issue happens here it effects everyone and everyone sees it.

In the past with smaller services those services did break all the time, but the outage was limited to a much smaller area. Also systems were typically less integrated with each other so one service being down rarely took out everything.

Re: Thoughts on slowing the fuck down

#35

If there is anyone who absolutely should slow down, it's the folks who are actively integrating company data with an agent -- you are literally helping removing as many jobs as possible, from your colleagues, and from yourselves, not in the long term, but in the short term. Integration is the key to the agents. Individual usages don't help AI much because it is confined within the domain of that individual.

> If there is anyone who absolutely should slow down, it's the folks who are actively integrating company data with an agent -- you are literally helping removing as many jobs as possible, from your colleagues, and from yourselves, not in the long term, but in the short term. I'm one of those people and I'm not going to slow down. I want to move on from bullshit jobs. The only people that fear what is coming are thos…

Exactly. The amount of bs bloatwork anywhere I've ever worked is insane and growing. We need to move on.

Re: Thoughts on slowing the fuck down

#36

I am "playing" with both pi and Claude (in docker containers) with local llama.cpp and as an exercise, I asked both the same question and the results are in this gist: https://gist.github.com/ontouchstart/d43591213e0d3087369298f... (Note: pi was written by the author of the post.) Now it is time to read them carefully without AI.

What I have leaned from the exercise above is that we paid more attention and spent more resources on "metadata" than real data. They are the rabbit holes that lead us to more metadata and forget what we really want.

We are all rabbits.

Re: Thoughts on slowing the fuck down

#37

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…

> People answered this wrong in the Ruby era, they answered it wrong in the PHP era Aren't you conveniently ignoring the fact that there were people saw through that and didn't go down those routes?

Change it to "Some people" if your pedanticism won't let you follow the flow.

Or better yet point out the better paths they chose instead. Were they wrestling with Java and "Joda Time"? Talking to AWS via a Python library named after a dolphin? Running .NET code on Linux servers under Mono that never actually worked? Jamming apps into a browser via JQuery? Abstracting it up a level and making 1,400 database calls via ActiveRecord to render a ten item to-do list and writing blog posts about the N+1 problem? Rewriting grep in Rust to keep the ruskies out of our precious LLCs?

Asking the wrong questions, using the wrong tools, then writing dumb blog posts about it is what we do. It's what makes us us.

Re: Thoughts on slowing the fuck down

#38
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…

It's a conversation I've had many times in my career and I'm sure I'll have many more. We've got code that seems plausible on a surface level, at a glance it solves the problem it's meant to solve - why can't we just send it to prod and address whatever problems we find with it later?

The answer is that it's very easy for bad code to cause more problems than it solves. This:

> Then one day you turn around and want to add a new feature. But the architecture, which is largely booboos at this point, doesn't allow your army of agents to make the change in a functioning way.

is not a hypothetical, but a common failure mode which routinely happens today to teams who don't think carefully enough about what they're merging. I know a team of a half-dozen people who's been working for years to dig themselves out of that hole; because of bad code they shipped in the past, changes that should have taken a couple hours without agentic support take days or weeks even with agentic support.

Re: Thoughts on slowing the fuck down

#39

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…

Maybe back in the beginning, but I don't think it's an engineering discipline now. I don't think that's bad though. I always thought we tagged on the word "engineer" so that we could make more money. I'm ok with not being one. The engineers I've known are very strict in their approach which is good since I don't want my deck to fall down. Most of us are too risky with our approach. We love to try new things and patte…

I’ve had jobs where my title was “software engineer”, but I never refer to myself as such outside of work. When I tell others what I do, I say I am a software developer. It may seem a pointless distinction, but to me there is a distinction.

Neither myself nor the vast majority of other “software engineers” in our field are living up to what it should mean to be an “engineer”.

The people that make bridges and buildings, those are the engineers. Software engineers, for the very very most part, are not.

Re: Thoughts on slowing the fuck down

#40
post #20

Earlier quoted context omitted.

We live in a world where every line of code written by a human should be reviewed by another human. We can't even do that! Nothing should go straight to prod ever, ever ever, ever.

> Nothing should go straight to prod ever, ever ever, ever. I'm one-shotting AI code for my website without even looking at it. Straight to prod (well, github->cf worker). It is glorious.

Were people reviewing your hobby projects previously? Were you on-call for your hobby website? If not - then it sounds like nothing changed?
Post reply on HN