The Humans Architect the System

The AI Writes the Code

Paul Stack
Co-founder / VP of Product
Elder Swamp Club
@stack72 / https://stack72.dev

> We don't write code.
> We're building the machine to do that for us.

*This is our way. You need to find yours.*

Note: [~1 min] · ~1:30 in Before I go further — this is how we work at Elder Swamp Club. I'm not standing here telling you this is the one true path. I'll show you our process in detail. Take what's useful. Leave what isn't. But by the end of this talk I want you thinking about your own version — what would it look like for your team, your codebase, your domain. That distinction — between writing code and building the machine that writes it — is what this talk is about. The most valuable thing you know isn't how to write the code. It's how to think about the system. The constraints. The invariants that must hold. That bundling is coming apart. And you get to decide what you do with it.

---

## What we'll cover

1. **Why** we stopped writing code — and what changed when we did
2. **How design guidelines** replace pull requests as the primary contribution mechanism
3. **What "architecture-first"** means in practice when an LLM is your entire engineering team
4. **How swamp** applies those same principles to operations
5. **How AI gives you back** the work you got into this industry to do

Note: [~30 sec] · ~2 min in Five things. Let's go.

---

# The Bottleneck
# Isn't Thinking

**6 years building. Threw it all away in January.**

**8 months later — we're thrilled with what we have.**

Note: [~1.5 min] · ~3:30 in Elder Swamp Club spent 6 years trying to build a product. In January we threw it all away and started again from scratch. Eight months later — we are genuinely thrilled with what we've built. More than we ever were in 6 years. That's what collapsing the translation gap does. Not just faster — fundamentally different. The bottleneck has always been turning ideas into working code. In the last two years, that gap has collapsed. Engineers making changes in an afternoon that would have taken a week. Not because they got faster. Because the translation from thinking to code got faster. And this changes something fundamental about how a team operates: trust. To work this way, you have to fully trust the decisions your team makes. No lengthy review cycles to catch mistakes. No hedging. No "let's wait and see." But that trust becomes possible precisely because of the speed. If a decision turns out to be wrong, you can reverse it in an afternoon. The cost of being wrong collapses. And when the cost of being wrong collapses, trust gets much easier to give. When the bottleneck moves, everything upstream backs up. If you can turn ideas into code 10× faster — the thing slowing you down is no longer code. It's clarity. Do you know what you want? Can you express it precisely? Can you catch mistakes before they're built? That's the new bottleneck. Not syntax. Clarity.

---

## The question is
## *what do humans need to do instead?*

Note: [~1 min] · ~4:30 in Not "review AI output faster." Own the architecture. The design decisions. The constraints. The invariants. The things that make a system coherent over time. Engineers getting consistently good output → the ones who can express what they want architecturally. Not vibes like "make it clean." Specific, unambiguous constraints. Clear constraints produce clear code. I've heard a rumour that the first thousand lines of code you feed an LLM shapes everything it produces after that. So if those first thousand lines are a mess — inconsistent patterns, no clear structure, technical debt baked in — then that's what you'll keep getting back. Garbage in, garbage out, but at scale and at speed. The quality of your constraints and your starting point matters more than it ever did before.

---

# We Banned
# Hand-written Code

## No exceptions.

Note: [~1 min] · ~5:30 in Not a guideline. Not a preference. A ban. We do not write production code by hand. No exceptions. Every line of code in swamp — our AI-native automation CLI — is generated by an LLM operating within design guidelines we've written and maintained. Those guidelines are architectural contracts: — The patterns we use and why — The boundaries between components — The invariants that must hold — Things we've tried and rejected, and why Not documentation. Executable constraints.

---

## No PRs

> A well-intentioned PR from an external agent is **indistinguishable from a supply chain attack at the CI layer.**

*The social norms of open source are changing.*

