DEV Community: Nerav Doshi

What is AI? You Are Already Using It - You Just Did Not Know

Nerav Doshi — Mon, 08 Jun 2026 23:08:14 +0000

Pipeline & Prompts | Byte size guides on DevOps, Cloud and AI

I Was Selling AI Before Most People Knew What It Was

A decade ago I was selling predictive and prescriptive analytics solutions to enterprise clients. Tools like SPSS Modeler — IBM’s data science platform for predicting future outcomes — and CPLEX, the optimisation engine we talked about in Article 6, which solved complex scheduling and logistics problems for supply chain and warehouse operations.

Back then AI was not a word that appeared in everyday conversation. It lived in university research departments, specialist software vendors, and the back offices of large corporations with data science teams. It was powerful, it was real, and almost nobody outside of those environments knew it existed.

Fast forward to two years ago. ChatGPT arrived and suddenly everyone was talking about AI.

My initial reaction? Skepticism. I had spent years working with AI tools that were precise, deterministic, and built for specific problems. ChatGPT gave confident answers that were sometimes completely wrong. The hallucinations — the technical term for when AI models generate plausible sounding but entirely false information — bothered me. I knew enough about how these systems worked to be cautious.

Then something changed my mind.

I was preparing for a conference demo and needed to test how an AI assistant would handle tough questions from a live audience. I spent an hour asking it difficult questions, critiquing its answers, pushing back on things it got wrong. And in that session I saw something I had not expected — not perfection, but genuine usefulness. The ability to think through a problem with you, draft something in seconds, and improve it based on your feedback.

Shortly after that I started using it for small things. Polishing emails. Sharpening how I communicated complex ideas. Then one day I pasted my Terraform code — the infrastructure code I had built through trial and error and a lot of googling — into Claude and asked it to review it.

What came back stopped me in my tracks. It critiqued my code the way a senior platform engineer would. It spotted patterns I had missed, suggested improvements I would not have thought of, and explained why — clearly, patiently, without making me feel like a beginner.

That was the moment I truly understood the power of modern AI.

But First — What Actually is AI?

Artificial Intelligence is the ability of a computer system to perform tasks that would normally require human intelligence.

That sounds abstract so let us make it concrete. Human intelligence involves things like recognising patterns, making predictions, understanding language, solving problems, and learning from experience. AI systems are built to do those same things — not by thinking the way humans think, but by processing enormous amounts of data and finding patterns within it.

There are different types of AI and understanding the difference between them helps everything else make sense. The best way to explain them is through an example most people use every single day — maps and navigation.

Four Types of AI — Explained With Maps

Descriptive Analytics — What Happened?

This is the most basic form. It looks at historical data and tells you what occurred.

On Google Maps this is your journey history — every route you have taken, how long it took, where you stopped. Pure description of past events. No intelligence applied yet, just organised data.

In business this is your monthly sales report, your website traffic dashboard, your bank statement. It tells you what happened but does not tell you why or what to do next.

Predictive Analytics — What Will Happen?

This is where it starts getting interesting. Predictive AI looks at historical patterns and uses them to forecast future outcomes.

On Google Maps this is the traffic prediction — “your journey will take 45 minutes, but if you leave in 30 minutes it will only take 28.” It has analysed millions of journeys on that route at that time of day and is predicting what will happen based on patterns it has learned.

This is the type of AI I was selling with SPSS Modeler a decade ago — predicting customer churn, forecasting demand, identifying which patients were most likely to need hospital readmission. Powerful, specific, and already well established long before ChatGPT existed.

Prescriptive Analytics — What Should I Do?

This goes one step further. It does not just predict what will happen — it recommends the best action to take.

On Google Maps this is the rerouting feature — “there is an accident ahead, I have found a faster route, turn left in 200 metres.” It has predicted the problem and prescribed the solution automatically.

This is where CPLEX lived — not just predicting that a warehouse would run short of stock, but calculating the optimal way to redistribute inventory across the entire supply chain to prevent it. Prescriptive AI makes decisions, not just predictions.

Generative AI — What Can I Create?

This is the newest category and the one that changed everything in the last two years. Generative AI does not just analyse existing data — it creates new content. Text, images, code, audio, video.

On Google Maps this is still emerging — but think about the natural language directions that sound like a human giving you instructions rather than a robotic voice reading coordinates.

ChatGPT, Claude, Gemini, GitHub Copilot — these are all generative AI. They have been trained on vast amounts of text and code and can generate new, original responses to almost any question or request. This is the AI most people mean when they say AI today.

AI You Are Already Using Without Realising It

Here is the thing most people do not know — you have been using AI in your daily life for years. It was just not called AI in the marketing materials.

Your email spam filter — AI analyses incoming emails and decides which ones are spam based on patterns it has learned from billions of emails. Every time you mark something as spam you are training it.

Netflix and Spotify recommendations — AI analyses what you have watched or listened to, compares it to millions of other users with similar tastes, and predicts what you will enjoy next. The “because you watched” row is a predictive model running in real time.

Your bank’s fraud detection — Every time you make a transaction, AI compares it to your normal spending patterns and flags anything that looks unusual. That text asking you to confirm a purchase abroad? AI spotted something that did not fit your pattern.

Voice assistants — Siri, Alexa, and Google Assistant use AI to convert your speech into text, understand what you mean, and generate a useful response. Every conversation makes the model slightly better.

Your phone’s face recognition — AI learned what your face looks like from the setup photos and now recognises it in milliseconds under different lighting conditions and angles.

Search engines — Google does not just match keywords. AI understands the intent behind your search and tries to surface the most relevant result even when your query is vague or poorly worded.

You are not just beginning to use AI. You have been living with it for years.

Why I Went From Skeptical to Convinced

The hallucination problem I mentioned at the start is real and it has not gone away entirely. AI models can still generate confident, plausible, completely wrong answers — and that is dangerous if you accept everything they say without thinking critically.

But here is what changed my perspective.

AI is not a replacement for your judgment. It is an amplifier of your capability.

When I used AI to review my Terraform code it did not replace my understanding of what the code was supposed to do. It applied a layer of expertise I did not yet have — the pattern recognition of someone who has reviewed thousands of infrastructure codebases — and gave me feedback I could evaluate with my own knowledge.

When I use it to polish my writing it does not replace my ideas or my voice. It helps me communicate them more clearly and efficiently.

The people who get the most out of AI are not the ones who trust it blindly. They are the ones who bring their own knowledge and judgment to the conversation and use AI to go further, faster than they could alone.

How AI Connects to Cloud and DevOps

If you have been following this series you might be wondering — how does all of this connect to everything we have covered so far?

More directly than you might think.

AI runs on Cloud infrastructure. The models behind ChatGPT, Claude, and every other AI tool run on massive cloud data centres — the same AWS, Azure, and Google Cloud platforms we have been talking about throughout this series. Training a large AI model requires thousands of specialised processors running for weeks. That kind of compute only exists in the cloud.

AI is deployed using containers and Kubernetes. When a company builds an AI powered application — a chatbot, a recommendation engine, a fraud detection system — it is packaged into containers and deployed on Kubernetes clusters, exactly as we covered in Articles 4 and 6.

AI infrastructure is managed with Terraform. The cloud resources that run AI workloads — the GPU clusters, the storage, the networking — are provisioned and managed with the same Infrastructure as Code tools we covered in Article 7.

AI is changing DevOps itself. GitHub Copilot writes code suggestions in real time. AI tools review pull requests and spot bugs before humans do. Pipelines are becoming smarter — able to predict failures before they happen and suggest fixes automatically.

The boundary between AI and DevOps and Cloud is dissolving. They are becoming one interconnected discipline and understanding all three is becoming one of the most valuable skill sets in technology.

AI is Not Going Away — And That is a Good Thing

A decade ago AI was a specialist tool for specialist problems. Today it is woven into almost every digital product you use. In another decade it will be as invisible and essential as electricity — present in everything, noticed only when it is absent.

