Infrastructure Was Just the First Use Case

Swamp, initially built for infrastructure automation, has evolved into a domain-agnostic automation primitive as users applied it to security scanning, cost analysis, and infrastructure validation. The platform's extension model enables agents to build typed, publishable extensions from API documentation, making automation accessible across teams.

Infrastructure Was Just the First Use Case Infrastructure was the first use case we looked at with swamp. Then users started solving security, finops, and validation problems with the same model. By the fifth time, it was hard to treat it as a coincidence. We'd built an automation primitive, and infrastructure was just where we'd pointed it. Infrastructure was the first use case we looked at with swamp https://github.com/swamp-club/swamp?ref=stack72.dev . It was February 2026, and we were entering the boom of AI and existing IaC tools weren't really designed for it, so it was a natural place to start. The first extensions we shipped were fundamentals like shell, command, and docker to prove the model worked. Then we started pushing it further, and our users found they could automate a lot more than standard infrastructure problems. A security team built extensions that scan dependencies against CVE databases. A platform team built cost analysis extensions that pull cloud billing data and flag anomalies. Someone built infrastructure validation that compares tfstate against actual deployed state as a post-deploy smoke test. None of these are infrastructure automation in the way I'd always thought about it, but they're all the same shape: start an agent, describe the problem you need to solve https://stack72.dev/intent-is-architecture/ , and let it build the extension and get the data you need. The first time we saw this happen outside infrastructure, we thought it was a one-off. By the fifth time, it was hard to treat it as a coincidence. We'd built an automation primitive, and infrastructure just happened to be the first place we'd pointed it. What CVE scanning used to look like Before swamp, our CVE checking process was a Python script that queried vulnerability databases, diffed the results against our dependency list, and produced a CSV. It ran when one person remembered to run it, broke when the API changed, and nobody else on the team could run it without asking how. We were doing enough to say we were scanning for CVEs, but not enough to catch issues early. We pointed an agent at the problem. We gave it the extension model https://stack72.dev/every-platform-promises-any-system-heres-why-they-dont-deliver/ and the documentation for the vulnerability databases we wanted to query. The agent didn't start with security expertise. It started with the extension model and the API documentation, and that turned out to be enough. It built model types with methods like scanDependencies and checkCVE , wrote pre-flight checks that validate the input format, and produced a publishable extension. The whole thing is on swamp-club https://swamp-club.com/?ref=stack72.dev now. Anyone on the team can install it and run it, any agent can discover it and use it, and every scan produces versioned data so you can compare this week's results against last week's. The cost analysis extensions happened the same way. Agent, billing API docs, description of what the output should look like. The infrastructure validation extensions too. After a few of these had been built, conversations stopped being about security or cost analysis or validation. We found ourselves talking about the process instead, because the implementation kept looking the same regardless of the domain. The agent that built the CVE scanner and the agent that built the cost analyser followed the same steps. They read the extension model, they read the domain documentation, they produced typed model methods with pre-flight checks. The domain was different every time. The process wasn't. We'd built the extension system thinking about infrastructure providers, but the pattern underneath it turned out to be completely domain-agnostic. That's also where the IaC comparison stops making sense. Terraform provisions resources. CloudFormation provisions resources. Pulumi provisions resources. A CVE scan isn't a resource. A cost analysis isn't a resource. An infrastructure validation check isn't a resource. They're work. Once we'd seen vulnerability scanning, cost analysis, infrastructure validation, and a handful of other examples built in exactly the same way, comparing swamp to Terraform stopped making much sense to us. They solve fundamentally different problems. Infrastructure is just one category of operational work that fits the pattern. Built to work once Every team has jobs like the CVE script. A Jupyter notebook that pulls billing data and makes charts for a quarterly review. A shell script that curls an API and diffs the output against expected values. They work when the person who wrote them runs them, and they break when anything else changes. Nobody designs them to last because nobody thinks of them as real tooling. They're stopgaps that quietly become permanent. The thing that actually changed wasn't the tooling itself, it was that anyone on the team could now do the work. The CVE scan used to run when one person remembered. Now it runs on a schedule and anyone on the team can trigger it. The cost report used to be a chart someone emailed last quarter. Now it's queryable data you can compare across months. The infrastructure validation used to be a script someone ran after an outage. Now it's a workflow step that pages someone when it fails. None of that required the team to learn a new tool in the traditional sense. They described the problem and an agent built the extension. Every team has a backlog of automation like this that should exist but doesn't, because building proper tooling for each one always felt like overkill. That calculus changed when the cost dropped to describing the problem. The jobs that used to rot in backlogs actually get built, and each one compounds https://stack72.dev/the-first-step-on-your-ai-journey-is-encoding-what-you-already-know/ the same way every other piece of encoded knowledge compounds in swamp. By that point, infrastructure felt like just another example rather than the thing we were actually building around. The teams getting the most out of swamp aren't trying to rebuild their Terraform. They're taking work that lives in scripts, notebooks, spreadsheets, and tribal knowledge, and turning it into discoverable automation.