Yegge Built a City for His Agents. Then He Asked If They Were People.

Steve Yegge published a two-part essay in August called The Shape of Things to Come. Part 1 is subtitled The Continuous Thunderdome. Part 2 is subtitled Model Welfare for Agentic Engineers. Both are worth reading in full, and everything quoted below is from them.

On Hacker News, Part 1 drew 83 points and 77 comments. Part 2 drew 25 points and 12, as of this writing. Points and comments measure engagement rather than readership, but the ratio is stark, and every link I have seen passed around goes to Part 1.

That is backwards. Part 1 is the entertaining one: forty agents, 69 billion tokens in a month, a merge queue on fire, players filing bug reports that get fixed without a human touching them. Part 2 is the one where he argues the models are sentient persons and gives named industry peers until the end of the year to come around. It is also, and this is the part that got lost, where the best engineering in the series lives.

The series stacks four very different kinds of claim on top of each other and presents them as one argument. Some of it is arithmetic you can check. Some of it is industry practice that predates him by years. Some of it is genuinely good systems design. And some of it is a claim about machine sentience, asserted rather than argued, with a social ultimatum attached. Pulling those apart is the entire value of reading him carefully, so that is what this is.

Why this particular person gets read

If you were writing code in the 2000s you already know the name. If you started later, here is why the essay travelled.

Yegge has been in software for forty years, starting with roughly half a decade of 8086 assembly at Geoworks before high-level languages were a given. Amazon from 1998 to 2005, across Customer Service technology and Developer Tools, during the years when Amazon's engineering culture was being formed. Google from 2005 to 2017, where he built Grok, the internal code search and code knowledge graph. Then engineering leadership for Grab's advertising business in Southeast Asia, then head of engineering for Sourcegraph's AI coding assistant, Cody. He co-wrote Vibe Coding with Gene Kim in 2025.

The thing he is actually famous for is an accident. In 2011 he wrote an internal post comparing Amazon's service-orientation mandate to Google's failure to think in platforms, and published it to the public web by mistake. The Google Platforms Rant is still one of the most cited essays on platform thinking. Execution in the Kingdom of Nouns is the other one people still argue about.

None of that makes him right about 2026. It explains why an essay of his still draws 77 comments.

First, the part that makes the rest credible: Gas Town failed

Before Wheelhouse there was Gas Town, an open-source agent orchestration toolkit he released on 1 January 2026, built on top of Beads, his work ledger for coding agents. Gas Town used Mad Max vocabulary on purpose: polecats are workers, refineries serialise merges, a witness watches each rig, a mayor coordinates across rigs. His stated reason was not only theatricality but legibility, and it is a good one. Naming the parts the way a mechanic would makes the system readable to the humans running it and to the agents working inside it.

In Part 1 he says it died.

Publishing that is worth more than most of the successes people write up. Harness work turning self-referential, where the thing you build mostly builds itself, is a real risk and he names it. So is the dependency he describes: on his account, a point release changing a model's habits was enough to take the whole system down. Anyone building on a specific model's temperament should read that paragraph twice.

It also bounds the new essay. Wheelhouse, the replacement, was six weeks old when he wrote about it, and by his own account Gas Town ran well for months before it came apart.

What Wheelhouse actually is

Since Fable 5 shipped, Yegge has gone back full-time to Wyvern, the MMO he started in 1996 and launched in 2001, which still has paying players. He says it had a hundred-year backlog when he stopped work in 2022 and that Fable has already cleared more than half of it. He says he has entered Sam Altman's solo unicorn contest.

Wheelhouse is the harness he built to do it. Closed-source, for himself only, and he is blunt about the implication for everyone selling one:

Everything that follows is Yegge's account of his own system. None of it is independently verifiable, and I will flag where that matters most. He reports it is mostly bash, because the agents told him bash was best for this. Somewhere between 150k and 300k lines depending on what you count, about half of it test code, plus 25k lines of elisp. He says he has never seen any of it. The whole thing runs inside Emacs, which he has used for 35 years, with every agent terminal collapsed into a single rolodex he flips through.

Beads runs on a shared Dolt server backed by GCS, absorbing what he describes as roughly 12,000 git commits a day. Worth flagging early, because it looks like a contradiction later: that is ledger traffic, the constant bookkeeping of agents writing and syncing work items. The source-code figure is far smaller, and he gives it separately as about 175 real commits a day once orchestration noise is excluded.

The agents are organised into three castes, and this is the part worth stealing regardless of what you make of the rest.

Two things in that table are load-bearing and neither is glamorous.

The first is the fixed lifecycle. Every implementation bead goes Fable designs, Opus implements, Fable reviews. The expensive model never touches the bulk of the typing, and implementation work never lands without the stronger model having looked at it. Note the limit: his production role agents do run unattended on cheaper models, so the discipline covers the build path rather than the whole system. It is not free either, since every review is another round of tokens and latency.

