The 5 Stages of DevOps: Console to AI-Assisted

Picture this: you've just set up a production environment on AWS. Took you a while, but it's running. Your manager walks over and says, "Great — now do the exact same thing for staging." And your stomach drops a little, because you're already trying to remember what size EC2 instance you picked, what permissions you gave that S3 bucket, what password you set on the database.

That moment of dread is the subject of a recent TechWorld with Nana video that maps out the full arc of how infrastructure management has evolved over the last decade — five distinct stages, each one built directly on top of the friction created by the last. It's a framework worth knowing, partly because it's accurate, and partly because the field is moving fast enough right now that misreading where you are on this map is genuinely costly.

Stage 1: The Console (Actually Don't Skip This)

The AWS Management Console — the point-and-click web interface — gets a bad rap in engineering circles. "Real" engineers use code, or so the vibe goes. But TechWorld with Nana pushes back on this in a way that's worth sitting with.

Clicking through the console is legitimately valuable at the start because it makes abstract cloud concepts visible. When you launch an EC2 instance (a virtual server) through the console, you physically see that it needs a VPC (Virtual Private Cloud — basically a private network segment), a subnet within that VPC, a security group (a set of firewall rules), a key pair for SSH access, and potentially an IAM role (permissions). The relationships between these pieces are right there on screen. You're not reading documentation about them in the abstract; you're watching them connect.

The problems are real too: you can't reproduce console work reliably, you can't document it automatically, human error compounds with every repetition, and it doesn't scale. But these aren't reasons to avoid Stage 1 — they're the signals that tell you it's time to move to Stage 2.

Stage 2: Scripts (Faster Clicks, New Problems)

Python with boto3 (AWS's Python library) or the AWS CLI transforms 30-minute clicking sessions into 30-second script runs. You can chain operations: spin up an instance, wait for it, grab its IP, update your DNS, configure monitoring. None of that is feasible to do consistently through a console. Automation this powerful is genuinely intoxicating when you first get there.

But scripts have a blind spot that doesn't reveal itself until it bites you: they have no memory. Run the same provisioning script twice and you don't get one updated environment — you get two environments, one of which is a mystery. As the video explains, debugging your script by running it five times is a great way to discover you now have five servers of unknown legitimacy. Then there's deletion: you need separate scripts, run in the correct order, and if you miss one resource, you're paying for it indefinitely without knowing it exists.

The video's framing here is sharp: "You're automating, but you're not really managing infrastructure. You're just clicking faster through code, basically." That's not an indictment of scripting — it's a precise description of its ceiling.

Stage 3: Terraform and the State Revolution

Infrastructure as Code (IaC) tools like Terraform solve the state problem by flipping the mental model entirely. Scripts are imperative — they tell the system what to do, step by step. Terraform is declarative — you describe what you want to exist, and Terraform figures out the delta between current reality and that desired state, then makes only the necessary changes.

Run Terraform when nothing has changed: it does nothing. Change your instance type from t2.micro to t2.small in the config: it updates that one property. Delete the entire configuration: it tears down the infrastructure. The state file (a record of what currently exists) handles the bookkeeping automatically.

This unlocks several things at once. Infrastructure becomes reviewable — a teammate can catch a security group opened to the entire internet before it ever gets applied. It becomes versionable — Git history tells you who changed what and when. It becomes reproducible — staging and production can be identical configurations with only variable values swapped.

The friction that remains is organizational: someone still has to remember to run Terraform after changes are merged. Engineers under pressure will still sneak into the console to make quick fixes, which silently diverges real infrastructure from what the code says (there's an official name for this: configuration drift). State files need to be stored somewhere everyone can access, with locking to prevent two engineers from running Terraform simultaneously and corrupting it. These aren't dealbreakers, but they're real operational overhead.

Stage 4: GitOps — The Policy, Not Just the Tool

GitOps is where the workflow shifts from discipline to enforcement. Instead of trusting that engineers will run Terraform after merging code, a tool like Argo CD (originally built for Kubernetes application deployments, but the pattern extends to infrastructure) watches the Git repository directly. Code merged to main? Argo CD detects the change, runs terraform plan, and applies it automatically. No manual command required.

More significantly: every few minutes, Argo CD checks whether actual infrastructure matches what's in Git. If someone made a manual change in the console — debugging, emergency patch, whatever — Argo CD reverts it. The Git repository becomes the enforced source of truth, not just the intended one.

The audit questions that plagued earlier stages evaporate. Who deployed this? Check the commit history. Why is staging different from production? The diff is in Git. Need to roll back? Revert the commit. The video's point is that GitOps doesn't just solve technical problems — it dissolves a whole category of coordination and blame-assignment problems by making the record of truth tamper-evident and automatic.

Stage 5: AI — Amplifier, Not Autopilot

The current stage, which TechWorld with Nana argues is still emerging rather than settled, layers AI on top of the GitOps foundation. The use cases are concrete: AI-native code editors like Cursor can generate Terraform configurations from natural language prompts. Describe the setup you want — auto-scaling group, PostgreSQL with read replicas, S3 bucket with encryption — and get back production-grade Terraform code in minutes rather than hours.

AI can also be wired into the review process. A junior engineer opens a pull request; AI scans the Terraform before any human even looks at it, flagging things like an RDS database instance placed in a public subnet (databases generally want to live in private subnets, away from internet-facing traffic) or an instance size that's oversized for its typical workload. It can continuously monitor deployed infrastructure and surface cost optimization recommendations — "this S3 bucket contains 2TB of data untouched for 90 days; cheaper storage tier would save you X per month."

The video is careful about where this ends, though, and the caveat deserves attention rather than dismissal: "AI may make you faster in infrastructure management, but it doesn't replace the technical understanding or domain expertise of the subject." The specific failure mode is precise — if you don't understand what a VPC is, you can't evaluate whether the AI-generated VPC configuration is correct or dangerous. The AI will produce something that looks right. You need to know enough to recognize when it isn't.

The Argument You Should Actually Chew On

The video's organizing thesis — that you cannot skip stages without paying for it later — is intuitive, but it's worth interrogating rather than just accepting.

The case for it is strong: each stage genuinely teaches things the next stage assumes. Someone who jumps straight to AI-generated Terraform without console time won't know what a security group does. They won't catch the AI opening ports it shouldn't, or know what to even ask for in the first place. The knowledge gap compounds.

The interesting open question is how much of this is necessarily sequential versus an artifact of how the tooling currently works. AI tools are getting better at explaining their output, at surfacing the reasoning behind configurations, at teaching through doing rather than just generating. Whether that eventually changes the calculus on stage-skipping is genuinely unclear.

What isn't unclear: the engineers who've walked the full path — console frustration to scripting limits to Terraform relief to GitOps enforcement — show up to Stage 5 knowing exactly what the AI is doing and why. That's a different position than hoping the output is correct.

The path already exists. The question is how much of it you actually need to walk.

Yuki Okonkwo is Buzzrag's AI & Machine Learning Correspondent.