This is the move from building software to running it. A model writes the container definition, the build and deploy pipeline, the infrastructure definition, the environment configuration and the alerts. It reads a failed build log and says what broke. It explains an infrastructure file nobody on the team wrote. Some agents can act on the infrastructure directly, through a command line or a connection to the provider.
The files involved are short, and they decide more than most of the code does: where the software runs, what it can reach, who can reach it, what it costs and what happens when it falls over.
What it is for
- A first container definition and pipeline for a project that has neither.
- Turning a plain sentence, such as "deploy every merge to the main branch once the tests pass", into configuration.
- Reading a failed build or a crash log and finding the line that matters.
- Translating infrastructure you inherited into something you can read, before you change it.
- Drafting alerts, health checks and the runbook for the incident you hope not to have.
Who it suits
Developers who already ship and now have to keep something running without an operations team behind them: solo builders, small teams, anyone who self-hosts. It suits people who will read the configuration as carefully as the code, because the configuration is what runs with real credentials.
It is not a shortcut past understanding how the software runs. It is a faster way to write down what you already understand, and a patient explainer for what you do not understand yet.
How to tell this is your category
- The files in question say where and how the code runs, not what it does: container definitions, pipeline files, infrastructure definitions, environment variables, alerts.
- A mistake shows up as a failed deploy, an outage or an invoice, not as a failing test.
- If the machine in question is where you write the code rather than where it runs for its users, that is a cloud development environment.
What it costs you later
- Real credentials, real systems. Generated configuration runs against production with production rights. A wrong line is an outage, an exposed database or a bill, and it lands at the speed of a deploy. Do not give an agent production credentials or the right to apply changes. Where the tool can show what it will change before changing it, read that plan, not only the file. A connection that lets an agent act on the provider directly runs with whatever access you gave it, because a protocol is not a sandbox.
- Open by default. Configuration that works first is often configuration that is open: a port reachable from anywhere, a database on the public internet, storage anyone can read, a container running with more rights than it needs, a permission granted to everything because the narrow one failed. All of it works in the demo. Ask of every generated grant what it allows that nothing needs.
- Secrets in the wrong place. A secret pasted inline to make the build pass, an example value that is real, a token printed to a build log, an environment file committed with the rest. Secrets come from the platform's secret store and never appear in the repository, and a pipeline that prints them is a leak with a timestamp.
- Versions nobody pinned. A base image or a pipeline step referenced as "latest" changes under you without a commit, and the build that passed yesterday fails today for reasons in nobody's diff. Pin versions, and upgrade them on purpose.
- Configuration nobody can explain. A pipeline that works and nobody understands is fine until the night it stops. Vibe coding builds fast, but can you explain it later? is about that night. If no one can say what each step does and why it is there, the configuration is not finished.
- Alerts that cry wolf, or none at all. Ask for monitoring and you can get an alert on everything. An alert that fires every day is soon ignored, including on the day it matters. Decide what a person should be woken for, alert on that, and send the rest somewhere nobody is paged by.
- Merging is shipping. Where every merge to the main branch deploys, as it does for this site, a change to the pipeline is a change to how everything ships. Review it with the care you give code that touches money, and keep a check that has to pass before anything deploys. Security checks belong in that path too, running on every change rather than once a quarter, the argument AI is finding bugs faster than teams can fix them makes.
Reviewing an infrastructure change
- What can it reach, and who can reach it?
- What will it change, shown as a plan before it is applied?
- Where do its secrets come from, and can any of them end up in a log?
- Is every version pinned?
- How is it undone? A change with no way back deserves a person's approval before it runs, not after.
- What alerts if it goes wrong, and who gets woken?
- Could you explain each step to whoever is on call?