Most IaC Programs Fail at the Same Step: Execution

A recent research note from Gartner lays out a maturity-based roadmap for Infrastructure as Code that many platform and infrastructure teams will immediately recognize. IaC adoption is no longer the hard part. The real challenge is advancing it in a way that actually supports DevOps, SRE, and platform engineering at scale.

One of the strongest points Gartner makes is that IaC maturity is not a tooling decision. It is an evolutionary process shaped by organizational structure, team boundaries, and the ability to move from manual intervention to repeatable, composable, and eventually autonomous systems. That framing is important because it pushes teams to stop chasing hype and start evaluating whether their infrastructure practices are actually delivering business outcomes.

Where this gets interesting is what happens in the middle of that journey.

Gartner Is Right About Where Teams Get Stuck

Gartner’s maturity model makes it clear that many organizations plateau after they have adopted declarative IaC and modularized their infrastructure. On paper, they are doing the right things. Infrastructure is defined in code. State is tracked. Pipelines exist. Policies are enforced.

Yet maturity stalls.

Gartner points out that advancing further requires more than better definitions or more advanced abstractions. It requires changes in how teams collaborate, how enforcement happens, and how automation replaces manual intervention over time. Infrastructure begins to mirror the organization itself, and any friction in execution shows up immediately as risk, backlog, or inconsistency.

This aligns closely with what we see in practice. Most teams are not failing because they chose the wrong IaC tool. They are failing because execution still depends on humans closing the loop.

Detection and Definition Are Not the Same as Maturity

One of the implicit tensions in Gartner’s framework is the gap between defining desired state and ensuring that state is continuously enforced. Teams get very good at describing infrastructure and very good at detecting when reality diverges from that description.

What they struggle with is what comes next.

Findings become alerts. Alerts become tickets. Tickets depend on prioritization and availability. Over time, remediation slows down, even as detection improves. The system becomes better at telling you what is wrong and worse at actually fixing it.

Gartner emphasizes that higher levels of maturity require infrastructure to become self-correcting and resilient to drift. That is not achievable if remediation is optional or best effort. As long as fixes rely on backlogs and follow ups, maturity will always have a ceiling.

Where Our Point of View Goes Further

Gartner frames IaC maturity as an evolutionary journey, and that is a fair and useful way to look at it. Where our point of view goes further is on what actually enables teams to move from one stage to the next.

In our experience, the critical transition is not from imperative to declarative code, or from scripts to modules. It is from advisory systems to executable ones.

This is where the idea of AI Code Security Assistants, or ACSA,represents the next step in AI coding assistants. Instead of probabilistic suggestions that still depend on statistical approximations and human judgment, ACSA applies deterministic AI to provide contextual fixes the same way every time. It moves AI assistance from helping engineers write code to helping systems enforce outcomes, which is what IaC maturity ultimately requires.

As long as security and compliance tools stop at findings, maturity stalls. The organization may have composable infrastructure, but enforcement still happens out of band. The system knows what needs to change, but it cannot make the change itself.

Why Execution Changes the Shape of Maturity

When remediation is delivered directly in code, several of the challenges Gartner highlights start to resolve themselves.

Team boundaries matter less because fixes move through shared workflows. Human factors matter less because consistency replaces judgment calls. Drift becomes manageable because the system actively corrects it rather than just reporting on it.

This is the practical role ACSA plays in the IaC maturity conversation. It closes the loop between assessment and remediation, ensuring that the intent expressed in Infrastructure as Code is actually enforced continuously, without relying on manual intervention.

ACSA is not a shortcut to transformational maturity, and it does not replace IaC. It operationalizes and accelerates it.

Maturity Shows Up in Outcomes, Not Diagrams

One of the most useful takeaways from Gartner’s research is the reminder that maturity is not something you declare. It is something you observe.

You see it when misconfigurations are fixed as quickly as they are found. You see it when backlogs shrink instead of growing. You see it when engineers spend their time reviewing code rather than chasing tickets. You see it when infrastructure behaves predictably even as the organization changes.

IaC maturity is not about writing better infrastructure code. It is about building systems where fixes ship reliably and consistently as part of normal engineering work.

Gartner is right that maturity is an evolutionary journey. ACSA becomes relevant at the point where that journey stops being theoretical and starts being enforced in code. Until execution is built into the system itself, most IaC programs will continue to do more work without seeing better results.