Anthropic Merges 30,000 Code Changes a Day — So Why Are 98% of Open-Source Issues Unclaimed?

Anthropic's engineering blog once revealed that the company merges more than 30,000 code changes per day. That number is staggering for any engineering team. But on the other side, in its public Claude Code GitHub repository, of 16,060 open issues, 15,766 — over 98% — have no assignee. Placed side by side, the two facts form a rather ironic picture: on one side, the code-merging pipeline runs at full speed; on the other, the entry point for external feedback is nearly clogged.

The question was raised on Reddit by a user who describes himself as a senior developer. The core challenge is not complicated: if Claude can write, review, and merge code at scale, why not use it to systematically triage issues, flag security vulnerabilities, and surface the problems that genuinely need human attention?

Merge Volume Is Not Issue Throughput, but Why Is the Gap So Wide?

The developer himself acknowledges that 30,000 internal merges a day and resolving public GitHub issues are not the same thing. Internal merges may be small commits, automated refactors, or dependency updates, whereas open-source issues require reading, reproduction, prioritization, and staffing. The two are indeed different in nature.

But the issue is the ratio. An unassigned rate above 98% means the vast majority of external feedback does not even reach the step of "being seen and assigned." Many issues have been open for months or even years, including security, privacy, and functional defects. A healthy open-source project usually has some proportion of unassigned issues, but when that proportion approaches all of them, it no longer reflects a shortage of manpower but a selective neglect in process design.

Code merge in a Git workflow refers to integrating commits from one branch into the main branch. It is typically triggered after review in the form of a Pull Request (PR) or Merge Request, and a single merge may contain only a few lines of change or an automatic dependency version bump. Thus "30,000 merges a day" measures change throughput, not the number of problems solved — a large share of merges come from bots, automated CI commits, and small iterations, and are not at all comparable to the time required for a human to read a single external issue.

Issue triage is borrowed from the medical field and refers to the preliminary classification of a problem before formal handling: determining whether it is a duplicate, assessing severity, applying labels, assigning an owner, or escalating to a specific team. Mature open-source projects usually have an on-call or bot-assisted triage process, and the unassigned rate is one of the key indicators of whether the feedback loop is functioning.

Security Vulnerabilities Queue Up in the Backlog

The post gives a concrete example: a privacy issue concerning the User-Agent header, involving Claude Code leaking users' email addresses to third-party websites without their consent. The issue had been reported in earlier issues dating back months, yet the relevant report remains open and unassigned to this day.

This touches the most sensitive part of open-source security governance. Public disclosure of security issues is itself risky; if no one responds for a long time, the reporter gets neither fix feedback nor any way to judge whether to pursue other disclosure channels. The more realistic consequence is that the problem may sit in the public repository until more people notice it and it gains traction on social platforms, forcing it into the handling process.

The rhetorical question in the post is quite pointed: why do problems have to go viral on Reddit or X before they get fixed?

Responsible Disclosure is a common convention in the security field: the finder first notifies the vendor privately, giving them a window to fix the issue, and only later discloses the details. Vendors usually provide a SECURITY.md or a dedicated security reporting email in the repository as a private channel. When a public issue goes unanswered for a long time, the reporter faces a dilemma — continuing to wait may delay indefinitely, while disclosing directly may expose users to risk. This is why "security issues must go to social platforms before being handled" is seen as a governance flaw: it forces disclosure, which should follow a private process, back into public channels.

A Signal of Resource Allocation: Pixel Hearts and Security Vulnerabilities

The poster also mentions a detail: Anthropic has the resources to add an easter-egg feature to its Windows desktop app — a pixelated heart that appears after multiple clicks on the screen — yet appears slow in triaging public issues.

The existence of a single feature certainly does not prove misallocation of resources; the easter egg may take only a tiny amount of manpower. But as an externally visible signal, it is indeed easy to interpret as a reflection of prioritization. When security vulnerabilities and privacy issues wait months in the queue while fun user-facing features ship as usual, external contributors and users will naturally question: whose interests does this project's feedback loop actually serve?

Is There a Technical Barrier to Using Claude for Issue Triage?

This is the part of the post most worth taking seriously. The poster is not asking Anthropic to replace human fixes with AI, but proposing a narrower idea: use Claude for preliminary issue triage — identifying duplicate reports, classifying by severity, flagging security-related items, and escalating the problems that require human judgment.

In terms of capability, these tasks are precisely what current large models are relatively good at: text classification, similarity matching, information extraction, and preliminary prioritization. The technical barrier is not obvious. The real problem may lie at the governance level — whether automated triage would misjudge, whether public repository issues are worth the engineering resources to build a pipeline, and where external issues rank on the internal priority list when the company's own merge cadence is already extremely fast.

The poster's observation is that there is a clear gap between the engineering capability Anthropic showcases externally and the speed at which it handles external feedback, and that this gap could be partly bridged by the very product it sells. Whether this challenge holds depends on whether Anthropic is willing to use Claude to maintain its own open-source project, not just on the code-production side.

Automated triage in engineering is usually implemented as a combination of rule engines, classification models, and nearest-neighbor retrieval: text embeddings are used to compute similarity between issues to identify duplicates, classifiers apply component and severity labels, and confidence scores decide whether to escalate to a human. The advantage of large language models in such tasks is that they do not require hand-written rules for each repository and can directly read titles, bodies, and comments to make semantic judgments; the limitation is the cost of misjudgment — labeling a security issue as ordinary, or incorrectly merging duplicate reports, can cause new information loss. Therefore, in practice, a hybrid model of "AI first pass + human review" is often adopted, with model output treated as a suggestion rather than a final assignment.

This Is Not Just One Company's Problem

Zooming out, the situation of the Claude Code repository is not isolated among AI companies. Rapidly iterating products, a flood of external feedback, and limited open-source maintenance manpower — the combination easily produces issue queues with high unassigned rates. The difference is that Anthropic happens to be one of the few companies that possesses both large-scale code automation capability and a large number of public issues, making this contradiction especially conspicuous in its case.

For developers using Claude Code, the practical implication is this: submitting an issue may not get a response, and for disclosing security issues you need to keep a backup plan of your own. For Anthropic, 30,000 merges a day is proof of engineering efficiency, but the 98% unassigned rate is another report card — and the community will see that one too.

One-line Summary

Anthropic merges 30,000 code changes a day, yet over 98% of its public issues are unassigned, exposing a clogged feedback loop.

Paragraph Summary

Starting from a challenge on Reddit, the article contrasts Anthropic's engineering efficiency — over 30,000 code merges per day — with the reality that 15,766 of the 16,060 open issues in the Claude Code public repository (over 98%) have no assignee. The author acknowledges that internal merges and open-source issue handling are different in nature, but points out that the stark ratio reflects selective neglect in process design rather than mere manpower shortage. The article cites a User-Agent privacy issue traceable back months to illustrate the risk of security reports languishing in the public queue, and questions why the company has the capacity to build a pixel-heart easter egg but not to use Claude for issue triage. The author argues that the technical barrier is low and the real obstacle lies at the governance and prioritization level.