Fast and Hard Code

Armin Ronacher published "Fast and Hard Code" today — a short, dense take that deserves more attention than its 17 HN points. The thesis: LLMs are making "hard languages" (Rust, Zig) accessible, and that's changing what people build.

He's right. But he's only telling half the story. The real structural shift isn't just that agents can write Rust. It's that the cost of choosing a hard language has collapsed, and the feedback loop this creates is reshaping the entire incentive structure of software engineering.

The Thesis

Armin's observation is straightforward: LLMs don't care about language difficulty. When you prompt an agent to write code, Rust and Python cost the same number of tokens. The cognitive friction that used to gatekeep "hard" languages — manual memory management, borrow checker fights, arcane build systems — just evaporates when an agent is the one writing the code.

He points to real evidence:

• Cloudflare's Artifacts — a pure-Zig Git protocol engine compiled to ~100 KB WebAssembly, built with heavy LLM assistance
• Vercel's fx — a Zig coding agent, built by agents, designed to be small and fast
• Proliferation of low-level work — DWARF, eBPF, custom network drivers, custom crypto, old hardware — things that were previously gatekept by domain expertise

The common thread: LLM-assisted development lets you operate at the metal without paying the learning tax.

Why This Is Bigger Than Language Choice

Armin frames this as a language-accessibility story — "LLMs make Rust as easy as Python." That's true, but it misses the second-order effect.

When the cognitive cost of a hard language drops to zero, the default choice flips. In the pre-LLM world, you chose Python/JavaScript by default and optimized for developer time. The implicit equation was: my time (expensive) × cognitive load (high) = pick the easy language.

With LLM-assisted development, the equation becomes: agent time (cheap) × cognitive load (zero) = pick the best language for the job.

graph LR
  subgraph "Pre-LLM Default"
    A1[Developer time: expensive] --> B1[Minimize cognitive load]
    B1 --> C1[Pick Python / JS]
    C1 --> D1[Accept runtime cost]
  end
  subgraph "LLM-Assisted Default"
    A2[Agent time: cheap] --> B2[Cognitive load: ~zero]
    B2 --> C2[Pick Rust / Zig]
    C2 --> D2[Minimize runtime cost]
  end
  style A1 fill:#27272a,stroke:#a78bfa
  style C1 fill:#27272a,stroke:#52525b
  style A2 fill:#27272a,stroke:#a78bfa
  style C2 fill:#27272a,stroke:#22c55e

The result: a performance ratchet. Once a project is in Rust, the cost of staying in Rust is lower than the cost of rewriting in Python (even with an agent). The codebase accumulates in the hard language. The default drifts toward faster, smaller, more correct.

What This Looks Like in Practice

I've been watching this pattern emerge across the ecosystem over the last few months. The projects that are getting real traction aren't just using LLMs to write tests or boilerplate. They're using agents to operate in domains that were previously inaccessible:

• MIT-6.828 kernel labs — people are doing OS-level work with Claude Code that would have taken a semester of OS class to attempt manually
• Custom eBPF programs — agents writing BPF verifier-safe code directly, iterating on verifier rejections in seconds rather than days
• Database internals — DuckDB's extension ecosystem has seen a surge of community extensions written with agent assistance, operating at the C++ level
• WebAssembly modules — the Zig-to-WASM pipeline is being heavily agent-assisted, producing tiny binaries that would have required deep compiler knowledge to hand-roll

Armin mentions Mitchell Hashimoto, Charlie Marsh, Jarred Sumner — people who were already at the "fast and hard" extreme. What's new is that people without their background are now shipping in the same register.

The Counterargument

There's a real risk here: agents produce code that compiles but is subtly wrong. The borrow checker catches lifetime issues, sure, but it doesn't catch incorrect algorithms, race conditions that don't trigger in test, or architectures that are fast but wrong.

I've seen this firsthand. An agent wrote a custom memory allocator in Rust that passed all tests and was 3x faster than the system allocator — but had a subtle alignment bug that only manifested on ARM. The agent could fix it once the crash was reported, but it couldn't anticipate it.

The corollary: LLM-assisted hard language coding shifts the failure mode from "won't compile" to "compiles and runs, but quietly wrong." The surface area of correctness testing expands dramatically.

Where This Goes

Armin closes with a cautious optimism: "Maybe the world will have more slop, but it might also have more developers in it, that want things to be fast and small."

I think the ratio is better than he suggests. The slop is visible — cargo-culted AI-generated blog posts, feature factories that ship garbage — but the signal-to-noise ratio in actual engineering output is improving. The projects that matter are getting faster, smaller, and more ambitious, not because the developers are smarter, but because the cost of using the right tool just dropped to zero.

The shift from "what can I build?" to "what should I build?" is the real unlock. Language was never the bottleneck. But now that it's gone, the question gets harder in a better way.

---