Claude Code's agent loops provide a tangible upgrade in autonomy and structured reasoning. Remember that the terminal must be left on continuously and sessions are limited (e.g., 3-day max).
Still, agent loops significantly enhance efficiency for scoped coding tasks and allow Claude to autonomously cycle through context gathering, tool actions like code editing or testing, and result verification. New capabilities include seamless tool integration, user interruptibility, model switching (e.g., Sonnet for routine work, Opus for complex), and self-correction.
Most of us test our networked code on a fast, reliable local connection — which means we're testing a fantasy. The real world has packet loss, jitter, reordering, and latency that will quietly destroy assumptions you didn't know you'd made.
The fix has been in the Linux kernel since the early 2000s. No extra tools, no containers — just tc and netem, sitting there unused on basically every Linux machine. This post is about how to use them, and why you probably should have been using them all along.
We say "deploy the model" and "ship the model" as if it's software — but is it?
A .gguf or .safetensors file has no control flow, no executable instructions — it's inert without an inference engine. That makes it data, not code. Yet weights implicitly encode behavior the same way conditionals do, just in a non-linear way.
I feel the answer is "no" but I'm not sure that's the complete answer. I'm curious what others think.
> 'The thing nobody wants to say is that the reason serious programmers historically hated Go is exactly why LLMs are great at it: There's a ceiling on abstraction.
This lines up neatly with the kind of low‑abstraction systems I like running: 2021 HP PC with i7, bare‑metal‑ish, Crunchbang++, no desktop, openbox window manager. Boots to login in 17 seconds. Terminal front and center — local AI bare-metal inference, no wrapper, ffmpeg, ffplay, etc.
Go’s “no abstraction ceiling” feels like the same preference at the language level: shallow stack, no indirection, and code that stays close to the metal. That’s why LLMs work so well on Go: it’s opinionated, predictable, and there’s usually one obvious way to do things. Personally, I've come to love a LACK of abstraction.
This article mirrors exactly how I’ve been feeling. I'm tired of being attacked for using these tools. AI doesn’t diminish understanding—it forces us to admit that “full understanding” was always partial. Working with AI forces clearer thinking about boundaries, contracts, and system behavior. It makes engineering more explicit, more honest, and ultimately more rigorous, not less. This is the craft of software development evolving, not disappearing.
You're 100% right - I'm human - I want visitors to clone my repos and try my applications. But yeah, it's just another place to get let down - GitHub is the last platform on which you're going to get famous. That's my point - I'm trying to train myself to view the code I've put on there, and know it's as good as it can be and have that be enough.
"The string shouldn't be too tight, neither too loose." I needed to hear that, I think. The answers are always somewhere in between, right? Thanks for mentioning the books - I'm already interested in reading both.
OP - I was aware it was coined by Karpathy, but confess that I never knew the meaning in relation to his way of working which is cool. It's the snarky types on reddit who use that term derisively - and right, I should just ignore them. So, good points - I have to agree with you've said.
I wrote this because the term “vibe coding” irritates me. This meme has taken on a weird, dismissive tone that doesn’t reflect what serious AI-assisted programming actually feels like.
The piece is about how this meme obscures a genuine shift in developer workflows, especially for the many people who are actually shipping production code with aid of LLMs.
Curious how this community sees the term. Is it helpful? Misleading? Harmless? Something else?