Nobody here wrote this.
The recording still knows what broke.

On code you inherited, the expensive part of a bug is not the change. It is finding the place the change belongs, in a system whose reasons left with the people who had them.

The problem

A symptom in unfamiliar code could be coming from any of four places, and the only way to rule out three of them is to read all four. That is slow work, it is difficult to justify against a roadmap, and it is the work that quietly gets skipped: a report that resists an afternoon of searching tends to be closed as unreproducible rather than fixed. The safety net is usually thin too — an inherited system rarely arrives with a suite anyone trusts — so even a change that looks correct is a change nobody can prove is harmless. And the context that would collapse all of this, why that branch is there and what the last maintainer was working around, is precisely what did not come with the handover.

How Snag helps

The attempt is graded rather than one-shot, which matters most when the answer is not obvious. A cheap first pass reads what was captured and decides whether this is even fixable in code, so nothing spends real effort on a third-party outage. What survives goes into a sandbox built to match the stack the repository actually uses, where the agent can search the code and step back through the recorded session to watch the failure happen — which is the step that turns a symptom into a location. When a report is severe, or the triage confidence is low, or there is no obvious area of the code to look in, the pipeline hands it to a more capable model instead of accepting the first plausible answer; the evidence and the sandbox are the same, and it counts as one fix-run either way. Then, before any of it reaches you, an independent pass reviews the change against the evidence and can send it back for revision.

What you get back

A change that arrives with its reasoning and the evidence behind it, which on a system nobody has a full model of is worth about as much as the diff. Reviews are not thrown away either: the fixes your team merges, and the corrections your reviewers make along the way, become material that later attempts look up in the same workspace — so the second time something in that corner breaks, the attempt starts from what your team decided rather than from nothing. Nothing merges without a human, which on inherited code is the part that matters: the judgement about a system you are still learning stays with the people who have to live in it.

Questions people actually ask

Our stack is old and slightly odd. Does the sandbox cope?

Partly, and here is the line. Where the stack is recognised, the sandbox is built to match it — dependencies installed, your test runner wired up — and the change is checked against your suite before anything is offered. Where it is not, the agent still reads and searches the code and still proposes a fix; what it cannot do yet is run your tests inside the sandbox, so the verification step falls back to you.

What stops it handing us a plausible fix in the wrong place?

Two passes it has to get through first. Your own tests, where they exist, have to pass before anything opens. And an independent review reads the proposed change against the captured evidence: it can approve, it can demand a revision with specific notes, or it can reject the framing altogether and send the report back to triage. That loop is bounded, so a report it cannot settle ends up in front of a person rather than circling.

Does our source end up in a model somewhere?

No. The work happens in a private copy of the repository, and that copy is destroyed when the run ends. What is kept is the evidence from the report and the history of what was opened — never your source — and nothing from your code is used to train a model. Later attempts do get better at your codebase, but by looking things up in your own merged fixes rather than by learning from them: per workspace, and never across workspaces.

Where these details come from

This page makes no claim about another product — every detail on it is Snag's own. Something out of date? Email admin@dvcllc.io and we will fix it.