No serious team merges application code without a review, a record of who changed what, and a way to undo it. Then those same teams build their entire cloud, the servers, databases, networks, and permissions that the code runs on, by clicking around in a console, with none of those safeguards.
This manual approach, often called ClickOps, is the single biggest driver of configuration drift, and drift is not harmless. Misconfigurations are behind a large share of cloud security failures, and roughly 82 per cent of them come from human error rather than any flaw in the cloud itself (Quali, 2025; datastackhub, 2026). The consequences can hide for years: Toyota disclosed in 2023 that a single cloud misconfiguration had exposed vehicle and customer data for around 260,000 people for eight years before anyone noticed (InformationWeek, 2024).
Infrastructure as Code is the fix, and the idea is simple: instead of clicking your infrastructure into existence, you describe it in version-controlled files, and a tool builds it to match (Transparity, 2026). This post is about why that one shift changes everything, from consistency to audits to disaster recovery, and what it does not solve. No code, just the argument.
What Infrastructure as Code actually is
It has two parts. You write down the infrastructure you want, declaratively, in files kept in version control, and a tool reads those files and makes your cloud match. The plain analogy is folding paper planes: instead of folding hundreds by hand and hoping they come out the same, you give a machine a blueprint and it produces perfect ones every time (Terramate).
Concretely, that means defining cloud infrastructure via version control in a file repository rather than building it manually through web portals (Transparity, 2026), and because the tool is declarative, it detects and corrects any drift from your stated intent on the next run (Spacelift, 2026). This is now mainstream: in one 2026 developer survey, 59 per cent of respondents said they actively manage infrastructure definitions in code, up from 34 per cent five years earlier (01, 2026).
The nuance is that this is not about a particular tool. Terraform, Pulumi, Bicep, and CloudFormation all do it. The shift that matters is treating infrastructure as something you write, review, and version, rather than something you click.
The problem it replaces: clicking creates snowflakes nobody can rebuild
The manual approach produces snowflake systems, each one slightly different, undocumented, and impossible to reproduce, because every manual step is a chance for a small deviation and there is no reliable record of what was done. Manual configuration introduces human error and creates undocumented snowflake systems that are hard to maintain and troubleshoot (Cloud Handbook, 2025).
It also breaks the paper trail. Documenting each manual step by hand is tedious and prone to inaccuracy, which makes it very hard to audit changes, track configurations, or onboard new people, and if you deploy twenty servers by clicking, however careful you are, they will not come out truly identical (Intercept, 2025).
The nuance is that clicking genuinely feels faster, especially under pressure in an incident, which is exactly why even experienced engineers fall back to it (Quali, 2025). The cost is not felt in the moment. It is felt later, as drift, wasted spend, and the day you need to recreate an environment and cannot.
Payoff one: reproducible, consistent environments
Because the whole environment is described in files, you can create an identical copy on demand, which fixes both consistency and recovery at once. With IaC, new environments are provisioned straight from the configuration, repeatably and without discrepancies between them (Spacelift, 2026), which is why environments become reproducible artefacts and consistency becomes programmable (01, 2026). When manual provisioning is used instead, 44 per cent of organisations report drift between development and production (01, 2026).
The recovery benefit is just as concrete. The code repository is essentially your infrastructure in file format, redeployable into another region far faster than rebuilding by hand (Transparity, 2026), and organisations using automated provisioning cut their average recovery time by 37 per cent (01, 2026).
The nuance is that reproducibility is only as good as your coverage. If half your infrastructure is in code and half was clicked, you have the worst of both, so the value grows as more of the estate comes under code.
Payoff two: every change is reviewed, recorded, and cheap to get right
When infrastructure is code, an infrastructure change becomes a pull request, so it inherits review, an audit trail, and the chance to catch mistakes before they ship, exactly like application code. Defining infrastructure as code allows code review, approval, and pull-request workflows just like software development, and lets a change move through test and acceptance stages before it ever touches production (Jamf, 2025).
Version-controlled IaC is, in effect, the most effective drift antidote there is, precisely because it brings immutable history, peer review, and one-command rollbacks to infrastructure (Quali, 2025). Those are the same habits you already trust for code, applied to the layer underneath it.
The nuance is that the review only helps if the pull request is the only way in. The moment someone can still click a change directly into production, the audit trail has a hole in it, and the code stops reflecting reality.
What IaC does not fix, and what it costs
IaC is a discipline, not magic. It does not automatically make your infrastructure secure, it has a real learning curve, and it fails quietly if people keep clicking alongside it. The honest trade-offs are a false sense of security, since hardcoded secrets, weak access controls, or poorly written definitions can still introduce vulnerabilities; a steep learning curve for teams new to declarative syntax and version control; and above all operational drift, because if a team uses IaC but keeps making ad-hoc portal changes, the code no longer reflects reality, leading to failed deployments and environments that cannot be reliably recreated (Transparity, 2026; Spacelift, 2026).
Drift is consistently the most frequent issue teams hit with IaC (Terramate), which is really the same lesson in a different place: the code is only the source of truth if nobody goes around it.
The nuance is that none of these are reasons to keep clicking, they are reasons to adopt IaC deliberately, usually by starting small and bringing existing infrastructure under code gradually rather than in a big-bang rewrite (Spacelift, 2026). And one honest carve-out: some things, databases in particular, are genuinely harder to manage this way, so most teams codify the bulk of their infrastructure and treat those few exceptions with extra care (platformengineering.org, 2026).
The part worth sitting with
So come back to the double standard we started with. You would never let a line of application code reach production without a review, a record, and a way back, yet the infrastructure underneath it, the part where a single wrong setting can expose millions of records or take the whole system down, is too often built by clicking, remembered by nobody, and reviewed by no one. Infrastructure as Code closes that gap. It turns your cloud into something you write down, so it can be reviewed before it changes, reproduced when you need a copy, rebuilt when it breaks, and explained when an auditor asks. It will not make you secure on its own, and it asks your team to learn new habits and, harder, to stop clicking. But the alternative is what Toyota lived with for eight years: infrastructure whose true state existed only in the console, drifting quietly, until the day it was found by someone you did not want finding it. Write it down, and review it like you review everything else that matters, because your infrastructure is everything else that matters.
Author note
I am Mohan Gopi, an Associate DevOps Engineer at Frigga Cloud Labs. I work across AWS, GCP, and Azure, with GitHub Actions as the deployment backbone for everything I ship. The pattern I keep seeing is teams that treat their application code with real rigour and then hand-build the cloud underneath it by clicking, and every messy incident I have walked into eventually traces back to a manual change nobody recorded. Moving infrastructure into code did more for my sleep than almost anything else, not because the tools are elegant, but because a change to production infrastructure now looks exactly like a change to code: a pull request someone reviews, with a plan I can read before it runs and a history I can point to afterwards. My one hard rule is that the console is for looking, not for changing, because the moment someone clicks a fix into production, the code stops telling the truth. Start small, bring one thing under code, and never go back. If you want to compare how you structure it, I am on LinkedIn → Mohan Gopi.