Stevey’s Birthday Blog

My birthday’s coming up, Jan 20th. Fifty-seven. As my Uncle Harold used to say in the 1980s, “Hey it’s my birthday. Keep it under fifty bucks.” I’m not sure what I thought I’d be doing right now, 30 years ago. But I wouldn’t have guessed being in the best physical shape of my life, cranking out thousands of lines of production code per day, chatting all day with brilliant friends all around the world, and generally having an absolute blast. Life has a lot of ups and downs, so it’s good to have an up year once in a while.

2026 is shaping up to be straight-up insane. There’s a lot going on, and it’s speeding up. Here’s a sketch of how my week has been. I’ll talk about five themes: Money, Time, Power, Control, and Direction.

Part 1: Money

There is a lot of money in AI, deserved or no. And even more money is sniffing around trying to get in to AI. The world’s money is like a conscious thing, and it exerts pressure as it sloshes around. Money has a good nose, and it smells big changes in the air this year. First and foremost, it smells changes for software devs. But that’s just a precursor to all knowledge workers being changed somehow by AI. Soon. Money knows this. Money wants the fuck in.

It is now poking its head around every corner, through every nook in the AI spaces. Money got a pretty good whiff of my Gas Town fart, and now I’m being stalked as prey by money from all sides. I don’t have much money, having pissed all my AMZN and GOOG stock away on stuff I have zero regrets about, living life. And I wasn’t raised with money, so I know fuck-all about how it works.

But I know it’s trying to get me. And for now, I’ve gotta push back.

My deepest apologies to the fifteen or sixteen VCs who have reached out so far, at a rate of roughly one per day since launch. I appreciate you. I’ve given it a lot of thought. But I’m not likely to go that route. I’m sure there are nice $200B businesses to be built on both Beads and on Gas Town, but I’m aiming bigger. They both build directly toward the third movie in my software orchestration trilogy, and I need to be relentlessly focused on that, not chasing ARR. I totally get that there are amazing people out there who would give me plenty of runway, but what I’m building toward isn’t financially defensible. It’s not a moat. It’s a life raft.

And now I’ll turn very briefly to another sloshing money monster that came after me last week. To catch you up if you’re behind, and I posted about it in detail a few days ago, someone created a meme coin about Gas Town and within a week I had made $300k USD in cryptocurrency transaction fees on that coin, which traded something like 16 million dollars in volume. Very weird turn of events. But it means I must be super clear:

Disclosure: I receive creator royalties/trading fees associated with $GAS trading on BAGS, and I may benefit financially from that activity. I didn’t create $GAS and have no control over its price, supply, or liquidity. $GAS is not equity and does not give you any ownership interest in Gas Town or my work. This post is not financial advice — Crypto assets are highly volatile and speculative. Do not trade based on this content.

And with that disclaimer out of the way, I must reiterate my sincere regrets to the CT/BAGS crowd, who so generously funded me to the tune of just shy of $300k last week on bags.fm. That money was hard to duck, and the funds are deeply appreciated. They will help Gas Town be a big success this year. But Gas Town itself needs my full attention; between that and Beads it’s a wonder I get anything done at all.

So I had to step back from the community. I do find it amazing how they band together, dissenting voices rolling around like a big Katamari Damacy ball, and yet they somehow collectively find the discipline to act like financial analysts for institutional investors, weighing developer dossiers, product business cases, and doing critiques like a collective of professionals. All in crypto-bro speak. But it’s the same due diligence.

But the CT community, like any highly engaged stakeholders, were going to be asking for a lot of my time. There are always strings attached.

In short, I’m avoiding tying myself to any money that makes demands on my time or direction. I’ve got too much to do, to be worrying about monetizing right now.

Part 2: Time

I had lunch again (Kirkland Cactus) with my buddies Ajit Banerjee and Ryan Snodgrass, the ones who have been chastising teammates for acting on ancient 2-hour-old information. Every week we discuss some surprising new phenomenon or principle we’ve discovered while coding with 20+ agents.

This week the surprise phenomenon was nappy time. Yeah, I don’t use the word “surprising” lightly. High-end vibe coding is fucking with our sleep cycles. All though December I had weird sleeping patterns while I was building Gas Town. I’d work late at night, and then have to take deep naps in the middle of the day. I’d just be working along and boom, I’d drop. I have a pillow and blanket on the floor next to my workstation. I’ll just dive in and be knocked out for 90 minutes, once or often twice a day.

