Staying behind on tech trends can be a career killer.

But let’s face it, no one has hours to spare every week trying to stay updated.

That’s why over 100,000 engineers at companies like Google, Meta, and Apple read The Code twice a week.

Here’s why it works:

Join 100,000+ engineers who read The Code to stay ahead of the curve.

Hey {{first name | there}},

If you had asked me a couple of months ago, I would have bet a substantial amount (probably not) that I would not be writing this, but the times are indeed changing.

Welcome to this week’s edition of technical notes from Jubril, and today I’d like to distill some of my thoughts about AI agents and how I am approaching them for DevOps.

Was this email forwarded to you? Subscribe here to get your weekly updates directly into your inbox.

Agents, as it relates to AI, are systems or programs that are capable of autonomously performing tasks on behalf of a user or another system. It is a little bit uncanny that we are at a point where this is even a thing, but it is also intriguing from a technical point of view.

So far, I have tried out cursor-cli and, unsurprisingly, Claude Code. For the rest of this issue, when I refer to agents, you can safely assume that I am using Claude Code as a reference, as it is what I have spent the most time with.

Well, I am no machine learning expert or historian, but somewhere along the line, we realized we could take existing large language models and run them such that they operate continuously until they accomplish a particular task, all with little human intervention.

This premise makes it a huge red flag for infrastructure and DevOps, yet here I am writing this issue.

To be clear, this is not a “Go ALL IN ON AI” or “Adapt or die” post. In fact, I am largely still on the fence; however, it would be dishonest not to give agents a shot, considering how fast things are changing.

Ansible was one of the very first configuration management tools I picked up; as such, it has stuck in my toolbox as I progressed through my career.

One of the very first things I tried was to see how much boilerplate I could avoid writing by getting Claude Code to do the grunt work instead.

This is typically the part where I tell you it one-shotted it, and you should give up on writing YAML forever. Well, sadly, this was far from the case. In my testing, I noticed I got the best results when I provided an existing structure for it to work with.

For example, I typically separate installation of core system utilities and general packages into two different files. This not only makes it easier for me to read, but shockingly, the agent was able to replicate this pattern when I asked it to create a similar file for installing a specific package.  

If you’d like to see what that looks like, take a peek at this directory in my homelab repository 

Obviously, your mileage might vary as the project grows, but for now, it’s nice to be able to offload bootstrapping while I think of higher-level goals for a project.

So far, I have found “AI-powered” auto-complete pretty distracting, as it tends to break my flow, especially in existing codebases. However, a neat use case I have found is obtaining information on what parts of a codebase control specific behaviour.

For instance, if you were dropped into a new codebase and needed to figure out what package controlled storage based on region, you could ask an agent for some good starting points of where to look. 

This has worked well for the most part, even in larger codebases; however, I fear the main drawback is losing some of the mental mapping you create by stumbling from package to package. Regardless, it’s always useful when you are in a pinch.

Far from it. My opinion is shifting daily, and while I think a lot of the hype/marketing around agents is suppressing some of the reasonable use cases, I do think it is worth giving a shot.

I have been reading some interesting takes from a few folks around the web; here are some of the best ones I have found.