Free — no signup required

Building a Safe AI-Assisted IaC Workflow

3 min read

The Human-in-the-Loop Pipeline

The goal is not to avoid AI — it's to use AI in a way that preserves correctness and security guarantees. This means building a workflow where AI accelerates the writing phase but every automated and human check still runs.

A safe AI-assisted IaC workflow looks like this:

1. Write a precise prompt (include provider version, constraints, output format)
        ↓
2. Generate draft code
        ↓
3. Read every line — understand what it does before running it
        ↓
4. terraform validate — catches syntax errors and unknown arguments
        ↓
5. terraform plan — catches logical errors, shows exact changes
        ↓
6. tfsec / checkov / trivy — static security analysis
        ↓
7. conftest (OPA) — policy-as-code compliance check
        ↓
8. Peer review — organizational context, naming conventions, architecture fit
        ↓
9. Merge and apply

Steps 4–8 are identical to what you'd run on hand-written code. The AI changes step 1–2, not the validation pipeline. If your organization has a CI/CD pipeline that runs these checks on every pull request, AI-generated code gets the same scrutiny as human-written code automatically.

Providing Context in Prompts

The single most effective way to improve AI output quality is to provide organizational context in the prompt. This can be done in several ways:

Inline context: Include your conventions directly in the prompt.

"Use the naming convention {environment}-{team}-{resource-type}. All resources must have the tags Environment, Team, CostCenter, and ManagedBy = terraform. The AWS region is always passed as a variable, never hardcoded."

Example-driven prompting: Provide an existing module as a reference.

"Here is an existing module from our codebase that follows our conventions: [paste module]. Write a new module for RDS using the same structure and patterns."

Constraint lists: Explicitly list what to avoid.

"Do not use deprecated arguments. Do not hardcode any values that should be variables. Do not use count for conditional resources — use for_each with a set. Do not enable public access on any resource."

The more context you provide, the less correction work you do afterward. Investing 5 minutes in a precise prompt saves 30 minutes of code review.

When Not to Use AI for IaC

AI is a poor fit for certain IaC tasks:

  • Novel or complex architectures: If you're designing something that doesn't have many public examples (a custom multi-region active-active setup with specific failover logic), the AI has little training data to draw from and will produce generic, incorrect output.
  • Security-sensitive resources: IAM policies, KMS key policies, and security group rules require precise, intentional configuration. AI-generated IAM policies frequently over-provision permissions. Always write these by hand and have them reviewed by someone with security expertise.
  • State manipulation: Never ask AI to generate terraform state mv or terraform import commands for your specific infrastructure. The AI doesn't know your state file, and a wrong state command can corrupt your infrastructure state in ways that are difficult to recover from.

This is one of 18 chapters

Every chapter is free — Kubernetes, Terraform, SRE, distributed systems, and more — with fast daily review built in.

Sign up free