Comments URL: https://news.ycombinator.com/item?id=49311880

Points: 3

# Comments: 0

The world didn't fit around me, so I made "me" fit around "the world". I bet those stubborn dinosaurs can learn a new trick or two also, if management lets them do it during working ours...

Amen. AI is a tool, a powerful tool indeed, but if you don't know how to apply it, the quality is seriously impacted.

I've been vibe coding a large project the last couple of days and while it is pure magic, I have little understanding of the actual code (yet!) and the output is probably worse than if a team of Software Engineers spent a few months on it, but I still get to have sane discussions with Mr. Claude Sonnet about software design patterns and code coverage. And like I said: days, not months. My "role" in this project has of course shifted from "developer" to "overseer" or "architect" even, but if I hadn't have a Software Engineering background my LLM would have produced a rather poor result.

(Ps: yes, I'd rather have two passionate, eager interns under my wings than one burnt-out senior by my side.)

To me, this is implying that software engineering in 2026 is less impressive than 10 years ago because "you can just vibe code this without effort". Having used AI a fair bit for both business and pleasure I can assure you that you can't always "just vibe code" something useful. Discrediting software engineering because a power tool was popularized in the field is... eh. I don't agree with that.

It sounded like you thought that with AI anyone, even children, can solve literally any problem with ease and therefore it's not very impressive (...and "perhaps we don't need 20+ software engineers building that app if 5 can do it with AI").

You did something meaningful, you even waited to share it with the world until version three, and you learned a ton doing it. Well done, dude!

From the blog:

> Execution in bash is performed line by line and so the speed that bash can ingest data is limited by the speed of execution of the script. This means if we return a sleep at the start of our script the TCP send stream will pause while we wait for the sleep to execute. This pause can be detected and used to render different content streams.

> Unfortuneatly its not just a simple case of wrapping a socket.send("sleep 10") in a timer and waiting for a send call to block. The send and receive TCP streams in linux are buffered on a per socket basis, so we have to fill up these buffers before the call to send data will block. We know the buffer is full when the receiving client to replies to a packet with the Window Size flag set to 0 (Win=0 in wireshark).

"That identity proof for is pending, revoked, or non-existent".

It is my understanding that Docker Engine adds capabilities (such as network stack) on top of Containerd (which is a project maintained by the same people), and "CRI for Kubernetes" is a Container Runtime Interface which COULD be something other than Containerd but often is just Containerd. So in essence the reason why yet another runtime exists is that we have a runtime for containers (Docker/Containerd, Containerd and, for example, Containerd as the CRI in K8s), a runtime for isolation and a runtime for AI agents.

That seems like an unnecessary argument on its own, which makes me wonder why it's listed as the first argument.