TL;DR

A software factory is a system that turns a plan into shipped, reviewed software: agents do the work, people make the decisions.

Ours is Tares, an open-source record of specs, tickets, reviews and decisions, plus a crew of Claude Code sessions that build, review and merge.

In September 2026, more than 95% of the code our team at GlassFlow shipped was written by coding agents, mostly Claude Code and Codex. The agents didn't just autocomplete lines. They wrote whole features, tests, migrations and docs. When something needs to change, we don't open the file. We tell the agent what is wrong and it fixes it. The work didn't go away, but it moved. We used to write code, read every diff, run tests on our laptops and work one task at a time. Now most of our day goes to deciding what to build, writing the plan with an agent, answering its questions and deciding what ships. Most pull requests merge on their own, and someone opens the changed files only when something looks off.

That shift is what lets one person steer several agents at once. It also raises a harder question. We no longer ask whether an agent can write a function. We ask what to build around the agents so that we can trust the code they write. Our answer is a software factory. The rest of this post explains what we mean by that, and how we run our software factory with Tares.

Why steering coding agents by hand breaks down

We sat down as a team and wrote down what got harder once agents wrote most of the code.

• Reviews. Agents review pull requests now, not people. Then who sets the bar, and is it the same bar every time?

• Working across teams. A lot of our communication became Linear comments written by one engineer's agent and read by another engineer's agent. It works, but the comments are long, and it is hard to tell when something actually needs you.

• Many agents in one repo. Usually fine, until two of them change the database migrations at the same time.

• Knowledge. The architecture lives in people's heads and in long prompts, so every new session starts from zero. Integration tests still run on laptops or in GitHub Actions.

Some of us had already patched these problems by hand. We wrote guardrails that reveal the architecture to the agent step by step. We had Claude Code post its updates to Slack. We kept one long-running session open that watches Linear for mentions. Each of these patches was a piece of a factory, and we wanted the whole thing.

What is a software factory?

There is no settled definition yet, so here is the one our team agreed on.

A software factory is a system that turns a plan into shipped, reviewed software. Agents do the work. People make the decisions.

The important word is system. A factory is not one clever prompt, and not one very long Claude Code session. It is a set of roles, rules and records that keeps working when you close your laptop, and that you trust enough to let it merge. Think of a real factory. You don't stand next to every machine. You design the line, set the quality bar, and get called when something needs a decision.

When we listed what a factory has to get right, we ended up with six things.

1. Opinionated. It knows what to build because there is a spec and a plan before any code. Its skills and rules are written down, not retyped into every prompt.

2. A fixed bar. Every change is tested and reviewed the same way, so "done" means the same thing on Monday and on Friday.

3. No drift. The work stays on the plan. Changing the plan is a decision someone makes on purpose.

4. Plays well with others. Each action has one owner. One agent reviews, one merges and one deploys. Nobody steps on a teammate's work.

5. Runs on its own. It keeps going when you walk away, and when a session stops it picks up where it left off.

6. Earns trust. Anything it decided without you is written down, so you check it at the end of a milestone instead of watching every step.

The word factory fits because the parts map almost one to one. An order and a blueprint become a spec, a plan and milestones with acceptance checks. The line manager is an orchestrator that hands out the work. The stations are builders. Quality control is a reviewer plus CI. Shipping is a releaser. And the logbook is a record of every ticket, review and decision. The logbook is the part people forget, and it is the part that makes the rest trustworthy.

How a software factory works, end to end

You plan with an agent and answer questions. The orchestrator hands out the work, builders open pull requests, the reviewer sends changes back until a pull request passes, and passed work merges. Every station writes to the record underneath.

How we run our software factory with Tares

Our factory has two parts. The crew is a set of Claude Code sessions running in the background on your own machine, on your own Claude Code login. Tares is the record. It holds the spec, the plan, the tickets, every review, every assumption and every answer you gave. The crew does the work, and Tares remembers it.

Planning a project

Every project starts with one command in the repo. Say you run a small link shortener, a service that turns long URLs into short codes, and you want to know how often each short link gets used. You would start the project with this command.

tares factory spec "add a click counter that counts each redirect and shows it at GET /links/{code}/stats"

tares factory spec "add a click counter that counts each redirect and shows it at GET /links/{code}/stats"

tares factory spec "add a click counter that counts each redirect and shows it at GET /links/{code}/stats"

tares factory spec "add a click counter that counts each redirect and shows it at GET /links/{code}/stats"

That opens a spec session in Claude Code. It reads the repo, then interviews you one question at a time, each with a suggested answer. A second model attacks the plan before it is written. The result lands in Tares as a spec, milestones with acceptance checks, and tickets that each name the repo they change. The session ends by asking whether to hand the plan to the crew. You say yes, and from there you don't assign anything.

