Infrastructure-as-Code has had a long journey, so far. Back from the early days when you could have automated your infrastructure deployments in Azure via ARM templates, to nowadays when you have multiple language options from which you can choose, depending on your needs or preferences: Bicep, Terraform, Pulumi and so on.
But now AI is here – and I think that’s a major game changer to how infra-as-code development and delivery will evolve.
1. Faster delivery time
This one is quite a no-brainer, probably.
Now, with AI, writing code becomes less and less of an activity. With AI you can just describe your intent and you’ll have your infrastructure-as-code in now time. Imagine the following – instead of writing from scratch bicep/terraform code for building, let’s say, 2 VMs in a VNET, you can easily instruct your AI to do so by just prompting something like “build bicep/terraform code that will build 2 VMs that are sitting in a VNET with an address space of 10.0.0.0/24, having 2 subnets of /28 each, each VM being in a separate subnet”.
No matter the level of your skills and how fast you can develop, you’re most probably not faster than an AI – so having a codebase for your infrastructure now has just become faster.
2. Standardization
For this one, try to think a bit just beyond code. If you’ve been part of multiple teams so far, you’ve noticed that each team has its own way of working, own preferences, own style. That even goes further and can be said the same about engineers – some just have different coding standards/methods than others. Applies also to architects – some design decisions were always debated when, in reality, there was no right or wrong answers.
AI can help on that, by standardizing things without internal arguments – by having your internal AI specifically for IaC related stuff, you can instruct it from the start to respect certain key-design aspects.
I’ll give you an example, to better understand: let’s presume your infra-as-code codebase relies on modules – if somebody will ever want to develop code for a new deployment, the AI, regardless of what’s instructed as a prompt, will follow the same way-of-working (on modules) and generate code that falls in line with that.
And don’t just think about code development here – go even further, to design/architecture decisions. You can instruct your AI to, each time, respect naming conventions, to respect security rules, governance and compliance considerations, and so on.
This way, you don’t have to worry that somebody from your team will forget about such things – your AI that develops infra-as-code will do that, implicitly.
You can even go further and have an AI agent that scans new code to see if it complies with all the architecture decisions that were made. Better to flag those things out before deploying, right?
3. Less error-prone
Infra-as-Code is usually repetitive, if we’re all being honest – you code/build resources, but also need care for identities, for monitoring, for diagnostic settings, and so on.
It’s easy to forget something, at some point.
The thing is that AI doesn’t get bored – once instructed, it will always include code for diagnostics, for monitoring, for identities. Having natural language prompts with predefined agent skills transforms us into engineers reviewing IaC work, not doing the “hardwork” anymore.
4. MCP servers
Of course, everything that we’re implying in this article, works on the assumption that the AI has the needed context to do such things. And for that… that’s where MCP (Model Context Protocol) servers can be of help.
With MCP servers, you can potentially ask why a certain deployment failed or why a certain file isn’t compliant with your architecture standards. MCP servers are basically the bridge between your AI agents and your internal dev universe.
5. Debugging made easy and… proactive.
Think about those pipelines that sometimes fail because of updates – can be a Microsoft update of an infra-as-code piece or some PowerShell module. AI can help on that too.
You can have AI agents that scan your failing pipelines and, based on the error, provide human-like explanations why the automation failed, what are the possible remedies and what needs to be done next.
Apart from reducing time to debug and repair, it also provides direct context on the issue and proactiveness in detecting the issue, instead of a reactive approach (such as when an engineer runs a pipeline/automation and realizes it fails because of some unknown reason).
6. Doing the nasty work – correcting tech debt.
Tech debt almost always exists, especially in IaC – even if we’re talking about deprecated resource, old modules, old versioning of a bicep resourceType or design patterns that are no longer applicable.
AI agents can scan repos and flag all of these outdated patterns. Will it clean up everything from the first try? Probably not. But constant clean-ups (under controlled review by a human) can help refactor that nasty tech debt that’s sitting in your repos.
Long story short is that IaC will not disappear. It’s just that the way we work with it is changing. It changes focus from less typing/coding, to more designing/thinking and reviewing.
Realistically speaking, it will transform engineers into small technical managers – managers of AI agents.
