From bug report to shipped fix: a Claude Code walkthrough

Most writing about agentic coding stays at the altitude of slogans: the agent ships the feature, productivity multiplies, the future is here. The actual experience of using Claude Code to fix a real problem is grittier and far more instructive. So instead of abstractions, here is a single concrete journey, start to finish: a vague customer bug report on a Monday morning, and the verified pull request that closes it by lunch. The point is not the bug. The point is the shape of the work — what the human does, what the agent does, and where the handoffs live.

The problem: a bug report that explains nothing

The ticket reads: "Some customers are seeing duplicate charges on their invoices, started a few days ago, can't reproduce reliably." That is the whole report. No stack trace, no steps, no account ID. This is the realistic starting point for most production work, and it is exactly the kind of fuzzy, investigation-heavy task where people assume an agent is useless. It is not — but only if you use it as an investigator first and a code generator second.

The instinct to avoid is dumping the ticket into Claude Code and asking it to "fix the duplicate charge bug." It has no idea what your invoicing code looks like, no access to the data showing which customers are affected, and no way to reproduce the issue. It would produce a confident, plausible, and almost certainly wrong change. The job in this phase is human: turn an unreproducible complaint into a crisp, well-scoped problem statement the agent can act on.

Phase one: investigation with the agent as a research partner

The first useful move is to give Claude Code the context it needs to investigate. With the right Model Context Protocol servers wired up — one for the codebase, one read-only server for the production database, one for the logging system — the agent can do real forensic work. I asked it to find every code path that writes an invoice line item, then to query the logs for the affected time window and correlate duplicate line items against deploys.

This is where the read-only constraint earns its keep: the agent is querying production data to understand the bug, but it cannot mutate anything. Within a few minutes it surfaced the pattern — duplicates clustered around requests that timed out and were retried by an upstream client, and the invoice-write path was not idempotent. The retry created a second charge. That insight would have taken a human an hour of log-spelunking; the agent did the mechanical correlation and I confirmed the conclusion.

flowchart TD
  A["Vague bug report"] --> B["Human scopes the problem"]
  B --> C["Agent investigates: code + logs + read-only DB"]
  C --> D{"Root cause found?"}
  D -->|No| C
  D -->|Yes| E["Human writes the spec & failing test"]
  E --> F["Agent implements idempotent fix in sandbox"]
  F --> G{"Tests & evals pass?"}
  G -->|No| F
  G -->|Yes| H["Human reviews diff & ships PR"]

Phase two: writing the spec and the failing test

Now the work inverts. Root cause in hand, I wrote the specification myself, because this is the cheapest place to be precise: the invoice-write path must be idempotent on the client-supplied idempotency key; a retried request with the same key must return the original charge, not create a new one; existing duplicate charges from the incident must be detectable but not auto-corrected, because financial corrections need human sign-off.

Then, before any fix, I had Claude Code write a test that reproduces the bug — a test that fires the same idempotency key twice and asserts a single charge. It failed, exactly as it should. This failing test is the contract. It converts "fix the duplicate charge bug" from a vibe into a concrete, checkable target. It also means that whatever the agent generates next has an objective bar to clear that I trust more than the agent's own claim of success.

Phase three: implementation, contained and verified

With a precise spec and a failing test, code generation is finally the right tool. I had the agent implement the idempotency check — a lookup on the key before insert, returning the existing charge on a hit — working in a sandboxed branch with no ability to touch production. It produced a clean diff, the failing test went green, and the broader suite stayed green.

This is the moment that separates safe teams from reckless ones. A green test is necessary, not sufficient. I read the diff as if a junior engineer had written it, and caught something the tests did not: the agent's lookup had a race condition under concurrent retries, because it checked-then-inserted without a unique constraint. I pointed this out, the agent added a database-level unique constraint on the idempotency key so the race resolves correctly, and we added a second test for the concurrent case. That back-and-forth — agent proposes, human catches the subtle flaw, agent corrects — is the actual rhythm of productive agentic coding.

Phase four: shipping and the human-only steps

The pull request that shipped had three commits: the failing test, the idempotency fix with its unique constraint, and the concurrency test. It went through normal review and merged like any other change. But two parts of this work stayed deliberately human. The data cleanup for customers already double-charged was done by a person, with finance in the loop, because refunding real money is exactly the irreversible, judgment-heavy action you never delegate to an autonomous agent. And the customer communication — explaining what happened and confirming the refund — was written by a human who owned the relationship.

Tallying it up: a fuzzy Monday-morning ticket became a verified, shipped fix before lunch. The agent did the log correlation, the boilerplate implementation, and the test scaffolding — easily the bulk of the mechanical hours. The human did the scoping, the spec, the critical review that caught the race condition, and every irreversible decision. That division of labor is not a compromise. It is the design.

Frequently asked questions

Why not just let the agent fix the bug from the ticket directly?

Because the ticket did not contain a problem statement — it contained a symptom. An agent handed a symptom invents a plausible cause and fixes that, which is worse than doing nothing because it looks like progress. The investigation phase, with real log and code access, is what turns a symptom into a root cause the fix can actually target.

What made the agent effective in the investigation phase?

Tools and scoped access. With MCP servers connecting it to the codebase, the logs, and a read-only view of production data, the agent could do genuine forensic correlation instead of guessing. Without that connectivity it would have been limited to reasoning about code it could see, which would have missed the retry pattern entirely.

How much of this could be fully automated?

The investigation and implementation, largely. The spec, the critical diff review that caught the race condition, and every irreversible action — the refunds, the customer message — should stay human. The lesson of this walkthrough is not "automate everything" but "automate the mechanical middle and own the judgment-heavy ends."

What was the highest-leverage human moment?

Reading the diff and noticing the concurrency race the tests did not cover. The agent's fix was correct for the case the test described and subtly broken for a case it did not. That gap is precisely where senior verification skill pays for itself.

The same loop, on your phone lines

CallSphere runs this investigate-act-verify loop on voice and chat — agents that look up account data mid-call, take the safe action, and escalate the judgment calls to a human. See an end-to-end agentic conversation at callsphere.ai.

---

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.