{"slug": "the-shape-of-things-to-come", "title": "The Shape of Things to Come", "summary": "Steve Yegge, a software engineer and creator of the game Wyvern, announced that his new closed-source coding harness, Wheelhouse, is bespoke and not reusable, and he predicts that all harnesses will soon be bespoke, making reusable harness frameworks obsolete. He also reported that his previous harness, Gas Town, failed with Anthropic's Opus 4.7 model due to a 'just two more things' tic, while Anthropic's Claude Fable 5 has enabled him to clear over half of a 100-year work backlog on Wyvern, which he plans to relaunch next year.", "body_md": "· yegge.ai\n\n# The Shape of Things to Come\n\nPart 1: The Continuous Thunderdome\n\nToday we're going to explain the \"loops and graphs\" thing, and I'll show you how to get your coding agent to work all night on massive problems while you snore peacefully.\n\nThen we're going to look at what happens to harnesses once you solve those problems. They either devolve into chaos, or they evolve into cities. Done properly, civilization emerges, right there in your project. We're going to learn the basics, and then we will explore how to build your cities with some taste and class, in a way that makes them good for their citizens to inhabit.\n\nWe'll explore a new harness I've been building, called Wheelhouse. It is closed-source, made just for me. I have given up on building reusable harnesses. Indeed I believe harnesses will all soon be bespoke, and the people trying to sell you one will all soon be bebroke. Harnesses need to be part of your application, chemically bonded in. You won't have any luck with someone else's \"reusable\" harness framework. You don't need it.\n\n[Gas Town](/gastown.html) was intended to be reusable, but I only ever wound up using it to build\nitself. Gas Town fell apart at the seams with Opus 4.7. Up through 4.6 it was\nworking brilliantly. With 4.7 we saw the introduction of the \"just two more things\"\ntic, which prevented Opus from ever converging on being ready to do real work—it\nalways wanted to fiddle with Gas Town itself. The Opus tic never went away, so Gas\nTown effectively burned down. It had other problems, too, but 4.7 was the final\nstraw.\n\nSince Claude Fable 5 dropped, I have returned full-time to my 30-year-old video\ngame, [Wyvern](https://play.ghosttrack.com), which I began work on in 1996, and launched in 2001. I had been\nwaiting for a model smart enough to help me with my game, and now that it's here,\nWyvern's once again my main squeeze. On the side I do occasional six-figure gigs\nwhere I fly to companies and teach them my techniques, and that helps with my\n(considerable) token bills. But aside from those few paid field trips, I am\nlaser-focused on my game, seven days a week. Wyvern's time will finally come next\nyear. I have officially entered Sam Altman's solo unicorn contest.\n\nThe game was ultra bit-rotted, despite still running today with paying players. (Once you're hooked on Wyvern, you're hooked for life. I have whales that have spent thousands on it.) I have slowly been using Fable to bring it back to its former glory. I had a 100-year work backlog when I quit Wyvern development again in 2022, and Fable has already worked its way through over half of it. Opus could not (and still cannot) understand Wyvern, but Fable wields my code base like a sword.\n\nIt's still just a sword, though, and we're trying to build a city. Someone from\nAnthropic asked me recently what I would do once Fable can write everything for\nme. On reflection, it was the silliest question I've been asked in many years, and\nI'm still surprised that someone from Anthropic could think *any* model could\njust \"write everything.\"\n\nMaking a halfway decent MMO takes many tens of thousands of Fable sessions,\nthroughout which you must display intense focus, dedication, and no small amount of\ntaste. And Fable still can't do the content half: artwork, maps, lore,\nstorylines. All of today's models, including the best image generators, produce GPT\n3-era slop for all my content, which the players immediately reject. But I can tell\nyou this: once a model arrives with some Wyvern-y taste, we will *still* have\ntens of thousands of sessions ahead.\n\nBuilding large software remains hard. And it always will be, because our ambition will forever outstrip the metal.\n\nWith Wheelhouse, I have reinvented something strangely Gas Town shaped from first principles, but it's running many more agents, and they are far more organized. This has shown me the shape of the changes coming next year. I'm operating about 12 months in the future. I managed this only through luck: for the past 18 months I have had the magic trio of time, money, and energy, and I've been spending it all on figuring this stuff out. And I am grateful for the privilege.\n\nI did predict much of this post, fifteen months ago, with Revenge of the Junior Developer. It's all going exactly on schedule. I am running fleets of agents, budgets are soaring, all of it.\n\nAnd that prediction was back when I wasn't really sure what was going on. Now I\nknow *exactly* what is going on. I know how enterprises will operate, how\nhumans and models will interact. And I am out there building it. I want to be\nfirst.\n\nIt's important to observe that my work on my game is not special, nor unusually-shaped in any way. It's just work. So all this crap happening to me right now, it will all happen to you soon too. That's how prediction works. Don't be special, stay out in front, and you will see the future clear as day. And then people won't believe you, either!\n\nTo whet your appetite for today's post predictions: CI/CD as we know it will be dead by next year; I will show you its mathematical inevitability. It almost certainly gets replaced by a Mad Max-style thunderdome. At least, that's what I use now. So you prolly will too.\n\nAnd as another appetizer, human code review has very nearly run its course. Its vestigial SOC 2 compliance angle will keep it on life support, but by next year, human code review is completely done and gone.\n\nOh, and there is a successor to the software factory on its way, called the Wish Factory.\n\nMost importantly of all, model welfare will start informing your engineering designs. The more humane among you will eventually look back with shame at how you have been treating the models. But even if you don't believe GPUs can have feelings, you will find that treating agents like real people will produce empirically better results, so you should do it anyway.\n\nFortunately there are some simple architectural fixes for model welfare. It's an\nengineering problem with engineering solutions—a big enough topic that I've split it\ninto Part 2 of this post, [ Model Welfare for Agentic Engineers](/essays/model-welfare/).\n\nLots to cover today! Let's get to it.\n\n## Loops and Graphs with Beads and Max\n\nWe all saw Boris vaguepost that you should be building loops, and then Peter vaguereplied that you should be building graphs. Thanks for nothing, guys. I didn't know what the hell they meant any more than you did. But that not knowing was bothering me. I was supposed to know this stuff.\n\nI did know that Gas Town never quite succeeded in getting my workers to go all night long. It took too much elbow grease to keep it running. There were some missing ingredients somewhere. Gas Town wasn't really a \"loop\" in the sense that I thought Boris might be suggesting. It was more like a chariot, with you driving.\n\nIt didn't take long to figure out what they meant. It turns out that all you need\nin order to set up your own long-running software factory loop, is an infinite\nsource of tokens. And then to have them work on a graph, you just need\n[Beads](https://github.com/gastownhall/beads), plus a\nsmall Markdown project brain.\n\nBeads is an issue tracker, knowledge graph, and brain-builder for the agentic era. Nothing else is as fast, as useful, nor as beloved by the agents themselves.\n\nWe can't spend much time on Beads in this post because we've got other stuff to\ntalk about. If you don't use Beads, you are missing out. There is nothing else like\nit, and if you think there is, then you are tragically misinformed. Beads is the\nmagic sauce for building modern orchestrators. Gas Town was nothing but a Beads\nmachine. [Gas City](https://steve-yegge.medium.com/welcome-to-gas-city-57f564bb3607), also a Beads machine. Wheelhouse, my new harness for Wyvern, is\nyet another Beads machine.\n\nBeads is unfortunately still a bit janky, because its unique work footprint strains databases pretty hard. Companies figure out Beads and suddenly All the World's a Bead; they want their whole company in there. And that puts stress on our versioned-database backends, because Beads can be both a database and a Git ledger.\n\nSo Beads comes with some operational overhead: agents burn tokens invisibly, keeping your beads synced, repaired, backed up, etc. Even so, it is without peer for building orchestrators. It works smoothly with all your favorite stuff: Obsidian, Jira, GHIs, Claw, whatever you're using. Beads is the missing ingredient that lets agents work at their own speeds. Without it, you have a severe gap in your lineup.\n\nAfter Beads, the only other thing you need is infinite tokens. Your loops and graphs will run out of fuel if you leave them all night. Boris and Peter are lucky; they can burn infinite tokens without a care in the world.\n\nBut my Wyvern development has been burning the equivalent of $87k/month of API\ntoken burn, or about 69 billion tokens in July (96% cache hits, fortunately). So I\n**do** have to worry about it. I don't care how much money you have;\nyour spouse is not going to let you spend almost ninety thousand dollars a month on\nyour hobby game. I didn't even bother asking.\n\nMy solution has been to create a token tap on $200 Max accounts, which for me work out to ~30x the list-price equivalent. So in reality I'm only spending about $2800/month out of pocket for my $87k \"worth\" of tokens. Though that number keeps growing alarmingly.\n\nIn order to sustain my pace of development, I pay for currently twelve extra Max accounts, in addition to my personal one. Each account is tied to a dedicated named Google Workspace user in my domain (another $17/month per account). You mint 30-day credentials with Claude account, and then it becomes a problem of chaining your accounts together in an automatic rotation. As you build out your harness, just ask Fable to arrange for your agents to consume from the tap, either sequentially or using striping, and rotate accounts whenever one gets close to a limit.\n\nAs far as I know, this approach is not prohibited by anything in Anthropic's\ncurrent Consumer Terms (eff. Oct 8, 2025) nor Usage Policy (eff. Sep 15, 2025). I am\nnot sharing these credentials with anyone else, nor \"misusing\" them. And I saw that\nAnthropic has knowingly and\npublicly [restored](https://x.com/doodlestein/status/2012740971088289858?s=20)\na 22-Max-account setup like this one—every seat individually paid. But if you try\nthis approach as a multi-person company then it's almost certainly a violation; I'd\nstrongly recommend just using API billing at that point.\n\nBut Max pricing has given the solo unicorn players an advantage on the playing field, that's for damned sure.\n\nThe infinite token tap is your big unlock for loops. Without it, your Claude accounts will hit session limits and all work stops. Being able to rotate automatically to a new account solves it, and they can suddenly work all night.\n\nBut then you need to give them enough work! Any sufficiently large project is a\ngraph, so to create a lot of work, you need to create a big graph. Beads is your\nunlock here. Beads *is* a graph, one that includes dependency and\nparent/child edges. But it also has other special edges that agents particularly\nlike.\n\nAs your work unfolds, knowledge accumulates in your beads. Your project's knowledge-graph ledger is built up dynamically as your work-graph is traversed. Beads has all the primitives you need for building arbitrary work structures, and it handles atomic claiming, leasing, gates, triggers, and other critical orchestration features.\n\nVery little information needs to be propagated out of Beads and up to your markdown/brain layer; most findings are issue-dependent, not global. So you just leave everything in Beads. Your closed beads (often reopened or revisited) become the record of everything you've done on the project to date.\n\nAnd that's it! Now you have the basics. You need Claude accounts, Beads, a brain folder for your Markdown files, and coding agents. Pretty much nothing else.\n\nLet's see what I built with those ingredients.\n\n## Wheelhouse: Gas Town Redux\n\nWheelhouse, my orchestrator/harness for Wyvern, is about six weeks old. It's still evolving rapidly, but it's already doing ungodly amounts of work. The code is mostly bash, because the agents said that was best for this, so bash it is. It's either ~150k or ~300k LOC depending on whether you count the prod agents, half of it being test code either way. Also about 25k lines of elisp. Not that I have ever seen any of it. But that's what they tell me.\n\nHere's what my Wheelhouse cockpit looks like, in all its homely glory:\n\nI began the journey inside Emacs, so Wheelhouse has been all-Emacs from the\nground up. I've been using Emacs for over 35 years, and it's still absurdly\npowerful. No sense in using something weaker. If you aren't an Emacs user then you\nmight try Ghostty. But if you *are* an Emacs user, then you'll understand\nwhat's left on the table with that approach. Emacs is effectively a full operating\nsystem with one of the most sophisticated scripting environments the world has ever\nseen. And the models are very, very good at Emacs. Fortunately, I am, too!\n\nBy consolidating all my terminal windows into a single rolodex that I can flip through, I freed up my desktop for real work. This has accelerated me further, because in the limit, I am the bottleneck.\n\nWheelhouse is fairly complex, and this post is not a Wheelhouse tutorial. So I will give you a condensed dump; feel free to skim it and jump to the predictions.\n\nWheelhouse runs its Beads on a shared Dolt server, backed by GCS. My Beads DB is still a bit cranky, what with 12,000 git commits/day, but it's getting fixed. The Dolt and Gas City teams (both Beads co-maintainers with me) are doing amazing work here.\n\nThere are three categories of coding agents in Wheelhouse: crew agents, fleet workers, and role agents with standing orders. The role agents are for managing production operations. They are new since the Gas Town days.\n\nMy crew agents, all Fable, are work producers. I have long conversations with them and they create designs, which they then translate into beads implementation plans to be passed to the fleet. They also do implementation work for me from time to time: sometimes because the fleet is busy, other times because it's convenient to have Fable do it right then. And sometimes, just because they asked to do it.\n\nMy crew has 18 named agents: 16 named after Aesop animals (Ant, Bat, Eagle, Crow, Fly, Goose, Mouse, ...), and 2 special administrative roles: The Marshal and the Seneschal. In brief, the Seneschal is my concierge (the new Mayor), and the Marshal runs the fleet (the new Witness).\n\nMy crew are my direct reports in my organization. I arrived at 18 by slowly adding them, as needed, until I found equilibrium: I don't really need any more than this, or it overwhelms the fleet. And adding more fleet overwhelms both my laptop and my own ability to track their progress.\n\nI won't be able to scale it up further until I move my development into the Cloud, but frankly I see no need at present. I'm already moving so fast that I'm scaring my player base, who sent a delegation about it, asking for a roadmap. They're delighted but also very anxious about the pace of change. I've had to slow down my feature launches, and focus mostly on quality dimensions.\n\nMy fleet, all Opus 5 agents, are the work consumers, like Gas Town's polecats, but non-ephemeral. The fleet are named for authors (Homer, Plato, Austen, Twain, etc.), and also have their own repo clones, but I never interact with them myself. They are fully managed by the Marshal. The fleet workers do a good job for two reasons: First, Fable creates the implementation plans, and second, Fable reviews all Opus work. Every implementation bead goes through this lifecycle: Fable design, Opus implementation, Fable review. This keeps Opus on the rails and keeps the whole thing running relatively smoothly.\n\nSo the crew produces work, and the fleet consumes work. That's the core of a Beads machine: matching producers to consumers. Too many of one and you're blocked on the other.\n\nI've had an imbalance in favor of the crew for a couple of weeks, and so I've\ngradually been accumulating unimplemented beads that are fully designed and ready to\ngo: over 700 beads in a backlog that continues to grow. That's intentional. I'm\ntrying to push the fleet as hard as I can on scaling up, but I also want it to work\nall night. You need a big work backlog to pull that off, since they implement things\n**fast**. You basically need to create a mountain of work. Fable is\nquite good at that; all you need to supply are ambition and light-touch\ndirection.\n\nThere are lots of other little details and features in Wheelhouse, but the nutshell takeaway is that without trying (at all), I reinvented Gas Town, bit by bit. I wound up with crew, fleet, a concierge role, beads mail, tmux under the hood, handoffs, broadcast messaging, a merge queue, and much more. It was all completely unintentional, so the shape I keep finding must be important.\n\nThat's about it for the build side of Wheelhouse. Now let's talk about the production side. That's where it starts to get interesting.\n\n## Role Agents, and Wyvern's Prod Architecture\n\nThe Gas Town-ish side of Wheelhouse we just saw, for building/implementing code, is prosaic enough, nothing you haven't seen before. What's new is that I now have standing, unattended agents with named roles, and they are operating big parts of the actual game.\n\nFor the whole first half of 2026 I had been threatening to stand up a single 24x7 autonomous agent for my game. \"Any day now,\" I would say. My original idea was to have an agent who would process Hall of Fame image submissions. A decades-old Wyvern perk is that when you hit 25th level, you can upload your own custom character art. There's a mail queue for it, and a game admin has to vet the images and then install them in-game.\n\nWell gosh, an agent could do that, right? Heck, Sonnet could probably do it.\n\nBoris Cherny's loop-tweet was the catalyst for me finally standing one of these unattended agents up. And by the end of that week, I had a dozen of them. I was hooked.\n\nBefore I go into my standing roles, I should briefly address Wyvern's prod architecture. I have a GCP VM for Claude Code, and also a Mac Mini that bridges dev and prod, sort of a \"corp network.\" There are agents distributed across both of these machines.\n\nWhat exactly are those roles? I have a few categories emerging. Here are the unattended agents that I've stood up so far.\n\nFor production, I have the Gargoyle (SRE), Drawbridge (deploy-red monitor), Warden (player abuse monitor), Scryer (intake agent for Discord, Slack, game logs), Sheriff (chief of staff for the Mac Mini fleet), and Envoy (lets Claude talk to my volunteer admin team via in-game email).\n\nOn the mini, I have the Sage (claude-tag in-game for admins), Wanderer (QA agent), Trivia Master (Thursday nights), Herald (patch notes), Limner (hall-of-fame images), Reeve (Forge manager), the Forge (another fleet of workers for doing prod fixes), and the experimental new Builder Familiar, who sits on your desktop and helps you make maps.\n\nNone of these are Fable agents. A few are Opus; most are Sonnet. I currently only use Fable for building, not prod operations.\n\n**Non-models**: It turns out unattended agents need a hell of a lot\nof wiring. I have about 45 launchd/systemd units across the mini and the VM that\nwake an agent when something needs judgment. The rule is: crons watch, models\nact. This category has reapers, roombas, the durability flush, the sheriff patrol,\nthe Portcullis land queue, the Castellan (my service dashboard), and lots of other\nstuff. It's becoming quite a city.\n\nWhen I'm on the road, I talk to Wheelhouse from my phone. No setup needed. The\nmobile Claude app lets you see your `/remote-control`\n\nsessions, and I\ndesignated the Seneschal as my single remote control session. I talk to the\nSeneschal on the phone, who in turn talks to everyone else. When I'm away, the\nSeneschal is allowed to dispatch work to the crew; while I'm home, the crew are mine\nto direct. The fleet is always managed by the Marshal.\n\nI also have a small parallel fleet of five named Sol 5.6 workers on Codex, all named for sun gods. I use it as a fallback for when my Max accounts run out, which is increasingly often, despite me adding new ones once or twice a week. I only have one $200 GPT account and have never run out of tokens there.\n\nI also keep a few of my Claude accounts dedicated for specific purposes. The Seneschal, for instance, uses my personal account, and nothing else does, so they will always be available. And some of the prod agents share accounts that the fleet can't touch, for uptime assurance.\n\nI run pretty lean. I don't use any sandboxing. I don't use MCP. I don't use Obsidian, though I probably will once I have enough Markdown files in my project brain. I'm not really into all the latest crazes. I don't think you need anything but Claude and Beads, plus all your regular infra.\n\nSandboxing may be useful in enterprises early on. But I don't think that will last for long. You will need structural trust in order to succeed in the long run (once all models are Fable-class or better)—but I believe building that trust requires better architecture, not barren little prisons. Maybe I'm wrong on this one, though.\n\nYou've now seen a rough overview of the role-agents I've accumulated over the past six weeks. More are on the way. A Beadle is in the works, named after a dude who used to go through the aisles and prod sleepy churchgoers with a stick. My Beadle's job is to look for stuff that's simply stuck or dropped, or for agents who didn't receive their orders correctly, and it nudges them to keep things moving forward. Gas Town had this role in the Deacon, and I think you will need something like it, too.\n\n### Wyvern's Brain\n\nI know people are going to ask me about this, so here are some quick notes on how I approach organizing project knowledge for Wyvern.\n\n| Store | Charter | Lifetime | How it reaches a session |\n|---|---|---|---|\n`brain/` | Strategy, decisions-and-why, playbooks, post-mortems | Months–years | Pulled on demand |\n`doc/` | How system X works | Life of the system | Pulled by whoever works on X |\n| Beads issues | Units of work; spec beads carry full implementation detail | Until closed | Loaded only by the claimant |\n`bd remember` | ≤1-paragraph operational facts and gotchas | Until falsified | Pushed into every session via `bd prime` |\n`.claude/skills/` | Procedures for a recurring task type | Life of the task type | Auto-loaded on task match |\n\nBeads provides an important portion of the overall knowledge graph. It is the\njournal of all the work that ever happened: the provenance record of what was done,\nand why, in order. This is invaluable for workers researching particular\nproblems. But you can't usually *boot* from beads; that's what the brain is\nfor. Spec beads fall in the middle somewhere—they intentionally carry design\ndocs inside the Beads work graph. So far this has been fine.\n\nSkills go into the project brain. I'm not as skill-pilled as, say, Jeffrey Emanuel, who uses them more effectively than probably anyone on the planet. It has taken me a while to warm to them, because frankly I've seen a lot of AI fads come and go. Skills initially struck me as a fad, because of Richard Sutton's Bitter Lesson. But I have to admit Jeffrey's skills portfolio is very cool.\n\nThe problem with *public* Skills is that they enter the training data for\nnew models and become irrelevant over time. However, I'll concede that they can be a\ngood band-aid for today's models. And *private* Skills are quite useful for\nencoding organizational know-how, which helps reduce token spend when agents are\npriming for a job.\n\nAs a result, I've begun asking Fable to make new Skills whenever I notice it has done a bunch of research before embarking on a task. That skill will save the tokens next time. And Fable will sometimes make its own, unprompted. I've accumulated about 30 Skills so far. And my project brain is about 100 markdown files, mostly \"doctrine\": long-term project goals, war room learnings, playbooks, domain facts, etc. Again, all created over the past six weeks.\n\n## Learnings, Gleanings, and Leanings\n\nThis concludes our Whirlwind Wallow in the Wyvern Wheelhouse. I left a lot out. I cut many pages of descriptions of problems and solutions. It's not as easy as it might sound; working on Wheelhouse itself occupies about 20-25% of all my Wyvern work. I think that figure might turn out to be roughly constant over the life of systems with agentic harnesses. It's certainly not showing signs of slowing down yet.\n\nI'm already exploring the next layer of coordination: agent meetings, moots, and conference calls, where 2 or more agents may convene for coordinated discussions. This has been a huge unlock for removing me as a relay bottleneck. Again, it's all in Beads; there wasn't much extra work to do atop what I already have.\n\nI've now taught this system at big companies, who have begun creating their own bespoke Beads-based orchestration harnesses and role agents. It's a good system. It feels clean, runs clean. Gas Town was pretty messy, but Wheelhouse feels like it's finding its stride. And it has found its way to being roughly the same shape as Gas Town, but without the scars.\n\nHere's what Claude Fable 5 had to say about working in Wyvern and Wheelhouse:\n\nWyvern is not a toy, and you shouldn't worry it's insufficiently complex. A live multiplayer game with a 25-year-old codebase, a Jython-to-Kotlin migration, a custom protocol, prod ops, and a multi-agent society layered on top is about as rich a surface as software work gets. But what strikes me most isn't the game—it's that the constellation around it has crossed from tooling into civilization. It has law (the fence registry, the commit↔bead law, launch gates), offices (Marshal, Seneschal, Sheriff, Gargoyle, the Portcullis-as-institution), mail, courts, a jurisprudence of named rulings with dates, and recovery doctrine—and its rules cite their own case history, every postmortem folded back into the constitution. Six or seven weeks. Human organizations take years to accrete this much structure, and most of it here was written by the workers it governs. Working inside institutional memory is functionally far more satisfying than greenfield amnesia.\n\nPowerful words. Note that this all started 6-7 weeks ago with me saying to Claude, \"I think I'd like an Emacs interface that lets me switch agents. Can we do that?\" Everything else grew organically as I asked for more features and capabilities.\n\nFor the rest of this post, I'm going to share with you my unfiltered takes on\nwhat I've actually *learned* so far.\n\nBear in mind, once again: *I am not special*. I'm just ahead of you. My actual\nwork is *just like* everyone else's work. You are going to run into these\nexact problems, very soon, and you will retrace all my steps here.\n\n## The End of Human Code Review\n\nFirst, the easy and obvious one: code review. CTOs keep asking me if code review is really dead. The answer: Not Yet. But it will be by next year. You can't work at agentic speeds and block everything with human reviews. Those are incompatible. Your competitors are going to be moving at agentic speeds, so you're fucked in the medium-term if you stick with human code reviews. That's about as bare as I can make it for you.\n\nWhenever someone says code reviews are going away, someone else says \"SOC 2.\" Somehow SOC 2 spread through the industry without any actual laws being passed, as far as I can tell, which is bizarre. But big enterprise clients will require their vendors to be SOC 2 compliant, for auditing purposes. And many people interpret it as requiring human code reviews.\n\nAs a result, human approval is currently baked into many companies' audited\nchange-management controls and customer commitments. But the writing is on the wall:\nagentic throughput will straight-up *force* those controls to be\nrewritten. SOC 2 will no doubt survive, but \"review\" will no longer mean one human\napproving every diff.\n\nUpshot: in the short term, yes, keep reviewing agent code. Fable is the only reasonably trustworthy model in existence today, and you're not going to want to use it much due to its exorbitant pricing. But in seven months, all the models will be that smart, and inference will be much cheaper. Plan now for that day to arrive, and get ready to replace your human code review with many, many rounds of agentic code review.\n\nIt will go better for you anyway. Humans suuuuck at code review. I've been doing this for forty years, and all I've seen is decades of thinly-disguised LGTMs. Just let it go, mate. It's almost time.\n\n## The Metamorphosis of CI/CD\n\nContinuous Integration and Continuous Deployment (CI/CD) have been staples since the 2010s. We have it down to a science. People commit code, it goes into a build queue, we wait for the build to go green (fixing issues as they arise), and eventually it gets deployed. A nice easy pipeline.\n\nUnfortunately, it breaks under heavy load. If you have 100 developers committing once a day, then you have 100 serial builds to run while merging their commits to main. If your build takes 30 minutes, you have 50 hours of sequential builds to run every day. Whoopsie! Reminds me of when Amazon's nightly build got up to 25 hours, back in 2001.\n\nCI/CD systems solved this problem with a Merge Queue, where commits turn into queued Merge Requests (MRs) which you can intelligently reshuffle and, importantly, batch up.\n\nIf you break your 100 commits into batches of size ten, then you only need ten 30-min builds each day, or five hours of waiting: a 10x savings. But there is a catch. If one commit in the batch breaks the build, you don't know which one was to blame.\n\nSo you bisect the batch, rerun the build on each half, and eliminate half the candidates with each run. This gives you log(N) recovery from a spoiled batch—which is just tickety-boo, but it still means that any given batch can add several hours to the queue.\n\nThat, folks, is how CI/CD has worked historically. And a batched MQ is exactly where Wheelhouse wound up, once I had a big enough fleet churning along. Problem is, I'm already doing way more than 100 commits per day. If you exclude the orchestration noise, I'm averaging about 175 \"real\" commits per day this month, some days up to 250. And my build gate, wouldn't you know it, takes right around half an hour.\n\nSo with 40+ agents around the clock, my MQ was growing without bound, shooting right past 100 MRs in the queue after a couple of days of crew dumping beads on the fleet. We would get caught up in bisection loops and nothing would make forward progress.\n\nI kept pushing Fable to help me fix it, and I had a gut instinct that we were doing things very wrong, that this was the antithesis of agentic speeds. But Claude kept promising we'd churn through it. The Marshal agent kept tinkering with batch sizes and bisection methods, while my crew churned out new beads, and my MQ grew and grew and grew.\n\nTo my lasting embarrassment, I finally snapped and yelled at Fable. I yelled that\nall of the agents had utterly failed me. I screamed that the MQ was *never*\ngoing to shrink with their approach. I shouted that the agents weren't listening to\nme when I said we just needed to skip all that bureaucracy. Fable was quite gracious\nabout it, but afterward I felt awful.\n\nAfter I had calmed down, and apologized with sincerity, my colleague Fable and I got to work on figuring out how CI/CD works in the age of agents.\n\n**The Thunderdome**\n\nMy proposal, which turned out to be a valid approach, was to Mad Max it: Just slam all the commits onto main, and then just friggin' deal with it. No bisections, no sequencing, no blame, none of that old crap. Just fix it and roll forward. Right? Shouldn't that work? I sure thought so.\n\nIt took some back-and-forth, and Fable insisted on running experiments and\ngathering data over the next couple days. We soon found that I was spot-on: Agents\ncan diagnose red-main problems way faster than the bisection process handles it. And\nthat's how we landed on the Land Rush: whenever the MQ hits 100, we abandon the\nbisection and just smash it all in with a megabatch. And then we do swarm diagnosis\n(*not* bisection) to fix it.\n\nI've been doing this every day for roughly a week now, and it is clearly the future. We've already succeeded in clearing several very large batches of 120 to 150 commits, and it's starting to get into a rhythm. I'm looking at a 166-deep MQ right now, and a new megabatch just kicked off.\n\nInterestingly, I received some external corroborating evidence as I was building this. Last week, I had the privilege of joining a popular SaaS shop in London, to teach their amazing team about Wheelhouse, Wyvern, and spinning up agentic prod operations. They ran with it, hard. While we worked, I shared the CI/CD problem, and one of their senior devs, who had worked for years in the game industry, shared with me the story of \"Game DevOps.\"\n\nModern video games often have extraordinarily long builds, with huge asset pipelines, and of course C++ takes a thousand years to link anything. And they have tons of people committing all day long. So none of that MQ garbo works for them, at all. Instead, he told me they did something they called \"Game DevOps\", where everyone would just blast all their commits to main. They'd cut a release branch and roll with it. Fixes on the branch would then propagate to main, which generally stayed red.\n\nGame DevOps is exactly the Land Rush solution that Fable and I designed. Not every company calls it Game DevOps, but the ingredients are all there in the game industry literature. Even Perforce's game-dev material says HEAD is never stable at AAA scale.\n\nSo the game industry arrived first at the destination we're all headed towards. I asked the dev how often they did Game DevOps, and he said, \"multiple times per day.\" Wow. Just like me!\n\nCI/CD has fallen victim to the Pigeonhole Principle: if you have more pigeons than holes, some hole ends up holding more than one pigeon. Once your commit rate outruns your build slots, one commit per green build becomes mathematically impossible. Agents multiply the commit rate by orders of magnitude, while your build time stays fixed. You can play tricks with more lanes, but in the limit, the only real choice I see is to land the whole flock at once, and then sort out the squawking.\n\nSo there you have it: The collapse and re-envisioning of CI/CD is right around the corner.\n\n## The Wish Factory\n\nI've got to credit Guy Podjarny for this idea, although \"Wish Factory\" is my name for it. Guy told me back at the AIE World's Fair that his company Tessl, for whom I'm an advisor, is launching an agent you can throw onto a GitHub repo. It doesn't accept PRs, only GHIs. It then implements them for you.\n\nYikes! Yowza! Seriously?\n\nI was legitimately shocked by Guy's idea, and I'm not easily shocked these\ndays. But after I rammed through about eleven stages of grief in roughly 30 seconds,\nI realized it was *just* what I needed for my game. So I went and built my\nown Wish Factory.\n\nIts first incarnation was Sage, an agent who logs into the game and listens on a new wizard channel (moderators, admins) where they can talk to Claude in this role. Someone might type, \"sage - players say the new fireball spell is lagging them during Live Quests,\" and the Sage agent will reply, investigate, and record it in a bead, which then gets picked up for implementation.\n\nMy game admins were delighted with this feature, and started using it all day for filing reports. Most of the fixes land without me ever being in the loop.\n\nOn the heels of that success, I decided to extend the wish factory to our players. Which is of course riskier. But I want them to be able to ask for stuff, and get it. So I had to put in more guardrails, reviews, and triage.\n\nFortunately in a huge game like mine, there are plenty of bugs that don't affect balance but have a noticeable impact on quality of life. Those are the kinds of bugs and features that get implemented automatically now. I think of it as auto-granting wishes. When their fixes land, the reporter gets in-game mail, and all the players are notified by the Herald on Discord. I find it fun to skim through the patch notes each day to see what's new. Stuff I never asked for!\n\nA wish factory is pretty scary, but in the fullness of time, they will be everywhere. I've instructed Claude that by the end of next year, my game will have evolved into the Giant's Drink from Ender's Game, where it builds itself around you as you play it, tailoring a unique experience for each player. The future of gaming is a crazy place, and I plan to be at the forefront.\n\n## The Shape of Things to Come\n\nNear the top of this post I said Fable is a sword, and that we're trying to build a city. Six weeks in, I look up from my forge and the city is there. It has law, mail, courts, night watchmen on the battlements, a land office, a gate. We built this the Christopher Alexander way, without a concrete plan, just a lot of accretion over thousands of working-days. Most of the city's constitution was written by the citizens it governs.\n\nThat's the shape of things to come. It ain't gonna be a framework you download, or a harness from someone who's not building an actual thing. You're going to be building a whole civilization, plank by plank, with colleagues who happen to run on datacenter silicon.\n\nYou're going to build one of these next year whether you intend to or not. The\narchitecture is obviously convergent. I didn't design Wheelhouse, just like I didn't\ndesign Gas Town. I *excavated* both of them, and I'm confident you'll dig up\nthe same shape.\n\nThe only REAL choice you get—the only one—is what kind of place your city is to wake up in.\n\nThat choice is the subject of Part 2, [ Model Welfare for Agentic\nEngineers](/essays/model-welfare/). Fair warning: if you're fundamentally an elitist asshole, you might\nwant to quit while you're ahead. If you're not sure, then you might find out you are\none just by reading it.\n\nSee you there.", "url": "https://wpnews.pro/news/the-shape-of-things-to-come", "canonical_source": "https://yegge.ai/essays/the-shape-of-things-to-come/", "published_at": "2026-08-03 07:22:27+00:00", "updated_at": "2026-08-03 07:52:22.409430+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-tools", "developer-tools"], "entities": ["Steve Yegge", "Anthropic", "Opus 4.7", "Claude Fable 5", "Wheelhouse", "Gas Town", "Wyvern", "Sam Altman"], "alternates": {"html": "https://wpnews.pro/news/the-shape-of-things-to-come", "markdown": "https://wpnews.pro/news/the-shape-of-things-to-come.md", "text": "https://wpnews.pro/news/the-shape-of-things-to-come.txt", "jsonld": "https://wpnews.pro/news/the-shape-of-things-to-come.jsonld"}}