The State of AI in DevOps & SRE, 2026
How much authority are infrastructure teams actually giving AI — and what has it cost them? A short, vendor-neutral survey of DevOps, SRE and platform engineers.
Take the survey (about 6 minutes) →Most writing about AI in operations is either a vendor’s benchmark or an anecdote. This survey asks the people who carry the pager: which AI tools touch your infrastructure work, whether anything they generate can reach production without a human, which guardrails you have in place, and whether an AI-generated change has already caused an incident.
It takes about six minutes. No vendor sponsors it, no answer identifies you, and the aggregate results — every chart on this page plus the underlying counts as a CSV — will be published here for anyone to use.
What the survey asks
Published in full, so you know what you are answering and can judge the results against the questions that produced them.
Which best describes your role?
- SRE
- DevOps engineer
- Platform engineer
- Cloud / infrastructure engineer
- Security engineer
- Engineering manager or lead
- Other
How many engineers work at your organisation?
- Fewer than 50
- 50–249
- 250–999
- 1,000–4,999
- 5,000 or more
Years working in operations, infrastructure or SRE?
- Less than 2
- 2–5
- 6–10
- 11–15
- More than 15
Which AI tools do you use for infrastructure or operations work?
- GitHub Copilot
- Cursor
- Claude / Claude Code
- ChatGPT / Codex
- Gemini
- An internal or self-hosted model
- None
What do you use AI for?
- Writing Terraform / OpenTofu
- Writing Kubernetes manifests or Helm charts
- CI/CD pipeline changes
- Writing log or metrics queries
- Incident investigation
- Writing postmortems or runbooks
- Reviewing infrastructure changes
- Automated remediation
- None of these
How often does AI-generated output end up in a change you ship?
- Never
- Occasionally
- Weekly
- Daily
- In most changes
Can an AI-generated infrastructure change reach production without a human approving it?
- No — every change is reviewed by a person
- Only low-risk changes, by policy
- Yes — some changes are merged or applied automatically
- Yes — agents can apply changes directly
- I don’t know
Which guardrails apply to AI-generated infrastructure changes?
- Mandatory pull request review
- Plan output reviewed before apply
- Policy as code (OPA, Sentinel, Checkov, …)
- Scoped or short-lived credentials for AI agents
- Sandbox or ephemeral environments
- Audit log of actions taken by AI
- None specific to AI
Do you record which changes were AI-generated?
- Yes, systematically
- Informally
- No
- I don’t know
In the last 12 months, has an AI-generated change contributed to an incident at your organisation?
- Yes — a customer-facing incident
- Yes — an internal incident
- A near miss caught before production
- No
- I don’t know
Which of these have you seen AI get wrong in infrastructure work?
- Over-broad IAM permissions
- A resource replaced or destroyed unexpectedly
- Security exposure (open ports, public storage)
- A hallucinated flag, API or resource attribute
- Cost increase
- Wrong environment or account targeted
- None of these
When AI output was wrong, what usually caught it?
- Code review
- Plan or diff review
- Automated policy or tests
- Monitoring or alerts after deploy
- A customer or user
- Nothing has been wrong yet
How much do you trust AI to write infrastructure code? (1 = not at all, 5 = completely)
- 1
- 2
- 3
- 4
- 5
How much do you trust AI to execute remediation during an incident? (1 = not at all, 5 = completely)
- 1
- 2
- 3
- 4
- 5
Over the next 12 months, will your team give AI more or less authority over production?
- Much more
- Somewhat more
- About the same
- Less
- I don’t know
What is your biggest concern about AI in operations? (optional)
Methodology
- Responses are collected anonymously through an external form; this site only ever receives aggregate counts.
- Multi-select questions report the share of respondents who chose each option, so percentages can sum past 100.
- Results are published only if at least 100 people respond; smaller samples are reported as such rather than generalised.