When the Car Comes Out Broken, Fix the Factory, Not the Car

A car rolls off the end of the line with a door that does not close. There are two things you can do.

You can fix the car. Send someone with a rubber mallet, bend the hinge, and ship it. That works once. Tomorrow the next car comes out with the same door.

Or you can walk back up the line, find the station that hangs the doors, and fix the station. Then every car after this one has a door that closes.

The first instinct is always to fix the car. It is right in front of you, and it is faster. But it is the wrong move. In Inside the Software Factory That Writes All My Code, I wrote about the andon cord: any worker at Toyota can stop the line when a defect appears. Stopping the line is half of the idea. The other half is what you do next. You fix the process, not just the part.

With coding agents, the factory is the workflow. It is the issues, the roles, the AGENTS.md files and the skills. When an agent ships something wrong, I do not edit its output by hand. I fix the instructions that produced it, so every future agent does it right, not just this one.

This post is about how that works in practice, in the repository behind this site. Then it is about why I run it all from the wrong control room.

The factory, in three roles

The factory for ryanxcharles.com has three roles. Each one is an SI agent in its own chat session.

Issues. I open one “issues” agent. It reads the repository and the open work, and I talk to it about what I want. It asks questions, then files GitHub issues with a clear outcome and a way to verify it. This post started that way: issue #5 holds its thesis, its outline, the facts to check and how we know it is done.

Code. Several code agents run in parallel. Each one asks the queue for the next issue, claims it, and makes its own Git worktree on its own branch. It posts a plan on the issue, then works in checkpoint commits. Each checkpoint builds, passes its tests and is pushed before the next one starts. When the work meets the issue’s criteria, the agent opens a pull request.

Review. Several review agents run in parallel too. Each one claims a pull request, checks out the exact commit in a separate, clean worktree, and runs the checks itself. It does not trust the coder’s screenshots. It either requests changes with findings, or it passes that exact commit. A pass merges it. After three rounds of changes, the reviewer passes the work or stops it for me.

My job becomes two things: writing issues and making decisions. When an agent needs a decision only I can make, it marks the issue needs-human and moves on to other work. The issue waits for me.

All of it runs through one command in the repo, rxc.nu. It hands out work, records who holds what, opens pull requests, submits verdicts and enforces the merge rules. Every agent uses it the same way I would.

Claims matter more than they sound. A claim is recorded where every agent can see it, so two code agents never take the same issue and two reviewers never judge the same pull request. When an agent crashes, the next one with that name resumes from the claim and the branch, not from my memory of what it was doing.

Skills are the tooling on the line

A station on a car line is a person plus tooling: jigs, fixtures and torque wrenches set to the right value. The tooling is what makes the hundredth car the same as the first.

For SI agents, the tooling is skills. A skill is a short Markdown file in the repo that teaches an agent how to do one job here. There are two kinds, plus one shared file.

Code skills say “our patterns work like this.” The coding skill tells an agent how to work in this repo: “For every step, inspect the diff, run the checks appropriate to that step, make a Git commit describing what it accomplishes, and push it.” It names the exact build and test commands, and it requires before and after renders of every page a change affects, at 390 and 1440 pixels wide.

Review skills say “good code in this part of the repo looks like this.” The general review skill tells a reviewer to compare the renders itself, not rely on the coder’s. A narrower one covers routing. This site is prerendered React Router served as static files, and that skill knows it. A changed route must work both ways: from a fresh tab, which must return the right HTML with status 200 before any JavaScript runs, and from a click inside the running app. An unknown path must return 404. Nobody has to remember that. The skill does.

AGENTS.md holds the shared rules. Keep the main checkout on main. One worktree per issue. Never deploy without me. Preserve the authored posts, redirects and feeds. Every role reads the same file, so the coder and the reviewer agree on what “right” means before either of them starts.

Why write this down instead of telling each agent? Because a correction in a chat dies with the chat. The agent that heard it does better for an hour. The next agent, in a new window, makes the same mistake. A correction in a skill is read by every agent that does that job, on every run, in either company’s app.

Fix the factory, not the car

The test is one question. When an agent gets something wrong, ask: would the next agent, starting fresh, make the same mistake? If yes, the defect is not in the output. It is in the issue, the skill or the rule. Fix it there, commit the fix, and let the output be fixed by the line like any other work. It takes a few minutes longer the first time. It saves those minutes on every car after it.

Here is what fixing the factory looks like. Three examples from today, all in this repository’s history.

The motion rule. The old site had a motion menu in the header, with four modes saved in the browser. Before the redesign, AGENTS.md said that motion stays “controlled by explicit site settings”. The redesign issue told the agent to keep “the existing motion menu”. So the code agent kept it, restyled it, and wrote the rule more firmly: “All motion follows the site’s explicit motion setting.” The agents did their job. The rule was wrong. This site does not have enough motion to need a switch.

I could have opened the code and deleted the menu. Instead I asked the issues agent to file #4. It removed the widget, kept the motion on for everyone, and rewrote the motion sentence in AGENTS.md. It also changed the tests that expected the menu, on purpose, so they check the new behavior. The car got fixed, but so did the station. No future agent will read that rule and keep the menu again.

The GlyphRain change. The old site had GlyphRain, an animated background. One minute after the redesign issue was filed, I decided the new design would not use it. I did not open a chat with the code agent. The decision went onto the issue, as a comment and in the issue body. The code agent read it when it claimed the work. It removed GlyphRain in its first design checkpoint, and it replaced the old GlyphRain rule in AGENTS.md later in the same pull request. The issue is the channel. A decision that lives on the issue reaches whichever agent picks it up, including one that starts after a crash.

