DEV Community: Adeje Oluwatobiloba

Building a Layered Code Review Workflow with Git Hooks and AI

Adeje Oluwatobiloba — Thu, 23 Jul 2026 19:06:28 +0000

As I progressed through my DevOps internship, I explored a workflow that combines Git pre-commit hooks with AI-assisted code review. While learning how these tools work together, I realized the entire process can be explained using a football analogy.

Think of a football match.

Git is VAR

Just as the Video Assistant Referee (VAR) records every play and allows referees to review important moments, Git records every change made to a project. Every commit becomes part of the project's history, making it possible to compare versions, inspect changes, or roll back to a previous state whenever necessary.

Without Git, recovering from mistakes would be much more difficult. In fact, during this assignment I accidentally performed a git reset --hard HEAD~1. Thanks to Git's history and the reflog, I was able to recover my work, this is a reminder of how valuable version control really is.

GitHub is the Referee

If Git records the match, GitHub acts as the referee.

GitHub manages pull requests, code reviews, approvals, and ultimately determines what gets merged into the main branch. It provides a structured collaboration process where developers can discuss changes, request improvements, and verify code before it becomes part of the production codebase.

Git Hooks are the Assistant Referee

An Assistant Referee watches for clear rule violations and immediately raises the flag.

Git pre-commit hooks serve exactly the same purpose.

Before every commit, the hook automatically inspects the staged changes and enforces predefined rules. During this assignment, the hook scanned my staged diff for issues such as:

Potential leaked secrets
API key patterns
Repository policy violations

These checks are deterministic. They don't understand the meaning of the code, they simply verify whether the staged changes violate known rules.

This makes Git hooks extremely fast and reliable for catching common mistakes before they ever enter the repository.

AI-Assisted Code Review is the VAR Review Team

While Git hooks look for predefined violations, AI-assisted code review analyzes the same code from a broader perspective.

Instead of asking:

"Does this code match a forbidden pattern?"

AI asks questions like:

Is this implementation maintainable?
Does it follow best practices?
Could this introduce security risks?
Is the pull request ready for review?

Unlike rule-based automation, AI evaluates context, allowing it to identify improvements that cannot easily be expressed as regular expressions or fixed validation rules.

This showed me that AI is not replacing automation, rather it is extending it.

Security Through Least Privilege

Another important concept I learned was the principle of least privilege.

The AI review workflow was intentionally granted only the permissions it required:

Read repository contents
Execute validation commands

It could not modify code, commit changes, or push to the repository.

Actions such as:

git commit
git push
Opening a pull request

remain the responsibility of the developer.

This design ensures that AI can provide recommendations without making irreversible changes to the codebase.

Key Takeaways

This week's assignment reinforced several important DevOps practices:

Create feature branches to protect the main branch and support collaborative development.
Use Git pre-commit hooks to catch predictable issues before code is committed.
Combine fixed-rule automation with AI-assisted review for more comprehensive code validation.
Follow the principle of least privilege by granting tools only the permissions they require.
Keep developers responsible for repository-changing actions while using automation and AI as decision-support tools.

Final Thoughts

The football analogy helped me understand the relationship between these tools:

Git records every play like VAR.
GitHub acts as the Referee, managing reviews and merges.
Git Hooks function as the Assistant Referee, enforcing predefined rules before play continues.
AI-assisted code review acts as the VAR Review Team, providing context-aware analysis that goes beyond simple rule checking.

Modern DevOps isn't about replacing one tool with another. It's about combining deterministic automation, intelligent analysis, and human decision-making into a layered workflow that delivers secure, reliable, and maintainable software.

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/Tobilee10.html · Start your DevOps journey: https://dmi.pravinmishra.com/?utm_source=student&utm_medium=ps-linkedin&utm_campaign=cohort3

Automating Linux Tasks with Bash

Adeje Oluwatobiloba — Wed, 22 Jul 2026 13:15:39 +0000

"Every repetitive task is an opportunity waiting to be automated."

One of the biggest lessons I've learned this weeek in the DevOps Micro Internship (DMI) is that automation begins with understanding the manual process.

Working in production support exposed me to many routine operational tasks. Whether it was gathering system information, validating files and directories, or running the same Linux commands repeatedly, I realized that many of these activities followed a predictable workflow. Although these tasks are essential for maintaining production environments, performing them manually can be time-consuming, inconsistent, and prone to human error.

This realization made learning Bash scripting more than just another technical exercise, it became an introduction to how automation solves real operational challenges.

Understanding Bash

Before writing scripts, I first learned the difference between a shell and Bash.

A shell is a command-line interpreter that allows users to interact with the operating system. Bash (Bourne Again Shell) is one of the most widely used Unix/Linux shells, offering features that make scripting powerful and flexible.

