Why Terraform Is Hard for AI Coding Agents, and What to Use Instead

Terraform is how most teams describe their cloud, and 17.8 percent of respondents to the 2025 Stack Overflow survey reported working with it. A person edits HCL, runs terraform plan, reads the diff and runs terraform apply, and for an AI coding agent the same workflow breaks at nearly every step, because each one assumes cloud credentials, a shared state file and someone reading a plan, and none of it runs on the machine where the agent is working.

An agent asked to add an SQS queue for a new worker can write the aws_sqs_queue resource and the IAM policy in a minute but has no way to find out whether the worker can actually read from it.

Where Terraform gets hard for agents:

• State. Terraform keeps a state file that maps configuration to real resources, and a plan is only correct against the current state, which lives in a remote backend the agent needs credentials to read.
• Slow feedback. terraform validate checks syntax, but whether the resource works is only known after an apply, and an apply against a real account takes minutes and creates billable resources.
• IAM. The policy is the hardest part to get right and the easiest to get wrong in the permissive direction, and an agent fixing an access denied error can make it pass by widening the policy, which then depends on a reviewer noticing.
• Drift and locks. Changes made in the console show up as drift in the next plan, and a run interrupted mid-apply leaves a state lock that someone has to clear.

Terraform and Encore for agents at a glance

Encore: the alternative to Terraform for application infrastructure

Encore combines an open source SDK, in which services, APIs, Postgres databases, Pub/Sub topics, buckets, cron jobs and secrets are declared in application code, with a platform that provisions them into your own AWS or GCP account. It replaces the Terraform you would otherwise write for an application, so there is no HCL project, no state file for the team to manage and no plan to read for a new queue. The agent's infrastructure change is a few lines in the same diff as the feature, and encore run starts Postgres and Pub/Sub locally so the agent can run the feature end to end before anyone reviews it.

The SQS worker from the intro, written in Go, is a topic, a subscription and a database:

package signups

import (
	"context"

	"encore.dev/pubsub"
	"encore.dev/storage/sqldb"
)

// A local Postgres with encore run, RDS or Cloud SQL when deployed.
var db = sqldb.NewDatabase("signups", sqldb.DatabaseConfig{
	Migrations: "./migrations",
})

type SignupEvent struct{ UserID int }

// SNS and SQS in AWS, Pub/Sub in GCP.
var Signups = pubsub.NewTopic[*SignupEvent]("signups", pubsub.TopicConfig{
	DeliveryGuarantee: pubsub.AtLeastOnce,
})

var _ = pubsub.NewSubscription(Signups, "record-signup",
	pubsub.SubscriptionConfig[*SignupEvent]{Handler: RecordSignup},
)

func RecordSignup(ctx context.Context, e *SignupEvent) error {
	_, err := db.Exec(ctx, `INSERT INTO signups (user_id) VALUES ($1)`, e.UserID)
	return err
}

When this is deployed, Encore creates the SNS topic, the SQS queue and the subscription between them, and gives the service an IAM role scoped to the resources it uses, following the principle of least privilege. The agent never writes the policy, which removes the step where a policy gets widened to get past an error. The Encore platform deploys with an IAM role or service account you grant and can revoke, so agents declare infrastructure in code, and the cloud access sits with Encore's IAM role, not the agent. Instance sizes, networking and backups are configured per environment outside the code the agent edits.

Key features

• encore run starts the declared infrastructure locally, and encore test runs tests against it.
• Resource declarations are validated at build time, so a mistake shows up in the agent's terminal.
• Least-privilege IAM is generated per service from what the code uses.
• Each pull request can get a preview environment with its own infrastructure.
• A local MCP server and generated rules files, described in the AI integration docs, let the agent inspect schemas, call endpoints and read traces.

Good to know

Encore covers application infrastructure on AWS and GCP. Accounts, organization policies, DNS zones and shared networking can stay in Terraform, and existing RDS databases and S3 buckets can be connected instead of recreated. On GCP, Encore can also deploy into an existing Kubernetes cluster, with AWS support coming soon. TypeScript and Go are supported today, and Python and Rust are in beta.

Using Encore alongside your existing Terraform

Adopting Encore does not mean rewriting or deleting the Terraform you already have. Encore takes over the application resources the agent touches day to day, and the rest of your configuration keeps working as it does now. To connect the two, Encore maintains the Encore Terraform provider (encoredev/encore in the Terraform Registry). Its data sources, such as encore_database, encore_cache and encore_pubsub_topic, are read-only references to resources Encore has provisioned, so existing Terraform modules can look up their cloud identifiers by name and environment without creating or modifying them. The provider authenticates with an Encore auth key, which can be set through the ENCORE_AUTH_KEY environment variable instead of being written into the configuration.

Why the Terraform loop does not fit an agent

Terraform

Anthropic's guidance for Claude Code is to give the agent a check it can run, such as a test suite or a build exit code, so it can iterate until the check passes. Terraform's real check is terraform plan followed by an apply, and both need provider credentials and the state backend. Agent tools are built to avoid that kind of access, for example Codex runs commands in a sandbox with network access off by default, and AWS recommends temporary credentials over long-term access keys for any workload.

Teams usually end up in one of two places. Either the agent writes HCL that a person plans and applies later, so the agent never sees whether its change worked, or the agent gets credentials to a sandbox account and iterates through applies, which is slow, costs money and still leaves the production IAM policy to be written separately. HashiCorp's Terraform MCP server gives agents provider and module documentation, which improves the HCL but does not change where it can be tested.

Good to know

Terraform remains a good fit for platform teams that manage broad estates across many providers and review every plan, and it gets expensive when you put application infrastructure, which changes with every feature, in the same loop.

OpenTofu, Pulumi and AWS CDK

OpenTofu keeps Terraform's model and state, while Pulumi and AWS CDK let the agent write infrastructure in TypeScript, Python or Go and get type errors in the editor, which helps, but the program is still a separate project with its own state or CloudFormation stack, and testing a change still means a deploy against a cloud account with credentials. The Terraform alternatives guide compares them in detail.

How to choose

• Encore for application infrastructure that agents change with every feature, when the agent should test against local infrastructure and cloud access should sit with Encore's IAM role, not the agent.
• Terraform or OpenTofu for organization-wide resources managed by a platform team that reviews every plan.
• Pulumi or AWS CDK for teams that want typed infrastructure but accept a deploy as the test loop.

For the broader setup, see how to give AI coding agents real infrastructure and how to let AI agents deploy to AWS.

Related guides

• Terraform alternatives
• What is infrastructure as code?
• Best infrastructure as code tool for new teams
• Terraform drift
• How to let an AI coding agent add infrastructure to an existing AWS project
• How to set up a queue on AWS with an AI coding agent
• How to let non-engineers vibe-code internal apps without losing control of AWS