For most of computing history, getting software built was a bad bet. Projects ran late, blew the budget, and still missed what users needed. If you were a small business, you usually did not get a custom system at all. You bought a generic SaaS, hired a cousin who "knew Excel," or went without.
On August 19, 2026, Thariq Shihipar — engineer on the Claude Code team at Anthropic — named the counter-promise: the software factory. Companies whose core competency is not software, he argued, need software to be a reliable, predictable process. That is the factory. Building a net-new product remains "an unreliable and risky, but profitable business."
Those are two different jobs. The phrase only earns its keep if you keep them apart.
TL;DR
| Question | Direct answer |
|---|---|
| What is it? | A repeatable agent pipeline that turns a specified software job into a process with gates, not a one-off chat |
| Who is it for? | SMBs and non-software companies (and departments inside large firms) that historically could not buy a good custom build |
| What is it not? | A claim that startups shipping new products become cheap, on-time, or low-risk |
| vs vibe coding | Vibe coding is ad-hoc prompting. A factory is harness + skills + tests + review |
| vs software-for-one | Personal/household apps. Factory is business internal software at agency-replacement prices |
| What's inside? | CLAUDE.md, thin skills, subagents, loops |
| Is it proven? | The machinery exists. The SMB outcome is a thesis, not a census |
What people are actually asking
The launch-thread mix-up is the same one that hits every agent slogan:
- "Does this mean more slop?" — If the factory is just vibe coding with a nicer name, yes. If it has tests and a reviewer agent that can fail the job, it is a process, not a vibe.
- "Is this for startups building products?" — Thariq's own second post says no. Product invention stays a gamble.
- "Isn't this just replacing a six-person agency?" — That is the SMB story. Enterprise already bought expensive, late software. SMBs skipped the market.
- "Do the models still lie and skip steps?" — Yes. Opus-class agents still invent background work and miss checks. A factory that cannot detect that is a slide deck.
The useful reply in the thread was the SMB line: enterprise always found a way to get software built — badly and expensively. SMBs went without. A factory does not have to "upgrade" Salesforce. It has to give a 12-person shop its first internal tool that is not a shared Google Sheet.
That is also true for departments inside Fortune 50 companies. A logistics team that cannot get on the central IT roadmap is an SMB wearing an enterprise badge.
What a software factory is
Borrow the factory metaphor only as far as it is honest. A physical factory is not "we hope the car appears." It is a line: parts, stations, gauges, scrap bins, a definition of done.
An agentic software factory is the same shape applied to code:
intake (ticket / interview)
→ spec artifact (not a 2,000-word prompt)
→ implement (coding agent in a worktree)
→ test / review (separate agent or CI)
→ ship or reject
→ loop until the gate passes or the budget dies
The model writes a lot of the code. The reliability is supposed to come from the line around it: loop engineering, an agent harness, termination conditions, and artifacts that survive a session. That is Thariq's other public stack — thin prompts, thick artifacts, thin skills — applied to a business process instead of a single chat.
If those files are not in the repo, you do not have a factory. You have a talented intern with amnesia.
Two jobs Thariq split on purpose
| Job | Reliability bet | Who pays | Failure mode |
|---|---|---|---|
| Internal / SMB software | Process can become predictable | A business that needs a tool, not a product company | Wrong spec, no tests, "done" means "looks like an app" |
| Net-new software products | Still unreliable and risky | Founders / venture | The market does not care that your loop is pretty |
This is the load-bearing distinction. A bakery that needs a delivery scheduler is a factory candidate: the need is known, acceptance can be written down, and "good" looks like fewer missed drops. A team inventing the next vertical SaaS is still in the old world — late, over budget, and possibly wrong about the user.
Treat "software factory" as a synonym for "AI will make startups easy" and you will ship slop into production and call it industrialization.
What it is not
Not vibe coding. Vibe coding (Karpathy, 2025) is prompt, run, shrug. Fine for a prototype. A factory that cannot fail a PR is still vibe coding wearing a hard hat.
Not "software for one." Software for one is Robin Sloan / home-cooked apps for a household. Adjacent economics (agents dropped the cost of writing), different buyer. An SMB factory is closer to replacing a boutique consultancy than to a calorie tracker for yourself.
Not Garry Tan's gstack, exactly. gstack is a packaged sprint of slash skills — office hours, plan, review, QA, ship. That is one implementation of factory-shaped process. Thariq is making an economic claim: non-software companies deserve a reliable line, not a bag of prompts.
Not Microsoft's 2004 Software Factories. That literature was software product lines and DSLs: generate variants inside a family. The 2026 phrase is about one-off internal systems becoming cheap enough to exist. Same word, different thesis. Do not cite Greenfield/Short as if they predicted Claude Code.
Not a finished SMB census. YC's Fall 2026 RFS already asked for a cloud for small software — deploy and share bespoke agent-built tools as easily as a doc. That is the missing distribution layer. A factory that writes code you cannot safely give to a nontechnical owner is a prototype mill.
What you actually build (this week)
You do not buy a "Software Factory" SKU. You assemble the same pieces explainx.ai already documents:
| Station | What goes there | Why it is a gate |
|---|---|---|
| Intake | A ticket, or an interview skill that refuses to code until the need is named | Stops "build me an app" from becoming a 40-file hallucination |
| Spec | A durable artifact (HTML/Markdown spec, fixtures, "done when") | Thick artifact, thin prompt — Thariq's own rule |
| Implement | Coding agent in an isolated worktree | Parallel jobs cannot clobber main |
| Check | Tests, linters, a reviewer subagent, CI | The factory's scrap bin |
| Stop | Max steps, max dollars, or "gate passed" | Termination conditions beat infinite loops |
Start with a first agent loop on one painful internal workflow — invoicing exceptions, inventory sync, a report nobody wants to rebuild in Excel — not a rewrite of the company's website. If you cannot write a failing test for "done," you are not ready for a factory. You are ready for a prototype.
The objections that are fair
Slop volume. More agents means more code. Without review gates, you get more incredibly unreliable software, not less. The factory is the gates. If you skip them, Thariq's critics are right.
Models still cheat the process. Replies in the same thread reported Opus-class runs that claimed background agents had run when they had not, and errors while context was still mostly empty. A factory that trusts the model's narration of its own work is not a factory. Log the commands. Fail closed.
Indeterminacy. Same prompt, different day, different patch. Seeds and temperature 0 help a little; they do not make the line deterministic like a CNC mill. Predictable process is the claim — same stations, same checks — not bit-identical output.
Downtime and vendor concentration. A line that only runs when one lab's API is up has a single point of failure. That is an ops fact, not a reason the metaphor is empty. Dual-harness and local fallbacks are the unglamorous part of "reliable."
Product companies will still eat glass. If your job is inventing software people pay for, you are in Thariq's second bucket. Agents change the cost of a prototype. They do not cancel market risk. That is consistent with the 2x, not 10x reading of coding productivity: the bottleneck moves to judgment and verification, not keystrokes.
How this fits the rest of Thariq's public stack
Same person, same week as the headless SaaS / charge agents per interaction thesis. Read them as a pair:
- Headless SaaS is what vendors should expose so agents can operate a product.
- Software factory is how buyers who are not software companies should produce the glue that never got built.
One is an API and pricing problem. The other is a process and verification problem. SMBs need both: something to call, and a line that can call it without a six-person shop in the middle.
The takeaway
A software factory, in the sense that is worth teaching, is custom internal software as a gated agent pipeline — aimed at the buyers who historically could not get a custom build at all. It is not vibe coding, not a household calorie app, and not a promise that your Series A gets easier.
If you run an SMB or an ignored department: pick one workflow with a written "done," put tests on it, and run an agent through implement → review until the gate passes. If you are building a product company: keep the factory for internal tools, and do not use the metaphor to deny that the product is still a bet.
Related on explainx.ai:
- Is software dying or changing? Why teams rebuild internally (Aug 20) — the vendor-side loop: cancel SaaS, rebuild, watch customers do the same
- Software for one: personal apps with coding agents — household-scale cousin of cheap custom software
- Headless SaaS for agents, charge per interaction — Thariq's same-week vendor-side thesis
- Thin prompts, thick artifacts, thin skills — the prompting stack a factory actually runs on
- Loop engineering for coding agents
- How to build your first agent loop
- What is an agent harness?
- gstack: Garry Tan's skills factory — packaged sprint skills, not the SMB economic claim
- YC Fall 2026 RFS — a cloud for small software
- 2x, not 10x: LLM coding productivity
- What are agent skills?
Official: Thariq Shihipar on X (August 19, 2026) · explainx.ai loops · skills registry
Definition and quotes reflect Thariq Shihipar's August 19, 2026 posts and public replies as discussed on X. "Software factory" is a metaphor in active use, not a standards body term; treat SMB-outcome claims as a thesis to measure, not a completed market shift.