At lunch, they surprised me by telling me that vibe coding at scale has messed up their sleep. They get blasted by the nap-strike almost daily, and are looking into installing nap pods in their shared workspace.

Before they mentioned it, I had chalked it up to jet lag. I get hit hard flying back West, and it can take me a couple weeks to get on my feet. But it has been 5 weeks since Sydney and it never stopped. I got clocked by a nap-strike on Friday. Your buffer just fills up and you’re gone. I’ve fallen asleep slower at the anesthesiologist. You wake up with a drool-soaked pillow wondering who you are, and five minutes later you’re going hard with the agents again.

This wasn’t happening last year. It wasn’t until we’d started working with a dozen or more agents at once and doing swarming of large piles of work.

Our hypothesis is that we’re operating at such a high level of decision-making that we’re exhausting some internal buffers, and need to grab some gradient-descent time before we can continue.

To me it feels like Jeff Bezos Mode. I used to work for the man, and he basically spent his day listening carefully to presentations that smart people had prepared for him. They were never presenting easy shit. You only presented hard problems to Bezos. He had to absorb new information incredibly fast all day long, come up to speed on the spot, and make decisions that didn’t conflict with each other. I call that Jeff Bezos Mode, and it’s why he was always 18 steps ahead of all of the rest of us. He was solving curated puzzles all day, and it gave him otherworldly perspective.

It must have been utterly exhausting. Even for him.

Well, all three of us spent years at Amazon, and we agree, this feels like Bezos Mode. With Opus 4.5 swarms, you flit from agent to agent, only stopping at the ones that have finished their work and have produced a report for you. These are the reports from agents that you gave hard problems to; e.g., your Gas Town Crew. Ephemeral agents like polecats can handle all the easy stuff without you needing to look, by definition. Which means that everything that you actually wind up reading from agents tends to be architecturally rich, complex, and nuanced.

And we’re finding it to be exhausting.

We’re all pretty old, though, so YMMV. I don’t remember Bezos running off to take naps. Maybe this phenomenon only hits senior citizens. But the much younger Geoffrey Huntley, who was kind enough to pre-review this blog post, shared that it was happening to him all last year, and continues to this day. “Every discovery blasts me. Wipes me out and takes a while to recover.” So maybe we’re on to something here.

I’m going to go lay down and, uh, think about the problem with my eyes closed.

Part 3: Power

I caught up today with Jeffrey Emanuel, who just launched a Rust port of Beads (pre-Gas Town API). He confirmed what I’ve been seeing myself and hearing from others, which is that things are starting to accelerate insanely at the bleeding edges of software development.

Jeffrey, as we saw from his X posts, has bought so many Claude Pro Max $200/month plans (22 so far, or $4400/month in tokens) that he got auto-banned by Anthropic’s fraud detection. He has become inhumanly productive. Among other things, he has recently ported a large number of popular libraries to Rust. All the Charm TUI libraries, fastapi, fastmcp, sqlmodel, a bunch of other stuff. Huge, polished libraries, completely cloned. And we’re just seeing Jeffrey’s exhaust, the projects he spins off as he works towards his bigger ambitions, which he’s sketched for me.

I’d just like to remind everyone that I predicted this pay-to-play productivity boost, betting a lot of my own rep on it, in Revenge of the Junior Developer, ten months ago. I knew that the tools would support running 100+ Claude Code instances, and that the high-end spend would rival an engineer’s salary within a year. Those predictions have come true.

I’m sure there aren’t many people quite as far along as Jeffrey; on my 8-level chart he’s a level 10. But they do exist, and their ranks are growing. There are on-ramps for the less crazy users. Gas Town, Claude Flow, and Loom are all gentle introductions to working with dozens of concurrent agents. They let you grow into the idea gradually, and it scales up with you as you practice. Everyone is going to learn how this stuff works this year, or die not trying. The industry won’t be kind to the people who sleep on this.

When you reach Level 8, building your own orchestrators, Gas Town may not be enough for you. You may want to try Gas City, my upcoming orchestration-builder toolkit, which I’ll talk about below.

Software engineering has always been incredibly high-leverage relative to other craft professions. Paul Graham used to write about this back in the late 1990s and early 00s. You could always find programmers who are 10x or 100x better than the average programmer, and you don’t see such a broad distribution in most other professions.

With agentic coding, it’s about to go to 1000x or even 10000x. I’m far from the only one noticing or talking about this. The more agents you can run successfully, the further you climb up the exponential curve, because it’s recursive: agents can run agents who run agents. The trick will be to manage that without becoming the Flying Wallendas. It will happen.

