Infrastructure-as-code & DevOps assistant

Cloud and platform teams spend much of their time writing and reviewing declarative configuration: Terraform modules, Kubernetes manifests, Helm charts, Ansible roles and CI/CD pipelines. AI assistants now generate this code grounded in current provider documentation, explain what a plan will change, fix policy violations and open pull requests. Applying changes stays behind plan review, policy checks and human approval, because a wrong line here can delete production.

Problem & value

• Today: engineers copy snippets from registries and old modules, debug YAML indentation and provider argument changes, and review long plan outputs. Knowledge sits with few specialists; drift between code and live state accumulates; security findings from scanners pile up as backlog.
• AI value: faster first drafts of modules and pipelines, plain-language plan summaries for reviewers, automatic remediation PRs for scanner findings, onboarding of non-specialists, and questions answered against live state ("which buckets are public?").
• Evidence base: vendors report productivity gains, but independent, infrastructure-specific measurements are scarce; measure on your own repositories before committing to targets.
• Grounding matters: models trained on older data suggest deprecated provider arguments; tool servers that expose current registry documentation address this directly [1].

Variants

• SMB / small IT team: assistant in the IDE plus a reviewed CI pipeline; managed Kubernetes or a few Terraform stacks.
• Enterprise platform engineering: governed agent with organisational context, policy-as-code guardrails, approval gates and an internal module catalogue ("golden paths") [2].
• Public sector / regulated: same, but self-hosted or EU-sovereign model hosting, audit trail, and change-management evidence for ISO 27001, NIS2 or DORA.
• Kubernetes operations assistant: natural-language kubectl, manifest generation and cluster diagnosis (kubectl-ai, k8sgpt) [4][5].
• Private/homelab: Docker Compose, Ansible and Home Assistant configs via a local coding model.

How it works

1. change request / ticket / scanner finding
2. context retrieval (repo, module catalogue, registry docs via MCP, live state read-only)
3. LLM / coding agent drafts IaC change on a branch
4. static checks (fmt, validate, tflint, policy-as-code, Checkov/Trivy)
5. plan in sandbox / ephemeral environment
6. plan summarised by LLM
7. pull request + AI review (CODE-003)
8. human approval (four-eyes)
9. CI applies with scoped, short-lived credentials
10. drift detection loop

• Grounding: the Terraform MCP Server gives agents registry provider/module data and, optionally, HCP Terraform workspace operations; destructive operations are disabled by default behind an explicit flag, and HashiCorp warns against pairing it with untrusted clients or models [1].
• Agentic loop: generate → validate → read errors → fix, bounded by iteration and cost limits.
• Human-in-the-loop: read-only credentials for the agent; apply, destroy, IAM and network changes always need human approval; production changes only through the pipeline.

Data preparation

Little classic data is needed; the "data" is your infrastructure knowledge. It lives in Git repositories (Terraform, Helm, Ansible), CI/CD definitions, wikis, tickets and often only in the heads of one or two administrators. Typical gaps: undocumented manual changes in the cloud console (drift), outdated or copied modules, secrets hard-coded in repositories, no naming or tagging conventions, and no module catalogue for the agent to retrieve from.

Preparation steps: 1. Put everything under version control and import manually created resources into state (terraform import, OpenTofu). 2. Run secret scanning (gitleaks, trufflehog) and rotate every leaked secret before any model sees the repository. 3. Write short conventions (naming, tags, approved modules) as a markdown file the agent reads, and curate a module catalogue. 4. Add policy-as-code (Checkov, OPA) so generated changes are checked automatically. 5. Collect a few good past pull requests as gold-standard examples.

Rough share of total effort: about 10-20 percent, mostly cleaning up repositories and drift. See PREP-005 and PREP-016 for exporting system data and gold-standard examples, PREP-013 for a curated knowledge base, and PREP-024 for rules on what may go into which AI tool.

Implementation paths

Which path for whom

