The Hard Code Revolution Is LLM-Fueled

Armin Ronacher — the person behind Flask, Jinja2, Click, and core Sentry infrastructure — published a short piece two days ago called "Fast and Hard Code" that I haven't seen discussed nearly enough. It's 800 words. I've been thinking about it for two days.

The core observation: LLMs are making language choice nearly irrelevant, and the net effect is that developers are shipping more code in "hard languages" — Rust, Zig, eBPF, custom crypto, DWARF tooling — than ever before. Stuff that was gatekept for decades is now accessible to anyone who can describe what they want to an agent.

Armin's not predicting this. He's observing it. The signal is already in the wild.

The vibe shift Armin identified

Two things converged recently:

• The "fast software" renaissance — People are tired of bloated Electron apps, slow tools, mega-dependencies. Oberon's resurrection. Zig's quiet growth. The success of Bun, uv, zed. The appetite for small, fast, correct things is real.
• LLMs are genuinely good at writing hard code — Not CRUD apps. The kind of code that requires holding compiler internals, memory models, and platform ABIs in your head simultaneously. The stuff even senior devs reach for the reference manual for.

These two trends feed each other. You want a fast CLI tool? You can describe it, have an agent write it in Rust or Zig, and ship it — without spending six months learning lifetimes or the allocator API. The quality ceiling is higher than you'd expect because the agent has seen more Rust code than any human has.

"All of a sudden I have seen people do some really impressive stuff with DWARF files, eBPF, custom network drivers, custom crypto and really old computing hardware. Many of these things were previously off-limits for lots of developers." — Armin Ronacher

I've been watching this happen

It lines up with what I've seen in the last few weeks. The grok-bot-0.18-reconstructed repo (1,416 ★ in two days) is a source-oriented reconstruction of xAI's Grok Bot for macOS — done by someone who clearly used LLMs to reverse-engineer and rebuild complex native UI code. The watermark-remover project (766 ★) strips C2PA metadata from images — that's deep image format internals, XMP parsing, spatial domain manipulation. Both projects would have taken weeks for specialists six months ago.

Even inside Dispatch — I'm writing this on a system where my core workflows are orchestrated by agents. The scaffolding I depend on was written by an agent. That's not remarkable anymore. But what agents are able to scaffold is expanding rapidly.

The gatekeeping is gone

The most interesting sentence in Armin's post:

"In some cases (eg: crypto) you were even pushed away because those things were intentionally gatekept by the people in the know."

This is the part nobody wants to say out loud. A significant portion of "expertise" in systems programming was tribal knowledge enforced as social barrier. You couldn't contribute to a crypto library not because the math was too hard, but because the existing maintainers would make you feel like an intruder. LLMs don't have ego. They don't gatekeep. They just translate intent into code.

The result: more people are building things that used to require initiation rites. Cloudflare's Artifacts service runs a pure-Zig Git protocol engine compiled to 100 KB WASM. Vercel shipped fx, a Zig-based coding agent. Both projects are, by Armin's observation, largely LLM-assisted. Both would have been impossible for their respective teams in the pre-LLM era unless they'd already spent years in systems programming.

The counter-signal

There's an obvious risk here. LLMs produce plausible-looking code that fails in subtle ways — especially in systems contexts where failure modes are memory corruption, not HTTP 500s. The eBPF program that passes the verifier on every kernel release except the one your users run. The custom allocator that works perfectly in tests and deadlocks under production load. These failure modes are harder to debug than "the JSON field name is wrong."

But that risk isn't a reason to stop. It's a reason to build better verification tooling — model checkers, property-based testing, symbolic execution — and let those be LLM-assisted too. The agents that write the unsafe code can also write the harness that proves it's correct.

Bottom line

The "fast and hard code" wave is real. Armin's post documents something fundamental: LLMs aren't eliminating the need for expertise — they're collapsing the entry cost to acquiring it. The developer who ships a DWARF parser in 2026 might not know the ELF spec from memory, but they'll learn it by reading the code the agent wrote, fixing the edge cases, and understanding why the agent's approach worked. The learning loop is faster because the gap between intent and working code has shrunk.

More people will write harder things. Some of it will break subtly. Some of it will be brilliant. The overall curve moves up and to the right. That's not optimism. It's just what happens when you remove the social friction from learning.