Why so many teams are frustrated with IaC

Widespread dissatisfaction with IaC implementations

Infrastructure as Code, IaC, was supposed to be a game-changer. Automate the infrastructure, define everything in human-readable files, treat infrastructure like application code, and let DevOps run with it. That was the promise. But based on the numbers, we’re far from fulfilling it.

Almost every company using IaC reports issues. A 2024 survey by Dimension Research, commissioned by StackGen, shows 97% of respondents say they’ve faced serious challenges with their IaC deployments. Even more telling, 87% say their organization hasn’t reached maturity in implementing it. These aren’t small missteps. They’re signs of a systemic disconnect between the IaC philosophy and its execution in everyday business environments.

For executive teams, here’s the bottom line: the tools may be modern, but the processes and structures around them aren’t keeping up. If nearly every organization is struggling, the issue isn’t team capability, it’s structural compatibility. IaC needs maturity in practice, not just in documentation. It needs buy-in across technical and leadership layers. Without that, we’re just writing YAML files and hoping things work.

This isn’t about abandoning IaC, far from it. It’s about being honest with where it’s failing and figuring out how to move faster, with fewer blockers. C-suite teams should be pushing for frameworks that close the gap between intent and execution. Having automation doesn’t mean you’ve streamlined, especially when that automation slows teams down due to design flaws and lack of alignment.

Limited flexibility and agility in dynamic cloud settings

Here’s where things start to fall apart. IaC thrives in structured environments. It does well when workflows are predictable and don’t change much. But real-world cloud environments are the opposite, messy, fast, dynamic. And that’s where traditional IaC starts slowing you down.

Developers often need to make quick infrastructure changes. Say a server needs more capacity right now. With IaC, someone has to take out a Terraform file from source control, make changes, test, commit, push, and only then will the change reflect. That process is too slow for operations that live under real-time pressure.

Joey D’Antoni, Principal Cloud Architect at DesignMind, shared a typical example. A client needed to resize an infrastructure resource under load. You’d think that’s easy, but no. It required manual edits in Infrastructure code, going through change management and version control. That delay could’ve been avoided by just clicking into the cloud provider’s console, but that breaks the philosophy of enforcing everything through code.

Arvind Rongala, CEO at Edstellar, put it well: IaC works great when your environment is stable. But when speed matters, and it often does in cloud environments, it holds you back.

Now imagine this friction multiplied across dozens of teams, each managing fast-changing assets. It creates a slow-moving system in a world that demands acceleration. For executive leaders, the point is simple: don’t treat IaC as a one-size-fits-all solution. It’s great in stable contexts, but alone, it’s not built for real-time agility.

If your teams are forced to choose between operational speed and process compliance, something’s broken, and it’s not the team. Fixing that starts at the system level, not at the individual. Redesign the workflow to support velocity without tossing out structure. That’s where the next evolution lives.

Workarounds undermine consistency and security

Speed is great, necessary, even. But speed without structure creates risk. That’s what’s happening when developers bypass IaC standards to get things done faster. They’re pulling templates from places like Stack Overflow or relying on unsupported AI tools to deploy infrastructure. The intent is to move quickly. The result is fragmented systems with unclear ownership, inconsistent templates, and security loopholes.

Asif Awan, Cofounder and CPO at StackGen, highlights this problem well: developers want flexibility, but they’re not always equipped with deep infrastructure knowledge. That gap leads to shortcuts, unsupported scripts, homegrown templates, and AI-generated configuration code that no one thoroughly understands or reviews. Over time, this creates a drift between what’s in the source of truth and what’s actually running in production.

From an executive standpoint, this isn’t just a technical issue. It’s an operational risk. When teams operate outside shared standards, you’re no longer scaling a unified infrastructure. You’re scaling chaos. Minor misconfigurations compound, audits become painful, and incident response slows down.

Standardization doesn’t need to mean rigidity, but it must be enforced with the right balance of control and flexibility. That means giving developers tools that enable speed with guardrails, not forcing them into brittle workflows they feel compelled to avoid. If teams have to work around IaC to stay productive, the strategy behind IaC needs a reset. The fix isn’t cracking down harder, it’s building something that actually supports how modern teams operate.

Cross-domain challenges create inefficiencies and frustration