The upstream sync. The workflow itself is code, and it has its own factory. rxc.nu is a port of the tool we use at Astrohacker. Early this morning, before any of the work above, I synced it with a fix from upstream. Before, a passed pull request still waited for someone to merge it. Now the reviewer that passes it merges it right away, the coder can finish the merge if the reviewer cannot, and an agent that restarts finds the work that merged while it was down. That one commit changed the skills, AGENTS.md, the tool and its tests. It did not fix any car. It fixed how every car moves down the line.

You are reading a car from this factory

Here is the part I have not told you yet.

The site you are reading was redesigned by this factory this morning, end to end. Here is the timeline, from GitHub, on Monday, November 9, in Central time:

• 6:22 a.m. The issues agent files #1, “Redesign every page of ryanxcharles.com in the Astrohacker brand system”.
• 6:26 a.m. A code agent claims it and posts a plan with six checkpoints.
• 6:27 to 7:03 a.m. Nine checkpoint commits land: before renders, tokens and fonts, the header and footer, the home page, the blog, the other pages, motion and icons, and after renders.
• 7:04 a.m. Pull request #2 opens: 103 files changed, 4,717 lines added and 1,771 removed, with 42 before and after renders committed for review.
• 7:22 a.m. A separate review agent passes the final commit and merges it. GitHub closes the issue.
• Before 7:36 a.m. The site is live in production.

About an hour and a quarter from issue to production. No code written by a human.

That is not the whole story, and I want to be precise about it. I asked for the redesign. I made the GlyphRain decision. I approved the deploy, because in this repo only I can. And the motion menu shipped, which is why issue #4 exists. The factory did not replace my judgment. It turned my judgment into a redesigned site while I did other things.

And the entire factory was run from chat windows.

Why chat windows, for now

I run every role in the native ChatGPT/Codex and Claude apps. Today, that is the cost-effective way to run many sessions on the strongest models. But those apps were built for one conversation, not a factory. The friction:

• I start every station by hand. Each agent is a new chat. I open it, tell it its role, and name it, like “claude-5 (code)”.
• I keep identities straight. Two agents with one name step on each other’s claims. The tool checks, but I pick the names.
• There is no view of the line. The apps list chats. They do not show the queue, who holds which issue, or which pull request waits for a verdict. I run a status command to find out.
• Agents poll. Waiting agents check GitHub about once a minute. Nothing wakes them when something happens.
• Permission prompts. An agent stops to ask about a command it ran a hundred times yesterday.
• I switch tabs to find who is stuck. A stuck agent looks like a busy one until I open it.

In My Computer Is a Team of Super Intelligent Agents, I wrote, “The harness matters less than you think.” I still believe it. The rules are still the factory, and a good harness cannot save bad rules. But the harness decides how many stations one person can run. In chat windows, my ceiling is the number of tabs I can keep in my head.

The harness I want

This is a wish list, not a product:

• Roles as objects. I define “code” and “review” once, with their skills, permissions and model, and spawn four of one and three of the other against a queue. Each gets a unique name automatically.
• A live board. Issues, claims, pull requests and verdicts on one screen, with each agent’s last action.
• Events, not polling. A new issue, commit or verdict wakes the agent that needs it. An idle agent costs nothing.
• Per-role permissions and budgets. A reviewer can build and test but not push. A coder cannot merge. Each issue has a cost limit. The harness enforces it, so I am not asked.
• Escalate only when needed. I hear about an issue when it is marked needs-human, and not before.
• Edit the rules in place. When I fix a skill or AGENTS.md, every station picks it up on its next item. Fixing the factory becomes one action.

Who’s building it

I checked each product’s own docs this week. Several have built pieces.

Grok Bot is the closest commercial product I know of, and most of my Astrohacker team already runs there. Each Bot has its own chats and role memory, skills are one library shared by all your Bots, and a routine can start a Bot on a GitHub event or a webhook instead of a timer. A harness like Grok Bot could run this workflow with rxc.nu as the queue and GitHub as the alarm clock. What I have not found is a board of claims and verdicts across Bots. Astrohacker is not affiliated with xAI. Grok Bot is a product of xAI.

The others each cover part of the list:

• Claude Code has agent teams with a shared task list, but the docs call them “experimental and disabled by default”.
• OpenAI Codex defines custom agents as files in the repo and can review pull requests against AGENTS.md.
• Cursor cloud agents run in parallel, isolated machines, start from GitHub, Slack or Linear, and have a spend limit.
• GitHub Copilot takes an assigned issue and opens a pull request for your review.
• Devin runs a coordinator that spawns child sessions, each with its own machine and usage limit.
• Factory Missions use an orchestrator, workers and validators.
• OpenHands starts from an issue label or comment, and Conductor runs Claude Code, Codex and Cursor agents side by side in separate workspaces.
• Gas Town is the closest in spirit, with named roles and a merge queue. Steve Yegge’s own advice: “You probably don’t want to use it yet.”
• Google Jules is winding down on December 31, 2026.

The pattern: many of these wake an agent from an event, and most run agents in parallel. I have not found one built around the whole line, with issues, code and an independent review role on one board.

At Astrohacker we are exploring it. Botpenny, a project of ours, explores teams of bots with roles, approvals and budgets across harnesses. Its README is plain: “These are areas to investigate, not implemented features or a fixed roadmap.”

Fix the factory

You do not need to wait for the perfect harness. I don’t. The factory that redesigned this site runs on chat windows, one Nushell script and a handful of Markdown files. The harness will get better. The rules are what you keep.

So build the factory now, with whatever runs your agents. And the next time a car comes out broken, do not reach for the mallet. Walk back up the line.

Here is one concrete first step. Think of the last time you corrected an agent’s output by hand. Write that correction as one sentence in your AGENTS.md, or as a step in a skill, and commit it. Then the next agent starts from it.

That is the whole method. When the car comes out broken, fix the factory.