I Wrote a Constitution to Govern the AI That Builds My Infrastructure

A growing share of my infrastructure work is done with AI agents in the loop. They draft Terraform, write deploy scripts, and propose CI pipelines. They are fast, tireless, and occasionally catastrophically confident. Speed without judgment is a liability, so I did the only reasonable thing: I wrote them a constitution.

That is not a metaphor. The final part of my internal DevOps guidelines is a document that declares itself the supreme authority over any AI agent doing infrastructure work on my projects. It defines a precedence order for when rules conflict, an output template the agent must follow, and, most importantly, four hard reject gates: security, reliability, observability, and cost. If a proposed change fails any gate, the agent must refuse to proceed, no matter how convincing the plan looks.

Why so formal? Because the failure mode of AI-assisted infrastructure is not dramatic hallucination, it is plausible mediocrity. An agent will happily generate a deployment setup that works on the happy path and quietly embeds a static credential, skips health checks, or provisions something expensive. Each choice looks locally fine. A human reviewer skims twenty lines of generated YAML and approves. The rot is cumulative.

Rules that live in your head do not survive contact with a code generator. Rules written down, with explicit reject conditions, can be pasted into every session, enforced in review, and pointed to in an argument. The constitution turns "I have a bad feeling about this" into "this fails gate two, here is the line".

The gates are deliberately blunt. Security: no static long-lived credentials, no secrets in code or CI variables when a managed identity exists, never trust location, trust identity. Reliability: no deploy path without rollback, no service without health checks, an untested backup is an assumption, not a recovery plan. Observability: if it cannot be seen failing, it does not ship. Cost: every resource has an owner and a reason, or it gets deleted.

Here is where the story gets embarrassing, which is to say useful. After finishing the constitution, I did the obvious thing and audited my own production setup against it. The result was a gap analysis document that I keep in the repo, and my own infrastructure failed several of its own gates.

Two failures stood out. First, deployment was SSH plus file copy: log into the server, pull, restart. It works, and it fails the reliability gate completely: no atomic release, no rollback, no audit trail beyond shell history. Second, and worse, static cloud credentials sat in GitHub secrets: long-lived access keys of the exact kind the security gate bans, because leaked long-lived keys are how small projects end up mining cryptocurrency for someone else.

I could have quietly fixed both and pretended the constitution sprang fully formed from principled engineering. I left the gap analysis in the repo instead, with warning markers on every failed check. A rulebook that has never caught its own author is marketing material. One that has caught you, with receipts, is a tool.

There is a broader lesson about working with AI here. The value of the constitution is not that it makes the agent smarter. It is that it makes the agent refusable. When an agent proposes something that fails a gate, the conversation stops being a negotiation with a very confident text generator and becomes a checklist lookup. The agent drafts, the constitution judges, and I decide. That's the correct hierarchy, written down so it survives my own laziness at midnight.

The CI insight from the same guidelines applies doubly to AI-generated changes: CI/CD is not a deployment tool, it is a trust pipeline, and the output of CI is confidence. Generated code enters with less trust than hand-written code, so it must earn more of it mechanically: stricter linting, mandatory plan review, no direct-to-production paths.

If you are letting AI write infrastructure, write the constitution first. Make the gates binary. Then run your own systems through it and publish what fails. The document that survives that exercise is worth following.