Why Agents Reach for React
Fifteen years building engineering platforms, currently focused on advanced AI infrastructure at yeet. I love turning the deeply complex topics into something everyone can understand. I relate deeply with the core yeet philosophy that you can just build things.
Current models are really good at front-end development. They can write vanilla JavaScript, they understand the DOM, event listeners, mutation observers, and low-level browser APIs.
So why do they often choose React when they are asked to build a substantial web application?
The short answer is that React provides a better abstraction for building and managing complex surfaces. And the same principle applies to the kernel. As the models continue their trajectory towards becoming extraordinary programmers, the more challenging languages like C, which is required to instrument eBPF, will become much easier to use. But just because they can, doesn’t mean they will…especially if there is a more productive choice available.
We grab for abstractions for the same reasons agents do. They make it so there are fewer variables to consider, and to get 100% right. They reduce resource spend, time or tokens, opening up an additional allowance of effort to spend on the actual problem. Essentially, they are how we stand on the shoulders of giants so that we can reach greater heights.
One of our favorite abstractions at yeet is Docker. You may have heard of it.
Solomon Hykes shows Docker to the public for the first time, PyCon 2013.
We like Docker because it reminds us of ourselves. See Docker is just an abstraction on top of namespaces, which have been in the Linux kernel for 24+ years. And even today, you can build a container yourself with unshare, cgroupfs, and chroot. But why would you? docker run turns a bunch of error-prone setup into a simple command. It’s plainly more efficient to use Docker.
eBPF is following a similar trajectory. Mount namespaces came out in Linux 2.4.19 in 2002, and Docker arrived on the scene in 2013, ~11 years later. eBPF became available in Linux 3.18 in 2014, and here we are ~12 years later, building the first true abstraction layer on top of it.
Our personal thesis on the future of AI coding is that models being better at programming doesn’t eliminate the value of abstractions or programming new ones. It’s rather the opposite. Better models make programmers, humans or machines, better at using them. Even in the long-term future, we don’t believe the frontier models are going to build a new browser every time they’re asked for a new website. The same goes for containers, eBPF and the Linux kernel. Long-standing primitives are the foundation of our digital world and the underlying compute layer that powers it.
So no, we’re not worried about Claude or Codex or any other model evolving their ability to write eBPF. Because that was never the hard part in the first place. Building the correct abstraction, the one that allows every programmer to easily utilize the amazing technology, and then move on with their project, is the hard part. docker run is magic. yeet run is the next chapter in the story.