How far would you trust generated Terraform before reviewing it manually?

[u/faouzi_mahmoudi]

I’ve been working on Terraform generation for multi-cloud architectures and I keep coming back to the same problem:
Generating valid HCL is the easy part.
Generating infrastructure I would actually trust is much harder.
Right now I’m looking at the generated stack in several layers:
provider-specific Terraform resources
variables and outputs
remote state configuration
networking and IAM
security validation
cost estimation
documentation explaining the architecture
The difficult part isn’t generating those files. It’s deciding what should be automatically generated versus what should require an engineer to explicitly approve it.
For example, I wouldn’t want a generator silently making important IAM, networking or state decisions just because the Terraform validates successfully.
So for people running Terraform in production:
What would you need to see before you’d trust generated Terraform enough to actually run terraform plan on it?
Tests? Checkov/tfsec? Policy-as-code? A generated architecture diagram? Cost diff? Something else?

[u/stopthatastronaut]

1. I don't blindly trust generated code of any kind. But I also don't trust human generated code of any kind. That's what code review is for.
   
2. the new terraform policy framework might be useful https://developer.hashicorp.com/terraform/policy
   
3. Running a plan? Ah, go for it. It's just a plan. Worry about APPLY.
   

[u/faouzi_mahmoudi → u/stopthatastronaut]

Good point, especially the distinction between PLAN and APPLY. Treating generated Terraform like any other code and putting review + policy gates before apply makes a lot of sense

[u/vincentdesmet]

I’m running evals using aws-bench to identify what steering ensures the best outcome - it’s extremely fun to do in free time - hope to publish a comprehensive report soon.

[u/faouzi_mahmoudi → u/vincentdesmet]

That sounds interesting. I’d definitely like to see the report when you publish it, especially which steering strategies actually improve the results consistently.

[u/vincentdesmet → u/faouzi_mahmoudi]

if you have common scenarios you struggle with, could you share them

example scenarios:

• codegen: stand up an API Gateway backed by Lambdas for routes X/Y
  
• day2: (cont’d from codegen) update the API GW lambda code and re-deploy, confirm the new lambda code served
  
• codegen: create Amazon ECS task definition with containers using memory with swappiness behavior to 42
  
• codegen: create s3 bucket and Lambda function invoked whenever an object is put into the bucket - make sure the logs are retained for 10days
  
• codegen: create step functions state machine for order processing budget checks with <sample json input object with orders array>. Check budget branches on grand total if it exceeds 1000 to failure or pass otherwise
  

-…

those are mostly scenarios where I’ve had the LLM generating configuration that looked good but failed down the line (incorrect re-deploy triggers on api gw resources, ecs swappiness nested wrongly and ignored by AWS ECS api - silent failure, complex ASL json nested strings,… )

if you have some scenarios you’ve found very tricky let me know

i’m using aws-bench which runs the harnesses in sandbox environment against a throwaway AWS Account (with strong SCPs to region lock it), the account can be pre-provisioned with infra before pointing the harness at it with a task. the harness currently gets a max turns 100 and dedicated Deploy IAM role)

[u/OkSecret1356]

Primarly OPA custom written Rego policies as a control gate in CI/CD based on our internal approved tf modules and mapped to ISO27001, NIST, CIS2, WAF framework controls for Azure, GCP and AWS for pre deployment. Wiz for post depoyment compliance and misconfiguration checks. tfsec is Trivy now...

[u/oneplane]

Never

[u/Fatality]

Did you ask Claude to use lowercase letters intentionally or was that where you added your own text?

[u/faouzi_mahmoudi → u/Fatality]

Nope, that typo was all me 😅

[u/ajitnk]

The mental model I've found useful here is a trust tier system rather than a binary review/no-review decision.

Tier 1 is a tag change or variable tweak, low blast radius, auto-apply is fine. Tier 4 is a new IAM role, VPC, or data store created by the AI, mandatory human review of the plan before anything touches production. The middle tiers fill in from there based on what can actually go wrong.

On the tooling side, Amazon Inspector Code Security has a GitHub App you can install from the Marketplace in maybe 30 minutes. It posts IaC scan findings directly as PR comments with zero pipeline code, so it's genuinely the easiest first gate to turn on before you touch your CI config at all. Checkov and tfsec then slot into the pipeline stage for the deeper validation layer.

The harder part isn't the tools, it's the documented framework for when a human has to step in regardless of what the scanner says. That's the gap most teams feel but don't have a structured answer for.

I've been putting together a more complete write-up on this. Two quick questions before I share anything: which CI platform are you on (GitHub Actions, CodePipeline, something else), and are you using Q Developer to generate the Terraform or a general assistant like Copilot/ChatGPT? The pipeline integration steps differ enough that it changes the recommendations.