I liked debugging. I liked the afternoon lost to one failure, and the moment the evidence finally lined up. I have not done it for a long time, and I do not think many people who work with current models have either. Debugging is dead. What surprised me is that the agents mostly do not do it either.
Debugging was never the goal. It was what we did because nobody can hold a whole program in their head. We set a breakpoint, printed a variable, or bisected history because we could not see what the code did by reading it. The debugger was a tool for a reader with a small working memory.
A model that reads the whole repository, the dependency it calls and the documentation of the service behind it does not need most of that ritual. It reads the path, says what is wrong and changes it. Sometimes it runs something to confirm. Often it does not have to.
What the September releases showed
Anthropic released Claude Opus 5.5 on September 22. The customer reports in that announcement are mostly about finding defects, and most of them describe reading, not stepping through.
- Deloitte's CIO reported that at its lowest effort setting the model caught 72 percent of the known bugs in their code reviews. The previous Opus caught 56 percent at high effort.
- An engineer at Column reported that in review it caught a bug by checking external documentation for a third-party integration the team had modeled wrong.
- A principal engineer at Chicago Trading Company wrote that overnight it "autonomously handled a bug in our Lakehouse services layer that I hadn't had time to diagnose", and that it "investigated, designed the fix, and implemented it on its own."
- Factory reported that on long, messy investigations it always came back with a clear, actionable answer.
None of those is a person at a breakpoint, and the first two are not even an agent at a breakpoint. The bug was found by something that understood the code and the system around it.
The hard cases are no different. In Anthropic's September report for Claude Fable 5.1, a senior portfolio manager at Millennium describes a crash that occurred roughly once in a million runs and had gone unexplained for four to five years. The model disassembled an outside vendor's library, matched it against a core dump and traced the crash to a bug in that library. That is the kind of investigation engineers expected to keep.
The success rate
The closest thing to a general rate is SWE-bench Pro: 1,865 problems taken from 41 real repositories, where the agent gets the repository and the issue and must produce a patch that passes the project's tests without breaking the rest. The Opus 5.5 system card reports 89.9 percent. Opus 5, released earlier this year, scored 79.2.
That number is the vendor's own, and earlier audits of this benchmark found that agents with open internet access sometimes looked up the published fix. So take the comparison that survives that objection. On Terminal-Bench 4.0, where the agent has to get real work done in a terminal, Opus 5.5 scored 66.4 percent against 52.3 for Opus 5 and 57.9 for GPT-6 Astra. Every measure moved the same way within one release.
OpenAI released GPT-6.1 Sol a week later, on September 29. On the independent Artificial Analysis coding agent index it finished one point ahead of GPT-6 Astra at under 15 percent of Astra's cost per task, as The Batch reported. Whatever a hard investigation cost in August, it costs a fraction of that in October.
Who still debugs
The strongest objection is a survey published on October 7. Three hundred senior engineering leaders, most of them working in C and C++, said their teams spend 16.9 hours a week debugging against 9.8 hours producing code. Ninety-three percent had seen an agent give a wrong root cause at least once in six months.
I believe those numbers, and I read them differently from the company that commissioned them, which sells debugging tools. The same survey says about a third of those teams let agents near comprehension and debugging only in straightforward codebases. Those teams keep the model away from the hard code and then spend their week debugging it by hand.
What is left
The work that remains is not debugging. It is making sure the model is looking at the system that actually failed: the version that ran, the configuration that loaded, the data that was there. A repository says what the program can do. It does not say what happened on Tuesday.
The other part is deciding what correct means. A model can trace a revenue calculation perfectly and still not know that the business counts refunded orders in last month's total. Someone has to say so.
Neither of those is the craft I enjoyed. I do not miss it as much as I expected.
Rewritten October 2026. Customer statements and Terminal-Bench figures are from Anthropic's September 22 and September launch announcements. The SWE-bench Pro figure is reported by Anthropic in the Opus 5.5 system card. The coding index result for GPT-6.1 Sol is from Artificial Analysis as reported by The Batch. The survey was run by Coleman Parkes for Undo and reported by InfoQ.