In recent days, a familiar kind of narrative has swept across developer circles: the claim that GitHub is ‘dying’. It has appeared in videos, threads, and blog posts with the usual hallmarks of online virality: strong opinions, selective facts, and a tone of urgency that suggests an imminent collapse. Given how central GitHub remains to modern software development, it is hardly surprising that such claims attract attention. Yet, as is often the case, the reality is both less dramatic and more interesting than the headline.
The current wave of criticism did not emerge from nowhere. It was catalysed, in part, by a public critique from Mitchell Hashimoto, a figure whose opinions carry weight within the developer community. His frustration centred on reliability: repeated outages, degraded performance, and an overall experience that, in his estimation, fell well short of what one expects from a platform of GitHub’s stature. His decision to move his terminal project, Ghostty, away from GitHub was not merely a personal choice but a symbolic gesture that resonated with others who had experienced similar issues. It is important, however, to interpret this moment with care. High-profile departures can shape perception disproportionately; they signal discontent, certainly, but they do not in themselves constitute evidence of a broader exodus.
Reliability concerns are nonetheless real. GitHub has experienced intermittent instability in recent months, and while no large-scale platform is immune to outages, expectations in this domain are exceptionally high. Developers rely on such services not only for storage but for collaboration, automation, and deployment pipelines. When interruptions occur, they ripple through entire workflows. The perception that reliability has slipped, even if only temporarily, can therefore have an outsized impact on trust. What remains less clear is whether these incidents represent a systemic decline or a series of unfortunate but ultimately transient issues. At present, the evidence supports frustration, but not collapse.
Source: GitHub’s own status logs for late April 2026
Alongside these operational concerns sits a more subtle, yet arguably more consequential, shift: changes to data usage policies for GitHub Copilot. As of late April 2026, GitHub moved to an opt-out model for certain forms of data collection used in training its AI systems. In practical terms, this means that interactions, such as prompts and generated code, may be used to improve models unless the user explicitly disables this behaviour. For many developers, particularly those working across personal and professional contexts, this introduces a degree of ambiguity that did not previously exist. The concern is not that entire repositories are being indiscriminately absorbed into training datasets, as some commentary has suggested, but rather that the boundary between private work and aggregated learning has become less immediately transparent.
It is worth noting that these concerns are not without qualification. Organisational and enterprise tiers are excluded from such data usage, and the opt-out mechanism remains available. Nevertheless, defaults matter. In software, as in many other domains, what is enabled by default often defines the practical reality of a system. The shift, therefore, is less about technical risk in the strictest sense and more about a recalibration of expectations around control and consent.
A further source of unease arises from changes to pricing. GitHub’s move towards a more usage-based model for Copilot reflects a broader industry trend: the recognition that AI-assisted tooling incurs substantial and uneven costs. Under such a model, light users may see little difference, while heavier users, those running extended sessions or integrating AI deeply into their workflows, may encounter higher and less predictable expenses. It is not difficult to understand why this has been received with scepticism. Developers tend to value clarity and stability in pricing, and any departure from that can feel, rightly or wrongly, like a shifting of the goalposts.
Compounding these issues was a temporary pause on new Copilot sign-ups, justified by GitHub as a measure to maintain service quality. Although this decision was framed in pragmatic terms, it inevitably fuelled speculation about underlying capacity constraints. Whether such speculation is warranted remains unclear; what can be said is that the optics of limiting access, even temporarily, sit uneasily alongside narratives of rapid expansion and technological progress.
Taken together, these developments form the basis of the current backlash. Yet it is equally important to consider what has been overstated or misrepresented in the process. Claims of a mass departure from GitHub, for instance, are not supported by credible evidence. The platform continues to dominate its space, and while alternatives such as GitLab attract periodic attention, there is no indication of a large-scale migration. Similarly, the suggestion that GitHub’s focus on artificial intelligence has directly caused reliability issues remains speculative. Correlation, in this case, has been readily interpreted as causation without sufficient proof.
Adding to the general unease, a number of more sensational claims began to circulate online, including suggestions that Copilot had, at one point, inserted what resembled promotional content into pull requests. These reports are difficult to substantiate and have not been confirmed by reliable sources, yet their spread is telling in itself. They reflect a growing suspicion among some developers that the platform’s priorities may be shifting in ways that are not entirely aligned with user interests. Even when such claims prove unfounded, they tend to gain traction in an environment where trust is already under strain.
What, then, should one make of the situation as a whole? Rather than signalling decline, it seems more accurate to view this moment as a period of adjustment. GitHub, like many technology platforms, is navigating the complex transition towards AI-integrated workflows while attempting to balance cost, performance, and user trust. Each of the current points of contention, reliability, data usage, or pricing, reflects a facet of that broader challenge.
For developers, the appropriate response is neither alarm nor indifference, but informed attention. The concerns being raised are not trivial; they touch on fundamental aspects of how tools are built, maintained, and monetised. At the same time, the more dramatic narratives obscure as much as they reveal. GitHub is not ‘dying’, but it is changing, and not all of those changes will be universally welcomed.
In the end, the significance of this episode lies less in any single policy or outage, and more in what it reveals about the relationship between developers and the platforms they depend on. Trust, once established, can be surprisingly resilient, but it is not immutable. Moments like this serve as a reminder that even the most entrenched tools must continually justify that trust, not through promises or positioning, but through consistent, transparent, and reliable behaviour over time.
Top comments (0)