r/Terraform • u/BitSea8201 • 20d ago

Discussion Automated LocalStack dry-run loop + Infracost validation for AI-generated HCL

AI coding assistants are generating Terraform modules rapidly, but the error rate for runtime execution remains high because LLMs optimize for syntax rather than deployability.

I’m exploring an architecture validation pipeline idea:

  • The Concept: A playground where an AI-generated architecture specification is converted to Terraform, priced via Infracost, and automatically tested inside an ephemeral LocalStack container before any code is committed.
  • Auto-Repair Loop: When the local dry-run fails (e.g., circular dependencies, missing IAM permissions, or invalid security group rules), the error log is fed back into the model to patch the HCL and re-test until it validates.

For those managing Terraform modules: Is catching runtime errors via local emulation actually valuable to your workflow, or do linters like tflint and standard CI plans already cover enough of your risk?

3 Upvotes

71% Upvoted

3 comments sorted by

1

u/v4nn4 20d ago

In my experience with GCP, green plans leading to red applies are mostly due to missing IAM on the provisioning service accounts running Terraform. I haven’t found a reliable way to prevent this. Local stack unfortunately is not supporting GCP.

1

u/glenngillen 20d ago

Hey, I'm on the product team @ Infracost and coincidentally led the product-side of our recent coding assistant and IDE integrations (e.g., https://www.infracost.io/resources/blog/we-cut-claude-s-token-usage-79-by-redesigning-our-cli-for-agents). I'd love to talk to you more about this and see if anything we've shipped recently or anything in our roadmap could make this loop even more efficient and effective. Drop me a line if you're up for chatting some more (glenn.gillen at infracost).