Note: [~2 min] · ~7:30 in We don't accept pull requests. That sounds extreme until you look at what's actually happening to software supply chains right now — so let me make the case properly. The social contract of open source was always: anyone can contribute code. That made sense when writing code was the hard part. The cost of producing a contribution was itself a filter, and the person who wrote it understood the codebase they were touching. Both halves of that are gone. AI generates plausible, well-formatted, test-covered code at scale — and the author may understand nothing about your architecture, or may not be acting in good faith at all. As I've written: the valuable part of an open source contribution was never the code. It was the understanding. Agents give you the code for free and strip the understanding out. Here's the framing that matters: a well-intentioned PR from an external agent is indistinguishable from a supply chain attack at the CI layer. The moment an untrusted PR runs in your pipeline it executes code with access to your runners, your caches, sometimes your secrets and tokens. Intent cannot be read from a diff. CI literally cannot tell a helpful contributor from an attacker — both are just untrusted code entering an automated pipeline. And this is not hypothetical. The last couple of years: — xz-utils, 2024 — an attacker spent years building trust as a maintainer to plant a backdoor in a library feeding sshd on nearly every Linux box. Pure social engineering of the contribution model. — Shai-Hulud, 2025 — a self-replicating npm worm that stole credentials and republished itself across hundreds of packages. — tj-actions/changed-files, 2025 — a compromised GitHub Action leaked CI secrets out of thousands of repos at once. — event-stream, 2018 — a popular package handed to a "helpful" new maintainer who added wallet-stealing code. Every one rode in through the trusted contribution path. That is the exact path we're closing. Now — be honest about it. You cannot make supply chain risk zero. Nobody can. What you can do is shrink the attack surface as far as possible, and that's what this is. We control who and what puts code into the pipeline — only our own constrained, reviewed flow — and we harden everything around it: CVE dependency audits on every PR, third-party Actions pinned to a SHA instead of a moving tag, a CI-security reviewer watching every workflow change, scoped tokens instead of the broad default. Defence in depth, knowing no single layer is perfect. So we accept issues, not PRs. You bring the problem and shape the design; the LLM builds it under our constraints, in our architecture, through our gates. And when an external report drives a fix, the reporter is credited as a co-author — contributors aren't excluded, they're more included. We just don't let untrusted code walk straight into the machine.

---

# The Full Flow
## From idea to merged code

Note: [~30 sec] · ~8 min in Let me show you what this actually looks like end-to-end. This is the real process — every step has guardrails built in.

                        @swamp/issue-lifecycle

                        a typed state machine — every transition is
                            validated
                    

                        a typed guard rejects any method that isn't legal from
                        the current phase — the machine can't be skipped
                    

This whole flow isn't a pile of shell scripts — it's an extension model, @swamp/issue-lifecycle, written in swamp. A typed state machine. swamp building swamp. triaging — a maintainer kicks it off. We're not at fully autonomous agents and we're not pretending to be — a human still decides when triage starts. Claude reads the agent guidelines, the design docs, and the relevant skills, independently verifies every claim in the issue, and explores the actual code before forming a conclusion. classified — bug, feature, platform, or security. Low confidence? It asks clarifying questions instead of guessing. And if it classifies something as a bug, we force it to challenge itself: is this a regression? It has to provide concrete evidence that it previously worked, then argue the strongest case that it's NOT a regression, then deliver a verdict with reasoning. Adversarial self-challenge built into triage — not just "this looks like a bug" but "I've verified this against the evidence and here's why I'm confident." plan_generated — the amber loop. Planning and adversarial review are ALWAYS paired: iterate, adversarial_review, resolve_findings all cycle here. You never see a plan that hasn't already been attacked. The state stays put until a human is satisfied. approved — the green gate. A human approves. Never auto-approved. That's the one transition we will not automate. implementing — the agent implements under the guidelines. After implementing, a code conformance review adversarially compares the implemented code against the approved plan. Deviations are expected — they just need a documented justification. verifying — a pre-PR verification loop. The agent runs the full CI checks — lint, test, compile, agent reviews — in a isolated workspace before opening a PR. If verification fails, it loops straight back to implementing to fix and re-verify. Before the PR opens, a verification attestation is posted to swamp-club. pr_open → releasing → notify → summarizing → done — CI runs the attestation gates, it auto-merges, ships, and thanks the contributor. The red branch is recovery: if CI fails the issue moves to pr_failed and loops straight back to implementing for another attempt — it doesn't fall out of the machine. summarizing — after notifying the contributor, the agent records a session summary restating the original problem and delivered outcome. This final check verifies the work actually addressed the issue. And the whole thing is guarded — a typed valid-transition check rejects any method that isn't legal from the current phase. The state machine can't be skipped. The guardrails are doing the work. [~2 min · ~10 min in]

# Agent Guidelines
## The Executable Contract

Note: [~30 sec] · ~10:30 in The center of gravity in this whole system is the agent guidelines file. We call ours CLAUDE.md — that's the convention in Claude Code. But every major AI coding tool has a version of this now: Cursor rules, Copilot instructions, Windsurf rules. The name doesn't matter. The concept does. Every agent session reads it before doing anything. Every CI reviewer reads it before reviewing anything. It's the difference between vibes and enforced architecture. Let me show you what's actually in ours.

---

