News · Datadog validated Codex against its own past incidents before rolling it out

Jul, 134 min to read
Automation

Datadog validated Codex against its own past incidents before rolling it out

Datadog's AI DevX team tested a coding agent by replaying historical incidents, then deployed it to more than 1,000 engineers as a reliability system rather than a review shortcut.

The incident replay harness is the real test here

Most AI code-review adoption stories rest on vibes: engineers say the suggestions feel smart, usage climbs, everyone moves on. Datadog's AI DevX team, led by Brad Carter, did something harder to fake. They built an incident replay harness that reconstructed pull requests that had contributed to past production incidents, ran Codex against each one as if it were part of the original review, and then asked the engineers who owned those incidents whether Codex's feedback would have made a difference.

The design matters because it removes the two escape hatches that usually inflate these evaluations. The pull requests had already passed human review at the time, so any risk Codex surfaced was one real reviewers missed. And the judges were the incident owners themselves, not a benchmark or a vendor scorecard.

The result: Codex flagged issues that would have mattered in more than 10 cases, roughly 22% of the incidents Datadog examined — more than any other tool the team evaluated. That is a specific, falsifiable claim tied to a company's own outage history, not a general accuracy percentage.

Why linter-style tools kept getting ignored

Datadog is explicit about why earlier AI review tools failed inside their workflow: many behaved like advanced linters, flagging surface-level issues while missing system nuance. Engineers found the suggestions too shallow or too noisy and simply ignored them. That is the honest baseline most announcements skip over.

The distinction Datadog draws is about context. According to the source, Codex compares the intent of a pull request against the submitted changes, reasons over the entire codebase and its dependencies, and executes code and tests to validate behavior. The concrete outputs engineers cited were interactions with modules not touched in the diff, missing test coverage in areas of cross-service coupling, and API contract changes carrying downstream risk.

It was the first one that actually seemed to consider the diff in the larger context of the program. That was novel and eye-opening.Montana Labs

That is a narrow, testable claim about tool behavior — reasoning across untouched modules — rather than a general promise of intelligence. It also explains the behavioral shift: engineers reported treating Codex comments as real review feedback instead of noise to skim past.

Organic Slack feedback instead of in-tool metrics

One operational detail stands out. Datadog now has more than 1,000 engineers using Codex regularly, but the company says feedback is largely surfaced organically rather than through formal in-tool metrics. Engineers post to Slack about useful insights and moments where Codex helped them think differently.

During the pilot, the measurement was even simpler: engineers reacted to Codex comments with thumbs up or down in a large, heavily used repository where every pull request was automatically reviewed. The signal Datadog trusted most was whether people voluntarily read the comments.

This is worth noting because it contradicts the usual instinct to build a dashboard first. Datadog treated the replay harness as the rigorous evaluation and let day-to-day adoption prove itself through whether engineers found the output worth their attention.

Reframing review around incident prevention, not cycle time

The stated implication for Datadog is a redefinition of what code review is for. Carter is direct that time savings, while real, are not the point at their scale — preventing incidents is. The team now describes Codex as a core reliability system rather than a checkpoint for catching errors or optimizing review speed.

Codex changed my mind for what code review should be. It's not about replicating our best human reviewers. It's about finding critical flaws and edge cases that humans struggle to see when reviewing changes in isolation.Montana Labs

For teams weighing similar tools, the transferable lesson is the evaluation method, not the vendor choice. A company that already knows its own incident history can grade any review tool against outages that actually happened and ask the people who lived through them whether the tool would have helped. That produces a defensible adoption decision — and, at Datadog, a clear division of labor where the agent surfaces cross-service risk and human reviewers concentrate on architecture and design.

Find this story relevant to you?

Contact us to find a unique solution

Contact us

Need an AI engineering partner that can actually build?

We help businesses integrate AI, build AI-powered products, automate high-value workflows, and modernize the software systems behind them.

Get in touch

Related reading

More analysis around product delivery, operational AI, and the systems work that makes deployment hold up in reality.

Jul, 134 min to read
Automation

OpenAI reframes adoption as a 'capability overhang' problem

Jul, 134 min to read
Automation

Cisco built the majority of its AI Defense product with Codex writing the code

Jul, 134 min to read
Automation

Commonwealth Bank standardizes on ChatGPT Enterprise as the shared surface for 50,000 employees