Which Change Caused the Incident?

Which change caused the incident?

That is the question teams ask once production is already failing and customers are already affected. But there is a more valuable question.

Could we have caught the regression before it reached production?

AI makes that question more urgent because it increases the volume and speed of change. But this is not only an AI code problem. It applies to application code, infrastructure, configuration, policy, and every other change that can alter behavior customers rely on.

Research Shows a Confidence Gap

GitLab published research in June 2026, with fieldwork by The Harris Poll across 1,528 developers and technology buyers. 87% said they were confident their team could determine within 24 hours whether AI-generated code contributed to a production incident. Among the organizations that had actually experienced an incident in the past year, 34% could not make that determination.

The caveats belong in the same breath as the figure. The percentages are not inverse answers to the same question. One measures confidence. The other reports outcomes among organizations that experienced an incident. Both are self-reported. GitLab sells governance tooling, and the report concludes that governance tooling is needed. “Could not determine” also includes cases where nobody attempted attribution.

What survives the caveats is the shape. Confidence and outcome were measured inside one sample, and they did not match.

Confidence is a forecast. The second number is a result.

Late Questions Get Harder

Nobody in that room is careless. The search is hard for structural reasons, and every one of them gets worse with time.

The consequence usually surfaces somewhere other than the code that moved. It is the pattern behind You Did Not Touch It. It Broke Anyway.. Weeks separate the change from the symptom, so the connection stops being obvious. And there is more to search than there used to be, because the volume of merged change keeps climbing.

Recent postmortems show that this is not limited to application code. Delivery, policy, and control-plane changes can alter customer-visible behavior too. In February 2026, Cloudflare traced an outage to a broken subprocess merged 15 days before deployment. It began withdrawing customer network prefixes ten minutes after release.

In June 2025, Google Cloud reported that a new quota-policy code path passed rollout because the policy change needed to exercise it had not happened yet. Two weeks after release, an invalid policy reached that path and its metadata replicated globally. In April 2026, GitHub reported a merge-queue regression that produced incorrect squash commits and inadvertently reverted earlier changes across 658 repositories. Different systems showed the same failure shape. The changed component looked local. The consequence was not.

You can probably recognize the shape of the search.

• Somebody bisects releases while the incident is still open.
• Somebody else reads three weeks of merged pull requests, looking for anything near the same area.
• A channel fills up with people who each understand one part of the system.
• The fix lands before the explanation does, and sometimes the explanation never lands at all.

Better Provenance Would Not Fix It

The obvious response is to label the code. Tag what the agent wrote, keep the trail, and answer faster next time. That is worth doing, and for some teams it is the right project.

It runs into two things.

The first is timing. In the same sample, 43% cannot reliably tell AI-generated code from human-written code in their own codebase. A trail has to be kept before it is needed. It cannot be recovered afterwards.

The second matters more. Even a perfect label answers a smaller question than the one being asked. Knowing which lines an agent wrote does not tell you which customer flows those lines put at risk. Authorship is a property of the code. Risk is a property of the behavior around it. That boundary is why verifying AI-generated code is different from reviewing it.

Whether AI writes worse code is a separate and contested question. The traceability gap does not depend on the answer. It applies regardless of who wrote the code.

Ask Before the Change Ships

Two questions are available, and they are not the same size.

Which change caused this?

That one gets asked after an incident, against a system that has moved on, with customers already inside the problem.

Which business flows does this change put at risk?

That one can be asked while the change is still a release candidate. Same subject. Different cost.

The second question also has a reference point the first one lacks. Yesterday’s production behavior is the most complete specification the software has. Documentation ages. Tests describe the behaviors somebody remembered to encode. Production behavior is what customers already rely on.

We have written before about why reviewing the diff was never the hard part. The same limit applies here. A diff shows what moved. It does not show what depended on it.

A Record at Change Time

Early maps which business flows a change puts at risk before it ships. That wide, low-noise view is kept separate from a narrower and more precise read of which behaviors actually changed. The two have different accuracy profiles, and blurring them would cost trust in both.

Each surfaced change carries its pull request, commit, author, timestamp and run. The record is written at the moment of the change instead of reconstructed after an incident.

A person still decides what each surfaced change means. Early surfaces and flags. It does not approve a merge, delay a release, or implement a fix by itself. The analysis runs as a scheduled batch, which suits teams on a daily release cadence, and it is not a real-time check on every pull request.

Early does not replace your tests, reviews, or monitoring. It is the QA persona responsible for protecting releases from regressions and helping teams resolve them before production. It gives QA teams, release owners, engineering leaders, engineers, and product teams the change-time context they need to investigate risk and act before issues reach customers.

What This Does Not Tell You

Early does not tell you whether a change was written by AI. It does not do provenance analysis. The question the survey asked is not the question Early answers.

It does not end the after-the-fact investigation either. Some failures only appear at runtime, under load, on one device, in one customer’s data. Monitoring answers those, and it answers them well. Early is complementary to it and not a replacement.

What changes is how often the investigation starts from nothing.

Finding Out Is the Part You Control

Nobody ships meaningful change without unintended consequences. That part is not going away.

An unexpected behavioral change found while the release is still a candidate is a review conversation. The same change found three weeks later by a customer is an incident, a rollback, a postmortem, and a week nobody planned.

Which change caused the incident? That is the question every team needs to answer.

Could we have caught the regression before production? That is the question that changes the outcome.