```
# Code Style
- TypeScript strict mode — no `any` types
- Named exports, not default exports
- AGPLv3 copyright header on every .ts file
- No fire-and-forget promises — await or handle every one

# Architecture
- Every command supports both "log" and "json" output
- Import from src/libswamp/mod.ts — never internal paths
- design/*.md are living documents — read them first

# Changes
- Touch only what's necessary. Keep the blast radius small.
```

Note: [~1.5 min] · ~12 min in These aren't preferences. There is one right answer for each. No <code>any</code> — hard fail. Named exports only — hard fail. Missing copyright header — hard fail. Import boundary — CLI commands may only import from the public interface, never from internals. Without this, every session would rediscover the architecture from scratch. Design docs — we maintain a folder of living design documents that capture the architectural decisions behind the system. Every Claude session reads the relevant ones before touching anything. Every triage run reads them before generating a plan. They're not historical artefacts — they're kept up to date as the system evolves. When a design decision changes, the doc changes too. Blast radius rule — the AI is not allowed to refactor adjacent code while fixing a bug. Must stay in its lane. Session Learnings — if the agent hits a non-obvious problem during a session that would trip up future sessions, it's required to propose an update to the guidelines before finishing. The guidelines, the design docs, the session learnings — none of them are done. The constraints get sharper over time.

---

## A Complete Testing Strategy

| Level | What it catches | Runs in |
|---|---|---|
| **Unit** | Logic errors in isolation | swamp repo |
| **Integration** | Components working together | swamp repo |
| **Contract** | API and interface boundaries | swamp repo |
| **Property** | Invariants hold across all inputs | swamp repo |
| **Architectural fitness** | Structural rules and design constraints | swamp repo |
| **UAT / Scenario** | Real user workflows end-to-end | **swamp-uat** |
| **Adversarial** | What a motivated attacker or edge case breaks | **swamp-uat** |

Note: [~1.5 min] · ~13:30 in When your entire engineering team is an LLM, your testing strategy has to grow to match. We don't just have unit and integration tests. Contract tests — verify that component interfaces don't silently drift. If the libswamp public API changes shape, callers break. Property tests — invariants that must hold across all possible inputs, not just the ones you thought to write. Architectural fitness tests — does the code still conform to the structural rules? Import boundaries. Layer separation. Domain model integrity. UAT / scenario tests — real user workflows, end-to-end, the way an actual person would use the CLI. Adversarial tests — what does a motivated attacker or a malicious edge case do to this code? Each level catches a different class of failure. And here's the thing — several of these aren't just tests. They're automated Claude reviewers running on every PR. And notice the last two — UAT/scenario and adversarial — don't run in the swamp repo at all. They run against the compiled binary in a separate repo, swamp-uat. That's a whole gate of its own — I'll come back to it in a moment.

---

# CI
## The Enforcement Layer

Note: [~30 sec] · ~14:15 in CI was designed when humans wrote code at a predictable pace. Agent-driven development breaks those assumptions. Let me show you what changed and why.

---

## CI's assumptions are broken

```
Agent writes code → opens PR → CI fails → context switch → fix → wait → repeat
```

**The feedback loop is in the wrong place.**

The agent has the code, the tests, and the environment — *right now*.
Why discover failures downstream?

Note: [~1.5 min] · ~14:45 in Here's the problem. Traditional CI discovers failures after the PR boundary. When a human writes code slowly, that's fine — you open a PR, CI catches something, you come back and fix it. When an agent writes code, this becomes an architectural mismatch. The agent writes a change, opens a PR, CI runs for minutes, finds a failure, and the agent has to context-switch back to fix it — then wait for another full CI run. At scale, this compounds: CircleCI analysed 28 million workflows and found throughput up 59% year-over-year while main-branch success rates dropped to their lowest in five years. The problem isn't CI speed. The problem is that the feedback loop is in the wrong place. The agent already has the code, the tests, and the environment. Verification should happen there — where failures can be fixed immediately, in context, without a round-trip.

---

## Pre-PR Verification Loop

```
  implement → lint → test → compile → review → fix → re-verify
                                                  ↺ iterate until clean
```

**Not a pre-commit hook.** An iterative process — the agent fixes failures and re-runs until everything passes.

When it's clean: an **attestation** records what passed.

- Verified commit hash
- SHA256 checksums of all config files
- Every step, its result, and duration
- The gate decision

*CI doesn't re-execute. It validates the proof.*