• SMB: A. Teams without a platform department get the fastest value from a mature coding assistant (Copilot, Claude Code, GitLab Duo) with plan-checked pull requests, without building agent infrastructure.
• Enterprise: B. Infrastructure topology is strategic and internal module catalogues, policies and guardrails need custom integration, which a cloud-API agent in your CI pipeline provides.
• Developer: C. Open-weight code models with OpenTofu, Checkov and Ollama or vLLM keep repositories local and cost nothing per seat.
• Public sector: C. Infrastructure topology and credentials should stay in a sovereign environment (STACKIT, IONOS, own data centre), which self-hosted models allow.

Path A — Buy (off-the-shelf; recommended for SMBs)

• IaC-platform agents: Pulumi Neo (agent on Pulumi Cloud, reads live state, opens PRs, policy guardrails and approvals; runs on Anthropic Claude via Amazon Bedrock) [2]; HashiCorp Terraform with its MCP server and HCP Terraform [1]; Spacelift, env0, Scalr and Firefly (Israel) with AI features.
• General coding assistants: GitHub Copilot, Cursor, Claude Code, JetBrains AI, Amazon Q Developer, Google Gemini Code Assist — all handle Terraform/YAML well enough for drafts (CODE-001/002).
• Cloud-native ops assistants: AWS, Azure and Google Cloud offer chat/agent features over their own resources (check availability per EU region).
• EU vendors: Mistral (Codestral, Devstral), JetBrains (Czech), GitLab Duo with EU/self-managed options, STACKIT, IONOS and OVHcloud as sovereign hosting targets for the infrastructure itself.
• Choose A when: you already run Pulumi/Terraform Cloud/GitLab and want fastest time to value.

Path B — Build on cloud APIs (recommended for enterprises)

• Models: frontier coding models (Claude, GPT, Gemini) or Mistral Devstral/Codestral from EU endpoints; Bedrock/Azure OpenAI/Vertex in EU regions.
• Stack: coding agent (Claude Code, OpenHands, Aider) in a CI job or chatops bot; Terraform MCP server and a read-only cloud MCP for context; plan summarisation step posting to the PR.
• Guardrails: least-privilege, short-lived OIDC credentials; OPA/Conftest or Sentinel policies; secrets never in prompts (secret scanning before model calls).
• Choose B when: you need custom workflows, internal module catalogues or an EU-only data path.

Path C — Self-host (open source)

• Tooling: OpenTofu (MPL 2.0, Linux Foundation/CNCF) [3], Checkov, Trivy, tflint, OPA, Kyverno, Argo CD/Flux, kubectl-ai [4], k8sgpt [5] with a local model backend.
• Models: open-weight code models such as Qwen3-Coder, Devstral, DeepSeek-Coder family, Codestral (check licence), served with vLLM or Ollama; MCP servers are model-agnostic.
• Hardware: HW3 for agentic workflows with a 30B+ coder model; HW2 suffices for completion, explanation and small-scale review with ≤30B quantised models.
• Choose C when: code or topology information must not leave your network (e.g. defence-adjacent, critical infrastructure).

Path D — Custom training

Rarely worthwhile. Fine-tuning on internal modules and conventions can improve adherence to house style, but retrieval over your module catalogue plus policy checks usually delivers more at lower cost.

State of the art (2026)

• Agents with tool grounding (MCP registry servers, live-state access) replace pure code completion; vendors position them as platform-engineering colleagues rather than autocomplete [2].
• Fork ecosystem: Terraform and OpenTofu both evolve quickly (OpenTofu 1.12.x), so generated code must be pinned to the version in use [1][3].
• Strengths: boilerplate, translating between formats (CloudFormation → Terraform), pipeline YAML, explanation, scanner-finding fixes.
• Failure modes: hallucinated resource arguments or modules, subtly over-broad IAM policies, missing dependencies/ordering, unintended resource replacement (destroy/create) hidden in a plan, state-file mistakes, and prompt injection via repository content, tickets or logs that steer a privileged agent. Syntactically valid code that is semantically wrong is the main risk.

Shared resources & combinations