IaC assumes people are fluent across domains, development, network configuration, security policies. That works at a few companies, ones with highly specialized staff who’ve trained across verticals. But most organizations split these responsibilities across multiple teams. Putting IaC in place without accounting for that split creates unnecessary friction and forces people into scopes they weren’t hired to manage.

With IaC, developers are configuring firewalls. Security teams are reviewing YAML. Operations are debugging code they didn’t write. This leads to mistakes, duplication, and frustration. According to the 2024 Dimension Research survey, 75% of infrastructure professionals are frustrated when other teams make changes to configurations. Developers, meanwhile, report spending over 20% of their time managing infrastructure, time they’d rather use to focus on product and features.

Joey D’Antoni said it clearly: asking non-developers to adopt full software development practices, or developers to manage deep infrastructure questions, is a stretch for most companies. There’s a gap between responsibilities and expertise. Ignoring that leads to inefficiency and burnout.

Executives should take this seriously. IaC was supposed to bridge teams, not blur lines to the point of confusion. When too many teams share ownership without defined scope, no one’s truly accountable. That’s where errors slip in and momentum fades.

The solution isn’t artificial clarity, it’s designing IaC systems with roles and capabilities in mind. Let developers engage at the application layer. Let ops and security teams build the underlying structure with appropriate tooling and oversight. Treat cross-functional access as a capability, not a default requirement. Empower people where they’re strongest, and the system performs better overall.

External dependencies and vendor instability complicate IaC

IaC’s effectiveness depends on reliable tooling that keeps pace with evolving cloud platforms. The problem is, many of the third-party tools companies depend on, particularly the major ones, are getting harder to trust. Shifts in licensing, philosophical disagreements, and M&A activity create friction across engineering teams and among leadership. The adoption of a tool that seemed stable a year ago may now carry risk.

Take Terraform, for example. For years, it was the dominant tooling choice in the IaC world. Initially open source, widely adopted, and well-documented. But after HashiCorp changed its licensing model, community trust took a hit. That shift, combined with its ongoing merger with IBM, has introduced strategic uncertainty for teams deeply invested in the ecosystem. Businesses are right to be cautious with vendor strategies that move targets midstream.

In response, many organizations are diversifying. According to Dimension Research’s 2024 report, 54% of surveyed companies are now using multiple IaC tools. It’s a defensive move, more tools, more options, more resilience. But it’s also more complexity, which means more to manage and more risk of integration failure.

For executive teams, the takeaway is this: even when your IaC philosophy is well-defined, the tooling underneath it may not hold steady. Vendor lock-in, unpredictable roadmaps, and fractured open-source models put your infrastructure stability outside your control. Leaders need long-term agility, not just tool familiarity. That may also mean prioritizing platform-agnostic tooling, clear migration strategies, and contracts that support predictability over flash.

Stability isn’t just about uptime, it’s about continuity across years of growth and change. That requires building a strategy around vendor management, not just relying on open-source enthusiasm or brand recognition.

Generative AI enhances workflows but doesn’t resolve core IaC issues

AI is starting to fill in some IaC gaps, but it’s not replacing the need for real infrastructure expertise. Tools like GitHub Copilot and custom AI-based assistants can generate Terraform files, flag configuration errors, and even suggest secure defaults. They save time and make IaC more approachable, especially for teams without deep experience. That matters. Productivity solutions that reduce barriers deserve space in the stack.

Arvind Rongala, CEO at Edstellar, explained how teams are embedding AI into their platforms, not just as coding assistants, but as policy-enforcement tools. Based on previous successful deployments, AI-enhanced interfaces can identify risks like misconfigured permissions or conflicting resources before deployment. That’s valuable, and it helps ensure compliance without constant manual review.

Still, AI tools don’t remove the need for sound engineering decisions. Asif Awan, Cofounder and CPO at StackGen, pointed out that generative AI can’t evaluate whether the code it generates is contextually valid. If a developer doesn’t deeply understand the infrastructure domain, especially networking, security, or cloud orchestration, they won’t catch subtle flaws in what AI generates. The result? More review cycles, more dependency on operations, and another ticket in someone’s backlog.

D’Antoni raised a further caution: even successful automation needs guardrails. Offloading infrastructure logic to AI doesn’t absolve teams from the need to test, review, and verify. That work still has to get done, just by fewer people, perhaps at greater risk of centralizing key knowledge.

