I Classified 600 of the Loudest Issues in 6 Coding Agents. Model Output Quality Is 4.7% of Them.

TL;DR: I pulled the 600 most-reacted issues across the public trackers of six coding agents (claude-code, Continue, Cline, aider, goose, opencode) and classified every one. 232 of 600 are feature requests, not bugs. Of the 321 defect reports I could classify, 306 (95.3%) are about the harness and 15 (4.7%) are about model output quality. The biggest single defect category is not bad code: it is getting the tool to talk to a model provider at all (24.5%). Environment and install issues are both the oldest still-open (median 441 days) and the most likely to be closed as "not planned" (26.3%). The thing people argue about is not the thing that breaks.

Public issue trackers are the one place the failure distribution of an AI coding tool is visible without signing anything. So I read them. On 2026-08-15 I queried the GitHub search API for the 50 most-reacted open issues and the 50 most-reacted closed issues in each of six repos, sorted server-side by reaction count, giving a sample of exactly 600. Then I split feature requests from defect reports by title and put the defects into a fixed taxonomy.

Two notes on the method before the numbers, because both cost me time. GitHub's unauthenticated REST API allows 60 requests per hour, and the search endpoint allows only 10 per minute, so this had to be a slow, deliberate 16-request pull rather than a crawl. And two of the six repos had moved: block/goose now redirects to aaif-goose/goose and sst/opencode now redirects to anomalyco/opencode. The search endpoint does not follow those redirects, it returns a 422 claiming the repository does not exist. Four of my first twelve calls died that way before I re-resolved the names through the repos endpoint.

What did 600 issues actually say?

The first surprise is that the loudest issues are mostly not bugs. 232 of 600 (38.7%) are feature requests. The single most-reacted issue in the entire sample is claude-code #6235, "Feature Request: Support AGENTS.md", sitting at 5,916 reactions and still open. Reaction counts measure demand, and demand mostly points at things that do not exist yet.

Setting those aside, here is the classified defect distribution across all six tools:

Category	Defect reports	Share
model/provider wiring	88	24.5%
IDE and terminal integration	80	22.3%
tool-calling failure	62	17.3%
environment / install	34	9.5%
auth / limits	25	7.0%
model output quality	15	4.2%
data loss	9	2.5%
cost / billing	8	2.2%
could not classify	38	10.6%

Excluding the 38 I could not confidently place, 306 of 321 defect reports describe the machinery around the model and 15 describe the model's output. The argument that dominates every conversation about AI coding, whether the generated code is any good, accounts for one issue in twenty-one.

Why is wiring up a model the single biggest category?

Because it is the part with the most surface area and the least standardization. This category swallowed titles like "Cline + deepseek R1 on local ollama cannot use tools," "OpenRouter chat doesn't work with some providers/models," "Unable to connect to Anthropic models provided through SAP AI Core," "Agent doesn't support LM Studio," and claude-code #8763, "API Error: 400 due to tool use concurrency issues" at 277 reactions. Ollama, OpenRouter, DeepSeek, Qwen, Bedrock, Vertex, Azure, LM Studio, Kimi, Mistral, Databricks: every one of them is a different authentication scheme, a different tool-call encoding, and a different set of silent truncations.

I counted these as harness failures, and I want to defend that choice because it is the one judgment call that moves the headline number. When Cline cannot get a tool call out of a local DeepSeek deployment, the model did not produce bad code. It never got asked properly. That is plumbing. If you disagree and reclassify every provider-wiring issue as a model problem, the harness share still lands at 68%.

What is missing from the top categories?

Code quality. And the honest caveat is that share is not the same as intensity. The two loudest quality complaints in the sample are enormous: claude-code #42796, "Claude Code is unusable for complex engineering tasks with the Feb update" drew 3,286 reactions, and "Claude says 'You're absolutely right!' about everything" drew 1,375. Fifteen issues can carry more collective anger than eighty. What the count shows is that quality complaints are rare and huge, while harness complaints are constant and small, and only one of those two patterns is what you will actually spend your Tuesday on.

That gap matters because the industry survey data points the other way. Stack Overflow's 2025 developer survey found 46% of developers actively distrust AI output against 33% who trust it, with 66% naming "AI solutions that are almost right, but not quite" as their top frustration. Developers report that their problem is output quality. Their bug trackers say their problem is install paths, editor panes, provider endpoints, and tool calls that time out. Both can be true, and the gap between what people report and what they file is the same gap that shows up when you look at who actually measured AI coding productivity.

What gets ignored the longest, and what gets closed as "not planned"?

Environment and install issues, on both counts. Their median age while still open is 441 days, nearly double any other category, and 26.3% of the closed ones were closed as not_planned rather than completed. The oldest example in the sample is claude-code #1455, "Claude Code does not respect the XDG Base Directory specification", open with 436 reactions.

IDE and terminal integration is close behind at 25.6% not planned, then provider wiring at 22.7%. The category maintainers are most likely to actually fix is tool-calling failure, at 7.4% not planned, followed by auth and limits at 9.1%. Across all 300 closed issues in the sample, 21.0% were closed as not planned.

There is a logic to that shape. Tool-calling failures are unambiguous and reproducible, so they get fixed. "Your app should follow the XDG spec on my distro" is a preference argument about someone else's machine, so it ages. The saddest single row in my sample is a data-loss report, claude-code #40710, describing an automated tool running git reset --hard origin/main in a user's project. 121 reactions. Closed as not planned.

Why can't you rank these six tools against each other?

Because issue volume tracks user count, not defect rate, and the spread here is enormous: claude-code's tracker reports 69,360 closed issues to aider's 3,012. Publishing "claude-code has 23x more bugs" would be a lie dressed as arithmetic. The only comparison that survives is within-tool category share, and there the finding is boringly consistent: the harness share of classified defects is 88% for claude-code, 99% for Continue, 95% for Cline, 94% for aider, 95% for goose, and 100% for opencode. No tool is the outlier. It is a property of the category.

What does this not prove?

Sampling by reactions selects for issues that are visible, relatable, and annoying, not for issues that are severe. A silent wrong edit in a private repo generates no thumbs-up. I classified by title only, which is why 38 defects stayed unclassified and why every number here should be read with a couple of points of slop. Reaction counts came from the API directly rather than any aggregator, but the taxonomy is mine, and I added "model/provider wiring" as a category because the data demanded it, not because I planned it.

What would change my mind is a labeled sample of issue bodies rather than titles, or telemetry on failures nobody bothers to file. Until someone publishes that, the trackers are what we have, and they say the same thing six times: in 2026 the agent is not mostly failing to write good code. It is mostly failing to start, connect, render, or finish. Which is also why "just self-host it" is not the escape hatch it sounds like, and why the licensing of the harness deserves more scrutiny than it gets, and why a demo that works proves so little about real work.