SWAMP
CLUB
How to build a software factory
How many of you would say you believe in Agile Software Development, Lean, or DevOps?
I want you to remember you raised your hand just now later, ok?
CEO of Swamp Club, CTO and co-founder of Chef. Configuration Management, IaC, DevOps and Digital Transformation
Swamp Club elevator pitch
This is not a talk about swamp, but building Swamp and working with the community of folks using swamp is why I can speak to you about software factories today
// summary //
tl;dr
You stop writing the software
Instead you build the system that writes it
Build the factory: architecture, adversaries, tests, UAT, shipping
Iterate until you trust it
Use the time you get back to talk to each other and your customers
Go be the most creative you've ever been
// what is a software factory //
The socio-technical system by which software is produced and shipped to users
Socio-technical — because all systems are both social (human beings relating to other human beings) and technical (the software we use to achieve our goals)
System: a bunch of independent, interacting parts that work together to form a single unified whole — e.g. going from "I have an idea" to "I shipped my idea to a customer" is a system
Software: maybe it's obvious, but we're talking software
Produced: how it gets written, tested, and maintained
Shipped: how it reaches users — maybe SaaS, maybe as software, whatever
// what is a software factory //
You already have a software factory
It's everything you do from "idea" to "shipped"
Your SDLC, plus CI/CD
For most of you, it's some variation of something-something Agile, plus tests that run locally and in CI, plus a delivery pipeline
// the agile manifesto //
Individuals and interactions
over process and tools
Working software
over comprehensive documentation
Customer collaboration
over contract negotiation
Responding to change
over following a plan
While there is value in the items on the right, we value the left side more
All 12 agile principles are better fulfilled by an AI software factory than any agile process that has ever existed
// swamp's ai software factory //
Swamp's Software Factory
A single developer, Paul Stack, largely ships most of the code for swamp
He's shipped 349 times in the last 30 days
The average lead time between a bug or feature being filed and fixed is 4 hours
He's added dozens of major complex featuers and refactorings in that time
While he's doing that, Nick Stinemates built a whole game around using swamp
// how did we do that //
We are incredibly agile
We communicate constantly
Working software in hours
We collaborate with customers directly
We respond to change immediately
We are the most agile team I've ever seen
We talk to each other constantly, because we have the time, since we aren't writing the software
We see working software, good or bad, in hours or days, not weeks or months
We collaborate with customers in real time, on average in four hours or less
When we learn something new, it's a conversation and a few hours before we've responded to that change — none of our plans last long, because we can evolve in real time
I will tell you the secret
// the secret //
Maximum
creativity
We talk about factories because we like to pretend software is like manufacturing
But it isn't — it never has been. It's just a useful metaphor.
Building software products is fundamentally a creative act
It's always had more in common with creative endeavours than it did factory work
Paul and Nick are on the most creative tear I've ever seen in my career, including my own streaks
We use an AI software factory because it collapses the time between the smartest, most dedicated people I've ever met and the software they imagine in their minds — from months to hours
// the near future //
You will also work this way
Anything else is an unacceptable business risk
I've spent my career building venture-backed startups and businesses — including helping a lot of enterprises
Once there is a critical mass of us who know how to work like this
You will have no choice but to work like this
Because anything else will be an unacceptable business risk
Not doing it is the business equivalent of refusing to adopt rail transport and instead using wagon trains
You'll be able to not work this way if you're alone, or if your work matters only for yourself or a small audience
Doing it any other way will be like tending a cottage garden — beautiful, worthwhile, meaningful, but a far cry from a commercial base to build a business on
// scale //
It will break your organization
Mythbusters, Season 5, Episode 89
Very few existing systems survive an order-of-magnitude increase in throughput from what they were designed for
Think of it like the water pressure in your house — if it went up one order of magnitude (10x), your house would literally explode
Here is a mythbusters clip, where they increased a water heaters pressure from 50 PSI to 350 PSI - this would be 500 PSI
That house is your existing SDLC, org chart, and systems
And we're using that first order of magnitude to build systems that likely move at ANOTHER order of magnitude
Nothing will survive a 100x increase. The entire system will be rebuilt in the end because of it.
Nobody can predict how, or what we'll keep, or what will change
It is that fundamental of a transition
The only way to survive it is to get ahead of it
// get ahead of it //
How to build a software factory
01 Green field
02 Brown field
First green-field, as this is where you are guaranteed to have success
Then I'll give you a summary of how I would approach brown-field
// still an engineer, don't worry //
Your role
Define outcomes
Engineer the factory
When the outcomes are bad, improve the factory
Define the acceptable outcomes
Engineer the system that produces those outcomes
When that system fails to produce the outcomes, improve it
We build the machine that builds the machine
// outcomes are what matters //
Output vs Outcome
Output is the result of an activity
Output is easy to measure, and largely in your control
Think lines of code, stories shipped, whatever metrc you want
You can't tell from the output if things are going to be good or not
Outcomes are the long-term impact on your customer
Outcomes are hard to measure, and largely out of your control
Do they like it? Does it solve their problem? Do they buy more of what you're selling?
// measuring outcomes //
Measuring outcomes
The best way is to interact directly with the stakeholder — a user or a customer
Did Steph win or lose the game? We'll know in 2 hours.
You file a bug. 4 hours later we ship the fix.
The issue is still in your mind — it didn't take weeks or months of waiting and suffering
Outcomes are much easier to see when they are immediate
If it takes you two weeks to fix the bug, how long before you get it confirmed?
You probably have bugs that have been open for literally years
// prompting //
Outcomes are good prompts for factories
implementation ✗
> Write a method to store cookie consent
outcome ✓
> Add a GDPR and ePrivacy compliant cookie consent banner
It's the factory's job to handle implementation
You will talk outcomes and architecture
"Write this method…" is tough when you move this fast
"Add a GDPR and ePrivacy compliant cookie consent banner" is a good prompt
the factory will handle aligning the output to your intented outcome
// building trust //
Building trust
Real trust comes from people (and systems) doing what they say they will do — over and over
LLMs are probabilistic by nature — that's where their creativity and problem solving comes from
That makes them hard to trust, especially as the system gets more complex
// skills are context //
Skills don't build trust
Skills add context, and frontier models do their best to follow their instructions
But the nature of the technology is that it won't always work
That's a real problem when the question is "did you run the tests"
Or when it is "did you implement everything I wanted you to"
Using skills to describe processes you want followed is the most expensive for loop in history
and it sometimes will just.. not run
// you trust software //
Use agents to build trustworthy systems
Build software
Skills explain how
Call into intelligence
Instead, we use the agent to build normal software we can trust
And we build skills that explain how to use that software
And call into intelligence when our factory needs it
Rather than using frontier intelligence as the most expensive for-loop ever created
This is precisely what Swamp does — an implementation of an AI software factory for producing reliable, repeatable automation
// not one shot //
Engineering is still engineering
Iteration is critical
Software engineering is still software engineering
You won't get it right all at once — you build the system, try it, tweak it, refactor it
Over time it will become trustworthy and stable
// emergent vs designed //
Software architecture
For most of us, architecture has been an emergent property of the code — we learn it from the bottom up
AI Agents make insane emergent architectures, because they will just make it up as they go along, when people didn't
Writing to a strict architecture pattern was fantastically annoying as an engineer — it's not annoying for an AI agent
So you need to start with an architecture perspective up front
pick one: DDD, CRUD, DOD, Layered, MVC, OO, ECS
// choose your style //
Start with Software Architecture
Build an architecture skill
Give it the pattern's vocabulary
Add language-specific examples of each pattern
Consistency is vital
Pick one pattern and build a skill with simple examples of it in your framework, in your language
Keep the examples simple and unrelated to your actual application, or it will over-fit
Give it the ubiquitous vocabulary of the pattern — Swamp uses DDD: value objects, entities, aggregates, domain services, repositories, application services
The more consistent the codebase is in vocabulary, structure, and architecture, the more the agent adheres to that design
Then you can navigate any implementation top-down, starting from that vocabulary
// from swamps ddd skill //
Value Object
Immutable, equality by value — readonly fields, a private constructor with a static factory
export class Money {
private constructor(
readonly amount: number,
readonly currency: string,
) {}
static create(amount: number, currency: string): Money {
if (amount < 0) throw new Error("Amount cannot be negative");
return new Money(amount, currency);
}
add(other: Money): Money {
if (this.currency !== other.currency) {
throw new Error("Currency mismatch");
}
return Money.create(this.amount + other.amount, this.currency);
}
equals(other: Money): boolean {
return this.amount === other.amount && this.currency === other.currency;
}
}
This is a real example from Swamp's DDD architecture skill
A value object: immutable, compared by value, constructed through a factory that enforces its invariants
The agent has simple examples like this for every building block — so what it writes looks like this
// your standards //
Adversarial skills
for example
Testing
Security
Accessibility
UX design
Observability
Add adversarial skills that cover the other aspects of the software
At a minimum: unit and functional testing strategy, security posture, and source-code commit standards
These skills ensure the output conforms to your standards — they refine the plan (adversarial review) and review the output
You probably have more of these than you realize — you're just bad at doing it consistently
Swamp Club is the first site I've shipped with a 100 accessibility score on Lighthouse
Because we have an adversarial skill detailing WCAG compliance, with examples, in our language
I literally never think about accessibility and compliance anymore
// what to do, and how to do it //
Planning phase
Start with a conversation about the outcome your feature will achieve, iterating with your agent
Then ask it to write a plan for implementing your feature
Then have it adversarially review that plan against your software architecture and all your adversarial skills
Critical feedback gets folded back into the plan and reworked — up to 5 times
Then it comes back to you for final approval
// build the factory //
Building your factory
Ask the agent to write the software
or use Swamp
describe the outcome
> Make me a software factory using Swamp. Start with an initial prompt, then we discuss the feature. When I tell you, write a plan, then review it against my software architecture skill and [adversaries], surfacing only critical recommendations. Fold any critical feedback back into the plan and rework up to 5×, then show me the final plan for approval.
The factory needs to be a program, written by your agent — not just a bag of skills
The bag of skills won't work the way you want, and will be more expensive
I recommend doing this with Swamp — but you could do it yourself by running the same steps for the software that drives your factory (a little recursive, eh?)
So install Swamp, initialize a repo, fire up your agent, and describe the outcome you want
Notice I'm talking outcomes, not implementation
This works because Swamp itself is a software factory for automation — in this case, other software factories
// write the code //
Implementation & testing
> Improve the factory so that after a plan is approved, you write the code with appropriate test coverage based on [test skill], then ensure all tests pass. If any are failing, rework the software until they pass — up to 5 times.
Now add an implementation phase
"Improve the factory so that after a plan has been approved, you write the code with appropriate test coverage based on [test skill], and then ensure all tests are passing. If any tests are failing, re-work the software until they are passing up to 5 times."
// review the code //
Code review
> Improve the factory to do a comprehensive code review after implementation and testing — checking compliance with the software architecture and [adversarial skills], surfacing critical issues. If there are any, go back to implementation and resolve them, feeding the previous findings into the next review. Do this up to 5 times.
Now add code review, across your software architecture and adversaries
"Now improve the factory to do a comprehensive code review after the implementation and testing phase. Ensure compliance with the software architecture and [list of adversarial skills], surfacing any critical issues. If there are critical issues, go back to the implementation phase and resolve the problems. When you reach code review again, feed the previous findings into your next review. Do this up to 5 times."
This is how our code gets a 100% Lighthouse score for accessibility and SEO — humans will never do that
// take it for a spin //
Build a first slice
first slice
> Use the software factory to start an application that does [X]. Help me design a good minimal first page and development environment, using my software architecture, design, and testing skills.
Examine the outcome — fire it up, how does it feel?Spot check the output — recognize the architecture? is coverage right?Iterate — tweak the skills, run it again, until you trust it
A good first feature is a simple initial slice that gets you something to work with
Go talk to your customer about the first feature while it spins — drink a cup of coffee
Examine the outcome: fire up the program you just wrote and ask yourself how you feel about it. If you want to tweak it, start again and tweak it
Spot check the output: now's the time to see if your architecture skill paid off — can you recognize the patterns in the code? Is it laid out in a way you understand?
Is test coverage what you expected?
If the answer is no to anything, tweak those skills and ask the system to refactor to improve — without changing the feature
Iterate: pretty quickly you'll stop needing to look at the output, because when you do, it's always fine — you'll find yourself looking at the outcome only
// package it up //
Production artifacts
> Improve the factory so that once a change is approved and merged, you build the production artifact — a [binary / container / static site] — and store it in [s3 / docker hub] where everyone can reach it.
Whatever you plan to ship — binaries, docker containers, directories of HTML
Add that to your factory after the code has passed and things are ready
You might do this in a platform like GitHub or your CI/CD tooling — that's fine for now, but the future is obviously letting the agent do all this
Store them somewhere accessible to everyone (Swamp can store them in its data lake — usually just S3-compatible storage)
// prove it works //
User Acceptance Testing
Start another factory: black-box UAT environment, built from production artifacts
Enables safe refactoring and avoids regressions
UAT is an old idea — QA engineers with CDs and binders
The goal is black-box acceptance testing from production artifacts
Pre-AI you'd never have forced a team to do this for long — too onerous, takes forever. Now it's easy
You're going to build a UAT factory, same pattern — run it after a production artifact is produced, and its only input is the artifact
The results confirm the product works and hasn't regressed
On failure you do one of two things: tweak the UAT (the acceptance test itself was wrong), or file a bug and let the factory run the whole process again (a real regression)
Then trigger the UAT suite automatically after every production artifact — this is what makes refactoring safe
// invest in uat //
UAT is key to refactoring
Over time you'll notice some outcomes are harder to achieve than others, or classes of bugs keep coming up over and over
When that happens, it's a clue to refactor
The UAT suite ensures that when you do, the product doesn't regress
Swamp has done many major refactorings — frequently 10k–20k lines, with zero regressions
UAT finds issues all the time. Invest in UAT!
// all together now //
The whole factory
Every phase we built, now one line: plan → build + test → code review → artifact → UAT → deploy
Plan and code review both run adversarial reviews against the same architecture + adversarial skills, reworking up to 5×
Build + test reworks until green; UAT catches regressions on the way out
Humans are in the loop where it matters — approving the plan, approving the merge — and nowhere else
An outcome goes in the front; production comes out the back
This is the machine that builds the machine
// keep extending //
Next steps
Extend it all the way to production deployment
Consider a "fast lane" for simple tasks
Refactor when bugs or features get brittle
Keep extending the factory
Extend it all the way to deploying your application
Add whatever external systems you want for prompting — we just have a basic issue tracking system
When the process fails you by producing poor outcomes, improve the system
Consider having a "fast lane" for simple tasks
When a class of bug or feature keeps coming back brittle, refactor the application
Now you're building the machine that builds the machine
// existing codebases //
Brown-field strategy
Start with UAT — a safety net around the existing product before you touch anything
Then software architecture, planning, implementation and testing phases — and refactor the existing code to be more consistent. No new features.
Then add the adversarial vectors, and refactor again. Still no new features.
When you're comfortable the factory can refactor safely, start adding new features
No standard factories
No matter what, you aren't going to use a "standard" factory
The details matter — they're what make the outcomes for your product your product
Agents with Swamp are great at building factories — so just use them to do that
Never be blocked
If something doesn't work the way you want, you are never blocked
In Swamp, every extension can be extended itself, and its behavior overridden
Or you can just write a new one that fits your use case exactly
You're the engineer — you know best. Get creative.
Share with each other
The moment we're in is amazingly fun
But you don't want to be doing it alone — it's hard to keep up, and we're all learning as we go
One good place to do that is the Swamp Discord — it's full of people on this exact journey as you
Embrace your creativity
Build the software factory that gets you from idea to working outcome as quickly as possible
And see how fun it is to engineer that way
You'll be hooked, just like we are
I can't wait to see what you build, and learn from you
// tl;dr //
You stop writing the software
Instead you build the system that writes it
Build the factory: architecture, adversaries, tests, UAT, shipping
Iterate until you trust it
Use the time you get back to talk to each other and your customers
Go be the most creative you've ever been
Join the Swamp Discord
discord.gg/swamp-club
Thank you! Scan the QR for a recording of this talk
Reach me at adam@swamp-club.com, and come hang out in the Swamp Discord — discord.gg/swamp-club
