What 48 Tracked Sessions Taught Me About AI in IT Operations

Ninety-one hours. That’s how long I spent building what would have taken 605 to 873 hours to build manually. I know those numbers precisely because I tracked every session, every deliverable, and every time-saving estimate across 48 working sessions over four months.

I didn’t set out to become an advocate for AI-augmented IT operations. I set out to build a comprehensive enterprise lab infrastructure , the kind that would demonstrate modern architecture patterns, not just a handful of VMs running on a shelf. What I discovered along the way changed how I think about the future of our profession.

The Numbers Don’t Lie (But They Don’t Tell the Whole Story Either)

Let me start with the hard data, because if you’re an IT leader worth your salt, you demand evidence before changing your mind about anything.

Over the course of these 48 sessions, working with an AI-augmented operations platform, I built:

• 45+ comprehensive documentation pages in a MediaWiki instance
• 8 custom API servers providing 336 integration tools
• 20 reusable automation skills mapped to common tasks
• 8 standard operating procedures that actually get followed
• A complete NetBox IPAM/DCIM implementation tracking 56 physical devices and 15 VMs
• A Naemon monitoring system covering 65 hosts
• Centralized Loki logging infrastructure spanning 13 hosts with 8 custom dashboards
• A hardware library system with Python automation and NetBox synchronization
• Full network access control architecture with custom Ansible collection
• pfSense migration plan and API integration for next-generation firewall management

The productivity multiplier averaged 7-10x across all task categories. But here’s where it gets interesting: that average masks enormous variation. Routine configuration work? Maybe 5-6x faster. Architecture research and documentation? 25-40x faster.

Think about that for a moment. Some tasks saw productivity gains that would have seemed like science fiction five years ago.

AI Doesn’t Replace Expertise. It Amplifies It

Here’s the part that the “AI will replace everyone” crowd gets catastrophically wrong: my 30 years in IT operations didn’t become less valuable when I started working with AI-augmented tooling. They became more valuable.

Every hour I spent with this platform was an hour of making hundreds of micro-decisions: Is this architecture pattern appropriate for my use case? Does this configuration align with enterprise best practices? Is this documentation accurate and maintainable? Will this automation framework scale beyond my immediate needs?

The platform could generate configuration files, write documentation, and even architect solutions. But it was my experience that made those outputs correct. I knew when to accept a suggestion, when to refine it, and , critically when to reject it entirely and provide better direction.

This isn’t pair programming in the traditional sense. It’s more like having an impossibly knowledgeable junior engineer who has read every manual, every best practices guide, and every Stack Overflow thread , but who still needs an experienced architect to provide context, constraints, and quality control.

Documentation: From “We’ll Do It Later” to “It Happens Automatically”

If you’ve led IT operations for any length of time, you know the documentation problem. Everyone agrees it’s critical. No one wants to write it. It falls behind reality within weeks. Critical knowledge lives in someone’s head, and when they leave, that knowledge walks out the door with them.

This approach obliterated that problem.

During a typical session, I might implement a new monitoring automation pipeline. In the old world, I’d make mental notes to “document this later,” and six months down the road, I’d be staring at my own configuration wondering what past-me was thinking.

With the integrated platform, documentation became part of the implementation process. As we built the NetBox-to-Naemon automation architecture, we simultaneously created comprehensive documentation pages: architecture diagrams, data flow tables, API endpoint references, troubleshooting guides. The documentation was often complete before the implementation, serving as a blueprint.

I ended up with 45+ wiki pages covering everything from hardware specifications to standard operating procedures. These aren’t token README files , they’re comprehensive, properly formatted, interlinked documentation that actually gets referenced and updated.

The Architecture Multiplier: Where Automation Really Shines

The highest productivity gains , 25-40x on some tasks , came from architecture research and planning work. This surprised me at first, but it makes perfect sense in retrospect.

Consider what architecture research looked like in the old world: hours of reading vendor documentation, combing through GitHub issues, cross-referencing best practices from multiple sources, synthesizing patterns from blog posts and conference talks. It’s high-value work, but it’s extraordinarily time-consuming.

The AI component had already processed all of those sources. When I asked about implementing network access control with dynamic VLAN assignment, it could immediately synthesize patterns from UniFi documentation, IEEE 802.1X standards, Ansible best practices, and real-world deployment experiences. What would have taken me three days of research happened in an hour-long conversation.

But , and this is crucial , the AI didn’t make the architectural decisions. I did. The platform presented options, explained trade-offs, and highlighted considerations I might have missed. I evaluated those options against my specific requirements, constraints, and risk tolerance. The decision-making remained firmly in human hands.

What AI Is Genuinely Bad At (And Why That Matters)

Let’s be honest about the limitations, because understanding them is just as important as understanding the capabilities.

AI struggles with genuinely novel problems in unfamiliar domains. When I hit an esoteric bug in a brand-new integration between two systems that had never been connected before, the suggestions were educated guesses at best. Pattern matching only works when you’ve seen the pattern before.

Physical troubleshooting remains firmly in human territory. “The server won’t POST” isn’t a problem any platform can solve. Neither is “the fiber connection is flapping” or “there’s an intermittent network issue that only happens on Tuesdays.”

And here’s the subtle one: AI can optimize for the requirements you give it, but it can’t intuit the requirements you forgot to mention. If I didn’t think to specify “this needs to survive a data center failover,” the platform wouldn’t design for that scenario. Completeness of requirements still depends on human experience and foresight.

Governance Makes Automation Sustainable

One of the most important discoveries from tracking 48 sessions: AI-augmented work requires more governance discipline, not less.

I built a framework around the operations platform: naming standards, project tracking methodologies, standard operating procedures, documentation templates. These weren’t bureaucratic overhead , they were force multipliers.

With clear SOPs, I could direct the platform to “create a new wiki page following SOP-DOC-001” and get consistently formatted, properly categorized documentation. With defined naming standards, infrastructure components were immediately recognizable and properly organized. With project tracking, nothing fell through the cracks across dozens of sessions.

Organizations that try to bolt AI onto chaotic operations will get chaotic outputs. Organizations that establish clear standards and procedures first will see genuine transformation.

The Uncomfortable Truth for IT Leaders

Here’s what 48 sessions and meticulously tracked metrics taught me about the future of IT operations:

In five years, the IT leader who has embraced AI-augmented operations and learned to direct it effectively will outperform the IT leader who hasn’t by an order of magnitude. Not 20% better. Not twice as good. Ten times more productive.

But , and this is the part that should comfort everyone worried about being replaced , that 10x multiplier only works if you have the experience to direct the tooling correctly, evaluate its output critically, and make sound architectural decisions. The multiplier applies to expertise. If you don’t have expertise, you’re just getting bad outputs faster.

Your 30 years of experience didn’t become obsolete. It became the most valuable it’s ever been, because now it can be applied across 10x the scope of work.

The question isn’t whether AI will change IT operations. It already has. The question is whether you’re going to develop the skills to harness that change, or whether you’re going to be outpaced by leaders who do.

I’ve spent 30 years in this profession. The last 91 hours taught me more about its future than the previous several years combined. The future is collaborative, it’s faster, it requires more governance discipline, and it rewards experience more than ever.

The infrastructure I built in 91 hours would have taken 605-873 hours manually. More importantly, it’s better documented, more consistent, and more maintainable than most infrastructure I built in the previous three decades.

That’s not a future to fear. That’s a future to embrace.

Want to discuss automation in IT operations, or see the infrastructure I built? Explore my Technology Lab or connect with me.