We survey infrastructure practitioners every year, because the gap between what teams believe about their IaC posture and what's actually true is almost always wider than anyone wants to admit.
In 2026, that gap didn't close. In most areas, it grew.
Here's what the data from The 2026 State of Infrastructure-as-Code Report actually says, and what it means for the teams building infrastructure in an agentic world.
AI is outpacing the automation it depends on
For cloud practitioners, AI adoption and interest is moving faster than the automation maturity underneath it.
Only 17% of teams believe they have reached the "Automated" or "Self-healing" stage of automation maturity. The other 83% are still gating workflows on human approvals, running scripts by hand, or making changes manually.
That maturity gap is in the foundation. Everything that follows (like AI without governance, drift without remediation, or IaC without rebuild confidence) sits on top of it. It’s a problem, and practitioners know it.
Governance isn't keeping up with what modern practitioners are already doing with agents
The headline number? As many as 46% of teams are now running AI in production or advanced pilots for infrastructure automation. Last year, 42% had no plans to use AI at all.
Things are shifting, and quickly.
AI adoption among cloud practitioners is up. The problem is what lies underneath it: a lack of trust. Only 34% of practitioners would trust AI agents to make autonomous production changes, even with guardrails. 43% cite the absence of guardrails as their #1 blocker to using AI for infrastructure.
Regardless of that reality, nearly half are running AI against infrastructure they wouldn't fully trust it to govern.
What would actually increase trust?
- Granular approval workflows and change gates (52%)
- Better observability into agent actions (48%)
- Audit trails (43%)
- Rollback capabilities (37%)
These are (and should be) table stakes in 2026. But most teams don't have them.
68% are running IaC through pipelines that weren’t built for it
General-purpose CI/CD (Think: GitHub Actions, GitLab CI, Jenkins) is where 68% of teams deploy IaC today. These tools are excellent at application delivery, but they are not infrastructure control planes. They won't surface drift, enforce policy mid-run, or stop a destructive agent action in progress.
The orchestration gap most practitioners recognize is a direct result of that trend.
According to the latest data, 90% of practitioners agree their IaC orchestration needs improvement. At scale, only 8% say they can manage IaC with no notable issues.
The top missing capabilities:
- Better observability into infrastructure changes (50%)
- Guardrails and approval workflows (39%)
- Drift detection and auto-remediation (38%)
This is exactly what Firefly was built to offer: a dedicated control plane that governs infrastructure the same way regardless of whether the change source is a human, a pipeline, or an AI agent.
Drift is already driving production incidents, and remediation isn't keeping up
35% of respondents tied configuration drift directly to multiple costly production incidents in the past year. For some, that even meant over an hour of downtime.
The source is predictable: 48% of teams make out-of-band production changes multiple times a week, like console changes, CLI commands, manual modifications that bypass IaC entirely. Every one is a potential drift event. When that’s multiplied across multi-cloud environments with dozens or hundreds of accounts, the exposure compounds fast.
Worryingly, the response from practitioners isn't matching the risk.
- 1 in 5 have no drift detection or remediation processes at all.
- Only 7% can remediate drift in under an hour via automation.
In an agentic environment, this is critical. AI agents introduce changes at machine speed. Drift remediation built for human-paced workflows doesn't scale to that. The incident window (the one from agent action to detection to remediation) is wide open for most teams.
(Hint: Firefly's drift detection is real-time and event-driven. When something changes outside IaC, it's caught immediately, with an auto-generated PR to close the gap. That's the baseline an agentic environment calls for.)
Rebuild confidence is what practitioners want most, but almost nobody has it
This is the finding that matters most for where the industry is headed:
Practitioners ranked infrastructure immutability and rebuild confidence as the #1 benefit of IaC in 2026. That’s the ability to lose a region, an account, an entire environment: and bring it back from code alone, within a defined RTO.
- Only 11% have a DR posture that's tested and validated.
- 30% have little to no RTO confidence.
- 29% don't test DR procedures at all.
- 17% have no formal DR plan.
These are teams who are using IaC. The code exists, and yet still, the confidence doesn't.
Imagine how bad it is for those whose clouds are largely not in code. They don’t even have the foundation they need for any degree of rebuild confidence, especially not if they’re assuming their business is backed up and covered just because their data is.
Because data protection is not the same as business resilience.
When organizations can't fully restore within RTO, it's rarely because backups are missing. It's usually because infrastructure can't be rebuilt completely, cleanly, or fast enough under pressure.
The root cause is codification debt. "Retrofitting existing ClickOps infrastructure into code" is the #1 IaC blocker in 2026. The infrastructure that accumulated before anyone had a real codification strategy? It’s still there, unrepresented in the codebase, invisible to any IaC-based recovery process.
And you can't rebuild from IaC if your infrastructure isn't in IaC.
What this means for the state of IaC in 2026 and beyond
The data this year’s research unveiled tells a consistent story. AI adoption has outpaced governance. Drift incidents are up; remediation velocity is down. Rebuild confidence is the most desired IaC outcome; tested recovery capability is rare.
The teams that will operate well in an agentic world aren't the ones moving fastest. They're the ones that built the control plane first: full codification coverage, real-time drift detection, automated recovery that's been validated before it's needed.
That's what we build at Firefly. And based on this data, the teams that haven't started building it yet are running out of time to do it on their own terms.
