WTF is a Software Factory?
Executive Summary
An interview with Adam Jacob, CEO of Swamp Club, on software factories. The product thesis: turn natural-language intent into deterministic modular automation — typed components, wired workflows, stored queryable data — so behavior runs identically without burning frontier-intelligence tokens, model swaps become one-component refactors, and the loop inverts: a deterministic system that calls out to intelligence when it needs it. The definition: a software factory hands as much of the SDLC loop as possible — ultimately everything but inputs, outputs, and some middle spots — to agents, keeping the system stable, architecture-aligned, and non-regressing; no two factories are the same, which is why the term confuses. The slop-factory objection is conceded for unchanged SDLCs and answered with more structure, not less. The organizational layer is the unsolved part: a trustworthy factory breaks control points, engineers ship without permission, and product people must pivot from directing to reviewing outcomes. On jobs, automation history says demand caps, and no cap has been found for software; LinkedIn could prototype an operating system in a week — but the real opportunity is not faster copies (the vibe-coded Adobe suite has yet to be made better) and factories as a creative outlet. Engineering guidance: black-box tests first (they make refactoring and therefore the factory safe), integration tests stay, unit tests are an open question (ThoughtWorks found agents worse with TDD; strong types absorb the role), and the stance is fix-the-factory, not blame-the-robots — build the machine that builds the thing. Skills are scoped to judgment, taste, and reasoning as measurable pieces, exemplified by an adversarial skill holding a 100 percent Lighthouse score.
Chapters & Key Takeaways
8 takeawaysSwamp compiles natural-language intent into deterministic modular automation, so behavior runs identically without burning frontier tokens — and swapping the underlying model is a one-component refactor of a configurable option.
A software factory hands as much of the SDLC loop as possible — ultimately everything but inputs, outputs, and some middle spots — to agents; no two factories are the same.
The slop-factory critique is earned for unchanged SDLCs; the exit is paradoxically more AI — more automation, structure, and system design.
The organizational transition is nearly unsolved because a trustworthy factory breaks control points: engineers ship without permission, and product must pivot to reviewing outcomes against themes.
No demand cap has been found for software — it is infinite given compute — so faster teams find new work, though nobody knows what it is yet; a faster copy of the same thing is rarely the next version.
Black-box tests are the single most important pre-factory investment; integration tests stay; unit tests are an open question that types and agent behavior may close.
The engineering stance: when a failure class appears, fix the factory, not the robots — you build the machine that builds the thing, and that is still engineering.
Skills are for judgment, taste, and reasoning as measurable system pieces — an adversarial skill holds Swamp's Lighthouse score at 100 percent.
Deep Read
WTF Is a Software Factory?
On Syntax, Swamp Club CEO Adam Jacob defines a software factory — the SDLC loop handed to agents — and shows the mechanics: intent compiled into deterministic automation, black-box tests as the safety rail, the slop-factory exit being more structure, and organizations as the unsolved layer.
Read the full articleInterview Highlights
8 exchanges- Q
Where does Swamp Club fit alongside someone already running Claude Code or Codex?
Wes Bos asked03:30AAdam Jacob answeredAdam contrasts the paths. Firing up Claude with instructions does something, maybe what you wanted; writing a skill fixes the instructions but burns frontier-intelligence tokens reinventing the same loop on every run. Swamp takes the same natural-language intent and converts it into modular automation: typed components, wired workflows, and stored queryable results, so it runs the same way every time without token burn. Swapping the underlying model — say to the Decisions APIs from OpenAI or Cloudflare — becomes refactoring one component's configurable option, reversing the loop: a deterministic loop that calls out to intelligence when it needs it. Skills still describe judgment; Swamp turns the rest into a self-refactoring web of automation that grows from tiny personal agents to bigger behaviors.
- Q
How is Swamp Club priced, and who provides the inference?
Wes Bos asked09:41AAdam Jacob answeredIt is a paid product, per user per month, the hosts note. On inference: you bring your own — Swamp sits underneath whatever agent, harness, or models you already run and plugs into them to provide the durable-automation behavior. Experimenting with building automations does not cost; payment arrives when you actually put it to work.
- Q
What is a software factory, actually?
Scott Tolinski asked10:19AAdam Jacob answeredAdam starts with empathy: five people would give five definitions, which is why the topic frustrates. His community's answer: take the traditional SDLC — figuring out what goes into the product, breaking the work down, flowing through the process to production — and hand as much of that loop as possible, in the end everything but the inputs, the outputs, and some middle spots, to agents that run it on your behalf. Keeping the system stable, producing code that fits the architecture, preventing regressions: that is the stuff of software factories. The shape depends tightly on what the factory produces and on the team — no two factories are the same, and inputs differ too, from tickets and PRDs to goals like 'validate the trust in this system' or standardizing what happens over and over.
- Q
Isn't a software factory just a slop factory?
Scott Tolinski asked17:17AAdam Jacob answeredAdam agrees the criticism is earned — if you keep the same SDLC: the same ten developers, the same Scrum meetings as last year, only now shipping thousand-line Claude PRs nobody understands, poorly aligned to outcomes, with velocity cranked up. That is surfing stuck inside the breakers, constantly murdered by the wave. The way out, paradoxically, is more AI, not less: more automation, more structure, more of the system getting designed — which is why it becomes a systems-design problem. It feels like a slop factory because your lived experience is one; so when someone offers to make the slop factory go faster, the honest answer is 'absolutely not — that is the thing killing me.'
- Q
How should a company with hundreds or thousands of engineers start re-architecting around this?
Scott Tolinski asked19:07AAdam Jacob answeredAdam frames two emerging frontiers — the labs, and regular mortals figuring out how to build working systems with the LLMs they receive — and says very few, maybe nobody, has solved the organizational side. The hardest part is not technology: the transition breaks existing points of control. With a trustworthy factory, engineers could implement, refactor, and ship whatever feature comes to mind without permission — so product people, whose job was staying ahead of engineers and telling them what to do, feel bad, because nobody stays ahead of that output rate. The organizational pivot: product reviews outcomes against themes, and because rework is cheap, changes what it dislikes. That restructuring is so weird that few have figured it out.
- Q
If everyone runs 10x faster, what do companies do with 10,000 engineers — or do we just have fewer engineers?
Scott Tolinski asked26:01AAdam Jacob answeredNobody knows, Adam says; his belief is yes, they can find the work, but nobody knows what it is yet, because an order-of-magnitude jump breaks everything. The history of automation — a thousand years, digital or not — is that jobs change and we do more, capped only by demand, and no demand cap has been found for software: given compute, software is infinite, not a finite resource. Concretely: LinkedIn could prototype a new operating system in a week and probably re-platform in two. The vibe-coded Adobe suite shows the shape of the opportunity — impressive, but nobody has made a better one; a faster copy of the same thing is rarely the next version. The excitement is factories as a creative outlet: on the other side, the question stops being 'AI can make pictures' and becomes what new thing you will build that nobody ever could.
- Q
In a software factory, how do you validate quality deterministically — what tests still matter?
Scott Tolinski asked39:04AAdam Jacob answeredBlack-box tests come first: the single most important thing to build before a factory, because they make refactoring safe and therefore the factory safe. Integration tests stay relatively valuable — they co-commit with the source and catch regressions earlier. Unit tests are the open question: AI is rarely writing functionally incorrect code, the TDD thinking loop between test and method is one AI does not need (ThoughtWorks research found agents did worse when asked to do TDD), and strong type systems — TypeScript, Rust — catch what unit tests used to. He would not be shocked if Swamp Club's engineering leader deleted every unit test as an experiment; worst case, an agent rewrites them. And the deeper reframe: when a class of failure appears, you do not blame the robots — you fix the factory. You have stopped building the thing and started building the machine that builds the thing (and the machine that builds the machine); write your architecture and vocabulary down, align the system to it, and iterate.
- Q
Why not just use skills for everything instead of this?
Scott Tolinski asked46:18AAdam Jacob answeredBecause it is augmenting skills, not replacing them. The early-era bet — models keep getting smarter, so throw everything at the god machine and it will sort it out — failed two ways: it does not reliably sort it out, and it is very expensive. Skills should describe the places where judgment, taste, or reasoning is applied, treated as pieces of the system: define their inputs and outputs, and measure whether the outputs are right. An accessibility skill is effectively a test suite that applies judgment — and occasionally errs — but is an order of magnitude better than what existed. Swamp's adversarial skill never lets the Lighthouse score drop, which is how he shipped the first product of his career with a 100% Lighthouse score.