Claude Code for DevOps, SRE, and ML Engineers

Infrastructure and data work benefit disproportionately from Claude Code. The work is configuration-heavy and script-heavy, and it usually comes with fast, objective verification: a plan output, a dry run, a schema check. The risk is also higher, because a bad change can take down production or corrupt data. Fast verification and tight permissions are the whole game.

Ground rules for infrastructure work

• Claude may run plan, validate, lint, and dry-run commands. It may not run apply, deploy, or delete commands. Encode this in the permission denylist, not just in CLAUDE.md.
• Sessions never hold production cloud credentials with write access. Use read-only roles for investigation.
• Every change goes through the same pull request and pipeline as human changes.

{
  "permissions": {
    "allow": ["Bash(terraform fmt:*)", "Bash(terraform validate:*)", "Bash(terraform plan:*)",
              "Bash(kubectl get:*)", "Bash(kubectl describe:*)", "Bash(helm template:*)"],
    "deny":  ["Bash(terraform apply:*)", "Bash(terraform destroy:*)",
              "Bash(kubectl delete:*)", "Bash(kubectl apply:*)", "Bash(helm upgrade:*)"]
  }
}

Infrastructure as code

Strong uses for Terraform, Pulumi, and CDK:

• Writing new modules that match your existing module conventions
• Upgrading provider versions and fixing the deprecation fallout
• Reading a terraform plan and explaining every destroy or replace in plain language
• Finding drift between modules that should be identical across environments
• Adding tagging, encryption, and logging defaults across all resources

A useful prompt before any merge: "Read this plan output. List every resource that will be destroyed or replaced, why, and whether data could be lost." Then compare the answer to your own reading.

Pair Claude with deterministic policy tools such as Checkov, tfsec, or OPA. Run them in a hook so Claude fixes violations before you ever see the diff.

Kubernetes

Claude writes and reviews manifests and Helm charts well. Ask it to check every workload for resource requests and limits, liveness and readiness probes, non-root users, read-only root filesystems, and dropped capabilities. Validate with kubeconform or kubectl --dry-run=server against a non-production cluster.

For debugging, give it read-only kubectl access to a staging cluster and a symptom: "Pods in the payments namespace restart every few hours. Investigate and report likely causes with evidence."

CI/CD pipelines

Pipeline YAML is tedious to write and painful to debug. Claude is good at both. Pipe a failing job log in and ask for the root cause. Ask it to add caching, parallelize test shards, or pin third-party actions to commit SHAs, which is also a supply-chain win.

Incident response

During an incident, speed of understanding matters most. With logs, metrics, and the incident channel reachable through MCP:

1. "Summarize what we know so far as a timeline, with sources."
2. "Which deploys, config changes, or dependency updates happened in the hour before the first alert?"
3. "Propose the three most likely causes, ranked, with the evidence for and against each."

Keep a human as incident commander. Claude accelerates analysis; it does not make the rollback call.

Afterward, ask Claude to draft the postmortem from the timeline and channel, in your template. Then ask it to turn the action items into runbook updates, so the next on-call engineer benefits.

Runbooks and toil

Generate runbooks from incident history: "Read the last five incidents involving the queue workers and write a runbook covering detection, diagnosis, and mitigation for each failure mode." Review it with the engineers who handled those incidents.

For recurring toil, the skill pattern from Chapter 5 pays off quickly. A rotate-service-cert or add-new-service skill turns a forty-step wiki page into a repeatable procedure.

Cost analysis

Export billing data to CSV and ask Claude to analyze it with code, not by eyeballing. "Group spend by service and environment, find the top ten month-over-month increases, and list the resources behind each." Insist that it compute numbers with a script so the arithmetic is checkable.

Data pipelines

Claude handles Airflow DAGs, Dagster assets, and dbt models fluently. For dbt specifically, ask it to add tests for uniqueness, not-null, and accepted values on every new model, and to document columns as it goes. Point it at your existing models as the style reference.

Data quality work is a strong fit: "Profile this table, flag columns with unexpected nulls, outliers, or format drift, and propose dbt tests that would catch each."

Notebooks and ML work

Claude Code can read and edit Jupyter notebooks directly. Useful patterns:

• Turning an exploratory notebook into a clean, tested module and a training script
• Writing evaluation harnesses with fixed seeds and held-out data
• Adding experiment tracking calls to existing training code
• Reviewing training code for data leakage between train and test sets

That last one is worth making a habit. Leakage is easy to introduce and hard to spot, and a fresh-eyes review catches it more often than the author does.

Database access

Give Claude a read-only role on a replica or a sanitized copy, connected through MCP. It is excellent at writing analytical SQL, explaining query plans, and proposing indexes. Never give an agent write access to production data, and never let raw customer PII flow into a session when a sampled or masked dataset would do.

Key takeaways

• Allow plan, validate, and dry-run commands; deny apply, deploy, and delete in the permission policy.
• Never give a session production write credentials.
• Pair Claude with deterministic policy tools in hooks.
• Keep a human as incident commander; Claude speeds analysis, not the rollback call.