Building on AWS with an agent

An agent can build infrastructure far faster than a person can review it. These practices exist so that speed stays an advantage — each one makes the agent's work easier to inspect, cheaper to undo, and harder to get catastrophically wrong.

Insist on infrastructure as code

This is the highest-leverage instruction you can give. Ask for Terraform, CDK, or CloudFormation rather than console clicks or raw CLI calls.

Console changes leave you with infrastructure nobody can explain and nobody can reproduce. A definition file gives you a diff to review before anything is created, a record of why each resource exists, and a way to rebuild — or tear down — everything cleanly.

Set this up as Terraform under infra/, and show me the plan before applying anything.

ℹ Info:terraform plan is the natural review checkpoint: the agent proposes, you read the resource list, then it applies.

Separate environments before you need to

Have a staging environment from day one, and let the agent work there freely. “Do it in staging, show me, then we promote” is the workflow that lets you move quickly without holding your breath.

Separate AWS accounts are the strongest boundary — a mistake in one cannot reach the other, and per-account budgets become meaningful. Separate resource prefixes in one account are weaker but far better than nothing.

Whatever you choose, make sure the agent knows which is which: “the staging profile is `acme-staging`; never run against `acme-prod` without asking.”

Least privilege, and let it tell you what it needs

Grant the narrowest permissions that let the work proceed, then widen in response to actual denials. An agent that reports “AccessDenied on s3:PutBucketPolicy” has told you precisely what to add — and given you the chance to ask whether it should be doing that at all.

Be especially deliberate about IAM permissions themselves. A credential that can modify IAM can grant itself everything else, which makes every other limit decorative.

Make cost visible while it is still small

The expensive AWS mistakes are rarely dramatic. They are a NAT gateway nobody needed, an oversized RDS instance, a log group with no retention, or an idle environment left running for a month.

Set a budget alert before granting write access — see Linking an AWS account.
Ask for the monthly cost estimate alongside any new infrastructure. “What will this cost me at idle?” is a fair question and the agent can answer it.
Set log retention explicitly. CloudWatch defaults to keeping logs forever.
Ask it to tear down experiments when you are done. Infrastructure as code makes that a single command instead of an archaeology exercise.

Keep production changes reviewable

Have the agent open pull requests rather than pushing to your main branch, and keep deploys gated on your approval. Reviewing a diff of intent is much easier than reconstructing what changed from CloudTrail after the fact.

For anything customer-facing, ask for the rollback path as part of the work: “deploy this, and tell me the exact command to roll back.” If a change cannot be undone, that is worth knowing before it ships rather than during an incident.

Verify against reality, not against the plan

A merged pull request and a green build are not proof that production changed. Ask the agent to confirm from the running system — the deployed version, the live health endpoint, the actual resource — and to show you what it saw.

This one habit catches a surprising share of “it's done” reports that were not.

Secrets belong in a secret store

Ask for Secrets Manager or SSM Parameter Store, never environment variables checked into a repository, and never credentials in a Terraform file. If the agent needs a value in order to build something, it can read it at deploy time rather than committing it.

If a credential is ever exposed in a log, a commit, or a screenshot, rotate it rather than deleting the evidence. Rotation is cheap; assuming it was not captured is not.