One important lesson was verifying the Bash version before writing scripts. Different Bash versions support different features, and writing scripts for the correct version helps avoid compatibility issues across Linux environments.

Importance of the shebang:

#!/bin/bash

This tells the operating system to execute the script using the Bash interpreter.

Before running a script directly, execute permissions must also be granted using:

chmod +x script.sh

This allows the operating system to execute the file as a program.

Building Scripts with Variables

Variables are one of the simplest but most important concepts in Bash scripting.

Instead of hardcoding values throughout a script, variables allow information to be stored once and reused multiple times.

For example, storing usernames, directories, or file paths inside variables makes scripts easier to maintain because updates only need to be made in one location.

Accessing variable values using the $ symbol also makes scripts dynamic and reusable.

Managing Multiple Values with Arrays

As scripts become larger, managing multiple values individually becomes inefficient.

Arrays solve this problem by storing multiple related items under a single variable.

Instead of creating several variables, I learned how arrays simplify data management while making loops much easier to implement.

This is particularly useful when working with multiple servers, directories, or applications that require the same operation.

Eliminating Repetition with Loops

One of the concepts that immediately demonstrated the value of automation was the for loop.

Rather than executing the same command repeatedly, a loop performs an action for every item in a list.

For example, instead of checking multiple directories manually, a loop can iterate through each directory automatically.

This simple concept significantly reduces repetitive work while making scripts shorter, cleaner, and easier to maintain.

Making Intelligent Decisions with Conditionals

Automation isn't only about repeating commands—it also requires making decisions.

Using if-else statements, scripts can respond differently depending on specific conditions.

During my exercises, I learned to:

Check whether files exist using -f
Verify directories using -d
Compare numbers using operators such as -ge
Execute different commands based on the results

These conditionals make scripts more reliable because they validate conditions before executing operations.

Organizing Code with Functions

As scripts become more complex, writing everything in a single block quickly becomes difficult to manage.

Functions solve this by grouping related commands into reusable blocks.

Instead of duplicating code throughout a script, a function can be written once and called whenever needed.

This improves readability, reduces maintenance effort, and makes debugging much easier.

Bringing Everything Together

The final assignment combined every concept into a single Bash automation script.

The script was designed to:

Display user and system information
Store values using variables
Manage collections with arrays
Repeat tasks using loops
Verify files and directories
Make decisions with conditionals
Organize reusable logic using functions

Although these are foundational Bash concepts, together they represent the building blocks of automation used across Linux administration, DevOps workflows, cloud infrastructure, and production support.

Key Takeaways

One thing this assignment reinforced is that automation is not simply about writing scripts.

Automation starts with understanding the manual process. Once the workflow is fully understood, repetitive tasks can be transformed into reusable, reliable, and consistent scripts.

As someone beginning a career in DevOps, this has changed the way I think about operational work. Instead of asking, "How do I perform this task?", I now find myself asking, "How can I automate this task safely and efficiently?"

Bash scripting is only one piece of the DevOps ecosystem, but it provides a strong foundation for future topics such as Infrastructure as Code, CI/CD pipelines, configuration management, cloud automation, and production engineering.

This is just the beginning of my automation journey, and I'm excited to continue building tools that simplify operations, improve reliability, and reduce manual effort.

How the Internet Works: A Beginner's Guide to Networking from Browser to Server

Adeje Oluwatobiloba — Wed, 22 Jul 2026 12:39:35 +0000

Learn how DNS, IP addresses, TCP/IP, packet switching, and HTTPS work together when you visit a website.

"You can't troubleshoot what you don't understand. For a DevOps Engineer, networking isn't optional, it's the foundation behind every deployment, API call, and cloud service."

When I first started learning DevOps, networking felt overwhelming. I could memorize terms like DNS, IP Address, TCP/IP, and HTTP/HTTPS, but I struggled to understand how they worked together. I knew the definitions, but I couldn't visualize what actually happens when someone types a website address into a browser.

To make learning easier, let's use an imaginary online bookstore called EpicReads.

The Journey Begins

Imagine you open your browser and type:

https://epicreads.com

From your perspective, it's just a website address.

Behind the scenes, however, several networking technologies work together in just a few milliseconds to deliver the webpage to your screen.

Let's walk through that journey step by step.

Step 1: DNS Finds the Server

The first question your browser asks is:

"Where is epicreads.com?"

Browsers cannot communicate using names like epicreads.com.

They communicate using IP addresses.

This is where DNS (Domain Name System) comes in.

Think of DNS as the internet's phonebook.

It translates:

epicreads.com

into something computers understand:

52.172.142.222

This translation happens because of a DNS A Record, which maps a domain name directly to an IPv4 address.

Without DNS, we'd have to memorize long strings of numbers every time we wanted to visit a website.

Step 2: Connecting to the Server

Now the browser knows where the server lives.

It begins communicating using the TCP/IP protocol suite.

This consists of two major protocols:

IP (Internet Protocol)

IP is responsible for routing data to the correct destination.

Think of it as the address written on a package.

TCP (Transmission Control Protocol)

TCP ensures that every piece of data arrives safely, completely, and in the correct order.

Think of TCP as the delivery company making sure every package reaches the customer without anything missing.

Together, TCP/IP forms the foundation of internet communication.

Step 3: Packet Switching

The browser doesn't send one huge request.

Instead, it breaks the request into many smaller pieces called packets.

This process is known as Packet Switching.

Each packet can travel through different routers and network paths.

Some packets may even arrive before others.

TCP keeps track of every packet and puts them back together once they reach the destination.

This makes the internet faster, more efficient, and more resilient.

Step 4: HTTP and HTTPS

After reaching the server, the browser sends an HTTP or HTTPS request.

These protocols define how browsers and web servers communicate.

Today, almost every website uses HTTPS because it encrypts communication between the browser and the server.

That encryption protects information such as:

Passwords
Credit card details
Personal information
Login sessions

Without HTTPS, anyone intercepting the traffic could potentially read the transmitted data.

Step 5: The Server Processes the Request

The request finally reaches the EpicReads web server.

The server may:

Retrieve available books
Check user accounts
Read shopping cart information
Process orders
Query the database

Once everything is ready, the server creates a response and sends it back to your browser.

Step 6: The Browser Displays the Website

The response also travels across the internet using Packet Switching.

TCP checks that every packet arrives successfully.

The browser reassembles the packets, interprets the HTML, CSS, and JavaScript, and finally displays the EpicReads homepage.

All of this typically happens in less than a second.

Putting It All Together

When you understand this flow, networking becomes much less intimidating.

Conclusion

Networking is one of the most important skills for anyone pursuing a career in DevOps, Cloud Engineering, or Site Reliability Engineering.

At first, it can feel like a collection of disconnected terms and protocols. But once you understand how DNS, IP addresses, TCP/IP, Packet Switching, and HTTPS work together, the internet starts to make much more sense.

If you're just beginning your DevOps journey, don't focus solely on memorizing definitions. Focus on understanding the complete flow of a request—from your browser to the server and back again.

That's when networking truly starts to click.

# Reflection – Week 2

Adeje Oluwatobiloba — Fri, 10 Jul 2026 09:23:11 +0000

"Shifting from Prompt Engineering to Infrastructure Orchestration"

Week 2 was a mix of excitement, curiosity, and a little bit of frustration. I learned a lot of new concepts, but I also realized that the best way to understand them is by actually trying them out. Reading or watching tutorials helps, but experimenting with the tools made everything click for me.

One of the topics I enjoyed learning about was Claude Code. Before this week, I mainly thought of AI as something that answers questions or helps write content. Seeing how Claude can assist with coding, debugging, and understanding projects made me see it differently. It feels less like a search engine and more like someone you can work with while building something. That really changed how I think about using AI in development.

Another interesting topic was Skills. I liked the idea that you can give an LLM specific skills so it behaves more like a specialist instead of a general assistant. It made me realize that the quality of the output doesn't only depend on the model itself, but also on how you guide it and what tools or skills you give it. That was something I hadn't really thought about before, and I can already see how useful it could be for different types of projects.

I also learned about Subagents, which was a new concept for me. At first, I didn't really understand why you would need multiple agents instead of just asking one AI to do everything. But after learning more about it, I started to see the benefit. Having different agents focus on different tasks seems like a much cleaner and more organized way to work, especially for bigger projects.

The biggest challenge I faced this week was running out of tokens while practicing. It happened a few times, and honestly, it was a little annoying because I would be in the middle of exploring an idea and suddenly had to stop. Even though it was frustrating, it also made me think more carefully about how I write prompts and how I use my conversations. I learned that being clear and intentional can make a big difference.

Despite the challenges, there was one moment this week that I’m really proud of. I was working on setting up infrastructure, and seeing my Terraform files get generated automatically by the AI felt incredible. However, it didn't work perfectly right away and threw an error. Instead of panicking or blindly asking the AI to fix it, I took a step back, read the error output carefully, and figured out how to fix it myself. Actually understanding what went wrong and resolving it was a huge confidence booster.