Note: [~1.5 min] · ~16:15 in So we moved verification before the PR. But this isn't a pre-commit hook — it's fundamentally different. A pre-commit hook runs once and blocks or passes. Our verification loop is iterative: it runs the full set of controls — lint, test, compile, code review, UX review — observes failures, modifies the implementation, reruns the controls, and repeats until everything passes or the agent asks for human input. When verification passes, the workflow generates an attestation — a structured manifest. It records the verified commit hash, SHA256 checksums of every config file — review prompts, workflow definitions, agent guidelines — every verification step with its result and duration, and the overall gate decision. This is the architectural pivot. CI no longer re-executes those controls. It validates the attestation: does the commit match the PR? Are the config file hashes still correct at that commit? Are all required steps present and passing? Is the attestation fresh? That validation takes seconds. Nothing executes — CI becomes purely a coordinator and evidence validator. The heavy lifting already happened where it should: in the agent's environment, where failures could be fixed immediately.

---

## Four Merge Gates

| Gate | Trigger | Blocks merge? |
|---|---|---|
| **Attestation Validation** | Every PR | Yes — verifies the pre-PR verification workflow passed |
| **Adversarial Review** | Core source changes | Yes — assumes broken, tries to prove it |
| **CI Security Review** | Workflow changes | Yes — prompt injection, supply chain, permissions |
| **Review Integrity** | Trust-root changes | Yes — protects verification chain of trust |

*Three Claude reviewers. One attestation gate.*

Note: [~1.5 min] · ~18:15 in Most of the heavy lifting has moved before the PR opens. Lint, test, compile, code review, UX review, skill quality — all of those now run locally in the pre-PR verification workflow inside a isolated workspace. The results are captured in a signed attestation that ships with the PR. The CI layer validates that the verification actually happened — and adds checks that benefit from fresh eyes in the CI environment. Attestation Validation — every PR. Verifies the attestation is present, valid, and covers the committed code. No attestation, no merge. This is the proof that the full verification workflow passed. Adversarial Reviewer → a completely separate Claude job, different persona. Assumes the code is broken and attacks it — logic errors, error handling, security, concurrency, data integrity, resource management, API violations. Fresh perspective in CI, independent of the local verification. Critical or high findings block the merge. CI Security Reviewer → watches workflow and CI changes specifically. Prompt injection, supply chain vectors, permission scope, third-party actions pinned to SHAs. Review Integrity → guards the trust root. If someone changes the verification workflow itself, or the attestation validation, this reviewer checks that the chain of trust still holds. This is defence in depth: local verification catches issues fast, the attestation proves it happened, and CI-only reviewers add an independent layer that the agent can't influence.

---

## Auto-merge

```yaml
needs:
  - validate-attestation
  - claude-adversarial-review
  - claude-ci-security-review
  - claude-review-integrity
```

When everything passes — **it merges itself.**

Note: [~45 sec] · ~19:30 in All gates pass — attestation valid, adversarial review clear, CI security clear, review integrity intact — PR is squash-merged, branch deleted. No human has to click merge. The heavy lifting already happened locally in the verification workflow — CI just validates the proof and adds its own independent checks. The guardrails are the architecture. If all constraints are satisfied, the code ships. One escape hatch: add a <code>hold</code> label to pause. Otherwise — if it passes the gauntlet, it goes.

---

## The Gate — `swamp-uat`

**Merge ≠ shipped.** The compiled binary is tested like a user — in a separate repo the agent can't touch.

```
merge → compile release binaries → dispatch to swamp-uat
        CLI acceptance · adversarial security · perf benchmarks
```

**Why separate?**

- The agent that wrote the code **also wrote the unit tests** — same misunderstanding, same blind spot
- The compiled binary is what users run — **code-level tests can pass while the binary breaks**
- A separate repo is a **separate trust boundary** — the agent can't weaken the tests to pass

Note: [~2 min] · ~20:15 in Auto-merge isn't the finish line. A merge is not a release. And this is where the talk before mine connects to what we're doing — this is the black box testing layer. When code lands, swamp compiles the cross-platform release binaries and dispatches the version to a separate repo — swamp-uat. swamp-uat installs the real binary and drives it the way a user would: CLI acceptance tests in clean temp dirs, JSON output validated against the Zod schemas, adversarial security probes — path traversal, secret leakage, CEL injection — and performance benchmarks. Why a separate repo? Three reasons. First — the agent that wrote the code also wrote the unit tests. If it misunderstood the requirement, both the code and the tests encode the same misunderstanding. They'll agree with each other and both be wrong. You need an independent check that tests outcomes, not implementation. Second — the compiled binary is what users actually run. Code-level tests can pass while the binary behaves differently. Three real examples, all caught in minutes after a fully green build: an async refactor that was never wired into the workflow execution layer — silent data loss. A lazy-loading optimisation where <code>has()</code> and <code>get()</code> disagreed across eleven call sites — every third-party vault user locked out. A later PR that quietly regressed the error-recovery path for extension developers. Third — and this is the architectural point — a separate repo is a separate trust boundary. The agent working the issue cannot modify swamp-uat's tests to make its own change pass. The acceptance tests are immutable from the agent's perspective. When a test fails, the default assumption is the code changes — not the test. This is the same principle from the "how to get started" slide: understand the user-facing behaviour and encode it in tests the agent can't touch. swamp-uat is that principle at scale.

