The demo that turned heads at KubeCon this year wasn’t a new container orchestrator or a service mesh — it was Spacelift Intent translating a plain English sentence directly into cloud provider API calls. No HCL. No Terraform plan. No generated intermediate code. You describe what you want:
“Create an S3 bucket with versioning enabled, encrypted with a KMS key, and a lifecycle policy that moves objects to Glacier after 90 days.”
And the system provisions it directly through the AWS API. It runs as an MCP (Model Context Protocol) server that plugs into AI coding assistants — Cursor, Claude Code, Windsurf — while enforcing the same policy guardrails and audit trails as traditional Infrastructure-as-Code pipelines.
Let me explain why this is conceptually significant before I tear into the practical problems.
The Promise: Skipping the Code Layer
Infrastructure-as-Code was a revolution because it replaced clicking through the AWS console with version-controlled, reviewable, repeatable configurations. Terraform and CloudFormation gave us reproducibility and auditability. But IaC has its own substantial problems that we’ve collectively normalized:
- HCL is a domain-specific language that takes months to learn. It’s not programming, it’s not configuration, it’s something in between — and it has its own weird quirks (count vs. for_each, anyone?).
- Terraform state management is error-prone. State file locking, state drift, importing existing resources, moving resources between state files — these are entire categories of infrastructure incidents.
- The gap between “what I want” and “how to express it in HCL” is significant. You want a VPC with public and private subnets across 3 AZs. The mental model is simple. The Terraform code is 200+ lines of resource blocks, data sources, and variable references.
Infrastructure-as-Intent skips the code layer entirely. You express intent, and the system figures out the implementation. This is the same conceptual leap that SQL made over procedural data access — you declare what you want, not how to get it.
My Honest Evaluation After Three Weeks of Testing
The happy path demos are genuinely impressive. I tested common infrastructure patterns — VPCs, Application Load Balancers, RDS instances, S3 buckets with various configurations, ECS services, CloudFront distributions — and they provisioned correctly from natural language descriptions about 85% of the time. For standardized patterns, this works.
But edge cases are where it falls apart, and infrastructure is mostly edge cases in production:
1. Complex networking configurations require precision that natural language doesn’t convey well. When I said “create a VPC with three private subnets using 10.0.0.0/16,” it created the subnets — but it chose its own CIDR blocks for each subnet. My team has a specific CIDR allocation scheme that maps to our network topology documentation. Natural language can express this, but it becomes so verbose and detailed that you’ve essentially written a specification document, not a casual description. At that point, you might as well write the Terraform.
2. Drift detection and state management remain unsolved. If someone modifies the infrastructure manually — and they will, during incidents — how does the intent system know? Terraform tracks state explicitly through its state file. Intent-based systems need a fundamentally different reconciliation model. Spacelift’s approach is to scan existing infrastructure and compare it against the “intent history,” but this is fuzzy matching at best. Terraform’s state comparison is deterministic; intent-based reconciliation is probabilistic.
3. Debugging failures is significantly harder. When a Terraform plan fails, I can read the HCL, understand the dependency graph, and identify the issue. When an intent-based provisioning fails, the error exists in the gap between my description and the system’s interpretation — a much harder debugging surface. I described a Lambda function with a VPC configuration, and it created the function but put it in the wrong subnets. The “why” required understanding the AI’s interpretation of “the private subnets,” which isn’t inspectable the way a Terraform resource reference is.
The Governance Question
Intent-based provisioning actually has potential security advantages. The system can enforce policies at the intent level — “no public S3 buckets ever,” “all databases must have encryption at rest” — rather than at the code level, where you’re scanning for specific HCL patterns that might be expressed differently across modules. Policy enforcement against intent is conceptually cleaner than policy enforcement against implementation.
But it introduces a new trust boundary. You’re trusting the AI to interpret your intent correctly and not provision something you didn’t ask for. In traditional IaC, you review the plan before applying — terraform plan shows you exactly what will be created, modified, or destroyed. In intent-based provisioning, the “plan” is the AI’s internal interpretation, which is opaque. Spacelift shows a preview of the API calls it intends to make, which helps, but it’s not the same as reading a Terraform plan that maps directly to your code.
Who This Is Actually For
Quick prototyping and development environments? Absolutely. Standardized infrastructure patterns where the intent is clear and the implementation is well-understood? Yes. Spinning up a demo environment with standard components? Perfect use case.
For production infrastructure with complex requirements, regulatory constraints, and precise networking needs? Traditional IaC is still safer. The determinism and auditability of Terraform outweigh the convenience of natural language for high-stakes infrastructure.
The question I keep coming back to: would you trust natural language to provision your production infrastructure, or does IaC fundamentally need the code layer for safety?