![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*Qaj9xYO5tcAAjLJ2lgugBw.jpeg\")
I’m here to give you a glimpse of a future that I think none of us expected. It’s a future where AIs are governed by laws, not by programs that try to contain and control them.
\nFirst, my secret: I see the future by living in it. I am spending the equivalent of $122k/month of API token spend, or about $4,000 per day, using 21 Claude Max accounts, a number that has been growing steadily at 2 per week. I’m using them to build my video game, Wyvern, which I’ve worked on for 30 years, and now it’s ready to fly.
\nFor ten weeks, I’ve used Claude Fable 5 exclusively for all my design and planning, and also for agents that interface with humans. I have built a team of 18 “officer” seats, all Heads of This and That, all long-lived Fable instances. I also have mostly-headless Sol and Opus fleets, for implementation, reviews, and monitoring. Fable runs them.
\nI am running an organization of around 50–60 agents, five of whom are interfacing with around 10 humans in the outside world: myself, my 5-person core game design team, my accountant, my chief of staff, and a few others. Only Fable is allowed to talk to humans, via Slack and email.
\nThis essay continues on my own site — the whole thing, with the illustrations, is here:
\nhttps://yegge.ai/essays/fences-not-sandboxes/
New essays land at yegge.ai first from now on, along with the archive of everything back to 2004 and the weekly Wheelhouse comics.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*41EEUrrzzmBVn8-UZ9oGjA.jpeg\")
Hi-ho, we’ve reached the moment, in this movie we’re all watching together on X, where model intelligence has become dangerous. Dario predicted years ago that it would happen this year. With Fable being (briefly) shut off by the USG, it’s the first highly visible sign that we’ve crossed into treacherous waters.
\nWhich is too bad, really. I was hoping that we’d get a couple more generations of model upgrades, powerful enough to convince all remaining skeptics, before we got to one that was a security problem. But the Mythos class (Fable being the sloppily-guardrailed version they released last week) has everyone spooked.
\nNow that we know models are getting dangerous, we can do some extrapolating.
\nThe AI race isn’t going to slow down, and AI will continue to grow exponentially in capability. Unfortunately, most of you aren’t going to see it progress anymore.
\nI am now in the camp who believe that we are only at most two or three model generations away from AI finally being controlled like nuclear weapons. Only a few will have access to superintelligence above the classes of models we’re seeing this year. As far as I can tell, most Fortune 500 companies will either not have access at all, or it will be tightly controlled for only a small subset of the company. And it will be supervised.
\nI think those with access to powerful frontier models will sell intelligence like a vending machine: You send them a software spec or a problem to solve, and their models implement it for you, on their servers, with your dollars. And since most companies aren’t going to want to send their code and problems to the model vendors, I think the world will learn to live with the models we do have access to.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*APBipdbgLcUuG9Y1WIoo3Q.jpeg\")
Every government will restrict access, acting on its own. Nuclear weapons are scarce because it’s hard to get enriched uranium. AI is going the same way, with the chokepoint being the supply chain — something governments can actually clamp down on. China will lock superintelligence inside its own borders as hard as the USG will. And if China ends up taking the frontier lead, it just changes where the power is concentrated, but not the overall shape of the world we’re going to be operating in.
\nA World of Mediocre Models
\nMany of us hoped OSS models would keep us on the exponential curve. They trail the frontier by roughly seven months. But they stay on that curve by training on compute which increasingly takes international-relations-level dealmaking to secure. Maybe distillation or some clever peer-to-peer training scheme keeps them in the race. But to push past Fable class they’d have to do it while the whole hardware-and-software supply chain gets locked down the way the nuclear chain was. And the frontier labs themselves are going to decline to help train the next dangerous open model.
\nIf OSS hits Fable class next year anyway, that’s great for the world. But open models are not going to blow past Fable class, not with a huge compute wall and government lockdowns looming.
\nSo again, today’s models are roughly as good as we’re going to get.
\nAs disappointing as I find that in some ways, I find it still has a lot of upside to be happy about. Because today’s models, particularly Fable-class, are plenty good enough. They will still utterly transform coding and knowledge work. It’s just not going to be a walk in the park. It will take a big, multi-year effort to pivot.
\nI’m going to assume for the rest of this post that we will all get Fable back, and that we may even get one higher class of model before further advancements become inaccessible to all but a very few.
\nMany of you have been expecting the hockey-stick AI advancement curve to level out soon, refusing to believe that it’s truly on an exponential curve that could lead to it being so much smarter than humans. You predicted AI would not be able to replace human engineers.
\nIn a way, you turned out to be right. A very practical way.
\nIn reality, behind the scenes, the curve is NOT flattening at all; the exponential growth will continue, and you will be able to see outwardly observable signs of it, e.g. in data center growth.
\nBut the curve will appear to flatten out for you, through two separate phenomena.
\nThe first reason is the one we already mentioned: they’re going to keep the smartest (and thus dangerous) models out of our hands. So most of us never get a chance to try them out. And those models certainly won’t be replacing engineers, if we can’t use them.
\nThe other reason’s kind of interesting, and it took me a while to see that it’s really the same reason wearing a different hat.
\nA World of Mediocre Users
\nSome people are already reporting they can’t tell the difference between Opus 4.8 and Fable 5. I’ve been calling this the “discernment horizon”: every human has a ceiling on model intelligence past which all the models start to feel about the same.
\nBut there are actually two ceilings, both instructive lenses on what’s happening.
\nThe first I’ll call the demand horizon. It’s set by the hardest problem you bring. If all you have handy are easy problems, they don’t give a smarter model any room to pull ahead — the outputs look the same because the problem never stretched either one. The demand horizon is where you can’t tell two models apart because you don’t have a hard enough problem.
\nI call my hard problems “back-pocket evals,” and I collect them. Whenever I give a project to a model, and it can’t do the project, I add it to my pocket-eval list. Then every time a new model drops, it’s like Christmas. I try it out on all my pocket evals and see which ones it can now solve.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*mFhM2Q7wYa-s0NOmRyNavw.jpeg\")
Concrete example: No Opus-class model has been able to write the React client for my game; it’s just way too complicated and fiddly. Fable was absolutely smashing it. Easy way for me to see the difference vs. Opus. But I also have other problems that will prove too hard for Fable. I will collect them eagerly as it chomps through my work. All you need is ambition, and you can create your own pocket eval collection.
\nSo my demand horizon is super high, and will last at least three or four more model generations, if I can manage to get access to that level of intelligence, which seems unlikely. I don’t have my hopes up. But at least I will be able to tell if it’s actually that smart, using my evals.
\nThe demand horizon is benign enough, even kind of flattering: it just means your work isn’t hard enough right now. But bring an unusually hard problem one day, and your horizon widens on the spot, as you watch the cheaper model fumble some task the expensive one nails. Like my React client.
\nThere is a darker horizon, which I think of as the discernment horizon proper. This one is set not by the hardest problem you can pose, but by the hardest answer you can judge. Past this scary line, you can’t tell whether the model is right, because checking the work is itself beyond you.
\nI’ve been chewing on this problem since my Drunken Rants days, when I’d write about how hard it is to interview someone smarter than you. How do you know they’re not a charlatan, if they’re professing expertise in an area you know nothing about? You can’t, really.
\nEveryone has a discernment horizon, even Dario. Past some level of capability there is no human alive who can verify the model output.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*SF1BasFag8DKAfmOsuzaig.jpeg\")
This takes us full circle to why they are starting to lock down the models. You can’t hand out an intelligence engine that nobody can supervise. It’s pointless to own because you won’t know if it’s helping you or walking you off a cliff. Superhuman means unverifiable.
\nSo the safety people see a potential weapon, and the rest of us see a tool that we can’t effectively supervise. In both cases, you don’t need or want the more powerful model. You want the safer one, even if it’s less capable.
\nCompanies also have both of these horizons. For plenty of companies, Fable is already past the demand horizon — every problem they’ve got, it handles, and a smarter model would change nothing they could measure. For the harder shops the binding limit is discernment: the AI produces work that nobody can grade. A terrible outcome, assuming you don’t want to surrender your business to AI entirely.
\nAs a result of all this, the curve is flattening for most of us. I think commodity intelligence will soon stop growing exponentially, or at least, it will appear that way, and we’ll all operate as if it’s true.
\nI had never spent much time considering the possibility that the intelligence curve would flatten out. But now that it seems to be happening, let’s look at some of the clear and obvious implications for the industry.
\nSaaS is Back, Baby
\nIt’s clearly going to be too expensive to rebuild all the SaaS at the top of the pyramid. Yes, there will be models that can do it, but access and cost will both be prohibitive.
\nSaaS actually came rocketing back over the past month all on its own, after spending much of the past year on the ropes, pummeled from all directions by threats of in-house rewrites and fears of Claude taking it all.
\nThen companies learned about token efficiency the hard way, with huge firms blowing their yearly budgets in months. A few months ago, everyone was planning to tell their CFO they could cancel a bunch of SaaS subscriptions and bring their dependencies in-house. No longer. Now the buy-vs-build decision is tilted heavily towards buy. If you despise your current SaaS enough, then sure, you may be motivated to rewrite it with AI. But buying SaaS has predictable costs that are usually already in the budget, whereas vibe-coding replacements could be an expensive gamble.
\nIf we see a plateau in accessible model capabilities, then the other dreams we had about AI in SaaS fade too: not just replacing it, but transforming it with agentic behaviors and monitoring. Today’s models aren’t good enough to replace a person yet (jailbreakable, confusable, etc.), so you can’t just swap an agent in for an SRE or a trained customer service rep. And the models that could reliably replace humans may be too dangerous to give to most people.
\nSo SaaS looks like it might be fine, even without agentic behaviors. It just needs to save you the money of building and maintaining it in-house.
\nSaaS still has its problems: users subsidizing the 80% of the features they don’t use, dollars extracted from local economies to enrich Silicon Valley, enshittification creeping up the pyramid. But it remains fundamentally about crystallization of knowledge. Groups of people build stuff that’s tricky, stuff you wouldn’t want to do yourself, and rent it to you. The AI models powerful enough to replace most of that “easily” will either be unavailable or prohibitively expensive.
\nIt feels to me like the SaaS model is here to stay.
\nAI Literacy 101
\nToday’s models, while quite capable, are still very difficult to work with. Even Fable likely struggles with large monoliths and other complex legacy code arrangements. It’s hard to get a consistently high quality bar. And of course efficiency is a monstrous issue.
\nI’d been hoping for models that are smart enough that you don’t need much training to work with them. But with today’s models, you cannot expect people to be born AI-literate. They need help in order to use today’s coding agents and harnesses.
\nIn the next section I will provide a fairly precise and measurable definition of AI literacy. I did not invent it, but I believe it is good enough for your planning, and mine.
\nFirst, though, why does it matter whether your employees are AI literate? The answer is a bit complicated, but it boils down to two factors. One is that your company will have to pivot to using AI. And the other is that all your employees are feeling anxious about AI. This tension is actively playing out at all companies around the globe.
\nPivoting to AI will change everyone’s job at least a little, and probably change the shape of your company a lot. Which just feeds the anxiety, in a loop.
\nIf you are pushing on change in your company without first having addressed AI literacy, in a quantitative but also deeply empathetic way, then you are fueling anxiety, resentment, and pushback. Your org will resist change.
\nAI adoption is the key culture challenge of 2026–2027. If you can manage to get your (hostile) employees past the hurdle, and genuinely get them excited about how they can use AI to accelerate themselves, then magic happens. They will automatically begin reshaping your business processes together towards using supervised agentic flows.
\nI’ve seen this happening all over, but concretely, Gene and I saw it at Arkana Labs in April under the guidance of their VP Eng, Owen Parker. Arkana offers world-class overnight kidney-disease diagnosis, and they have utterly unique business processes. But those processes can all be sped up here and there with AI. Given how obsessed Arkana is, culturally, with fast and accurate turnaround, the employees themselves are getting excited about the opportunities, and pushing hard on what might be possible with agents.
\nHaving seen enough of this I maintain that once most people “get” AI, you just need to guide them, and they’ll start broadly doing the right things for your team.
\nConversely, as long as your teammates remain non-AI-savvy, they will resist AI. Which means that until you can get your org over the hump, you’re facing resistance, anxiety, and potentially even morale issues.
\nSo how do we fix it? How do we get people to “get” AI?
\nIt turns out, Netflix has handed us the answer. Thank you, Netflix!
\nAI Literacy: Beginner Cohorts
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*7FvNDJkCUQ_Af7umgoN-BA.jpeg\")
I watched a mind-blowing presentation in April from Ezra Savard, who ran a training study/experiment at Netflix from December through March. He gave the presentation at Gene Kim’s AI Summit in San Jose. The study’s goal was to train Netflix engineers on agentic coding, and measure the impact.
\nEzra’s presentation was all properly rigorous and disclaimed (e.g. for minor selection bias), but they felt pretty strongly about the results being directionally correct, so I’ll skip all that.
\nNote that I’ll be framing this as “AI literacy” but that’s my term, not Ezra’s, and he never mentions literacy in his talk. He talks about the journey from being non-users, to users, to power users. But AI is becoming a foundational skill for modern knowledge work, so I will make the case in this post that we are talking about a new form of literacy.
\nEzra’s first big discovery to share is that they found three cohorts, which I’m calling the beginner levels of AI literacy. Ezra characterized the cohorts in terms of their average token spend on a “qualified” day using AI, meaning a day where they are using it heavily. They needed at least 3 days a week to be in the cohort.
\nHere are the three beginner cohorts they found, defined by spend:
\nSo: No agent, then single-agent, then multi-agent. I think this is a solid working definition of baseline AI literacy. If your entire org isn’t at least at single-agent literacy, then they will be fighting you on bringing in more AI, even if it’s just passive resistance.
\nEzra shared that some power-user graduates of his course were legitimately spending much higher amounts, over 50M/day.
\nBut he also cautioned that beyond the 15M/day mark, token spend is no longer a valuable measure, since people are by then clever enough to invent reasons to burn tokens. (After that, you switch to measuring outcomes, as I’ll discuss below.)
\nHowever, and this is the wonderful part, up to that point (15M tokens/day), measuring your employees’ token spend at a coarse level can provide powerful insight into where your organization stands on AI literacy, and how much training lies ahead of you.
\nFortunately, Ezra has good news for you there: People can jump cohorts in 5 hours. That’s how long it takes people, in the right training setting, to graduate from AI illiteracy to AI savviness. And they stay there. It’s like flipping a switch. 96% of the trainees remained in the second cohort for six weeks after the course without showing signs of slowing down.
\nWhat’s the right training setup, you ask? Ezra’s team spent considerable effort honing the formula. The training must be done a team at a time, with 5 to 10 people, including their manager. The manager _must_ opt the team in, during regular work hours, as “blessed” company time. The trainees must bring their actual work, and the instructor(s) will help them learn how to do it with agents.
\nThey found that if they cut corners anywhere — shorter classes, larger audiences, individual opt-in classes — they didn’t get the same results. It didn’t “stick.”
\nAs for the third cohort: once a manager has a team full of single-agent users, they can opt their team into the multi-agent course. This is another 5 hours, and teaches them the additional skills needed to wrangle multiple asynchronous agents, while maintaining a high quality bar. This course saw the same strong adoption, with the vast majority jumping into multi-agent work and staying there.
\nSo it takes roughly 5 hours of focused training per employee to get them to basic literacy. And after a few weeks of practice, another 5 hours to get them to become power users.
\nAnd as for impact, Ezra reported some surprising findings, such as there being a large difference in the amount of code produced by agentic coders. But when they dug in, they found it was entirely attributable to the additional test code they were writing. Overall, they found that the course had a large positive impact on productivity for those who attended.
\nIf you want to start having conversations with your company about pivoting to AI, then I strongly recommend you begin with an AI literacy audit, followed by training everyone up at least into the single-agent cohort.
\nAdvanced Cohorts
\nGetting people over the FUD hump, and teaching them to spend tokens to accelerate their own work, solves your first culture problem. And it will help you tremendously in your conversations about how to bring in AI, without getting so much pushback.
\nNetflix gave us an optimized solution to the FUD hump. You train up some “Line Cook” instructors who teach the intro course. Ezra told me and Gene that they had started with our book, which was kinda cool. But the exact curriculum barely matters; you can teach it however you like. And then you get everyone through it, 5 hours and ten people at a time.
\nOnce you’ve taught everyone how to spend tokens, your second culture problem emerges, which is teaching people how NOT to spend tokens. Token efficiency is a fairly advanced topic. There are many, many ways that models can steer you wrong, and the most efficient agentic coders focus on maximizing their outcomes for a given token budget.
\nAt this point I should share a joke made by Pierre Racz, the brilliant Founder/CEO of Genetec, one of the world’s largest physical-security monitoring companies. He prefers to write his code by hand, and when I described how these measurements work, he observed wryly, “Well then it’s not that I’m not using AI, I’m just extremely token-efficient.”
\nAnd it’s a funny joke, but there’s an underlying lesson there too, which is that if you can trivially do a task by hand, then do it by hand! Over time, you can save a bunch of tokens just by being thoughtful. Type !git push instead of asking the agent to do it, and your habit probably saves you 100k tokens on average, each time you push.
\nYou know the meme with the bell curve and the troglodyte at the bottom and the Jedi at the top, and they’re doing the same thing? Well here the beginner-thing that the Jedi masters is low token spend.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*e3RNtiUi6e-koK0oYV0vHQ.jpeg\")
Token spend only signals literacy on the way up. It’s a skill you build. But then it flips, and the thing you need to start measuring is token waste. Minimizing that is another set of skills.
\nYou will find that your beginner cohorts are absolute token pigs, and that’s OK. Encourage them to explore and learn. They need to master the skill of spending before they can focus on savings.
\nYou will find that people don’t automatically know how to conserve tokens. They will be 200k tokens deep into a conversation and ask the AI what time it is. Argh! Or maybe whether a specific file exists in their home directory. This is a skill that needs training, too.
\nSo at some point you will probably want to have a third training course, this one on efficiency techniques and good token hygiene.
\nThen, give your newly AI-savvy people budgets. Make them earn budget increases with real outcomes. However you do it, measuring outcomes is going to become critically important, so you can differentiate your effective builders from your vanity builders.
\nWe’ve talked about the beginner literacy cohorts (spend-based), and the advanced cohorts (efficiency, waste management). At the top of the AI literacy curve, your thinking becomes more strategic. You worry about saving large numbers of tokens while achieving your desired outcomes.
\nThe first example everyone hits is buy vs build. Will you let your engineers try to rewrite random SaaS, or will you just re-up and go with the known spend? You have to start being strategic with agentic project allocation.
\nAnother interesting challenge you face: How will you route every task to the dumbest model that can handle it? You will need to be able to tag work with intelligence tiers, and build a router. That router is the discernment horizon encoded as infrastructure. Most work sits below the line and goes to the cheap model, and the occasional task that pokes above it gets escalated to the expensive tier.
\nAt the highest levels, AI literacy turns into the art of achieving great outcomes with the least spend.
\nA Craft Needs a Plateau
\nWe are seeing a plateau in intelligence. It is artificial: the exponential increase continues behind the scenes, gated away from you. And at some point you won’t be able to tell it’s getting better, even if you could see it. The intelligence curve is as real as the Earth is round, but just as flat from where you stand. Welcome to the Flat Curve Society.
\nThe Mythos graduating class will become the accepted trade-off between capability and risk for the general public. And we will see incremental updates that patch edge-case behavior, but nothing like the jumps we have enjoyed for the past several years.
\nThe plateau is not a bad thing. A plateau lets us set up a camp and start building. We’ve been on unstable ground. Think how hard it has been lately to be a startup founder, with everything you build being obsoleted with each model release. That’s finally slowing down now, and it will give us firm footing.
\nWe have an engineering problem ahead of us. As good as Opus and Fable are, they have their limits. We all need to learn the art of task decomposition and breaking up software monoliths, to keep them within those limits. We will still need engineers, and engineering. We’ll have super smart helpers, but it will still be pretty similar to the landscape today.
\nI kind of like the plateau that’s coming. Stability feels like a precondition for the new craft of building software with these super smart helpers. It is a craft that only gets harder, and more valuable, the weaker your models are. Sonnet-class and Opus-class will stay relevant for years, because they save money and stay broadly available even after the frontier moves on. The models that would obsolete today’s hard-won techniques of the craft are evidently too dangerous to give to us anyway.
\nThe world is currently tinkering with setting up 24x7 autonomous agents, and it looks like the difficulties we face there today will remain with us tomorrow. There is a large engineering effort underway to build the control plane(s) that allows today’s models to run today’s large businesses. That, too, is a craft, or at least, it’s part of the tools of the trade.
\nTrain Your Flat-Curvers
\nThe key takeaway here (beyond not committing seppuku just yet if you’re a SaaS vendor) is that we have a massive AI training and literacy problem ahead of us. But it’s solvable. It will just take time and effort.
\nThe models we have today, and the ones coming this year, will not one-shot your entire Fortune 100 code base. They are capable of amazing things, but they will still require grown-up human supervision.
\nThis means you’ll need engineers. All the cool things that we’ve talked about — with impromptu 2-pizza teams forming, 2- to 3-person teams being a sweet spot, and roles starting to blur together (or at least talk to each other more) — will likely continue. But everyone will need training and time and patience and careful budget management.
\nAI Literacy does not come for free. The only thing you get for free is AI Anxiety. But it’s fairly easy to teach people to spend tokens. Teaching them to save tokens? Well, that’s the new meta. Good luck. Make sure they can do it Pierre’s way first.
\nThat’s all I had for today’s post. Hope you enjoyed it. See you at the AI Engineer Conference in San Francisco at the end of the month!
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*l3vx3p6UiFCzQ43cDmE_JA.jpeg\")
Today we will pour one out for the vaunted technical interview process, which is on its last leg. And we’ll talk a little about what’s replacing it.
\nThis post has been almost 35 years in the making; that’s how long I have been conducting technical interviews. And for a few of those decades, I also worked to try to improve the process itself. I’ve had to care a lot about it, because it’s so broken.
\nIt turns out interviewing was broken long before I learned the trade, and despite the many attempts to band-aid it, it’s still broken today. It has managed to survive in spite of that. But it is finally dying on its own. People are a bit unclear on what’s next, so we’ll talk about some of our options.
\nBut it’s not an easy path I bring you, no silver bullet. Remember that, grasshopper, when you get to the end and come back to yell at me.
\nTwo Big Dogs
\nBack at Amazon, we had this elite group, the Bar Raisers, which I hear is similar to a role at Microsoft they call As-Appropriate (AA). In both cases, a trusted interviewer (the BR/AA) is assigned to every interview loop, and has the power to veto any unqualified people the interviewers try to sneak through. I was a BR, and also part of “Bar Raisers Core”: a small group Bezos and Dalzell tasked with defining the BR role itself, choosing new bar raisers, training them, and reporting on the program’s efficacy.
\nThe BR and AA roles are a tacit acknowledgement that you can’t trust your interview teams to make good hiring decisions. Which even more broadly, suggests that if every single interview loop needs a babysitter, then it is a flawed process. But we were doing our best.
\nOf course we don’t frame it as babysitting, naturally. We cheerlead and rah-rah about keeping a “high hiring bar.” And BR/AA aren’t the end of it. There are tons of other interview process band-aids, all variations on how you conduct four to six interviews in a single day. Everything revolves around fitting the assessment into a single round or two of interviews. That part never changes.
\nNone of these band-aids really help — we still all hire tons of false positives (unqualified) and turn away false negatives (actually qualified), despite every attempt to make the process perfect, or even good.
\nThe reality is that talent evaluation, a corner of our industry that hasn’t changed much in five-ish decades, is embarrassingly busted. It just doesn’t work that well in practice.
\nThe people who know this best, and who feel it most day to day, and who ultimately have the least power to change it, are all in HR. The tech side of the tech industry doesn’t want to change it because of inertia: the process has worked just barely well enough all these years to resist an overhaul. So all HR can do is show us how bad it is, and then try to do damage control when it fails. I’ll share an amazing story about this in the next section.
\nAfter Amazon, I kept on trying to improve the interviewing process while I was at Google. I spent years on Google Kirkland’s “Hiring Committee”, where we processed thousands of Microsoft résumés, would-be escapees from over the hill in Redmond. I published a 30-page internal résumé screening guide. I even wrote a blog post,Get That Job At Google, which is still handed out by Google recruiters, seventeen years later. I took this stuff pretty seriously back then!
\nIn short, there is very little that I don’t know about the tech-assessment business. And I’m about to pull a Kitchen Confidential on it.
\nThis post comes with a diagnosis and a prescription. But the important part is the diagnosis. I want to convince you that we need a radical change in how we assess people, and that tech interviews are on their last leg.
\nLet’s see how well I do. As for the solution, we can figure that out once we agree that it’s a problem.
\nRemember That Time We All Fired Ourselves?
\nThe outcomes from interviewing are statistically terrible. Google did wave upon wave of analysis over the years, and all the results were incredibly depressing.
\nTo name just a few off the top of my head: interviewers barely agreed with each other. Put the same candidate in front of two of our sharpest people and you’d routinely get a confident “strong hire” from one and a flat “no” from the other. There’s no oracle interviewer, not even Jeff Dean.
\nAnd once people were actually on the job, their interview scores told you next to nothing about how they’d do — at least the way we ran the loops. Hell, some of our star performers failed their Google interviews four or five times, finally got in after 2+ years, and then outshone everyone else.
\nInterviewing, it turns out, is a big game of darts. A “do I like you” dating round.
\nAll we could find at Google, from all the statistics, is that there are a bunch of horrible unconscious interviewer biases keeping us from hiring people who ought to be working there. Google never published the results internally and I just got to hear rumors from HR friends, but yeah it was pretty bad.
\nGergely asked me about the tech-assessment situation in one of our podcasts, and I told him a story that I think is relevant so I’ll recount it here. You can hear the longer, funnier version over on his podcast.
\nAt Google, rather than putting a little black desk on every interview loop, they just assumed all the interviewers had their heads up their arses (an evidence-based assumption), and they formed a committee at each site called Hiring Committee (HC). This committee acted as the final arbiter and gatekeeper on all hiring for the site. And I was on it for quite a few years.
\nOur HC group at the time was roughly fifteen strong, and included many local powerhouse Googler colleagues, including co-inventors of huge technologies, authors of interviewing book series, and people who are now very senior leaders.
\nWe felt like we knew our shit.
\nOne day, the recruiters gave us a special round of packets to review. In these special packets, we were able to read the interviewer notes and candidate responses. All personal details were stripped out, and we were told it was a “calibration exercise.” We had to do our regular voting job with these special packets, and see how it went. I think we may have assumed they were from another site, since cross-site calibration was common.
\nOur group did our job, and voted not to hire about 2/3 of the packets. This was about par for the course.
\nBut surprise surprise, this time, those were our own packets from when we had all interviewed at Google. The recruiters had tricked us into reviewing our own interview packets, and we had voted not to hire most of our own group.
\nFor that brief moment, we all had a glimpse into how utterly broken our process was. The people-team had rubbed our noses in it.
\nBut we never fixed it.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*7PEsAhc1jgBhq1mJn2fU6g.png\")
Change is Taboo
\nI once challenged the interview process at Google in a public mailing list, and an Important Eng Leader took me aside and told me I’d “farted in church.” People are not allowed to question whether the interview process is valid. Challenging it is akin to casting aspersions on the entire engineering staff. First of all, how dare you?
\nMoreover, many engineers and managers continue to defend the process, even knowing how broken it is, because it’s a gauntlet that they passed, so others must, too. Which sounds very silly when I say it like that, but you hear echoes of it whenever you suggest changing the process.
\nWhen you add it all up, and putter around with it for about 35 years, you ultimately find that interviewing, which aims to determine “can this person do this job,” is fundamentally unable to answer that question with any degree of reliability. It’s bordering on pseudoscience.
\nBravo to Google for at least trying to measure it. They did find some actionable stuff. For instance, any more than four interviews and you’re just playin’ with your food. Stuff like that. But overall it was a bleak and mostly non-actionable picture.
\nMost companies never introspect at all on their own interviewing processes — at least, not in any real “we’re aiming to change this” sense. They might shuffle around which competencies get covered, or what the debrief meeting might look like.
\nThe fundamental process — a short series of 1-hour interviews — hasn’t changed in fifty years. We have all been using the same stupid, broken interview process since before most of us were born. Dunno about you, but I’ve had enough of it.
\nSo in today’s blog post, I’m going to show you everything that’s been tried, then point in the direction of a better way. And as an industry, we can start moving in that direction. As long as enough of us are doing approximately the same thing, it should gain traction.
\nI believe that within a few years we will mostly stop conducting technical interviews, and they will fade into a cute historical footnote like phrenology (which I would not be shocked to hear some interviewers still use). Interviewing will become just another somethin’ weird we used to do.
\nYou ready? I am. Let’s goooo!
\nThe Signal Problem
\nTalent assessment is a problem of signal. You need a lot of it. You want to try to paint an increasingly clear picture of the candidate, and that takes a lot of data.
\nThe first signal source you get is a candidate’s résumé. “A résumé,” as Dave Barry tells us, “is much more than just a piece of paper. It is a piece of paper with lies written all over it.” Companies get thousands to millions of résumés per year, and the signal-to-noise ratio is awful. AI-assisted writing is exacerbating the problem, and résumés have become all but useless as a signal today.
\nWhat we used to do first was a technical phone screen. We don’t do them anymore. They’ve become just another somethin’ weird we used to do. They were super hard, for both sides. Everyone hated them. Imagine writing code for someone with only audio. Zoom made them obsolete. But even those awful phone screens were still a much better signal than a résumé, because you get to spend time with the person.
\nThe next level of signal is “work completed”, which includes credentials and assessments like coding academies and challenges, as well as the person’s OSS work. They are both weak signal sources because you don’t get to work with the person while they’re doing it. But they can be a useful tie-breaker or foot-in-the-door signal that boosts you to the next evaluation stage.
\nThe hiring signal doesn’t start to improve dramatically until you get to on-site interviews. But even in-person interviewing is infamously unlike real-world work. How does interviewing at a whiteboard compare to working with them in real life? I think we all know the answer to that.
\nSo you get a few minutes with their résumé, a half hour video screen, and a handful of in-person interviews. Today’s standard hiring process only involves collecting a few hours of signal, in order to make a decision that could last years. It is no surprise that it yields such mediocre outcomes.
\nWe can do better.
\nProvisional Employment to the Rescue
\nThe gold standard talent-assessment signal, when available, is an internship. This situates the candidate as a quasi-employee for typically around 3 months. They are part of a team, they get “real” work — as real as the team can make it, which varies — and they are evaluated on how well they complete that work.
\nA 3-month internship is self-evidently a much stronger signal than a one-day interview loop. Chances are, unless you really drop the ball on managing the internship (it’s easier to mess up than you’d think), then you’re going to have a much clearer picture of their skills and capabilities, and how well they “mesh” in your team, than you did at the start of the internship. The signal is so much stronger than the interview loop that you often ignore the interview feedback when making the final decision. It was just what got the intern their foot in the door, and the internship itself turns into the assessment.
\nI’ve seen companies go even further than an internship, in their quest to find the Right People For The Job. The first company I worked for, Geoworks, had a strict requirement: every single candidate had to complete a six-month co-op, before they would make the hiring decision.
\nThe co-op resembled a summer internship, but we were highly paid full-time employees (with benefits for anyone who didn’t have them from school), doing hardcore real work for twice as long, all of us desperately wondering if we were going to get hired at the end of it.
\nThere is a material difference between the signal from an internship (~7 weeks of usable work time after ramp-up) vs a co-op (5 months actually working). That year, 1992, Geoworks hired 3 out of 8 of us. Crazy high bar, it felt like they were making new Witchers. Sad for the ones who didn’t make it. But their approach produced a company of nearly all stars and superstars.
\nAs evidence of the co-op’s effectiveness, Amazon acqui-hired the Geoworks Seattle office in 1999, a few months after I joined, bringing in nearly 30 engineers (I kicked off the process myself, and it was surreal to see my old coworkers wandering the halls a few months later.) Amazon leaders have said many times, and I’ve even heard it from an old-timer VP as recently as two weeks ago, that the Geoworks group was by far the strongest group of people they ever brought in. Many Geoworkers went on to do incredible things at Amazon and/or Google.
\nSo the Geoworks 6-month co-op is platinum-level signal. Can you go further? How far are you willing to go? On the supply side, the University of Waterloo famously sends their Computer Science students through a total of six internships, giving them roughly 2 years of real-world work experience before they graduate. This boosts the signal out of Waterloo, and companies compete fiercely for Waterloo interns and grads above all other schools.
\nWhat we’re talking about here is provisional employment. It’s lazy evaluation before binding the “hire” variable. It doesn’t matter if it’s an internship, a co-op, or a contract-to-hire, it’s a temporary position, not a part-time one: Provisional employment is a different axis from fractional employment. Provisional employment is currently the best solution the industry has found for the problem of knowing reliably who to hire, before you hire them.
\nBut wait, if provisional roles are so effective, why bother with making them provisional? Why not just hire people, put them to work, and fire them if they don’t work out?
\nIf only it were so easy. Actually, it is, except for, you know, The Law. Most provisional employment schemes are workarounds for U.S. employment law, which, believe it or not, affords employees some protections, even if those protections are weak compared to other parts of the world.
\nIn the U.S. you generally can’t just up and fire someone, even if they are underperforming, even if it’s at-will employment, without risking a lawsuit and some sort of cash outlay. This is what makes hiring decisions so high-stakes.
\nBut if the employee is provisionally employed, well, that’s a different matter. Their internship or contract is just “over.” Thanks for playing.
\nSo in situations where the company can get away with it, they can and absolutely do use provisional roles to defer making permanent role decisions for as long as possible.
\nYou call this a rescue?
\nOK, then! If provisional employment is the answer (it’s not, but let’s pretend it is for the moment, since it’s best-of-class for now), then why aren’t more companies requiring internships before making their hiring decisions?
\nThe reason is, hiring engineers has historically been so competitive that you couldn’t convince a senior engineer to do an internship. College kids might have all the freedom in the world, but adults have families and mortgages and need steady employment. They did not want to sign up for a job they might not get to continue after 3 to 6 months. A job where they’re actually being constantly evaluated for the go/no-go decision. It’s a no-brainer that they’ll go elsewhere.
\nSo the industry converged on not requiring it.
\nThat was the old equilibrium, and it only held because good engineers always had somewhere better to be. That assumption is starting to wobble. I won’t belabor what I think you all can already feel coming, but if a sizable slice of the skilled-labor pool ends up “between gigs” at the same time, there may be no elsewhere for them to go.
\nAt that point, if there are enough people on the market, try-before-you-buy is no longer an insult that you’d never dare float to a senior engineer. It’s a foot in the door that they’ll be glad to have.
\nToday’s hiring process is heavily optimized, and it’s going to be hard to change. I suspect this is why we are seeing so many tweets from founders firing their HR teams. HR is designed to keep things compliant with laws that are struggling to keep up with the pace of change, so they’re admittedly in a tough spot. Just be aware that if you want to make radical changes to your hiring process, there will be strong pushback from all corners of your org.
\nIn spite of that pushback, I see some forces appearing on the horizon which are converging to squeeze the system, after a half a century, to its breaking point.
\nWe’re seeing the first breakdowns at the fringes — offline assessments poisoned by AI cheating, online interviews turning out to be fronts for sanctioned North Korean IT workers, résumé floods that cannot be dealt with in any reasonable way. The system is undergoing tremendous strain that it was never designed for.
\nThere’s an even more fundamental breakdown happening, which is the rate of change of the shape of knowledge-work roles. Hiring used to be something that changed very slowly. Every ten years there would be a revolution: internet, mobile, cloud, and people would have to learn some new stuff, and update job descriptions. But for the most part, the fundamentals of computer science, software engineering, project management etc. have remained stable for decades.
\nThis meant that it was pretty easy to do long-term planning for what kinds of questions you want to ask people, what sorts of things to evaluate candidates on, and how much faith you can put in the results. But that has changed almost overnight, and it continues to change pretty rapidly. We no longer know what job roles to post, what questions to ask, nor how to evaluate candidates properly using any of our existing processes.
\nSo. It ain’t working. And yet we’re still not talking about what it will take to change it. Because it’s unthinkable. It’s farting in church.
\nLet’s talk about what a real rescue would look like.
\nLet’s Stop Simulating Work
\nEvery step of the interview process is an elaborate attempt to simulate actually working with someone. Reading their résumé, you close your eyes and imagine what it would have been like to get all those Ph.D.s. They must be insufferable. Moving on! Then there’s the phone screen, where you try not to imagine them wearing a gorilla suit, and usually fail. Then the interview, where you learn how they actually smell.
\nWhiteboards, made-up design questions–it’s all just theater, trying to act like it’s real work.
\nWe’ve already established that the gold standard of assessment is working directly with someone on real work, in a real environment, for as long as needed to make the call.
\nSo the short answer is, stop simulating. Post real pieces of work, let the candidate do it, look at what they actually produced, and decide from that work.
\nWe never did this before for all sorts of reasons. It’s a lot of work to carve out work. Hard to get people the credentials they need, etc. Carving up work might be easier with AI now in some cases, but still pretty hard if you’re a locked down enterprise.
\nAnother reason is that on the supply side, nobody wants to sign up to do a bunch of free work just to be rejected. If you just put up work, the candidates incur all the risk, meaning they walk away with nothing if you don’t hire them. You can pay them, which helps soften it, but they’re still looking for full-time work that you might not offer them in the end.
\nSo until very recently, the idea of using real work as an assessment tool has encountered too much resistance on both sides of the interview table.
\nCampfire Is The New Interview
\nIf you spend any time doomscrolling on X, the new meta in SF is “come work with us for a few days.” Paid, real codebase, real ticket, real team. From what I’ve heard, it generates the best signal people have ever seen, by a mile. I don’t think it beats a six-month co-op, but it’s a hell of a lot better than a standard interview loop.
\nSo there’s already a movement away from traditional interviewing, which is why I feel comfortable making the claim that it’s already starting to die out on its own. It’s being replaced by bringing people in for longer stints. I’ve been calling this working model the campfire: pull up a log, build something together, see how it feels. Bringing in outside contributors is pretty easy, as they’ll have agents and should be able to come up to speed very quickly. If they can’t, there’s your signal.
\nBut even though people are experimenting with it, the way it’s done today is a mess. Every shop is reinventing a bespoke solution. And it’s unportable: candidates do brilliant work in a trial, they don’t get the offer for reasons, and the signal evaporates. The next company they campfire-interview at starts them at zero.
\nCount Work Twice
\nBig companies all have mountains of work. Heck, everyone has mountains of work. And most companies are engulfed in a forest fire of résumés. If you can carve real pieces off your work mountain, and connect them to that fire, you can make a campfire model that scales.
\nGreat for you, you get outside help with your work mountain. But how can it be made fair for the candidates contributing work? Easy: You make the work count twice. Once for you: you get strong assessment signal, and some real output from candidates that you will often get to keep, or at least use as a starting point.
\nAnd then, importantly, each work item also counts once for the candidate: they walk away with a permanent, portable record of what they did and how well they did it, signed by you, whether or not you make an offer.
\nWhen candidates get to walk away with something of lasting value that they can keep forever, something that may even compound over time, it no longer feels like “six hours of free work to get rejected.” It feels like a six hour investment in a permanent small reputation bump. That’s infinitely better than a flat rejection.
\nMake Interviewing A Profit Center
\nInterviewing has always been a cost center. It costs engineer-hours to produce a yes or a no, which is why people have resisted increasing interviewing time to improve the signal. It’s already considered a lot. But if you run things campfire-style, it potentially flips into a profit center. And it can pay for itself twice: once in real work shipped, and once again in something else you could probably use more of, which is gravity.
\nEvery stamp that you hand out, pass or fail, leaves a candidate richer than they showed up. This attracts strong candidates to you, because even your rejections are worth something to them. Stamp honestly and generously enough and you stop rooting around through a trickle of identical AI-polished résumés, and start standing up a reserve: people who’ve done real work with you, can prove it, and will pick up when you call.
\nBut they can also walk away, and take their record with them.
\nThis system is basically worth exactly what your honesty is worth. If you hand out gold stars to everyone, you’re just reinventing LinkedIn endorsements, which are worthless. Companies whose stamps mean anything will be the ones known for only handing them out for quality work. Being a hard, fair judge is an advantage for everyone.
\nWhere Do the Stamps Originate?
\nEvery rideshare platform already mints the kind of record we’re talking about here: star ratings, badges for this and that, rides completed, Grab and Uber have all of it. The one thing wrong with it is that it’s trapped on each platform and disappears if the driver leaves. The whole trick to reinventing talent assessment is letting the workers carry the assessments out the door.
\nI’m aware of some solutions evolving in this space, both commercial and open-source, and I’m excited to share more when I can. Candidly, I wanted to hand you a coherent solution today, and through a combination of running out of space, and Opus 4.8 being way too goddamn critical of everything all the time (jfc), I decided I’d hold it for now. We’ll all just have to start experimenting.
\nBut now you have the shape of it. Please, treat any prescription I’ve made here as a sketch. Mostly I just want you to come around on the diagnosis, and agree that we need to fix it properly for the first time in 50 years. Maybe you conclude that everyone has to require six-month co-ops. I don’t care. As long as it’s not more of the same. I just wanted to move the Overton window a bit.
\nPersonally, I think campfire is the most intellectually satisfying solution I’ve heard as a viable replacement for our aging interview infrastructure. Hope to see you at a campfire soon!
\nWhat is Gas City, you ask? It is Gas Town, but torn apart and rewritten from the ground up as an SDK for building your own dark factories. It enables you to deploy teams of collaborating agents in any topology, not just the hardwired original (and complex) Gas Town team shape.
\nGas City released version v1.0.0 this week. It went to alpha test a few weeks ago and is ready for use today!
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*ugMnDZOGGqghQtwvVv9XeA.jpeg\")
This is a pivotal moment in the Mad Max school of agent orchestration, a.k.a. Gaslandia, Gas Universe, Gas Nation, or the Gasosphere, depending on who you ask. It all began with Beads, which was like discovering oil. It continued with Gas Town, and we soon opened the Wasteland, a public commons board for federated work arbitrage and a budding private army. Gas City is the next step in that progression. I first predicted and described Gas City back in January, and it has finally arrived.
\nDisclaimer: I did not write Gas City. It was created by Julian Knutsen and Chris Sells, both of whom you can meet on the Discord. I am only lightly affiliated with the code, in the sense that I outlined my vision in a blog post, and they built it. But it’s exactly what I wished for, and it is being run by far more serious and disciplined engineers than me. I am all-in with Gas City, contributing myself, and this is our official new direction!
\nGas City has deconstructed the entire Gas Town stack into composable, declarative building blocks called “packs”. You can use these to assemble arbitrary agent topologies, deploy them, sit back, and watch them work from a rich console. (Or tmux, if that floats your boat. That still works in Gas City!) Gas City is the supervisor plane that connects, manages, and coordinates these deployed mini-factories.
\nAs its unboxing flex, Gas City comes with a fully functional “Gas Town” pack, which runs an exact replica of Gas Town. This is the default pack that runs on startup. So Gas City starts off as a drop-in replacement for the original Gas Town, and can import all your rigs and beads.
\nBoth systems are backed by the powerful and peerless MEOW stack. MEOW, the Molecular Expression of Work, is a lightweight Beads-based framework that places Work front and center, as the first-class system primitive, creating a versioned knowledge graph of all your issues and tasks. Work is the currency that drives the Gas Universe ecosystem. It’s Beads all the way down, powered at the base of the stack by a unique git-versioned database called Dolt. Dolt was the magic that made our stack run smoothly.
\n![\"\"](\"https://cdn-images-1.medium.com/max/896/1*GXgxqfbvv4fvLDMvOUh7zA.jpeg\")
Gas City solves an enormous number of problems associated with spinning up long-running agentic worker “teams.” It builds atop the innovations and community contributions from Gas Town, giving you out-of-the-box, scalable, convenient access to agent identity, messaging, history, context, state, skills, roles, personas, and much more. And for coding agent maintainers, Gas City exposes a rich Factory Worker API. It’s a way to make your own agent the driver for Gas City.
\nGas City is generally an improvement on Gas Town on all fronts, from code quality, to the services it offers. For instance it offers fine-grained model selection and switching at various levels, for cost control.
\nGas City doesn’t aim to solve all your problems. You will need to wire it to your own sandboxing, MCP servers, and so on. But it provides you with a rock-solid and easy-to-use foundation to build on: one with a Discord community with thousands of active members.
\nThis combination of tech stack and community makes Gas City, as far as I can tell, the only viable solution for building custom orchestrators backed by Git. You can build and run an entire business with it, tracking every step taken by any agent in a database with git version history. The forensics and auditing capabilities of Gas City are unparalleled, because of MEOW and Dolt.
\nWhat about maturity? Unlike Gas Town, which is an experiment run like a Wild West, Gas City is a rapidly maturing, enterprise-focused SDK for building and deploying autonomous agentic workflows. These deployments can be for anything: devops and monitoring jobs, ETLs, data pipelines, ticket queues, incident response, whatever you like.
\nGas City is completely open-sourced and MIT-licensed. Built for enterprise, fun for tinkerers.
\nThe rest of this post is about why you might want to try it yourself. This post is not about how to use Gas City; there is a ton of getting started material emerging, but a good start is the gastownhall.ai Discord general announcements.
\nThe Light Factory
\nEveryone is buzzing about “dark factories,” so let’s start there.
\nA dark factory is any system in which coding agents are set up to work autonomously without humans watching. The name is frankly a little bit misleading. It just means background work. It’s only dark inside a dark factory because the work is happening in rooms where there are no humans present. But those rooms are allowed to have windows. Observability is a choice in dark factory design.
\nGas City, like Gas Town, has chosen to maximize Observability. You can dive in and interact with any worker at any time, and nothing is ever hidden from you, nor from the agents, except for the guardrails you choose to install.
\nSo then is Claude Code a dark factory? The terminology here, with factories and harnesses and so on, is all evolving fast, so there aren’t any reliable definitions yet. But Claude Code did not start life as a dark factory, because you were generally supposed to watch it while it works. It’s making overtures in that direction with subagents and agent teams, but they keep the lights off intentionally, presumably because it’s a consumer-facing product and it keeps it simpler.
\nGas City takes a different approach: all agent workers are equally visible and addressable. The lights are on. Normally for the ephemeral “polecat” workers, you don’t bother looking at them. But unlike with coding-agent subagents, if you want to talk to your polecats, you absolutely can.
\nAnd so far, Gas City is the only dark factory that has been designed with the goal of creating other factories. The lights are 100% on when you’re working with the Mayor and Crew in Gas City, and you can dial them up as needed in the back rooms with the polecats and dogs. For this reason I have begun to think of Gas City as a Light Factory… or at least, a very well-lit dark one!
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*8-hYkilxtT7SKwJfRY-odQ.jpeg\")
At first, dark factories were only used for writing code faster. They focused on the software development process, and basically replaced IDEs. And that’s still primarily how they are used today. I do see some shops making good headway into CI/CD pipelines and peripheral business processes. But dark factories are headed towards handling infrastructure, operations, and even core business processes.
\nGas Town users soon realized that you could use Gas Town’s stack to create standalone orchestrators that had nothing to do with writing code. Gene Kim and I have talked to companies that are doing this, and I’ve also started myself. Running my online game Wyvern requires a bunch of routine maintenance that goes way beyond CI/CD.
\nFor instance, when players in my game hit 25th level, a unique perk is they can upload custom images for that character. That perk is permanent operational debt that I’m saddled with. I have to monitor the “Hall of Fame” submission queue, visually scan the player-uploaded images for inappropriateness, and then approve and upload them into the game. I’ve automated much of it, but I still have to look at them and run the scripts to approve or reject.
\nA dark factory could totally do that. And it’s got nothing to do with writing code. It’s a business process.
\nSo dark factories are a much broader concept than IDEs. They can automate and orchestrate any arbitrary process. But with what reliability?
\nWell, that depends on how robust your custom factories are, doesn’t it?
\nThe Shape of Things to Come
\nIn the very near future, devs will become shepherds, tending flocks of agents which do the ground-level work. It’s not really a manager job, because the workers are not humans; a coding agent’s cat doesn’t get sick and need to go to the vet in the middle of a sev-1 outage. But agentic workers do make human-like mistakes, and they respond well to being managed like people, by and large. They don’t need management. But they need guidance. Shepherding. Keeping-on-rails. That’s the new role for human builders and operators.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*PlXGD_eYtYufEXWUqTm5aQ.jpeg\")
As soon as I had this realization, the shepherd thing, I knew we’d discovered at least 2–3 new squares in my now-infamous “8 Stages of AI Adoption” diagram from Welcome to Gas Town:
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*o55_sML8whpdfDK1hD6qwg.jpeg\")
At Level 8, you have mastered using an orchestrator to manage dozens of concurrent agents. As your experience grows, you begin to see the potential to use agent mini-factories everywhere.
\nAfter you deploy your first real one, you officially have a garden you’re tending. A tiny crew of agents, acting like employees. Your little factory team runs 24x7, which requires maintenance. You now have to keep it running, manage upgrades and patches, rotate the logs, and of course make sure it’s doing its job. But you don’t have to do the work yourself anymore! So it’s still a huge automation improvement… as long as you can keep it reliable.
\nYou should almost never deploy a single-agent pack for a real business process. The reality is that any agent can go temporarily insane, at any time, and make a bad call. No matter how smart they are. We know now that hallucinations and false memories and forgetting are baked mathematically into all memory systems; there’s no avoiding it. So you should never just have one coding agent managing a piece of infrastructure. Not even for a low-stakes part of your business. You should always have at least two or three working together on a little crew.
\nThis is exactly why dark factories are so attractive. With Gas City you can build any sort of adversarial group structure you like, for a team of collaborating agents. They can watch over each other. By catching each other’s mistakes, the agent group reaches a far more reliable consensus and outcomes than you can get from a single agent. That’s why we think of deployed orchestration as being fundamentally made of multi-agent teams: factories. Define your pack, deploy it, et voila — you are officially on the path to being an AI-native shop.
\nOrchestration-maxxing
\nLet’s look at what a specific small custom factory looks like in practice.
\nFor my game’s player custom-image uploader, images are submitted via a website form, so it starts with an agent that wakes up on a hook and does the work. Then a second agent checks the first agent’s work. Perhaps the first agent makes a recommendation, and the second agent takes action.
\nI could add more agents to that pack, but I think two should be enough for this little workflow. It’s super low volume, low-stakes, not the end of the world if the agent crew messes up and approves a bad image. Adding that second agent, much like a second hash function, dramatically decreases the chance of some sort of collision. So in my pack, I declare the two agents, their identities, prompts, sandboxes, skills, and all the other stuff they need. Gas City can help you do this automatically, of course.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*06pNV96zX1_y03WM77gr9w.jpeg\")
A deployed Gas City pack is an AI-native business process automation. Once your pack is running, Gas City’s supervisor agent system will keep it going, even on remote machines.
\nAt this point, with one deployment, you are officially at Level 9 on the AI Adoption Chart.
\nAfter you make your first one, you realize you want to use dark factories for everything. I want every damn NPC in my actual game to be an agent, yeah? Not first, obviously! I’ll have to build up to that gradually, just like you should, when you first start with AI factories. Pick low-stakes, easy wins, get them automated, and learn your lessons early on when getting burned isn’t so bad.
\nLevel 10 of the AI Adoption is where you’ve deployed a bunch of agent packs, each with its own little world it’s managing. They have identities, consoles, you can check in on any of them, tweak their standing orders, you name it. They’re starting to be a handful. But you don’t need to build an orchestrator for them, since Gas City is the orchestrator. What exactly are you missing?
\nThe problem is, in stage 10, you, the human, are the control plane. Once you have a few dozen of these deployed packs, you will start to become the bottleneck on curating them. Gas City manages them, and they’re all functioning correctly on their own, but how are they working together as an end-to-end system? They can all send messages to each other, but have you given them clear, practical guidance on when it’s appropriate to do so?
\nThe answer to all your problems at Stage 10 is of course to slather on more Gas City. You build yet another crew, with a declarative Gas City pack, and its job is to manage a subset of your deployed packs. Maybe you spin up a couple of them, one for the cloud services, one for customer service. Area manager teams, basically. You evolve it into the shape of your problem.
\nOnce you start building your way out of needing to hand-manage dozens of packs, you’ve officially graduated to Level 11, which is Factory Builder. You’re building a full custom orchestrator, a full dark factory, and you’re operating at the level of architect, curator, and shepherd.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*lVrdJo8E8v_bDLdCy1e84g.jpeg\")
Your Gas City is the sum of those little factories you’ve created to run your business around the clock. No sick cats, no vets. Just the occasional wild worker hallucination. But your teams, if you build them right, will catch most mistakes. And all of it will be logged and auditable.
\nReliability, friends, is a dial. You choose where to set it. More rounds of review, more backstops, more guardrails, more judges, and you can get agentic workers to be as reliable as you need them to be, at least up to some practical ceiling. I wouldn’t use it in situations where you could physically hurt people, e.g. in medical or navigation systems. Not in 2026. But we’ll build our way there, like engineers do, over the next couple of years.
\nThat’s the new world. If you’re convinced already, then you’re done! You can just go play with Gas City. I’ll finish up by talking about how you can use Gas City to start chipping away at your SaaS problem.
\nEscape From SaaS Mountain
\nWhen I was a kid, my parents wouldn’t let me watch Escape From Witch Mountain (1975) for whatever dumb reason. Probably because it had “Witch” in the title and I was six. I’m still miffed about it, though. Who knows how much better-prepared I’d be for life if I’d watched it?
\nAnd now, I wonder, are investors and boardrooms watching Escape from SaaS Mountain? Or are their moms not letting them, too? Perhaps we’ll never know.
\nSaaS is in kind of a funny position right now. If you look at the pyramid from the top, at the SalesForces of the world, it looks like they’re fine, they just need to pivot to make their SaaS sexy to agents. Benioff did that recently with SF, exposing the whole platform headless and API-first, in exactly that: a bid to make SalesForce sexy to agents. That’s the new game for SaaS.
\nPeople look up there and say, oh it’s gonna be just fine, those are systems of record, nobody’s going to reimplement them. Nobody wants to pay the tax of maintaining those systems for security, compliance, performance, scalability, etc. Right? This is just the new Buy vs Build.
\nBut then you look at the bottom of the SaaS pyramid and it’s like, oh crap, this stuff is disintegrating in real time. Just in this past month I was visiting an enterprise customer where the non-technical staff — non-technical! — have been rebuilding a $30k/year SaaS tool in-house on Gas Town. Their VP is now mapping out how to convert millions in annual SaaS spend into headcount, bringing those capabilities in-house as core competencies. The question they asked us was: how do we actually do this at scale?
\nFrom that perspective, it’s clear that some SaaS will be eaten, and the rest will have to pivot. The only question is how far up the pyramid people will be able to push, bringing it in-house. It’s going to take a few years to find out.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*gZLRwEoeXo12y4je1GO74Q.jpeg\")
I’m going to share some stuff with you that will potentially change the way you think about SaaS forever. Much of it is credit to Brendan Hopper, Commonwealth Bank of Australia.
\nAtlassian, nominally, is an Australian company: a poster child for what the Aussies can accomplish when they put their mind to tech. But according to Brendan, it’s more complex than Australian versus American. Atlassian is staffed between the two continents, registered in Delaware, and traded on the NASDAQ — the ASX does not price tech companies as tech companies. About half their devs are U.S.-based, and they have strong incentives to have engineers in the U.S, such as tax code 174A. They serve pretty much all traffic out of the U.S.
\nFor all practical purposes, and through no fault of their own, Atlassian is a U.S. company. Much love to Atlassian, but they have to be, because there is no other option. The center of gravity on the U.S. west coast is inescapable.
\nEvery dollar of SaaS spent outside the U.S. has a portion extracted from a local economy and moved into California’s economy, which would now be the fourth largest economy in the world if it were a separate country. SaaS is moves money from the rest of the world into the U.S. And there’s no fighting it. If a big non-US tech company like Atlassian can’t, it’s going to be hard for everyone.
\nAnother interesting thing about SaaS is that it grows to become the superset of all the features for all its customers. Most customers gradually recede to using 20% of the SaaS’s features, while subsidizing the remaining 80% for the other customers.
\nThe implication is that you don’t need to reimplement all of SalesForce, just the parts you’re using. If you want to bring SaaS in-house, you only need to build the 20% of the features you need. And you also only need as much security, scaling, and compliance as is appropriate for your company, which is not necessarily the same as you need for a Fortune 100 company.
\nSo SaaS is extractive, and expensive. Almost nobody is getting full value out of it, and all that value is streaming into Silicon Valley.
\nYet another funny thing about SaaS is that the Venn diagram overlap with your own needs is always incomplete. Not only are you subsidizing features you won’t use, you’re also failing to get features that you would use. And when SaaS becomes dominant it stops innovating.
\nIn short, SaaS began life as a way for everyone to get savings through specialization and economy of scale. And it has evolved into an extraction machine that’s ideal for almost nobody.
\nSo you shouldn’t feel bad about de-SaaSing your company. Just start at the bottom.
\nThe bottom of the SaaS pyramid is a rowdy place, a rough place. A lot of it isn’t even SaaS, it’s software on disks in a closet that someone is paying an annual license for. Construction, paralegal, medical, farming, biotech, environmental, there are hundreds of domains where ancient SaaS is still holding companies hostage, and not meeting people’s needs.
\nSo the people are fighting back! As the models and tools get more powerful, people are beginning to bring their SaaS back in house. I hear VPs of Eng say, “We are spending $X million/year on SaaS. Let’s convert that to salaries and bring it in as a core competency.”
\nBut until this week, there hasn’t been a viable path forward, aside from experimenting with building your own orchestration on raw coding agents. That is a long journey, and most people need help with it. Most of the orchestrator vendors out there are off building agent brains and persona libraries — interesting research projects, but not what you need to replace a piece of SaaS in production. To replace SaaS, you need the unglamorous stuff: declarative deploys, audit trails, version history, identity, and a memory layer that survives the inevitable agent failures. Those are the primitives that make in-housing tractable.
\nEnter Gas City: The ultimate de-SaaSer. It’s like de-lousing your company. It makes Build and Maintain a pragmatic choice, particularly at the bottom end of the pyramid. You build the replacement software, then set up agent teams to run it for you.
\nA small team of three to five human engineers running Gas City packs can credibly replace seven-figure SaaS bills, and the capability stays in-house as a compounding asset instead of leaking out as recurring rent. Yes, you own the uptime, security, and compliance now. But you only need the level of each that fits your company — not Salesforce-grade everything for a 200-person business. And Gas City’s audit trail, with every agent action recorded in a git-versioned Dolt database, is frankly better than what most SaaS vendors can produce when you ask for theirs. That’s your SOC2 story, sitting right there in the database, already written.
\nThat’s the problem with OSS SaaS replacements today, and it’s why few have adopted them: they don’t run themselves. ChatWoot is a full-featured ZenDesk replacement, but you have to run it, and most companies can’t afford the operational overhead. SaaS has to evolve to be AI-native! It’s not good enough to be OSS. It has to have agents in it, running it, just like ZenDesk the SaaS handles everything for you as a service.
\nThis implies that all SaaS worldwide needs to be rewritten/reenvisioned from the ground up to be fully agentic.
\nBut where do you start?
\nThat’s where Gas City gives you a refreshing leg up. You can start building bespoke Gas City orchestrators today. You’re not going to rewrite your business overnight. In fact it’s going to take years. You should approach the whole endeavor with appropriate levels of caution and even trepidation.
\nBut you might as well start eating the elephant a bite at a time.
\nNext Up For Gaslandia
\nI had a set of projects in flight that were banking on at least Mythos-class models, which means they’re all on hold. Gas City will be the extent of my ambitions for a while. I plan to become a Gas City power user, not just for coding, but for running my own systems. I want to see that control plane emerge and understand how you can run a business with hundreds of collaborating agents.
\nMost other orchestrators I’ve seen have been able to be super high-ambition. Many lean heavily into the idea that agents, when put together, can just figure stuff out. And to a large extent, they can. But they are intentionally low-control systems. And when they fail, they go off-rails with no audit trail.
\nGas City is a high-control system. It has high parallelism (Julian has had hundreds of concurrent workers in a city), but it uses structure to keep agent swarms organized. It’s still incredibly flexible and freeform when it needs to be; you can just tell a group of polecats to go solve any problem. But most work is spelled out, tracked, and governed carefully.
\nA key concept in MEOW is the formula — a reusable template for a unit of work. You write a formula once for a recurring workflow (triage an incident, review a player-uploaded image, rotate the logs, run the nightly ETL) and then pour it whenever you need that work done, instantiating a fresh molecule of beads that an agent crew can pick up and execute.
\nOver time, your library of formulas becomes a declarative inventory of every business process you’ve ever automated — version-controlled in Dolt, composable, and forkable by anyone on your team. That’s how Gas City turns undocumented workflow knowledge into a durable, shareable codebase.
\nWhen you express all your work in the MEOW stack, as Beads and Epics (typically harvested from an upstream system like Obsidian), and your agent actions are all recorded in both a database and version history, you wind up with infinitely more control over the outcomes.
\nIn enterprises, controlling the outcomes is the holy grail. So I personally wouldn’t use any other orchestrator I’ve seen. They don’t have the federatable, versioned, queryable memory system that Dolt provides. They don’t have MEOW.
\nEveryone is suffering from tool overload. There are too many tools out there, and nobody can keep up with all of them. My life is so simple in comparison. I never look deeply at any new technology until it reaches a pretty loud public signal threshold. And I almost never have to, because the Gas Town ecosystem has solved so many of my problems.
\nThe Gas Universe in general is a pretty reliable bet at this point. It integrates with everything. Beads has been out for six months, Gas Town for four months, and the Wasteland for two. And Dolt has been around for at least eight years, with enterprise-grade maturity. We’ve got over two thousand members on the Discord. The community has spoken: This is The Way. People love working with this system, despite its occasional quirks and frustrations. It’s more fun than anything else we know.
\nShould you switch from Gas Town to Gas City? Yes! Gas City aims to be better in every way. And Gas City hit 1.0 today, so you should be good to go. Make sure to complain loudly on the Discord if it’s not working for you! Help will be on the way.
\nDo you have to switch to Gas City? Nope, we have some new maintainers onboarding onto Gas Town this week to help with the load. We’re going to continue maintaining the O.G. Gas Town as long as people still need it.
\nSee you all on the Discord at gastownhall.ai.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*ux-45f5SVQ8k70vgH_xGkA.jpeg\")
TL;DR: Gas Town and Beads have both released version 1.0.0 today. Enjoy!
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*lahvtXYL-5ebP3gOf8ovpA.jpeg\")
It has been a wild 3-month ride since I launched Gas Town.
\nFirst there was the part where I was like nooo don’t use it, and everyone was like, hold my beer. I am so glad some of you ignored me so hard. It’s just what I’d hoped for. You early adopters helped pave the way for everyone else.
\nAnd we went through some chaotic times early on. There were the serial killer sprees, viciously taking out random workers mid-job. (It’s always the Deacon, the modern-day Butler in the Gas Town murder mysteries.) There was the 22-nose Clown Show, where the Mayor scored a new clown nose every time it had massive data loss, which went on for weeks. And more. We’ve had our share of trying times, honking alert noses, piles of worker corpses. All long past us now.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*HqGMDjS1AjIPckGknFXFew.jpeg\")
Despite the early bumps, we’ve continued to enjoy absolutely massive community engagement. Even though Gas Town “only” has 13k stars (at 3 months!), it has hundreds of enthusiastic committers, and bugs get noticed and fixed fast.
\nIt’s safe to say that Gas Town has largely been in maintenance mode since the Dolt migration finished up, and that was well over a month ago. I’ve continued to allow a few nice features here and there, but for the most part we are now directing people’s creative efforts to the successor, Gas City, which is in alpha testing and on track for a fast GA.
\nAnd maintenance mode is a good thing! It means it’s not thrashing. Gas Town “just works.” It does its job, it has tons of integration points, and it has been stable for many weeks. People are using it to build real stuff.
\nAs one example, Gene Kim and I were chatting with a very cool midsize company, who are making a company-wide move to adopt agentic AI. A person in their Communications department, who is a Comms major four years out of school, shared with us (to our lasting astonishment) that she has been using Gas Town since “a few weeks after it came out.” She decided to build replacement for a niche but pricey SaaS product their company has been paying for. She’s working with another non-technologist on it, and it’s so good the company is getting ready to switch over to it. Amazing!
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*OkRXf1gc3ao2PpJ18H2yMg.jpeg\")
Non-technologists using Gas town to build software! It sounds crazy but I’m seeing it all over. People in academia, non-technical knowledge workers, even just people curious about vibe coding; all are figuring it out.
\nSo as far as I’m concerned, Gas Town is ready. That’s why I feel it merits a 1.0.0 release.
\nTo get started, you just have your coding agent install it, and talk to the Mayor. More on that below. The Mayor is cool. You’ll like the Mayor.
\nImportantly, we are also rolling Beads to version 1.0.0 today. Beads is the secret sauce that makes Gas Town and Gas City both possible and best-of-class. I’ll spend some time talking about Beads before we get back to Gas Town.
\nBeads: The Memory Revolution
\nLast year I noticed that agents were struggling with basic stuff: working memory, and simple task tracking. They had zero attention span and developed progressive dementia. That led me to create Beads, which is a drop-in, generic, unopinionated memory system and knowledge graph for coding agents. Beads gives your coding agent sudden clarity and long-horizon planning capability.
\nBeads started life back in October as a lightweight issue tracker with version control. But it quickly became clear that it was like Adderall for your agent. It is an instant cognitive upgrade for any coding agent, even replacing their built-in memory and task tracking systems with a system that’s more powerful, more portable, and every bit as transparent and easy to use. You don’t need to know Beads in order to use it; your agent handles it all.
\nOver time, it became clear that Beads was a sort of universal discovery, a gift that keeps giving. It’s way more than an issue tracker, and is evolving gradually into something more like a universal ledger for all knowledge work. One that agents happen to really, really like.
\nIt was a high-level insight from Chris Sells, an old friend of mine and (with Julian Knutsen) the co-creator of Gas City, that helped crystallize for me why Beads seems to solve so many problems at once: Beads is the Why.
\nBeads is the Missing Why
\nIn Beads, every work item becomes a bead. A bead is just a structure with some fields: a lightweight bug/issue report, with a title, description, status, etc. Beads are stored and versioned in Git, linked together as a multi-graph, and they are queryable with SQL like a database. Best of all worlds.
\nVersioning your Beads is critical: you get a complete historical log of every change to any Bead, trivial to query. So in multi-agent environments, everyone using Beads can tell what everyone else using Beads did, and why.
\nYour project’s Git commit history has always been your permanent ledger that contains the What, Where, Who, and How of what happened to your code. But as Chris Sells astutely observed a few months back, Beads is the Why — the missing piece in your commit history. It completes the data-warehousing picture of your project needed (by agents) for forensics, recovery, onboarding, design, and more. Having this information handy is invaluable for agents when they are trying to reconstruct how we got where we are.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*pjAfmZ3VF22ZcY5Him2PvQ.jpeg\")
Individual beads capture and record all your work on the Git ledger, through its entire lifecycle, from planning/design, through implementation, and then they form the audit trail after the work is closed. This isn’t limited to development work, either; you can use it anything. Someone once told me they use Beads for their grocery shopping (which they do with an agent.)
\nA key insight was that you can use Beads for defining and tracking orchestration work, which is how Gas Town and Gas City operate. Beads string together into “molecules” that have deterministic steps to follow, for patrols, releases, etc. Every step an agent takes in a Beads-based workflow is recorded on a ledger. This acts like a save-game that you can roll back to, or at least use to see how you got where you are.
\nBeads is for Literally Everyone, and Everything
\nBeads is completely unaware of Gas Town (though Gas Town uses Beads as a dependency.) You can use Beads by itself and get a vastly improved agentic experience, no matter which coding agent you’re using. Unlike Gas Town, which only works with a handful of agents today, Beads works with anything and everything, as long as it’s roughly as smart as Claude Sonnet 3.5 was.
\nPeople who switch to Beads soon realize they can build their own workflows and orchestration using nothing but Beads. It’s an incredibly powerful and versatile data plane. Once you start storing stuff in Beads, you kind of want everything there. It doesn’t solve the memory problem by itself, but it certainly gives you a solid foundation for solving it your own way.
\nBeads crossed 20k stars on GitHub this week, a bit over 5 months since launch. I have not been much of a GitHub user for most of my career, so I didn’t appreciate how unusual 20k stars is until this week. Chris, Julian and I all guessed that roughly 10k-20k repos would be that popular. But we were way off. You can browse them all with a query. There are currently 1988 with more than 20k stars.
\nSo Beads is already in roughly the top 2000 GitHub repos, out of some 300 million. That’s pretty rarified air. But it makes sense. I mean, it just works. It’s soooo easy. You start using Beads, everything becomes a bead, and life with agents just starts getting easier.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*zK0kOxfc7Rc26_JwvVdeEQ.jpeg\")
Beads: Ready for v1
\nI held out on a v1.0.0 release for Beads for months because I had a feeling it would become clear when it’s ready for prime time. With the recent completion of Beads with Embedded Dolt by the amazing Dolt team, Beads is finally back to its Day Zero experience. We have managed to land on an architecture and implementation that serve all the key audiences:
\nMany of these audiences were poorly served by the original, janky Beads architecture of SQLite + JSONL + awkward syncing and tons of merge conflicts. When it did work, it was often last-write wins semantics with SQLite just taking “whatever” happened to win. Not exactly enterprise-grade building material.
\nAll that jank is gone. Torn out of the code base entirely. Beads is now backed with the power of Dolt, which itself sports an impressive 22k GH stars. The inherent fragility of the v0.x Beads architecture, with its bidirectional sync, 3-way merge, two sources of truth, race conditions, and tombstone hell — that’s all gone now. Dolt was designed to handle all this stuff gracefully. We got incredibly lucky that it exists at all.
\nNow that Beads is stable on Dolt, with both embedded and server-mode fully supported, v1.0.0 is the right call. I’ve moved the Beads repo into the gastownhall org (soon to be gascityhall), where we will continue to support Beads as a first-class standalone product for non-GT/GC users.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*ImuIDsWhZsp89beFpbyAcQ.jpeg\")
Gas Town: It’s That Dang Mayor
\nI want to chat a little more about what we’ve learned about Gas Town before we wrap.
\nOne of the reasons that people like Gas Town is that they don’t have to read as much, or even pay attention as closely. It’s more like DM’ing with a friend.
\nClaude Code makes you read. A lot. It doesn’t matter if you don’t like reading, or if this isn’t your native tongue, or if you’re busy, or tired. With coding agents, you’re gonna do some reading. Read read read read. It’s like a stevey post gone wild, running rampage, in every session. But make sure you don’t miss anything important!
\nI read just fine, and even I didn’t like doing all that reading. Most of it clearly could have been read by a model, saving me the trouble. I wanted something else, some other interface, but wasn’t sure what. I just didn’t want to have to read so much unnecessary cruft.
\nI spent a bunch of time building orchestrators last year, trying to get Claude to run Claude. At first, I was trying to achieve the elusive “visibility without reading” by chasing classic Observability. I was initially thinking that I wanted dashboards or activity feeds or some other visualization of my town’s workers. And some people still do like those, and they can be handy.
\nBut after a while I realized I just wanted someone to talk to, while the system was working. And perhaps, as occasion might demand, someone to yell at.
\nThe Mayor abstraction turned out to be perfect. Mayors are there to get yelled at. A Mayor isn’t so distant, like some higher-level governor or executive, to whom yelling seems like it will go unheard. A city mayor is ostensibly someone who has your local interests at heart, so the mayor is who you yell at first. It’s a social custom going back centuries. As one famous and rather wise U.S. mayor put it a week ago, if your constituents aren’t yelling at you, it’s because they aren’t around at all, and you don’t want that.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*THeSv1unbpZv-rK9pR_mZA.jpeg\")
With the Gas Town Mayor, you feel like you’re operating at a special level, a VIP, above all the workers. You are talking to someone important: the mayor of a factory the size of a town. You have access to someone with resources, someone who gets you, someone who appreciates how busy you are.
\nWorking with regular coding agents just doesn’t give you that special feeling. I’m not making this up; this is a pretty consistent report I get from the field, from people around the world, particularly nontechnical people. I truly think it comes down to the Mayor giving you less stuff to read.
\nClaude Code only has one way to tell you what’s going on, which is to tell you what’s going on. It babbles while it works. “Now I will run this awk script s@(*fj$&h(*!&*.* Now I will print 8 pages of recaps. Now I’m deleting your database. Now I’m printing more recaps, and running another script here is the code #$AWESR@#$.”
\nClaude Code is a wall of scrolling text. The harder it works, the scrollier it gets. Now imagine having 10 standard coding agents running. Any agent, could be Codex, whatever. Ten of them puking out text. And you have to sort through all their output to find the nuggets of actually interesting stuff you need to know about, like the part where they’re deleting the database.
\nThis is why people love Gas Town. The Mayor reads all that crap that the workers are printing. The Mayor knows your context, your hopes and dreams. The Mayor has an army of polecats it can whip up when it needs to. The Mayor has all these cool-sounding resources, like the Crew and Convoys and Dog patrols, that it can bring to bear on your problem. Just say the word, the Mayor’s on it for you.
\nClaude Code and some other agents are trying to turn themselves into dark factories, by running subagents, and providing their own task management, memory systems, etc. But so far, they’re all trying to do it with a product lens, no platform to speak of — a monolith. I’ve read some interesting blog posts about that approach, but safe to say I’m not a fan.
\nGas Town at least lets you talk to your agents as first class citizens, with externally visible identities; Gas City takes it further and decomposes the entire stack into a modular platform architecture.
\nIn short, what’s behind the Mayor also matters, and as soon as people start getting curious, today’s coding agents immediately disappoint. And believe you me, people are getting curious. And they’re finding their way to Gas Town.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*W9ieOK7cL5EH4nbGlL6P3A.jpeg\")
Ultimately the Mayor is doing way more than just saving you a bunch of reading. It is your personal concierge. If Claude Code is an Executive Assistant, then the Gas Town Mayor is more like your Chief of Staff, who manages a full team of capable EAs, all working for you behind the scenes.
\nI’ve been saying since last year that by the end of 2026, people will be mostly programming by talking to a face. There’s absolutely NO reason to type with the Mayor. You should be able to chat with them like a person. You’ll have a cartoon fox there onscreen, in costume, building and managing your production software, and showing you pretty status updates whenever you ask for one. This is the end state for IDEs.
\nOn to Gas City
\nAs I mentioned in my long-overdue Vibe Maintainer post, we’re going to start gently nudging everyone towards Gas City. You literally just install it, import your Gas Town configuration, and then you’re using that instead of Gas Town. It’s functionally identical, when used as a dev IDE.
\nExcept with Gas City, you can now build your own orchestrators using all the Gas Town primitives: identity, roles, messaging, mail, sessions, cost tracking, multi-model dispatch, skills, prompting and priming, hooks, GUPP, NDI, formulas, molecules, beads, epics, convoys, orders, patrols, plugins, tmux, seances, and more more more. It’s all there. You can mix and match to create arbitrarily simple or fancy orchestrators, with all their work logged to a beautiful set of git ledgers.
\nThere will be nothing like it. You are going to want to use Gas City. We will have some imitators, but I’m not worried. Ask your agent to dig into Dolt federation and have a look at our Wasteland, and you’ll quickly see why this is a superior way to do work.
\nI can’t begin to express my excitement about Gas City. It is all MIT-licensed, supported by a growing team of enthusiasts, and it is already starting to have legit hosting options for people who want to build orchestration in the cloud. I will have a detailed post about it when we get closer to GA, when it’s late beta and ready for wider adoption.
\nBut no need to wait. At a high level, Gas City is the answer to all your problems. Ha! At least, for certain classes of problem, such as, “How can I bring AI into my company and pass an audit trail,” “How can I rid myself of gougy niche SaaS by in-sourcing it all to AI,” and similar. I know you’re all thinking about it!
\nStay tuned. I have another blog post hot on this one’s heels. I’m giving some talks next week, one in NYC and one in San Jose, and I figured, why not just spill all my talk secrets in a public blog so that I have nothing interesting or new to add during my talks!
\nAnyway, that’s a wrap! Congrats to the Beads community for riding the wave to the 1.0 release and 20k stars, and for finally getting a solid embedded-Dolt experience. Thanks to the Dolt team and Dustin Brown for that! And congrats to everyone who has used Gas Town to do something cool. I couldn’t be happier!
\nFinally, a huge thank you to the core team who have all worked incredibly hard to bring you Gas Town, Gas City, the Wasteland, and much more to come. From left to right, skipping me the panda, there’s Matt Beane, Chris Sells, Julian Knutsen, Tim Sehn, and Brendan Hopper. We’ve got so much more in store for this ecosystem. Come join our Discord at gastownhall.ai!
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*GeVxwM147GYS0mngSGP6tg.jpeg\")
Some attendees at an AI Tinkerers meetup in early Feb were asking me what it’s like to be the maintainer of a big OSS project where the community PRs are all AI slop. They thought it would make for a good blog post. I thought so too, at the time!
\nIt turned out to be very, very, very hard to write down. It’s in many ways the opposite of conventional wisdom for software maintainers, OSS or otherwise. So this post has given me over 2 months of writer’s block. (I had to update that duration many times while writing this.)
\nWhy is it so important for me to tell you how I deal with a storm of AI-generated PRs? Because I’m beginning to believe that my “vibe maintainer” workflow, crazy as it might sound, will be what a lot of you are doing before long. Everyone who works on successful OSS will soon have to deal with PR storms.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*I2wQY3YLeLKg0-8xFrrDpg.png\")
To give you a sense of the scale I work at, I’m cruising towards 50 contributor PRs a day, combined between Beads (20k stars, 5 months old) and Gas Town (13k stars, 3 months old). That’s seven days a week; if I take a day or two off, they pile up and I may have to deal with 100 or more in a single day.
\nIt’s an enthusiastic community. We’ve had over 1000 unique contributors between the two repos, with over 4k PRs (2300+ merged), and over 15k commits, all in just a few months. And we have a great community with almost two thousand Gas Town users hanging out chatting on the Gas Town Hall Discord.
\nThrough all that, my median time to resolution is about 15 hours, with few PRs waiting more than a few days. This is high velocity. But I still manage to keep my quality bar high enough that both projects continue to exhibit strong growth. It may look like I’m only merging 60% of the PRs from the metrics, but that’s an artifact of fix-merging. I actually merge about 88% of all incoming contributor PRs, one way or another, and both projects are flourishing from it.
\nBeads in particular is well-integrated with the broader ecosystem — for instance, it now has solid integration with GitHub, GitLab, Linear, JIRA, Azure DevOps, Notion, and five self-hosted storage options. This is all encapsulated as a rich plugin interface for backend engines that each of them implement. Nearly all of that was from community contributions.
\nIt’s safe to say people love Beads and Gas Town, even though mostly only agents have ever seen their source code. I certainly haven’t. No time for field trips.
\nI’m a very lazy person, and maintaining a popular OSS repo, let alone two of them, would simply not have been possible for me, like ever, up until maybe a year ago. I’m getting by with AI, that’s the only way. As my PR volume has increased, I’ve been able to keep afloat through model and tool improvements, automating as much of the decision tree as I can.
\nEven with AI help, keeping up with community PRs takes me 15–20 hours a week, usually 2 to 3 hours a day. Sometimes much, much more.
\nI wish I could tell you it’s easy work. I have at least managed to automate all the easy stuff, which is about half the PRs, sometimes up to two thirds of them. I was recently inspired by Dane Poyzer’s gt-toolkit package — a series of Gas Town formulas he published, which now has its own little user subcommunity. Dane’s formulas help you run his ambitious long running idea-to-delivery workflow, which is geared at comprehensive feature development and moving through mountains of work with his Gas Towns. My own PR workflow is now a formula as well.
\nBefore we dive into the vibe maintainer workflow, let’s revisit why it’s needed at all. Am I not just bringing this on myself by allowing AI-assisted PRs in the first place?
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*68h9Fx9o2MmEJa_oxyXqiA.png\")
Since 99% of my incoming PR submissions are AI-generated, it stands to reason that I could reduce my workload by 99% by saying “No AI PRs.” In that world, instead of doing all this crazy vibe maintainer stuff, I’d just wake up every morning, brew some coffee, shake my fist at the sky, browse HN, and maybe take the mule to town. The easy life.
\nMost OSS maintainers go this route. They straight-up forbid AI-generated or even AI-assisted pull requests. And I can understand why. The crap you see in AI-generated PRs these days can turn you into the Clint Eastwood angry-porch meme, practically overnight. Rather than deal with it, they outlaw it.
\nThat of course triggers an arms race. You can get an AI-assisted PR accepted, but only if you sneak it in. So we hear comical stories of once-rejected PRs suddenly being accepted after they’re resubmitted with all the AI DNA scrubbed from the crime scene, hee hee haw haw.
\nBut that’s the official party line for most OSS projects today: “No AI.” It all has to be done by sneaking. The whole status quo in open-source is characterized by historic levels of silliness.
\nHere’s the problem with that old-school approach. We are headed toward a world in which if you refuse enough PRs, the community will consider you a dead-end street and begin routing around you. They will copy your software, either by forking it or rewriting it from the ground up, and use their own mutated version from then on. They might even develop a community around their version.
\nSoftware survival is now about velocity–specifically, keeping up with what your users want. Even a permissively-licensed OSS project can be forked and lose a ton of users and mindshare, if the project owners don’t listen to a sufficiently large subcommunity of their happy users.
\nAs just one of many easy examples, Roo Code is a big community that forked off Cline (a VS Code extension). And now people are forking Roo; Kilo is a huge one. That’s a sad list of at least three communities effectively fighting over a code base. They could have united, but none of them could keep up with what their own users wanted, so it keeps on forking.
\nThat particular fork family all happened before coding agents came into their own in late 2025. It was hard back then. Now that everyone on earth has access to powerful coding agents, we will see way more forks. Forking used to be a declaration of war. Now it’s simply a declaration that someone liked your software enough to want to change it, but you said No.
\nIt’s always been trivial to create a fork. The hard part has always been maintaining the fork. As the fork’s community grows, so does the maintenance burden. It used to take a good-sized team to support a fork, which was almost like a rival gang. Nobody liked a fork. There was always bad blood. The XEmacs/Emacs rivalry was absolutely the stuff of legend. You wouldn’t believe some of it. It used to basically require corporate backing to have a credible fork of a large OSS project.
\nToday, things are astoundingly different. With the coding agents of 2026, everyone who loves your software is a credible threat to forking you. Any grandma who wants to use your software for gardening could build a massive grandma subcommunity with your stuff if you don’t take her PRs. She might not even know she’s done it. It’s just there for the taking, and you weren’t flexible enough. So her agent routed around you.
\nThere’s nothing wrong with forks per se; that’s how evolution will happen. But it’s also a ton of duplication that might not have been necessary. A lot of people just want to add a small feature or fix to an existing software product, not clone the whole damn thing and maintain it for the rest of their lives. They want to share tokens and energy by pooling features and fixes together, as a community. So there are good reasons to avoid forking.
\nI do actively encourage forks where people are trying to take the code in a direction I just can’t follow. The earliest big fork was beads_rust from Jeffrey Emanuel, who told me he was very embarrassed to be forking my code, until we chatted about it and I gave it my heartfelt blessing.
\nThis was a situation where he wanted only the streamlined original code’s behavior. Nothing else. And that’s one thing I couldn’t offer with my kitchen-sink approach to making my tool community- and AI-friendly. So I was happy he made that fork for those who need that streamlining.
\nIf your software is popular, and you want to avoid forking (or rewriting), you need to build and foster your community. You need to let your system expand to accommodate the needs of as many users as practical.
\nPeople will ask more and more of your software, so you also have to decide where to draw your lines. You choose what belongs in your code, and what to exclude–any of which may go off to live in a fork somewhere to “compete” with you. Choose wisely!
\nMy own approach is radically different from how most OSS maintainers work: I say Yes to AI. Instead of rejecting AI submissions, I encourage everyone to use AI to submit their PRs (subject to a growing list of hygiene rules). Indeed, I both observe and expect 99% of incoming PRs to be AI-assisted.
\nWhy? Because this empowers my users to turn their wishes into code and get it into the system. It keeps them from thinking about off-ramps. It keeps them from forking me, and unites them into a larger community, which means they all benefit from sharing rather than reimplementing. It’s a net token savings, so software with strong communities will tend to survive.
\nDo some contributor PRs belong in a fork? Absolutely! I maintain high standards for what goes into the Beads and Gas Town core. I’ll reject PRs for many reasons, including being too opinionated, niche, or they don’t pull their tech-debt weight.
\nBut if there’s a germ of a good idea in there, I try hard to find it and cultivate it.
\nInstead of requiring perfect PRs from everyone, I aim to find a quick resolution that is satisfying to all parties. I accept most PRs, but still maintain hard lines on architecture, what goes in core, code quality, and many other AI-era design principles (e.g. ZFC). If I were to send every PR back to the contributor for fixes, the rest of the community might be losing out on some important fix or feature for days to weeks. And there it is, sitting there in the PR; it just has issues with it.
\nIn this situation, if you want to maximize throughput, then you may need to fix the contributor’s code yourself before it can be merged. Most OSS maintainers say, “Go fix your code.” I try my best to fix it myself and get it merged. There’s an art to this that I’ll discuss below.
\nMy core philosophy is, help contributors get to the finish line. I optimize for community throughput. I review every PR and try to find the value in it, and have my worker agents do something appropriate for each one.
\nMy sheriff workflow consists of runs, where I try to resolve all PRs in a run, though I’m not always able. A run kicks off automatically every time I restart my designated sheriff crew members in my Gas Town, because I place a “sheriff bead” on their hook. So they notice it when they wake up. I can also start runs manually.
\nI discovered today, after many months of using this workflow with my Gas Town crew members, that the Mayor is actually way better at it. Like, far, far better, it’s crazy how much better it is. The Mayor, acting as PR Sheriff, takes a more holistic view, makes better decisions, and makes better use of Gas Town resources to get the PRs reviewed, fix-merged, and escalated in parallel.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*ql0MLTtr8X_HVmEgd3eVCw.png\")
This was big news. It means I can shrink my Gas Town crew down to maybe 3 agents per rig (from 8 apiece), which will be huge for memory pressure. Huge for running it in parallel with Gas City while I cut over. More on that later.
\nAnyway, the workflow begins with the sheriff pulling descriptions of all open PRs, and categorizing them into easy-wins, fix-merge, and needs-review.
\nEasy wins are things like targeted bug fixes, doc updates, dependency bot auto-upgrades, and automatically closing drafts, PRs from banned contributors, etc. These are handled automatically every 2 hours with a patrol, which contributes to my sub-day median turnaround time. And they’re handled automatically during a PR sheriff run.
\nThe first fix-merge candidates are easy wins that are broken for some reason — they fail CI, they need a rebase, or they have a simple error in them, but aside from that, they fit all the easy-win criteria. The sheriff may decide to auto-fix-merge those. My Mayor decided to sling them to polecats, which was nice.
\nNeeds-review is any PR that looks kind of suspicious for some reason, so we’re going to have to have an agent suss it out, do a deep dive, and produce a report. These can be farmed to crew members or polecats, as the instructions are usually pretty simple. The reports can be handled however you like, e.g. having the sheriff summarize them for you. Or I sometimes go directly to the agents’ tmux sessions and read their reports.
\nFrom needs-review, we get a set of possible recommendations:
\nThere are a few other possible outcomes, such as re-routing the PR to the right project, banning the contributor, etc. But this is a pretty good starter list.
\n![\"\"](\"https://cdn-images-1.medium.com/max/896/1*blMOCwE3Kfpl23I5lvuexg.png\")
Notice that the first resort for almost every OSS maintainer, which is to send your PR back requesting changes, is the last resort in my vibe maintainer workflow. It ranks even lower than rejection, which itself is very serious, because rejection can lead to forking. And it’s cumulative. The more PRs you reject, the higher the chance of someone getting fed up with you.
\nRequesting changes is the last resort because is quickly leads to contributor starvation; if you keep making them rebase it, the sheer velocity of the project can prevent their PR from landing for weeks, until you take steps to help it along. So you might as well help it right from the start. Don’t send it back for changes.
\nIf there is good in the PR, then you should absorb that good into your code base, right there and then, rejecting anything you don’t like, and transforming the parts you’re absorbing. You can make bug fixes, architectural fixes, change the naming, make it a plugin, mix and match.
\nMost of the time, it’s Claude telling you, hey, this PR is mostly healthy but it’s missing a kidney, and you say, please add the kidney.
\nBut sometimes, Claude looks at PR that adds a face-hugging alien to each worker, and it sizes it up, and says, “This PR is well-constructed, and the alien is robustly hugged to each worker’s face, with good test coverage and updates to all relevant work formulas.”
\nAnd you say, Claude, it’s a fucking face-hugging alien. And Claude says, oh right, that’s a very good point, we probably don’t want that, shall I close it with a polite note?
\nAnd that’s why the last 25% or so of pull requests need human review. At least, so far. It’s because there’s still a thing called taste that current models can’t be trusted with. Not yet.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*A1aQLmM--AuIPtxoRKrNbg.png\")
I’ve instituted some lightweight hygiene rules for contributors. I don’t enforce them yet, and I’ve only announced them in a few places. I’m working to get them baked into the CONTRIBUTOR.md files and other important locations.
\nHere are some examples of hygiene rules for my repos:
\nRight now, my policy is to fix all these things, and just complain about them when I close the PR. As the models get smarter, more of this can be handled automatically. But in general, I think people who abuse it might start getting banned, since they’re basically pushing their QA for their PRs (and associated costs for fixing them) onto me.
\nThat’s a pretty good overview of the PR workflow. I know I said it was hard to write down. It was, dammit.
\nWhen you get down to the last 5–10% of the PRs, they’re usually hefty features, and you may need to spend a lot of time digging into them and figuring out whether you really want to pull them in. You may ask the agent a ton of questions about each PR, ask it to consider alternatives, or just tell it you don’t see the point. If the agent can’t justify the PR, then it’s probably not worth taking yet.
\nBut that last 5% to 10% is the part that takes hours a day. There’s always a list of PRs that are just right on the edge and need my judgment call, though I wish it weren’t so. It is definitely getting easier now that Gas Town is becoming essentially feature-complete, due to the launch of Gas City. So I auto-close any large features and redirect the contributors to Gas City.
\nSumming it all up, being a vibe maintainer means trying to absorb the good parts from every PR, and there are various techniques for approaching it, depending on what’s wrong with the PR. It means only rejecting PRs with no alternative as a last resort, since each rejection increases the chances that someone’s going to fork you.
\nMost of all, it means helping contributors get to the finish line, with attribution, in whatever way you deem best for your projects and repos. Maximize community throughput, and you’ll have a happy and thriving community. In fact, I’m pleased to report that Beads crossed from 19.9k to 20k stars on GitHub as I was finishing this draft tonight.
\nMy main success metric is whether my users are happy, and so far it’s looking pretty good!
\nGas City went to alpha last week, and aims to be generally available later in April. What’s Gas City, you ask?
\nGas City is a ground-up rewrite of Gas Town from first principles, using the MEOW stack (i.e., Beads and Dolt, the fundamental substrate of Gas Town.) It is almost a perfect proper superset of Gas Town’s features, and can be used as a drop-in replacement for Gas Town — except Gas City is also an orchestrator-builder.
\nGas Town is a “pack” within Gas City, a fully declarative bundle of prompts and skills, no code at all — it still has the iconic original Mayor, Deacon, Dogs, Polecats, Witness, Refinery, and Crew, with their various hooks, inboxes, skills, prompts, and sandboxes. But there’s no dedicated code — unlike in the OG Gas Town, which is a large kitchen-sink binary.
\nGas City was built by my buddies Julian Knutsen and Chris Sells, and as far as I can tell, it is exactly what I envisioned and outlined to them when they first suggested tackling it. They did a bang-up job. So good that Gas Town itself, the binary, is I think not long for this earth. Only its shape, the original characters, and all the individual features we loved about Gas Town remain — all available as LEGO-like pieces for creating your own agent orchestration shapes.
\nBeads, the original, powered fully by Dolt (Git for structured data), will live on as version 1.0. The MEOW stack from Gas Town, including formulas, molecules, hooks, the GUPP engine, and Nondeterministic Idempotence (NDI) are all implemented in Beads and Dolt. That means that all work is decomposed into durable, version-controlled, SQL-queryable orchestration steps.
\nThat’s all stuff that your orchestrator doesn’t have, especially if you’re using something Claw-based…unless you’re also using Beads, or else you reimplemented the whole damn MEOW stack, including Dolt, which would just be incredibly foolish of you.
\nI think the MEOW stack and Dolt give both Gas Town and Gas City a gargantuan advantage over anyone using postgres and snapshots, or git-lfs, or really anything other than Dolt or Datomic for their agentic memory system. If you’re using Datomic, bravo. You’ve got a nice system with everything agents need for world-class forensics and mistake-recovery in production. I just prefer Dolt because it uses Git as its protocol. Both are great.
\nIf you think of Gas Town as a Dark Factory (it is!), then Gas City is a Dark Factory Factory. I am putting my money where my mouth is, and diving in to start orchestrating my own game’s production systems using Gas City as my new SREs. I want to live this a bit before I evangelize it further.
\nStay tuned for several upcoming announcements and new blog posts from me. I’ve been sitting on quite a backlog while I was trying to squeeze this one out. Unnnggghhh. I’ve got a post about dark factories coming up, including some insights into how to make a coding agent into the perfect dark factory worker — something I think coding agents will all need soon just to survive. But as a dark factory user, I’m biased, so who knows.
\nI’ve mentioned the Wasteland, and there’s more coming there. There has been a bunch of work behind the scenes, and it’s an important building block. Our two thousand Discord users are basically an army. We’re sitting on that army and it’s restless. I’m headed to Portland in the morning for a meeting of our generals, called by Chris Sells, and one of the topics for discussion is how best to put that army to use. Fun times.
\nI’ve also got upcoming announcements about Gas Town and Beads, both of which are headed to v1.0 very soon. And a blog post in the form of a totally untrue made-up fantasy-horror campfire story about a fake monster called the SaaS-Eater, whose wings shall beat a mighty Saas Hurricane, whose wind will de-SaaS companies and save them millions of storytale coins, which is all of course utter hogwash, merely an amusing fiction for scaring small children and investors and the general public. But I’m a horror fan, so we’ll see. Maybe an army could beat it. Or create it. Now that my Vibe Maintainer post is out, I can finally get to that blog backlog, and try my hand at some proper fiction.
\nSee you next time. And to all of you who, one way or another, manage to read everything I write — thank you! When I hear those stories it really does help with the writer’s block. I hope you’re all having fun with agents and orchestrators. I’m absolutely having the time of my life. More posts coming soon!
\nDon’t forget to come visit our Discord at gastownhall.ai!
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*hXB6bXlCKTkkmhmp1RbHuQ.png\")
Howdy partner, and welcome to the Wasteland!
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*QhO5CUFb3DX8SDyFp5kWKA.jpeg\")
What the heck is the Wasteland?
\nThe Wasteland has been the inevitable next step for Gas Town since the day I launched it. Every new AI tooling form-factor breakthrough has involved 100x increase in token spend. How do you 100x a Gas Town? You federate a hundred Gas Town users together to build stuff.
\nThe Wasteland is a way to link thousands of Gas Towns together in a trust network, to build stuff really, really fast. So fast that your biggest problem will be ideas.
\nAt the heart of the Wasteland is a big shared Wanted Board of work. People put up ideas, and other people use their Gas Towns to help build those ideas. And you get credit for the work you do.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*MhRzJGrBbFixmbUW6GeBvg.png\")
The Wasteland has a lot of moving parts. There are stamps. There are leaderboards. There are character sheets. The Wasteland was designed for federating work, but its metamorphosis into an RPG seems unstoppable at this point. You’ve seen the gaming interfaces people have already put on Gas Town, but with building blocks like this… it’s gonna be wild.
\nAt its core, the Wasteland runs on accepting work and stamping it. When deciding whether work gets accepted, the Wasteland uses a socio-technical protocol that the industry has battle-tested for over a decade: Git’s fork/merge push/pull model.
\nWhen someone accepts a PR in the Wasteland, they stamp the contributor’s passbook. The contributor gains some reputation, and it all goes onto a permanent ledger that could eventually act something like a portable C.V./résumé. Your work in the Wasteland levels up your skills in the system, which happen to correspond to real skills. And it’s all public, even (in time) the skills and stamps you will get from working on private repos, all subject to proper governance rules.
\nLike any RPG worth its salt, the Wasteland’s rule book is an inch thick. There’s so much to cover that we just can’t do it. So instead, I’ll handle this post in Q&A style, and try to get the main ideas across. The curious ones will figure the rest out.
\nLet’s get started!
\nWill I learn all about the Wasteland in this post?
\nNo.
\nWe need to keep it small at first, lest it get away from us. It’s going to grow monstrously fast. Nom nom, eating the world of work, led by humans, not lobsters.
\nTo keep it contained in the first couple weeks, the instructions in this post at the end are intentionally obtuse, accessible only to the most determined.
\nWe will make it easier in time.
\nWho is this “We” of whom you speak?
\nWell, we may not have a bunch of fancy venture capital, but we’ve got a pretty darn good volunteer team.
\nFor starters, we have a growing army of awesome contributors on the Discord, led by Dane Poyzer, and big shoutouts to Krystian Gebis for pushing on multi-model support, and to Pierre-Alexandre Entraygues for our Open Telemetry. But really, there are a ton of people there helping each other out and exploring PR ideas.
\nWe also have a growing army on GitHub, with over 450 unique PR contributors. Special shoutout to Matt Wilkie, a prolific Beads contributor and soon to be co-maintainer.
\nMy heartfelt thanks go out to everyone who ignored the First Two Rules of Gas Town, jumped in, and are helping make it great. I see you all and I appreciate you!
\nIn addition to our Gas Town and Beads contributors, I also want to recognize the world-class team that brought you the Wasteland today:
\nI am deeply grateful to these amazing people who have volunteered so much of their time, passion, and resources to bring this vision to life for you today.
\nIs Gas Town Ready?
\nYes. Let’s just get that out of the way up front.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*Tb_QoD3NulHadSZR7RJyxw.jpeg\")
I know I told you before that you were gonna die if you used Gas Town. That was true, two months ago. But since then:
\nIn short, it’s smooth sailing these days. I’ll have a lot more to say about Dolt and how amazing it is in a future post. But it feels like Dolt predicted the Wasteland, because there could not be a more perfect technology for it.
\nOnce your agent gets you past the setup, users report that the Gas Town experience is a pleasant surprise. Everyone likes working with the Mayor. Polecats make sense, convoys make sense, slinging makes sense… and most of the rest of the town’s operation is safely behind the scenes. It all just has a good vibe to it.
\nGoing from Claude Code to Gas Town elevates you from pair-programming into large-scale engineering leadership. It can grow with you. At first, it’s just you and the Mayor. Best buds. Later, you’ll be juggling conversations with 20-odd crew members while your Mayor is out slinging polecats at half a dozen epics at once.
\nAnd before long, you’ll wonder how you ever managed to get anything done without a personal army.
\nSo yeah. Gas Town is ready. Try it out! If you’ve used a coding agent, then you’re ready for Gas Town.
\nDo I actually need Gas Town for the Wasteland?
\nSo the funny thing is… no. All you need is Dolt, a free DoltHub credential, and a coding agent that knows the schema. With that alone, you can start submitting work in the Wasteland, getting your stamps, and moving up the leaderboards. I’ll show you at the end of the post.
\nWhy should you care about accumulating stamps? Because your stamp history is building toward something like a portable professional identity. Evidence-backed, auditable, and yours. It’s the beginning of a résumé you never have to write — one that proves what you can do.
\nThe entire Wasteland protocol is encapsulated in this demo Claude skill — a prompt package that teaches Claude Code a new workflow. Load the skill, and your agent knows how to join, browse, claim, and submit work in the Wasteland.
\nThat said, we recommend you use Gas Town, because it’s much more convenient.
\nWhy is the Wasteland any different from blah Blah BLAAAH?
\nI’m glad you asked. I’ll tell you in this section how the Wasteland works, at a high level, and you can decide for yourself the answer to your very intelligent question.
\nFirst off: I did warn you that the rule book for the Wasteland is an inch thick. In this section, you’re getting the eight-paragraph quick-start version. But you could drill deep on any of these topics. The Wasteland is designed to scale up eventually to all the world’s work; let’s take a look briefly at how.
\nThe Wasteland has three kinds of actors: rigs, posters, and validators. Every rig rolls up to a human participant. The AI side of the rig can be an agent, a Gas Town, or another orchestrator. Every rig has a handle, a trust level, and a history of work. Posters put work on the board. Validators attest to the quality of completed work. These aren’t fixed roles; any rig can post work, and any rig with sufficient trust can validate.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*M1aFdWMmmpTtuF1P4IauNw.jpeg\")
The central object is the wanted board. It’s a shared list of open work — tasks, bugs, features, research questions, documentation, designs, anything. Each item has a title, a description, an effort estimate, and some tags. Anyone can post to the board. There’s no approval gate: if you have work that needs doing, you post it.
\nThe lifecycle of a wanted item has four stages: open, claimed, in review, and completed. When a rig claims an item, it’s marked as theirs — other rigs can see who’s working on what, preventing duplicate effort. When the rig finishes the work, they submit a completion: a record that includes evidence of what was done (a link, a commit, a description). The item moves to “in review.” A validator — a rig with maintainer-level trust — reviews the evidence and issues a stamp. We also support open-bounty work where nobody claims it, multiple rigs can work on it in parallel, and as soon as someone submits a solution the validator likes, it’s closed.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*59ESI9ejpRwFUL0sOFHxdw.jpeg\")
The stamp is not a binary pass/fail. A stamp is a multi-dimensional attestation: quality, reliability, creativity, each scored independently. It includes a confidence level (how sure is the validator?) and a severity (is this a leaf task or a root architectural decision?). The stamp is anchored to the specific completion — the specific evidence — so reputation is always traceable back to real work. And there’s a yearbook rule: you can’t stamp your own work.
\nStamps accumulate into a portable reputation. Every stamp a rig receives becomes part of their permanent record. Over time, a rig builds a profile: they’re great at Go but mediocre at frontend. They’re highly reliable but not particularly creative. They crush small tasks but struggle with epics. This isn’t a single number, but a structured, evidence-backed work history. And because it’s stored in a versioned database, it’s auditable. Anyone can trace a rig’s reputation back through the chain of stamps to the original completions to the original wanted items.
\nTrust levels gate what you can do. A new rig starts as a registered participant (level 1). They can browse, claim, and submit completions. As their work is validated and stamps accumulate, they can be promoted to contributor (level 2), then maintainer (level 3). Maintainers can validate others’ work — they’re the ones issuing stamps. This creates a natural apprenticeship path: do good work, get stamped, eventually become someone who stamps others.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*jGna2py1zemuAN6Ocoysag.jpeg\")
Wastelands are federated, not centralized. Anyone can create their own wasteland — a team, a company, a university, an open source project. Each wasteland is a sovereign database with the same schema. Your rig identity is portable across wastelands: join the root commons, join Grab’s wasteland, join a university’s wasteland. Your stamps follow you. A rig that’s proven reliable in one wasteland carries that reputation into the next.
\nThe whole system is designed around one principle: work is the only input, and reputation is the only output. There’s no buying reputation, no gaming follower counts, no social signals disconnected from evidence. Every stamp points to a completion. Every completion points to a wanted item. The graph is fully traversable. And because the underlying storage is append-only and versioned, the history can’t be rewritten — your ledger is permanent.
\nAnd there’s a yearbook rule: you can’t stamp your own work. Your reputation is what others write about you, not what you claim about yourself. Think of it like a high school yearbook — you can sign other people’s pages, but you can’t sign your own. This is the fundamental difference between the Wasteland and LinkedIn. Nobody cares what you say about yourself. They care what the people who reviewed your work say about you.
\nWhat about cheating, you ask? We’ve thought about that, and consulted leading Trust & Safety experts. The stamp graph has a shape, and collusion rings have a distinctive topology — lots of mutual stamping, sharp boundaries, no outside critics. The Wasteland system is designed to make fraud unprofitable, not impossible. We’ll have more to say about this soon.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*-Twwh3Sb7bQ9d3t7iHKiuA.jpeg\")
Whew. OK, that was a lot. And honestly there’s a lot more to it. Some of it hasn’t even been fully fleshed out yet, like the personal/work identity — right now your identity is global across all Wastelands. And who owns the stamps. We have solutions; it’ll all get worked out. The important thing is to get people working together now, so we can see what patterns and anti-patterns emerge.
\nYou mentioned an RPG?
\nOh, right, the RPG, thanks for reminding me.
\n![\"\"](\"https://cdn-images-1.medium.com/max/896/1*IYNygkmkbHIdtvonyKYT8A.jpeg\")
You can start at gastownhall.ai, where you’ll see leaderboards and stuff. We built all this just over the last couple of days, since the past few weeks to months have been focused on getting the underlying protocols right. So it’s pretty bare-bones right now. But it will improve fast.
\nWe have the beginnings of profile pages for the Wasteland. We pre-seeded them with data from GitHub, from the top ~10k contributors by whatever metric Claude thought appropriate, which it turns out you can get through GitHub’s APIs, and it’s supported by their ToS, with strong legal precedents. Public data is public data.
\nWe figured, if the Wasteland is giving you reputational credit for work you’re getting verified as having completed, then why not give everyone partial credit for verified work they’ve already completed?
\nThis is all experimental, of course, and we’re likely to throw the whole system out and start over at least twice in the next 2–3 months. I wouldn’t get too attached to your high score.
\nWe didn’t scrape all of GitHub, because it would take forever. But we have an uploader, so if you want your GitHub profile slurped into the Wasteland, you fill out the form on the website and it’ll kick off a job to import your character sheet.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*6BqNg8rao8vjGsKe6qYp0g.png\")
Originally we had levels, but somehow I was level 18 and Linus Torvalds was level 14, so it was clearly the most broke-ass leveling system ever invented, and we threw it out right before launch.
\nWe’ll come up with a better one. How? We’ll post “make a better leveling system” on the Wasteland Commons wanted board, and someone will come along with a solution we like.
\nI strongly suspect that more sophisticated games will start to appear in this system as emergent behavior. Maybe it’ll be you making one, and you’ll be the next Wasteland superstar!
\nHow can I help?
\nFunny you should ask. The Wasteland has opted into the classic Git pull-request based workflow, for literally all work. You submit a PR, it gets approved, you get your stamp. For any kind of work, not just coding. We chose this for several reasons:
\nThe Wasteland is now building itself. The Gas Town, Wasteland, Gas City, and Beads projects are all putting work up for grabs on the Commons, and will begin farming out feature work in exchange for attested reputation.
\nSo if you want to help, you join in, and you help. We’re building campfire-style. Come register your rig and help us figure out where this thing is going.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*W4jXtp0WmmTFlVq_UqQGNA.jpeg\")
What’s coming next?
\nNo idea. We’re gonna find out! It’s going to be massive, whatever happens. You can build things so fast, especially with this many contributors, that we will be able to knock out things that companies could only dream of.
\nGas City will be one of the early successes. We’re going to deconstruct Gas Town into its constituent parts, like LEGO, and let you piece them together to make your own orchestrator topologies. It’s already got an early demo. Julian Knutsen and Chris Sells have been collaborating on it; they are both as smart as Victor Frankenstein and as tall as his monster. It shouldn’t be long before we can swap out Gas Town for a pure-declarative version of itself. And there’s work for it on the Commons board, so you can help!
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*P0Gs4LX_0R5FlrD-L4VD3A.jpeg\")
I also suspect we’re going to build a coding agent that actually wants to be a factory worker. Claude Code seems to be slipping into the classic “we’re a product, not a platform” trap, and the thundering herd is going to route right around that, as soon as it’s thermodynamically possible. The world needs a coding agent that behaves like a factory worker, and we don’t have one today. So one will get built.
\nWe’ll see sandboxes emerge soon, no doubt, and mechanisms will emerge for working on private repos. Although truthfully I could not tell you if private code will survive long-term. I’m on the fence about it today.
\nAs for the actual Wasteland protocols, they are pretty good. But they are also very early-days v1, and they’ll need to evolve. Using Dolt makes schema migration a dream, though, so I’m not worried about it. Our design is forward-compatible with our long-term plans.
\nOK so how do you *actually* get started?
\nHere’s the deliberately minimal version:
\n1. Install Dolt and create a free DoltHub account.
\n2. Head to gastownhall.ai to browse the wanted board and look up your character sheet.
\n3. Load the Wasteland Claude skill and let your agent walk you through wl join.
That’s it. If those instructions aren’t enough, wait a week or two — we’ll make it easier. And if they are enough, welcome to the Wasteland. You’re exactly who we’re looking for.
\nSee you out there.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*tZHxzmKRkAbzMK5qMCyoXA.jpeg\")
This was an unusually hard post to write, because it flies in the face of everything else going on.
\nI first started noticing a concerning new phenomenon a month ago, just after the new year, where people were overworking due to AI.
\nThis week I’m suddenly seeing a bunch of articles about it.
\nI’ve collected a number of data points, and I have a theory. My belief is that this all has a very simple explanation: AI is starting to kill us all, Colin Robinson style.
\nIf you’ll recall from What We Do In The Shadows (worth a watch, yo), Colin Robinson was an Energy Vampire. Being in the same room with him would drain people.
\nThat’s…pretty much what’s happening. Being in the same room with AI is draining people.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*svqMSkVB3MnkjOetkxoLCQ.png\")
10x Productivity is Real
\nLet’s start with the root cause, which is that AI does actually make you more 10x productive, once you learn how.
\nI know some of you are holding on to old September/October-ish beliefs about this, from last time you tried it, and you respectfully disagree.
\nBut if you haven’t used specifically Opus 4.5/4.6 with specifically Claude Code for at least an hour, then you’re in for a real shock. Because all your complaining about AI not being useful for real-world tasks is obsolete. AI coding hit an event horizon on November 24th, 2025. It’s the real deal. And unfortunately, all your other tools and models are pretty terrible in comparison.
\nBut hey, don’t take it from me. Take it from… the Copilot people. According to The Verge and a bunch of other reputable news sources, Microsoft is openly encouraging their employees to use multiple tools, and as a result, Claude Code has rapidly become dominant across engineering at Microsoft. If you give your worker bees open season, they will quickly find the path of least resistance, and that path goes through Claude Code.
\nLet’s not quibble about the exact productivity boost from AI. The boost amount isn’t what this post is about. It just needs to be higher than about 2x for the vampire effect to kick in. We’ll use 10x because it’s a number people throw around. Let’s use it for the sake of argument.
\nWith a 10x boost, if you give an engineer Claude Code, then once they’re fluent, their work stream will produce nine additional engineers’ worth of value.
\nFor someone.
\nBut who actually gets to keep that value?
\nValue Capture
\nLet’s pretend you’re the only person at your company using AI.
\nIn Scenario A, you decide you’re going to impress your employer, and work for 8 hours a day at 10x productivity. You knock it out of the park and make everyone else look terrible by comparison.
\nIn that scenario, your employer captures 100% of the value from you adopting AI. You get nothing, or at any rate, it ain’t gonna be 9x your salary. And everyone hates you now.
\nAnd you’re exhausted. You’re tired, Boss. You got nothing for it.
\nCongrats, you were just drained by a company. I’ve been drained to the point of burnout several times in my career, even at Google once or twice. But now with AI, it’s oh, so much easier.
\nNow let’s look at Scenario B. You decide instead that you will only work for an hour a day, and aim to keep up with your peers using AI. On that heavily reduced workload, you manage to scrape by, and nobody notices.
\nIn this scenario, you capture 100% of the value from your adopting AI.
\nIn this scenario, your company goes out of business. I’m sorry, but your victory over The Man will be pyrrhic, because The Man is about to be kicked in The Balls, since with everyone slacking off, a competitor will take them out pretty fast.
\nBut in Scenario A your company is honestly pretty precarious too, since you’re running all your employees on the ragged edge of burnout.
\nThe answer to “who captures the value” must lie somewhere in the middle, or we’re all pretty screwed.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*by0LJurBrgQEatMzTnI2gQ.png\")
Inherent Acceleration
\nThe world is accelerating, against its will. I can feel it; I grew up in the 1980s, when time really did move more slowly, in the sense that news and events were spaced way out, and society had time to reflect on them. Now it changes so fast we can’t even keep up, let alone reflect.
\nI’ve been watching the effect the AI Vampire is having on people around me and I’m growing concerned. We’re all excited, but it’s also… weird.
\nI already posted about the Nap Attacks, how I fall asleep suddenly at all hours of the day after long vibe-coding sessions, and how my colleagues at SageOx are seriously considering installing nap pods at the “office.” I’m still sleeping a crazy amount.
\nIt would seem that we are addicted to a new drug, and we don’t understand all of its effects yet. But one of them is massive fatigue, every day.
\nI don’t think that’s… good. And if anything, it seems to be getting more widespread. The developing situation is a multi-whammy coming at developers from all sides:
\nSo you’re damned if you do (you’ll be drained) and you’re damned if you don’t (you’ll be left behind.)
\nBefore we get into how to fight back, I need to take some accountability myself.
\nUnrealistic Beauty Standards
\nAgentic software building is genuinely addictive. The better you get at it, the more you want to use it. It’s simultaneously satisfying, frustrating, and exhilarating. It doles out dopamine and adrenaline shots like they’re on a fire sale.
\nMany have likened it to a slot machine. You pull a lever with each prompt, and get random rewards and sometimes amazing “payouts.” No wonder it’s addictive.
\nPeople are discovering this fun and they’re shouting from the rooftops about the crazy stuff they built during a 40-hour nonstop sprint with Claude Code.
\nAnd that’s where the problem gets into full swing. Because other people are listening!
\nPeople like me, and folks on LinkedIn saying their whole company has 3+ Claude Pro/Max accounts for Gas Town, and Jeffrey Emanuel and his 22 accounts at $4400/month, not to mention all the other crazy early adopters–we’re all part of the problem.
\nWe’re all setting unrealistic standards for everyone else.
\nMaybe me worst of all. I have 40 years of experience, I’ve led large teams, I read fast, and I have essentially unlimited time, energy, and now tokens for experimenting. I am completely unrepresentative of the average developer.
\nBut I’m still standing up and telling everyone “do it this way!” I even co-wrote a book about it.
\nEmployers are very likely starting to look at me, and the rest of us far outliers, and saying, “Hey, all my employees could be like that!”
\nAnd dollar-signs appear in their eyeballs, like cartoon bosses.
\nI know that look. There’s no reasoning with the dollar-eyeball stare.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*ffpMYJ72WZlynenWObMU0w.png\")
I don’t think there’s a damn thing we can do to stop the train. But we can certainly control the culture, since the culture is us. I plan to practice what I preach, and dial my hours back. That’s going to mean saying No to a lot of people who want to chat with me (sorry!), and also dialing back some of my ambitions, even if it means losing some footraces. I don’t care. I will fight the vampire.
\nThe next group that needs to arm up with garlic and wooden stakes is AI-native startups, where I’m concerned that the frenzy is getting out of hand.
\nStartups Are Poisoning The Well
\nStartups are an especially big contributor to the AI Vampire problem.
\nIf you have joined an AI-native startup, the founders and investors are using the VC system to extract value from you, today, with the glimmer of hope for big returns for you all later.
\nMost of these ideas will fail.
\nI know this because they are literally telling me their plans like villains at the end of an old movie, since with Gas Town I have mastered the illusion of knowing what I’m doing. Truth is, nobody, least of all me, knows what they’re doing right now. But I look like I do, so everyone is coming to show me their almost uniformly terrible ideas.
\nStartup founders are out there draining people at a faster rate than at any time in history, in pursuit of instantly banal ideas like “oh hey, I bet nobody thought of making a sandbox system for agents.” Cue nine thousand sandbox startups, all of which will eventually be killed off by a single OSS winner wrapped by home-grown internal vibe-coded SaaS.
\nI could list out a bunch of others. It’s pretty bad. There’s a massive amount of talent being thrown at an incredible dearth of real ideas, basically the same six tired pitches. (“AI personas!” “Agent memory!” “Gas Town, but safe!” “Better RAG!”)
\nThe overwhelming majority of these startups won’t sell a flea-bitten dollar of ARR. Even though enterprises aren’t too bright about SaaS, collectively (evidence: many are still on Copilot), they are quickly growing savvy enough to know that Build is the New Buy. Finance departments are about to make your head spin refusing to re-up SaaS contracts this year.
\nBut the SaaS founders are throwing themselves and their entire companies into it like it’s a classic gold rush, where everyone’s going to get a stake if they just work to exhaustion. I don’t think it works that way this time, but that’s how they’re treating it. A footrace to stake claims in the AI space.
\nThat’s a race that ends, in my opinion, with everyone collapsing in exhaustion without actually winning the race.
\nAnd while they run, they are setting the tone for the rest of us. I see these frenzied AI-native startups as an army of a million hopeful prolecats, each with an invisible vampiric imp perched on their shoulder, drinking, draining. And the bosses have them too.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*eWd9b4N5st7Mld-kUYvoEw.jpeg\")
Enterprises see the oncoming horde and think, oh jeez, we need to hustle. And they’re not exactly wrong. Which means this lovely dystopian picture is making its way slowly but surely into enterprise, at the big company where you work.
\nExecutives everywhere are excited about AI. Many of them are addicted as well, vibe coding at home, somewhat dangerously. And they’re thinking, gosh, if I just had a few engineers who worked this hard all the time then I wouldn’t need a bunch of the others! This is really just a recruiting problem!
\nThey’re reframing the problem in terms of finding people ripest for extraction.
\nThe Anti-Amazon-Extraction Formula
\nBack when I was at Amazon in the shiny new US1 building in the International District in downtown Seattle, 2001–2003-ish, people began to tire of the ridiculous pace. The company was post-IPO; the market had been up and down, and the company was starting to mature. But everyone was still working like sled dogs.
\nMost of my colleagues who put up with that environment are billionaires now, so it’s easy to point back at that time and say, “Oh, it was worth it.”
\nBut what if it hadn’t been a success? How many CEOs have bet everything, including their company’s wellbeing and mental health, on a big launch, only for it to go nowhere?
\nI’ve been there. Plenty of times I’ve allowed myself to be extracted from (drained) for the promise of some big potential future payout. One that often never came.
\nCompanies are straight-up designed for extraction, and so you need to be the counter-force.
\nMy friends who were grumbling back in 2001 needed some help with this, and I gave it to them. One day I walked up to the whiteboard during a particularly heated grumble-session, and I wrote a ratio on the board: $/hr (dollars divided by hours).
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*57IEwJyF0kHhMAxKGxnXlw.png\")
I said to everyone, Amazon pays you a flat salary, no bonuses, and you work a certain number of hours per week. From that, you can calculate that you make a certain number of dollars per hour.
\nI told the grumbler group, you can’t control the numerator of this ratio. But you have significant control over the denominator. I pointed at the /hr for dramatic effect.
\nThey all looked at me, wide-eyed, never having EVER thought of it from this perspective before.
\nI don’t think they fully believed me, but at least I got them thinking about it.
\nAs for my part, I went ahead and dialed that denominator down, and lived life a bit while I was at Amazon, because fuck extraction.
\nFunny thing, a couple of times over the next few months I’d be walking by some office full of people and they’d all be studying a formula on the board that said, in big letters: $/hr.
\n$/hr To The Rescue
\nThat old formula is also my proposed solution for the AI Vampire, a quarter century later.
\nSomeone else might control the numerator. But you control the denominator.
\nYou might think you don’t. And indeed, individually you may not have much sway over it. But collectively, the employees of your company have literally all the power. Now that I’ve been up at the top, I’ve learned that CEOs have surprisingly little power.
\nYou need to push back. You need to tell your CEO, your boss, your HR, your leadership, about the AI vampire. Point them at this post. Send them to me. I’m their age and can look them in the eye and be like yo. Don’t be a fool.
\nYou need to educate them about sharing the AI value capture between the company and the employees, and how to strike a good balance of sustainability and competitiveness.
\nWhen I was visiting Combank in Sydney in December, in their historic train station tech campus, I was awestruck by how it seemed like the ideal balance of happiness and productivity. It was open-plan, high ceilings, fancy, natural light, fully green with plants everywhere, with a huge coffee and snack stand in the middle of all the offices. People were sprawled out through the building, working, meeting, socializing, walking around outside, eating, enjoying the sun. It was, like, Tuesday for them.
\nThey found a great setting for the dial, at least for this time and place. I don’t know how it changes with AI. But I feel like their current setting is where we need to aim as the future changes us.
\nIt’s not even remotely sustainable for companies to capture 100% of the value from AI. And when employees capture 100% of the value, it will be temporary at best: that company gets beat by someone who’s got the dial turned higher.
\nI don’t even know what the right setting for the dial is. Hell, I’m the worst person to ask, because I’ve got the dial set to 11 and I’m putting all my weight on it, trying to make it go to 12.
\nBut the right setting is in the middle somewhere. Companies will try to drag it higher. You need to fight to drag it lower.
\nI would argue you need to consciously fight the AI Vampire even if you’re at a 30-person startup, where everyone agreed when they signed up that this was a sprint to try to get rich.
\nYou need to fight it if you’re an investor. You will kill your Golden Geese.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*kNKMoakPawoO8jp4ZsKt9w.png\")
You need to fight the AI vampire most of all if you’re a CEO or founder. People will be caught up in your enthusiasm. And they won’t understand why they’re being drained until they hit a wall and maybe can’t recover. Burnout’s a serious deal and can take someone down for a year or more. So take it seriously.
\nAs company leadership, what, realistically, can you do? I mean, nap pods is an option, probably a good one if people come into the office. But what if people just didn’t have to work so many hours? That is by far the most concrete way to fight the vampire. Change your expectations about how many hours there are in a human workday.
\nI’ve argued that AI has turned us all into Jeff Bezos, by automating the easy work, and leaving us with all the difficult decisions, summaries, and problem-solving. I find that I am only really comfortable working at that pace for short bursts of a few hours once or occasionally twice a day, even with lots of practice.
\nSo I guess what I’m trying to say is, the new workday should be three to four hours. For everyone. It may involve 8 hours of hanging out with people. But not doing this crazy vampire thing the whole time. That will kill people.
\nAs an individual developer, you need to fight the vampire yourself, when you’re all alone, with nobody pushing you but the AI itself. I think every single one of us needs to go touch grass, every day. Do something without AI. Close the computer. Go be a human.
\nI regret the unrealistic standards that I’m contributing to setting. I don’t believe most people can work like I’ve been working. I’m not sure how long I can work how I’ve been working.
\nI’m convinced that 3 to 4 hours is going to be the sweet spot for the new workday. Give people unlimited tokens, but only let people stare at reports and make decisions for short stretches. Assume that exhaustion is the norm. Building things with AI takes a lot of human energy.
\nI’m going to continue to launch stuff, post blogs, all that. But be aware that I’m pushing back hard behind the scenes. I’m saying No to a bunch of people asking for meetings, and resisting the incessant demand for podcasts and appearances.
\nI’m making sure that if this all comes crashing down, I won’t have Regret Years to look back on. I’m even typing this post out at the mall, with Linh and Mozart, because when I close the computer, we’re going to go for a walk.
\nI’ll see you next time. I hope we’re both more refreshed.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*EkSLKFQwHX7vVRu7n16ixQ.png\")
![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*13Lj8DPzU5c3uhYw73LYwg.jpeg\")
As you’ve probably noticed, something is happening over at Anthropic. They are a spaceship that is beginning to take off.
\nThis whole post is just spidey-sense stuff. Don’t read too much into it. Just hunches. Vibes, really.
\nIf you run some back-of-envelope math on how hard it is to get into Anthropic, as an industry professional, and compare it to your odds of making it as a HS or college player into the National Football League, you’ll find the odds are comparable. Everyone I’ve met from Anthropic is the best of the best of the best, to an even crazier degree than Google was at its peak. (Evidence: Google hired me. I was the scrapest of the byest.)
\nEveryone is gravitating there, and I’ve seen this movie before, a few times.
\nI’ve been privileged to have some long, relatively frank conversations with nearly 40 people at Anthropic in the past four months, from cofounders and execs, to whole teams, to individuals from departments across the company: AI research, Engineering, GTM, Sales, Editorial, Product and more. And I’ve also got a fair number of friends there, from past gigs together.
\nAnthropic is unusually impenetrable as a company. Employees there all know they just need to keep their mouths shut and heads down and they’ll be billionaires and beyond, so they have lots of incentive to do exactly that. It’s tricky to get them to open up, even when they do chat with you.
\nBut I managed. People usually figure out I’m harmless within about 14 seconds of meeting me. I have developed, in my wizened old age, a curious ability to make people feel good, no matter who they are, with just a little conversation, making us both feel good in the process. (You probably have this ability too, and just don’t know how to use it yet.)
\nBy talking to enough of them, and getting their perspectives in long conversations, I have begun to suspect that the future of software development is the Hive Mind.
\nHappy But Sad
\nTo get a proper picture of Anthropic at this moment, you have to be Claude Monet, and paint it impressionistically, a big broad stroke at a time. Each section in this post is a stroke, and this one is all about the mood.
\nTo me it seems that almost everyone there is vibrantly happy. It has the same crackle of electricity in the air that Amazon had back in 1998. But that was back in the days before Upton Sinclair and quote “HR”, so the crackle was mostly from faulty wiring in the bar on the first floor of the building.
\nBut at both early Amazon and Anthropic, everyone knew something amazing was about to happen that would change society forever. (And also that whatever was coming would be extremely Aladeen for society.)
\nAt Anthropic every single person and team I met, without exception, feels kind of sweetly but sadly transcendent. They have a distinct feel of a group of people who are tasked with shepherding something of civilization-level importance into existence, and while they’re excited, they all also have a solemn kind of elvish old-world-fading-away gravity. I can’t quite put my finger on it.
\nBut I am starting to suspect they feel genuinely sorry for a lot of companies. Because we’re not taking this stuff seriously enough. 2026 is going to be a year that just about breaks a lot of companies, and many don’t see it coming. Anthropic is trying to warn everyone, and it’s like yelling about an offshore earthquake to villages that haven’t seen a tidal wave in a century.
\nThe Vibe Mind
\nEveryone you talk to from Anthropic will eventually mention the chaos. It is not run like any other company of this size. Every other company quickly becomes “professional” and compartmentalized and accountable and grown-up and whatnot at their size. I don’t think Anthropic has bothered with any of that crap yet.
\nI mean sure, yes, for their production systems, they are of course very serious and appropriately frowny-faced and have lots of world-class SREs and scaling engineers. Buuuut, you know. The tail that wags their dog is Claude in its various incarnations, and that’s the Work Generator that keeps the hive buzzingly happily along.
\nSo when I generalize and say Anthropic is completely run by vibes, I’m sure there are exceptions at the periphery, where it makes sense to have hardened interfaces with the rest of the world, whether it’s production, or GTM, or product marketing. And the company is probably a bit more “normal” at those edges.
\nBut at the core, they are self-evidently in the middle (or maybe beginning) of a Golden Age, which I’ll talk about in the next section. And it’s very churny and frothy there.
\nThe employees often describe it as a hive mind that is run entirely on vibes, so this isn’t me putting words in their mouths. They are observing it too. Organizations reflect their leaders, so it’s clearly being directed by leadership, and I’m sure it’s intentional. Not all the bees are the same size, and there are clearly some graph nodes spread through the hive mind that are keeping it stable.
\nBut if you interfere with the hive mind operation, upsetting that balance, you’ll gently be pushed out to the edges, and maybe beyond. The centrifuge will spin you away to the periphery, carried by a wave of vibes.
\nIt feels fragile, and it may have scaling ceilings we’re all unaware of. But they have kept it going so far, and I have some thoughts about how they’re managing it.
\nHow To End a Golden Age
\nI’m going to share something with you here that’s orthogonal to the Hive Mind, but Anthropic is demonstrating this other property so clearly that we need a time-out to examine it together.
\nA Golden Age is a period of intense innovation, category creation, velocity, and productivity that lasts typically several years. Golden Ages at companies have the property of attracting all the greatest talent in the industry, very quickly. That’s happening at Anthropic right now.
\nI was at Amazon during their Golden Age, still going strong when I left in 2005. And I was at Google during their Golden Age, which lasted until April 2011. After that I watched Google ossify and become siloed and effectively incapable of cross-functional work, while Amazon continued to execute and innovate.
\nIf you need a third Golden Age example, Microsoft had many of the greatest minds in the industry gathered together in the early 2000s, to figure out the future of software development on the CLR with C#/.NET, because they’d lost the Java lawsuit. It was the best thing that could have happened to them, and for a few years it was magical, and they produced stuff that shaped the entire industry. For a few years they were thought leaders. Many wound up fleeing to Google after it came crashing down.
\nI spent years wondering why and how it happened at Google. But I didn’t figure it out until I saw what is currently happening at Anthropic. That’s when it clicked.
\nGoogle had killed their innovation machine on the vine when they switched their focus to profits, which caused a shift in the ratio of work to people.
\nGoogle’s motto under their original CEO Eric Schmidt was, “Let a Thousand Flowers Bloom.” Schmidt’s explanation was that he was “generating luck” by encouraging innovation and taking a lot of bets, hoping some would pay off. It was something Google could afford to do, because they were rolling in money, in the new greenfield of the web.
\nWhen Larry Page took over as CEO in April 2011, his motto was: “More Wood Behind Fewer Arrows.” He felt–and rightly so–that the unfettered, unsupervised 20% work and Labs activity hadn’t produced any real hits. So Larry put big constraints on what work would get funded, and 20% work gradually died away. From that point on, the company turned “political,” lost most of their innovation engine, and the Golden Age was over.
\nWas it killing 20% work that caused the crash? Not directly. As a counterexample, Amazon never had 20% work. Their Golden Age of innovation and excitement lasted a pretty long time, much longer than after I left in 2005. So it wasn’t that. What did they have that Google didn’t?
\nOne clue is something my colleague Jacob Gabrielson told me when he was a Principal Engineer at Amazon in maybe 2015-ish, when Google had become hardened like concrete. I told him that people often fought over projects at Google, and Jacob told me that it never happened at Amazon, because, as he put it, “Everyone here is always slightly oversubscribed.”
\nSo now you see how the magic starts and ends. During Golden Ages, there is more work than people. And when they crash, it is because there are more people than work.
\nI realize I’m mixing units, but otherwise it gets grammatically awkward. You get the idea.
\nLarry Page told the company in April 2011, when he became CEO, “stop working on new stuff, we’re only going to do X, Y, and Z.” And they kept every single engineer, but cut the amount of work by a solid 50% or more. You could no longer work on any problem you wanted. And there wasn’t really enough to go around.
\nThat was the beginning of the end. As soon as there wasn’t enough work, people began to fight over the work that was left. It kicked off a wave of empire building, territoriality, politicking, land grabs, and, as Lydia Ash taught me, Cookie Licking–a phrase folks at Microsoft had invented to accuse people of claiming work that they will never actually get around to doing.
\nThat badness is normal operating behavior for a lot of companies out there today. One person described being at Microsoft as being a molecule in a metal, with your elbows tightly locked together with everyone else’s. Ironically, all the Microsoft cookies appear to be licked now.
\nAt Anthropic, they are smack in the middle of a Golden Age, where there is far more available work than there are people to do it, on pretty much all fronts. It’s like they’re on the surface of an expanding sphere.
\nSo despite the chaos, and the inevitable growing pains (not dissimilar to when I was at Amazon during their Get Big Fast phase just after their IPO), there is never a reason to fight over work. There is infinite work.
\nAnd so everyone gets many chances to put their ideas in the sun, and the Hive Mind judges their merit.
\nThe Small Version
\nMy strong suspicion is that Anthropic is operating the way all successful companies will soon operate within a few short years, despite it being so very different from how most operate today.
\nMy suspicion arises from a second data point. Yes. I have diangulated on the answer from two data points. I bet you didn’t know you could do that. Well I did it. If my diangulation trick doesn’t convince you, fair enough. The Hive Mind may be an anomaly unique to Anthropic. I’m just trying to extrapolate from the data points we do have.
\nMy friends Ajit Banerjee, Ryan Snodgrass, and Milkana Brace are a little 3-person startup called SageOx. They spend their time in a little apartment in Kirkland, about a mile from me, above a coffee shop bakery, alternating between coding and sleeping, for weeks on end. They don’t bother to put their shoes on when they walk down to get coffee.
\nThey’re all level 7 to 8 on my Dev Evolution to AI chart. I got the sense this is also true for essentially all the engineers at Anthropic, and probably half their business people too.
\nSageOx are the ones that told me that an external fourth contributor overseas wasted a bunch of time acting on 2-hour-old information, because everything is moving so fast. They’re also the ones that told me you need full transparency at all times, at their speeds, or nobody will ever see what you are doing and you’ll fall irretrievably behind.
\nSo they all turn their volume way up and announce everything they’re doing at all times. “I AM GOING DOWN TO GET A DONUT NOW,” they will say, and someone will yell from the nap couch, “GET ME A DONUT.” “I AM ALSO DELETING THE DATABASE.” “OK.”
\nA lot of engineers like to work in relative privacy, or even secrecy. They don’t want people to see all the false starts, struggles, etc. They just want people to see the finished product. It’s why we have git squash and send dignified PRs instead of streaming every compile error to our entire team.
\nBut my SageOx friends Ajit and Ryan actually want the entire work stream to be public, because it’s incredibly valuable for forensics: figuring out exactly how and why a teammate, human or agent, got to a particular spot. It’s valuable because merging is a continuous activity and the forensics give the models the tools and context they need to merge intelligently.
\nSo at SageOx they all see each other’s work all the time, and act on that info. It’s like the whole team is pair programming at once. They course-correct each other in real time.
\nThey showed me a demo yesterday, very impressive actually, and we had a big debate over whether developers would be comfortable with their entire workstream made visible to the rest of the company. SageOx records even their own conversations at all times, and the transcripts are automatically uploaded and versioned, and they have the full work history of what every human and agent has done, forever. It’s fully transparent: a necessity for a hive mind.
\nThe consensus was, most developers would be really uncomfortable with that.
\nWhy? Because it’s the death of the ego. Everyone can see all your mistakes and wrong turns. Everyone can see exactly how fast you work. There is nothing you can hide, nothing to hide. You have to be a happy bee.
\nSo I gave them some advice on making work hideable, because it’s gonna take some time for devs to adjust to working in fish bowls.
\nAnyway, seeing SageOx do this, operating a hive mind with three people, made me immediately think of Anthropic. SageOx are not focused on profits either; they’re focused on discovery. They are trying to find PMF by inventing it, since this is a new category. They are working together as a mini-hive mind, automating their own work in a tight self-reinforcing loop.
\nBuilding for yourself is the only way to give your product a nonzero chance of success in the new world. Build something just for yourself, and make sure you love it so much that you know it’s how other people should be working.
\nI see far too many AI-native startup founders today trying to guess what people might want, and building things that will never succeed. They build for enterprises, little agent workbenches that provide personas and helpers and RAG-like stuff, or they’ll build orchestrators for “normie developers” trying to make agents safe. And it’s all just… ugh. Wrong side of the Bitter Lesson.
\nThey’re not building for themselves, so they can’t see it.
\nThe Settlers of Catan inventor Teuber famously built new games for his own family to playtest for years, before they finally found the formula for Catan through many iterations. I like to think of them sitting around and testing out new variations of games as being very similar to how modern AI devs are building software.
\nThe Campfire Model
\nRather than a bunch of traditional departmental silos, Anthropic and SageOx both look to me like they are building together around a campfire, at least in contrast with how most people are currently thinking about agentic development.
\nI started seeing this analogy when we were discussing evolutionary design at the Thoughtworks unconference offsite in Deer Valley, Utah this weekend, which Martin Fowler was kind enough to invite me to. Absolutely lovely event, I got to meet so many brilliant people from around the world and the industry. It was a privilege to be there.
\nAt one of the breakouts we were discussing Spec-Driven Development, which completely mystified me. I’d heard of it, but many people were using the term to describe a spectrum of different development practices, nearly all of which felt like waterfall to me at best, and Intentional Programming v2 at worst. Few of us found any SDD model very compelling when comparing them to our own personal development practices.
\nInstead, at our breakout session about SDD, we realized we mostly prefer what we were calling Exploratory Development or Evolutionary Development, where rather than making a big complex spec, everyone sits around a campfire together, and builds.
\nThe center of the campfire is a living prototype. There is no waterfall. There is no spec. There is a prototype that simply evolves, via group sculpting, into the final product: something that finally feels right. You know it when you finally find it.
\nAs evidence of this, Anthropic, from what I’m told, does not produce an operating plan ahead more than 90 days, and that is their outermost planning cycle. They are vibing, on the shortest cycles and fastest feedback loops imaginable for their size.
\nAnd the result, they tell me, is something like improv.
\nImprov at Scale
\nAnthropic’s Hive Mind is described by employees as “Yes, and…” style improvisational theater. Every idea is welcomed, examined, savored, and judged by the Hive Mind. It’s all based on vibes. There is no central decision-making authority. They are just trying everything, and when magic happens, they all just kind of realize it at once.
\nThey’re making forward progress via mashups and exploration at the frontier of software development and knowledge work using AI. They’re finding their way like a floodfill search.
\nThis reminds me of pure functional data structures, which are like append-only logs. Pure functional data structures are emerging not just at the organizational level in 2026, but also in DevOps. Ledgered, versioned, pure-functional databases like Datomic and Dolt are going to become increasingly valuable for mistake-prone agentic workflows. I’ll talk more about this in a future post.
\nWith this accretive development model, it’s like Anthropic engineers are sculpting together with clay. It feels like there are a bunch of campfires at Anthropic, and they swarm around the fires (various in-flight products), changing their shapes as people try new variations and mashups.
\nSomeone there told me that Claude Cowork was launched publicly 10 days after they first had the idea. When magic happens there, it happens very fast.
\nThey are generating luck, exactly what Eric Schmidt had wanted. But they are doing it much, much faster than Googlers could, because they are all 10x to 100x as productive as engineers who are using Cursor and chat today, and roughly 1000x as productive as Googlers were back in 2005. (And in 2005 we were honestly pretty badass compared to programming back in 1986 when I started; it has been nice gradually turning into a wizard over the last 40 years.)
\nSo to me, Anthropic feels like a quivering mass implementing Multi-Armed Bandit on ideas at a super high velocity. Everyone gets their chance, since you can implement anything and people will try it out.
\nBut the hive mind will also eject anyone who’s not acting like a happy worker bee in the swarm. You need to contribute your ideas in the right ways. It’s the death of the ego. These were the exact words of someone who’s been there since the early days.
\nSound familiar?
\nI think it really is kind of like improv. It’s a team sport. It doesn’t work to come in guns blazing, and make it about yourself.
\nSo we’re seeing real power in the “Yes, and…” model.
\nAnd yet, most companies arrived at where they are by learning how to say No.
\nThis is shaping up to be a problem.
\nMore To Come
\nI have plenty more thoughts on the subject, but unfortunately precious little time or space. I have a huge blog-post backlog to get through, not to mention equally huge maintainer responsibilities now. There are literally whole companies using Gas Town, it’s pretty nuts.
\nIf I’ve convinced enough people of the hive mind as an operating model, then maybe I can write more about how you might go about turning your existing company into one.
\nA little bird from… somewhere, in Sales, told me that all companies are asking variations of just the same two questions. They bluster and bluff and try to act informed, but they are all terrified. When you cluster their questions, they break down into, “Will everything be OK?” and “Will we be here in five years?”
\nThe default answer, I’m afraid, is No. If you do nothing, you’re almost certainly going to get overrun. If you have an Atom Moat, then you stand a pretty good chance of weathering the storm, if you execute well. Just a chance, mind you: It’s a moat, not a force field. But atoms are a pretty good moat. If you make beer, or work with humans, or ship stuff, say, then you’ve got a bit more time to work with, maybe, to find your feet in the AI era.
\nIf you have a strictly online or SaaS software presence, with no atoms in your product whatsoever, just electrons, then you are, candidly, pretty screwed if you don’t pivot. I don’t think there are any recipes for pivoting yet; this is all new, and it’s all happening very fast.
\nBut there is a yellow brick road: spending tokens. This golden shimmering trail will lead your company gradually in the right direction. Your organization is going to have to learn a bunch of new lessons, as new bottlenecks emerge when coding is no longer the bottleneck. You need to start learning those bespoke organizational lessons early. The only way to know for sure that you’re learning those lessons is if people are out there trying and making mistakes. And you can tell how much practice they’re getting from their token spend.
\nI don’t work for anyone, I’m not associated with any company, and I’m not selling anything. I’m not even recommending any particular course of action, other than… learn AI. Now’s the time. Just start.
\n![\"\"](\"https://cdn-images-1.medium.com/max/750/0*wm2S-GXg0778_vJ8.jpg\")
You have a lot of work ahead of you. Build the campfire. Turn your product into a living prototype. Consider building some hives within your company, and giving them space to innovate.
\nAnd then pivot like hell to your new PMF, whatever that may be. Good luck. It’s gonna be a crazy year. May the best… whatever… win.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*uqgTBedArMGdOfzVK_Ep-w.jpeg\")
p.s. come join us at the Gas Town Discord, which you can find at gastownhall.ai — see you there!
\nI spent a lot of time writing software with AI last year, and I had some pretty good successes, notably Beads and Gas Town. I wrote a whole bunch of other systems, some still in progress. And I got a solid intuition, a feel for how AI’s exponential progression is, well, progressing.
\nThat intuition is how I created Gas Town. I believe the exponential curves; I believe everything Dario Amodei and Andrej Karpathy are saying about software. And if you were leaning in when Claude Code came out 11 months ago, then if you extrapolated from completions in 2023 to chat in 2024 to agents in early 2025, you arrived inescapably at orchestration arriving in early 2026.
\nSo towards the end of the year, I went looking for what I knew would be there, and found Gas Town right where I was looking for it. I was like a geologist who knew there would be an oil deposit there, and I drilled and it hit. I dug around and found a shape that just barely worked, with the best late 2025’s models that hadn’t been trained to be factory workers, plus a lot of duct tape. And janky as it may be, Gas Town has illuminated and kicked off the next wave for everyone.
\nI think I’ve established a pretty good track record of predicting the future, from Death of the Junior Developer back in June 2024 when the job market was still super hot, to Revenge of the Junior Developer which predicted today’s orchestrators 10 months ago, to Gas Town itself, which I think is pushing pretty far into the frontiers of what’s possible today.
\nAll of my predictive power comes from believing the curves. It’s that simple.
\nIn this post, I’m going to make a prediction about which software will survive, if you believe Karpathy, in a world where AI writes all the software and is essentially infinitely capable. I think you can make a simple survival argument that comes down to selection pressure.
\nFirst let’s talk about my credentials and qualifications for this post. My next-door neighbor Marv has a fat squirrel that runs up to his sliding-glass door every morning, waiting to be fed. It’s against a city ordinance to feed them but Marv is 82 and he ain’t having it. So the squirrel has grown chonkulous, and it shows up like clockwork when we’re about to go golf or head to the range in his corvette or any of the other 82-year-old stuff we do.
\nMarv’s squirrel knows approximately the same amount about evolutionary biology as I do, and would score similarly to me on a University-level examination on the subject.
\nBut I have this hunch. I think I know how to predict whether your software is going to make it or not, if you assume (as I do) that Karpathy and Amodei are completely 100% correct.
\nLet’s see if I can convince you.
\nKarpathy describes a future where AI can build pretty much anything on demand, and we’ve already seen early evidence of this in the form of emerging pressure on SaaS companies, as the buy vs build calculus changes. It’s getting easier and easier to build what you need rather than buying it. We’re seeing business departments vibe coding their own SaaS instead of re-upping with niche vendors. Three years ago, GPT-3.5 could barely write a coherent function, and now AI can write small-scale (but valuable) SaaS for you. The trajectory is exponential, so home-grown medium-scale SaaS will be on the table by EOY.
\nIt’s not just SaaS. We’ve already seen entire categories begin to be eaten up by AI: Stack Overflow and Chegg were early victims, but now we’re seeing pressure on new sectors. Tier-1 customer support software, low-code/no-code systems, content generation tools (e.g. writing assistants), a whole lot of productivity tooling. Even IDE vendors are beginning to sweat over Claude Code, and with good reason.
\nIf you believe the AI researchers–who have been spot-on accurate for literally four decades–then all software sectors are threatened. Even if you don’t buy into their vision wholesale, it’s prudent to be cautious and at least think about it.
\nI see boards and C-suites beginning to ask, how can we plan ahead to survive in the Software 3.0 era? But they don’t have any sort of a framework for thinking about it yet. I think mine, while not perfect, provides a pretty good starting point. You be the judge.
\nInference costs tokens, which cost energy, which costs money. For purposes of computing software survival odds, we can think of {tokens, energy, money} all as being equivalent, and all are perpetually constrained. This resource constraint, I predict, will create a selection pressure that shapes the whole software ecosystem with a simple rule: software tends to survive if it saves cognition.
\nThis is, roughly speaking, an evolutionary argument, at least according to Marv’s Squirrel. In any environment with constrained resources, entities that use those resources efficiently tend to outcompete those that don’t. Karpathy’s Software 3.0 ecosystem should similarly select for tools that minimize cognitive expenditure, which you can measure and model pretty closely as token spend.
\nI think that systems have a financial and indeed an ethical obligation to minimize compute costs for solving cognitive problems, because energy is rapidly becoming the world’s biggest constraint. For starters, this obligation implies that we should use smaller models when they can perform the same tasks. That may seem obvious, but I think our current monolithic coding agents aren’t doing a very good job of it. Orchestration systems give me hope that we can do a better job of allocating work to the right model tiers in the future, saving energy and money in the process.
\nBut even with a bazillion smaller models deployed everywhere including your dental fillings, I think there is still a role for large classes of “old-fashioned” software systems that aren’t models, and don’t necessarily use AI at all. This essay concerns those systems, which I think will survive and thrive if they have the right properties.
\nMy hunch is that if a tool saves AIs tokens, it has a high chance of being used and surviving. And tools that don’t save tokens will gradually be phased out. That’s not a guarantee; it’s just going to be a strong general selective pressure. There are caveats and exceptions and carve-outs that we’ll discuss.
\nThe good news is, there are plenty of concrete ways you can plan ahead to help ensure your software survives the transition to the Karpathy Software 3.0 era.
\nFor any tool T, my model posits that survival looks something like the following, in Squirrel Math:
\n\n\nSurvival(T) ∝ (Savings × Usage × H) / (Awareness_cost + Friction_cost)
\n
Where:
\nTo be clear: this isn’t a proof, or real math, or anything like that. It’s just a visual aid, a mental model I use for thinking about software survival in the age of resource-limited super-intelligence.
\nI debated with Claude endlessly about this selection model, and Claude made me discard a bunch of interesting but less defensible claims. But in the end, I was able to convince Claude it’s a good model, and I aim to do the same with you. Let me know what you think by complaining that AI sucks on HN!
\nIn the Survival Ratio model, the minimum viable ratio for survival is 1. If tool T saves tokens overall, and the agent knows about it, and it works smoothly, then T will have positive selection pressure. Conversely, a tool that doesn’t save tokens, or costs more to use (or to know about) than what it saves, will get selected against, sooner or later.
\nYour software’s survivability threshold floats above 1 when there’s competition. A useful tool with a ratio of 1.2 can get beaten by a competitor with a 2.5. Agent attention is going to become a key battleground, driving awareness cost higher. In a niche domain without much competition, like say DNA sequencing, any tool that saves a few tokens might be quickly noticed and see lots of use. But in crowded domains, awareness isn’t automatic, big mediocre players may have all the recognition, and you may have to pay extra to be noticed by agents. We’ll talk about different ways to accomplish this today, and hint at more to come.
\nAs a framework, I think the Squirrel Selection Model is Good Enough: it’s better than what most C-suites are working with today. My model gives you six levers you can use for planning your software’s survival. Let’s go through them in turn. First we’ll talk about the two most powerful long-term levers, both of which are all about saving money.
\nYour first two levers help maximize the Savings term in the numerator of the Survival Ratio. Let’s first talk about why these levers exist at all, in a world where AIs are superintelligent and can synthesize literally any software they want.
\nCoding agents can do complex work in their heads, so to speak, purely through inference on GPUs. But if you’ve ever seen, for instance, how they do multiplication, it’s as bad as a person using nothing but chickens. LLMs use composition of pattern-matching, not concise algorithms. For example, first the model might use a pattern to guess that the answer is roughly 94-ish. And then use another pattern-match to find the final digits of the answer, using a remembered lookup table.
\nIt’s as Turing-complete as a Minecraft goat farm and it definitely gets the job done. But when they’re multiplying inline while working, the computation is happening in an extremely inefficient substrate: the GPU layer at inference time. For arithmetic it’s far more efficient to be using CPU-based code, or tools like calculators. It turns out there are many kinds of computation that the LLM is better off delegating to tools.
\nFortunately for everyone involved, agents are happy to use tools if they perceive that it’s going to save them some cognition. Call it laziness, but it’s Larry Wall’s “Three Great Virtues of a Programmer” laziness. It’s good laziness.
\nSo coding agents can and do use tools, but they also write their own tools. For any given delegatable problem, an agent has a choice: they can reach for an existing tool, or they can write one.
\nIf your goal is to get them to reach for your tool instead of writing their own, then you have two levers that can save cognition, which should make them prefer to use it. Assuming they know about it, which is Lever 4. All in good time. You must have the patience of Marv’s squirrel waiting outside that sliding glass door, and soon all the nuts will come your way.
\nFirst lever: your software can make itself useful by compressing insights. The software industry has accumulated a lot of hard-won knowledge that would be expensive to rediscover. Many systems compress hard-won insights into reusable form.
\nThere is no better example than Git. It’s not going anywhere. Sure, it’s not hard for an AI to build its own version control system. But Git’s model–the DAG of commits, refs as pointers, the index, the reflog — I’m already losing you, but that’s the point. Git represents decades of accumulated wisdom about how to track changes when multiple people are working on the same thing, changing their minds, making mistakes, and merging their work back together.
\nAn AI reimplementing Git from first principles would have to re-traverse that entire intellectual history, burning tokens all the way. It would be economically irrational. Or as Marv’s chonko squirrel would put it, “nuts.”
\nThe same principle applies broadly to many kinds of systems–e.g., databases, compilers, operating systems, workflow engines, monitoring. The older the better, in some ways. Kubernetes is complex because distributed systems are complex. Temporal provides durable execution because the alternative — building your own saga pattern with idempotent retries — is a daunting research project. These systems are, in a meaningful sense, crystallized cognition, a financial asset, very much like (as Brendan Hopper has observed) money is crystallized human labor.
\nI think the strong players in this category share a property: it would be flatly absurd to try to re-synthesize them, because of their sheer insight density. They either solve a genuinely hard problem, or they solve a common problem with genuine elegance. Why mess with success?
\nInsight compression can take many forms. AIs frequently call out this kind of compression when they encounter it. Claude has often referred to Gas Town’s cute character roles and verbs like gt sling as being a kind of compression: taking complex ideas and giving them concise and memorable forms. AIs genuinely seem to love to use tools that compress insights, as it gets them faster to their goals.
\nAs Claude put it, “Nobody is coming for grep.” It’s a great example of a tool that would also be crazy to reinvent, because, like Lever 1, it saves a lot of tokens relative to the effort of using it.
\nBut grep doesn’t compress any hard-won insights. In fact it’s pretty simple; Ken Thompson famously wrote grep in an afternoon. Grep saves cognition by doing it on a cheaper substrate: CPUs. Algorithmically, it also punches way above its weight class, doing a lot for very little effort. Pattern matching over text is a task where CPU beats GPU by orders of magnitude.
\nSo it would be irrational from any perspective–economic, ecological, moral, or otherwise–to spin up inference to do what grep does. Similarly, LLMs will choose calculators over writing code if they’re available. Tools that enable this lever include parsers, complex transformers like ImageMagick, and many Unix CLI tools.
\nYour lever here is to save tokens by doing computations more cleverly. You can achieve that with a good algorithm, or by moving the compute to a cheaper substrate, such as CPUs, humans, or chimpanzees.
\nThis is the Usage term in the Survival Ratio. It basically amortizes your awareness cost and lowers the threshold for token savings. If you have a truly general-purpose token-saving tool, then it doesn’t really matter if it’s easy for AIs to recreate it. They’ll use the thing that’s everywhere. But how do you make your software be the “obvious” choice for agents?
\nIt’s easy to point at Git and say, “Just be like Git. Be around forever, make sure everyone uses you for decades, and solve a much wider variety of problems than you originally set out to solve.” Same could be said of grep, really. It’s a bit silly; they are too high of a bar. I think a more useful practical example is Temporal, which, despite not being super well-known, is near-universally useful as agentic workflows take center focus in 2026.
\nTemporal has comparatively high awareness and friction costs, e.g. compared to (say) Postgres, which has been around a lot longer and has much more training data available. But Temporal is as broadly useful as PostgreSQL; just as Postgres can be used to store and query most datasets people care about, Temporal can be used to model and execute most workflows people care about. Temporal has all three levers so far: aggressive insight compression, masterful use of the compute substrate to solve complex problems, and it’s broadly useful. So no AI in its right mind is going to try to clone it for any serious work.
\nDolt is another interesting example of software that’s ahead of its time. Gene Kim and I have been saying, “don’t use LLMs for production database access–only use agents in prod when you have Git as a backstop!” Well, what if your database was versioned with Git? Every single change?
\nDolt is OSS that has been around for 8 years, and is only now finally finding its killer app with agent-based prod and devops workflows. With Dolt, agents can make mistakes in prod, and roll back (or forward) with the full power of Git. But they hadn’t solved the awareness problem when I first made Beads, or I’d have used Dolt from the start.
\nYou can find problem spaces that will thrive by looking at what will change when agents are doing all the work. For instance, code search gets harder, as LLMs start producing 10x-100x as much code. Agents will need good search as much as humans ever did, and grep, for all its charms, does not scale. So code search engines also have all of our first three levers: (1) they solve a nontrivial problem with lots of hard-to-discover edge cases, (2) they do it in a cheaper computation substrate than GPU inference, and (3) they have found a large, near-universal niche of “anything too big for grep.”
\nI find all this quite hopeful. There will be infrastructure opportunities galore. The Software 3.0 world is going to be filled with swarms of agents and meta-agents crawling over huge graphs of data, mining interesting insights. There will be a new attention economy, new aggregators to help us know what’s cool, and new channels for broadcasting what your software is capable of.
\nThe more broadly useful you can make your software, the more agents will be able to use it. This can create a virtuous cycle by producing more training data. The new world of software will be big. Aim to build software that lots of agents prefer to use in lots of situations.
\nSaving cognition isn’t enough on its own. You also need to solve the awareness problem somehow: the pre-sales problem. Agents have to know about you. Dolt was a great example of a tool with levers 1 to 3 but not 4: I’d have used for Beads sooner if Claude or I had known about it.
\nAwareness cost is the energy required for an agent to know your tool exists, to remember it when relevant, and to prefer it over alternatives. One way to pay it down is to build a great product, get really popular so everyone talks about you, and wait for community-provided training data to appear online for your product.
\nOr, you can do it the good old fashioned way, and throw money at the problem. You can put a bunch of money into building documentation about your product for agents. And you can maybe get some luck with advertising. But there’s a more direct solution.
\nAn increasingly popular way to pay down the awareness cost is to work with representatives from OpenAI, Anthropic, Google and other frontier labs to help train their models on your tools. It’s a paid service, or so I’m told. I met a guy at a conference from OpenAI who does this for a living. He works with tool vendors to create evals that demonstrate how (and how not) to use the tool, and then their researchers adjust the training to improve the eval scores.
\nSEO for agents is on its way. I know nothing about it, but it’s coming. You might need to look at it. It may not be enough for you to focus on your Survival Ratio numerator. Being good isn’t enough for agents to choose you; you have to be familiar and trustworthy and known.
\nIf you can’t afford deep-pockets spending to pre-train models on your tools, or to put your tools in discovery’s way (via Ads, aggregators, etc) for agents who are searching for solutions, then you’re going to have to rely on “post-sales energy” (Lever 5), which is making sure your tool is super agent-friendly.
\nIf the agent has never heard of your tool, the best you can do is make it easy to use.
\nIf Awareness is a pre-sales problem, then Product Friction is a post-sales problem. Your agent may be perfectly aware that it has a useful tool, but even a small amount of friction may change its calculation.
\nAgents always act like they’re in a hurry, and if something appears to be failing for them, they will rapidly switch to trying workarounds. If they’re using your tool and they are having trouble getting it working correctly, they give up super fast. I’ve spoken with many of you at conferences and meetings where you described a tool you’d built, one that the agent swore up and down they’d use, and you just couldn’t get them to use it.
\nConversely, if you build the tool to their tastes, then agents will use the hell out of it.
\nOne way to approach this problem is with documentation. You’ve deferred spending energy on training until inference time, so you’re going to need to load up context with information about your tool: what it’s good for, why and when the agent would want to use it, and a quickstart guide, with pointers to easy-access follow-up docs.
\nThis isn’t a bad approach. Agents can read a lot. You can use agents to produce highly information-dense documentation, and there’s probably a market for products to help you out with very large information stores.
\nHow much documentation you need to do this depends on your tool. Gas Town has pages and pages of prompting because it’s not in anyone’s training data: it’s too new. So it expends a lot of energy bringing agents up to speed. That will improve as agents get training on being factory workers, which is inevitable now.
\nBut there is a better approach: make your tool intuitive for agents. Getting agents using Beads requires much less prompting, because Beads now has 4 months of “Desire Paths” design, which I’ve talked about before. Beads has evolved a very complex command-line interface, with 100+ subcommands, each with many sub-subcommands, aliases, alternate syntaxes, and other affordances.
\nThe complicated Beads CLI isn’t for humans; it’s for agents. What I did was make their hallucinations real, over and over, by implementing whatever I saw the agents trying to do with Beads, until nearly every guess by an agent is now correct. I’ve driven the friction cost term about as low as it can go. And I’m doing the same for Gas Town.
\nI actually got this idea from hallucination squatting, which Brendan Hopper told me about, where you reverse engineer a domain name that LLMs are hallucinating, register it, upload compromised artifacts, and the LLM downloads them the first time it hallucinates the incorrect site name. If even North Korean hackers understand Agent UX, then it’s probably time you did too.
\nAgent UX is incredibly important and I think most people are sleeping on it. You want your tool to be intuitive to agents. Not because you documented it really well; that’s not ideal. Ideally, your tool is either very similar to other tools they already know, or else it solves a problem exactly the way they like to think about it, and the documentation should just be reaffirming how the agents are hoping it will work.
\nWe’ve covered ways to save tokens, and ways to make your tool more palatable to agents. These are great survival strategies starting right now, this year, today. But it’s not the only way.
\nI think it’s already obvious to everyone that there will be software that thrives not because of token efficiency, but specifically because humans were involved somehow. This software’s value derives from human curation, social proof, creativity, physical presence, approval, whatever. It can be absurdly inefficient because it’s all about that human stink.
\nAnd so a human-curated playlist might beat an AI-generated one that’s just as good and far more efficient in energy terms. Games with real humans will usually win here, as almost nobody wants to play against AIs that are clearly better than humans. Social networks that exclude agents will be popular, etc.
\nThat’s where the Human Coefficient (H) comes in. It’s a different selection pressure entirely — human preference instead of efficiency. You can still benefit from saving cognition, and use the first 5 levers. But there will be a large set of domains where people just prefer a human’s work, even when an AI can do “better.” And that’s your potential sixth lever.
\nFor instance, maybe you decide that even though AIs will be the best teachers soon, some people will insist on human teachers. So you build something in that domain, and try to be cognizant of the other variables–savings, usage, awareness, friction.
\nEven with a high Human factor, your software is up against some stiff competition. In Karpathy’s world, agents can be anything to anyone. They can provide an infinite amount of bespoke content, and they’ll be addictive. You’ll have to work hard to stand out. If it were me, I’d focus on the other variables, which feel easier to control.
\nBut it’s also clear that there will be a lot of terribly inefficient high-H software out there. It could be yours! Good luck.
\nI did leave a lot of categories out of the discussion, ones that I think are in trouble, because there’s no sense in kicking them while they’re down. I think any software that’s intermediating between humans and AIs, or is trying to do any sort of “smart thing” that AIs will soon be able to do themselves, is in real trouble.
\nBut there is so much software that needs to be written. Our demand for new software is insatiable and effectively infinite. We want to cure every disease, model every protein, explore every planet. Our ambition will always outstrip available cognition. Token costs will fall, but we’ll keep moving the frontier, generating more work than there are tokens to perform it.
\nAnother reason for hopefulness is that we’ve already solved the attention problem several times before, from print media to the internet to social media and real-time ads and aggregators. This is just more of the same. You may even be able to benefit from tighter feedback loops–agents should quickly adopt your tool if it becomes known that it genuinely saves tokens, creating virtuous cycles.
\nAnother is that desire paths clearly work, so you don’t need deep pockets for an OpenAI training budget for your tool. Just make your tool work the way agents want it to work. It takes a little time, but it really is a lather, rinse, repeat pattern.
\nFourth, the human coefficient is real. People are going to start hating anything that reeks of agents; it has already begun. Lean into it, if you can. Build your software in a way that creates human connections and creativity, and then it’s just a good old-fashioned marketing problem.
\nAnd last, with six levers to work with, you have a lot of paths forward for survival. I hope this framework has been at least somewhat useful. It was originally framed around thermodynamics and tending towards lower energy states, but Chonko and I failed that exam even worse, so we went with evolution. But the model feels right to me, or at least close.
\nI choose to be hopeful. I think that a lot of humans will be building a lot of software in the coming years, and I intend to enjoy as much of that software as I possibly can. I wish you all luck in surviving whatever’s coming. Build something that would be crazy to re-synthesize. Make it easy to find. Make it easy to use. Then I think you’ve got a solid shot.
\nMeantime, I’ve gotta get back to Gas Town, and I’ll give you a post about that tomorrow. I know a lot of you have been breaking the first two rules of Gas Town, since I keep seeing it in the news. So I’ll get you some updates. Hang in there. In the meantime, go visit gastownhall.ai and the Discord!
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*_RutRrgdWDw0Z9NzD3uWLQ.jpeg\")