Marcin Wyszynski: I built Spacelift because I was tired of watching teams struggle with infrastructure collaboration. As a consultant helping customers migrate to the cloud, I kept seeing the same problem repeatedly. Terraform itself was powerful for one person, but it created chaos for teams. Terraform Enterprise from HashiCorp was available, but it didn’t solve my problems.

I built what I wished existed—infrastructure as code designed to be multiplayer, not just shared state files for remote execution, but real collaboration. We created a layer that controls who changes what, when, why, and with what policies and audit trails. We made infrastructure a team sport. When HashiCorp pulled their Business Source License (BSL) move on Terraform, we helped launch OpenTofu with other industry players. Today, we’re by far the largest sponsor of that project.

What Is Spacelift Intent and How Does It Relate to Infrastructure as Code?

SB: You’re calling Intent “codeless infrastructure provisioning.” What is Intent, and how does it relate to Infrastructure as Code? Does it replace or complement it?

MW: Intent is not meant to replace infrastructure as code—it’s designed to fill the massive gap between console clicking and full Terraform ceremony. There’s a proverb: when all you have is a hammer, everything looks like a nail. For many DevOps people, Terraform was the only hammer available, and everything looked like a nail. The only alternative was unacceptable console clicking.

Think about the typical infrastructure as code flow. You need a database. First, you learn HCL syntax. Then you research provider documentation to express that database the way Terraform expects—maybe 50 lines of configuration. You handle dependencies, set up a backend, configure CI/CD, create a pull request, wait for review, run a plan, get approval, then apply. That’s hours at minimum, maybe days if you’re starting from scratch.

Meanwhile, your colleague clicks three buttons in the AWS console and has a database in 30 seconds. Sure, it’s not repeatable or governed, but they’re shipping features while you’re debugging Terraform.

Intent sits in the middle. You say, “I need a Postgres database for my staging environment.” Intent translates that directly to provider OpenTofu provider API calls. It’s not generating Terraform code—it’s actually calling the AWS APIs mediated by the provider. You get the same governance, audit trail, and policy engine as your Terraform stacks in Spacelift, but without the ceremony.

When would you use Intent? If you’re doing production networking, write proper Terraform. But if you’re quickly experimenting on something that might not become real, use Intent. Complex multi-region deployment? Use Terraform. Need an S3 bucket for experiments? Use Intent.

The beauty is they coexist. Intent-provisioned resources can be imported into Terraform later, or they might not be. It’s about having the right tool for the right moment. Infrastructure as code solved ClickOps chaos, and Intent solves IaC ceremony.

How Does Intent Maintain Security and Compliance Guardrails?

SB: Many DevOps teams worry that AI-driven provisioning could compromise control, security, or compliance visibility. How does Intent maintain those guardrails while delivering automation?

MW: We’re launching two versions simultaneously. One is a public open source repository on GitHub available today. The other is an early access commercial version that’s a Spacelift-mediated experience.

The open source experience is essentially an MCP server giving you access to local Terraform providers—a single player mode that works similar to Terraform. You express intent locally inside your LLM, and everything stays on your machine.

With the Spacelift version, the same MCP server becomes a remote MCP server with powerful middleware—the same Spacelift experience as our traditional IaC offering. You get policies, audit trails, access control, and all the things you’re used to with Terraform.

You can express a policy in Open Policy Agent the same way you would for a Terraform stack in Spacelift to prevent shooting yourself in the foot. The only difference is that rather than being project-level, policies are resource-level. They can reject a resource update, approve it, or flag it for manual review—you get the equivalent of a Terraform plan but expressed as Intent, with the whole view inside a nice GUI.

There’s a real difference between single player mode, which is very much like Terraform, and multiplayer mode where governance and security guardrails are exactly the same as traditional Terraform.

What Workloads Should Teams Start Testing Intent With?

SB: You’re launching an open source release and a commercial early access offering. What kind of workloads should teams start with when testing Intent—critical or non-critical? What feedback are you looking for before it’s production ready?

MW: We’re envisioning two main use cases for commercial Intent. First is quick experimentation. If you’re building infrastructure for a project that’s not production usage—just messing around, trying to connect dots to understand how things could be wired—and you’re being slowed down by traditional IaC approaches, then being able to vibe code your infrastructure sounds perfect. You’re probably vibe coding your feature in the first place, so why wouldn’t you vibe code the underlying infrastructure?

