Week 0 wasn't about tools. It was about making sure the ground beneath every tool actually made sense.

Starting With a Question I Thought I Already Knew

I opened ChatGPT and asked a simple question:

What is a protocol in networking?

Having spent over 14 years as a Wireless RAN Engineer, I expected nothing more than a quick refresher. Instead, approaching the question honestly, as someone transitioning back into hands-on technical work after years away, and asking for real-life analogies instead of textbook definitions completely changed the learning experience.

A protocol, explained simply, is an agreed-upon set of rules that two systems follow so they can understand each other, much like two people need a shared language before a conversation can make sense.

It sounds simple, but it's the kind of understanding that makes every acronym that follows, TCP, IP, HTTP, finally click instead of simply being memorized.

Making It Concrete: EpicReads

To reinforce the concept, I worked through a practical scenario: a friend launching an online bookstore called EpicReads, hosted on a server in Finland.

How does someone in another country actually reach that website?

The answer involves several layers working together.

Packet Switching. Rather than sending an entire webpage as one large file, packet switching breaks it into many small packets. These packets can travel across different routes on the internet before being reassembled by the recipient's device.

IP Addressing. Every device connected to the internet, including the EpicReads server, has a unique IP address. Think of it as a digital street address that tells the network exactly where each packet should be delivered.

TCP/IP. This pairing forms the backbone of internet communication. TCP (Transmission Control Protocol) ensures that every packet arrives correctly, in the proper order, and without corruption. IP (Internet Protocol) determines the most efficient route for those packets to travel between the client and the server. Together, they make reliable communication over the internet possible.

HTTP and HTTPS. Once the packets reach the server, HTTP (HyperText Transfer Protocol) defines how the browser requests web pages and how the server responds. HTTPS builds on HTTP by adding encryption through SSL/TLS, protecting sensitive information such as login credentials, payment details, and personal data while it travels across the internet.

None of these concepts are particularly difficult in isolation. The real value comes from understanding how they work together as one complete process.

Two Ways to Build the Same Bookstore

The next lesson focused on application architecture.

We compared a two-tier architecture, where the frontend communicates directly with the database, against a three-tier architecture, where the frontend, backend, and database are separated into independent layers.

For EpicReads, the three-tier design might look like this:

• Frontend: Next.js or React

• Backend: Node.js with Express

• Database: MySQL or MongoDB

This separation isn't about adding unnecessary complexity. Instead, it improves maintainability, scalability, security, and flexibility. Each layer can evolve independently, making the application much easier to manage as it grows.

It's also the architecture you'll encounter repeatedly when working with modern cloud-native applications.

Giving the Bookstore a Name

The final networking concept was DNS (Domain Name System).

Technically, EpicReads could be accessed directly through its IP address. Practically, nobody wants to memorize a long sequence of numbers.

DNS solves this problem much like your phone's contact list. Instead of remembering a phone number, you simply remember a person's name. When someone types epicreads.com, DNS quietly translates that domain name into the server's IP address behind the scenes.

Connecting a domain name to an IPv4 address requires an A Record, a small but essential DNS record that performs this mapping.

It's one of those concepts that seems basic until you realize how frequently you'll encounter it in cloud engineering.

Closing the Loop With the Terminal

Week 0 ended with something practical.

I opened Visual Studio Code, launched the integrated terminal, and verified that my development environment was working correctly.

It may seem like a small task, but it reinforces one of the most valuable habits in DevOps: always verify your environment before building on top of it. That simple practice saves countless hours of troubleshooting later.

What This Week Actually Was

Week 0 wasn't about deployments. It wasn't about Docker, Kubernetes, CI/CD pipelines, or cloud infrastructure.

It was about building the foundation that makes all of those technologies easier to understand.

By the end of the week, I had revisited how data moves across the internet, how applications are structured, how domain names become IP addresses, and how to begin working comfortably within the development tools I'll rely on throughout this journey.

Sometimes the fastest way to move forward is to revisit the fundamentals with fresh eyes.

The technology hasn't changed. My understanding of it has.

Grateful to Pravin Mishra for a curriculum that rewards curiosity over shortcuts, and to Anjana Muthunayake (Lead Co-Mentor) and Joy Ukpabi (co-mentor) for their continued support and guidance.

About the DevOps Micro Internship

This post is part of my learning journey through the DevOps Micro Internship (DMI) with Agentic AI, Cohort 3, led by Pravin Mishra.

I'm documenting every week's lessons and practical experiences as I transition from over 14 years in Wireless RAN Engineering into Cloud and DevOps Engineering.

You can follow my progress here:

• My DMI Progress Dashboard: https://dmi.pravinmishra.com/s/kakpoklebervincent.html

• Learn more about the DevOps Micro Internship: https://dmi.pravinmishra.com/?utm_source=student&utm_medium=ps-blog&utm_campaign=cohort3

If you're also transitioning into Cloud or DevOps, I hope these weekly reflections help make the journey a little clearer.

One was about contributing to someone else's project.

The other was about protecting my own.

By the end of the week, I realized they were teaching exactly the same lesson from two different directions: professional software development is built on trust, and trust is earned through verification, not assumptions. Whether you're proposing a change to an open-source project or reviewing your own code before it reaches GitHub, the principle is the same. Build workflows that make mistakes difficult and verification easy.

Part 1: Learning the Real Open-Source Workflow

I'd read about fork-based collaboration before. Actually doing it was something else entirely.

On paper, the task sounded simple: add my name to a shared pull_request.md file and open a Pull Request. The real learning wasn't adding one line of text. It was everything that happened around that one line.

I forked the upstream repository into my own GitHub account instead of cloning it directly, because contributors don't normally have permission to push to the original repository. Inside my local clone, I configured two remotes:

• origin, my fork, where I own the changes

• upstream, the original project, where I receive updates

That separation is the foundation of open-source collaboration. You never push directly to a project you don't own.

