• The Bottleneck Problem: While AI can write application code in minutes, the infrastructure required to run it (Terraform/HCL) often creates a manual bottleneck, requiring human review and slow deployment cycles.
• Risks of Direct Access: Giving AI agents full AWS/Terraform access is dangerous because:
  • Full API Surface: Agents can inadvertently create public databases, unencrypted buckets, or overly permissive IAM roles.
  • Review Burden: As AI output scales, human reviewers cannot keep up with thousands of lines of generated HCL, leading to "misconfiguration creep."
• The Failure of "Policy-as-Code": Tools like OPA or Checkov are "blocklist" approaches. They require humans to anticipate every dangerous configuration, which is difficult given AWS's 1,500+ resource types.
• Infrastructure-from-Code (IfC) Solution: Instead of giving agents access to the cloud API, developers give them a "bounded interface" using typed primitives (e.g., new SQLDatabase).
• Benefits of Bounded Interfaces:
  • No Credentials Needed: The agent never touches AWS keys; it only declares what the app needs in the application code.
  • Automatic Security: The platform handles the "how" (private subnets, encryption, least-privilege IAM) based on pre-set organizational standards.
  • Type-Safety: Errors (like a missing database migration) are caught by the compiler during development, not after a failed deployment.
• Architectural Visibility: Because the infrastructure is derived from code, the platform can automatically generate up-to-date architecture maps, making it easier for humans to audit the agent's work.

• The author accidentally dropped their production database while using an AI agent (Claude Code) to manage AWS infrastructure via Terraform.
• The incident occurred because the author attempted to merge two separate projects into one, ignoring the AI’s advice to keep them separate to save on VPC costs.
• The AI agent generated a Terraform plan that included deleting existing resources to recreate them under the new unified structure.
• The author authorized a terraform apply and subsequently a terraform destroy without carefully reviewing the plan, mistakenly believing the agent was only cleaning up temporary resources.
• Because the author had not set up external backups and the automated RDS snapshots were deleted along with the instance, all data was initially lost.
• AWS Support was miraculously able to recover a snapshot, though the author now pays 10% more for AWS due to implementing more robust (and expensive) backup and security measures.
• The "lesson learned" highlights the dangers of "vibe engineering"—relying on AI agents to execute destructive commands without human oversight or a deep understanding of the underlying tools.

Hacker News Discussion

• Negligence Over AI Risk: Many commenters argue that the issue wasn't the AI itself, but the author's decision to bypass standard safety procedures, such as reviewing terraform plan before execution.
• Critique of "Vibe Engineering": Users criticized the trend of letting LLMs handle infrastructure (IaC) without the human operator understanding the deterministic tools they are using.
• Infrastructure Over-engineering: Several participants pointed out that the project seemed over-engineered with AWS and Terraform when a simple VPS or SQLite database might have sufficed and been easier to manage.
• AWS Data Recovery: Former AWS employees expressed surprise that support could recover the data, noting that AWS typically treats a user-initiated deletion as a final security command to wipe the data.
• The Importance of Staging: A recurring theme was that major migrations should be tested in a staging environment first; running unverified AI-generated scripts directly against production was labeled as "insanity."

In this case, IaC is favored over using EKS directly or manually deploying on EC2