The other interesting use case is what’s known as unmanaged drift—things in your AWS or Azure account that were provisioned using ClickOps or various shell scripts, but you forgot about them. This is a big topic in cloud security and cloud management because it’s shadow IT.

Intent really shines here because it can detect those using Terraform data sources. You can query for all unused or unmanaged resources, then bring them into Intent management—soft-managed using Intent. When you feel like you want the full ceremony, you can export them into full Terraform management. That’s the second very compelling use case.

What Does the Intent Workflow Look Like in Practice?

SB: Walk us through what the workflow looks like in practice. Are engineers prompting the system, reviewing generated plans, then approving changes? How much human oversight stays in the loop?

MW: If you’ve worked with a coding assistant like Claude or any desktop version, you’ll recall there are different ways of running MCP tools. You can put an MCP tool into always-on mode, or you can ask for each individual call to be reviewed separately. When reviewing separately, you see the input that’s going to be passed into each particular call.

With open source Intent, your guardrail becomes the ability to review what the tool is doing at each MCP call. Intent is an MCP server intercepting your requests, and you can control what flows into it.

With commercial Intent, you have two points of control. One is obviously that, but the other is a central server that enforces your organizational guardrails. Even if you go full YOLO mode—which I’m not endorsing—the policies on the central server will say, “I’m sorry, you can’t do this. You need to try again.”

The amount of human oversight depends on your particular task and risk profile. You’ll have different risk profiles working on production infrastructure versus one-off resources for a quick throwaway prototype versus pre-prod infrastructure. Single player versus multiplayer mode offers different ways of working and different risk profiles.

How Does Intent Ensure Plans Are Explainable and Not Black Boxes?

SB: Spacelift has always focused on policy-driven automation. How do you ensure the plans Intent generates are explainable and reproducible, not just black boxes?

MW: Intent isn’t doing anything magical here. It’s translating natural language into a state of Terraform resources. When you make a request to an Intent server, there’s back and forth—first we query for the schema of a resource you want to provision, then before provisioning, we show you the desired state of that resource.

You’re seeing the exact same thing as in a Terraform plan, expressed exactly the same way. You’re just seeing it without the whole Terraform scaffolding—just as a JSON thing. Then you can have AI or your LLM explain what you’re seeing, but we’re not hiding anything. It’s very open and transparent.

It’s the same for deletes and updates. Intent is just a translator of human language, LLM tool calls, and provider API calls. Nothing hidden there, very similar and fully compatible with Terraform and OpenTofu.

How Will AI Reshape the Future of DevOps and Platform Engineering?

SB: With Intent and natural language provisioning now emerging, how do you see AI reshaping the future of DevOps and platform engineering?

MW: We can’t predict the future, but we can extrapolate trends. We’ve been seeing a move slightly away from DevOps toward what people call platform engineering. DevOps is developers doing operations, while platform engineers want to ensure operations aren’t even there—they want to democratize access and remove the need for as much operations as possible.

From that point of view, Intent accelerates what platform engineering is after: self-service. Today when you talk about Terraform self-service, the definition is frequently “here’s that Terraform module with 47 different inputs—go figure.” But with Intent, a data scientist can say, “I need a GPU cluster for model training,” and they just get their cluster. They don’t need a module or inputs. They express the need, might have to elaborate if it can’t be translated directly, but essentially it’s a conversation rather than going back and forth between documentation, the module, and the DevOps team.

This kills the ticket queue. The DevOps team is no longer a bottleneck. Ticket queuing isn’t engineering—it’s human middleware. Intent takes over, allowing AI to handle that middleware of human intent into actual resource mapping. It’s really good at it and allows people to focus on real engineering and planning rather than being guardians of Terraform expertise.

DevOps as “developers doing ops” is disappearing because it’s becoming less relevant if there are fewer ops. It’s not a complete revamp of how people do things—it’s a force multiplier and one of the tools allowing this move toward democratization of infrastructure and removing yourself as a human bottleneck from infrastructure-related tasks.

What Edge Does Intent Have Over Other AI Infrastructure Tools?

SB: Are there other early experiments in AI-driven infrastructure provisioning, and what edge does Intent have over them, given your deep involvement with OpenTofu?

MW: That’s an excellent question because it touches the core of what Intent is. If you looked at how people used AI in infrastructure, especially in the Terraform space before, it was to generate HCL code. I’m not saying it’s bad—we all love coding assistants, and I’m not giving my Claude away. Writing code is something they’re very good at.