From there, I created a dedicated feature branch, made one focused documentation change, committed it with a meaningful message, synchronized my branch with upstream, and pushed the change to my fork before opening a Pull Request.

None of that surprised me. What surprised me was the few quiet minutes before clicking Create Pull Request.

I stopped. I checked the base repository. Then the base branch. Then the head repository. Then the compare branch. Finally, I reviewed the file diff line by line, exactly one file, exactly one added line, nothing else touched.

That small habit, verify before submitting, felt almost unnecessary at the time. A few days later, it turned out to be one of the most valuable lessons of the week.

Part 2: When a Habit Becomes a Safety Net

The next practice asked a very different question. Instead of learning how to collaborate, I was asked to build a workflow that could prevent risky changes before they ever became Pull Requests.

Part of that practice involved opening another Pull Request. This time, the target wasn't the shared upstream repository, it was my own fork, because the files were learning artifacts, not contributions intended for the class repository.

When I reached GitHub's comparison page, something interesting happened. GitHub had quietly remembered the destination from my previous Pull Request and automatically selected the upstream repository as the base.

If I had accepted the default without checking, I would have proposed a fake AWS key, a demonstration Git hook, and a personal Claude Code skill to the shared repository used by the entire cohort. It wouldn't have created a real security incident, since the key was intentionally fake, but it would have demonstrated something equally important: tools remember, defaults persist, and convenience can quietly create mistakes.

Because I'd already built the habit of verifying every Pull Request before submitting it, I caught the issue immediately, switched the base repository to my own fork, and continued. That moment reinforced something I hadn't fully appreciated before, verification isn't something you learn once. It's a discipline you practice every single time.

Part 3: Building a Safety Net That Knows Its Own Limits

The second half of the week focused on building two different layers of protection into my Git workflow. The interesting part wasn't the tools themselves, it was understanding why neither one should ever exist alone.

Layer one: a deterministic gate.

The first layer was a Git pre-commit hook written entirely in Bash. No AI, no reasoning, no interpretation. Before every commit, it scanned staged files for AWS access-key patterns, private key headers, and oversized files.

To test it, I deliberately staged a fake AWS access key. The hook blocked the commit immediately. Every time, the outcome never changed, no judgment, no negotiation, just deterministic rules.

That consistency is exactly what makes fixed-rule automation valuable. But it's also where its limitations become obvious. The hook only catches what it's explicitly programmed to recognize. If a secret doesn't match a known pattern, the hook has no understanding that it's a secret at all. Rules are reliable. Rules are also limited.

Layer two: a context-aware reviewer.

The second layer approached the exact same staged changes differently. I built a Claude Code skill called /pr-ready. Unlike the hook, it wasn't looking for predefined patterns alone, it was trying to understand the change.

It identified the fake AWS key. It also noticed a debug echo statement that would have exposed that key if the script had actually run. Then it highlighted missing documentation, and drafted a Pull Request title and description for me to review.

That was the moment the distinction became clear. The hook enforced rules. The AI reviewed context. One detected patterns. The other explained why those patterns mattered.

But perhaps the most important design decision wasn't what the AI could do. It was what it couldn't do.

The skill was deliberately configured as read-only. It couldn't modify files. It couldn't commit code. It couldn't push to GitHub. It couldn't open a Pull Request. That wasn't a missing feature, it was an intentional safeguard.

AI can provide analysis. AI can draft documentation. AI can even identify problems humans overlook. But state-changing actions belong to the engineer who is accountable for the result. Every file I fixed, every commit I created, every push, every Pull Request, those decisions remained mine. I used AI as a collaborator, not as a substitute for engineering responsibility.

The Pattern Hidden Inside Both Practices

Looking back, I realized these two hands-on practices followed exactly the same structure we'd explored earlier in the internship through the Agentic Loop: Gather → Analyze → Human Act → Verify.

In the open-source contribution workflow, gathering meant reviewing the Pull Request, checking every field, and inspecting the diff before submitting it. Analyzing meant confirming the proposed change matched my intention. Acting meant creating the Pull Request. Verifying meant confirming that exactly the right change had been proposed.

In the Git safety-net exercise, both the hook and the AI skill gathered information from the staged changes. The hook analyzed those changes through deterministic rules. The AI analyzed them through reasoning and context. But every action that changed the repository, editing files, committing code, pushing to GitHub, opening the Pull Request, remained a human responsibility. Verification came afterward, rerunning both checks to confirm the issues had genuinely been resolved rather than assuming they had.

The more I reflected on it, the more I realized this isn't just a Git workflow. It's a pattern for building reliable engineering systems. Automation gathers information faster than humans. AI helps interpret that information more intelligently. But accountability still belongs to the person making the final decision.

Final Thoughts

When I started this week's work, I thought I was learning Git.

By the end of the week, I realized I was learning something much broader. I wasn't just learning how to contribute to open source, I was learning how professional teams build confidence in every change they ship.

Good engineering isn't simply about writing code. It's about designing workflows that help people trust one another. That trust doesn't come from automation alone. It doesn't come from AI alone. It comes from combining deterministic safeguards, intelligent analysis, and human judgment into a process that makes mistakes less likely and accountability unmistakably clear.

For me, that entire week comes down to one sentence: fixed rules give you a guaranteed floor. AI gives you judgment. A human decides what actually happens.

A huge thank you to Pravin Mishra for a curriculum that rewards curiosity over shortcuts, and to Anjana Muthunayake (Lead Co-Mentor) and Joy Ukpabi (Co-Mentor) for their continued guidance and encouragement throughout this journey.

P.S. This post is part of the DevOps Micro Internship (DMI) with Agentic AI — Cohort 3 — by Pravin Mishra. My graded progress is public: https://dmi.pravinmishra.com/s/kakpoklebervincent.html · Start your DevOps journey: https://dmi.pravinmishra.com/?utm_source=student&utm_medium=ps-blog&utm_campaign=cohort3

