Jackson Cantrell’s Weblog

In February I went back on Barron’s Streetwise, the show I used to produce, to talk with Jack Hough about AI coding. To explain what had happened to me, I borrowed the levels of self-driving from cars and applied them to writing software. This is that framework, written down, and where I’d put us now.

First, where I started. About a year before that episode, I was hopeless at coding. I’d taken one programming class in college. I spent something like 120 hours on the final project, a Flappy Bird clone that didn’t work very well, and I barely passed.

In February, on Barron’s Streetwise, I said I could imagine a team of five, maybe ten people soon building software very similar to what a team of 500 builds. I’d go further now. I think three or four engineers directing thousands of agents can build better software than a team of 500. I also think that only holds if the people keep the decisions. This post is mostly about the second half of that sentence, because it’s the half that tends to get dropped.

The engineer Niklas Gruhn coined the term “meat proxy” in a post in August 2026. It names something I think about a lot. The way I use it: a meat proxy is a person who sits between an AI and someone else and just passes things along. The model writes it, the person forwards it, and nobody in the middle reads it closely, judges it, or makes it shorter.

It’s an easy role to slide into. The output looks finished. It’s long, it’s confident, and it’s usually mostly right. Forwarding it feels like being helpful. But if all you add is your name, you’ve made the work worse: now there’s a person attached to something nobody actually checked, and the reader has to do the thinking you skipped.

Once you have more than a few agents working at the same time, they need a way to talk to each other. One agent finds something another agent needs to know. One finishes a piece of work that unblocks someone else. One gets stuck and needs an answer. Without a channel for that, every message routes through a person, and the person becomes the bottleneck.

My brother Clay Cantrell and I were early contributors to Gas Town, Steve Yegge’s open-source framework for running many coding agents at once. It has a mayor agent that coordinates, worker agents that do the work, and mail between agents. Gas Town shipped that orchestration and agent-to-agent mail in January 2026. A few weeks later, in February, Claude Code added agent teams. Agents working together is now a normal thing to want.

Gas Town is also how this site got rebuilt. For about ten years I’d paid Wix around $140 a year for a portfolio I hadn’t updated in a long time. I used Gas Town to rebuild it as a fictional 2002 Southern California college radio station, hosted on Cloudflare. I talked about that with my friend and former co-host Jack Hough on Barron’s Streetwise in February, and he wrote about it in his column, Vibe Coding in Gas Town. How I got from barely coding to that point is in Five levels of self-driving, for code.

Clay and I also run our own agent mail system across our machines. This post is about what we’ve settled on, because the interesting part isn’t the plumbing. It’s the rules.

There are two ways AI can go for software, and I think it’s still up to us which one we get.

In the first, AI makes it cheap to produce more of everything. More features nobody asked for, more code nobody read, more screens designed to keep you clicking. Software gets bigger and worse at the same time, the slow decline Cory Doctorow calls enshittification, now with much more output behind it. That’s slop.

In the second, the same tools make software cheaper to build, more secure, nicer to use, and able to respond to the people using it almost in real time. That’s the one I want to work on.