Incident response

Survey: 93% of large North-American IT shops have hit an AI-coding incident

Survey: 93% of large North-American IT shops have hit an AI-coding incident

The number

A survey published today on DevOps.com reports that 93% of 406 IT decision makers at North American organizations with more than 250 employees have experienced at least one infrastructure incident caused by reliance on AI coding tools. The sample is North American only, and the size cut is 250-plus employees. Startups and mid-market shops sit outside the frame. Read at face value, the AI-coding incident is now a baseline event at large IT.

That changes the conversation CI/CD owners have been carrying on their own. Until now the case for harder review on agent-generated changes was thin: anecdote against vendor demo. 93 out of 100 large IT shops is a number that fits on a slide in front of a steering committee.

What it doesn't tell you

The respondents are IT decision makers, not the on-call engineers paged at 3am, so the operational shape of these incidents (rollback time, blast radius, whether the offending change came from an autonomous agent or an autocompleted line) sits outside the headline. "Caused by reliance on AI coding tools" is also a wide net. A merge of a hallucinated import is one thing. A refactor pushed through a stale test suite is another. They call for different controls.

So the practical read is narrower than the headline. The 93% says the argument has shifted from whether AI-assisted code can break production at large IT shops, per DevOps.com, to which gate stops it and how much of the existing CI suite is enough. That second half is what teams will be answering with their own incident postmortems in the meantime.

Source: DevOps.com (devops.com)

Related
Platform engineering

Where the controller-runtime cache bites you: stale reads, missing indexes, unbounded watches

A revised kubernetes.io deep dive walks through the local cache every kubebuilder-based controller depends on. The operational read: r.Get and r.List never touch the API server, and that is where a class of quiet controller bugs actually lives.

August 8, 2026
Platform engineering

After the ingress-NGINX retirement, what your migration plan owes production

The Kubernetes SIG Network retired ingress-nginx in March 2026, leaving clusters still on it exposed to unpatched CVEs and stalled feature work. A CNCF post lays out the two migration paths operators are picking between and the tooling to make the move.

July 11, 2026
Platform engineering

etcd v3.7 adds a streaming range API and drops the legacy v2 store

SIG etcd shipped v3.7.0 with a RangeStream API that chunks large read responses instead of buffering them, plus faster lease handling under load and the removal of the legacy v2 backing store. Kubernetes will expose the feature in v1.37 behind a gate.

July 9, 2026

Turn this into your pipeline. Build it on Buddy.

Start free