Escaping the
IaC Abyss
AI is notoriously terrible at Infrastructure as Code. Here's how we forced it to be competent, cutting redeploys by 60%.
It started with a little experiment. I was watching my terminal vomit red text for the third hour straight—something about a "circular dependency" that definitely didn't exist—when I decided to let the Pulumi AI bot take the wheel.
I expected it to fail. I wanted it to fail, just so I could feel superior to the machine. Instead, it did something terrifying: it analyzed the state file, identified a zombie lock, wrote a fix, opened a Pull Request, and then—I kid you not—ran the apply command itself.
It worked. First try. I sat there in silence, half-impressed, half-offended. If a specialized bot could navigate the minefield of state management better than me at 11 PM, what happens if we give that same specialized context to our primary AI agents?
That's when we decided to dig deeper with the improved Anticursor skills. Because let's be honest: most generic AI acts like a confident junior dev who deletes the production database because "it looked cluttered."
Why "Generic" AI Fails at IaC

Figure 1: The "circle of life" for DevOps engineers using standard LLMs. Note the "Scream at Cloud" phase.
1. The Versioning Puzzle
Cloud providers change APIs faster than LLMs retrain. An AI trained on 2024 data will generate `acl="private"` for S3 buckets, unaware that AWS deprecated ACLs. The result? Immediate deployment failure.
2. State Drift Blindness
LLMs treat code as the source of truth. But in IaC, the *real* source of truth is the live cloud state. Generic AI suggests "just delete the resource" code blocks, oblivious to the production database attached to it.
3. Permission Hell
To avoid errors, AI defaults to `*:*` permissions. It's easier to give AdminAccess than to figure out the exact `kms:Decrypt` action needed. This creates a security nightmare masked as "working code."
4. Secret Leakage
"Here, put your API key in this variable." No. Stop. The AI doesn't understand KMS, Vault, or Pulumi ESC unless explicitly forced to respecting secret providers.
The Experiment: 60% Fewer Redeploys
We reverse-engineered that "Dashboard AI" competence into a reusable SKILL.md for Google Antigravity. Then we ran a controlled test with 4 groups of entry-level devops engineers (because let's be real, seniors don't have time for this).
- Groups 1 & 2Standard Cursor Rules. Immediate chaos. Struggles with state locks and circular dependencies.
- Group 3Armed with the Antigravity Pulumi Skill. Detected drift autonomously.
- Group 4Control group (No AI). Pure manual suffering.
The result? Group 3 spent 60% less time waiting for `pulumi up` to fail.
The "Intern Study"
Average redeploys required to fix a drifting Pulumi stack.
The Pulumi Mastery Skill
This isn't just a prompt. It's a procedural standard for managing Python-based Pulumi architecture. It handles programmatic drift detection (`stack.refresh()`), enforces KMS usage, and validates provider versions.
So, if you're tired of debugging state files at midnight, grab this skill. Or don't. You can always go back to Terraform, enjoy the HCL, and pretend that the terraform.tfstate file isn't plotting your demise. Personally? I'm letting the robot handle the resource graph. The last time I tried, I accidentally deleted the staging environment thinking it was a "test bucket."
(The robot hasn't made that mistake. Yet.)