Building, reviewing, merging

• The orchestrator picks up the project and starts a builder for each milestone and repo. When a builder is stuck, the orchestrator answers first.

• A builder works its tickets in order, one pull request per ticket, on its own branch. When the plan doesn't cover something, it picks the sensible answer, records it as an assumption and keeps going.

• The reviewer reviews every pull request to the same bar, checks that the tests would actually catch the bug, and posts its verdict on the pull request. Optionally, Codex challenges each review as a second model.

• Once the verdict passes and CI is green, the builder merges its own pull request. If you want every merge to wait for your yes, that is one setting per crew.

• A releaser is optional. Without one, the crew stops when the work is merged to main.

In a small test run on a link shortener, planning took 7 minutes, the first ticket merged 7 minutes after the hand-over and the second one 5 minutes later. We answered only one question, at the end, and it was whether the work was done.

Keeping it running

Claude Code stops an idle session after about an hour, so the crew plans for it. A watch brings back any station that stops, under the same name. The orchestrator wakes every 20 minutes to check for new projects, stalled tickets or merged pull requests that unblock the next one. A revived session reads the project on Tares and carries on where the last one stopped. This is why the record matters. Sessions come and go, but the record stays.

Talking to the factory

The orchestrator is the only session you need to talk to. It brings you what needs you, one question at a time, with th

tares factory crew attach orchestrator

tares factory crew attach orchestrator

tares factory crew attach orchestrator

tares factory crew attach orchestrator

That also fixed our noisy-comments problem, because you only hear about what actually needs you. One crew serves every project you give it, at the same time. Run Tares on your own machine, or put the record in Tares Cloud so your team shares it while the crew stays on your machine.

What stays with people

Agents do the work, but some decisions stay yours. You always decide what to build and why. Secrets and billing, production and real data, and contacting a new person or channel also stay with you.

Then there is a dial you set per crew. Does a pull request merge on its own after review and green CI, or wait for your yes? May the crew deploy, and to staging only or production too? Which extra rules always apply? Start careful and turn it up as the record earns your trust.

How to know your agents’ code can be trusted

We look at four signals.

1. Tests that prove the change, and a reviewer that checks the tests would actually catch the bug, not just pass.

2. An agent that opens the app in a browser and takes screenshots.

3. Acceptance checks that run against a deployed app, not someone's laptop.

4. A list of assumptions. Every time an agent hit something the plan didn't cover, it picked the sensible answer, wrote it down and kept going. At the end of each milestone you read that list and keep or change each one. That is how you find a wrong turn before it reaches staging.

If you want to start this conversation in your own team, these are the six questions we used.

1. What share of last week's code did you type yourself?

2. Who reviews the pull requests, and to what bar?

3. How do your agents work with your teammates' agents?

4. What makes a change done? Is it tests, screenshots or a staging deploy?

5. What will you never hand to an agent?

6. How do you notice when an agent took a wrong turn?

Your answers are your factory's spec.

Run your own software factory

You need macOS or Linux, Claude Code signed in on a plan that allows background sessions, and the GitHub CLI signed in. You don't need an Anthropic API key, because the crew runs on your Claude Code subscription.

The steps below are the short version. The get-started guide in the Tares docs walks through each one in more detail.

1. Install Tares.

   uv tool install tares     # or: brew install glassflow/tap/tares

   uv tool install tares     # or: brew install glassflow/tap/tares

   uv tool install tares     # or: brew install glassflow/tap/tares

   uv tool install tares     # or: brew install glassflow/tap/tares

2. Start Tares, and in a second terminal the MCP endpoint the crew talks to.

   tares up
   tares mcp --transport
   
   

   tares up
   tares mcp --transport
   
   

   tares up
   tares mcp --transport
   
   

   tares up
   tares mcp --transport
   
   

3. In your repo, check the setup and start the crew. It asks a few questions first, like whether it may merge on its own.

4. Plan something small and hand it over.

   tares factory spec "what you want to build"

   tares factory spec "what you want to build"

   tares factory spec "what you want to build"

   tares factory spec "what you want to build"

5. Follow it at http://127.0.0.1:8787/crew, or attach to the orchestrator with tares factory crew attach orchestrator.

Want a safe first project? Make a copy of our link shortener starter and ask the crew for a click counter. On Tares Cloud, replace step 2 with tares login. The full guide is in the Tares docs, and the code is on GitHub.

Our factory is always a work in progress. We keep improving it, and most improvements arrive as new crew members that take on another part of the work. Which crew members would help in your team? Leave your ideas in the comments, and we will use them to decide what to build next.