A two-hour vendor keynote is not usually where you find an honest number about AI reliability. Datadog's DASH 2026 keynote is mostly what you expect — agent demos, product launches, a customer on stage — but one segment quantifies something most teams are guessing at, and it does so against the presenter's own interest.
The number
Setting up the database-optimization launch, the presenter starts by admitting the feature category does not currently work well.
"And they help a lot of the time. But I think we're all seeing how inconsistent they can be. In fact, just the other day I had to roll back an LLM suggested optimization because it actually regressed performance."
Then the measurement:
"My team and I wanted to quantify this. So we took the top 500 queries from across our services and asked an LLM to optimize them. We got back around 300 suggestions. 300 is way too many for me to roll out to prod with any confidence, because I know that there are outages lurking in many of them. So I would have to spend days running benchmarks to figure out which ones to weed out. So is the LLM saving me time or causing me more work?"
And the result after putting every candidate through an automated benchmark on a simulated database:
"We found that this validation harness took those original 500 queries with 300 blind optimization candidates and produced 30 validated optimizations ready to merge. That's 90% less noise with full confidence in what's left."
| Stage | Count |
|---|---|
| Production queries submitted | 500 |
| LLM optimization candidates returned | ~300 |
| Candidates that survived benchmarking | 30 |
Nine out of ten suggestions from a competent model, on a task it should be good at — rewriting SQL is pattern work with a clear objective function — did not hold up when measured. This is disclosed by the company selling the AI feature, in the slide arguing you should buy it. Whatever you think of the product, that is the most useful reliability figure in the keynote, and it is almost certainly generous.
Where the bottleneck actually moved
Later, introducing the developer tooling, the keynote states the general case better than most conference talks manage:
"AI agents compress the time from idea to PR, but trust doesn't accelerate automatically. The bottleneck shifts downstream to reviewing, releasing, and evaluating it safely."
That is the same finding as the query experiment, generalised. Generation went to near-zero cost; verification did not move. A team that adopts the first half without building the second half has not sped up — it has moved its queue from writing to checking, and made the queue longer, because the model produces candidates faster than a human produced them and with a worse prior.
The practical test: for any AI-assisted workflow you run, can you say what fraction of its output you rejected last month? If not, you are running the 300-candidate version and calling it leverage.
The pattern worth copying
The incident demo contains an autonomy model that is independent of the product. Actions are split by blast radius, and the split is explicit:
"These guardrails tell Bits which actions it can take completely on its own, and which ones still need a human signoff... my team has already given Bits approval to restart pods completely on its own, because it's scoped and it's low risk."
And the escalation path is learned from what a human already approved:
"Bits sees that I've approved the same action for the service before. Now I can tell Bits to update my guardrails. So this action is auto approved and Bits will autonomously resolve these issues for me next time. This is how Bits learns from the changes I've already made in my environment."
Graduating an action from ask me to just do it on the evidence of repeated human approvals is a reasonable design, and you can implement the idea in your own runbooks without buying anything: enumerate the actions an agent may take, classify each by what it costs when wrong, and promote across that line deliberately rather than by drift.
Where to push back
Every demo here is staged. The incident resolves, the agent's hypothesis is correct, the fix works. That tells you nothing about behaviour on the incident where the first hypothesis is wrong, which is the only kind that is hard.
The 30 is unaudited. We have Datadog's word for the harness, the queries, and what "validated" meant. Validation ran against a simulated database — the keynote says as much, framing it as a privacy benefit — and a simulated database has synthetic data distribution, no concurrent load, and no cache state. Query plans are sensitive to exactly those things. Some of the 30 will regress in production, and nothing in the keynote tells you how many.
The learned-guardrail mechanism has an obvious failure mode nobody mentions: approvals accumulate. Approve a pod restart three times under three different circumstances and the fourth circumstance is one you did not consider, but the promotion has already happened. A permission that widens through repetition needs an expiry or a review, and no such mechanism appears on stage.
And the rest of the two hours is a launch reel — network device monitoring, Observability Pipelines, cardinality, journey monitoring, a partner segment. It is competent and it is marketing.
Worth watching
One hundred and twelve minutes, of which about six matter. Go to 35–41 minutes for the query experiment and its numbers. If you also want the autonomy model, 15–23 minutes covers the guardrails and the promotion mechanic. Everything else you can read in the press release.
Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.
Top comments (0)