The validation loop: what it actually looks like when an architect pressure-tests AI-generated infrastructure

This is the depth companion to The 10x infrastructure architect isn’t the one who prompts fastest. It delivers the concrete method: what the validation loop actually looks like, run on a real AI-generated config. Access is free — subscribe to read on.

Last week I asked Claude — grounded in the live Terraform Registry via the HashiCorp MCP server — to generate a three-region AWS landing zone. VPCs, transit gateway, security groups, IAM roles, S3 state bucket, deployment pipeline. It came back in about ninety seconds. Clean module structure, sensible naming. Roughly what a capable mid-weight engineer would produce in two days.

Three things were wrong. None of them would have been caught by terraform validate.

That gap is the job. Here is what I actually do with it.

What came back — and what passed validation

The AI’s output was a well-formed Terraform project. terraform validate returned zero errors. A quick read looked fine. But run against our landing-zone principles:

Finding 1 — IAM too permissive. The pipeline role had "Action": "s3:*" with "Resource": "*" on the state bucket policy. Syntactically valid. Explicitly banned by our baseline: No IAM policy may grant wildcard actions on any resource without written justification. Correct scope: s3:GetObject, s3:PutObject, s3:DeleteObject, on the specific bucket ARN.

Finding 2 — Encryption absent. The S3 state bucket had no aws_s3_bucket_server_side_encryption_configuration block. Not a syntax error — simply not generated. Our baseline (and NIS2 Article 21’s “appropriate technical measures” obligation) requires KMS or AES-256 on any bucket holding infrastructure state. One missing resource block; one compliance gap.

Finding 3 — Log retention too short. VPC Flow Logs lifecycle set to 30 days. Our standard is 12 months minimum — NIS2 Article 23 logging obligation, plus our own audit-trail requirement for incident investigation. The AI generated a reasonable-looking default. It is wrong for our context, and only we know that.

All three pass terraform validate. All three fail against our principles.

How the validation actually works

This is not intuition. Every finding maps to a written principle. The checklist I run through for any AI-generated landing zone:

1. IAM scope — every policy, every role. Wildcard actions trigger a mandatory justification before approval.
2. Encryption at rest — every storage resource, every region. Absent encryption blocks approval.
3. Logging and retention — VPC Flow Logs, CloudTrail, S3 access logs. Retention must meet both the internal standard and the applicable regulatory floor (NIS2 / DORA / GDPR, depending on data classification).
4. Network blast radius — CIDR blocks checked against the IP address management register. An overlapping subnet that passes validate creates a routing conflict at apply or, worse, silently corrupts topology.
5. Cost guardrails — right-sized compute, no accidental on-demand in reserved workloads, no orphaned resources.

The AI generates against your prompt. You validate against your principles. These are different inputs — only you have both.

The output: a decision record, not a Slack message

The validation is half the work. The output is the other half. Not “I found some issues” in a thread somewhere — a decision record:

ADR-2026-047 — Landing zone v2.3 initial generation (AI-assisted)
Status: Approved with modifications
Generated by: Claude + Terraform MCP server
Reviewed against: Landing Zone Principles v4.1

Modifications required before merge:
— IAM: scope s3:* → s3:GetObject/PutObject/DeleteObject on specific ARN (LZ-IAM-03)
— Encryption: add server_side_encryption_configuration block, KMS key ref (LZ-SEC-07)
— Log retention: update lifecycle to 365 days (NIS2 Art. 23 / LZ-LOG-02)

Justified exceptions: none
Principles updated: none required — standard applies as written

That document guides the dev team that applies the modifications. It also guides the AI on the next generation cycle: the same principles, encoded as policy-as-code rules (Checkov, OPA, Sentinel), become the guardrails the machine runs inside next time.

This is what leading the AI means in practice. Not fixing the config yourself — authoring the guardrails that make every future generation better.

The Automate / Augment / Reserve split

For deciding where AI fits across your infrastructure work, I use three buckets:

• Automate — AI runs it, architect verifies the output against principles. Initial IaC generation, documentation, runbooks, cost reports. High-velocity; validation is the human step.
• Augment — AI drafts, architect decides. Design options, security analysis, failure-domain modelling. AI narrows the solution space; architect owns the call.
• Reserve — human only. Trade-off decisions (cost vs. resilience vs. compliance), justified exceptions to principles, escalated incident response, stakeholder sign-off on risk.

The full Automate/Augment/Reserve map across infrastructure domains — networking, compute, observability, FinOps, security — is the spine of the book. This is the frame. Article #2 takes it one domain at a time.

The one question

The pillar piece teased it. Here it is:

For every artifact the AI hands you: what breaks, and who pays?

Not “is this correct?” — the AI already gave you plausible. “What breaks” forces you to trace failure domains. “Who pays” forces you to think about blast radius: the team, the budget, the compliance posture, the customer.

If you can’t answer both, you don’t know enough to approve it yet. That pressure-test takes about five minutes on a mid-size config. Those five minutes are the line between amplified and replaced.

Next

Article #2 maps the Automate/Augment/Reserve split to specific infrastructure domains — with the boundary cases that are easy to get wrong.

If you want the full validation checklist — principles template + ADR template + starter Checkov rules — that goes in the book.

---

If you can’t beat them, lead them.