• Same stack (llm-code + agent-framework): CODE-001 IDE assistance, CODE-002 autonomous coding agents, CODE-003 code review, CODE-021 dependency/refactoring automation — one agent platform and one model endpoint can serve all.
• Downstream/upstream: CODE-010 AIOps (incident → remediation PR), CODE-011 log analysis, SEC-004 vulnerability management with auto-fix (IaC scanner findings).
• Shared infrastructure: MCP servers, secrets handling and sandbox runners are reusable across agent use cases.

Effort, cost & KPIs

• Path A: days to weeks; per-seat or per-resource pricing.
• Path B: 1–3 months for a governed pipeline with policies, sandbox plans and audit logging; token cost scales with repository context and agent iterations.
• Path C: 2–4 months plus GPU operations.
• KPIs: lead time for infrastructure change, PR review time, share of AI-authored PRs merged unchanged, change failure rate and rollback rate (DORA metrics), policy-violation backlog age, drift incidents, cost per agent task.

People & change

Involve early: management (budget, AI policy), the platform or department lead (process owner) and IT security (credentials, least privilege, prompt injection, see GUIDE-013). Legal/compliance joins when customer-related infrastructure is touched. End users (administrators, developers) should co-design the pilot, because they own the review step.

Works council: depends. Pure code generation is not monitoring, but assistants and CI agents log who prompted what and which pull requests were accepted. Under §87(1) no. 6 BetrVG the Federal Labour Court treats objective suitability for monitoring as sufficient, so check logging and usage statistics. §90(1) no. 3 additionally requires timely information when work processes are planned with AI. Public sector: Personalrat. See GUIDE-004.

Data protection: repositories and logs seldom hold personal data beyond developer names; involve the DPO briefly, conclude an AVV with the provider, and run a DPIA only if personal data flows in at scale.

AI literacy: support staff with short training on reviewing generated code, never pasting secrets, and recognising hallucinated modules (GUIDE-006).

Communication and pilot: start with one volunteer team and non-production environments. Typical concern: "the AI will replace administrators" or break production. Address it by showing that the agent has read-only credentials, that apply always needs human four-eyes approval, and that time saved goes to reviews and automation (GUIDE-008, GUIDE-009).

Risks, regulation & compliance

• EU AI Act: typically minimal risk for development tooling; AI literacy duty (Art. 4) applies. Classification changes only if the agent autonomously operates safety components of critical infrastructure (Annex III point 2) — keep it in the change pipeline, not in real-time control. No Art. 5 prohibition is relevant [6].
• GDPR: IaC and logs may contain personal data (usernames, IPs, tags); minimise context sent to models, use EU regions and a DPA, and never include production data in prompts.
• Sector rules: NIS2 (supply-chain and change-management security), DORA for financial entities (ICT risk management, third-party providers), ISO 27001 change control; Cyber Resilience Act for products. Document AI use in change records.
• Security risks: leaked secrets, over-privileged agent credentials, prompt injection through tickets/READMEs, supply-chain risk from suggested modules. Mitigate with read-only default, scoped credentials, pinned module versions/checksums, signed commits, mandatory review and policy-as-code gates.

Getting started

1. Pick one low-risk repository (e.g. non-production stack); enable a coding assistant with the Terraform MCP server in read-only mode.
2. Put guardrails first: fmt/validate/tflint, Checkov or Trivy, OPA policies and a mandatory plan review in CI.
3. Let the assistant fix existing scanner findings via PRs and summarise plans for reviewers.
4. Baseline DORA metrics and PR review time before and after; review incidents of wrong output.
5. Only then widen scope (more stacks, live-state queries); keep apply and IAM changes human-approved.

Sources

1. HashiCorp Terraform MCP Server (GA reporting, InfoQ) — https://www.infoq.com/news/2025/05/terraform-mcp-server
2. Pulumi Neo documentation — https://www.pulumi.com/docs/ai/neo/
3. OpenTofu project — https://opentofu.org/
4. kubectl-ai (Google Cloud Platform) — https://github.com/GoogleCloudPlatform/kubectl-ai
5. k8sgpt — https://github.com/k8sgpt-ai/k8sgpt
6. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
7. Checkov — https://github.com/bridgecrewio/checkov