---

# The Last 30 Days

<div style="display:flex; justify-content:center; align-items:flex-end; gap:2.2em; margin:0.5em 0 0.7em;">
 <div><div style="font-size:3.2em; font-weight:800; color:#00ff55; line-height:1;">496</div><div style="color:#888; letter-spacing:0.12em; font-size:0.62em; margin-top:0.4em;">OPENED</div></div>
 <div><div style="font-size:3.2em; font-weight:800; color:#42affa; line-height:1;">336</div><div style="color:#888; letter-spacing:0.12em; font-size:0.62em; margin-top:0.4em;">SHIPPED</div></div>
 <div><div style="font-size:3.2em; font-weight:800; color:#ff44aa; line-height:1;">138</div><div style="color:#888; letter-spacing:0.12em; font-size:0.62em; margin-top:0.4em;">CLOSED</div></div>
</div>

<div style="display:flex; justify-content:center; align-items:flex-end; gap:2.2em;">
 <div><div style="font-size:2.2em; font-weight:800; color:#42affa; line-height:1;">4.8h</div><div style="color:#888; letter-spacing:0.12em; font-size:0.58em; margin-top:0.4em;">MEDIAN TIME TO TRIAGE</div></div>
 <div><div style="font-size:2.2em; font-weight:800; color:#f0a020; line-height:1;">1.3h</div><div style="color:#888; letter-spacing:0.12em; font-size:0.58em; margin-top:0.4em;">MEDIAN TRIAGE → SHIP</div></div>
 <div><div style="font-size:2.2em; font-weight:800; color:#00ff55; line-height:1;">≈ $3k</div><div style="color:#888; letter-spacing:0.12em; font-size:0.58em; margin-top:0.4em;">PER MONTH · ALL IN</div></div>
</div>

*5 × Claude Max ($1,000) + CI merge gates ($1,500–2,000). Five people. No code written by hand.*

Note: [~1 min] · ~21:30 in This is the last 30 days — one month — not cumulative since we restarted in January. 496 issues opened. 336 shipped. 138 closed. And the part that matters most: every one of those 336 is a change that cleared the entire gauntlet I just showed you. Design constraints, pre-PR verification in a isolated workspace, attestation, CI gates, auto-merge. These aren't raw AI suggestions — they're changes that passed every verification gate we have. What you're looking at is the output of the machine, not the input. And the speed is real: under five hours to triage, well under two hours from triage to shipped. Five people produced this. Not one line written by hand. And what does the whole machine cost? Five Claude Max seats at $200 — a thousand a month — plus fifteen-hundred to two-thousand for the CI merge gates. Round it to about three thousand dollars a month, all in. That's the entire engineering pipeline that shipped those 336 changes — less than the fully-loaded cost of a single contractor.

---

# swamp
## Deterministic workflows for a probabilistic system

The model's reasoning is **probabilistic**.
The workflow it runs inside is **deterministic**.

*Typed state machines · explicit transitions · validation at every step.*
*The guardrails aren't advice the AI can ignore — they're the workflow it can't leave.*

Note: [~1.5 min] · ~22:30 in Everything so far is how we build swamp. But swamp itself is the same idea pointed at operations — and here's the one line to take away. swamp is deterministic workflows for a probabilistic system. The model at the centre is probabilistic. It's brilliant, but it won't give you the same answer twice — and you cannot let that touch production directly. So swamp doesn't ask the model to "be careful". It wraps the probabilistic reasoning in a deterministic workflow: a typed state machine, explicit phase transitions, validation at every step, every action recorded and auditable. That's the exact machinery you just watched enforce our codebase — the @swamp/issue-lifecycle state machine — now pointed at deployments, configuration changes, incident response, provisioning. This is the distinction that matters: the guardrails aren't guidance the AI can choose to follow. They are the workflow. The AI can only move where the workflow allows. Probabilistic reasoning, deterministic execution — that's what lets AI drive operations without going off the rails.

swamp debugs itself

