Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Thoughts on slowing the fuck down

mariozechner.at

Post reply on HN
Print view View original

381–390 of 505 posts

Re: Thoughts on slowing the fuck down

#381

Post by 6510 »

marcosdumay wrote: post #262
6510 wrote: post #226

I keep returning to this thought: Assuming our abstraction architecture is missing something fundamental, what is it? My gut says something simple is missing that makes all of the difference. One thought I had was that our problem lives between all the things taking something in and spitting something out. Perhaps 90% of the work writing a "function" should be to formally register it as taking in data type foo 1.54.3…

You seem to be describing a type system.

walking away from the keyboard I thought I did a pretty poor job describing that one.

Ill try an example, those always have the potential to describe things even worse.

Imagine a type that is an outdoor datetimetemperature in utcc or a first name form value or a solitaire terms of service checkbox value. Have both the chewing gum balls in dispenser and a total weight of chewing gum balls in dispenser as well as a min-max weight per chewing gum ball in dispenser.

Make it just as ridiculous as it sounds. If you can quantify it a type must be registered. If there is a pair of quantifications to be had register that too.

The vision just expanded! Make for everything an xml implementation then do a ram drive and make all variables into files.

The idea sounds so ridiculous it might actually work. Think of the employment opportunities!

Re: Thoughts on slowing the fuck down

#382

Post by 6510 »

Hackbraten wrote: post #278
6510 wrote: post #226

I keep returning to this thought: Assuming our abstraction architecture is missing something fundamental, what is it? My gut says something simple is missing that makes all of the difference. One thought I had was that our problem lives between all the things taking something in and spitting something out. Perhaps 90% of the work writing a "function" should be to formally register it as taking in data type foo 1.54.3…

There's more to a function than just types. It's not sufficient to know that the function outputs a baz 42.0. You have to understand which one. The oldest? The latest? The one that matches the foo and bar input parameters? I think that's the part where it remains difficult. Someone has to convey clearly what the semantics and side effects of the function are. Consumers have to read and understand it. Failing that, yo…

If there is anything to know about the type register sub types for each.

Like the way we say something is an mp3. Why would it be good to have one unifying concept where we pretend a car crash and Beethoven are the same thing? It can be a WAV too!

Do you prefer hard or soft cover books?

Re: Thoughts on slowing the fuck down

#383

Post by vaultdweller101 »

SoftTalker wrote: post #44

> Companies claiming 100% of their product's code is now written by AI consistently put out the worst garbage you can imagine. Not pointing fingers, but memory leaks in the gigabytes, UI glitches, broken-ass features, crashes One thing about the old days of DOS and original MacOS: you couldn't get away with nearly as much of this. The whole computer would crash hard and need to be rebooted, all unsaved work lost. You…

Is the price of speed bloat? Where does the tolerance for less reliable software come from?

Re: Thoughts on slowing the fuck down

#384

Post by AbanoubRodolf »

SaucyWrong wrote: post #176
Towaway69 wrote: post #124

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

This is a great point, and I routinely use it as an argument for why seasoned professionals should work hard to keep their skills and why new professionals should build them in the first place. I would never be comfortable leasing my ability to perform detailed knowledge work from one of these companies. Sometimes the argument lands, very often it doesn't. As you said, a common refrain is, "but prices won't go up, co…

[flagged]

Re: Thoughts on slowing the fuck down

#385

Post by esseph »

Forgeties79 wrote: post #353
esseph wrote: post #350

Earlier quoted context omitted.

I mean, yeah. I've seen a network infrastructure monitoring system for an ISP, a router config generator tool, and a go-based BGP EVPN daemon in the past week. All are in production.

Were any of these created by people using AI who weren’t already capable of making them?

Maybe if you gave them a decade.

Re: Thoughts on slowing the fuck down

#386

Post by jillesvangurp »

chr15m wrote: post #379
emmitska wrote: post #372

"Do me a SOLID, YAGNI, give me a DRY KISS" — that's been my coding philosophy for 20 years. So when I came back to building after a long detour, I couldn't stomach watching agents confidently generate 400 lines where 40 would do. What I found is that the discipline was the feature, not the obstacle. I ended up pair programming closely — not because I distrusted the agent, but because I couldn't let go of the architec…

As well as pair programming with the AI, you can explicitly put those principles in AGENTS.md and the stochastic code generator will pay attention and be less verbose.

Exactly. There's a difference between vibe coding and agentic software engineering. One is just prompting and hoping for the best. It works surprisingly well, up to a point. And then it doesn't. If that's happening to you, you might be doing it wrong. The other is forcing agents to do it right. Working in a TDD way, cleaning up code that needs cleaning up, following processes with checklists, etc. You need to be diligent about what you put in there and there's a lot of experience that translates into knowing what to ask for and how. But it boils down to being a bit strict and intervening when it goes off the rails and then correcting it via skills such that it won't happen again.

I've been working on an Ansible code base in the past few weeks. I manually put that together a few years ago and unleashed codex on it to modernize it and adapt it to a new deployment. It's been great. I have a lot of skills in that repository that explain how to do stuff. I'm also letting codex run the provisioning and do diagnostics. You can't do that unless you have good guard rails. It's actually a bit annoying because it will refuse to take short cuts (where I would maybe consider) and sticks to the process.

I actually don't write the skills directly. I generate them. Usually at the end of a session where I stumbled on something that works. I just tell it to update the repo local skills with what we just did. Works great and makes stuff repeatable.

I'm at this point comfortable generating code in languages I don't really use myself. I currently have two Go projects that I'm working on, for example. I'm not going to review a lot of that code ever. But I am going to make sure it has tests that prove it implements detailed specifications. I work at the specification level for this. I think a lot of the industry is going to be transitioning that direction.

Re: Thoughts on slowing the fuck down

#387

Post by hschne »

andai wrote: post #302
simonw wrote: 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.

For reference, the creator of OpenClaw has roughly the opposite philosophy: https://steipete.me/posts/2025/shipping-at-inference-speed

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

Re: Thoughts on slowing the fuck down

#388

Post by mdavid626 »

Towaway69 wrote: post #124

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

There is no such thing as agentic codebase. If humans don’t understand it, nothing really does. Agents give zero fuck about anything. If they burn 100 or million tokens to add a feature, they don’t care. It’s the developers responsibility to keep it under control.

Re: Thoughts on slowing the fuck down

#389

Post by throwa356262 »

andai wrote: post #302
simonw wrote: 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.

For reference, the creator of OpenClaw has roughly the opposite philosophy: https://steipete.me/posts/2025/shipping-at-inference-speed

Jesus, that started like one of those LinkedIn posts where the author works 25 hrs/day and everyone who doesn't are going to be left behind.

Re: Thoughts on slowing the fuck down

#390

Post by Hackbraten »

6510 wrote: post #382
Hackbraten wrote: post #278

Earlier quoted context omitted.

There's more to a function than just types. It's not sufficient to know that the function outputs a baz 42.0. You have to understand which one. The oldest? The latest? The one that matches the foo and bar input parameters? I think that's the part where it remains difficult. Someone has to convey clearly what the semantics and side effects of the function are. Consumers have to read and understand it. Failing that, yo…

If there is anything to know about the type register sub types for each. Like the way we say something is an mp3. Why would it be good to have one unifying concept where we pretend a car crash and Beethoven are the same thing? It can be a WAV too! Do you prefer hard or soft cover books?

If I have two functions `GetCurrentBaz()` and `GetPreviousBaz()`, then I’m certainly not going to register `CurrentBaz` and `PreviousBaz` subtypes.

Those semantics are not properties of the type.

Post reply on HN