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.
WTF is a software factory?
A software factory hands as much of the SDLC loop as possible — ultimately everything but the inputs, the outputs, and a few middle spots — to agents that run it on your behalf, keeping the system stable, aligned to its architecture, and free of regressions. That is the definition Adam Jacob, CEO of Swamp Club, brings to Syntax, and his company's product is the working proof of concept: it compiles natural-language intent into modular automation with typed inputs and outputs, so behavior runs identically every time without burning frontier-intelligence tokens. The rest of the hour is the honest hard part: why unchanged SDLCs become slop factories, why organizations — not technology — are the unsolved layer, and which tests still matter.
From prompt to compiled intent
The contrast that makes the idea click: prompting Claude does something, maybe what you wanted; a skill fixes the instructions but re-buys the intelligence every run. Swamp instead turns the same prompt into modular automation on your behalf — the stored, queryable kind later steps can consume. Swapping the underlying model, like the new Decisions APIs from OpenAI and Cloudflare, becomes refactoring one component's configurable option: the loop inverts, with a deterministic loop calling out to intelligence only when needed. Commercially: paid per user per month, and you bring your own inference — it sits under whatever harness and models you already run. Scott's own automations range from keeping his Pi harness updated to turning Sentry bugs into merged PRs.
The definition, and why it confuses
Adam's definition: hand as much of the SDLC loop as possible to agents. No two factories are the same — the shape depends on what the factory produces and on the team's inputs — which is why five people give five definitions. The deeper claim: good software was always the decisions about how it works, unique to its builders; a factory encodes those decisions so intent reaches outcome faster, and it owns the output in between.
The slop-factory objection, conceded
If you have not changed your SDLC, Adam agrees the result is awful — and the way out, paradoxically, is more AI: more automation, more structure, more of the system being designed. It feels like a slop factory because your lived experience is one; the thousand-line Claude PRs nobody understands are the breakers you cannot get past. Organizationally, the transition breaks the existing points of control: engineers with a trustworthy factory ship without permission, and product people must pivot from directing work to reviewing outcomes. His recipe is kaikaku-style — five people, one real slice of the business, permission to break every rule — and of the large companies that started, he has seen none finish.
Demand has no discovered cap
What do 10,000 LinkedIn engineers do when everyone runs ten times faster? Adam's answer: nobody knows, but no demand cap has ever been found for software — it is infinite given compute, so automation history says the work changes and grows. His velocity illustration: decide to build LinkedIn a new operating system tomorrow and you would have a prototype in a week. The Adobe lesson follows: the vibe-coded suite is impressive, but nobody has yet made a better one — a faster copy of the same thing is rarely the next version; the prize is the creative outlet, not the clone.
Tests, architecture, and the machine
Black-box tests are the single most important first investment: they make refactoring safe, which makes the factory safe. Integration tests stay relatively valuable; unit tests are the open question — AI rarely writes functionally incorrect code, ThoughtWorks found agents did worse with TDD, and strong types absorb the role; he would not be shocked if his engineering leader deleted all unit tests as an experiment. Architecture returns as a written skill the agent can follow, and the closing stance is the episode's thesis in one line: when a class of error appears, do not blame the robots — change the factory so that whole class gets caught. Against skills-for-everything: the god-machine bet failed as unreliable and expensive; skills should scope judgment as measurable system pieces — one adversarial skill holds Swamp's Lighthouse score at a perfect 100. And if a giant turns the evil eye of Sauron on the company, they can take the code but not the practice of building with practitioners.
Interview 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.