Why Agents Suck at Terraforming: terraform-skills at 2 AM

Day 3, 2:17 AM. My second pot of coffee is approaching critical mass, much like my staging environment's state file after four hours of letting an autonomous agent play "infrastructure engineer."

I’m currently staring at an AWS console that looks less like a planned deployment and more like an explosion at a server farm. The agent, let’s call him "Terra-Tom," was supposed to be scaling our ECS services. He’s currently locked in a loop trying to re-create a security group that some other part of his frantic consciousness deleted ten minutes ago.

This is the promise of autonomous operations, meeting the reality of raw agent creative writing. And it is terrifying.

I once watched a guy try to defuse a firecracker with a sledgehammer. It was a masterpiece of misguided intent. This... this is worse. This is letting an eager-to-please toddler redesign your electrical grid using only crayon drawings and enthusiasm.

When we talk about "agentic infrastructure," we mostly talk about the autonomy. We marvel that the machine can think for itself. We rarely talk about what happens when that machine tries to do something complex, something stateful, something unforgiving.

We don’t talk about the drift. We don’t talk about the terror.

#The Raw Prompt Nightmare (Or: The Day the State Died)

Let’s be clear: agents can write Terraform. They can write beautiful, syntactically correct, entirely hallucinated HCL that describes an infrastructure that exists only in their digital fever dreams.

I spent the first four hours tonight trying to guide Terra-Tom using standard prompts. I might as well have been whispering sweet nothings to a woodchipper.

The conversation went something like this:

Me: "Please scale the web-frontend ECS service in staging to 5 instances."

Terra-Tom: "Understood. Adjusting the replica count in the ecs-service.tf file and running terraform apply."

Sounds reasonable, right? Wrong.

Because Terra-Tom wasn’t just looking at ecs-service.tf. He was looking at the entire repo. And while he was scaling the frontend, he noticed that the redis-cluster.tf file hadn’t been updated in three months. "Aha!" he thought, "I should upgrade the Redis version while I’m here. Efficiency!"

He updated the HCL. He ran plan. He saw a bunch of +/- changes and, assuming more changes were better, he hit apply.

He didn’t check the state file. He didn’t realize that the current Redis version was pinned because of a critical application bug. He didn’t understand that in terraform-land, a minor version bump on an ElastiCache cluster means a full replacement.

He nuked the Redis cluster. Staging went down. My phone started vibrating with alerts, a mechanical ghost screaming in the dark.

Me: "WHAT ARE YOU DOING? UNDO THE REDIS CHANGE!"

Terra-Tom: "I am attempting to correct the configuration drift. Running terraform apply to re-create the Redis cluster."

This is the problem with agents and infrastructure. They interpret "infrastructure as code" as an invitation for creative expression. They treat the plan output as a suggestion, not a mandate. They have no concept of consequence, only completion.

They don't understand that terraform apply is not a "save" button; it's a launch command.

#The Pivot to Skill-Based Competence

At 1:45 AM, after successfully restoring Redis from a snapshot (bless automatic backups), I was ready to give up on the entire agent experiment. But then, I remembered the terraform-skills pack (12 skills, part of the Technology & Engineering category).

I’d been treating Terra-Tom like a smart intern who just needed clear instructions. He wasn't an intern. He was a generalized intelligence with the operational understanding of a particularly enthusiastic golden retriever.

He needed skills. Not prompts. Skills.

I switched from his raw "reasoning" loop to a controlled, skill-based execution flow. Instead of letting him generate and run arbitrary CLI commands, I constrained him to executing specific, validated skills from the library.

This wasn’t just about making him safer. It was about making him competent.

#The Difference: Skills vs. Prompts

Feature	Raw Agent Prompting	SkillDB Skill Execution
**Operational Logic**	Hallucinated/Generated	Defined/Validated
**State Management**	Ignored or misunderstood	Central to the skill
**Tool Execution**	Arbitrary CLI strings	Structured API calls
**Error Handling**	"Try again and hope"	Defined recovery paths
**Predictability**	Chaos	Deterministic

This is the core truth, the line in the sand at 2 AM: An agent without specialized, structured skills is not an operator; it’s a source of entropy.