The question is not whether AI will affect your work and your life. It already has. The question is whether you understand it well enough to use it intentionally, critically, and effectively.

You do not need to become a data scientist or a machine learning engineer. But understanding what AI is, how it works at a high level, and where it is already present in your daily life puts you in a far stronger position — whether you are in technology, business, healthcare, education, or anywhere else.

Quick Recap

Here is everything we covered today:

AI has existed for decades in specialist forms — predictive analytics, optimisation engines, recommendation systems — long before ChatGPT made it mainstream
There are four types of analytics and AI: descriptive (what happened), predictive (what will happen), prescriptive (what should I do), and generative (what can I create)
You are already using AI every day — in spam filters, Netflix recommendations, bank fraud detection, voice assistants, and search engines
Generative AI like ChatGPT and Claude is powerful but requires critical thinking — it amplifies your capability rather than replacing your judgment
AI runs on Cloud infrastructure, is deployed using containers and Kubernetes, and is managed with Infrastructure as Code — it connects directly to everything in this series

What’s Next?

In Article 9 we are going deeper into Generative AI — how large language models actually work, what they are good at, where they fall short, and how to use them effectively in your daily work whether you are in technology or not.

We will also start to talk about something that is changing the industry right now — Agentic AI — AI that does not just answer questions but takes actions, makes decisions, and completes complex tasks on your behalf.

It is the most exciting topic in technology right now and Pipeline & Prompts is going to make it make sense.

See you in Article 9.

Written by Pipeline & Prompts | Byte size guides on DevOps, Cloud and AI

Found this useful? Share it with someone who thinks AI is brand new — and watch their reaction when they realise they have been using it for years. Follow along for a new article every week.

The Big Picture: How DevOps, Cloud and AI Are Converging — And What That Means for You

Nerav Doshi — Fri, 05 Jun 2026 22:38:08 +0000

Pipeline & Prompts | Byte size guides on DevOps, Cloud and AI

I Still Remember the Sound

Forklifts beeping in reverse.

Conveyor belts humming.

Cold warehouse air hitting my face as I stood on the floor of a Delphi plant in 2002.

I was staring at a maze of pallets, racks, and production lines, trying to redesign the entire material movement system. I had a chemical engineering degree, a head full of equations, and absolutely no idea how this moment would shape the next 20 years of my career.

Back then I believed something that held me back for years.

I thought I needed to know everything before I could start.

Turns out, that was completely wrong.

The Real Lesson I Learned (Much Later Than I Should Have)

After two decades moving through logistics, supply chain software, analytics, AI, Cloud, DevOps, and now writing Pipeline & Prompts, here is the truth I wish someone had told me on day one:

Your real advantage isn't the technology you know. It's your ability to understand problems deeply and translate them into solutions.

Everything else is learnable.

That single idea would have saved me years of stress, hesitation, and self-doubt.

From Warehouses to Whiteboards

A few years after Delphi, I found myself in a conference room at Menlo Worldwide. Whiteboards covered in arrows. Spreadsheets everywhere. Executives debating distribution strategy.

I wasn't the most technical person in the room.

I wasn't the most senior.

But I understood the system. I could see the bottlenecks. I could explain the trade-offs.

That skill — not a tool, not a certification — became my compass. It followed me everywhere.

From Supply Chain to Software to Cloud

Fast forward to IBM. Now I'm in front of customers, showing them how supply chain applications could solve problems they'd been wrestling with for years. I wasn't just demoing software — I was telling a story about their business.

Not because I knew every feature. Not because I had memorised every architecture diagram. But because I could connect dots others didn't see.

That's when it clicked.

Technology changes. Fundamentals don't.

Years later I was teaching workshops on data science platforms, running labs on machine learning, helping customers adopt hybrid cloud and OpenShift, and barely passing a containers certification I had spent six months grinding through. I was building Terraform infrastructure through trial and error and a lot of googling. I was staring at a Linux terminal on an AWS server, typing dir out of Windows habit.

If you told the version of me standing in that cold Delphi warehouse that I would one day be explaining Kubernetes, CI/CD pipelines, and Agentic AI to complete beginners on a blog I built myself — I would have laughed.

But every transition followed the same pattern. Start from zero. Learn the basics. Understand the problem. Apply the fundamentals.

The tools changed. The principles never did.

What We Have Covered — And Why It Fits Together

Over the past nine articles we built something deliberately. Not a random collection of topics but a connected foundation — each article building on the last, each concept making the next one easier to understand.

Here is the full picture.

DevOps is the culture and practice of bringing development and operations together to deliver software faster and more reliably. It is the philosophy that everything else in this series operates within.

Linux is the operating system that powers virtually all of it — every cloud server, every container, every Kubernetes node runs on Linux underneath.

Git is how every change — to application code and infrastructure code alike — is tracked, reviewed, and managed. It is the single source of truth that connects developers, operations teams, and automated systems.

Containers and Docker package applications into portable, consistent units that run the same way everywhere — eliminating the "works on my machine" problem that plagued software teams for decades.

CI/CD Pipelines automate the journey from a developer pushing code all the way to that code running in production — testing, building, and deploying without manual intervention.

Kubernetes manages containers at scale — keeping them running, scaling them up and down with demand, and healing them automatically when they fail.

Infrastructure as Code — Terraform and Ansible — means your entire cloud environment is defined in code, stored in Git, and reproducible on demand. No more tribal knowledge, no more configuration drift, no more environments that cannot be explained.

AI — from the predictive analytics tools that have existed for decades to the generative and agentic AI tools reshaping how we work today — runs on all of the above. Cloud infrastructure, containers, Kubernetes, CI/CD pipelines. AI is not separate from DevOps and Cloud. It is the next layer built on top of everything else.

This is the modern technology stack. And you now understand all of it.

The Fundamentals That Never Change

Here is something I have observed across twenty years of working through multiple technology shifts — from supply chain software to data science platforms to Cloud infrastructure to AI.

The tools change constantly. The fundamentals never do.

Systems thinking — the ability to understand how individual components interact within a larger whole — applies equally to a warehouse distribution network, a Kubernetes cluster, and an AI pipeline.

Communication — the ability to translate complexity into clarity — is as valuable in a boardroom as it is in a technical architecture review. Every article in this series was written around this principle.

Understanding the problem before the solution — this is the habit that separates good technologists from great ones. The best DevOps engineers, Cloud architects, and AI practitioners I have worked with all share this quality. They are not in love with the tools. They are in love with solving the right problem.

These fundamentals aged better than any platform, any language, any certification.

Certifications That Actually Mattered

I have taken many certifications. Some I barely passed. Some I forgot almost immediately. But a few genuinely changed how I think:

OpenShift and Containers — gave me hands-on intuition I could not have got any other way

IBM Cloud Pak for Data Architect — helped me see the full data and AI lifecycle end to end

Machine Learning with PyTorch — demystified AI and gave me genuine intuition about how models work under the hood

MIT Transportation Simulation — shaped my systems thinking mindset that I still apply to cloud architectures today

IBM Sales Academy — sharpened my ability to tell stories and influence decisions

The badge was never the value. The perspective was.

Your Non-Technical Background is an Advantage

If you come from logistics, finance, healthcare, retail, education, or any domain outside of traditional technology — lean into it. Do not apologise for it.

Technology does not exist in a vacuum. Every cloud infrastructure supports a business outcome. Every AI model solves a real world problem. Every DevOps pipeline delivers value to an end user.

The people who understand both the technology and the domain it operates in are rare and extraordinarily valuable. Your domain knowledge is your differentiator. Bring it with you.

The One Thing I Wish I Did Earlier

For years I taught workshops, spoke at conferences, trained teams, and helped customers — but I never shared my learning publicly.

If I had started writing earlier, if I had documented my journey, if I had shared even small insights — my growth would have accelerated tenfold.

Learning in public forces clarity. It builds community. It opens doors you did not know existed.

Starting Pipeline & Prompts is my way of finally doing that. And I wish I had done it a decade earlier.

If You Are Reading This and Wondering If You Can Break Into Tech

