The article discusses how LLMs are reducing friction in programming language choice, leading developers to adopt performance-oriented languages like Rust and Zig for fast, small software and enabling work with complex technologies previously considered difficult.
<p>One of the memes on Twitter is that “programming is solved now.” I’m not sure
to what degree it is, but one thing is pretty clear: the act of familiarizing
yourself with a language no longer matters and some of the friction that
mattered for humans does not matter for agents.</p>
<p>As a result, LLMs make language choice much less consequential than it used to
be. If you don’t like the choice, you can seemingly rewrite it in another
language and you can make it pick a language that you, as a programmer, are
entirely unfamiliar with.</p>
<p>Which in turn means that people can, and do, choose based on the marketing of
languages much more. As a long-term Rust programmer I found it quite
fascinating to see people now ship Rust code who previously might not have
chosen it. I attribute at least one part of this to two recent vibe shifts:
there is a lot more talk about wanting fast software, and about LLMs being
exceptional at optimizing code without regressing behavior.</p>
<p>Folks like Mitchell Hashimoto, Charlie Marsh, Jarred Sumner, Daniel Lemire and
quite a few others always carried a certain level of obsession with fast and
performant software and they also all happen to be receptive to agents writing
code. Maybe as a result, or unrelated others are now joining in. That’s
because with things like
<a href="https://github.com/davebcn87/pi-autoresearch">autoresearch</a> you don’t even
necessarily need to know all the tricks: you just need to put an agent on it —
though knowledge greatly helps!</p>
<p>If you look around, there are plenty of projects that want to be fast and small,
and they increasingly pick “hard languages”. And it’s not just Rust that is
benefiting. Even Zig — despite the fact that the creators and parts of the core
community are pretty negative on the whole AI thing — is too. For instance
Cloudflare’s new
<a href="https://blog.cloudflare.com/artifacts-git-for-agents-beta/">Artifacts</a> service
uses a pure-Zig Git-protocol engine, compiled to a roughly 100 KB WebAssembly
module and Vercel released <a href="https://github.com/vercel-labs/fx">fx</a>, a Zig coding
agent advertised to be small and fast. From what I can tell, all these projects
are largely LLM-assisted.</p>
<p>But it’s not just people picking less common languages but also that they are
increasingly working with “much harder” technologies. 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. In some cases (eg:
crypto) you were even pushed away because those things were intentionally
gatekept by the people in the know.</p>
<p>So maybe the world will have more slop, but it might also have more developers
in it, that want things to be fast and small.</p>
# Fast and Hard Code
Source: [https://lucumr.pocoo.org/2026/8/22/fast-hard-code/](https://lucumr.pocoo.org/2026/8/22/fast-hard-code/)
written on August 22, 2026
One of the memes on Twitter is that “programming is solved now\.” I’m not sure to what degree it is, but one thing is pretty clear: the act of familiarizing yourself with a language no longer matters and some of the friction that mattered for humans does not matter for agents\.
As a result, LLMs make language choice much less consequential than it used to be\. If you don’t like the choice, you can seemingly rewrite it in another language and you can make it pick a language that you, as a programmer, are entirely unfamiliar with\.
Which in turn means that people can, and do, choose based on the marketing of languages much more\. As a long\-term Rust programmer I found it quite fascinating to see people now ship Rust code who previously might not have chosen it\. I attribute at least one part of this to two recent vibe shifts: there is a lot more talk about wanting fast software, and about LLMs being exceptional at optimizing code without regressing behavior\.
Folks like Mitchell Hashimoto, Charlie Marsh, Jarred Sumner, Daniel Lemire and quite a few others always carried a certain level of obsession with fast and performant software and they also all happen to be receptive to agents writing code\. Maybe as a result, or unrelated others are now joining in\. That’s because with things like[autoresearch](https://github.com/davebcn87/pi-autoresearch)you don’t even necessarily need to know all the tricks: you just need to put an agent on it — though knowledge greatly helps\!
If you look around, there are plenty of projects that want to be fast and small, and they increasingly pick “hard languages”\. And it’s not just Rust that is benefiting\. Even Zig — despite the fact that the creators and parts of the core community are pretty negative on the whole AI thing — is too\. For instance Cloudflare’s new[Artifacts](https://blog.cloudflare.com/artifacts-git-for-agents-beta/)service uses a pure\-Zig Git\-protocol engine, compiled to a roughly 100 KB WebAssembly module and Vercel released[fx](https://github.com/vercel-labs/fx), a Zig coding agent advertised to be small and fast\. From what I can tell, all these projects are largely LLM\-assisted\.
But it’s not just people picking less common languages but also that they are increasingly working with “much harder” technologies\. 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\. In some cases \(eg: crypto\) you were even pushed away because those things were intentionally gatekept by the people in the know\.
So maybe the world will have more slop, but it might also have more developers in it, that want things to be fast and small\.
This entry was tagged[ai](https://lucumr.pocoo.org/tags/ai/),[programming](https://lucumr.pocoo.org/tags/programming/)and[thoughts](https://lucumr.pocoo.org/tags/thoughts/)
[copy as](https://lucumr.pocoo.org/2026/8/22/fast-hard-code.md)/[view](https://lucumr.pocoo.org/2026/8/22/fast-hard-code.md)markdown
The article argues that LLMs and AI tools are lowering the barrier for software performance optimizations, enabling custom adaptations like JIT compilers and regex engines that were previously too costly to implement.
The author argues that LLMs currently provide about a 2x productivity boost for coding due to their ability to handle easily verifiable tasks, but fundamental limitations prevent a 10x improvement; further gains will come from retooling around existing capabilities rather than model improvements.
The article discusses how AI assistance has simplified the creation of fast JIT compilers with sub-microsecond compile times, demonstrated through a Rust-based regular expression engine example.
The article describes various tricks and strategies for writing fast compilers, focusing on minimizing code execution, reducing memory usage, and optimizing common paths to achieve compilation speeds of over 500,000 lines of code per second.
An opinion piece arguing that LLMs perform better with boring, consistent languages and ecosystems (like Ruby on Rails) because the training corpus has lower variance, leading to more reliable agentic output, while fragmented ecosystems (like JavaScript) produce poor results.