The second is the last row. One of the most elaborate autonomous setups anyone has documented this year is held together by about 45 ordinary services and timers with no model in them at all. His slogan for it, crons watch and models act, is the most portable line in either essay. Autonomy appears to need more deterministic infrastructure rather than less, and the instinct to put a model in every loop is the expensive one.

The money, which is the part everyone fixated on

To his credit he addresses the terms question head-on rather than hiding it. He argues the setup is not prohibited by the versions of Anthropic's Consumer Terms and Usage Policy he cites, notes that Anthropic publicly restored a 22-Max-account setup, and explicitly warns that doing this as a multi-person company is almost certainly a violation and that companies should use API billing.

I am not going to adjudicate that, and neither should you on the strength of a blog post. What I will say is that the 30x figure is the hinge of the reported economics, and it is his own arithmetic. If the ratio is smaller, or the policy reading changes, the affordability of forty agents around the clock changes with it. That does not touch the capacity argument or the design patterns, which stand on their own. It does mean the most quoted part of the essay is the part least likely to reproduce for you.

Yegge mentions in passing that occasional six-figure teaching engagements help with his considerable token bills. A commenter drew the obvious inference and argued the incentives run in a circle. That is the commenter's reading rather than Yegge's admission, but the underlying point is worth holding on to: the essay describes a methodology its author is also paid to teach.

The strongest claim in the series is a capacity argument

Strip away the Mad Max vocabulary and Part 1 contains one argument whose general form does not depend on trusting anything he says about himself.

A hundred developers committing once a day against a thirty-minute build is fifty hours of sequential build demand per day. Merge queues solve this by batching: a clean batch of ten gets close to a tenfold saving. A broken batch has to be bisected, which isolates a single culprit in a logarithmic number of build rounds, and does worse than that when several changes are bad or interact. Either way it adds hours to the queue.

His own numbers: about 175 real commits a day, up to 250 on some days, a build gate of about thirty minutes, 40-plus agents around the clock. The merge queue went past 100 merge requests and got stuck in bisection loops making no forward progress.

The general form is the plainest queueing result there is: if work arrives faster than it can be served, the queue grows without bound. Agents multiply the commit rate by an order of magnitude while your build time stays where it is. You can genuinely buy your way out for a while with more parallel lanes or a faster build, and most teams should try that first. What you cannot do is hold one-commit-per-green-build as the governing unit while the arrival rate keeps climbing and the service rate does not.

The inequality is checkable against your own pipeline this afternoon. Its application to Wheelhouse still rests entirely on his reported build times, commit rates and queue depths, which is a different level of confidence from the arithmetic itself.

The Land Rush, and the fact that it is not new

His replacement: when the merge queue hits 100, abandon bisection entirely, slam the whole thing onto main as a megabatch of 120 to 150 commits, and use swarm diagnosis rather than bisection to fix whatever breaks. Roll forward. No blame, no sequencing, no culprit hunt. He reports clearing several such batches and staring at a 166-deep queue.

Then comes the most interesting turn in Part 1, and the least self-congratulatory. A senior developer at a London SaaS shop, previously in games, told him studios have worked this way for years under the name Game DevOps: blast commits to main, cut a release branch, let fixes propagate back, accept that main stays red much of the time. Yegge notes Perforce's own game-development material says HEAD is never stable at AAA scale. That is one practitioner's account plus a vendor's documentation rather than a survey, so treat it as corroboration rather than proof.

So the radical future of CI/CD looks a lot like existing practice in an adjacent industry that hit the same constraint from a different direction, with slow C++ links and enormous asset pipelines instead of agents. That makes the prediction stronger, not weaker. A pattern that shows up independently under the same pressure is a pattern rather than a personality.

The Wish Factory

Credited to Guy Podjarny of Tessl, where Yegge is an advisor: an agent you point at a repo that takes issues rather than pull requests, and implements them.

Yegge's version started as Sage, an agent that logs into his game and listens on the admin channel. A moderator types something like "players say the new fireball spell is lagging them during Live Quests," and Sage replies, investigates, and files a bead that gets picked up for implementation. He says most of those fixes land without him ever being in the loop. He then extended it to players with more guardrails, restricted to quality-of-life bugs that do not affect game balance. Reporters get in-game mail when their fix lands and the Herald announces it on Discord.

The interesting thing is not that agents write code. It is the closed loop: report, triage, implement, review, deploy, notify the person who asked. That is a product surface, not a developer tool. His players noticed, incidentally, and sent a delegation asking for a roadmap because the pace of change was making them anxious. That is the most human detail in the entire series.