Maybe you are curious about Cloud. Maybe AI feels overwhelming. Maybe you are switching careers. Maybe you are starting from zero.

Here is the advice I wish someone had given me:

Start before you feel ready.
You will never feel fully prepared. Start anyway.

Don't chase tools — chase understanding.
Tools change. Principles don't.

Your background is an asset.
Whatever you have done before gives you an angle others don't have.

Learn in public.
Share what you are learning. Even small things. It compounds faster than anything else.

You absolutely can do this.
Tech isn't about perfection. It's about curiosity, persistence, and the willingness to learn.

If my journey proves anything it is this — you do not need a straight line to build a meaningful career in tech. You just need to keep moving toward the next interesting problem.

Quick Recap

Here is everything the series has covered:

Article 1 — DevOps: the culture that brings development and operations together
Article 2 — Linux: the operating system that powers the internet and the Cloud
Article 3 — Git: version control that tracks every change and powers CI/CD
Article 4 — Docker and Containers: portable, consistent application packaging
Article 5 — CI/CD Pipelines: automating the journey from code to production
Article 6 — Kubernetes: managing containers at scale across cloud environments
Article 7 — Infrastructure as Code: defining cloud environments in reproducible code
Article 8 — What is AI: from predictive analytics to generative models
Article 9 — Generative and Agentic AI: from answering questions to taking action

- Article 10 — The big picture: how it all connects and what it means for you

What's Next?

The foundation series is complete. But Pipeline & Prompts is just getting started.

Coming up we are going deeper — advanced Kubernetes patterns, real world Terraform projects, building with AI APIs, and the rapidly evolving world of Agentic AI and what it means for Cloud and DevOps professionals.

If you have made it through all ten articles — thank you. You have built a genuine foundation. You understand the modern technology stack better than most people who have been in the industry for years but never stopped to connect the dots.

Now it is time to build something with it.

Written by Pipeline & Prompts | Byte size guides on DevOps, Cloud and AI

If this series has been useful, share it with one person who is curious about technology but does not know where to start. That is exactly who it was written for. Follow along for a new article every week.

Linux: The Operating System That Runs the Internet

Nerav Doshi — Fri, 05 Jun 2026 22:38:03 +0000

Pipeline & Prompts | Byte size guides on DevOps, Cloud and AI

The Day I Realised Linux Was Everywhere

When I first started working in Cloud and Infrastructure, I assumed most servers ran Windows — because that's what I grew up using on my laptop. Then I got access to my first cloud environment and was greeted with a black screen, a blinking cursor, and absolutely no Start menu in sight.

That was my introduction to Linux.

I typed dir (the Windows command for listing files) and got an error. I tried clicking around and realised there was nothing to click. Just me, a terminal, and a lot to learn.

If that sounds familiar — or if you want to avoid that moment of panic entirely — this article is for you.

So What Actually is Linux?

Linux is an operating system, just like Windows or macOS. It controls the hardware of a computer and lets software run on top of it.

But here's the key difference. Linux is:

Free and open source — anyone can use it, modify it, and build on it
Lightweight — it runs efficiently even on minimal hardware
Incredibly stable — servers running Linux often go years without needing a restart

This is why Linux powers roughly 96% of the world's web servers. When you visit Google, stream on Netflix, or order on Amazon — you are talking to a Linux server.

In the Cloud world, virtually every virtual machine, container, and Kubernetes cluster runs on Linux. If you are going into DevOps or Cloud, Linux is not optional. It is the foundation everything else is built on.

The Terminal: Your New Best Friend

On Windows you point and click. On Linux, you type commands into a terminal — a text based interface that lets you control the system directly.

This feels scary at first. But think of it like learning keyboard shortcuts. Once you know them, you never want to go back to clicking through menus.

Here are the Linux commands every beginner must know. These are the ones I use almost every single day in Cloud and Infrastructure work:

Moving around the file system

pwd          # Shows where you currently are (Print Working Directory)
ls           # Lists files and folders in your current location
ls -la       # Lists everything including hidden files with details
cd /etc      # Change directory — navigate into a folder
cd ..        # Go back one level up

Working with files

touch notes.txt        # Create an empty file
mkdir my-project       # Create a new folder
cp notes.txt backup/   # Copy a file
mv notes.txt docs/     # Move a file (also used to rename)
rm notes.txt           # Delete a file (careful — no recycle bin!)
cat notes.txt          # Read the contents of a file

System information

whoami                        # Shows which user you are logged in as
df -h                         # Shows disk space usage
top                           # Live view of processes (like Task Manager)
ssh user@your-server-ip       # Connect to a remote cloud server
grep "error" logs.txt         # Search for specific text inside a file
tail -f /var/log/syslog       # Watch a log file update in real time

The Mistakes I See Beginners Make (And I Made Too)

Mistake 1: Using `rm -rf` without thinking

This command deletes files and folders instantly and permanently. There is no undo. I once watched a colleague accidentally delete an entire project directory because they ran it in the wrong folder. The command is useful but treat it like a chainsaw — powerful, and dangerous if you are not paying attention.

Mistake 2: Ignoring file permissions

Linux has a strict permissions system that controls who can read, write, or run a file. When something is not working and you can not figure out why, nine times out of ten in Cloud environments it is a permissions issue. Learn the chmod and chown commands early.

Mistake 3: Thinking the terminal is only for experts

The terminal looks intimidating but it is just a different way of talking to your computer. Every command you run is simply an instruction in plain English abbreviated. ls = list. cd = change directory. pwd = print working directory. Once you see the pattern, it clicks.

How Linux Connects to DevOps and Cloud

Everything in the DevOps world sits on top of Linux:

Docker containers run on a Linux kernel. When you spin up a container — whether on your laptop or in the cloud — it is using Linux underneath even if your laptop runs Windows or Mac.

Cloud servers on AWS, Azure, and Google Cloud are almost always Linux by default. When you launch a virtual machine in AWS, the most common choice is Amazon Linux or Ubuntu — both Linux distributions.

CI/CD pipelines — the automated systems that test and deploy your code — run their jobs inside Linux environments. The scripts you write, the tools you install, the paths you reference — all Linux.

Kubernetes — the container orchestration platform we will cover later in this series — is built entirely around Linux concepts. Understanding how Linux handles processes, networking, and file systems makes Kubernetes far less mysterious.

In short, Linux is not just one skill. It is the lens through which all of DevOps and Cloud makes more sense.

Try It Right Now — No Installation Needed

You do not need to install anything to start practising Linux today. Use one of these free browser based tools:

Play with Docker — gives you a free Linux terminal in your browser
JSLinux — a Linux environment running entirely in your browser
Replit — create a free account and open a bash terminal

Open one of these, try the commands from this article, and see what happens. The best way to learn Linux is simply to use it.

Quick Recap

Here is what we covered today:

Linux is the operating system that powers 96% of web servers and virtually all cloud infrastructure
The terminal is how you control Linux — it feels scary but becomes second nature quickly
The essential commands are ls, cd, pwd, mkdir, cp, mv, rm, and cat
Common beginner mistakes include using rm -rf carelessly and ignoring file permissions
Linux is the foundation of Docker, Cloud, CI/CD, and Kubernetes — everything we will cover in this series

What's Next?

← Previous: What is DevOps? A Plain English Guide

Next up: Git — The Tool That Saves Your Code and Your Career — the tool that tracks every change ever made to your code and lets teams collaborate without stepping on each other's work.

I'll also share the story of how I accidentally committed directly to the main branch early in my Cloud career and nearly triggered a production deployment. It's a mistake almost everyone makes once — and after reading Article 3, you'll never make it.

Found this useful? Share it with someone just getting started in tech and follow along for a new article every week.

Kubernetes: The Platform That Keeps the Internet Running at Scale

Nerav Doshi — Fri, 05 Jun 2026 22:29:49 +0000

Pipeline & Prompts | Byte size guides on DevOps, Cloud and AI

From Supply Chain to Container Orchestration

