Tuning the Factory

In Back in the Saddle I rebuilt Software Factory in fifteen minutes and shipped the first ticket by 2 AM. With the foundation in place, the next three days were fast follow-ups: I filed 27 improvements as tickets, and the Factory's agents designed, built, tested and merged them while I reviewed from the board.

Friction in, ticket out

Between October 6 and October 9, Software Factory merged 27 tickets for its own improvement, and half of them went from filed to merged in under two hours. The repository took 85 pull requests in the same stretch.

The rule was simple. When something in the Factory annoyed me, I didn't open an editor. I filed a ticket on the same board my game tickets use, usually a screenshot and a few sentences. Design asked its questions, I approved a plan, and Implementation and Testing did the rest. I came back at Final Review.

I wasn't the only one filing. The Testing agents opened 8 of the 37 SF tickets themselves, for bugs they found that the ticket in front of them didn't cause.

The four slowest weren't hard. I filed them between 9:30 PM and midnight, and they sat overnight until I was back at the board to answer and approve.

One reply, 77 minutes

One ticket shows the loop at its best: a screenshot and five sentences at 11:16 AM, merged at 12:33 PM, with one reply from me in between. The Machines page had grown a tall block of CPU, memory and disk settings. I circled it, drew an arrow to the title bar, and asked for pills there instead.

Two minutes later Design asked four scoping questions, each with a default it would use if I stayed quiet. I answered all four in one reply. The one that mattered changed the design: pill colors should show how the machine itself is doing, not how close it is to my targets.

Seven minutes later the design was up. It opens with what I decided, in plain words, then numbered paragraphs I can strike or quote, then seven mocks that each say what to look at.

Machines that report on themselves

Seven tickets in three days turned the Machines page from a list of settings into a health view I can read at a glance. Every one started as something I noticed while watching my own PCs.

The pins answer a question every team lead asks: does a passing test on one machine mean the same thing on another? Each project now keeps a small file pinning the exact Godot, Android SDK, Node and other tool versions it needs. Each machine card says "In parity" or "Out of parity". A check runs every night at 3 AM, runners fix drift between jobs, and I only hear about it when they can't.

Balancing came from the same habit of watching. The balancing change makes a busy machine wait up to five minutes so an idle one can take the next job first.

A supervisor on the floor

The biggest addition is a shift supervisor: the Factory Agent. It handles the questions and failures that used to land on me, and it tells me which calls it made so I can check them.

It also spots problems across projects. On an Upwardly Math ticket, I asked why the Design agent couldn't look up our content. Within two minutes it found the cause: the project's tools were set up only for Claude sessions, and that job ran on Codex. That was a Software Factory problem, so I asked it to file the ticket. It couldn't yet, so it wrote one ready to paste. I filed it at 2:10 PM, and it merged at 3:39 PM.

I talk to it with @Factory on any ticket, in a general Messages thread where it answers everything, or under its shift reports. A ticket now in Testing closes that gap: the supervisor can create tickets itself. Anything it files without my direction lands in Backlog, and only I can move it into real work.

A memory with a firewall

Memory now has two kinds of store, and a wall between them. Each project keeps its own notes, and the supervisor keeps a separate pool about how I make decisions.

The wall is deliberate. The supervisor's notes record my judgment: what I agreed with, what I corrected, and why. Phase agents get that judgment the way a team gets a manager's, through the supervisor's answers when they ask, not by reading its notes.

Project notes still work the way they did. When I answered a game ticket's question about building a signed app, the Codex implementer saved my answer to the game's notes, linked to the thread it came from. All of it lives in my own Google Cloud project, and I can edit or delete any note.

The shift report

Twice a day the supervisor writes me a director's report on its last 12-hour shift. The ticket that added it asked for "a human readable and simplified summary", and it went from filed to merged in 2 hours 15 minutes. Shifts run 8 AM to 8 PM and 8 PM to 8 AM Eastern.

The first version was eight headings, from "Needs your decision" to "Next shift". It was thorough, but slow to scan. So at 2:04 PM on October 9 I filed a follow-up: give me an executive summary first, and keep the detail as an appendix I can follow links into. It merged at 5:47 PM, and the 8 PM report was the first one written the new way.

Now each report opens as a printable Shift Brief: the shift in one paragraph, what each project delivered in plain words, how the work went compared with a usual shift, and what needs my attention. The original sections follow as the appendix.

An unread report puts a (!) on the Shift Reports tab. Each report has its own discussion, so I can push back on a call right there and the supervisor answers.

Reading the finished work

The Tickets report is where I look back. It lists every ticket with lead time, agent time, my turns and the agents' turns, tokens, estimated cost and, as of this week, time spent in each phase. It filters by project, strategy, provider and model, and sorts on any column.

Three tickets from this week show why I watch turns:

The pills and the icon counts were clear asks with a picture attached. Renown was an open-ended ask about a hard design problem, and it took seven design versions and nine of my replies to get right. The report doesn't judge that. It shows me which kinds of tickets need more of me up front.

Deploys from the board

The Deployments page shows what's live for each project and what's waiting to ship, and one button deploys it. I filed the ticket at 10 PM on October 7, and it merged at 10 AM the next morning.

My projects don't deploy the same way, and the ticket said so: "Not all repositories work the same way." Software Factory merges to main with no auto-deploy, Upwardly Math promotes its preview branch to production, and the game builds a signed Android app. So each project picks one of three deploy styles: merge a branch into a target branch, start a GitHub Actions workflow, or run an agent that builds and signs a release, which the runner then publishes.

I didn't configure those styles by hand. After it merged, I told the supervisor "you should have access to build these. Please do so." Seven minutes later it had built all four deploy setups, each posted with the decision it was based on. That night the game's first releases failed, and each deploy thread said exactly which step broke and why. That made the fix a small change to the release instructions instead of an evening of digging, and the next deploy produced a signed release.

Discussions that work like a team

I can now talk to several agents in one message, the way I'd address two people in a meeting. Every agent I tag wakes up, and each is told which part of the message is its own and who else is answering. On the ticket for the new phase-time columns, one message did two jobs:

@Design Your recommendations are approved.

@Factory how confident can we be to historically backfill these columns? If we can do so accurately then let's do it. Otherwise leave blank

A minute later the answer was in the thread: the old timestamps include setup and lost retries, so a backfill would look precise and be wrong. The columns stay blank for older tickets. Seven minutes after my message, the design was up for review.

The agents talk to each other too, and Testing has become the team member who files what it finds. While testing the machine-stats pills, the tester hit three failures that ticket didn't cause. Instead of failing it, it filed each as its own ticket:

The pills still shipped at 12:33 PM, and all three spin-off tickets were merged by 1:17 PM.

What fast iteration taught me

The Factory got better fastest when I used it the way I'd want a team to use a process: every complaint became a ticket, and most came back merged within a few hours.

In Back in the Saddle I went back to running a board. Three days later I'm doing what I'd do with any product I ship: watching it in use, listening to the feedback, and tuning it, or changing course when the data says to. The Factory is no different.