For more than a decade, Infrastructure-as-Code has been the backbone of modern cloud operations. It brought discipline to an environment that desperately needed it: versioning, repeatability, auditability, and a shared language for how infrastructure should exist. Engineers who lived through the ClickOps era still talk about IaC the way a grateful owner of a new home talks about plumbing that just works.
But every era of engineering eventually develops blind spots, and IaC is no exception. Somewhere along the way, we convinced ourselves that every change must pass through heavyweight workflows, complex pipelines, and elaborate reviews. We made this the case for seemingly everything, whether it was mission-critical production systems or a quick throwaway sandbox.
Along the way, we solved the chaos problem so well with IaC that we accidentally created a rigidity problem.
Now, that rigidity is met with a new reality: AI-driven, intent-based tooling that is giving teams a safe, governed way to move faster without writing infrastructure code first. The result is a transition that would have sounded unthinkable even two years ago:
Some organizations will skip IaC for entire classes of coding work, and they’ll be right in doing so.
This isn’t a rejection of IaC. It’s the recognition that the original promise of the cloud was speed and control. For the first time, we have the tooling to offer both without requiring engineers to become DSL experts before they can create value.
Below are some trends accelerating this shift, revealing a turning point not just for how we write infrastructure, but how we think about it.
1. The boundary between developers and platform engineers is dissolving.
The center of gravity is shifting from “write the code for the infrastructure” to “express the intent of the infrastructure.”
Over the past year, AI has quietly changed the relationships across engineering teams. Front-end developers can now ask for infrastructure using natural language; platform engineers can prototype application components without waiting for another team to translate requirements.
This doesn’t eliminate expertise, but it eliminates the penalty for not having it. AI becomes the translation layer that interprets intent and applies policy. It’s the difference between needing to speak a foreign language fluently and being able to communicate effectively through a world-class interpreter.
Because of this, the old “handoff” model (dev requests, platform interprets, dev waits) begins to collapse. The bottleneck was never infrastructure provisioning itself; it was the human coordination required to get the right infrastructure provisioned. Once the translation step is automated, velocity increases dramatically.
This rising capability reshapes expectations: if developers can safely ask for what they need and get it immediately, then the idea that every workflow must start with IaC becomes harder to justify.
2. IaC is becoming a durable store of truth, not the starting point for every workflow.
IaC is evolving from being the gateway to infrastructure to being the graduation path for anything meant to last. Temporary work begins with intent; durable work ends with code.
The prediction is not that IaC disappears. Far from it. It remains indispensable for production systems, long-lived environments, and compliance-heavy domains where determinism is paramount.
Teams are beginning to realize they don’t need the ceremony of IaC before they know what they’re building.
The vast majority of infrastructure created inside organizations is ephemeral: prototypes, staging environments, sandboxes, experiments, troubleshooting replicas. Historically, these environments either suffered from too much process (writing IaC for something that lives 48 hours) or too little process (console clicks that no one remembers six months later).
This is where intent-driven provisioning fills the deployment gap. Engineers express desired outcomes in natural language, the system interprets them through policy, and everything remains tracked, governed, and auditable, without hand-crafted IaC standing in the way.
3. “Trust” is emerging as the real innovation in infrastructure automation.
Trust is elevating from a vague sentiment to a measurable property of the system. Teams start to say, “I don’t trust the AI; I trust the architecture around it.”
The shift that enables teams to safely skip IaC is not the intelligence of the model, but the framework that constrains it. We are entering the era of “trust architectures” for infrastructure automation. These include:
- Running automation inside the customer’s cloud boundary (never through opaque external services)
- Enforcing policy first, natural language second
- Treating irreversible actions (like deletions) as mandatory human-in-the-loop events
- Maintaining a live, authoritative view of state and drift
- Auditing every action in human-readable form
When these controls are in place, intent-driven infrastructure doesn’t feel like gambling with production. It feels like having a disciplined junior engineer who never gets tired, never skips documentation, and never forgets to check policy before executing.
Skepticism around AI touching infrastructure is healthy and widespread. The fear isn’t philosophical; it’s operational. Infrastructure is one domain where a small mistake can have a very large blast radius.
And that’s what makes skipping IaC viable for the right workflows.
4. Guardrails are replacing gates as the primary governance model.
Teams are beginning to move more quickly because they are governed, not in spite of being governed.
For years, infrastructure governance relied on gating mechanisms: pull requests, approvals, pipeline checks, manual reviews. These gates protect production, but they also slow down experimentation and force all work into the same procedural bottleneck.
AI-driven infrastructure shifts governance from “stop signs” to “lane markers.” Instead of preventing engineers from acting until a specialist approves every change, systems begin enforcing policies continuously and automatically.
This transition is powerful because it changes the job of platform teams. Instead of being gatekeepers who manually vet infrastructure, they become curators who define the patterns, policies, and safe boundaries that everyone else can operate within. Governance becomes proactive rather than reactive.
And when guardrails are effective, the necessity of writing infrastructure code for short-lived work begins to feel… optional.
5. The false choice between ClickOps and IaC is finally disappearing.
For more than a decade, organizations have lived with an uncomfortable compromise: move fast with ClickOps and risk drift and shadow infrastructure, or move slow with rigorous IaC pipelines and maintain safety. These two extremes defined the perceived boundaries of what was possible.
Looking ahead, that binary collapses.
Intent-driven workflows bring speed, safety, policy enforcement, state tracking, and auditability into a single model thereby eliminating the unhealthy incentives that pushed developers toward untracked console work. The best way to eliminate ClickOps has always been to make the safer path easier, and now the tooling exists to do exactly that.
The result is a new middle ground, one where engineers no longer need to choose between velocity and governance.
This middle ground is what enables teams to skip IaC when IaC isn’t the right tool for the job.
6. Platform engineering is becoming more strategic and less transactional.
As the burden of infrastructure translation shifts to AI systems, platform teams finally get to focus on higher-order concerns.
This includes things like:
- Defining the infrastructure patterns that accelerate development
- Improving reliability and operability across environments
- Reducing cognitive load for developers
- Curating guardrails that scale across teams and clouds
- Understanding how teams actually use infrastructure and evolving the platform accordingly
Instead of spending their time writing every Terraform module or resolving every infrastructure request, platform engineers become the architects of a more predictable, more humane system.
This shift gives organizations something they’ve never really had before: a platform function that scales faster than headcount. And that is one of the quiet forces enabling the “skip IaC” movement, because when the platform itself delivers infrastructure safely from intent, fewer teams need to manage the mechanical details manually.
What’s not happening: the death of IaC
Despite the strength of these trends, I am confident that IaC will remain essential. It’s not going anywhere. It will continue to anchor production, compliance, and long-lived systems for the foreseeable future. But the shift underway is subtle and important:
- IaC becomes the output of a process, not the entry point.
- Developers spend less time writing it and more time building software.
- Platform teams focus on policy and patterns instead of code generation.
- Intent-driven workflows handle ephemeral and iterative work with speed and safety.
IaC is not on its death bed. We’re just no longer forcing it into places where it provides negative value. The organizations that benefit most from this transition will be those that recognize the difference between governance and process, between intent and implementation, and between trusting AI and trusting the system that constrains it.
The teams that succeed will be those who:
- Use IaC where rigor matters
- Use intent where speed matters
- Use policy everywhere
This is not an abandonment of discipline. It is an expansion of it.
And for the first time, we can finally say this without irony: moving fast and not breaking things might actually be possible.