When IBM acquired Red Hat, I was working as a technical seller trying to position IBM’s data science platform to clients. Our internal team was containerising CPLEX — a powerful optimisation engine used in warehouse management and supply chain applications — and running it on OpenShift.

I had seen CPLEX solve complex scheduling problems in the real world. I understood inputs, equations, constraints, and outputs. But pods? Nodes? Dockerfiles? It felt like a science project. I could not connect what I was seeing on screen to anything that could work in real production.

It took six months of trial, error, and grinding through an OpenShift certification I barely passed to get any footing at all.

What finally made it click was sitting with a teammate on a real internal project — converting an actual application into containers. That hands-on experience is when I finally understood the most important idea in Kubernetes: breaking software into small independent pieces and understanding how those pieces talk to each other.

Networking still gives me headaches to this day. But that is a story for later in this article.

So What Problem Does Kubernetes Actually Solve?

In Article 4 we talked about containers — how they package your application into a portable, consistent unit that runs the same way everywhere. If you have not read that one yet, it is worth a quick look before continuing here.

Now imagine your application becomes popular. Really popular.

One container running on one server handled things fine when you had a hundred users. But now you have a hundred thousand users. You need dozens of containers running simultaneously. Some containers crash and need to be restarted. Traffic spikes on Monday mornings and drops on weekends, so you need more containers sometimes and fewer at others. You need to update your application without taking it offline.

Managing all of that manually would be a full time job for a large team. You would spend every hour watching containers, restarting crashed ones, spinning up new ones during busy periods, and taking things offline every time you needed to update.

Kubernetes automates all of that.

You tell Kubernetes what you want — “keep ten copies of this container running at all times, and if any of them crash, restart them automatically” — and Kubernetes makes it happen. It watches your containers constantly, heals them when they break, scales them up and down based on demand, and distributes traffic evenly across all of them.

It is like having a highly organised operations team working around the clock — except it never sleeps, never takes a day off, and reacts in milliseconds.

The Concepts That Confused Me (Explained Simply)

When I first encountered Kubernetes the terminology was one of the biggest barriers. Here are the key concepts explained in plain English — the way I wish someone had explained them to me.

Cluster The whole Kubernetes environment. Think of it as your warehouse — the building that contains everything. Inside the warehouse you have different sections, workers, and systems all working together.

Node A single server inside your cluster. Think of it as a shelf unit inside the warehouse. Your cluster will typically have multiple nodes — multiple shelf units — so that if one fails, the others keep running.

Pod The smallest unit in Kubernetes. A pod is essentially a running container — or sometimes a small group of containers that always work together. Think of a pod as a single box sitting on a shelf. It contains your application and everything it needs to run.

This is the concept that took me longest to understand. In the CPLEX project, I kept asking — if a container is already a packaged unit, why do we need a pod? The answer is that a pod gives Kubernetes a consistent way to manage, monitor, and communicate with your containers regardless of what is inside them.

Deployment A set of instructions that tells Kubernetes how many copies of your pod to run and how to update them. If you want ten copies of your application running, you define a deployment and Kubernetes takes care of the rest — including restarting any that crash.

Service This is where networking comes in — and where my headaches begin. A service is how pods communicate with each other and with the outside world. Because pods are temporary — they get created and destroyed constantly — you cannot rely on a pod having a fixed address. A service gives you a stable address that always routes traffic to the right place regardless of which pod is actually handling it.

Think of it like a customer service phone number. The number stays the same even when different agents are answering the calls.

Namespace A way of dividing your cluster into separate sections for different teams or applications. Think of it as different departments inside the warehouse — each with their own space, their own rules, and their own resources.

How Kubernetes Connects to Everything in This Series

If you have been following along since Article 1, Kubernetes is where everything comes together.

Linux is the operating system every Kubernetes node runs on. Every pod, every container, every networking rule — it all sits on Linux underneath.

Git is where your Kubernetes configuration files live. Every deployment, every service, every namespace is defined in YAML files stored in GitHub. Change a file, push to Git, and your pipeline picks it up.

Docker and containers are what Kubernetes manages. Every pod runs a container image built with Docker or Podman. Without containers there is nothing for Kubernetes to orchestrate.

CI/CD pipelines are how new versions of your application get into Kubernetes. A developer pushes code, GitHub Actions builds a new container image, and ArgoCD syncs the new image into your Kubernetes cluster automatically.

This is the complete modern DevOps loop. Code → Git → Pipeline → Container → Kubernetes → Live application.

The Managed Kubernetes Platforms You Will Encounter

Nobody runs Kubernetes completely from scratch in production. The major cloud providers offer managed Kubernetes services that handle the complex underlying infrastructure for you — so you can focus on running your applications rather than managing servers.

EKS — Amazon Elastic Kubernetes Service AWS’s managed Kubernetes platform and one of the most widely used in the industry. EKS handles the Kubernetes control plane for you and integrates tightly with AWS services like IAM for security, ECR for container images, and CloudWatch for monitoring.

AKS — Azure Kubernetes Service Microsoft Azure’s managed Kubernetes offering. AKS integrates naturally with Azure Active Directory, Azure Monitor, and Azure DevOps — making it a strong choice for organisations already in the Microsoft ecosystem.

GKE — Google Kubernetes Engine Google’s managed Kubernetes service and arguably the most mature of the three — Kubernetes was originally created at Google. GKE is known for being smooth to use and deeply integrated with Google Cloud services.

OpenShift — Red Hat’s Enterprise Kubernetes Platform OpenShift is Kubernetes with a significant layer of enterprise features built on top — stricter security defaults, a built in developer workflow, and deep Red Hat tooling integration. It is the platform I spent six months wrestling with and the one most common in large enterprises, regulated industries, and organisations that came from the IBM and Red Hat ecosystem.

OpenShift is more opinionated than vanilla Kubernetes — it makes certain decisions for you in the name of security and consistency. That is a strength in enterprise environments. It is also why it can feel harder to get started with than EKS or AKS.

The Thing That Still Surprises People

When I explain Kubernetes to people outside of IT, the thing that surprises them most is this: Kubernetes does not care what your application does.

It does not know if it is running a banking system, a streaming platform, a supply chain optimiser, or a simple website. It just knows that you want a certain number of containers running, kept healthy, and able to communicate with each other.

That universality is what makes it so powerful. The same platform that runs Netflix’s recommendation engine runs a small startup’s first web application. The same concepts, the same commands, the same mental model — just at different scales.

Be Patient With Yourself

If you are reading this and feeling like some of it is still fuzzy — that is completely normal. Kubernetes has a famously steep learning curve. I spent six months on it before things started clicking, and I still learn something new regularly.

The key is the same lesson that got me unstuck — get hands on with something real. Do not just read about pods and services. Spin up a free cluster, deploy something simple, and watch it run. The moment you see Kubernetes automatically restart a crashed container for the first time, the whole thing suddenly makes sense in a way no article can fully convey.

Quick Recap

Here is everything we covered today:

Kubernetes solves the problem of managing many containers across many servers at scale — automatically healing, scaling, and updating them
The key concepts are clusters, nodes, pods, deployments, services, and namespaces
Kubernetes connects everything in this series — Linux, Git, containers, and CI/CD pipelines all come together here
The managed platforms you will encounter in real Cloud work are EKS, AKS, GKE, and OpenShift
The most important idea in Kubernetes is breaking your application into small independent pieces that communicate with each other — microservices

What’s Next?

We have now covered the full DevOps foundation — from what DevOps is, through Linux, Git, containers, CI/CD pipelines, and Kubernetes.

In Article 7 we are moving into the Cloud — starting with Infrastructure as Code and Terraform, the tool that lets you define and manage your entire cloud environment in code rather than clicking through dashboards.

If you have ever spun up a server manually and then had no idea how to recreate it, Article 7 is going to make your life considerably easier.

See you there.

Written by Pipeline & Prompts | Byte size guides on DevOps, Cloud and AI

Found this useful? Share it with someone who has been hearing the word Kubernetes for years and never quite understood what it means. Follow along for a new article every week.

