The Light Factory

I have been for a while coding exclusively with AI Agents and finding ways to improve efficiency, scalability, and reliability. It is not an easy task at all. I also took several workshops and on the way here I have built, broken and reassembled a few projects. There is a lot written about AI Models, and how to code with agents, but there is not so much written about how to leverage those into a professional setup. Some people are calling these Software Factories. I thought that it would be interesting to put down into words some of the things I have learned on the way. In this case, I want to talk about a specific technology called Gas City.

All this did not come easily. This is frontier technology, and it is brittle. Getting the thing to run took more effort that I would like to admit: a lot of attention and small adjustments. Nobody sets this up and walks away on the first afternoon.

But it did run. And once it was running I watched pull requests start appearing on GitHub on their own in a controlled way. One, then another, then two at the same time on different parts of the project, because several agents were working at once and none of them were waiting for me to approve anything. I got to a point where I could step back, and the work kept going.

With everything I have been testing during the last year, I am convinced that this is where software engineering is heading. I went from working with a single agent in a single chat window, approving every step, to more autonomy and parallel sessions to a point in which I became the bottleneck in the process. We are looking at a different monster now. People call it loop engineering. In a few months it will have another name.

From steering to running#

For a year the whole conversation was about making one agent better. Better prompts, more context, tighter feedback in the chat. That work paid off, and steering one good agent is genuinely useful. But it has a ceiling, and the ceiling is me. The agent is only ever as fast as my attention, because it stops and waits at every step. If I am not at the keyboard, nothing moves.

A software factory is the attempt to take me out of that inner loop. The tool I used is called Gas City, and Chris Sells, who runs the company behind it, defines it this way: a software factory is a system for building, validating, deploying, operating, and maintaining production software. The whole pipeline, running as a system, with the agents working inside it instead of waiting on me.

The person whose ideas sit underneath all of this is Steve Yegge. If you have been around a while you know him as the engineer who wrote the Google Platforms Rant, which got passed around the industry for years. He has spent more than thirty years shipping software, at Amazon, Google, and Sourcegraph among others. Early last year he argued that coordinated fleets of coding agents were coming whether we wanted them or not, and then he left and went to build one. When someone with that much mileage stops writing essays about a thing and starts building it, I pay attention.

Gas City describes itself as a town. A city is the whole factory, the thing that runs on your machine and keeps everything alive. Inside it are rigs, and a rig is just one of your projects, a git repo you register so the factory can work on it. The rigs are worked by agents, drawn from pools, so when there is more work than workers the city starts a few more and shuts them down when the work runs dry. The work itself follows formulas, which are methods written down once and then run over and over. City, rig, agent, pool, formula. That is most of the vocabulary, and it is enough to follow the rest.

Two words you will hear are polecat and refinery. A polecat writes the code, a refinery reviews it and merges it. This part is easy to get wrong. Those are terms from Gas Town, the older and fully furnished version Yegge built first and open-sourced at the start of the year. Gas City is the rebuilt engine underneath, and it does not bake those roles in. The documentation is blunt about it: roles are examples, not platform law. Gas City just hands you the parts to build whatever workers you need.

The engine runs on one rule. When a worker is handed a job, it does the job. It does not check in, it does not wait for a good moment, it does not ask permission. It finishes and it is done.

Coordinating through the tracker#

A crowd of agents could coordinate by talking to each other. One finishes, tells the next, they message back and forth to a result. But in reality they coordinate through the issue tracker. Every piece of work is a row in a shared, versioned database, and the agents read and write that database instead of talking. The tracker is a separate Yegge project called Beads. It is MIT licensed, it has been around since late 2025, and by the middle of 2026 it had somewhere past twenty-five thousand stars on GitHub. It sits on Dolt, which is roughly git for a SQL database: versioned, branchable, and mergeable the same way your code is.

One unit of work is a bead. It has an id, a title, a status, a type. On screen it is about as thrilling as this:

bd-a1b2  "Render capital A as ASCII"  [in_progress]  type:task

A row. But the beads point at each other, this one blocking that one, this one a slice of a bigger one, so the whole set is a graph of the work and what depends on what. A graph of rows beats a conversation for a few reasons that add up. Two agents can create work at the same moment without colliding, because the ids are hashes rather than counters. An agent can ask what is ready, meaning everything a bead depends on is already done, and get a clean list back. It claims a bead in a single atomic step, so no two workers ever grab the same job. And when the reviewer sends work back to the coder, that whole handoff lives on the bead itself, not in a chat log somebody has to go find later.

Agents crash mid-task, and they do it more than you would like. If the coordination lived in a conversation, the context dies with it and you are reconstructing what happened from logs. Because it lives in a versioned database, the agent can drop mid-job and the next one reads the record and picks up where it says things stand. The fleet is restartable. It survives its own workers failing, which a room full of chat threads does not.

Making the work into data does more than let the agents coordinate. It is also what lets you watch them.

There is a name for agents working on their own like this, and it comes from manufacturing. A dark factory is a plant automated to the point that it can run with the lights off, because the only thing on a factory floor that needs light is the people, and there are no people. Yegge borrows the term for software: coding agents working in the background, autonomously, with nobody watching. It only feels dark because the work is happening in rooms with no humans in them, but the system makes everything auditable: fast, tireless workers firing away, and you only find out what they did when something breaks and you go digging. So in a way, Gas City builds the dark factory and leaves the lights on anyway. You can open up any worker while it runs, and nothing is hidden. The reason the lights can be on is the dull decision from a minute ago: because the work already lives in a versioned graph, the same database that lets the agents coordinate is the one that records what each of them did, in order, permanently. And the thing that coordinates them is the thing that holds them accountable.

Did I mention this is still a bit brittle, and getting it running was most of the work? Then there is also the cost. The loop does a lot of back and forth before a single task becomes a merged pull request: a worker implements, a reviewer checks, it comes back with a reason, a fresh worker fixes the flagged thing, around again until it passes. That churn is what makes the output trustworthy, and it is also what makes it potentially expensive. In one of my experiments I left my factory running on its own for about three hours, came back, and I had hit my daily usage limit while the job as a whole was still not done. It had been working the entire time and most of the work was done, but not complete. The cost of the process, the constant back and forth of the agents to get to a final valid result, is real.

Gas City reached its 1.0 only in the last few months and ships new releases at a steady clip, so anything specific I tell you about it is probably already a little stale by the time you read it. That is the tax on standing this close to the front.

Where this goes#

So, this is real enough to build with, and early enough that you should expect the ground to move under you. If those two halves cannot sit comfortably together for you, this is not the season to put a critical path on it.

The direction, though, I am no longer unsure about. The race to make one agent smarter is not where the leverage is. The leverage is in running many ordinary agents so they stay coherent, and the piece that makes that possible is the least glamorous thing in the building: the issue tracker, promoted from the place you file bugs to the thing the whole fleet runs on and is judged by. I spent a year getting good at steering. I think the next year is about learning to build the loop and then step out of it.

Reading about it only gets you so far. In the next piece I start from an empty directory, stand a factory up, hand it a small project of my own, and watch it open a pull request on its own. It cost me a good amount of effort to get there the first time. I want to see how much of that I can rebuild from scratch now, and where it fights me.