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

Precisa de um parceiro de engenharia de IA que saiba executar?

Ajudamos equipas em Portugal a integrar IA em produtos, automatizar processos de alto valor e modernizar os sistemas que suportam o negocio.

Get in touch

Leitura relacionada

Mais análises sobre entrega de produto, AI operacional e o trabalho de sistemas que faz com que a implementação funcione na prática.

Jul, 144 min de leitura
Produtos de AI (keep the English acronym)

Como a Google DeepMind recriou, a partir de arquivos e filmagens de dobras, o golo de Pelé de 1959 nunca filmado

Jul, 134 min de leitura
Frontend

A DNP colocou o ChatGPT Enterprise diante de dez departamentos e tratou a janela de chat como interface

Jul, 134 min de leitura
Frontend

A AdventHealth implementa o ChatGPT em nove estados ao tratar a adoção como o produto