Personal Software Factory: Should You Build One?

A personal software factory is a setup one developer builds so that AI coding agents can take a task from idea to merged code with little hand-holding: agents with roles, a loop that plans, writes, tests and reviews, and a few points where the developer signs off. In October it became the most argued-about idea in agentic coding. Should you build one? Only if the software you ship is the point. If you want agents doing your everyday work, or you need production code shipped without building the machinery, there are shorter paths, and this post covers both.

Why everyone is talking about personal software factories

The term went from niche to timeline in a few days in mid-October. "ok so today twitter is software factories," Alex Miller wrote on 19 October, adding that he "kinda built a shitty software factory." The same day, Ian Lapham posted a diagram of "what my actual personal software factory looks like," and Ben Vinegar shared "a new AI software factory experiment, modeled after a human eng team": several agents, each with its own Linux VM and a role, a private IRC server, and rituals like daily standups and "review my pr."

Builders followed. Johannes Schickling wrote that "software factories are having a bit of a moment right now" and that he is building a framework "to make it easy for you to build your own software factory." Gojko Adzic published a lights-on software factory boilerplate for Claude Code, and Seb Moska described his as "4 AI workers, each in a locked box" with "2 human gates: the plan and the yes."

The jokes arrived on schedule. "I don't build software factories. I'm the software factory," Lane Wagner posted. Aleksandr asked whether anyone had used one "to do anything other than make harnesses and software factories."

The case against building one

The sharpest pushback is Peter Piekarczyk's essay Personal software factories are a waste of time, which drew 108 points and 99 comments on Hacker News. His argument:

Building the factory is comfortable because "it's close to what you've always been good at," and it often ends the way side projects do.
AI does not remove the hard part of building. "The frustration is just different: miscommunication, building the wrong thing."
The labs are already removing friction from their own products, and "I'm having a hard time competing with that."
If you build one anyway, "it better be for work," where real systems, timelines and "100 different edge cases" justify the effort.

The Hacker News thread split the other way as often as it agreed. Several commenters asked what a software factory even is. One said that "being able to build a software factory is probably a very useful skill," another that "there wasn't ever a better time to build a software factory." Allen Hutchison summed up the middle ground: "the opportunity-cost case is strong, but making one can be a worthwhile hobby," while at work "years of patterns and edge cases may justify an internal platform."

Lights on or lights off

The second argument is about who reads the code. A "dark" or lights-off factory ships code no person reviews. A lights-on factory keeps people at the gates. Tessl put the dark position plainly: "Agents write code faster than we can read it. So the dark software factory says: stop reading."

The evidence so far favours keeping the lights on. An October paper, (When) Should a Software Factory be Lights-off?, built a benchmark of 1,800 review tasks to test whether review agents catch real bugs. The best agent caught 71.9% of bugs within its top five comments, up from 47.7% five months earlier. The authors also found agents weaker on complex changes and bugs that need wider reasoning, with sharp drops on proprietary industry code. Addy Osmani's argument in Own the Outer Loop is the human version of the same point: "The model may write the line, but the Verdict is mine."

For the background on dark factories, see what is a software factory and dark factory software development.

What goes into a personal software factory

The setups shared this month differ in tools but share the same parts:

Part	What it does	Example from October
Roles	Separate agents plan, write code, test and review	Vinegar's agents each have "a role/persona"
Isolated workspaces	Each agent works in its own sandbox or VM	"each w/ their own desktop linux VM"; "each in a locked box"
A coordination channel	Agents hand work to each other	A private IRC server; a task queue
The loop	Investigate, implement, verify, repeat	Osmani's outer loop
Human gates	A person approves the plan and the merge	Moska's "the plan and the yes"
Upkeep	Prompts, permissions and tools change with each model release	The part most posts leave out

The last row is the cost Piekarczyk is pointing at. A factory is not built once. Every new model, tool or repo convention means more maintenance.

How to build a software factory, if you decide to

If shipping software is your job and you want your own line, keep it small:

Start with one repeatable job. Pick work you already do by hand the same way each time, like dependency bumps, test coverage or small bug fixes.
Write down done. A task the agent cannot check against is a task it will finish confidently and wrong.
Give each agent a fenced workspace. Separate sandboxes keep one agent's mistake out of another's work.
Put review where the risk is. Keep a person on the plan and the merge, and scale review effort to the size of the change.
Measure output, not activity. Count merged changes that held up, not agent hours or tokens.
Budget for upkeep. Plan time each month to retune the setup after model and tool changes.

For the step-by-step mechanics, AI agent workflow and single agent vs multi-agent cover how work moves between agents and when more of them helps.

If your work isn't code: a squad instead of a factory

Most people asking for "a factory" don't want to ship software. They want research done, documents drafted and admin cleared, without opening a chat window for every step. That job doesn't need a factory you assemble.

xSquads for Work gives each knowledge worker their own squad of specialised agents to delegate to and review, so they become 10x more productive. The squad runs on your computer, works on your own files and folders, and moves each mission across a shared board from Backlog to To Do to In Progress to Review to Done. Bots propose, you approve, and anything irreversible is escalated to you instead of executed. It is on Mac and Windows, and free with Pro agents. Use cases shows the missions people start with.

If you need production software: a managed software factory

Piekarczyk's own exception is building a factory for work. A managed software factory is the version where the line is run for you instead of being something you assemble and staff yourself.

On this site, that offer is xSquad operating as your code factory. Agents open pull requests you can read. A person reviews before code is merged, and nothing merges without your approval. You add or remove agents as the workload changes. Every output passes through quality gates: automated tests, code reviews, QA validation and human approval. Services describes custom squads that usually take the shape of an agent swarm or a code factory, built around one process your team already runs by hand. The code factory page does not publish a price comparison. Current plans go through the contact form. The full description is in what a managed AI software factory does.

Which one fits you?

Build a personal software factory if you enjoy the tooling, ship software for a living, and will maintain it. Keep the lights on.
Use xSquads for Work if the work is research, writing, planning and admin in your own files, and you want a squad whose output waits for your review.
Use a managed code factory if production software has to ship as pull requests a person reviews, and you'd rather not build or staff the line.

Where these facts come from

Read on 2 November 2026.

Personal software factories are a waste of time (Peter Piekarczyk, 18 October 2026) and the Hacker News discussion.
(When) Should a Software Factory be Lights-off? Benchmarking Code Review Agents on Bug Detection (arXiv, October 2026).
Own the Outer Loop (Addy Osmani).
Lights-on software factory boilerplate for Claude Code (Gojko Adzic, GitHub).
Posts on X: Alex Miller, Ian Lapham, Ben Vinegar, Johannes Schickling, Seb Moska, Lane Wagner, Aleksandr, Allen Hutchison, Tessl.

Frequently Asked Questions

What is a personal software factory?

A personal software factory is a setup one developer builds so AI coding agents can take a task from idea to merged code: agents with separate roles, isolated workspaces, a loop that plans, writes, tests and reviews, and points where the developer approves the plan and the merge.

Are personal software factories worth building?

It depends on what you ship. Peter Piekarczyk argues they are a waste of time for side projects and only make sense for work, where real systems and edge cases justify the effort. Others see building one as a useful skill. Either way, plan for ongoing maintenance as models and tools change.

How do you build your own software factory?

Start with one repeatable job, define what done looks like, give each agent its own sandbox, keep a person on the plan and the merge, measure merged changes that hold up, and set aside time each month to retune the setup after model and tool changes.

What is the difference between a lights-on and a lights-off software factory?

A lights-off, or dark, factory ships code no person reviews. A lights-on factory keeps people at the gates, usually the plan and the merge. An October 2026 benchmark found the best review agent caught 71.9% of bugs within its top five comments, with weaker results on complex changes and proprietary code.

Do I need a software factory if I don't write code?

No. If your work is research, documents, planning and admin, a squad of agents that works on your own files fits better. xSquads for Work gives each knowledge worker their own squad to delegate to and review. It is on Mac and Windows, and free with Pro agents.

What is a managed software factory?

A managed software factory is a software production line run for you instead of one you assemble and staff yourself. On xsquads.ai, that is xSquad operating as your code factory: agents open pull requests, a person reviews before anything merges, and you add or remove agents as the workload changes.