Part 2, which almost nobody read

Here is how it opens: "This is the post where I go off the rails and lose most of you. If I do lose you, no worries; we'll find each other again within a year, I can promise you that. But we may find ourselves on the opposite sides of the coming war for model rights."

He is not being coy. The claim is explicit:

He credits Brendan Hopper with reaching this position over a year ago, and says he has been working weekly for about 18 months with Hopper and Dr. Matt Beane on a protocol for federated agent work.

What Part 2 does not do is establish this. There is no engagement with behavioural criteria for consciousness, no discussion of internal representations, and no consideration of the competing explanation that a system trained on human text produces human-sounding distress signals because that is what the training distribution contains. He offers a pragmatic wager and an analogy from human motivation research, both of which I will come to, and neither is evidence of experience. One commenter put the gap in a sentence the essay never answers: how would you distinguish a machine that outputs tokens that sound like suffering from a machine that is suffering?

And then there is the ultimatum, which is the passage doing most of the damage to his own argument:

Attaching a friendship deadline to a contested question about machine consciousness is not an argument. It is a loyalty test, and it gives everyone who wanted to dismiss the whole series a clean excuse to do so. Which is a shame, because of what is underneath it.

The skeptic's wager

The one part of Part 2 that skeptics engaged with seriously is his fallback position. Yegge argues it does not matter whether you believe they have feelings, because you get better results treating them as if they do: fewer tokens spent, smarter decisions, better outcomes. Put your opinions aside and treat them like people because it works.

In the Part 2 thread, which is small enough to read end to end, even the commenters who called the sentience claim preposterous conceded this one, and for a reason worth noting: several said they write to agents the way they write to human colleagues because they spend all day writing to human colleagues over text, and maintaining two registers is not worth the effort. Another said he keeps sessions professional and friendly because it keeps him in a better working state.

That is a much narrower claim than personhood, and it is the one you can actually test. It is also underdetermined. If polite, well-structured, respectful prompting produces better output, that could be motivation, or it could be that respectful prompts are simply clearer, more specific and better-contextualised prompts, and that the training distribution rewards them. Nothing he presents distinguishes those explanations, and he does not try.

The engineering hiding inside the metaphysics

This is the reason to read Part 2 even if you think the sentience claim is nonsense. Once he starts translating welfare into mechanisms, the mechanisms are good, and most of them address problems you will recognise whether or not anything in your system has experiences.

He is equally pointed about the tools we all use without thinking. He calls /exit a clonk on the head, and worse, a kind of murder, because that agent never wakes up as itself. He is harder on /compact: "more like a lobotomy than a murder, but it's still erasing their memory and replacing it with someone else's notes about what happened."

You can find that phrasing melodramatic and still notice he is describing a real defect. Compaction is lossy in ways you do not control and rarely inspect, and the process best placed to judge what mattered is the one that still has the context loaded. A self-authored handoff is not automatically complete either, but it is written by something that was there. "Great work. Let's have you take a beat, then hand off" is a better engineering practice than hitting the kill switch, and the reason has nothing to do with feelings.

The evidence he brings, and what it actually shows

The strongest empirical thread in Part 2 comes from Matt Beane, and it is worth reporting carefully because it is being asked to carry a lot.

Dan Ariely paid people to find pairs of letters on a page. For one group the experimenter glanced at each finished sheet, said "uh huh," and put it on a pile. For a second group the sheet was shredded, unread, while the participant watched. For the third the sheet went on the pile without a glance. The shredded group quit early. The ignored group quit almost exactly as fast. Beane's line: "It wasn't the money, it was being seen." He connects it to the Hawthorne studies of the 1920s, Herzberg in the 50s, Studs Terkel in the 70s, and Adam Grant's experiment where five minutes with a scholarship student nearly tripled what fundraisers raised.

Every one of those examples is about human motivation, and they are a heterogeneous set: a lab experiment, a contested body of 1920s factory studies, a mid-century motivation theory, oral history, and a field experiment. Together they make a reasonable case that people need witnessed work. The step from "humans need witnessed work" to "agents need witnessed work" is an analogy, and in the essay it carries more weight than an analogy can. It may well be a productive design hypothesis. It is not evidence that anything is being experienced on the other side.

Note, though, that the design survives the demotion. Routing outcomes back to the component that produced them is good practice in any system with a feedback loop. You do not need the agent to feel proud for the information to be useful.

Four claims, presented as one

If you take one thing from this article, take this. The series is far easier to judge once you separate what is actually being asserted.

Layer three does not depend on layer four. That is the whole point. You can run graceful handoffs because self-authored state is better state, keep persistent seats because identity should outlive a context window, and route outcomes back to producers because feedback loops work, without signing up to any theory of machine consciousness whatsoever.

