A NullReferenceException fires in production at 2am. The alert shows you the frame that threw: a formatter three layers deep, rendering a field that came back empty. That frame is where the program died. It is almost never where the bug lives. The empty field was set four services upstream, by a request that silently dropped a header, because a deploy two hours earlier changed a default. The stack trace shows you the corpse. Finding the killer is the job, and it is the part that eats the hour.
That gap — between "an error happened here" and "here is why" — is exactly what Sentry built Seer to close. Seer went generally available on June 17, 2025, and it is worth looking at not as another autocomplete-for-bugs but as a specific bet about what an AI debugger actually needs to be useful: not a bigger model, but more of the right context, walked in the right direction.
Root cause is a graph walk, not a lookup
Most AI coding help works forward. You hand it a symptom and it pattern-matches toward a plausible edit. Debugging production runs the other way. You start at the failure and walk backward through everything that led to it until you reach the first thing that was actually wrong.
Seer does this by pulling in far more than the exception. For a given issue it can read the stack trace, breadcrumbs, distributed traces and spans, structured logs (currently in beta), profiling data, commit history, and the linked source in your GitHub or GitLab repositories. It treats the codebase like a resource it can grep, not a static blob it was pre-fed. Then it traces the chain back through those signals until it lands on a specific line.
The distinction that makes or breaks a debugger: reporting the frame that blew up is trivia; reporting the line that started the problem is diagnosis. Everything Seer collects exists to tell those two apart.
The distributed-trace piece is the part that would be hard to fake. When your failing request touched five services, the frame that threw and the code that misbehaved can sit in different repositories. Spanning that boundary is precisely where a human loses the thread, and it is where telemetry the model can actually read earns its keep.
The numbers it launched on
Sentry put figures behind the claim. Across the beta, Seer analyzed 38,000+ issues and identified root causes with 94.5% accuracy, work the company estimates saved development teams over two years in aggregate.
Read that 94.5% carefully: it is root-cause accuracy, not fix-is-perfect accuracy. Those are different bars, and the split matters. Correctly naming the cause is the expensive cognitive step; turning a correct diagnosis into a patch is comparatively mechanical. A tool that gets the why right nine-and-a-half times out of ten, even if you still touch up the how, has already removed the part you were paying a senior engineer's attention for.
Three steps, and where you can stop it
Seer's autofix runs as a pipeline you can halt at any stage:
- Root Cause Analysis — it examines telemetry plus code and streams its reasoning live, linking evidence to specific line numbers.
- Solution Identification — it proposes a fix strategy you can edit: strike a step you disagree with, or add a requirement.
- Code Generation — it produces diffs across the affected repositories and can draft a pull request or hand off for local checkout.
Per project, you choose how far it is allowed to go on its own — Stop after Root Cause, Stop after Plan, or Stop after PR Drafted — and it also gates whether to act unprompted. Conceptually the automation rules read like this:
# Illustration of Seer's autofix gating, not a literal config file
autofix:
run_automatically_when:
- event_count >= 10 # not a one-off fluke
- first_seen_within: 14d # still relevant to current code
- fixability: high # model-scored confidence
stop_at: plan # root_cause | plan | pr_drafted
The requirement worth stealing regardless of whether you adopt Seer: at the Solution step you can tell it to add a unit test that reproduces the failure before it writes the fix. That turns a one-off patch into a regression guard, and it is the difference between closing an incident and closing the class of incident. A diagnosis you cannot re-run is a guess you got away with.
Where it hands the work off
Seer does not insist on being your code generator. Once it has a plan, it can delegate implementation to a Claude, Cursor, or GitHub Copilot cloud agent, and it reads existing rules files from Cursor, Windsurf, Cline, and Claude Code so the generated code respects conventions you already wrote down. Investigations can be kicked off straight from a Slack alert, which keeps the trigger point where the on-call engineer already is at 2am.
On pricing, Sentry charges $40 per active contributor per month — an active contributor being anyone who commits two or more PRs to a connected repo — layered on top of a paid Team, Business, or Enterprise plan. It supports every language and framework Sentry already does, because the intelligence rides on the telemetry, not on a per-language integration.
The takeaway
If you try Seer, the setting that determines whether you trust it is the automation level, and the mistake is starting at the top. Wire it to Stop after Plan first and read a couple of weeks of its root-cause writeups against issues you have already solved by hand. You will learn quickly where its 94.5% holds and where your system's weird corners confuse it. Only once the diagnoses stop surprising you should you let it draft PRs unattended.
An AI debugger is not valuable because it writes code. It is valuable because it does the backward walk through your telemetry that you were going to do anyway, faster and at 2am without you. Give it good traces and logs, make it prove the bug with a test, and keep the merge button human until it has earned otherwise.
Sources: Seer product page, Seer is Generally Available — Sentry Changelog, Autofix documentation