Let that sink in for a second. swamp has a skill that, when something goes wrong, downloads the version of the source code that matches the running binary — not main, not latest, the exact version — analyses it against what went wrong, and opens a swamp-club issue with full context, reproduction steps, and a suggested fix. The system is filing bugs against itself. And those issues drop straight into the same guardrailed flow we've been talking about — the @swamp/issue-lifecycle state machine: triage, plan, adversarial review, human approval, implement, verify in a isolated workspace, attestation, CI gates, auto-merge. This is what "building the machine" actually looks like when you follow it all the way. [~1 min · ~23:30 in]

## Multi-Agent Development

**Multiple agent sessions work in parallel — each in an isolated git worktree.**

- Every issue gets its own **short-lived session** — no long-running contexts
- No context compaction, no clearing — the session ends when the issue ships
- Different agents **test different models** against the same constraints
- Same guidelines, same CI gates, same state machine — **the rails don't change**

*One session per issue. The model is the variable — the rails are the constant.*

Note: [~1.5 min] · ~24 min in The repo currently has over thirty active worktrees — thirty issues being worked in parallel by different agent sessions. Each one is isolated: its own git worktree, its own branch, its own lifecycle instance. And here's a deliberate architectural choice: every issue gets its own short-lived session. We don't use long-running sessions. When the issue ships, the session ends. No context compaction, no clearing, no degradation over time — the agent starts fresh with the guidelines, the design docs, and the issue context. That's it. This keeps us incredibly token-efficient — and that's because of how swamp is designed. One session per issue, short-lived, focused. My personal usage: 3,000 sessions, 12 billion tokens last month alone — on a $200 subscription. At API rates that would be over nine thousand dollars. The prompt cache does the heavy lifting because every session reads the same guidelines, the same design docs, the same skill definitions. swamp's architecture means short sessions with shared context — you're paying for the delta, not the base. And here's why that matters beyond just cost: we use this to test different models against the same constraints. The guardrails — the agent guidelines, the CI gates, the state machine — are the constant. The model is the variable. We can run the same issue through different models and compare: which one produces better plans? Which one catches more edge cases in adversarial review? Which one writes more idiomatic code? The constraints are what make this safe to do. You can swap the model because the rails don't move.

---

## We're not automating code
## We're **building the machine**
## **that builds the machine**

And **it keeps evolving**

Note: [~1 min] · ~25:30 in People miss this. They hear "AI writes the code" and think we've replaced the engineering. We haven't. We've replaced the typing. What we've done — and are continuing to do — is build the system the AI operates inside: agent guidelines · CI pipeline · issue lifecycle · triage flow · skill library Every one: something humans designed, humans wrote, humans maintain. And crucially — they're not done. Constraint missing → add it. CI gap found → close it + add a reviewer. Session hits a non-obvious problem → encode it into the guidelines. The guardrail system and the codebase evolve together. The AI works confidently because we've built — and keep building — the rails for it to work on.

---

## No more
## bus factor of one

*the architecture lives in the guidelines — not in one person's head*

Note: [~45 sec] · ~26:15 in Every team has a bus factor — how many people can walk out the door before you're in real trouble. In most codebases the important architectural knowledge lives in a handful of heads, so that number is dangerously low. When the senior engineer who knows why the system is structured the way it is leaves, that knowledge leaves with them. The guidelines change that. Every design decision feeds back into the document. CI reviewers enforce it on every PR. Triage workflow applies it before any code is written. New engineers — or new agent sessions — don't absorb the architecture through osmosis. They read the guidelines.

---

# How Can I Get Started?
## Start with what "correct" means.

1. **Understand the user-facing behaviour of your system** — then write acceptance tests that encode it. The agent can't modify them without your approval. That's your immovable specification.
2. **Turn your conventions into constraints** — give one repo a contract the agent can't ignore, not a README it won't read.
3. **Let the agent refactor** — with acceptance tests in place, the agent can change internals safely. If the tests pass, the behaviour is preserved.
4. **Every failure is your next constraint** — write it down. Now you're building the machine.

*Code is cheap now. Defining what "correct" means is the precious human contribution.*

Note: [~1.5 min] · ~27:45 in I used to say start with your conventions. I've changed my mind. Start with your tests. 1. Write black box acceptance tests — tests that verify user-facing behaviour from the outside, not internal structure. Make them immutable: agents cannot modify acceptance tests without explicit human approval. That test suite is your specification — the thing that defines what "correct" means. Everything else can change around it. 2. Then write your constraints — the conventions the agent has to follow. Strict types, import boundaries, the mistake every new hire makes. But now you have a safety net under them. 3. Here's why the order matters: agent-generated code is continuous refactoring. With acceptance tests in place, the agent can change internals safely. If the tests pass, the behaviour is preserved. Without them, you're trusting that the agent and the unit tests it wrote don't share the same misunderstanding. 4. And when something breaks, that failure becomes the next constraint you add. That's the loop — and it's the same loop whether you start today or you've been at it for years. The economics have shifted. Code is cheap now. The bottleneck isn't implementation — it's validation. Your most valuable asset isn't the codebase. It's the tests that define what the codebase must do.