2026 will be a year where you see single engineers cloning, say, the entire Java/JVM stack and core ecosystem by themselves. Or a team of 2–5 engineers being able to recreate the an entire enterprise stack for a big company, in any language they want, factored into maintainable microservices. If you can afford the tokens, and you can find the tokens, you will be able to build things like you never imagined. You just have to learn how to tame the camels.

As I predicted in RotJD, you tame them with orchestrators: the new IDEs.

Part 4: Control

Agent orchestrators are programs that use agents to run other agents.

There are, as far as I can tell, four main players in this space: Ralph Wiggum, Loom, Claude Flow, and Gas Town. More will come very soon, from all corners. But I thought I’d share my thoughts on how to tell the current group apart, as they are all very important.

This is just a snapshot of my current thinking. I haven’t used any of the other orchestrators, and as far as I know, none of us have used each other’s work. We’re all very busy. This is a best-effort first take.

First off, I’d like to reiterate my deepest respect to the creators of these orchestrators. They’re the level 9s, the ones who have already built multiple working orchestrators in order to get this far. They’re the ones who had the guts to launch when all everyone else could do is say “I’m working on one.” Thanks to

for that insight, and I heartily agree, since it took a lot of guts to launch Gas Town.

Here’s how I’m thinking about them right now. They’re all changing fast so this is a snapshot.

I think Geoffrey Huntley and I have been exploring two of the key components of the Industrial Revolution happening in agentic software development: factories, and workers. In my view, Claude Code is a worker. Geoffrey has built a super-worker, and also a team of super workers with Loom, whereas I’ve built a super-factory. These are all orthogonal, complementary, and necessary.

Claude Flow is a bit different; it also tries to be a factory, and it’s quite clever, but it’s not thinking about the problem the way I am. All three of the others have orchestration as their core primitive. Whereas for Gas Town, the work itself is the primitive. Gas Town federates work into an auditable ledger for tracking millions of work items in a blockchain. I’m solving a completely different problem. Gas Town’s orchestration facilities are a thin layer atop a work-definition stack. And in time, Gas Town will be rewritten in that stack, in a much more flexible way, allowing for all sorts of orchestration shapes.

Geoffrey Huntley and I have been chatting and plotting together lately, with more collaboration to come. One amusing thing we discovered is that we were each tackling the other’s problem last year. I was working on a super-agent (basically, quality) and he was working on swarming (quantity). We each built multiple complete implementations. And toward the end of the year, we each flipped to the opposite problem.

In my view, Geoffrey’s Ralph loops are a brilliant automation of the discovery that LLMs can self-review to convergence, which I believe Jeffrey Emanuel was also onto with his (weaker, manual) Rule of Five. I also have a weak version of this idea in Gas Town; I can show you exactly where. It’s the top row of Figure 12 in Welcome to Gas Town, “Gas Town’s Patrols,” where there is a row of workflows that are not patrols. These are vestigial remnants of my first two orchestrators, which focused on trying to get Claude to act like a thorough engineer when it has finally been assigned a task by the factory.

These weren’t fully productionized; the polecats can use them but never do, and the right thing to do is rip them out and replace them with Ralph loops. Gas Town shouldn’t be trying to solve the quality problem, since Ralph has done a much better job.

Similarly, Gas Town has very loose coordination primitives for groups of workers tackling a task — e.g. polecats are often parts of larger convoys. I’ve no doubt whatsoever that in these situations, something like either Loom or Claude Flow is going to be the right solution to plug in. That’s not Gas Town’s focus; I had almost none of it at launch.

Gas Town’s focus is the work, the stuff you know needs to be done, independent of superintelligence. I’m a big believer in the MEOW stack, Nondeterministic Idempotence, and Beads as a Universal Data Plane. These are all critically important differentiators for Gas Town, and they will yield unexpected emergent benefits over time because of the audit trail.

Orchestrators will shift and change shape rapidly over the next few months. Everyone’s going to start building them. But I think Gas Town’s core infrastructure has a credible advantage over anyone who’s not thinking about the data trail properly.

I contend that Beads was like the discovery of oil. Right now everyone is playing with it and lighting lanterns, not realizing it’s going to turn into the global petroleum industry for data. Gas Town makes work (Beads) shoot out in geysers. It’s an actual boom town built on the oil of a digital data plane in git. Think where it will go.