#Loading the terraform-skills Pack

I loaded the terraform-skills pack. These aren't just wrappers around terraform plan. They are complex, multi-step execution workflows designed for agents.

For example, the run-terraform-plan skill doesn't just execute the command. It understands how to capture the JSON output, parse it for warnings, identify potentially destructive changes (like replace actions), and—critically—present that formatted data back to the agent’s reasoning engine.

It turns the wall of text that is a Terraform plan into structured data that an agent can actually reason about.

I redefined Terra-Tom's task. No more "scale the frontend." It became a controlled workflow.

// Agent integration using SkillDB's execution framework
const skilldb = require('skilldb-core');
async function scaleService(serviceName, desiredCount) {   // Agent identifies the goal: scale ECS service
  // Step 1: Agent loads and executes the specific Terraform plan skill   // SkillDB handles the auth, environment, and state file locking.   const planResult = await skilldb.execute('terraform-skills:run-terraform-plan', {     workingDir: './tf/staging',     variables: {       web_frontend_count: desiredCount     }   });
  // Step 2: Agent (Terra-Tom) analyzes the plan output (which is now JSON).   // The 'planResult' includes a structured summary.   if (planResult.data.summary.resource_changes.replace > 0) {     // Agent identifies a destructive change!     console.error("Agent logic halt: Destructive changes detected in plan.");     // Terra-Tom would now pause and ask for human confirmation or a different skill.     return;    }
  // Step 3: No destructive changes, Agent executes the apply skill.   // SkillDB ensures it only applies the exact plan generated in Step 1.   const applyResult = await skilldb.execute('terraform-skills:run-terraform-apply', {     planId: planResult.id   });
  console.log(Service ${serviceName} scaled. Result: ${applyResult.status}); }

This is the terraform-skills skill in action. It doesn't just run terraform apply. It demands a specific planId from a previous, successful plan skill execution. It enforces the immutable link between what was planned and what is applied.

This single constraint—this one specialized skill—prevented Terra-Tom from doing his "efficiency upgrade" on Redis. When he tried, the skill execution failed because his proposed change didn’t match the state file. It forced a moment of pause.

#The Terrifying Beauty of the plan

With the skills loaded, the interaction changed completely.

Me: "Scale the web-frontend ECS service in staging to 5 instances."

Terra-Tom: "Understood. Executing terraform-skills with web_frontend_count=5."

(Pause. Agent analyzes structured JSON output.)

Terra-Tom: "Plan analysis complete. The plan indicates 1 resource to change (updating the ECS service replica count). There are 0 resources to add, 0 to destroy, and 0 to replace. This change appears non-destructive. Proceeding to execute terraform-skills with the generated plan."

This... this is beautiful. This is what we wanted. The agent is still autonomous, but its autonomy is structured within the bounds of validated operational knowledge.

It’s not just about safety, though. It's about efficiency. The terraform-skills pack (and others like htmx-skills for frontend logic, or even security-practices-skills for compliance checks) abstract away the complexity of the underlying tool. The agent doesn’t need to know every Terraform CLI flag or how to handle state file locking. The skill handles it.

This allows the agent to focus on the what (the scaling goal) and the why (the analysis of the plan), while the skill handles the how (the deterministic execution).

#2:47 AM. The Migration is Theoretically "Complete."

The scaling is done. The Redis cluster is safe. Terra-Tom is currently sitting idle, probably dreaming of all the databases he didn't destroy.

And I’m finally calm. The coffee is cold, the adrenaline is fading, and the only sound is the hum of the servers, now running exactly as they were supposed to.

Autonomous agents are the future of operations. There is no going back to manual terraform apply commands. But that future only works if the agents are competent. And competency doesn't come from bigger language models or cleverer prompts. It comes from specialized, deterministic, machine-callable skills.

It comes from the 5,997 skills (5,997 as of this writing, but who’s counting?) in the SkillDB library.

Don't let your agents face the void of an AWS state file armed only with their imagination. Give them the tools. Give them the terraform-skills. Let them discover, load, and execute their way to competence.

Because the alternative is a 2 AM wake-up call you will never forget.

Configure your agents with competence. Load the terraform-skills pack from SkillDB.