---

## Meanwhile…

*I kicked off a swamp image-triage run when I walked on stage.*

- triaged and classified the issue
- reproduced the issue
- written a plan, then **adversarially reviewed** it
- Now it's waiting for me to give it the go ahead
- It will then implement, verify in a **isolated workspace**, and ask me for permission to open the PR

**Human is always in the loop!**

Note: [~1 min] · ~29:15 in Remember the run I kicked off when I walked on? Let's see where it got to. [SWITCH TO THE LIVE RUN — show the lifecycle output and the PR it opened] While we've been talking, swamp took an image-triage task from raw intent all the way through the machine you've just seen — triage, plan, adversarial review, implement, every gate — completely unattended. Nobody touched the keyboard. That's the whole talk in one artefact: humans built the rails; the machine did the work. (If it's still running, narrate whatever phase it's in — the state machine tells you exactly where it is.)

---

## AI gives you back the work
## you got into this industry to do

**Systems design. Not syntax.**

## Intent is the new architecture.

Note: [~30 sec] · ~30:15 in The bottleneck was never thinking. It was always turning thinking into code. That part is changing. What's left — what grows — is the work most engineers find genuinely meaningful. Figuring out the right design. Understanding the domain. Knowing when the requirements are wrong. Building the system that everything else depends on. So if you take one line away from this talk, take this one: intent is the new architecture. The code is cheap now — what you craft, version, and get right is the precise expression of what you want. That's the bet we've made at Elder Swamp Club. We think it's the right one.

Questions?

Try it out — swamp-club.com

I blog about this entire journey into
agentic software delivery at stack72.dev

Paul Stack
paul@swamp-club.com
@stack72

## "Isn't this just AI autocomplete?"

```
Autocomplete  →  finishes the code you're typing
                 you still author it — and own it

swamp         →  you write the intent + the constraints
                 the agent writes the whole change · the gates prove it
```

**Not faster typing. A different job — you own the architecture, not the diff.**

## Intent is the new architecture.

Note: No. Autocomplete finishes the line you're already typing. This is different in kind. You write the guidelines and an issue. The AI produces complete, architecturally-coherent implementations constrained by both. You're reviewing architecture, not diffs. And that's the line I want you to leave with: intent is the new architecture. The thing you craft, version, and get right is no longer the code — it's the precise expression of what you want. That's where the engineering moved.

---

## "How do you trust something non-deterministic in production?"

- You don't trust the **model** — you trust the **workflow** around it
- Deterministic gates on probabilistic output: typed schemas, review, tests, validation at every step
- Same prompt, different output — but the **gates don't move**

**It's the exact answer swamp gives operations.**

Note: This is the honest objection — LLMs are probabilistic. The same prompt won't give you the same output twice. How can you put that anywhere near production? The answer is that you don't trust the model. You trust the workflow around it. The probabilistic reasoning happens inside a deterministic box: typed schemas it can't step outside, a review it can't skip, tests it has to pass, validation at every step. The model's output varies; the gates it has to clear do not. That's the same thing swamp does for operations — deterministic workflows for a probabilistic system. The non-determinism isn't the problem. Letting it touch production without a deterministic layer around it is the problem — and that layer is the whole point.

---

## "What if Claude misses something?"

```
local verification + 4 CI gates  ·  defense in depth
```

- **Local verification** catches it before the PR opens — lint, test, compile, code review, UX review
- **CI gates** add independent checks — attestation · adversarial · CI security · review integrity
- Better than one human trying to catch everything at once

Note: Defense in depth. The pre-PR verification workflow catches most issues locally — lint, test, compile, code review, UX review, skill quality — all before a PR even opens. Then four CI gates add independent checks: attestation validation, adversarial review, CI security, and review integrity. That's better odds than one human trying to hold all those concerns in their head on a Friday afternoon. And when something does slip through, we add a constraint or a reviewer so it can't happen the same way twice.

---

## "How does `/triage` work?"

```
Maintainer comments /triage
  ↓  reads agent guidelines + design docs
  ↓  independently investigates the codebase
  ↓  reproduces the issue
  ↓  classifies — and if it's a bug, challenges itself: regression?
  ↓  creates a plan and adversarial reviews it
  ↓  code conformance review after implementation
  ↓  verification in isolated workspace
  ↓  posts attestation to swamp-club
Human must approve the plan. Human must approve the PR.
```

