The Dark Side: Hallucinations and Drift

The "Confident Liar"

LLMs predict the next statistically likely token. They do not look up documentation. They do not run terraform validate. They have no mechanism to distinguish between a real Terraform argument and a plausible-sounding one they invented. And critically, they present both with identical confidence.

This is the hallucination problem, and it is particularly dangerous in IaC because the failure modes are not always immediately obvious.

Common failure modes in generated IaC:

1. Hallucinated arguments. The AI writes:

resource "aws_s3_bucket" "b" {
  bucket        = "my-bucket"
  force_destroy = true
  region        = "us-east-1"   # This argument does not exist
}

The region argument on aws_s3_bucket does not exist in the AWS provider. Terraform will fail with An argument named "region" is not expected here. This is a benign failure — it surfaces immediately. More dangerous are hallucinated arguments that Terraform silently ignores, or arguments that exist but do something subtly different from what the AI described.

2. Outdated syntax. LLMs are trained on historical data. A significant portion of Terraform code on the internet was written for versions 0.11 and 0.12. Generated code frequently uses patterns that were valid then but are deprecated or removed now:

# Old (Terraform 0.11 style) — AI frequently generates this
resource "aws_instance" "web" {
  ami           = "${var.ami_id}"    # String interpolation unnecessary in modern HCL
  instance_type = "${var.size}"
}

# Modern (Terraform 1.x) — what you should write
resource "aws_instance" "web" {
  ami           = var.ami_id
  instance_type = var.size
}

For AWS provider specifically, the v3→v4→v5 migrations involved significant breaking changes to S3, EC2, and IAM resources. AI frequently generates v3-style code even when you ask for v5.

3. Insecure defaults. The internet is full of tutorial code that prioritizes simplicity over security. LLMs trained on this data reproduce these patterns:

• S3 buckets with ACLs enabled (deprecated and insecure in provider v4+)
• Security groups with 0.0.0.0/0 ingress on port 22
• IAM policies with "Action": "*" and "Resource": "*"
• Hardcoded credentials in user_data scripts

These patterns appear in the generated code not because the AI is malicious, but because they appear frequently in the training data. The AI has no concept of "this is a bad practice."

Maintainability and the Understanding Gap

There is a subtler long-term risk beyond immediate correctness: the understanding gap.

If you generate 3,000 lines of complex Terraform — a multi-region VPC with Transit Gateway peering, complex IAM roles, and a service mesh configuration — using AI, and you commit it without deeply understanding how it works, you have created technical debt with a time bomb attached.

When that infrastructure breaks at 3 AM (and it will), the AI won't be there to debug it. You will be staring at a terraform plan diff that shows unexpected changes to resources you don't fully understand, trying to reason about state that you didn't build from first principles.

The rule is simple: never commit infrastructure code you cannot explain line by line. Use AI to accelerate your writing, not to replace your understanding.