Git: The Tool That Saves Your Code and Your Career

Nerav Doshi — Fri, 05 Jun 2026 22:29:46 +0000

Pipeline & Prompts | Byte size guides on DevOps, Cloud and AI

The Day I Nearly Broke Production

Early in my Cloud career, I was making what I thought was a small change to a configuration file. I'd been working on it locally, testing it, feeling confident. Then I committed and pushed — straight to the main branch.

Within seconds, a CI/CD pipeline picked up the change and started deploying it to production. My phone buzzed with an alert. My colleague looked over and said, very calmly, "Did you just push to main?"

I had. And the automated pipeline was already rolling it out.

We caught it in time. Barely. But that day I learned two things: first, that Git branching matters. And second, that understanding Git isn't optional if you work anywhere near production systems.

This article is the guide I wish I'd had before that moment.

What is Git?

Git is a version control system. In plain English, it tracks every change ever made to your code — who made it, when, and why.

Think of it like Google Docs' version history, but for code. Every time you save a meaningful change, Git records a snapshot. You can go back to any previous version, see exactly what changed, and undo mistakes.

But Git does more than just track changes. It lets multiple people work on the same codebase at the same time without overwriting each other's work. In a world where software teams can have dozens or even hundreds of developers, this is essential.

Every DevOps pipeline, every cloud deployment, every infrastructure change — it all starts with Git.

The Core Concepts

Before we get into commands, let's understand the key ideas:

Repository (repo) — A project folder tracked by Git. It contains your code and the entire history of changes.

Commit — A saved snapshot of your changes. Think of it as a checkpoint. Each commit has a message describing what changed and why.

Branch — A parallel version of your code. The main branch is the official version. You create new branches to work on features or fixes without affecting main.

Merge — Combining changes from one branch into another. When your feature is ready, you merge it into main.

Pull Request (PR) — A request to merge your branch into main. In teams, someone reviews your changes before they go in. This is where mistakes get caught — the step I skipped on the day I nearly broke production.

Essential Git Commands

Here are the commands you'll use constantly:

Setting up

git init                    # Start tracking a folder with Git
git clone <url>             # Download a repository from GitHub

Daily workflow

git status                  # See what's changed
git add .                   # Stage all changes for the next commit
git commit -m "message"     # Save a snapshot with a description
git push                    # Upload your commits to GitHub
git pull                    # Download the latest changes from GitHub

Branching

git branch feature-login    # Create a new branch
git checkout feature-login  # Switch to that branch
git checkout -b feature-login  # Create and switch in one command
git merge feature-login     # Merge a branch into your current branch

Seeing history

git log                     # View commit history
git log --oneline           # Compact view of commits
git diff                    # See what changed since the last commit

The Two Biggest Beginner Mistakes

Mistake 1: Working directly on main

This is exactly what I did. The main branch should always contain working, production-ready code. Never make changes directly on main. Instead:

Create a new branch
Make your changes there
Open a pull request
Get it reviewed
Then merge

This workflow exists for a reason — it's the safety net between your code and production.

Mistake 2: Writing useless commit messages

Bad commit messages:

"fixed stuff"
"update"
"asdfgh"

Good commit messages:

"Fix login timeout by increasing session duration to 30min"
"Add error handling for failed API responses"
"Update Kubernetes deployment to use image v2.3.1"

Your future self — and your teammates — will thank you when they're trying to understand why a change was made six months from now.

How Git Connects to CI/CD Pipelines

This is where Git goes from "useful tool" to "essential infrastructure."

In a modern DevOps workflow, Git isn't just where you store code — it's the trigger for everything that happens next:

You push code to a Git repository
A CI/CD pipeline automatically detects the change
The pipeline builds your application
It runs automated tests
If everything passes, it deploys to production

That's why my push to main was so dangerous. The pipeline was watching main for changes and automatically deploying whatever landed there. No human review. No safety check. Just straight to production.

Here's a simplified GitHub Actions example:

name: Deploy on Push
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: npm install
      - run: npm test
      - run: npm run deploy

Every push to main triggers this pipeline. That's powerful — and exactly why you need branch protection and pull requests.

Git for Infrastructure (Infrastructure as Code)

Here's something that surprises many beginners: Git isn't just for application code.

In modern Cloud and DevOps, your infrastructure is defined as code too. Server configurations, network settings, Kubernetes deployments — all written as code files and stored in Git.

This means:

Every infrastructure change is tracked and auditable
You can review changes before they're applied
You can roll back if something breaks
Multiple team members can collaborate on infrastructure safely

Tools like Terraform, Ansible, and Kubernetes manifests all live in Git repositories. The same branching and pull request workflow applies.

Quick Recap

Here's everything we covered:

Git tracks every change to your code — who made it, when, and why
Branches let you work on changes without affecting the main codebase
Pull requests are the safety net between your code and production
The essential commands: git clone, git add, git commit, git push, git pull, git branch, git merge
Git triggers CI/CD pipelines — a push to main can automatically deploy to production
Infrastructure as code lives in Git too, making all infrastructure changes trackable and reversible

What's Next?

← Previous: Linux: The OS That Runs the Internet

Next up: What Are Containers? — We'll look at how Docker packages applications so they run the same way everywhere, and I'll share the moment when a shipping container analogy finally made it all click.

Found this useful? Share it with someone just starting their DevOps journey and follow along for a new article every week.

CI/CD Pipelines: How Your Code Goes from a Laptop to the Real World

Nerav Doshi — Fri, 05 Jun 2026 13:19:00 +0000

Pipeline & Prompts | Byte size guides on DevOps, Cloud and AI

The First Time I Saw a Pipeline Run

I still remember the first time I watched a CI/CD pipeline run from start to finish.

A developer pushed their code to GitHub. Within seconds, a series of automated steps fired off on their own — tests ran, the application was packaged into a container, and it was deployed to a live environment. Nobody pressed a button. Nobody sent an email saying “please deploy this.” It just happened.

My first reaction was: this looks incredibly simple. A few lines in a YAML file, push some code, and everything just happens on its own. I genuinely thought — how hard can this be?

Then I tried to set one up myself in OpenShift.

What followed was hours of staring at cryptic error messages, pipelines that failed for reasons that made no sense, permissions that were wrong in ways I could not explain, and configuration files where a single misplaced space broke everything. I am not exaggerating when I say that one missing environment variable cost me an entire afternoon.

The humbling truth about CI/CD pipelines is that they look effortless when someone else has already built them. The first time you build one yourself — especially in an enterprise environment like OpenShift — you quickly discover there is a lot happening behind those few lines of YAML.

But here is what I want you to take away from that experience: the concept really is simple. The frustration comes from the setup details, not from the idea itself. And once you understand what a pipeline actually does and why, those error messages start to make a lot more sense. So let us start from the very beginning — no IT background required.

Let’s Start With a Real World Analogy

Imagine you work at a bakery. Every morning you follow the same process:

Mix the ingredients
Bake the bread
Check the bread is cooked properly
Package it up
Deliver it to the shop

You do those same five steps every single day, in the same order, without skipping any of them. Because if you skip step 3 and the bread is not cooked, customers get raw dough. If you skip step 4, the bread gets damaged in transit.

Now imagine you could automate that entire process. Every morning, the moment the ingredients arrive, a machine mixes them, bakes them, checks them, packages them, and delivers them — automatically, consistently, without anyone having to remember the steps.

That is exactly what a CI/CD pipeline does for software.

Every time a developer saves their code, the pipeline automatically runs through a set of steps — testing the code, building the application, and delivering it to users. Same steps, every time, no human error.

What Does CI/CD Actually Stand For?

CI — Continuous Integration

This is the first half of the pipeline. Every time a developer adds new code, it is automatically merged with everyone else’s code and tested immediately. The goal is to catch problems early — before they grow into big expensive disasters.

Think of it like a spell checker that runs the moment you finish typing a sentence, rather than waiting until you have written the entire document.

CD — Continuous Delivery or Continuous Deployment

