---
title: 'I''ll Explain 10 Years of Infrastructure Evolution in 25 Minutes (Console → CLI → IaC → GitOps → AI)'
source: 'https://youtube.com/watch?v=iTrxsotFNHA'
video_id: 'iTrxsotFNHA'
date: 2026-08-04
duration_sec: 1559
---

# I'll Explain 10 Years of Infrastructure Evolution in 25 Minutes (Console → CLI → IaC → GitOps → AI)

> Source: [I'll Explain 10 Years of Infrastructure Evolution in 25 Minutes (Console → CLI → IaC → GitOps → AI)](https://youtube.com/watch?v=iTrxsotFNHA)

## Summary

This video outlines the evolution of infrastructure management from manual console clicks to AI-assisted automation. It presents a five-stage journey—console, CLI/scripts, Infrastructure as Code (Terraform), GitOps, and AI—explaining the problems each stage solves and the foundational knowledge required to progress.

### Key Points

- **The Problem with Manual Console Setup** [00:02] — Setting up a web application on AWS via the console is easy initially but becomes tedious and error-prone when replicating for staging or production. Key issues: not repeatable, not documented, prone to human error, and doesn't scale.
- **Stage 2: CLI and Scripts** [04:31] — Using AWS CLI and Python scripts (boto3) enables automation and repeatability. Scripts can be shared and act as documentation. However, they lack state management: running a script twice creates duplicate resources, deletion is complex, and updates are not handled well.
- **Stage 3: Infrastructure as Code (Terraform)** [07:40] — Terraform uses declarative configuration instead of imperative scripts. It maintains a state file to track existing resources, compares desired vs. actual state, and makes only necessary changes. This makes infrastructure repeatable, reviewable, and versionable.
- **Problems with Terraform** [12:14] — Even with Terraform, issues remain: manual execution (someone must run terraform apply), configuration drift from manual changes, state file management (needs shared storage and locking), and coordination among team members.
- **Stage 4: GitOps** [14:56] — GitOps automates the deployment of infrastructure changes by watching a Git repository. Tools like Argo CD detect changes, run Terraform plan/apply automatically, and continuously sync to revert manual changes. Git becomes the single source of truth.
- **Stage 5: AI-Assisted Infrastructure** [18:27] — AI can generate Terraform code from natural language prompts, review code for security/cost issues, and continuously monitor infrastructure for optimization opportunities. However, AI does not replace foundational knowledge; understanding the concepts is essential to evaluate AI output.

### Conclusion

The journey from console to AI is a progression where each stage builds on the previous. Skipping stages leads to a lack of foundational knowledge, which is critical for effectively using advanced tools like AI. Understanding where you are on this journey helps you decide what to learn next.

## Transcript

devops engineer. Your first task is to set up a web application on AWS. The application needs a server to run on and database to store data and storage for user uploaded files. So you open the AWS console and start clicking. You launch
an EC2 instance, click click, configure, create an RDS database, click through the settings, you set up an S3 bucket, so more clicking, and it works. The application is running, you feel great. But then your manager says, "Now you
need to do exact same setup for our staging environment." So you open the AWS console again and start clicking. Launch another EC2 instance, but here you have to pause because you think, "Wait, what size did I use last time?"
Then you have to create another database, and you think, "What password did I set for this database?" Another S3 bucket. "What permissions did I configure for the first S3 bucket?" you realize that you don't remember exactly
what you did because there are thousands of details in the configuration. And even if you wrote it down and documented it, recreating everything by clicking is tedious and very error-prone. So this is when you start wondering, "There has to
be a better way, right?" And there is. Actually, there are several ways. And most engineers think there are just two approaches: the old way where you click through the console and the new way where you use tools like Terraform. But
that's like saying there are just two ways to get somewhere, either walking or teleportation. There's actually a whole journey in between. So in this video, I want to show you the four stages of infrastructure management. Each stage
solves problems from the previous stage, and understanding where you are on this journey will change your perspective about what you should learn next. So about what you should learn next. So let's start at the beginning.
infrastructure through the AWS console. Everything is done by clicking through the web interface. You need to launch an EC2 instance, you just click through the launch wizard, choose the instance type, configure the network, add storage, set
up security groups, and so on. You need an S3 bucket, just click create bucket, fill in the name, set the permissions, configure encryption, leave the rest of the defaults, and there you go. And honestly, that actually works. And it's
very easy to start here. You can see everything visually, you can explore the options, it feels very tangible and understandable. And this is why this stage is actually important. You need to actually understand the basic concepts
of cloud infrastructure before you start automating it. So, you need to understand what VPC is before you provision it automatically. You need to see how security group rules actually work visually, which ports you're
opening, what IP ranges you're allowing, before you can write them in code. So, the console actually teaches you what AWS resources exist and how they connect to each other. When you're launching an EC2 instance through the console, you
see the relationship between the VPC it needs to be in, the subnet within that VPC, the security group that controls traffic, the key pair for SSH access to your instance, the IAM role that it might need. So, you're learning all
these basic building blocks and round the EC2 instance that you're creating. And this is valuable, but pretty quickly, you start hitting problems. First of all, it's not repeatable. You set up a production environment, now you
need staging. You have to click through everything again, trying to remember what you did in which order exactly. Second, it's not documented. So, six months later, when someone asks, "Why did we configure the security group this
way?" you don't remember. Nobody remembers. There's no record. Also, it's very human error prone. When you're setting up the 10th server, you're tired, you accidentally choose the wrong security group, you forget to close a
port, open another one, the server cannot connect to the database, debugging takes hours, so very high chance of human error here. And finally, it doesn't scale. If you need to launch 20 servers, are you going to click
through that wizard 20 times? That is super inefficient. So, you start looking for a better way, and you discover the AWS CLI and Python scripts.
So, welcome to stage two. You discover that you can control AWS through code. And now that you understand those basic concepts and building blocks, you don't need to visually see them all the time. So, instead of clicking, you start
writing scripts, like a Python script, cuz Python has a library for AWS to connect with AWS and basically do anything that you can do in the console programmatically, or connect to any other cloud provider. So, you start
controlling, creating, configuring everything via scripts. And this is a game-changer, because now you can repeat things. You save your script, just run which is identical. You can share the script with your team. It also acts as a
documentation, and you can modify it for different scenarios. And this stage is powerful, because it gives you automation. Tasks that maybe took you 30 minutes of clicking, now take just 30 seconds. And you can add logic to your
scripts. You can check if a resource already exists before creating it. You can look through a list to create multiple resources, or handle errors gracefully. You can also chain multiple operations to create more complex
workflows. For example, you can say, "Launch an EC2 instance, wait for it to be up and running fully, get its IP address, update your DNS records, configure monitoring, and so on. Now, try doing all that through the console
automating everything with Python scripts. Everything looks great, but you quickly learn that scripts are great for automation, but terrible for state management. Let me explain what I mean.
You write a script that creates an EC2 instance. You run it, great, you have a server. The next day, you run the same script again. Maybe you forgot you testing something, some configuration change. Now, you have two servers. So,
which one is the real one? You're debugging your script, so you run it Congratulations, you just launched five servers, and you're not even sure which ones are supposed to exist. So, the script does not know what infrastructure
already exists, unless you explicitly check it. It just executes commands. resources. So, you end up writing a lot of code to check, "Does this resource exist? If yes, don't create it. If no, create it." And you would have to do
this with every single resource. And this gets complicated really fast. But here's another problem, deletion. Let's say you created 10 resources with your script. Now, you want to tear everything down, delete the whole stack. You need
separate scripts to delete everything in the right order. If you miss one resource, you're paying for something that you forgot existed. Or if you delete things in the wrong order, it may mess up your entire infrastructure. And
finally, these scripts also do not handle updates well. Let's say you have a server running, you want to change its instance type. Your script only knows how to create servers, but it's not really good at modifying them. So,
you're automating, but you're not really managing infrastructure. You're just clicking faster through code, basically. So, this is when you realize you need something that understands the current state of your infrastructure and can
manage changes intelligently. And that's where infrastructure as code tools like where infrastructure as code tools like Terraform come in. infrastructure as code. With Terraform, you completely change how you think
about infrastructure. Instead of writing imperative scripts that say, "Do this, then do that. If resource exists, don't create it. If it doesn't exist, then create it." Instead of these imperative commands, you write declarative
configuration that says, "This is what I want to exist." So, basically, instead of giving the script a step-by-step execution steps of what it needs to do, you say, "This is what I want as a final
result. You figure out the steps behind to get me this result." So, that's how Terraform works compared to Python script, for example. So, here's what the same EC2 instance looks like in Terraform compared to Python script, for
example. You're not saying, "Create this instance." You're saying, "This is a definition of a resource that I want you to create. It's an EC2 instance with these properties." And after I execute this, this thing should exist. And
here's where it gets interesting. When you run Terraform the first time, Terraform sees in your code configuration that you want an instance. configuration that you want an instance. Then it goes to AWS and it checks, "Does
this instance already exist in AWS infrastructure or not?" And it sees it doesn't exist. So, Terraform creates it. Now, you run Terraform the second time, anything. Terraform sees you want an instance. Again, the code hasn't
changed. It goes and checks, "Does it already exist?" Yes, Terraform does nothing. Then you go and change the instance type of the same instance to T2 instance type. Again, Terraform checks the code, "Oh, this is what you want."
Then it goes and compares what is a type of the instance that already exists. It's T2 micro, but you want T2 small. Great, let me handle this. So, it updates the existing instance with that one property. Finally, you delete the
configuration. You basically just select the entire code and you just delete it. Terraform sees you don't want any instance. It goes to AWS and sees but there is an instance in the infrastructure, but your code says you
don't want any. Perfect, it just deletes it to match your desired configuration. And this is state management. And Terraform does it very easily actually by just maintaining a simple state file that tracks what infrastructure exists
at any moment and comparing it to what's in the code. So, every time you run Terraform, it reads your configuration, the Terraform code that's tells it what you want, it reads the current state, what exists, compares them, shows you a
plan of what will change after the execution. So, you confirm that you want this change to happen and makes only the necessary changes to give you that new desired state. And this now changes everything because your infrastructure
suddenly becomes repeatable, means the same Terraform code produces the exact same infrastructure every time, no matter how many times you run the script. And you can create identical staging, production, development
environments from the same code with single command execution. Now, usually you have some values or some variables that are different across those environments, even though the resources are the same. So, Terraform actually
gives you a way to parameterize your code and pass those different variable values if you need to for different environments. Your infrastructure also becomes reviewable and this is very important. Infrastructure changes go
application code, because your entire infrastructure is now written as code. So, your teammate can see, "Wait, you're opening port 22 to the entire internet? That is a security risk." And you can fix these issues before applying the
changes. Your infrastructure also becomes versionable. I don't know if this is a real word, but your infrastructure basically lives in Git, which allows your infrastructure code to be versioned just like your application
code. So, you can see entire history of changes, who made what change and when. version if you need to, and it's automatically documented without you having to create some text document, because the code is the documentation.
If you want to know how production is configured, you just read the Terraform everything looks great with our Terraform configuration, but even with Terraform, problems still exist. First of all, manual execution. You still have
to remember to run Terraform. Someone needs to notice a change was merged to Git and manually apply it, so that the actual infrastructure gets updated, right? Someone needs to run Terraform apply command from terminal to make the
changes. Problem number two is, in parallel to Terraform code making changes to AWS infrastructure, you still have manual changes made to the infrastructure. So, someone goes into AWS console and manually changes
something, because maybe they were debugging some issues, so they need to fix something quickly. Or maybe there was an emergency fix, so they just wanted to quickly patch and fix some issue, and they just took the fastest
route by doing it directly in AWS. And when that happens, it actually breaks a lot of things, because now your Terraform state does not match the actual state or the reality. And if nobody executes Terraform run after
these manual changes, then nobody even notices there was this change for months. And then something breaks, you realize that your infrastructure drifted from your code. And there is official name for this as well, called
configuration drift. Another issue that you have with Terraform is state file management. The state file needs to be stored somewhere everyone can access. Usually, S3 bucket is used to store that file because if you have it locally on
your computer, what happens if another engineer wants to run Terraform script up-to-date state file that you have, right? So you need to set up locking so
simultaneously and corrupt the state. And finally, there is an issue of coordination because multiple team members working on infrastructure need to coordinate who's applying the changes in what order. What if two people are
working on different parts or the same parts of the code? And these problems are all soluble, obviously, but they need operational overhead. And they all point to the same fundamental issue, which is Terraform is still a tool you
manually run. But what if instead the infrastructure automatically stayed in sync with your code? What if manual changes were automatically reverted? And automatically when Terraform code
changes was merged in Git repository? Do we have a concept for that? That could actually solve most of these problems, right? Well, that's exactly where the final stage comes in, which is called GitOps.
So with GitOps, you fundamentally change how infrastructure changes are deployed. So Terraform solves the problems of how infrastructure creation, deletion, and modification is automated. On top of that, now we have this layer that
actually manages how those changes are deployed and enforcing a team workflow where there's no configuration drift, nobody manually intervenes, and so on. And that's what GitOps does. So, instead of manually running Terraform, you
basically set up an automated system that watches your Git repository. It detects whenever infrastructure code changes in the repository. And whenever it does, it automatically fetches those changes and applies those in the
continuously ensures that reality matches what's in Git. So, let me give you specific examples. Let's say you're using a tool like Argo CD, which was originally built for Kubernetes, but the
pattern applies to infrastructure as well. And you have a Git repository with all your Terraform code. And you configure Argo CD to watch this Step one, you need to change infrastructure. Maybe you want to add a
new server. So, someone on the team edits Terraform code in their local Git clone, right? So, locally on their laptop, they make the changes. And once they're done, they open a pull request. Your team reviews it and says, "Looks
configuration, so we can actually apply it." And to confirm that the PR is merged to the main branch. As soon as this happens, Argo CD detects that there was a change or new commit in the branch. It automatically runs Terraform
plan to see what will change. It applies the changes, and your new server is created. So, nobody has to run manual commands to apply the changes. You just merge to Git, and the rest was done automatically. But here is the really
powerful part of GitOps, which is the continuous sync. Every few minutes, Argo CD would check, "Does the actual infrastructure match what's in Git?" So, let's say someone goes into AWS console and manually changes a security group
configuration. Maybe they're debugging or testing something. Argo CD detects, "Wait, the security group in AWS does not match what's in Git." So, it automatically reverts the manual change back to what Git says. In this way, it
back to what Git says. In this way, it enforces that no manual changes persist and that whatever it naturally means that Git repository becomes the single source of truth. If it's not in Git, it will not exist. If someone makes a
manual change, it gets reverted to what's in Git. So, think about what problems now disappear with GitOps. If you want to ask who deployed this the commit history. Why is staging
Well, they're both deployed from the same Git repository with different variable files. So, if they're different, the difference is visible in Git. Someone made a manual change and now things don't work. Can't happen
reverted. We need to roll back to yesterday's infrastructure. Just revert the Git commit, the automated system deploys the previous version. I'm Well, system applies it automatically after the code review. So, you can run
all the tests and make the checks within the pull request before it gets merged and deployed to the infrastructure. So, this is an ideal infrastructure state that you want to work towards. But, there is a stage after GitOps that we're
going to see become more and more prevalent in the future because of AI. So, this is stage five of what I call an AI-assisted infrastructure that directly
layers on top of infrastructure as code and GitOps to make it even more efficient. So, where does AI fit into this whole thing? Well, even with GitOps, you're still doing few things manually, which is writing all the
changes yourself, debugging configuration issues, and those are exactly the things that you can now automate or enhance with AI. So, let's go back to our initial scenario where you need to set up that web application,
server, database, storage, and and on. With GitOps, you would still need to write Terraform code for the EC2 instance, configuring the RDS database with all its settings, or set up the S3 bucket with proper permissions, right?
Create security groups with the right rules, and so on. And this requires deep AWS knowledge cuz you need to understand those concepts to be able to write it in Terraform. You need to know which instance type to choose, what database
engine settings to configure, how to structure security groups correctly, and you need to go and make sure you have the up-to-date Terraform syntax to define the desired infrastructure because things do change, and AI is
exceptionally good at writing code. So, instead of searching for the right syntax and configuration to create your desired infrastructure configuration in Terraform, you basically go to AI or use an AI-native
code editors like Cursor, and you just type in natural language, "I need a web application setup with auto scaling between two and 10 instances, a PostgreSQL database with read replicas, and an S3 bucket for user uploads with
proper security." And AI generates the Terraform code for you. It creates an configuration, an application load balancer, the database with read replicas in multiple availability zones, S3 bucket with encryption and
appropriate access policies, security groups with least privilege rules, and then you, as an experienced engineer, you review the generated code to make sure it's correct, adjust anything specific to your needs, and now you have
code ready for your use case within minutes instead of maybe hours. You can also create AI automation for code reviews, right? Whenever a junior engineer commits something to a Git repository, you can have AI review the
code and detect any security issues or any configuration issues, and so on. So, AI can actually catch issues before your teammates even look at the code. It will know the AWS best practices, security guidelines, cost optimization patterns.
So, for example, it may flag configuration and say, "This RDS instance is in public subnet, but best practice to put databases in private subnets. So, please change that." Or you're using T3.large
for this workload. Based on typical usage patterns, T3.medium would be sufficient and save you another $30 per month. And in addition to that, you can actually use AI to continuously monitor your infrastructure resources while they
are deployed, which is actually a completely new addition to your Because traditionally, you would just deploy resources with Terraform or GitOps, and they just stay there until you manually review and optimize and
decide, "Are we creating resources that we're not fully using and paying a lot even need?" So, you can create AI automation that continuously analyzes your infrastructure and tells you, "Hey, your production database is using uh 40%
CPU on average, and you're paying for a large database instance, but medium would be sufficient to handle your load. You can save this much per month." Or you can say, "Three EC2 instances have been running for 6 months with
consistent usage, so switching to reserved instances would save you 40%." Or detect, let's say, "This S3 bucket has 2 TB of data that hasn't been accessed in last 90 days, so maybe you
can move it to a cheaper storage and save this much per month." So, as you see, AI can actually enhance parts of your infrastructure management if you use it efficiently. But here is a very important point that I want to make. AI
may make you faster in infrastructure management, but it doesn't replace the technical understanding or domain expertise of the subject. If you ask AI to create a VPC with public and private subnets, but you don't understand what a
VPC is or why you would want public versus private subnets, you cannot evaluate if AI solution is correct. AI may generate code faster that looks right, but has maybe subtle security issues. If you never went through stage
one and learn what a security group does, you won't catch that the AI maybe opened too many ports. Or in most cases, you wouldn't even know what to ask AI to
create or automate for you if you don't understand the underlying concepts. So, think of AI as a knowledgeable co-worker, not a replacement for your knowledge. Because if you hire a team member that has a lot of knowledge and
is very efficient in what they do, it doesn't mean that you now need to know less, right? The more knowledge you have, the more efficiently you can use this AI assistant, basically, to work much faster and get the most of your
knowledge and understanding of the subject. And that's why the learning path is not to start with AI and jump straight into the end stage, but actually go through the stages one by one. Because a lot of junior engineers
try to jump straight to the AI code generation because it sounds impressive and they don't want to {quote} unquote lose time, but that means they will never build a foundational knowledge if they skip the stages. So, the expert
engineers who really understand infrastructure walked the whole path. they understood the cloud concepts and main building blocks. They automated with CLI or Python until they hit the limits and felt the pain of imperative
scripting. Then they adopted infrastructure as code and understood the value and power of declarative configuration and state management. Then they implemented GitOps, and now they use AI to work faster. They understand
everything that AI generates because they've written it manually before. So, each stage actually teaches you something that the next stage assumes you know. So, when you review the stages, just know where you are on the
journey and what comes next. And if you need a structured path through the stages, our DevOps boot camp covers stages one till three like console scripting and infrastructure as code and the advanced DevSecOps boot camp takes
you into GitOps and securing infrastructure parts. And once you have that deep expertise, you can layer AI automations on top of that at any point very easily yourself. Because once you know how to do things manually and how
they work under the hood, you can then easily automate them. Now, I hope you learned a lot of valuable insights in this video. Let me know in the comments what your next action step is in your infrastructure management journey. I'd
love to hear where you are and where you headed. And with that, as always, thanks for watching and I'll see you in the next video.