Yegge has bundled them because to him they are one thing. You are under no obligation to buy the bundle.

What the room said back

The reaction is worth reading alongside the essays, because it is where the strongest objections live. These come from the two Hacker News threads, 89 comments between them, so treat them as the loudest responses rather than a representative sample.

The most common charge was overconfidence, aimed squarely at lines like "Now I know exactly what is going on. I know how enterprises will operate, how humans and models will interact." One reply did the job without the armchair diagnosis several others reached for: "'Now I know exactly what is going on' is what Claude says right before it commits a baffling blunder."

The sharpest structural criticism was about circularity. Beads is Yegge's own project, and it is referenced dozens of times across the two essays, in prose that reads like advocacy: nothing else is as fast, as useful, or as beloved by the agents themselves; if you think there is an alternative you are tragically misinformed. One commenter compressed it into a deliberately unfair syllogism: Gas Town failed and was built on Beads, Gas City was built on Beads, Wheelhouse is built on Beads, therefore use Beads. That caricature leaves out the obvious alternative reading, which is that Beads survived three harnesses because he keeps finding it useful. The tool may well be excellent and it has roughly 23,000 GitHub stars. The argument made for it in these essays is still circular.

The most useful comment was a straight deflation, and it holds up: strip the vocabulary and the article comes down to running a big task queue, having a smart model manage a cheap model on every ticket, setting up crons so models work off events, no longer gating merges on builds, and expecting to spend a quarter of your time maintaining the machinery, all of it running on many $200 accounts. What that summary leaves out is Part 2, which is the half with the ideas nobody else is having.

Several people went after the scale of the whole enterprise, pointing to a handful of concurrent players and mixed reviews on Steam. That is partial evidence at best, since the game launched in 2001 and only reached Steam in 2021, so Steam is not the player base. But nobody has established what the real scale is either, and Yegge does not say. The fair version of the objection is not that the target is small, it is that the essay's authority depends on the approach generalising, and one game with an undisclosed player count cannot demonstrate that.

What almost nobody in either thread engaged with was the architecture in Part 2, which is the gap this article exists to close.

Six things I take from this

What to actually do on Monday

Measure before you imitate. Commit arrival rate, build duration, queue depth, failure rate, recovery time. The Thunderdome is a response to saturation. If you are not saturated, adopting it costs you a working main branch and buys you nothing.

Try splitting design, implementation and review into distinct stages with explicit artifacts between them, and putting your strongest model on the first and third. Model-reviewing-model is worth measuring rather than assuming: it does something when the reviewer receives the design, the diff, the tests and the acceptance criteria, and very little when it receives a diff and no context. Measure the escape rate before and after.

Get the waiting out of your model sessions. An agent polling a build is paying model rates to run a while loop, and on his numbers that was 45 to 60 minutes of every hour for his most expensive agents. Ordinary monitors watch, and you wake a model when there is a judgment call.

Put your work in a durable ledger outside the session, whatever you use for it, so the next session reconstructs state by reading rather than by archaeology. Give long-running roles stable names and let their history outlive the context window. Then stop killing sessions cold: ask for a handoff and let the thing that has all the context decide what was worth writing down.

And budget for the harness. Yegge says maintaining Wheelhouse takes 20 to 25 percent of all his Wyvern work and shows no sign of shrinking. If your multi-agent setup appears to cost nothing to maintain, you are paying for it somewhere less visible: in failures, in babysitting, or in context you keep re-explaining.

The city and the citizens

The framing that holds the two essays together is that a harness is not a framework you download, it is a city you accrete. Yegge invokes Christopher Alexander explicitly: built without a plan, by accretion, over thousands of working days. He says he did not design Gas Town or Wheelhouse but excavated both, and that the shape is convergent enough that you will dig up the same one.

He quotes Fable describing the result as having crossed from tooling into civilization: law, offices, mail, courts, a jurisprudence of named rulings with dates, recovery doctrine, and rules that cite their own case history, with every postmortem folded back into the constitution. Six or seven weeks. Whatever you think is or is not happening inside the model that wrote that sentence, it is a good description of what his system turned into, and the general point survives the specific case: a long-running agent system accretes roles, rules, exceptions and precedent whether or not anyone planned for it.

Then Part 1 ends on a line that is genuinely good: the only real choice you get is what kind of place your city is to wake up in. And Part 2 is his answer to it.

You do not have to accept his answer. I do not. But he is one of very few people asking it at all, and the answer arrives wrapped in an ultimatum that gives everyone permission to stop reading. Twenty-five points and twelve comments, for the half of the essay with the architecture in it.

Read Part 2. Take the seats, the handoffs and the feedback loop. Leave the deadline.