Artificial Intelligence has become one of the biggest talking points in technology today. Every week, a new AI tool promises to write code, automate deployments, troubleshoot systems, or even replace parts of a software engineer's daily workflow. It's easy to believe that AI is becoming the engineer while humans simply supervise.

I used to think that way too.

When I began the DevOps Micro Internship (DMI) Cohort 3 with Agentic AI, I was excited about learning Claude Code, AI agents, and automation. I imagined building intelligent assistants capable of solving operational problems with little human involvement.

What I didn't expect was that my biggest lesson wouldn't come from AI at all.

It came from Bash.

Yes, the same command-line scripting language that has existed for decades.

Over two assignments, I discovered something that completely changed how I think about automation:

AI without reliable evidence is just sophisticated guessing. Bash provides the evidence. AI provides the reasoning. Engineers provide the judgment.

That realization became the foundation of everything I built.

In this article, I'll share how I progressed from writing my very first Bash script to building an AI-assisted Linux incident investigation workflow using Claude Code, one that deliberately refuses to make changes without human approval.

This wasn't simply an exercise in writing scripts.

It was an exercise in learning how modern DevOps engineers combine automation, observability, artificial intelligence, and human accountability into a safe operational workflow.

Why Bash Still Matters in the Age of AI

Whenever a new technology becomes popular, there's a tendency to believe older technologies have become obsolete.

People once said graphical interfaces would eliminate the command line.

Then cloud platforms arrived, and people assumed Linux administration would disappear.

Today, many people believe AI will replace scripting.

After completing these assignments, I can confidently say the opposite is true.

The more capable AI becomes, the more valuable good automation becomes.

Consider this simple question:

How does an AI know whether your Linux server is healthy?

It doesn't.

Claude doesn't magically inspect your server.

It doesn't know if Nginx is running.

It doesn't know whether your disk is almost full.

It doesn't know if your application responds with HTTP 200 or HTTP 500.

Someone, or something, must collect that information first.

That's where Bash comes in.

Bash isn't simply a scripting language.

It's a bridge between the operating system and automation.

It transforms raw system information into structured, repeatable evidence that both humans and AI can understand.

Without Bash, AI has nothing reliable to analyze.

Learning Bash One Building Block at a Time

Like many people transitioning into DevOps, I didn't begin by writing complex automation.

I began with the basics.

That stage focused on building a solid Bash foundation before attempting any real operational automation. Rather than jumping straight into advanced scripting, the exercises introduced each concept progressively, from understanding the Bash environment to combining multiple scripting techniques into a reusable automation workflow.

Looking back, I now realize each task was preparing me for something much larger.

Step One: Understanding the Environment

Before writing any automation, I first needed to understand the environment where my scripts would run.

One of the first commands I executed was:

echo $SHELL

This confirmed the default shell running on my Ubuntu system.

Next, I checked the installed Bash version:

bash --version

At first glance, these commands seem trivial.

But in production environments, assumptions are dangerous.

Different Bash versions support different features.

Verifying the environment before writing scripts is no different from confirming software versions before deploying applications.

Good engineers don't assume.

They verify.

I also created a dedicated workspace to organize every script throughout the assignment.

Instead of scattering files around my home directory, everything lived inside a structured project folder.

It might sound like a small detail.

It isn't.

Well-organized projects become easier to maintain, debug, and extend over time.

That same principle applies whether you're managing Bash scripts, Terraform modules, Kubernetes manifests, or entire software systems.

Writing My First Bash Script

Every programmer remembers the excitement of writing their first working program.

Mine was no different.

The script itself was simple.

It displayed a welcome message, printed my name, and showed the current date and time.

Although basic, this script introduced several concepts that every Bash script depends on:

the shebang (#!/bin/bash), sequential command execution, executable permissions, and running scripts from the terminal.

After creating the script, I made it executable using:

chmod +x first-script.sh

Then executed it using:

./first-script.sh

That small exercise introduced an important Linux concept.

A script isn't automatically executable simply because it contains valid commands.

Permissions matter.

Linux requires explicit permission before allowing code to run.

It's one of many examples where Linux prioritizes security over convenience.

That philosophy appears repeatedly throughout DevOps engineering.

Variables: Making Scripts Flexible

Imagine writing a script that contains your name twenty different times.

Now imagine changing your name.

Every occurrence would need updating.

Variables solve that problem.

Instead of hardcoding information repeatedly, I learned to store values once and reuse them throughout the script.

For example:

name="Kleber Vincent"
role="DevOps Engineer"
location="Nigeria"

Those values could then be displayed anywhere using:

echo "$name"

While this seems elementary, variables are one of the most powerful concepts in scripting.

They allow automation to adapt.

The same script can be reused for different users, servers, applications, or environments simply by changing a few values.

Even better, variables don't only store text.

Using command substitution:

today=$(date)

the script dynamically captured the current system date every time it ran.

Instead of producing static output, the script became aware of its environment.

That distinction is what separates automation from simple text output.

Arrays: Organizing Related Information

As my scripts became more capable, I encountered another challenge.

What happens when one variable isn't enough?

Suppose I wanted to work with several DevOps tools:

Git, Docker, Kubernetes, Jenkins, Terraform.

Creating five separate variables would quickly become messy.

Instead, Bash arrays allow related information to be grouped together under a single variable.

For example:

tools=("Git" "Docker" "Terraform" "Kubernetes")

Now, instead of managing four different variables, the script manages one collection.

Arrays make automation cleaner, more scalable, and easier to extend.

More importantly, they prepare the way for loops.

And loops completely changed how I thought about scripting.

Loops: Eliminating Repetition Through Automation

One of the biggest lessons I learned during this stage was that automation isn't just about writing commands, it is about avoiding repetition.

Imagine having a list of twenty servers to check manually.

You could type the same command twenty times.

Or you could write a loop that does it for you.

That is exactly why loops exist.

To understand this concept, I first created a simple counter that displayed numbers from one to five. Although the task itself was straightforward, it introduced one of the most powerful ideas in scripting: allowing a computer to repeat work consistently without manual intervention. Later, I combined loops with arrays to process multiple values automatically, demonstrating how repetitive tasks can be transformed into efficient automation.

A simple example looked like this:

for number in {1..5}
do
    echo "Number: $number"
done

Five lines of output.

One block of code.

The computer handled the repetition.

That may not sound revolutionary, but almost every automation tool used in DevOps relies on this same principle.

When Ansible configures multiple servers, when Terraform provisions multiple resources, when Kubernetes schedules multiple Pods, something behind the scenes is iterating over a collection of objects.

Learning loops in Bash wasn't simply learning syntax.

It was learning how computers automate repetitive work reliably.

File Validation: Never Assume

Another lesson that stood out to me was the importance of validating resources before acting on them.

Suppose your script expects a configuration file.

What happens if someone accidentally deletes it?

Without validation, the script may fail unexpectedly.

Or worse, it may produce incorrect results.

To prevent that, I learned how Bash checks whether files and directories exist before continuing.

Using file test operators such as -d and -f, the script could determine whether a directory or file was present before attempting any operation.

This might seem like defensive programming.

That's because it is.

Production systems should never assume required resources exist.

They verify first.

That single habit dramatically reduces failures caused by missing files, incorrect paths, or unexpected environmental changes.

Teaching Scripts to Make Decisions

Until this point, every script I wrote followed instructions exactly as written.

But real-world automation often needs to decide what to do.

Should it continue? Should it stop? Should it display an error? Should it notify an engineer?

That's where conditional statements became essential.

Using if-else logic, I created a script that evaluated a student's score and displayed either Pass or Retry depending on the result. Although simple, the exercise demonstrated how automation can respond differently based on changing input rather than producing the same output every time.

A simplified example looked like this:

if [ "$score" -ge 70 ]
then
    echo "Pass"
else
    echo "Retry"
fi

While the example involved exam scores, the same concept applies everywhere in DevOps.

If disk usage exceeds 90 percent, raise an alert. If Nginx isn't running, report a failure. If an application returns HTTP 200, mark it healthy.

Good automation doesn't blindly execute commands.

It evaluates conditions before deciding what happens next.

Functions: Writing Scripts Like an Engineer

By the end of this stage, my scripts were becoming noticeably longer.

Instead of placing everything inside one large file, I learned how to organize related tasks into reusable functions.

This was one of my favorite topics.

Functions allow you to group related commands under a meaningful name.

Instead of writing the same code repeatedly, you simply call the function whenever it's needed.

For example:

show_header()
show_user()
show_tools()
show_result()
show_footer()

Each function had a single responsibility.

One displayed the script header. Another displayed user information. Another processed the DevOps tools checklist. Another summarized the results.

Separating logic into functions made the script easier to understand, maintain, and extend. The final automation exercise brought together variables, arrays, loops, conditionals, and functions into one structured workflow, demonstrating how individual Bash concepts work together to solve practical problems.

Looking back, this wasn't simply about making the script cleaner.

It was my first introduction to software design principles.

Large systems become manageable when they're divided into small, reusable components.

The same principle applies whether you're writing Bash, Python, Java, or designing cloud infrastructure.

Looking Back at the Bash Fundamentals

When I completed the final Bash automation script, I thought I had finished learning Bash.

In reality, I had only built the foundation.

At the time, my scripts could:

✔ Display information

✔ Store variables

✔ Process arrays

✔ Execute loops

✔ Validate files

✔ Make decisions

✔ Organize reusable functions

Those skills felt useful.

What I didn't yet realize was that every one of them would soon become part of a much larger system.

Variables would become configuration settings. Functions would become health checks. Arrays would define automated workflows. Conditionals would determine system health. Loops would execute repeated diagnostics.

The final Bash script wasn't the destination.

It was the beginning.

From Learning Bash to Solving Real Problems

One week later, a very different challenge appeared.

There were no counters. No student scores. No "Hello World."

Instead, the objective was to build something that resembled a real production support tool.

The next stage asked me to create a read-only Linux health triage system capable of investigating an Ubuntu server, collecting operational evidence, and integrating with Claude Code as a reusable AI skill. Rather than allowing the AI to make changes, the workflow followed a disciplined sequence: Gather, Analyze, Human Act, Verify.

This wasn't just another Bash exercise.

It was an incident response workflow.

The difference was immediately obvious.

Instead of writing scripts to demonstrate Bash syntax, I was now writing scripts to answer operational questions such as:

Is Nginx running? Is the server listening on Port 80? Can the application respond to an HTTP request? Is disk usage becoming a problem? Is there enough available memory?

These weren't academic questions.

They're exactly the kinds of checks engineers perform every day when diagnosing production issues.

For the first time, Bash stopped feeling like a scripting language.

It started feeling like an engineering tool.

And that was the moment everything clicked.

Building a Linux Health Check Script That Thinks Like an Engineer

By the time I reached this next stage, I already understood the building blocks of Bash.

Variables. Functions. Loops. Conditionals. File validation.

The next challenge wasn't learning new syntax.

It was learning how to combine those concepts into something genuinely useful.

Rather than creating another practice script, I was asked to build a Linux Health Check utility capable of gathering operational evidence from an Ubuntu server.

The goal wasn't to repair anything.

The script had one responsibility:

Observe the system. Report the facts. Change nothing.

That philosophy immediately stood out to me.

Many beginners assume automation should immediately restart services or delete temporary files whenever a problem is detected.

In production environments, that approach can create even bigger incidents.

Sometimes the safest action is to collect accurate information and allow an engineer to decide what happens next.

That became the guiding principle for everything that followed.

The Five Questions Every Healthy Server Should Answer

Instead of checking hundreds of different metrics, this stage focused on five essential health checks.

Each one represented a common source of production incidents.

1. Is the Operating System Running Out of Disk Space?

One of the easiest ways to bring down an application is to fill the disk.

Logs continue growing. Applications cannot write temporary files. Databases become unstable. Services begin failing for reasons that seem unrelated.

The first health check measured disk utilization using:

df -h

Rather than displaying every mounted filesystem, the script extracted the information needed to determine whether disk usage remained within acceptable limits.

If utilization exceeded the defined threshold, the report clearly highlighted the issue.

No cleanup. No file deletion. Just evidence.

2. Is Enough Memory Available?

Applications depend on available RAM.

When memory becomes exhausted, performance drops dramatically. Processes may terminate unexpectedly. Linux may begin swapping heavily to disk.

Using standard Linux commands, the script gathered memory statistics and summarized the results in a format that both engineers and AI could interpret.

Again, the objective wasn't optimization.

It was visibility.

3. Is Nginx Actually Running?

For web applications, one of the quickest checks is confirming that the web server itself is operational.

Instead of guessing, the script queried the service directly.

systemctl status nginx

or

systemctl is-active nginx

The result immediately answered an important operational question.

Running? Stopped? Failed?

Instead of manually logging into servers during every incident, the automation collected the answer consistently every time.

4. Is Port 80 Listening?

A running service doesn't necessarily mean users can reach it.

Applications sometimes start successfully while failing to bind to the expected network port.

To verify this, the script checked whether HTTP traffic could actually be accepted.

Typical Linux networking tools made this verification straightforward.

The output became another piece of operational evidence.

One more fact. One less assumption.

5. Does the Application Respond?

This final check moved beyond infrastructure.

It tested the application itself.

Even if the operating system looked healthy, even if Nginx was running, even if Port 80 was listening, users still care about one thing.

Can the application respond?

Using a simple HTTP request, the script verified the application's availability.

A successful response confirmed that requests could reach the service.

An unexpected response immediately became part of the incident report.

Why Read-Only Automation Matters

One of my favorite design decisions in this project was something the script didn't do.

It never attempted to repair anything.

No service restarts. No package installations. No deleting files. No killing processes.

At first, I wondered why.

Wouldn't automation be more powerful if it fixed problems automatically?

The answer became clear after thinking like a production engineer.

Imagine an AI notices Nginx has stopped.

Should it restart the service?

Maybe. But what if the reason Nginx stopped was because the disk is full, the configuration file is corrupted, an SSL certificate expired, another application already occupies Port 80, or an engineer intentionally shut it down during maintenance?

Automatically restarting the service might hide the real problem or make the situation worse.

Instead, the workflow deliberately separates observation from action.

That single design choice dramatically reduces operational risk.

From Raw Commands to Structured Evidence

A Linux terminal produces enormous amounts of information.

Running a command like df -h may display several lines of output.

Another command might produce dozens more.

Humans can usually interpret that information.

AI, however, performs much better when information is organized consistently.

Instead of dumping raw command output, the Bash script transformed system information into structured sections, something like:

========== Disk Usage ==========
Filesystem      Used  Available  Use%
...

========== Memory ==========
...

========== Nginx ==========
Running

========== Port 80 ==========
Listening

========== HTTP Check ==========
HTTP 200 OK

Notice what happened.

The Bash script wasn't simply executing commands anymore.

It was creating a structured report.

That report became the "language" Claude Code would later read and analyze.

In other words: Bash gathered the evidence. The AI interpreted the evidence. The engineer made the final decision.

Introducing Claude Code Into the Workflow

This was the point where the whole project became truly exciting.

Instead of treating AI as something separate from Linux administration, the project combined them into a single workflow.

The Bash script collected reliable facts.

Claude Code received those facts.

Then Claude generated an operational assessment.

But there was one very important rule.

Claude never connected directly to the server.

It never executed Linux commands on its own initiative.

It only analyzed the report generated by Bash.

That distinction matters enormously.

The AI wasn't replacing Linux. It wasn't replacing Bash. It wasn't replacing engineering judgment.

It was acting as an intelligent analyst reviewing evidence collected through trusted automation.

Designing an AI That Knows Its Limits

One of the most valuable lessons from this stage wasn't technical.

It was philosophical.

AI should know what it cannot do.

The Claude skill was intentionally designed with clear boundaries. It must never restart services, modify files, install packages, delete data, or execute destructive commands.

Instead, its responsibilities were simple:

✔ Read the report.

✔ Explain what it sees.

✔ Suggest possible causes.

✔ Recommend safe next steps.

✔ Ask a human engineer to approve any corrective action.

That approach reflects one of the core principles of modern DevOps: automation should increase confidence, not increase risk.

Writing those constraints down felt different from writing a normal script. Instead of teaching the system what to do, I was teaching it what to refuse to do, no matter how obvious the fix seemed. When people imagine AI-powered operations, they often picture an assistant that immediately starts fixing things: restart Nginx, delete unnecessary files, install missing packages, reboot the server. That sounds impressive until the AI makes the wrong call.

Picture a production server where Nginx has stopped because the disk is full. Automatically restarting Nginx won't solve the problem, it could delay discovering the real root cause. Or picture a server where the application was intentionally stopped for scheduled maintenance. An AI that blindly restarts services in that situation would actually create an outage where none existed.

The safest AI isn't always the one that can do the most. Sometimes it's the one that knows when to stop and ask for human approval.

The Gather, Analyze, Human Act, Verify Workflow

One of my favorite aspects of this workflow was how closely it mirrored a real production support process.

Rather than jumping directly into remediation, the workflow followed a disciplined sequence.

Step 1: Gather. Everything begins with Bash. The health check script collects evidence from the server. Instead of relying on assumptions, it captures measurable facts: disk usage, memory utilization, Nginx service status, port availability, HTTP response. At this stage, no decisions are made. The script simply observes.

Step 2: Analyze. The generated report is then provided to Claude Code. Because the information is structured, the AI can quickly identify patterns, for example, "Disk usage is healthy," "Memory utilization is normal," "Nginx service is inactive," "HTTP endpoint cannot be reached." Instead of reading dozens of terminal outputs manually, engineers receive a concise operational summary. The AI becomes an intelligent interpreter rather than a system administrator.

Step 3: Human Act. This is the most important step. After reviewing Claude's assessment, the engineer decides what should happen next. Maybe restarting Nginx is appropriate. Maybe the configuration file needs inspection. Maybe another engineer is already performing maintenance. Automation provides evidence. AI provides insight. Humans remain responsible for operational decisions. That balance dramatically reduces unnecessary risk.

Step 4: Verify. Once corrective actions have been completed, the Bash script runs again. The new report confirms whether the issue has actually been resolved. This creates a simple but effective feedback loop:

Engineer identifies issue
        ↓
Collect evidence
        ↓
AI explains findings
        ↓
Human approves corrective action
        ↓
Run health checks again
        ↓
Verify resolution

Notice something important. The AI never assumes the problem has been solved. Verification comes from fresh evidence. That principle is fundamental to good engineering.

Lessons That Changed My Perspective

Before beginning these assignments, I viewed Bash as "just another scripting language."

Now I see it differently.

Bash is not simply about writing commands.

It is about creating repeatable operational knowledge.

Every function. Every conditional. Every loop. Every validation.

They all contribute to building reliable automation.

I also learned something equally important about artificial intelligence.

AI is most valuable when paired with trustworthy data.

Without evidence, even the smartest AI can only speculate.

With structured evidence, it becomes an incredibly effective assistant.

That distinction changed how I think about modern DevOps.

The future isn't humans versus AI.

The future is humans working alongside AI.

Why This Matters for Modern DevOps Engineers

Today's DevOps engineers are expected to understand far more than infrastructure.

They must be comfortable with Linux, networking, cloud platforms, containers, Kubernetes, CI/CD, Infrastructure as Code, monitoring, security, automation, and artificial intelligence.

That list can feel overwhelming.

But these assignments reminded me that every advanced system still relies on strong fundamentals.

Claude Code didn't replace Bash.

Claude Code depended on Bash.

The AI couldn't analyze information that hadn't been collected.

Likewise, Bash alone couldn't explain patterns across multiple health checks.

Each technology complemented the other.

And that's exactly how modern engineering teams should think about AI.

Not as a replacement.

But as a multiplier.

Looking Ahead

Completing these assignments has changed how I approach every future automation project.

Instead of asking, "Can AI solve this problem?"

I now ask, "What reliable evidence should I collect before AI begins reasoning?"

That single question has influenced how I think about infrastructure monitoring, incident response, cloud operations, and production reliability.

As I continue my DevOps journey, I know Bash will remain one of my most valuable tools, not because it is new, but because it provides the foundation upon which reliable automation is built.

And with AI tools like Claude Code acting as thoughtful collaborators rather than uncontrolled operators, the possibilities become even more exciting.

Final Thoughts

When I started these assignments, my goal was simply to complete another milestone in the DevOps Micro Internship.

Instead, I gained something much more valuable.

I learned that great automation isn't measured by how many commands it executes.

It's measured by how much confidence it gives engineers.

Bash taught me how to collect reliable evidence.

Claude Code showed me how AI can transform that evidence into meaningful insight.

Together, they demonstrated what the future of DevOps looks like: reliable automation, responsible AI, and human judgment.

That's a future I'm excited to be part of.

Acknowledgements

This project was completed as part of the DevOps Micro Internship (DMI) Cohort 3 with Agentic AI, led by Pravin Mishra.

The internship continues to reinforce an important philosophy: learn the fundamentals first, build practical solutions second, and use AI to amplify your engineering, not replace it.

I'm grateful for the opportunity to explore modern DevOps practices in a way that combines Linux, Bash scripting, automation, and AI into real-world engineering workflows.

Connect With Me

If you enjoyed this article or you're also transitioning into DevOps, I'd love to connect and learn from your journey.

LinkedIn: https://www.linkedin.com/in/vincent-kleber-kakpo-8b920b88

GitHub: https://github.com/kakpoklebervincent

If this article helped you, consider sharing it with someone learning Linux, Bash, or AI-assisted DevOps.

P.S. This post is part of the DevOps Micro Internship (DMI) with Agentic AI — Cohort 3 — by Pravin Mishra. My graded progress is public: https://dmi.pravinmishra.com/s/kakpoklebervincent.html · Start your DevOps journey: https://dmi.pravinmishra.com/?utm_source=student&utm_medium=ps-blog&utm_campaign=cohort3

For a long time, I thought my biggest strength was discipline.

Every weekday, my alarm rang at 3:00 a.m.

Before most people had started their day, I had already finished my morning devotion, completed a short workout, and settled into two uninterrupted hours of learning.

It wasn't exciting.

It wasn't easy.

But it was consistent.

That routine carried me through my first DevOps Micro Internship, and I genuinely believed consistency alone would be enough to help me become the engineer I wanted to be.

Then life happened.

A season of family responsibilities pulled me away from my studies. It wasn't planned, but it was necessary.

When I eventually returned, I expected to pick up where I had left off.

Instead, I experienced something that completely changed how I think about learning.

I had completed the lessons.

I hadn't mastered them.

I had gone through CI/CD, Docker, Terraform, and Kubernetes.

I remembered the videos.

I remembered the labs.

I remembered the concepts.

But when I opened a terminal and tried rebuilding everything without following a guide, I struggled.

That moment was difficult to accept.

Not because I couldn't do it.

But because I finally realized I had confused finishing a course with building a skill.

That's when one sentence came to mind.

I didn't have a discipline problem.

I had a repetition problem.

Watching someone build infrastructure isn't the same as building it yourself.

Following a walkthrough isn't the same as solving problems when nobody is telling you what comes next.

Real confidence only comes through repetition.

That realization became the biggest reason I decided to return for another DevOps Micro Internship.

Many people asked me why I would repeat a programme I had already completed.

For me, the answer was simple.

I wasn't coming back for another certificate.

I was coming back to build competence.

Why This Time Feels Different

There was another reason I returned.

During DMI Cohort 2, I had my first introduction to Agentic AI.

At the time, I found it interesting, but I didn't fully understand its significance.

As the months passed, I kept reading, experimenting, and paying attention to how engineering teams were beginning to work.

The more I learned, the more convinced I became that Agentic AI wasn't simply another tool to learn.

It represented a completely different way of building software and infrastructure.

Instead of using AI only to answer questions, engineers were beginning to build systems where AI understood project context, respected engineering standards, automated repetitive work, and collaborated like another member of the team.

I didn't want to be catching up later.

I wanted to grow with the technology while it was still evolving.

Returning to DMI Cohort 3 gave me that opportunity.

The Small Change That Changed Everything

This time, I only changed one thing in my learning routine.

One evening every week became rebuild day.

No notes.

No videos.

No walkthroughs.

Just me, my laptop, and a blank terminal.

Instead of reviewing the previous week's lab, I rebuilt it completely from memory.

Not because I expected perfection.

But because I wanted to understand why every command existed.

If I couldn't rebuild it myself, then I hadn't really learned it.

That single habit completely changed my approach to learning.

Today, my routine looks like this.

👋 Monday to Friday (3:00 a.m. to 5:00 a.m.): Hands-on DMI learning before the day begins.

👋 Wednesday evening: Rebuild the previous week's lab entirely from memory.

👋 Saturday: Live DMI session.

👋 Sunday: Review, reflection, and preparation for the week ahead.

It isn't a perfect routine.

It's a repeatable one.

As Pravin Mishra often says,

"You don't need a perfect routine. You need a repeatable one."

That quote has stayed with me because it perfectly describes what was missing from my first attempt.

Looking Back Helped Me Move Forward

When I reflect on this journey, I realize it didn't begin with cloud computing.

Long before Terraform, Kubernetes, GitHub Actions, or Agentic AI became part of my vocabulary, I had already spent years solving infrastructure problems in another industry.

My career started in traditional IT infrastructure before I moved into Wireless Radio Access Network operations.

Over the next fifteen years, I worked in telecommunications, eventually leading a team responsible for more than 14,000 network sites and over 120 controllers across Nigeria.

When alarms went off at three o'clock in the morning, there wasn't time to panic.

Customers were already affected.

Services had to be restored.

Root causes had to be found quickly.

Solutions had to work.

Those years taught me lessons that still guide me today.

👋 Stay calm under pressure.

👋 Solve problems methodically.

👋 Take ownership.

👋 Never stop learning.

Technology changes.

Engineering principles do not.

Reinvention Isn't Starting Over

As cloud computing became the future of infrastructure, I knew I had a choice.

I could remain comfortable with what I already knew.

Or I could challenge myself to learn again.

I chose to learn again.

Today, that decision has brought me into a world where infrastructure is defined as code, deployments are automated through CI/CD pipelines, Kubernetes orchestrates cloud native applications, and Agentic AI is beginning to reshape how engineers work.

What excites me most isn't simply learning new technologies.

It's seeing telecommunications and cloud engineering gradually become one ecosystem.

Telecommunications is becoming cloud native.

Cloud engineering increasingly benefits from the operational discipline that telecommunications has refined for decades.

Standing between those two worlds is exactly where I want my career to be.

People often think reinvention means leaving the past behind.

I've learned something different.

Reinvention isn't forgetting where you came from.

It's carrying everything you've learned into the future you're building.

Final Thoughts

Looking back, I no longer see returning to the DevOps Micro Internship as repeating a course.

I see it as making an investment in myself.

Every early morning.

Every lab rebuilt from memory.

Every challenge solved.

Every lesson learned.

Each one has moved me one step closer to becoming the engineer I want to be.

If you're currently in a season where it feels like you're starting again, don't see it as moving backwards.

Sometimes the strongest engineers aren't the ones who learn the fastest.

They're the ones who are willing to return to the fundamentals until those fundamentals become second nature.

Growth isn't always about learning something new.

Sometimes it's about learning something well.

Thank you for taking the time to read my story.

If any part of this journey resonates with you, I'd genuinely love to hear your thoughts. Every engineer's path is different, but we all grow by sharing experiences, learning from one another, and continually challenging ourselves to improve.

This article is one chapter in my journey from Telecommunications to Cloud Native Engineering. I look forward to sharing many more lessons as I continue learning, building, and growing in public.

P.S. This post is part of the DevOps Micro Internship (DMI) with Agentic AI — Cohort 3 — by Pravin Mishra. My graded progress is public: https://dmi.pravinmishra.com/s/kakpoklebervincent.html · Start your DevOps journey: https://dmi.pravinmishra.com/?utm_source=student&utm_medium=ps-blog&utm_campaign=cohort3

Introduction

When I began Week 2 of the DevOps Micro Internship with Agentic AI, I thought I would simply be learning how to use another AI tool. Looking back now, I realize this week was about something much bigger.

It changed the way I think about working with AI.

Instead of treating AI as something that simply answers questions, I learned how to build a structured working relationship with it. Every assignment added another capability, gradually transforming Claude Code into a reliable engineering assistant that could follow instructions, respect project rules, remember important information, and help me work more efficiently without taking control away from me.

Coming from more than fifteen years in Telecommunications and now transitioning into Cloud Computing, DevOps, and Agentic AI, every assignment reminded me that engineering is not only about solving technical problems. It is equally about creating systems that are reliable, repeatable, and safe.

Week 2 challenged me to slow down, think more carefully, and understand the reasons behind every feature instead of simply trying to finish the assignments.

Every assignment during Week 2 built upon the previous one. What started with understanding Claude's workflow gradually expanded into creating reusable Skills, configuring specialized Subagents, connecting external tools through MCP, implementing safety mechanisms with Hooks and Permissions, and finally giving Claude the ability to remember project-specific knowledge across sessions.

Looking back, I realized I wasn't simply learning individual features. I was learning how to build a complete AI-assisted engineering workflow.

Biggest Technical Insight I Got This Week

The biggest lesson for me was understanding that Agentic AI is far more than an advanced chatbot.

Throughout this week I learned how different components work together to create a complete engineering workflow.

👋 I learned how CLAUDE.md provides project instructions that guide Claude before any work begins.

👋 I discovered how Skills transform long prompts into reusable commands that improve consistency.

👋 I explored Subagents, allowing specialized tasks to be delegated to the most appropriate AI agent.

👋 I configured MCP to securely connect Claude Code with GitHub and retrieve live repository information instead of relying only on built-in knowledge.

👋 I implemented Hooks and Permissions to prevent unsafe operations before they could execute.

👋 Finally, I experienced Memory, where Claude could remember project rules across completely new sessions without needing to be reminded.

Watching all these capabilities work together completely changed my perspective. I no longer see AI as a tool that simply answers questions. I now see it as an engineering partner that can follow structured workflows while still relying on human guidance, review, and oversight.

Biggest Insight I Got About Myself This Week

This week taught me something important about my own learning style.

I learn best when I build things with my own hands.

Reading documentation is valuable, but I truly understand a concept only after I have configured it, broken it, fixed it, tested it, and documented the outcome.

There were moments when things did not behave as expected. Instead of immediately assuming something was wrong, I learned to investigate more carefully, compare outputs, verify configurations, and understand why the result differed from what I expected.

That shift in mindset has made me much more confident when working with unfamiliar technologies.

My Biggest Weakness or Loop I Noticed

One habit I noticed is that I sometimes become too focused on getting the expected output.

When Claude's response looked different from the examples provided in the assignment, my first reaction was to think something had gone wrong.

As I investigated further, I realized that the underlying functionality was actually working correctly. Claude had simply explained the hook behaviour differently instead of displaying the exact wording shown in the assignment guide.

That experience reminded me that successful engineering is not about matching screenshots. It is about understanding the behaviour of the system and verifying that it is functioning as intended.

One System I Will Implement From This Week

One habit I will carry into every future assignment is creating a structured checklist before I begin.

Before starting any task, I will:

👋 Read the entire assignment from beginning to end.

👋 Identify every required screenshot before executing the first command.

👋 Complete one task fully before moving to the next.

👋 Document my work immediately while everything is still fresh.

👋 Commit changes regularly instead of waiting until the very end.

I believe this simple system will reduce mistakes, improve consistency, and make future assignments much easier to complete.

What I Learned About Agentic AI and DevOps

Before this week, I mostly viewed AI as a tool for generating answers.

Today my perspective is completely different.

I now understand that Agentic AI can participate in structured engineering workflows when it is given the right instructions, permissions, and safety boundaries.

At the same time, I also learned that automation should never replace human responsibility.

👋 Hooks prevent unsafe actions.

👋 Permissions control what AI can access.

👋 Memory improves consistency.

👋 Skills encourage reusable workflows.

👋 MCP connects AI with external systems.

Yet despite all these capabilities, human judgment remains essential.

The engineer is still responsible for reviewing decisions, validating outputs, and ensuring that every action aligns with the goals of the project.

That balance between automation and human oversight is one of the most valuable lessons I will carry forward in my DevOps journey.

My Week 2 Highlight

The most memorable moment for me was watching Claude remember my project rules after a completely fresh session.

I taught Claude three important facts about the project, closed the session entirely, reopened Claude Code, and asked questions without providing any additional context.

Claude immediately remembered the required hero section background colour without me providing any additional context.

It refused to add JavaScript because of the rule I had previously defined.

It even referenced the stored project memory while explaining its decision.

Seeing that happen made me appreciate the practical value of persistent memory in real engineering environments. It was no longer just an AI conversation. It felt like collaborating with a teammate who genuinely understood the project's standards.

That moment made all the previous assignments come together.

Final Thoughts

Week 2 has been one of the most rewarding learning experiences since I began my transition into Cloud Computing, DevOps, and Agentic AI.

Every assignment built naturally upon the previous one, and by the end of the week I wasn't simply using Claude Code. I was teaching it how to work with me safely, consistently, and efficiently.

The journey has also reinforced something I have always believed.

Technology continues to evolve, but the willingness to learn, adapt, and improve remains the greatest skill an engineer can possess.

I am excited for the weeks ahead and look forward to building even more real-world projects while continuing to grow as a Cloud and DevOps Engineer.

I would like to sincerely thank Pravin Mishra for designing a learning experience that continually challenges us to think beyond simply completing assignments. My sincere appreciation also goes to the entire mentoring team for their guidance, encouragement, and unwavering support throughout this journey. Every lesson has encouraged me to become a better engineer, not just a better learner.

This is only Week 2, yet I can already see how much my mindset has evolved. I look forward to the weeks ahead, building more real-world projects, sharpening my DevOps skills, and continuing my transition from Telecommunications into Cloud Computing, DevOps, and Agentic AI.

One assignment at a time.

One project at a time.

One step closer to becoming the engineer I aspire to be.

P.S. This post is part of the DevOps Micro Internship (DMI) with Agentic AI — Cohort 3 — by Pravin Mishra. My graded progress is public: https://dmi.pravinmishra.com/s/kakpoklebervincent.html · Start your DevOps journey: https://dmi.pravinmishra.com/?utm_source=student&utm_medium=ps-blog&utm_campaign=cohort3