Claude Code as an Operational Partner for DevOps
People are building incredible things with AI coding tools. Custom applications, full-stack prototypes, automation pipelines. But there's a quieter, equally powerful use case: using Claude Code as an operational partner.
I've written before about using Claude Code for personalized software, and I still think that's a great use case. But some of the highest-value work I do with it never results in committed code at all.
DevOps Work Is Half Investigation
Here's a reality about DevOps that people outside the discipline don't appreciate: most of the work doesn't result in checked-in code. Research from Garden.io found that engineers spend over 15 hours per week on non-coding tasks like maintaining tooling, debugging pipelines, and setting up environments, compared to just 4.5 hours writing application code. Kubernetes operations, Argo deployments, metric crawling, cloud bill investigation, diagnostic scripts, environment analysis. Small tasks need to get done, discussed, and iterated on.
Some of this work does result in code changes. Helm chart modifications, Argo configurations, infrastructure-as-code updates. That's great because it lives in a repo. But much of DevOps work is investigative. The work requires analysis, scripts, and data, but the end result is a decision or an insight, not a pull request.
Or consider another pattern: analysis that, combined with knowledge of the codebase, leads to very targeted code changes. The investigation itself is the heavy lift. The resulting code change might be a single line.
This is exactly where Claude Code excels as a partner.
Read-Only Access Changes Everything
The biggest unlock for operational AI partnership is giving Claude Code read-only access to diagnostic information. Whether you're using AWS CloudWatch, GCP monitoring, Prometheus, or similar tools, connecting Claude to those data sources lets it investigate independently. Building monitoring tools that serve the operator's actual workflow is critical, which is why monitoring platform design matters.
The goal is building larger closed feedback loops. Every additional read-only data source you connect expands the scope of what Claude can investigate without you manually copying and pasting results.
When Claude can query metrics directly, it can form a hypothesis, check the data, refine the hypothesis, and check again. That loop, which would otherwise require you to run each query and relay the results, happens automatically.
Note that you must consider what PII and types of access you are giving Claude before providing prod diagnostic data. Doing this safely (read only) and securely (understanding the data in those logs and metrics) is critical.
The Partner Model, Not the Autopilot Model
The boundary matters in how I use this. I don't give Claude direct access to Kubernetes. Instead, we work together in one of two patterns.
The first pattern is script generation. Claude writes analysis scripts, I review them, I execute them, and I give Claude the results. This keeps me in the loop on what's running in my environment while letting Claude handle the tedious parts of writing and iterating on those scripts.
The second pattern is command generation. Claude generates kubectl commands or diagnostic queries, I run them directly, and I provide the results back. This is particularly useful for complex commands with multiple flags or piped operations that I'd otherwise spend time looking up or composing manually.
Both patterns maintain human oversight while dramatically accelerating the pace of investigation. Claude handles the generation and analysis. I handle the execution and judgment calls.
Giving read-only access through commands like this is difficult. That's why I opt for script generation.
Practical Applications
Production metric analysis: Checking metrics before and after a performance improvement used to mean pulling up dashboards, comparing time ranges, and eyeballing trends. With Claude as a partner, I can describe what I'm looking for and have it build queries that systematically compare the relevant metrics. The key is focusing on the right signals rather than getting lost in dashboard proliferation.
Cloud bill investigation: This remains one of the highest-value applications. According to Flexera's 2025 State of the Cloud Report, 84% of organizations say managing cloud spend is their top cloud challenge, with budgets already exceeding limits by 17%. Cloud cost analysis requires correlating spend data with architectural context. Claude can process cost reports, cross-reference them with what it knows about the infrastructure, and surface anomalies that would take hours to find manually.
Kubernetes diagnostics: A Rafay Systems survey of over 2,000 professionals found that 93% of enterprise platform teams face persistent challenges managing Kubernetes complexity and costs. Whether it's debugging pod scheduling issues, analyzing resource utilization patterns, or investigating network policies, Claude can help generate the right commands and interpret the output. The back-and-forth of "here's what I see, what should I check next" becomes a structured diagnostic conversation. Well-designed alerts reduce the ad-hoc investigation needed, though even imperfect alerting beats reactive hunting.
Each of these tasks involves real investigation. There's no single command that gives you the answer. It's iterative, context-dependent work that benefits enormously from having a partner who can hold the full picture in memory while you work through it together.
The Broader Point
What I find interesting is how many of the highest-value AI coding applications aren't about writing application code at all.
Operational partnership is yet another non-code way to use AI effectively. Not building features. Not writing production code. Just doing operational work more effectively with a partner that can hold context, generate scripts, analyze data, and iterate alongside you.
If you're only using AI coding tools to write code, you're missing the larger opportunity. Google's 2024 DORA report found that AI adoption in code generation actually correlated with a 7.2% decrease in delivery stability, largely because AI makes it easy to produce larger, riskier changesets. The operational partnership model sidesteps this problem entirely. When AI handles investigation and generation while you handle execution and judgment, the value comes from better analysis and faster iteration, not from shipping more code.
Getting Started
If you want to try this approach, here's where to begin:
- Name your threads. Start naming Claude Code threads by ticket number or operational task. The ability to resume context is the foundation of the partnership model.
- Connect read-only data sources. Give Claude access to your monitoring and observability tools. Even one additional data source creates a feedback loop that multiplies its usefulness.
- Start with investigation tasks. Pick an operational task that requires analysis rather than code changes. Cloud cost review, metric comparison, or diagnostic investigation are all good starting points.
- Keep execution in your hands. Review scripts before running them. Run commands yourself and provide results. The value is in the generation and analysis, not in autonomous execution.
The more closed feedback loops you create, the more effective the partnership becomes. Start small, expand the loops, and you'll quickly find that your operational work moves faster with a partner that never loses context.
Related Content