This week also changed my mindset a bit. I realized that it's okay not to understand everything immediately. Some of the concepts felt overwhelming at first, but after trying them myself, they became much easier to understand. I'm starting to feel more comfortable experimenting instead of worrying about getting everything right the first time.

Going forward, one habit I want to build is working on more hands-on projects with Claude instead of only learning the theory. I think building small projects and experimenting with different features will help me remember what I've learned much better than just reading about them. I also want to keep challenging myself by trying new ideas, even if they don't work perfectly on the first attempt.

Overall, Week 2 helped me see AI as more than just a tool for answering questions. I'm beginning to understand how it can become a real partner in learning and building projects. There were definitely some challenges along the way, but they were part of the learning experience, and I'm looking forward to seeing what I'll be able to build as I keep practicing.

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/Tobilee10.html · Start your DevOps journey: https://dmi.pravinmishra.com/?utm_source=student&utm_medium=ps-linkedin&utm_campaign=cohort3

DevOps Success Mindset

Adeje Oluwatobiloba — Thu, 02 Jul 2026 21:37:08 +0000

The DevOps Mindset: Build Yourself Before You Build Systems

We often measure growth in DevOps by the tools we know namely Docker, Kubernetes, Terraform, GitHub Actions, Ansible, cloud platforms, and everything in between. While mastering these technologies is important, they're only part of the equation.

The most valuable system you'll ever build isn't running in the cloud. It's the one that shapes how you think, learn, solve problems, and grow as an engineer.

Tools will change. Principles won't.

Here's the mindset that has become increasingly important to me as I continue my journey in DevOps.

Long-Term Thinking
There are no overnight experts in DevOps.
Every deployment, failed pipeline, production issue, and late-night debugging session teaches something valuable. These experiences compound over time, shaping both your technical skills and your confidence.
Instead of chasing rapid progress, focus on becoming slightly better every day. Consistency will always outperform short bursts of motivation.
Remember: careers are built one commit, one project, and one lesson at a time.
Think Like an Engineer, Not Just a Tool User
Knowing commands is useful. Understanding systems is invaluable.
Great engineers don't jump straight to solutions—they investigate first. They rely on logs, metrics, monitoring data, and evidence instead of assumptions. They ask why before asking how.
When something breaks:
a. Stay calm.
b. Gather information.
c. Identify the root cause.
d. Improve the system so the same problem is less likely to happen again.
DevOps isn't about fixing the same issue repeatedly; it's about building systems that prevent it from happening in the first place.
Build More Than You Consume
Tutorials are a great starting point, but they shouldn't be your destination.
The fastest way to grow is to build.
Create projects that challenge you. Experiment with new technologies. Break things in your lab environment. Document your discoveries, even when they don't go as planned.
Every GitHub repository, technical article, and project becomes evidence of your progress.
Your portfolio should speak before your résumé does.
Protect Time for Deep Work
Modern engineering comes with endless distractions—notifications, meetings, social media, and constant context switching.
Real progress happens when you dedicate uninterrupted time to meaningful work.
Whether you're debugging Kubernetes, writing Terraform modules, or designing a CI/CD pipeline, focus on one important objective at a time.
Quality engineering requires attention, not multitasking.
Stay Curious and Adaptable
Technology evolves faster than job titles.
The tools you rely on today may be replaced tomorrow, but the ability to learn will always remain valuable.
Be willing to question old habits, embrace better practices, and remain teachable regardless of your experience.
The best engineers don't know everything.
They simply never stop learning.
Collaboration Is a DevOps Superpower
DevOps isn't just about automation.
It's about people.
The best solutions emerge from clear communication, thoughtful documentation, constructive feedback, and shared ownership.
Write documentation that helps the next engineer.

Review code with respect.
Share knowledge freely.
Celebrate team success, not just individual achievement.
Strong systems are built by strong teams.
Measure Progress, Not Perfection

At the end of each week, ask yourself:

Did I build something meaningful?
Did I learn something new?
Did I improve an existing process?
Did I document or share what I learned?
Did I help someone else grow?
Did I take care of my health and maintain a sustainable pace?

You don't need a perfect week.
You just need more good weeks than bad ones.

Final Thoughts
DevOps is often associated with automation, cloud infrastructure, containers, and deployment pipelines.
But beneath every reliable system is an engineer who has developed discipline, curiosity, resilience, and a commitment to continuous improvement.

Invest in your technical skills.
Invest even more in your mindset.
Because tools will evolve, platforms will change, and frameworks will come and go.
A growth mindset, strong engineering principles, and consistent execution will remain your greatest competitive advantage.
Build systems that scale.
Build habits that last.
And never stop building yourself.

What mindset has had the biggest impact on your growth as an engineer? I'd love to hear your thoughts in the comments.