AI for DevOps: configs, scripts and incident analysis

AI for DevOps is useful where work consists of rigidly structured texts: Dockerfiles, CI pipelines, manifests, Terraform, shell scripts, logs. A model drafts quickly and finds obvious mistakes in someone else's config. The danger is not that it makes a mistake but that you apply the result to real infrastructure without checking. Below: which tasks make sense to hand over, how to build safety boundaries and what this looks like in code.

What to hand to a model

Dockerfile. Ask it to build an image for your application, then in a separate request to review it: layer order and build cache, running as non-root, extra packages, image size, pinned base image versions. Run the result through docker build and a linter rather than taking it on faith.

CI/CD. A workflow draft for GitHub Actions or GitLab CI, moving a configuration from one system to another, explaining why a step fails. For such tasks the model needs the config itself and a fragment of the error log.

Terraform and manifests. Writing a module from a description, reviewing terraform plan, finding insecure settings (open ports, public buckets). Important: the model looks at the plan text but does not know your real infrastructure beyond what you showed it.

Scripts. Bash and Python for routine work: log rotation, metric collection, certificate checks. Ask for safe-by-default variants (set -euo pipefail, argument checks, a dry-run mode).

Log and incident analysis. Structuring a timeline, proposing hypotheses from log fragments, drafting a postmortem. The main rule: do not send logs whole; first filter and compress them by time, level and message patterns.

Documentation. An incident runbook, an architecture description from configs, a README for an infrastructure repository.

What not to hand over without a human

• Applying changes (terraform apply, kubectl apply, migrations) on the production environment.
• Making decisions about access and network policy without review.
• Working with real secrets and dumps containing personal data.

The reason is simple: a model can confidently suggest a wrong command. The price of a mistake in development is a failing test; in production it is downtime or data loss.

Safety boundaries for an agent

If you use an agent tool (Claude Code↗ or similar) that runs commands itself, build protection in before the first run.

1. A separate environment. The agent works in a sandbox, on a test stand or in a copy of the repository, not on a working machine with access to production.
2. Minimal rights. Read-only credentials: terraform plan and kubectl get instead of apply and delete. Issue cloud keys restricted by resource.
3. No production secrets in the agent's environment. If environment variables contain production tokens, the agent can read them and accidentally send them to the model. Use separate test values.
4. Confirmation of dangerous commands. Do not enable "allow everything" mode. Allow reading files and running linters permanently, confirm everything else. How this is configured is in the documentation of the tool you use.
5. A human applies. The agent prepares the change and shows a diff or plan, and you or the pipeline run apply after review.
6. Secrets in the prompt. Before sending logs and configs, remove tokens, passwords and internal addresses. Automate it, as in the example below.

Restrict the API key the agent uses too: a separate key, a daily limit in dollars and a list of allowed models: how to set a limit↗. An agent in a loop without a limit can burn through a budget: how to limit spend↗.

Example: reviewing a Terraform plan before apply

The script reads the output of terraform plan, scrubs anything resembling secrets and asks the model to find risky changes. It is a review helper, not a replacement for a human.

import re
import subprocess
from openai import OpenAI

client = OpenAI(base_url="https://api.zukko.pro/v1", api_key="fetch_your_key")

SECRET = re.compile(r"(?i)(password|secret|token|api[_-]?key)\s*[=:]\s*\S+")

def redact(text: str) -> str:
    return SECRET.sub(lambda m: m.group(1) + " = [REDACTED]", text)

plan = subprocess.run(
    ["terraform", "plan", "-no-color"],
    capture_output=True, text=True, timeout=600,

Now the price. Suppose the plan output takes 20,000 tokens and the answer 2,000. Formula: input × input price + output × output price, prices as of October 18, 2026. For gpt-6.1-sol (0.27 / 1.32 per 1M): 0.02 × 0.27 + 0.002 × 1.32 = 0.0054 + 0.00264 = $0.00804. For claude-sonnet-5-5 (0.4 / 2): 0.02 × 0.4 + 0.002 × 2 = 0.008 + 0.004 = $0.012. At ten plans a day that is around ten cents. Fresh prices are always in the GET https://api.zukko.pro/v1/models response.

Regular expressions for scrubbing secrets are imperfect: they catch typical patterns but do not guarantee nothing is missed. For sensitive repositories use dedicated secret scanners.

Choosing a model

For config drafts and log work an expensive model is not always needed. A practical order: start with a cheap one from the catalog (for example deepseek-v4.1-flash or glm-5.3-flash) and escalate if the result is wrong: model cascade↗. For hard things like multi-step pipeline debugging try claude-sonnet-5-5 or claude-opus-5-5. Model strength by the Artificial Analysis index: deepseek-v4.1-flash 39, glm-5.3-flash 42, claude-sonnet-5-5 48, claude-opus-5-5 58; that is no guarantee of quality on your particular configs, so test on real examples.

Connecting: create a key in the dashboard↗; for Claude Code use the address without /v1, for OpenAI-compatible clients https://api.zukko.pro/v1. Access from Russia goes through the gateway; payment by SBP, MasterCard card or cryptocurrency.

FAQ

Can I give an agent access to production if it is smart?

No. A smart model can still be wrong, and the price of an error in production is out of proportion. Grant read-only rights and test stands, and apply changes yourself.

How do I check that a model's Dockerfile is good?

Build the image, run the container, run a Dockerfile linter and a vulnerability scanner. Then compare image size and build time with the previous variant.

What about secrets in logs?

Scrub them before sending to the model: automatically, as in the example, and selectively by hand. For regular work connect a dedicated secret scanner.

Will AI replace a DevOps engineer?

No, it speeds up draft work. Design, responsibility for access and production decisions stay with a person.