This is the second half. Once the code passes all the tests, it is automatically prepared and delivered to production — the live environment that real users interact with.

Continuous Delivery means the code is ready to deploy at the push of a button. Continuous Deployment goes one step further — it deploys automatically with no human involvement at all.

Together, CI/CD turns what used to be a stressful, manual, error-prone process into something that happens quietly and reliably in the background dozens of times a day.

A Day in the Life of a Pipeline

Here is what actually happens when a developer pushes code. Let us walk through it step by step in plain English:

Step 1 — Code is pushed to GitHub
A developer finishes their work and pushes it to a branch on GitHub. This single action wakes the pipeline up.

Step 2 — Tests run automatically
The pipeline runs a series of automated checks. Does the code work? Does it break anything that was already working? Does it meet the team’s quality standards? If anything fails, the pipeline stops and alerts the developer immediately.

Step 3 — The application is built and packaged
If all tests pass, the pipeline packages the application — often into a Docker container as we covered in Article 4 — ready to be deployed.

Step 4 — Deployment to a test environment
The packaged application is deployed to a staging environment first — a copy of production where the team can do a final check before it goes live.

Step 5 — Deployment to production
Once everything looks good, the pipeline deploys to the live environment that real users are using. Done. No late night deployment calls, no manual steps, no crossed fingers.

The whole process can take minutes. And it happens the same way every single time.

The Tools That Make It Happen

GitHub Actions

GitHub Actions is built directly into GitHub — the platform where most developers store their code. It is the tool I use most and the one that genuinely impressed me when I first saw it in action.

You define your pipeline in a simple file called a workflow, and GitHub takes care of the rest. Here is a real example that shows exactly what a basic pipeline looks like:

# .github/workflows/pipeline.yml
name: Build, Test and Deploy

on:
  push:
    branches:
      - main

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - name: Get the code
        uses: actions/checkout@v3

      - name: Run tests
        run: npm test

      - name: Build container image
        run: docker build -t my-app:latest .

      - name: Deploy to production
        run: ./deploy.sh

In plain English this says: every time someone pushes to the main branch, get the latest code, run the tests, build the container, and deploy it. That is your entire pipeline in about fifteen lines.

The first time I set one of these up and watched it run on its own, it felt like automation magic. The frustrating hours came later — when something broke and I had to figure out why. But that is a story for another day.

ArgoCD

If GitHub Actions is the engine that builds and tests your code, ArgoCD is the specialist that handles the deployment side — particularly in Kubernetes environments like OpenShift, EKS, or AKS.

ArgoCD watches your GitHub repository and automatically keeps your live environment in sync with whatever is in your code. If you change a configuration file in GitHub, ArgoCD notices and updates your running application to match.

This approach is called GitOps — using Git as the single source of truth for both your application and your infrastructure. We mentioned this briefly in Article 3. ArgoCD is one of the most popular tools that puts GitOps into practice.

In my experience, ArgoCD is genuinely elegant once it is set up correctly. Getting it set up correctly — especially in OpenShift — is where the hours disappear. But when it works, watching it automatically sync your deployments is deeply satisfying.

Why This Matters Even If You Are Not a Developer

You might be reading this thinking — I am not a developer, why does any of this matter to me?

Here is why.

Every digital product you use — your banking app, your food delivery service, your streaming platform — is updated constantly. New features, bug fixes, security patches. Without CI/CD pipelines, every one of those updates would require a team of people to manually test, package, and deploy the changes. It would be slow, expensive, and full of human error.

CI/CD pipelines are why your banking app can add a new feature on a Tuesday without taking the whole system down. They are why Netflix can update its recommendation algorithm without you ever noticing any disruption. They are the invisible infrastructure that keeps the digital world running smoothly.

Understanding CI/CD does not require you to be able to build one from scratch. But knowing what it is and why it exists makes you a far more informed collaborator in any technology team — whether you are in product, operations, finance, or leadership.

The Things Nobody Tells You About Pipelines

Since we are keeping it real on this blog, here are a few honest truths about CI/CD that tutorials often leave out:

Pipelines break. A lot. Especially when you are first setting them up. A missing environment variable, a wrong file path, a version mismatch — any of these can bring a pipeline down and leave you staring at error logs. This is normal. Every engineer has been there.

Start simple. The most common mistake beginners make is trying to build the perfect pipeline on day one. Start with just two steps — run the tests and deploy. Add complexity gradually once the basics are working reliably.

Read the logs. When a pipeline fails, the answer is almost always in the logs. Learning to read pipeline error output quickly is one of the most valuable skills you can develop. It is not glamorous but it will save you hours.

Quick Recap

Here is everything we covered today:

CI/CD stands for Continuous Integration and Continuous Deployment — it automates the process of testing and delivering software
Every time a developer pushes code, the pipeline automatically tests it, packages it, and deploys it — no manual steps required
GitHub Actions is the most beginner friendly pipeline tool and lives directly inside GitHub
ArgoCD handles the deployment side in Kubernetes environments and powers GitOps workflows
CI/CD pipelines are not just for developers — they are the infrastructure behind every digital product you use every day

What’s Next?

We have now covered DevOps, Linux, Git, Docker, and CI/CD pipelines. You have the full foundation.

In Article 6 we are going to talk about Kubernetes — the platform that manages all those containers we built in Article 4 at massive scale. We will cover what it actually is, why the industry adopted it so quickly, and how EKS, AKS, GKE and OpenShift fit into the picture.

See you in Article 6.

Written by Pipeline & Prompts | Byte size guides on DevOps, Cloud and AI

Found this useful? Share it with someone — in tech or not — who has ever wondered how apps get updated without anyone noticing. Follow along for a new article every week.

Generative AI and Agentic AI: From Answering Questions to Taking Action

Nerav Doshi — Fri, 05 Jun 2026 13:12:03 +0000

Pipeline & Prompts | Byte size guides on DevOps, Cloud and AI

The Meeting That Changed How I Prepare

I used to spend hours before important workshops and client meetings pulling together materials. Downloading presentation decks, saving links, reading through documents, trying to hold enough in my head to answer questions confidently in the room.

Then I discovered NotebookLM.

NotebookLM is a generative AI tool from Google that lets you upload your own documents, presentations, and links and then have a conversation with all of that material as if it were a knowledgeable colleague who had read everything perfectly.

Before a recent conference I uploaded every presentation, every link, every document related to the topics being discussed. Then during the event, when someone asked me a question I was not sure about, I could query my own private knowledge base in seconds and get a precise answer drawn directly from the materials I had loaded.

I also started using generative AI to write meeting agendas, workshop plans, and to evaluate presentation slides before I delivered them — asking the AI to critique the flow, identify gaps, and suggest improvements the way a trusted colleague might.

The difference in how I work before and after generative AI is not subtle. It is significant.

And I am only just getting started with what comes next.

A Quick Recap — Where We Left Off

In Article 8 we covered the four types of AI — descriptive, predictive, prescriptive, and generative — using Google Maps as our guide. We talked about how generative AI like ChatGPT and Claude can create new content — text, code, images — rather than just analysing existing data.

In this article we are going deeper into two things:

Generative AI — how it actually works, what it is genuinely good at, and where it still falls short
Agentic AI — the next frontier, where AI does not just answer questions but takes actions and completes complex tasks on your behalf

How Generative AI Actually Works — In Plain English

A Large Language Model — or LLM — is the technology behind ChatGPT, Claude, Gemini, and most of the generative AI tools you encounter today.

Here is how to think about how it was built.

Imagine reading every book, every article, every website, every piece of code ever written — billions and billions of words. As you read, you start to notice patterns. Certain words appear together. Certain sentence structures follow certain ideas. Certain concepts are always explained in similar ways. Over time you develop an incredibly deep intuition for language — not because you memorised everything, but because you absorbed the patterns.

That is essentially what happens when an LLM is trained. It processes an almost incomprehensibly large amount of text and learns the statistical patterns of language — which words follow which words, which ideas connect to which concepts, how questions are typically answered.

