AI agents build software quickly, but they don’t default to building systems with great operational quality. Using agents to build the infrastructure that hosts software feels especially risky. But we need to incorporate infrastructure into agentic software delivery workflows not only to keep up with the pace, but to handle rapidly increasing pressure on reliability, security, and scalability.
I’m experimenting with how to use agents to build AWS infrastructure to run a sandboxed instance of OpenClaw for myself. It’s a nice dogfooding project that I’m actively relying on and needs constant work to keep up with frequent software releases and changes as I add new capabilities and data.
I could just fire up Claude Code with AWS credentials, give it a prompt or spec for the infrastructure I need to run OpenClaw, and let it loose with the AWS CLI - “vibe infrastructure engineering”. Claude is happy to crack on with it. The agent will make mistakes along the way, but it knows the outcome I want and will iterate on the implementation until it gets there.
The challenge is that my coding agent does a messy job of it. It takes multiple tries to find a command that works and casually blows away data and application configuration. When I ask for a minor change it replaces a solid, efficient implementation with a slow, less-reliable bodge. At one point it started implementing a Slack gateway, something already built into OpenClaw. Working with an AI agent reminds me of working with an old-school system administrator who likes to build everything by hand.
Code for Consistency
Infrastructure code gives me consistency. I define the set of resources I need and how to assemble them. Then I can build, rebuild, and replicate the system, and know it’s essentially the same. Infrastructure code is an anchor for my coding agent. Rather than starting from scratch for every change, the agent starts with the existing code, and I guide it to incrementally improve the quality of the infrastructure. The agent can also use existing code as a reference for new infrastructure with similar requirements, so it will thrash less deciding how to build it.
Having code helped me move from my original OpenClaw build to a new AWS account with additional capabilities. I built it using Swamp as my infrastructure coding tool. I decided to try Swamp because it’s written from the ground up to be used by AI coding agents. I had Claude build the new instance infrastructure by copying the relevant Swamp models and workflows from the original repository. Starting with a specification or export of the existing AWS resource structure would have needed much more time to work out a new implementation.
Code for Confidence
One of the reasons I’ve always liked using code to build infrastructure is that it gives me confidence when making a change, which helps me to make changes faster and more often.
I can inspect and run checks on the code before deploying it. I can deploy a disposable replica and run active tests to make sure it works the way I want. I can test the operational tolerances of my system by running stress tests, failure scenarios, and attacks on a replica. And if I still end up hosing my production instance, I can quickly rebuild it, presuming I’ve also automated data and configuration persistence.
The confidence I get from using code to manage my infrastructure makes it less scary to change it. So I can knock out fixes, improvements, updates, and new capabilities whenever I need to, rather than leaving them on a backlog to get around to. For years this has served me well working with fast-paced human software delivery teams. Agentic fire-hoses of software and infrastructure code make confidence in the reliability of the workflow even more important.
Infrastructure code by itself isn’t enough to make agentic infrastructure as reliable as I need it to be. I’ll go into more details of creating an agentic harness for infrastructure in a separate post, building on what my colleague Birgitta Böckeler has been writing about harness engineering.
Code for Composability
The benefit of using infrastructure code with agents that I’m particularly excited about is being able to reuse infrastructure implementations.
The Infrastructure as Code ecosystem includes many attempts at shareable libraries, but we’ve never achieved anything close to what operating system and programming language packaging systems have. Maybe infrastructure code is too brittle, or organizations’ requirements are too idiosyncratic. But unlike static libraries, agents can adapt code to specific needs and context. As Mitchell Hashimoto and Adam Jacob have pointed out, agents are particularly good at assembling pre-existing components.
If a coding agent can adapt working, pre-built code to the needs of a specific workload in a specific organization’s context, then we may have the basis for a healthy ecosystem of infrastructure components. Even as models get better at writing infrastructure code that works on the first try, having pre-built components will be faster and more consistent. Off-the-shelf infrastructure components, combined with a robust delivery harness that enforces compliance and operational standards, can empower developers to build and deploy production-grade systems, something I previously described as the return of NoOps.
Photo by Georg Eiermann
