---
id: "lib-2026-11-03-finding-backend-performance-wins-with-a-coding"
type: "library"
title: "Finding backend performance wins with a coding agent"
lang: "EN"
org: "Sentry"
source_type: "Practitioner post"
date: "2026-11-03"
week: "2026-W45"
url: "https://nosov.ai/library/lib-2026-11-03-finding-backend-performance-wins-with-a-coding/"
original_url: "https://blog.sentry.io/performance-wins-traces-coding-agent/"
tier: "B"
tier_name: "Useful, limited"
tier_reason: "A Sentry engineer's first-hand account with specific queries, PRs and before-and-after measurements; concrete and useful, but uncontrolled day-on-day comparisons on the vendor's own product, ending in a product pitch."
summary_basis: "full-text"
original_minutes: "6"
tags: ["ai technology", "coding agents", "observability", "performance"]
---

# Finding backend performance wins with a coding agent

Tier B (Useful, limited): A Sentry engineer's first-hand account with specific queries, PRs and before-and-after measurements; concrete and useful, but uncontrolled day-on-day comparisons on the vendor's own product, ending in a product pitch.

Summary based on the full text.

## In short

A 3 November 2026 Sentry blog post by engineer Scott Cooper. Over a few weeks he pointed a coding agent (Claude with Opus 5.5, connected to the Sentry MCP server) at the traces Sentry collects on itself and asked it to find hot-path performance problems. Most fixes changed a line or two, each PR linked to an example trace, and SQL changes were checked with EXPLAIN ANALYZE on a read-only mirror. Together they removed hundreds of millions of queries a week.

## Key numbers

- ~143M: extra SELECT queries a week removed by reusing an already loaded project in ingestion hot paths
- ~10k/s: UPDATE rate on the US attachments database removed by one check; commits there fell ~17%
- ~95ms to ~61ms: p95 of save_issue_occurrence after two fixes, vs the same hours the previous day
- 935ms to 0.4ms: GroupHistory lookup for the busiest group on a read-only mirror after a query rewrite
- roughly 29M: fewer queries a day from eager-loading the app and token for Sentry app requests

## What it reports

- The agent ranked spans by frequency and duration and returned file, line, estimated weekly volume and an example trace per candidate; the engineer steered with short prompts and chose what to fix.
- A check before an UPDATE during ingestion removed a ~10k/s write on the US attachments database; commits fell ~17%, and one function went from ~6ms to ~2.5ms.
- Reusing an already loaded project removed an estimated ~143M SELECTs a week; with a second fix, save_issue_occurrence p50 went from ~35ms to ~30ms and p95 from ~95ms to ~61ms.
- A GroupHistory query rewrite cut a query that was ~8% of disk reads on the EU primary database to nearly zero; on the mirror, 935ms to 0.4ms.
- Eager loading cut two extra selects from ~1.9% to ~0.16% of control-database query volume, about 29M fewer queries a day.
- A missing index cut average execution of a pagination query by ~69% (30ms to 9.2ms); one org with ~16k repositories was paging through them roughly every 40 seconds from the CLI.
- Batching cache writes took one round trip (about 1.2ms) instead of one per issue (about 51ms in the example).

## How they got it

Single-engineer practice over a few weeks. Candidates came from Sentry's own Django traces; the agent read code and git history and opened draft PRs. Results were read from traces, request latency and database load, mostly compared with the same hours on the previous day. Volumes are estimates from sampled spans.

## Limits

- No control or longer baseline; day-on-day comparisons can move with traffic, though the author compared work per request.
- No count of candidates rejected, PRs abandoned or time spent; no token cost.
- Written by the vendor about its own MCP integration, with a sign-up call to action.

## Why it matters for companies

Production traces give a coding agent something specific to work on: a ranked list of real, expensive code paths with evidence attached. The pattern is cheap to copy with any tracing tool: let the agent find and rank, keep a person choosing what to touch, validate SQL on a read-only copy, and link each PR to the trace that justifies it. The wins here are small fixes that add up at scale, which suits teams with mature systems and limited time for performance work.

Original: https://blog.sentry.io/performance-wins-traces-coding-agent/