It’s just not clear whether you’re solving any real problem with AI or just building a faster hammer. If Terraform is a hammer and everything looks like a nail, then writing Terraform using AI is making a faster hammer. You can move faster, but you’re still solving the same problem the same way. There’s still ceremony involved.

With Intent, we’re turning the problem on its head. We’re not using Terraform at all—we’re using Terraform providers and using AI as a translation layer between your intent and directly the provider. We’re short-circuiting Terraform.

Think about the long electrical circuit of how you build infrastructure at scale—from your intent through HCL, through the provider, backend, all those steps. We’re short-circuiting and jump-starting the whole thing. That’s what AI makes possible. Previously it wasn’t possible because humans weren’t very good at writing provider calls directly, but AI is pretty good at it.

Instead of using AI to write code that’s then understood by a machine, we’re saying, “Just make machine calls directly—short circuit and jump start.” Very different approach from what we’ve seen in the past.

Will “Infrastructure by Intent” Become Its Own Category?

SB: Do you think this will eventually become its own category, something like “infrastructure by intent,” or will we fall back into traditional IaC tools over time?

MW: I think there’s a massive need for something between ClickOps and infrastructure as code, and this category will exist however it’s implemented. Our take so far is the best I’ve seen, and it’ll get better over time. We open sourced it and will let people play around with it, give us feedback, and help us make it exactly what they want.

But honestly, playing around with it and having a few goes at building infrastructure with it—I don’t want to go back. It feels like finally my infrastructure behaves the same way as my code. I can vibe code my application, and suddenly I can give access to Intent to my coding assistant, and it provisions infrastructure at the same time. And it’s not toy infrastructure—it’s real infrastructure.

I believe the category is with us to stay, and our entry into the category is the strongest I’ve seen so far.

What’s the Relationship Between Open Source and Commercial Versions?

SB: What kind of synergy do you see between the open source and commercial versions, and will Intent stay as a Spacelift project or eventually align under something like OpenTofu?

MW: This will remain a Spacelift open source project. We’re a member of the OpenTofu organization, but this is not an OpenTofu project. We’re piggybacking on the OpenTofu ecosystem—that’s what makes it possible in the first place. This will, for the foreseeable future, be a Spacelift open source project. If at some point it makes sense for a foundation to adopt and standardize it, sure, why not?

The symbiotic relationship is interesting. There’s single player mode and multiplayer mode. Open source projects are generally very good at being single player, but whenever multiplayer comes in, you need a central server, governance, SLAs, someone on pager rotation. You need regular bug fixes, update cadences, edge cases, corporate governance—that’s where commercial products really shine.

It’s not the core features that shine—it’s what’s built on top of those core features. What makes it possible to work as a large team, what makes it possible to work in a sophisticated, technologically advanced, and secure organization. That’s what I believe is worth paying money for, not the core feature.

What Feedback Are You Hoping For and When Will It Be Production Ready?

SB: What kind of feedback or contributions are you hoping to see from the community? Do you have a timeframe for when early access will be fully ready for production?

MW: We’re hoping to share it with humanity for Christmas this year. We’re aiming for GA before Christmas.

In terms of feedback for Intent open source, we’re mainly looking for people playing with it and telling us what it’s good at. As testers, we’ve spent countless hours testing it with different AI providers and workloads, but we’re just a small sample. We’re giving it for free as open source to the community to tell us what they want to do with it.

I believe, as with every project, that the best ideas don’t come from within—they come from without. Projects are used in ways you haven’t imagined before. Releasing as open source opens up the possibility for people to come up with new, very creative ideas for using this technology.

A good analog is when OpenAI released ChatGPT—they had no idea how people would use it. Then people said, “I think you should be able to control my computer.” And they were like, “Oh my God, how do you go about that?” Then came tool calls, then the whole MCP ecosystem starting.

As an author of technology, you need to be humble and optimize for serendipity, allowing people to discover ways they find the technology working best for them.

Final Thoughts

SB: Marcin, thank you so much for your time today. Infrastructure as code transformed how we manage the cloud, but now with tools like Intent, we could transform how we create it. Thank you for walking us through what’s next for Spacelift and AI-driven provisioning.

MW: Thanks for having us.

Watch the full video interview on TFiR to see Marcin Wyszynski discuss how Spacelift Intent is bridging the gap between console clicking and infrastructure as code ceremony, bringing natural language provisioning to cloud infrastructure management.