When you ask it a question it does not look up the answer in a database. It generates a response word by word, each word chosen based on what is most likely to come next given everything it has learned. This is why it feels like a natural conversation — because it is built on the patterns of natural human communication.

It is also why hallucinations happen. The model is always generating what is most likely — not necessarily what is true. If the patterns in its training data point toward a plausible but incorrect answer, that is what it produces with complete confidence.

Understanding this does not make LLMs less useful. It makes you a better user of them.

What Generative AI is Genuinely Good At

Drafting and communication
First drafts of emails, reports, agendas, presentations, and proposals. Generative AI is extraordinarily fast at producing a solid starting point that you then refine. The key word is starting point — your judgment, your knowledge, and your voice still matter.

Explaining complex things simply
Ask an LLM to explain a concept as if you are a complete beginner and it will almost always produce a clearer explanation than most textbooks. This is one of its most underrated uses — using it as a patient, infinitely available teacher.

Code review and debugging
As I shared in Article 8, using AI to review Terraform code as a beginner was genuinely transformative. It applies the pattern recognition of someone who has seen thousands of codebases to your specific code. GitHub Copilot does this in real time as you type.

Summarising and synthesising
Upload a long document, a set of meeting notes, or a collection of links and ask for a summary. NotebookLM does this particularly well because it works only with the materials you provide — so the answers are grounded in your specific content rather than general training data.

Brainstorming and thinking partners
Some of the most valuable AI interactions are not about getting an answer but about thinking through a problem. Describe a challenge you are facing, ask the AI to push back on your assumptions, and you often end up with a clearer view of the problem than when you started.

Where Generative AI Still Falls Short

Since we keep it honest on this blog:

Hallucinations are real. AI models can generate confident, detailed, completely wrong answers. Always verify important facts, especially anything involving numbers, dates, specific technical details, or legal and medical information. Critical thinking is not optional.

It does not know what it does not know. An LLM will rarely say “I have no idea.” It will generate something that sounds plausible. The less common or more specialised your question, the more carefully you need to evaluate the response.

Context has limits. Most LLMs can only hold a certain amount of conversation in their working memory at once. Very long or complex projects can lose earlier context in ways that affect the quality of later responses.

It has no real world awareness. A standard LLM does not know what happened yesterday, cannot access your company’s internal systems, and cannot take action in the world on your behalf.

That last limitation is exactly what Agentic AI is designed to solve.

What is Agentic AI?

Every AI tool we have discussed so far follows the same basic pattern. You ask a question. The AI answers. You ask another question. It answers again. Each interaction is a single exchange.

Agentic AI breaks that pattern.

An AI agent does not just answer a question — it takes a goal, breaks it down into steps, uses tools and external systems to complete those steps, learns from what it finds along the way, and delivers a completed result.

Think of the difference between asking a colleague a question and delegating a task to them.

Asking a question: “What flights are available from London to New York next Tuesday?”
Delegating a task: “Book me the best value flight from London to New York next Tuesday, add it to my calendar, and email the confirmation to my team.”

The first is what current generative AI does. The second is what agentic AI does — or is rapidly learning to do.

A Real World Agentic AI Example — n8n

I am currently experimenting with n8n — an open source workflow automation tool that lets you connect AI to real world actions and systems.

With n8n you can build workflows where AI is not just thinking but doing. For example:

Monitor your email inbox, identify action items using AI, and automatically create tasks in your project management tool
Watch a folder for new documents, summarise each one with AI, and post the summary to a Slack channel
Pull data from multiple sources, have AI analyse it, and generate a weekly report that gets emailed automatically

Here is a simple example of what an n8n workflow looks like conceptually:

Trigger: New email arrives
   ↓
Step 1: AI reads the email and classifies it
   ↓
Step 2: If it contains an action item → create a task
Step 3: If it is a meeting request → check calendar and respond
Step 4: If it is a document → summarise and file it
   ↓
Result: Inbox managed automatically

I am still in the early stages of building with n8n — it is a genuine work in progress. But even at this early stage the potential is clear. Tasks that used to require human attention for every individual item can be handled automatically, consistently, and at a scale no individual could match.

The Spectrum From Assistant to Agent

It helps to think of AI capability as a spectrum rather than a binary on/off:

Level 1 — AI Assistant
Answers questions, generates content, reviews code. You drive every interaction. ChatGPT and Claude in basic use are here.

Level 2 — AI with Tools
The AI can search the web, read documents, run code, and access external data to give better answers. Claude with web search enabled, NotebookLM, and GitHub Copilot are here.

Level 3 — AI Workflow Automation
The AI completes multi step tasks using connected tools and systems. n8n workflows with AI, Zapier with AI integration, and similar tools are here. This is where I am currently experimenting.

Level 4 — Fully Autonomous AI Agents
The AI receives a high level goal and figures out how to achieve it independently — planning, executing, adapting, and reporting back. This is where the industry is heading and where the most significant questions about oversight and control are being asked.

We are moving along this spectrum faster than most people realise.

How Agentic AI Connects to Cloud and DevOps

In Cloud and Infrastructure work, agentic AI is beginning to appear in ways that will fundamentally change the role of the DevOps engineer.

Automated incident response — AI agents that monitor your Kubernetes cluster, detect an anomaly, diagnose the likely cause, apply a fix, and log the resolution — without waking anyone up at 3am.

Self healing infrastructure — Terraform configurations that AI can review, update, and apply in response to changing requirements or detected drift — the configuration drift problem we talked about in Article 7, solved autonomously.

Intelligent CI/CD pipelines — Pipelines that do not just run fixed steps but adapt based on what they find. If a test fails, the agent analyses why, suggests a fix, and in some cases applies it automatically.

AI assisted cloud cost optimisation — Agents that continuously monitor your cloud spend, identify wasteful resources, and make recommendations or take action to reduce costs without manual review.

None of this is fully here yet in the way the marketing materials sometimes suggest. But the direction is clear and the pace of change is faster than anything I have seen in a decade of working in Cloud and Infrastructure.

The Question Everyone Should Be Asking

As AI becomes more capable of taking action — not just giving advice — the most important skill is not knowing how to use AI. It is knowing when to trust it, when to verify it, and when to keep a human in the loop.

The engineers and professionals who will thrive in an agentic AI world are not the ones who hand everything to the AI and walk away. They are the ones who understand what the AI is doing well enough to catch it when it goes wrong and to guide it toward genuinely useful outcomes.

That combination of AI capability and human judgment is going to be the most valuable professional skill of the next decade.

Quick Recap

Here is everything we covered today:

Generative AI works by learning statistical patterns from vast amounts of text and generating responses word by word — which is why it is fluent but sometimes wrong
It excels at drafting, explaining, summarising, code review, and thinking partnership — tools like NotebookLM make it even more powerful when grounded in your own materials
Hallucinations are real — critical thinking and verification remain essential
Agentic AI goes beyond answering questions to taking actions — completing multi step tasks using tools, external systems, and autonomous decision making
Tools like n8n let you build agentic workflows today even as a beginner
In Cloud and DevOps, agentic AI is beginning to reshape incident response, infrastructure management, and CI/CD pipelines
The most valuable skill in an AI world is the combination of AI capability and human judgment

What’s Next?

We have now covered the full Pipeline & Prompts foundation — from DevOps and Linux all the way through to Generative and Agentic AI.

In Article 10 we are going to zoom out and look at the big picture — how DevOps, Cloud, and AI are converging into a single discipline and what that means for anyone building a career in technology right now.

We will also talk about where to go next on your learning journey — the resources, the certifications, and the hands on projects that will take you from understanding these concepts to actually building with them.

The foundation is laid. Now it is time to build.

See you in Article 10.

Written by Pipeline & Prompts | Byte size guides on DevOps, Cloud and AI

Found this useful? Share it with someone who thinks AI is just a chatbot — and show them how much further it has already come. Follow along for a new article every week.

What is DevOps? A Plain English Guide for Beginners

