AI for DevOps: infrastructure, CI fixes and incidents with guardrails

AI for DevOps works best on the reading and writing around operations: drafting infrastructure as code, diagnosing CI failures, summarizing logs during incidents and writing runbooks, while humans keep the final say on anything that changes production. This guide covers each workflow with commands and prompts, and the guardrails that keep an agent from becoming your next incident.

How can you use AI for DevOps today?

The best uses of AI for DevOps are tasks where the agent reads a lot and writes a draft that a human checks before it touches production. Infrastructure code, CI failures, log analysis, runbooks and postmortems all fit. Autonomous changes to live systems do not, at least not without the same review pipeline humans go through.

Google's 2025 DORA report, based on survey responses from nearly 5,000 technology professionals, found 90% of respondents using AI at work. It also found AI adoption linked to higher software delivery throughput but lower delivery stability, and called AI an amplifier: strong engineering practices get stronger, weak ones get exposed. For DevOps teams, that means tests, review and fast rollback matter more as AI use grows.

How do you write infrastructure as code with an AI agent?

Let the agent write and plan infrastructure changes, and keep the apply step human. A terminal coding agent such as Claude Code can read your existing modules, follow your naming and tagging conventions, and run terraform plan to check its own work.

A workflow that holds up:

1. Point the agent at an example. Name an existing module that follows your conventions.
2. State constraints. Region, naming, tags, encryption, what must not change.
3. Have it run validation. terraform fmt, terraform validate and a plan saved to a file.
4. Read the plan yourself. Every create, change and destroy.
5. Apply through your normal pipeline after review.

Add an S3 bucket for invoice PDFs in modules/storage, following the patternin modules/storage/logs_bucket.tf. Requirements: private, versioning on,server-side encryption, lifecycle rule moving objects to infrequent accessafter 90 days, our standard tags from locals.tf.Do not modify any existing resource.Run terraform fmt, terraform validate, and terraform plan -out=tfplan.Then summarize the plan: every resource added, changed or destroyed.

Saving the plan with -out lets the agent and you inspect exactly what will run. The Terraform docs note that terraform show -json tfplan prints a JSON representation of a saved plan, which is easy for an agent to summarize or check against rules. Two more details from the plan docs: -detailed-exitcode returns 2 when there are changes, which is handy in scripts, and saved plan files can contain sensitive values in cleartext, so keep them out of git and logs.

Block the dangerous commands outright in the agent's settings. Deny rules apply in every permission mode:

{  "permissions": {    "allow": ["Bash(terraform fmt *)", "Bash(terraform validate *)", "Bash(terraform plan *)"],    "deny": [      "Bash(terraform apply *)",      "Bash(terraform destroy *)",      "Bash(kubectl apply *)",      "Bash(kubectl delete *)",      "Read(./.env)"    ]  }}

The permissions reference explains the matching: Bash(terraform plan *) matches terraform plan -out=tfplan but nothing else, and Claude Code checks each part of a compound command such as a && b separately.

How do you use AI to fix CI failures?

Feed the failing job's log to a coding agent and ask for the root cause before any fix. Most CI failures are a dependency bump, an environment difference or a flaky test, and an agent reads a 3,000-line log faster than you can scroll it.

From your terminal, the GitHub CLI and Claude Code's non-interactive mode combine into one command:

gh run view 1234567890 --log-failed | claude -p "Find the root cause of this CI failure. Quote the lines that prove it. Say whether it looks like a real bug, a flaky test, or an environment problem, and propose the smallest fix."

For a fix, start an interactive session so the agent can reproduce locally:

CI fails on the integration-tests job since commit a1b2c3d. Log summary: [paste].Reproduce the failure locally with the same Node version as .github/workflows/ci.yml.Find the root cause, fix it, and run the job's test command to confirm.Don't skip, retry or loosen tests to make it pass.

The last line matters. Anthropic's best practices give the same advice: ask for the root cause and tell the agent not to suppress the error.

On GitHub you can also run this from the pull request itself. The Claude Code GitHub Action responds to @claude mentions, so a comment like "@claude the lint job fails on this PR, fix it" gets a commit on the branch. Set --max-turns in claude_args and a workflow timeout to cap runaway jobs. Our guide to Claude Code GitHub Actions covers setup and permissions.

How does AI help with incident triage and log analysis?

During an incident, AI is most useful for compressing information: summarizing logs, correlating events across services and drafting a timeline. It should work from read-only data, and humans decide and execute remediation.

Good triage prompts give the time window, the symptom and the data, and ask for evidence:

Incident: checkout API returning 502s since 14:05 UTC.Attached: nginx error log and checkout-service logs from 13:50 to 14:30,and the deploy log for today.1. Build a timeline of notable events with timestamps.2. List the top 3 hypotheses for the root cause, each with the log lines   that support or contradict it.3. Suggest the single safest diagnostic step for each hypothesis.Don't suggest restarts or rollbacks yet.

Practical rules for incident use:

• Redact first. Strip tokens, customer emails and IP addresses before logs leave your systems, and use only AI tools whose data terms your company approved.
• Trim the input. A focused 15-minute window beats a day of logs; large inputs bury the signal and cost more.
• Ask for quotes. Hypotheses must cite log lines. An unsupported claim during an incident sends people down the wrong path.
• Keep a human incident commander. The AI drafts; a person decides.

After the incident, AI is good at turning the chat history, timeline and notes into a first draft of the postmortem. An engineer then checks every fact and owns the action items. For a deeper method, see our guide to debugging with AI.

Can AI help with Kubernetes and configuration?

AI explains and reviews Kubernetes manifests, Helm charts and cloud configuration well, and spots common misconfigurations such as missing resource limits, containers running as root or overly broad RBAC. Give it read access, not write.

Useful requests:

• "Explain what this Helm chart deploys and which values a user must set."
• "Review these manifests for missing limits, privileged containers, latest tags and missing probes."
• "Why is this pod in CrashLoopBackOff? Here is kubectl describe pod and the last 200 log lines."
• "Write a NetworkPolicy that only allows the api pods to reach postgres on 5432."

If an agent runs kubectl itself, give it a kubeconfig bound to a read-only role (get, list, watch) in the namespaces it needs. Applying changes then goes through your GitOps or CI pipeline like any other change.

How do you write ops scripts and automation with AI?

AI writes Bash, Python, Makefiles and CI workflow YAML quickly, and these are where small mistakes cause outsized damage: an empty variable in rm -rf $DIR/ or a missing set -e can wipe the wrong directory or hide a failure. Ask for defensive defaults and a dry run every time.

Write a Bash script that deletes Docker images older than 14 days on ourbuild servers, keeping the 5 newest tags per repository.Requirements: set -euo pipefail, quote every variable, a --dry-run flagthat is the default and prints what would be deleted, a --yes flag toactually delete, and clear log lines. Run shellcheck on it and fix warnings.

Then run it in dry-run mode on one machine and read the output before anyone passes --yes. For workflow YAML, ask the agent to pin third-party actions to a version and to grant the job only the permissions it needs, since broad default tokens in CI are a common way a small script becomes a security problem.

Keep generated scripts in the repository, reviewed like application code, rather than pasted into a terminal from a chat window. A script nobody reviewed is a script nobody can safely rerun six months later.

What guardrails does AI need in production environments?

Production guardrails for AI come down to four rules: read-only by default, every change through a reviewed pipeline, no long-lived production credentials in the agent's environment, and isolation for anything unattended.

For scripted, unattended runs in CI, Claude Code's dontAsk permission mode is a good fit: it allows only the tools you pre-approve and denies everything else instead of prompting. Prompt injection is the reason these limits matter even for trusted tools; our guide to prompt injection in coding agents explains the attack patterns.

If you want agents working on infrastructure code around the clock without giving them a seat on your own machine, Orkio runs them on an isolated cloud box: they clone the repository, push branches and open pull requests, and you review and apply through your normal pipeline.

How do you measure whether AI helps your DevOps team?

Measure delivery outcomes, not AI usage. The four DORA metrics already tell you whether changes ship faster and more safely: deployment frequency, lead time for changes, change failure rate and time to restore service.

Watch them in pairs. If lead time drops but change failure rate rises, the team is shipping faster and breaking more, which is the pattern DORA's 2025 report warns about. Add two AI-specific checks:

• Share of AI-assisted pull requests reverted or hotfixed within a week.
• Time from CI failure to green before and after you add AI diagnosis.

Review these monthly and adjust where you allow automation. Our guide to AI code review helps with the review load that more AI-generated changes create.

Where to start this week

Pick one low-risk workflow and add guardrails before you expand:

• Add deny rules for apply, destroy and delete commands to your agent settings
• Create a read-only cloud role and kubeconfig for agent use
• Try gh run view <id> --log-failed | claude -p on your next CI failure
• Have an agent write one Terraform change end to end, up to a saved plan you review
• Draft your next postmortem with AI from the incident notes, then verify every fact
• Track change failure rate alongside lead time for the next quarter

For agents that keep working after you log off, our guide to remote development servers covers hardening the machine they run on.

Frequently asked questions