**It doesn't take the reporter's diagnosis at face value — it reads the actual code.**

Note: A maintainer comments /triage. The agent reads the guidelines and design docs, then independently investigates the codebase and reproduces the issue. When it classifies a bug, it's forced to challenge itself: is this a regression? It must provide evidence that the behaviour previously worked, then argue the strongest counter-case that it's NOT a regression, then deliver a verdict with reasoning. If the counter-evidence is strong enough, it downgrades the classification. This adversarial self-challenge is built into triage — the agent can't just say "looks like a bug" and move on. After the human approves the plan, it implements, runs a code conformance review against the plan, verifies everything in an isolated workspace, and posts an attestation before asking for permission to open the PR. The key part: it doesn't take the reporter's diagnosis at face value. It reads the actual code and forms its own conclusions before proposing a plan.

---

## "So you're telling me swamp builds swamp?"

**Yes. Self-hosting.**

- The whole triage-to-merge pipeline *is* a swamp automation
- The bugs it files against itself run the same flow
- We trust it on our own most important codebase, every day

Note: Yes — self-hosting. The entire triage-to-merge pipeline I showed you isn't bespoke scripting — it's authored as a swamp automation. The tool that automates our engineering is the product we ship. We point swamp at building swamp. And it ties back to the slide before: when swamp hits a problem in production it files a bug against its own source, and that bug runs the exact same flow as everything else. The loop closes on itself. Why does this matter? It's the strongest proof we have that the system works — we trust it on our own most important codebase, every day.

---

## "You judged 6 years of work after 8 months — honeymoon?"

- Fair challenge. The honest answer: **the speed is the safety net**
- Wrong decision → reversible in an afternoon, not a quarter
- We're not betting it's perfect — we're betting **the cost of being wrong collapsed**

*If the bet is wrong, we'll know fast and cheaply. That's the point.*

Note: It's a fair challenge and I won't pretend eight months is a long time. But here's the thing the honeymoon framing misses: the reason we can move this fast is the same reason being wrong is cheap. If a design decision turns out badly, we reverse it in an afternoon, not over a quarter. So I'm not claiming we've proven this is right for all time. I'm claiming the cost of being wrong has collapsed — and that's exactly the condition under which you *should* make bold bets early. If it's the honeymoon, we'll find out quickly and cheaply. That's a feature, not a risk.

---

## "Is this still open source if you won't take PRs?"

- The **license** is unchanged — AGPLv3, source is public, fork it, run it, audit it
- What changed is the **contribution mechanism**, not the freedom
- You contribute **issues and design** — your ideas shape the architecture, not just a diff

**More open to ideas. More guarded about unreviewed code.**

Note: The license hasn't changed — it's AGPLv3, the source is public, you can fork it, run it, read every line, audit it. None of the four freedoms went anywhere. What changed is the contribution mechanism. PRs assume a human wrote code that understood the architecture — and AI-generated PRs break that assumption at scale. So we take issues instead: you bring the problem and shape the design, the AI implements it inside our constraints. I'd argue that's *more* open, not less — contributors influence the architecture, not just a single diff. We're more open to ideas and more guarded about unreviewed code. Those aren't in tension.

---

## "Who's accountable when auto-merged code breaks prod?"

- **The maintainers. Always.** Automation doesn't move accountability — it's ours
- Every action is **tracked and auditable** — what shipped, why, what each reviewer found
- The rails are a **human decision**; a gap that ships is a gap we own and close

*"The AI did it" is never the answer. We built the machine — we're responsible for it.*

Note: We are. The maintainers. Auto-merge doesn't move accountability onto the AI — that's a category error. We built the rails, we decided what passes, so anything that ships is ours. What automation gives us is something a script-and-hope process never did: a full audit trail. What shipped, why, what each reviewer found, what the tests showed. When something breaks we can reconstruct exactly how it got through. And then we do what the talk is really about — we close the gap. A new constraint, a new reviewer, so it can't happen the same way twice. "The AI did it" is never the answer. We built the machine; we're responsible for what it produces.

---

## "Are junior engineers less valuable now?"

- **The opposite.**
- Constrained by good guidelines, they produce **senior-quality output**
- They get to do **meaningful architectural work earlier**

**The guidelines level the floor up — not the ceiling down.**

Note: The opposite. Constrained by good guidelines, junior engineers produce senior-quality output — the rails carry the architectural knowledge that used to take years to absorb. And it means they get to do the meaningful architectural work — thinking about constraints and design — much earlier in their careers than they otherwise would.