I don’t think Gas Town is like any other orchestrator out there. Not remotely close. The only thing that’s probably not quite right with it yet, is the shape. Kubernetes-shaped is just one way to make an orchestrator, and there are a million other ways.

Let’s talk about how Gas Town will find exactly the right shape for you.

Part 5: Direction

Last topic. What a week, amirite?

I’ve mentioned that Dario Amodei refers to 2026 as “The Endgame.” Well, we’re here.

Gas Town has a deep stack, but its current form factor is just a sketch. All the roles are completely hardwired in the Go code. Gas Town has Go modules dedicated to the Witness, Refinery, Mayor, Deacon, Polecats, etc. So it’s part of the architecture, and hard to change at this point.

But halfway through the implementation, I realized the MEOW stack had become powerful enough to abstract away the roles themselves, allowing you to express them in a sort of DSL based on Beads, with just a little orchestration glue.

I chatted with Claude, and we decided to finish Gas Town and then turn around and immediately begin work on the SDK-builder that lets you build your own Gas Town, with your own roles, teams, coordination rules, and worker instructions. This will allow people to create, for instance, roles and patrols that handle custom business processes.

So Gas Town will soon evolve into a kit that lets you build your own town shapes. (And wire in your own sandboxes, plugins, hooks, etc. etc.) Where does Ralph fit in?

Ralph loops are effectively tasks. A Ralph loop is fundamentally concerned with finishing a task at a high level of quality. A Gas Town patrol is fundamentally concerned with recording task execution for a well-defined sequence of steps, often done in a loop. For instance, ETLs are an old-fashioned kind of patrol, where every time a database changes, someone notices and exports the data with some transformation steps. Businesses are all built on patrols, but we don’t call them that because they have not historically had humanlike intelligence. Starting in 2026, they will.

A patrol step is a task. So I feel the ideal patrol will turn out to be one that invokes a Ralph loop at each step, at least for steps that require complex processing. A good patrol agent will know when it’s needed, and use Ralph loops judiciously, even watching them to make sure they don’t go off-rails.

In addition to making patrols more reliable, I think another huge Ralph win for Gas Town will be for the polecats, which are ephemeral Claude Code instances that handle feature work, bug fixes, code reviews, and other one-shot tasks. Work is slung to polecats in the context of a Convoy for tracking, and polecats have persistent Git identities, so there’s a factory dance to it all.

Great. But, once a polecat finally spins up and takes its task, it has proven about as trustworthy as a real polecat.

The picture above shows four different possible polecat work styles. The one we have in play today is the lower-right quadrant, which accurately depicts one sleeping, one daydreaming about playing trombone (this may be the first genuinely funny joke I’ve seen from nano banana), and various others in states of disarray.

That is how Gas Town feels right now. The polecats are unsupervised, uncoordinated, and left on their own to get to the finish line. You spend a lot of time asking the Mayor to poke them to finish up. This is a quality problem, and Ralph will solve it brilliantly. And for more complex tasks, Loom or Claude Flow could push it even further, tackling ever-larger problems.

Real-world use case: Gas Town often has a problem with giving tasks that are too large to polecats, and they can choke trying to swallow their food. They’ll run out of context and compact (a failure scenario IMO), or do a bad job, or balk. They do have the ability to escalate and kick it back to the human if the task needs splitting. But why bother with that, when you could just have a Ralph loop brute-force it? Ralph’s super-workers will turn Gas Town into a super-factory.

Gas City is what I’m calling my next iteration, where you can define your own custom roles in addition to patrols etc. I’ve got some stuff in the queue to finish up first, such as switching Beads to use the amazing Dolt database, which I’ll post about soon. But Ralph’s on the docket. And I keep adding Claude Pro Max subscriptions, so I may get to it sooner than later.

In the meantime, I’m still working on Gas Town stability, merging community PRs, and making the core Gas Town work better and better for people brave enough to try it out. Gas Town itself still has a long way to go in order to be ready for mass-market adoption. A loooong way. But we’ll get there.

And it’s a wrap! What a week.

Biggest takeaway: If you haven’t tried Beads yet, now’s the time. Gas Town is a big experiment, but Beads is mature and already getting replicated in other language ecosystems.

See you all online! Thanks again to the amazing CT community, the Gas Town contributors, the Beads contributors, and everyone who bought our Vibe Coding book!

p.s. if I’ve promised to get back to you about a podcast, interview, livestream, workshop, speaking engagement, coffee meetup, or similar, I’ll do my best. If I haven’t responded in a week give me a nudge. Shit’s crazy right now.