WEEK 4: BUILDING A SAFER DEVOPS WORKFLOW WITH GIT AND AGENTIC AI

This week of my DevOps journey was focused on something that is easy to overlook when learning how to build and deploy software: safety.

It is one thing to know how to use Git, create branches, commit changes, push code, and open Pull Requests. It is another thing to build a workflow that can identify risky changes before they make their way into a repository.

For Week 4 of the DMI program, I worked on an AI assisted Git safety workflow that combined traditional rule based automation with Claude Code. The goal was not simply to automate everything, but to understand where automation is useful, where AI adds value, and where human judgment must remain in control.

STARTING WITH A CLEAN GIT WORKFLOW

I began by working with my fork of the internship repository and creating a dedicated feature branch called feature/ai-pr-ready.

Using a separate feature branch gave me a controlled environment for the assignment. It kept my work isolated from the main branch and made it easier to review exactly what I was changing.

I also verified the relationship between my fork and the upstream repository. This was important because the Pull Request needed to target my own fork rather than the shared upstream repository.

That small step reinforced an important Git principle: knowing where your changes are going is just as important as knowing what you are changing.

BUILDING A GIT PRE COMMIT SAFETY NET

The first major part of the assignment was creating a Git pre commit hook.

The idea behind the hook was simple. Before Git creates a commit, the hook examines the staged files and checks them for specific risky patterns.

For this exercise, I created a notification script containing an intentionally fake AWS access key and a debug statement.

The credential was deliberately fake because using a real AWS credential for a security exercise would be extremely dangerous. The purpose was to reproduce a realistic mistake in a controlled environment without exposing an actual account.

I then configured Git to use a tracked hooks directory instead of relying on the default local .git/hooks directory.

This was an important lesson because a tracked hook can live inside the repository and be shared with other developers. It turns the safety rule into part of the project rather than something that exists only on one developer’s computer.

SEEING THE SAFETY CHECK ACTUALLY WORK

The most useful part of the exercise was testing the hook.

When I attempted to commit the staged notification script, the pre commit hook detected the secret like pattern and rejected the commit.

Instead of allowing the risky change to enter the Git history, the hook displayed a BLOCKED message and stopped the commit.

This demonstrated the value of fixed rule based automation.

The hook does not need to understand the entire project or make a complicated judgment. It simply enforces a predefined rule consistently every time a commit is attempted.

That gave me a practical understanding of why security checks are often placed as early as possible in a development workflow.

ADDING AI ASSISTED REVIEW WITH CLAUDE CODE

After establishing the fixed safety rule, I added a Claude Code /pr-ready skill.

The purpose of this skill was different from the pre commit hook.

Instead of simply blocking a known pattern, /pr-ready reviews the staged Git changes and provides a broader assessment of the changes before a Pull Request is created.

The skill was designed to inspect the staged files and staged diff, look for potential risks, and then produce a risk report along with a proposed Pull Request title and description.

I also made the skill read only by giving it Bash, Read, and Grep as its allowed tools while deliberately excluding Write.

This was an important safety decision.

The AI was allowed to inspect and reason about the changes, but it was not given permission to modify files. It also was not responsible for committing, pushing, or opening Pull Requests.

FIXED RULES AND AI REVIEW SERVE DIFFERENT PURPOSES

One of my biggest takeaways from this exercise was understanding that the pre commit hook and AI review are not competing systems.

They complement each other.

The pre commit hook provides a fixed safety gate. If a defined rule is violated, the commit is blocked.

The /pr-ready skill provides contextual analysis. It can look beyond a single pattern and identify things such as debug statements, accidental files, suspicious changes, and other potential risks.

In my test, the hardcoded credential was caught by the fixed rule, while the AI review also identified the debug statement and provided a broader assessment of the staged changes.

This showed me why relying on only one type of protection is not ideal.

Rules are consistent and predictable, while AI can provide additional context and reasoning.

FIXING THE PROBLEM AND VERIFYING AGAIN

After the risky commit was blocked, I fixed the notification script.

