Every technical guide we publish goes through several independent checks — and each time, that process reveals something a little different about how humans and AI work together. Our recent LiteLLM Proxy upgrade guide had already been through multiple drafting-stage review passes before it was considered finished. Then Alexander Eichmann, our DevOps Engineer, put the finished guide through his own pass and caught things those earlier passes had missed. Then, while implementing his feedback, Maria Sivenkova, our Senior Technical Communicator, and her AI collaborator found a further issue neither the drafting passes nor Alexander’s review had caught.
We sat down with Alexander to talk about his path into DevOps and infrastructure, how AI fits into his work, and what actually broke when he dug into the guide.
What drew you to DevOps and infrastructure work?
I started out as a software engineer, writing code without paying much attention to everything that actually gets it running: deployment, pipelines, the infrastructure underneath. Over time I got curious about that hidden half and started digging into it, and it pushed me to see beyond the code itself. The domain turned out to be surprisingly broad: I get to tinker with servers, tooling, and operational engineering. It’s deeply technical work, and I genuinely enjoy it.
What do you like about this kind of work?
The learning never ends. There’s always something new to dig into. A performance problem can send me down an OS-level rabbit hole, while an operational one has me picking apart a broken process to work out how to fix it. No two problems look quite the same, and that variety is exactly what keeps it interesting.
What’s actually changed about your work in the AI era?
AI has made me a lot more efficient. Infrastructure work, like most engineering, comes down to planning and implementation. On the planning side, I use AI agents to help map out a project, surfacing possible blockers and edge cases earlier than I would on my own, then verifying those findings myself. On the implementation side, it streamlines the actual coding. But efficiency doesn’t remove the responsibility as everything still gets verified and thoroughly tested before it goes anywhere near production. Trust, but verify.
Where’s the field heading, in your view?
I think infrastructure work gets more streamlined with less grunt work, better planning, more of the repetitive toil handed off to AI. That frees us up to focus on the harder, higher-leverage problems: architecture, reliability, and the judgment calls AI can’t make on its own. The tooling around infra-adjacent work will keep expanding, and the field will adapt to it the same way it adapted to the cloud and containers. The bottleneck moves from “doing the work” to “deciding what’s worth doing and checking it’s right.”
Walk us through catching the issues in the LiteLLM runbook.
You reviewed our tutorial on upgrading LiteLLM Proxy to patch an authentication-bypass CVE. What was your actual process — did you test this against a real deployment, walk through it with AI assistance, something else? And what turned out to be wrong?
I wrote a prompt for an AI agent to simulate the walkthrough: provision the example target (LiteLLM) in a sandbox environment and actually run the commands from the runbook, step by step. The agent checks whether each command works and flags issues in the logic, wording, and so on, then produces a summary of what it found. From there, I go through that summary manually to confirm each item is real before acting on it.
It did catch some genuine command issues. It also flagged things that turned out not to be problems at all — and that’s exactly where the human part comes in. The agent is good at surfacing candidates fast, but deciding what’s actually a bug is still on me.
After your review, we caught something else while implementing your feedback. The same fact was stated two different ways in two parts of the document, and the more accurate version was sitting right next to the weaker one the whole time. Does that match anything you’ve run into in infrastructure work — a case where you only catch a problem because you’re looking at two things side by side, not because either one looks wrong on its own?
Definitely. A lot of debugging in infrastructure comes down to correlating multiple signals rather than trusting any single one. A deployment can fail because two or three conditions line up in a way that looks completely fine individually. Every metric is green, every config looks right, and the problem only shows up when you put them side by side and notice they don’t agree. So a document that reads correctly section by section while two parts quietly contradict each other doesn’t surprise me at all. That’s the kind of thing you only catch by comparing, not by reading straight through.
Shares to Social Media
