TL;DR

For a month, I ran my work two ways: through our software factory and through plain Claude Code sessions. Our software factory is Tares, GlassFlow’s open-source software factory for Claude Code: a crew of agents that plans, builds, reviews and ships changes while you answer its questions. The factory shipped five times as many changes a day, took a third of my time per change, cost the same per change, and its changes needed a follow-up fix less than half as often.

The gain doesn't come from a smarter model. It comes from being able to keep many projects moving at once without losing track of any of them.

Everything here ran on a normal Claude subscription, the $200-a-month Max plan, not on pay-per-use API keys. The factory doesn't need API credits: it uses the same Claude Code login you already have. So every cost in this post is a share of that flat monthly plan, not an API bill.

In our last post, what a software factory is, we explained what a software factory is and how we run ours with Tares. The question we've heard most since: is it worth it?

To answer it, I worked both ways side by side, on my own Claude subscription. Planned projects went to the factory. Everything else went to plain Claude Code sessions, the way most developers use it: open a terminal, describe the task, check the result, ship it. Then I measured both, from 5,070 session logs and every pull request they opened. (A pull request, or PR, is one finished change submitted for review. It's the unit of work we count throughout.)

Want to try it? Get started with Tares | Star it on GitHub

Software factory vs plain Claude Code: the results

The factory (October 2026) against plain Claude Code sessions (September and October 2026).

The same 33 hours of my typing produced 392 shipped changes through the factory and 132 through plain sessions.

Cost didn't go up. Both ran on the same Claude plan, $200 a month, and each change used about the same slice of it either way: roughly 20 cents.

Quality went up. 19% of factory changes needed a fix within a week, against 46% of plain-session changes.

For a team lead, that means one person can keep seven projects moving at the same time, at the same cost, with fewer things breaking afterwards.

Why a software factory beats parallel Claude Code sessions as projects multiply

A single Claude Code session is great at one job. With many jobs, the bottleneck is you: starting sessions, checking on them, answering them, remembering what you told which one.

The factory runs a crew of agents. One of them, the orchestrator, is the only one you talk to. It hands work to builders, a reviewer checks every change, and a releaser ships it. In 18 days, one crew shipped work for 12 projects, up to 7 of them on the same day: a web app built from scratch, a desktop version of an existing app, features that touched up to 7 codebases at once, cleanup work, reported bugs and tests that fail at random.

Each row is a project, each dot a day it shipped, sized by how much.

This is what software factories were about long before AI. Michael Cusumano, who studied Japan's software factories at MIT, described them in 1991 as a way to run many projects with one well-organised setup. Coding agents bring that within reach of a single developer. At company scale, Stripe now merges more than a thousand agent-written changes a week.

Before Tares I tried the same thing by hand: I kept a dozen agent sessions open and juggled them myself. On a normal day I typed into 12 of them, on a bad day 29. With the factory it's one to three, and 95% of the time just the orchestrator. It also keeps working when I don't: a third of its changes shipped between midnight and 8 in the morning.

Fewer windows to watch, and one place for questions.

A third of the factory's work shipped overnight, against a tenth for plain sessions (Berlin time).

When a software factory is worth it, and when it isn't

It pays off when you have several projects or a long list of tickets in flight at once, when the work can be planned with clear tests for "done", and when you'd like progress to continue overnight. It also suits teams who want every decision written down in one place.

It's less worth it for a quick one-off fix or an exploratory idea you haven't thought through yet. For those, a plain Claude Code session is still faster.

How a software factory plans work: specs, tickets and plan review

Every project starts with a planning conversation. Claude reads the existing code first, then asks you questions one at a time. Each question comes with the options it sees and the one it would pick.

A real planning question: three options, a recommendation, a one-line answer.

Out of that conversation comes a written plan: milestones, a test for each one that proves it's done, and a list of tickets small enough for one builder each. It also writes down how the work ships and how to undo it if something goes wrong.

Before anything is built, a second agent reads the plan looking for holes: steps a builder would have to guess, tickets in the wrong order, tests that could never fail. On a small demo app it found 8 problems, one of them a release step that could have shipped after a failed test.

One place for every decision

All questions come to one place, the orchestrator, one at a time, each with a recommendation. In 18 days the factory asked me 110 questions. I answered half of them within 13 minutes.

The home page answers one question first: what is waiting for me? (A demo project.)

When a builder hits a choice the plan didn't cover, it doesn't stop and wait. It picks the sensible answer, writes it down as an assumption and keeps going. At the end of each milestone, the orchestrator shows you all of them at once, and you keep or change each one.

End of a milestone: four assumptions, kept or changed in one reply.

You decide how much the crew can do on its own. Tares calls this setting Autonomy. At the stricter level, every change waits for your yes. At the default level, a change goes in once the reviewer approves it and all tests pass. Releases to customers always wait for you.

The difference is big. A production feature run at the strict level took 42 of my answers for 37 changes. Turning a web app into a desktop app, at the default level, took 45 answers for 202 changes.

Autonomy, set per crew.

The crew page: who is doing what, and how much the crew may do on its own.

Shared memory for coding agents: how the factory remembers your decisions

A plain Claude Code session starts from zero every time. You explain your conventions again, and the decision you made last week is lost in an old chat. Tares keeps a record instead: every plan, ticket and review, every assumption, and every answer you gave, in your own words. The agents check it before they act. In 18 days they looked something up in it about 1,360 times.

What the record did over 12 days in October 2026.

It saves you from answering twice. About a third of the builders' questions never reached me, because the orchestrator found the answer in something I'd already decided. Once a safety check was skipped on a change, and the orchestrator refused to ship it: I'd said earlier "only ship when the checks pass", and a skipped check hasn't passed.

It also learns from mistakes. When the reviewer flags the same kind of problem on three or more tickets, Tares proposes a new rule, and once you accept it, every builder follows it from then on. Fifteen rules came out of the first week, on things like missing tests, security and database changes.

Decisions in your own words, and every assumption marked kept or changed.

Each project keeps its milestones, the crew's guesses and your decisions on one page.

The reviewer holds every change to the same bar. It deliberately breaks the code to make sure the new tests would actually catch the problem, and sends back anything that isn't right. A second agent, running another company's model (OpenAI's Codex, or xAI's Grok) then reviews the work too. Every round of findings and fixes is kept on the record.

Three review rounds on one change, every finding and fix kept.

Why didn't a whole crew of agents cost more than one session? Each agent handles one small ticket and carries only what that ticket needs, so each step is cheaper. The crew takes more steps per change, but the steps are small.

Bugs and flaky tests go straight to the crew

When an outside user reported a problem on GitHub, the factory logged it, fixed it, reviewed the fix and shipped it, all within 23 minutes.

The same crew handles this kind of ongoing work alongside its projects:

• Tests that fail at random. Every hour a builder looks at the test failures, files a ticket for each unreliable test, fixes it, and ships the fix once the reviewer approves it.

• Reported bugs. Bugs from our tracker flow into Tares. A builder reproduces each one, fixes it, adds a test so it can't come back, and the reviewer checks it. If it needs a decision, the person who knows that part of the product is asked.

Ongoing work runs through the same crew, and the right person answers.

That last step matters most. The people who know a feature best can ask the factory about it directly. When a colleague asked whether a feature really needed its own service, the orchestrator answered from the original plan in three minutes, with a draft reply.

What we've added since

This post covers October. Tares has moved on since then, and a few of the new pieces deserve their own posts. Watch the Tares repo on GitHub to follow them as they ship:

• Tares for teams. Each developer runs their own crew, everyone shares one record, and a question about a piece of code goes to whoever owns it. (Post coming soon.)

• A home page that shows what's waiting on you. One screen lists what's waiting for you and from whom, and who you're waiting on. You can answer and sign off from the browser.

• Private projects. Sensitive work stays visible only to the people on it, even on a shared team setup.

• The same idea for production. An AI SRE edition watches your live services, raises incidents in Slack and works through your runbooks.

How we measured

• Every Claude Code log from late September to late October 2026, 5,070 files in all.

• Pull requests matched against GitHub. Questions, decisions, assumptions and review rounds taken from Tares.

• Typing time: we counted every 5-minute stretch in which I typed something.

• A follow-up fix is a later change, titled as a fix or a revert, that touches the same files within 7 days.

• Cost: from about 150 plan-usage readings Claude Code reported, we estimated how much work a week of the $200 Max plan covers, then converted each setup's usage into a share of that week. Per change, the factory used about 0.4% of a week, plain sessions 0.35% to 0.6%.

Further reading

• Agentic engineering: 5 terms every AI developer should know, IBM Technology. Software factories start at 9:37.

• AI-DLC: the AI-driven development lifecycle, IBM Think.

• The factory model: how coding agents changed software engineering, Addy Osmani.

• The agentic software factory, BCG Platinion.

• Minions: Stripe's one-shot, end-to-end coding agents, Stripe.

• Building a C compiler with a team of parallel Claudes, Anthropic.

• Software factories and the agentic moment, StrongDM, and Simon Willison's write-up of it.

• Shifting economies: from craft production to flexible systems and software factories, Michael Cusumano, MIT, 1991.

Run your own software factory

Tares is open source. Start with a project that's already planned, or a backlog full of bugs, and let the crew work through it while you answer its questions.

• Get started with the Tares software factory

• Star Tares on GitHub

FAQ

What’s the difference between a software factory and Claude Code?

Claude Code is a single agent session: you describe a task, watch it, and check the result. A software factory like Tares runs a crew of agents instead: an orchestrator you talk to, builders, a reviewer and a releaser, working from a written plan and a record of your decisions. It uses the same Claude Code login.

Is a software factory just parallel Claude Code agents?

No. Parallel sessions alone just give you more windows to juggle: before Tares I typed into 12 sessions on a normal day and 29 on a bad one. A factory adds a written plan, a reviewer on every change, one place for questions and a record of past decisions. With it, I type into one to three sessions.

Does a software factory cost more than Claude Code sessions?

There's no extra bill: the factory runs on your Claude subscription, not on API keys. And it didn't use more of that subscription per change in our data. Each change used about the same slice of a $200-a-month Claude plan, roughly 20 cents, whether it came from the factory or a plain session.

Does quality drop when agents ship changes on their own?

In our month, it went the other way. 19% of factory changes needed a fix within a week, against 46% for plain sessions. Every change is checked by a reviewer and by a second agent, and nothing reaches customers without a person's yes.

How much of my time does it need?

About 5 minutes of typing per shipped change, against 15 for plain sessions, almost all of it in one conversation with the orchestrator. Most of that time goes on approvals and product decisions.

Can I choose what ships on its own and what waits for me?

Yes. The Autonomy setting decides it per crew: either every change waits for your yes, or changes go in after the reviewer's approval and passing tests. A single project can be held to the stricter level. Releases to customers are always yours.

What if the plan changes halfway through?

Tell the orchestrator. The change is written down in your words, and the plan and tickets update with it. When you change an assumption at the end of a milestone, the fix becomes a new ticket that is built, reviewed and shipped like any other.

What happens when an agent gets stuck?

The orchestrator tries to answer from the record first. If it still can't move, say it can't reproduce a bug or needs a product decision, it parks the ticket and asks the person who knows best instead of wasting time.

Does my whole team need to use it?

No. The crew works through normal pull requests, under your existing checks. Teammates see ordinary changes with clear descriptions, and where a codebase needs a person's approval, the crew waits for it.

Is Tares open source, and which models does it use?

Yes, Tares is open source, and the code is on GitHub. The crew runs on your Claude Code login. For review, a second agent running another company’s model, OpenAI’s Codex or xAI’s Grok, checks each change too, and every round of findings and fixes is kept on the record.

What's the difference between running Tares locally and Tares Cloud?

Locally, the record lives on your own machine next to your crew. With Tares Cloud the record is shared, so your team sees the same plans, decisions and reviews, while each crew still runs on its owner's machine.