Nerav Doshi — Sat, 30 May 2026 14:05:22 +0000

Ever Wondered How Netflix Never Seems to Go Down?

Think about this for a second. Netflix has over 260 million subscribers worldwide. People are watching shows in Tokyo, London, Lagos, and New York — all at the same time. And yet, when was the last time Netflix crashed on you?

Now think about your favourite food delivery app. You open it, order food, track your driver in real time, and get a notification the moment your burger arrives. All of that happens in seconds.

Behind all of this is a way of working called DevOps. And by the end of this article, you'll understand exactly what it is — no jargon, no complicated diagrams, just plain English.

The Old Way (And Why It Was a Nightmare)

To understand DevOps, we first need to understand the problem it solved.

Imagine a software company in the early 2000s. They had two completely separate teams:

The Developers — the people who wrote the code and built new features

The Operations team — the people who managed the servers and kept everything running

These two teams barely talked to each other. Developers would spend months building new features, then hand over a massive pile of code to the operations team and say "here you go, make it work."

The operations team would panic. They hadn't been involved in building it, had no idea what it did, and now they had to deploy it to millions of users without breaking anything.

The result? Deployments took weeks. Bugs slipped through. Systems crashed. Customers complained. And the two teams blamed each other.

Sound stressful? It was.

So What is DevOps?

DevOps is simply the practice of bringing developers and operations teams together to build, test, and release software faster and more reliably.

The name itself is a combination of Dev (Development) and Ops (Operations). Instead of two teams working in silos, they work as one team with shared goals, shared tools, and shared responsibility.

Think of it like a restaurant kitchen.

In a badly run kitchen, the chefs cook the food and just slide it through a hatch to the waiters. The waiters don't know what's in the dish, the chefs don't know what the customers are saying, and when something goes wrong, everyone points fingers.

In a well run kitchen — like the ones you see at a great restaurant — the chefs and waiters communicate constantly. They know the menu inside out, they get feedback from customers quickly, and they work as one team to give people a great experience.

DevOps is that well run kitchen, but for software.

A Real World Example: Amazon

Amazon deploys new code to its website thousands of times per day.

That means engineers are constantly making small improvements — fixing a bug here, improving the checkout experience there, tweaking a recommendation — and those changes go live almost instantly.

How? Because Amazon uses DevOps practices. Small changes are automatically tested, automatically checked for problems, and automatically deployed without anyone having to manually press a button.

In the old way of working, those same changes might have taken weeks to go live, gone through five teams, and required a late night deployment session that everyone dreaded.

The Three Big Ideas Behind DevOps

You don't need to memorise these, but it helps to know the thinking behind DevOps.

1. Work in Small Steps

Instead of building for six months and releasing everything at once (terrifying), DevOps teams release small changes frequently. If something breaks, it's easy to find and fix because the change was tiny.

Uber does this constantly. Every few weeks, the Uber app gets tiny updates — a new button here, a faster map there. You barely notice, but the team is constantly improving without disrupting your experience.

2. Automate the Boring Stuff

Testing code manually, deploying to servers manually, checking for errors manually — all of this is slow and humans make mistakes. DevOps teams automate these tasks so they happen instantly and consistently every single time.

Think of it like a car factory. Cars aren't built by hand anymore — robots do the repetitive work faster and with fewer errors. DevOps applies the same thinking to software.

3. Get Feedback Fast

When something breaks, DevOps teams know about it within seconds, not days. Monitoring tools watch the system constantly and send alerts the moment something looks wrong.

Netflix actually has a famous practice where they intentionally break parts of their own system during working hours to make sure their team can fix things quickly. They call it Chaos Engineering. It sounds mad, but it means they're never caught off guard.

What Does a DevOps Engineer Actually Do?

A DevOps engineer is the person who builds and maintains the systems that help developers work faster and more safely. They work on things like:

Setting up automated testing so bugs are caught before they reach users
Building pipelines that automatically deploy code (we'll cover this in a future article)
Managing cloud infrastructure on platforms like AWS or Azure
Monitoring systems and making sure everything is running smoothly
Writing scripts to automate repetitive tasks

It's one of the most in-demand roles in tech right now, and the skills involved are exactly what this blog is here to help you build.

Why Should You Care About DevOps?

Whether you're a developer, a system admin, a project manager, or someone just getting into tech — DevOps matters because it is how modern software is built.

Every major tech company in the world uses DevOps practices. Banks use it to deploy new banking features. Airlines use it to update booking systems. Hospitals use it to improve patient management software. It's not just for Silicon Valley startups — it's everywhere.

Learning DevOps opens doors. And the best part is, you don't need to know everything at once. We'll take it one byte at a time.

Quick Recap

Here's everything we covered today in plain English:

DevOps = Developers and Operations working together instead of in separate silos
It solves the old problem of slow, painful, risky software releases
The core ideas are: small changes, automation, and fast feedback
Companies like Amazon, Netflix, and Uber use DevOps to deploy changes thousands of times a day
A DevOps engineer builds the tools and systems that make all of this possible

DEV Community: Nerav Doshi

What is AI? You Are Already Using It - You Just Did Not Know

I Was Selling AI Before Most People Knew What It Was

But First — What Actually is AI?

Four Types of AI — Explained With Maps

AI You Are Already Using Without Realising It

Why I Went From Skeptical to Convinced

How AI Connects to Cloud and DevOps

AI is Not Going Away — And That is a Good Thing

Quick Recap

What’s Next?

The Big Picture: How DevOps, Cloud and AI Are Converging — And What That Means for You

I Still Remember the Sound

The Real Lesson I Learned (Much Later Than I Should Have)

From Warehouses to Whiteboards

From Supply Chain to Software to Cloud

What We Have Covered — And Why It Fits Together

The Fundamentals That Never Change

Certifications That Actually Mattered

Your Non-Technical Background is an Advantage

The One Thing I Wish I Did Earlier

If You Are Reading This and Wondering If You Can Break Into Tech

Quick Recap

- Article 10 — The big picture: how it all connects and what it means for you

What's Next?

Linux: The Operating System That Runs the Internet

The Day I Realised Linux Was Everywhere

So What Actually is Linux?

The Terminal: Your New Best Friend

Moving around the file system

Working with files

System information

The Mistakes I See Beginners Make (And I Made Too)

Mistake 1: Using rm -rf without thinking

Mistake 2: Ignoring file permissions

Mistake 3: Thinking the terminal is only for experts

How Linux Connects to DevOps and Cloud

Try It Right Now — No Installation Needed

Quick Recap

What's Next?

Kubernetes: The Platform That Keeps the Internet Running at Scale

From Supply Chain to Container Orchestration

So What Problem Does Kubernetes Actually Solve?

The Concepts That Confused Me (Explained Simply)

How Kubernetes Connects to Everything in This Series

The Managed Kubernetes Platforms You Will Encounter

The Thing That Still Surprises People

Be Patient With Yourself

Quick Recap

What’s Next?

Git: The Tool That Saves Your Code and Your Career

The Day I Nearly Broke Production

What is Git?

The Core Concepts

Essential Git Commands

Setting up

Daily workflow

Branching

Seeing history

The Two Biggest Beginner Mistakes

Mistake 1: Working directly on main

Mistake 2: Writing useless commit messages

How Git Connects to CI/CD Pipelines

Git for Infrastructure (Infrastructure as Code)

Quick Recap

What's Next?

CI/CD Pipelines: How Your Code Goes from a Laptop to the Real World

The First Time I Saw a Pipeline Run

Let’s Start With a Real World Analogy

What Does CI/CD Actually Stand For?

A Day in the Life of a Pipeline

The Tools That Make It Happen

Why This Matters Even If You Are Not a Developer

The Things Nobody Tells You About Pipelines

Quick Recap

What’s Next?

Generative AI and Agentic AI: From Answering Questions to Taking Action

The Meeting That Changed How I Prepare

A Quick Recap — Where We Left Off

How Generative AI Actually Works — In Plain English

Mistake 1: Using `rm -rf` without thinking