WTF is a Software Factory?

Summary

Adam Jacob describes a software factory as a system that uses agents to automate as much of the software development lifecycle as possible—from turning product intent into code through testing, architectural checks, and production readiness. The goal is not simply to generate more code, but to produce reliable outcomes through repeatable processes. Because products, teams, and architectures differ, there is no single factory design that fits every organization.

Swamp Club and agent workflows

Jacob presents Swamp Club as a platform for turning natural-language requests into modular, reusable automations. It breaks work into components with typed inputs and outputs, connects them into workflows, and can store results in shared, queryable memory. The automations can also integrate with APIs and be refactored as needs change.

Unlike a coding agent or skill alone, which may cause a model to reason through the same task from scratch each time, Swamp Club turns the intent into a reusable process. This reduces repeated model work and makes execution more consistent. Its design places a deterministic workflow around model calls: the workflow handles predictable steps and invokes AI where judgment or interpretation is needed. Users bring their own inference and can change the model behind a component.

Examples discussed include organizing project folders, cleaning up build artifacts, updating software, processing Sentry issues into tasks and pull requests, and automating podcast editing.

Trust, testing, and architecture

Jacob argues that factories need strong ways to verify their output, especially when fewer people are involved in the code-generation loop.

• Black-box testing: Test the product from the outside, without relying on knowledge of its internals. Jacob considers this especially important for detecting regressions and recommends it as a foundational step toward building a factory.
• Integration tests: These can still be useful for catching problems where system components interact.
• Unit tests: Their value is less settled in AI-assisted development. Jacob notes that strong type systems, such as those in TypeScript and Rust, can catch some issues traditionally covered by unit tests. He also cites research suggesting that asking agents to follow test-driven development can worsen outcomes in some cases. His view is to experiment rather than assume all existing unit tests must stay—or go.
• Architecture and domain language: Agents need explicit architectural guidance. Jacob recommends documenting a project’s architecture, potentially using domain-driven design (DDD), and checking generated code against those principles. For example, an anti-corruption layer translates between systems so changes to one API do not force changes throughout another.
• Adversarial review: Add checks for requirements such as accessibility, including WCAG criteria, and review changes against them. Checks can be selected based on the type of change; for instance, accessibility review may not be needed when no user-facing code has changed. When failures recur, improve the factory so it catches that class of problem more reliably.

The broader principle is to treat failures as opportunities to improve the process and its checks—not merely as evidence that the model is incapable.

Organizational change and the future of software

Jacob warns that simply adding AI-generated code to an unchanged development process can create a “slop factory”: large, poorly understood changes that teams cannot review or safely maintain. More automation and structure—not just faster code generation—are needed to make higher output trustworthy.

For large companies, he recommends starting with a small group—perhaps five people—given permission to work outside normal rules on a real problem. Their task is to build a complete, trusted factory and demonstrate working results before scaling the approach. Jacob says organizations are still experimenting; he has seen companies begin this transition but not complete it.

He expects engineering work to shift toward designing and improving the systems that produce software. He also anticipates more personalized, small-scale software: tools made specifically for an individual or team, rather than only larger, general-purpose products. He is uncertain how increased productivity will affect engineering headcount, but argues that expanded capacity may lead to new software and new kinds of demand.

Practical guidance from the discussion

1. Start with black-box tests that verify the product’s behavior.
2. Write down the project’s architectural principles and domain vocabulary.
3. Use skills for judgment, standards, and examples, but make them part of a larger workflow rather than relying on prompts alone.
4. Review generated work against architecture and other requirements, such as accessibility.
5. When a recurring failure appears, update the factory to prevent or detect it.
6. In a large organization, prove the approach with a small team and a real project before attempting a broad rollout.

The episode also includes a brief Sentry sponsor message. Jacob recommends Swamp Club and its Discord community as places to explore the tools and share approaches.

Main speakers and sources

• Adam Jacob — CEO of Swamp Club; explains software factories, automation, testing, architecture, and organizational adoption.
• Scott and Wes — Syntax hosts; ask questions and share examples of personal automations.
• Other sources referenced in the discussion: A ThoughtWorks blog article on agentic test-driven development, and a social-media post about a team shipping 2,500 pull requests in a month.