I removed the hardcoded fake AWS access key and removed the debug echo statement that exposed the value.

I staged the corrected file again and attempted the commit.

This time, the pre commit hook allowed the commit to proceed because the problematic content had been removed.

I then ran /pr-ready again.

The second review produced a clean risk assessment and generated a Pull Request title and description based on the updated changes.

This before and after process was particularly useful because it demonstrated that security checks are not only about detecting problems. They are also about fixing, rechecking, and proving that the problem has been resolved.

CREATING THE PULL REQUEST

Once the changes had passed the checks, I pushed the feature/ai-pr-ready branch to my GitHub fork.

I then created a Pull Request targeting my own fork.

One important lesson here was the need to critically review AI generated content before using it.

The /pr-ready skill generated a Pull Request title and description, but I still had to verify that the information was accurate and actually represented the work I had done.

AI can produce useful drafts, but a draft is not automatically a fact.

A human still needs to check it.

WHY AI SHOULD NOT CONTROL EVERY GIT ACTION

This assignment also changed how I think about Agentic AI in DevOps.

It can be tempting to give an AI agent permission to perform an entire workflow automatically. However, sensitive operations such as committing code, pushing to a repository, and creating Pull Requests should not simply happen because an AI decided they should.

The workflow I built follows a much safer pattern:

Gather → Analyze → Human Act → Verify

Git provides the information about the staged changes.

The AI analyzes those changes and provides recommendations.

I remain responsible for deciding what should be changed and for performing the important Git operations.

The automated checks then verify the result.

This creates a balance between automation and human control.

WHAT I LEARNED ABOUT AGENTIC AI

Before this assignment, it was easy to think of Agentic AI mainly as something that performs tasks on your behalf.

This week showed me another way to think about it.

A good AI assisted workflow does not necessarily mean giving the AI unlimited control.

Sometimes the better design is to give the AI enough access to observe, analyze, and advise, while deliberately keeping important actions under human control.

That distinction is especially important in DevOps because a single incorrect action can affect repositories, deployments, infrastructure, credentials, or production systems.

The goal should therefore not be to remove humans from the workflow.

The goal should be to use automation and AI to help humans make better and safer decisions.

FINAL TAKEAWAYS FROM WEEK 4

This week taught me several practical lessons:

1. Fixed rules are valuable because they provide consistent safety barriers.
2. AI assisted review adds context that simple rule based checks may not provide.
3. AI generated recommendations should always be reviewed before they are acted upon.
4. Sensitive Git operations should remain under human control.
5. Security checks are most useful when they run early and are followed by another verification after problems are fixed.
6. Agentic AI does not have to mean unrestricted AI autonomy. A well designed workflow can deliberately limit what an AI agent is allowed to do.

CONCLUSION

Week 4 was less about writing a large amount of code and more about understanding how to build a safer engineering workflow.

I combined a traditional Git pre commit safety mechanism with an AI assisted Pull Request review system. The fixed rule prevented a risky commit, while Claude Code provided broader analysis and helped prepare the Pull Request.

Most importantly, I learned that the strongest workflow is not necessarily the one with the most automation.

It is the one where automation catches what it is designed to catch, AI provides useful judgment and context, and the human remains responsible for the final decision.

That is a lesson I will carry forward as I continue learning DevOps, cloud engineering, and Agentic AI.

Badge Page: https://dmi.pravinmishra.com/s/ikechukwuemmanuel2024-source.html⁠�

DevOps #CloudComputing #Networking #git #github #codetrack #Linux #CloudEngineering #LearningInPublic #DMI

Connect with me on LinkedIn: www.linkedin.com/in/ikechukwu-emmanuel

Become a Medium member P.S. This post is part of my DevOps Micro Internship with Agentic AI Cohort-3 by Pravin Mishra.

If you’re beginning your own DevOps journey, you’re welcome to join the community:

Discord: https://discord.pravinmishra.com/ Pravin Mishra (LinkedIn): https://www.linkedin.com/in/pravin-mishra-aws-trainer/