For business leaders, the opportunity is clear. Use AI to boost speed and scalability, but don’t confuse speed with safety. The bigger win isn’t in replacing teams, it’s in making infrastructure more usable across functions, without creating new points of failure. AI supports delivery when paired with the right accountability structure. Without that, it only speeds up potential missteps.

Emerging approaches aim to augment or supplant traditional IaC

New thinking is entering the infrastructure management space, and that’s a good thing. The friction and inefficiencies exposed by current IaC implementations are prompting the development of smarter, more adaptable solutions. These aren’t just marginal upgrades. They rethink how infrastructure is expressed, managed, and handed off between teams without requiring everyone to become a configuration expert.

System Initiative, led by cofounder Adam Jacob, former CTO of Chef, offers a visual-first approach that removes the need to write infrastructure code by default. Teams see what they’re building and make changes directly through a UI built for collaboration. It’s fast, transparent, and removes unnecessary complexity without removing control. The goal isn’t to eliminate IaC but to make it usable at scale by the people who need it, whether or not they write infrastructure code daily.

StackGen, cofounded by Asif Awan, takes another route. They call it “Infrastructure from Code.” The tool scans application code and automatically generates required infrastructure configurations. This means DevOps teams receive ready-to-use IaC artifacts they can manage, while developers benefit from aligned infrastructure setups without needing to become Terraform experts. It’s automation with respect for domain boundaries, something traditional IaC hasn’t solved cleanly.

Pulumi, an established IaC provider, is integrating generative AI directly into its platform. The outcomes have been mixed so far, but the intent is clear: simplify the authoring and managing of infrastructure through tools powered by machine learning and natural language prompts. As these approaches mature, we’ll see more convergence between Dev, Ops, and Platform Engineering, without forcing unnatural workflows or skill compression.

For senior leaders, this isn’t a time to double down on the status quo. Look at where your current process creates friction. If engineers are burning time just managing templates or stuck waiting on DevOps to provision environments, your infrastructure architecture isn’t helping your business velocity. The tooling is evolving, your strategy should too.

IaC might be overkill for small-scale deployments

Not every organization needs to run full-scale Infrastructure as Code, especially those with small cloud footprints. If your company is managing 20–30 infrastructure resources, heavy-weight templating processes may slow down more than they help. Forcing IaC on smaller operations often leads to complexity without the payoffs in scalability or auditability that justify it.

Joey D’Antoni framed this clearly: IaC has real benefits, but for lightweight deployments, it might be unnecessary overhead. In these settings, teams often find that simply managing cloud resources through the provider’s built-in graphical interface is faster and more effective. That method lacks version control and automation, but for certain use cases, those aren’t deal-breakers.

What’s important for business leaders is making sure infrastructure strategy aligns with scale, stage, and staffing. Small teams with limited DevOps capacity can’t afford to waste hours writing, testing, and debugging infrastructure code unless there’s a return that justifies it. Click-through provisioning isn’t undisciplined, it’s a decision to keep things lean when that’s what the business needs.

The key is to assess whether the infrastructure layer is enabling velocity, or merely adding structure no one benefits from. As the company grows, flexibility remains critical. The infrastructure decisions you make early on shouldn’t lock you into complexity but give you options to scale when it makes strategic sense. At a certain point, IaC becomes essential. But that point isn’t at the same place for everyone.

In conclusion

IaC isn’t broken, but how most organizations are using it is misaligned with reality. The foundational ideas still make sense: automate repeatable infrastructure tasks, bring infrastructure closer to code, and align dev and ops. What’s missing is a system built around how teams actually operate today.

Most failures with IaC aren’t about bad tools or poor intentions. They stem from scaling rigid processes across dynamic environments, assigning responsibilities across mismatched skill sets, and forcing workflows that slow down more than they streamline. The result is frustration, inefficiency, and reactive workarounds that introduce risk.

This is a leadership problem, not just a technical one. If your teams are working around your systems to stay productive, it’s time to rethink the system. Smart tooling helps, but it’ll never replace the value of giving the right people the right level of responsibility, backed by process that adapts as the organization grows.

Leaders need to focus on fit. Where is IaC helping? Where is it creating drag? What does the team need to move faster without compromising safety? The road ahead is less about doubling down on templates and compliance, and more about enabling velocity, specialization, and visibility across the stack.

If you want real impact from infrastructure automation, it starts with designing for how people work, not how tools were originally built.