The Crime Against Software: Analyzing GitHub's Infrastructural Decay
The modern software development landscape is almost synonymous with GitHub. For many developers, a GitHub profile is a prerequisite for professional legitimacy. However, beneath the polished interface of the world's most popular code host lies a growing pattern of infrastructural decay. When a service becomes the central nervous system of global software production, its reliability and performance are no longer mere "user experience" concerns—they become systemic risks.
Recent outages and performance dips are often dismissed as the growing pains of "agentic development workflows." But a closer look suggests that the current state of GitHub is not an accident of growth, but a result of deliberate priorities that favor flashy AI features over fundamental engineering excellence.
The AI Priority Paradox
Microsoft and GitHub have aggressively pushed "AI Agents" and Copilot into every corner of the platform. On a typical repository landing page, users are met with multiple AI buttons, often four in a single quadrant of the screen. This push isn't just a UX choice; it's a resource drain.
GitHub has attributed recent availability struggles to the rapid acceleration of agentic workflows. However, this "load" is a direct consequence of their own strategy. By subsidizing these tools to drive adoption, GitHub effectively funded a distributed denial-of-service (DDoS) attack on its own infrastructure.
While Microsoft claims that "availability first, then capacity, then new features," the data suggests otherwise. A review of GitHub's public changelog over a 30-day period reveals a stark contrast in priorities:
- Copilot mentions: 59
- Agent mentions: 8
- Performance mentions: 0
- Reliability mentions: 0
Quantifying the Bloat: A Comparative Experiment
To understand the extent of the technical decay, an experiment was conducted to compare the frontend resource usage of GitHub against GitLab and Codeberg (Forgejo). The goal was to measure the cost of rendering a minimal, identical repository across all three services using a throttled "Fast 3G" connection to simulate real-world constraints.
Memory and Heap Usage
Even in a steady state with no active processing, the RAM consumption is staggering. While a PlayStation 2 operated on 32 MiB of total RAM to render 3D graphics, modern web frontends for code hosting are consuming far more just to display text.
| Service | Steady-State Heap Usage |
|---|---|
| Codeberg | ~14 MiB |
| GitLab | ~68 MiB |
| GitHub | ~69 MiB |
When loading actual content, the waste escalates. A heap snapshot of a high-activity page (like the Rust language pull requests) showed spikes of over 148 MiB—more memory than the original iPhone possessed—just to render a list of links.
Network Payload and Code Volume
Using a custom analysis tool (anhar), the network requests for a blank repository were dissected. The results reveal a massive disparity in the amount of code delivered to the client.
- GitHub: Loads approximately 300 files totaling ~550,000 lines of code and data. To put this in perspective, this is more code than was required to build the original DOOM (35k lines) or the entire MS-DOS 4.0 operating system (332k lines).
- GitLab: Pulls
7 MiB over 70 files (10,000 lines). - Codeberg: Pulls
1 MiB over 11 files (1,100 lines).
GitHub's reliance on Webpack for chunking has resulted in a fragmented delivery system where hundreds of independent HTTP requests are required, adding significant overhead and slowing the "Time to Interactive" to an unacceptable degree. In some tests, a blank page took over 21 seconds to fully load on a throttled connection.
The "Enshittification" of Infrastructure
There is a common theory called "enshittification," where a product first serves users, then business customers, and finally serves only its own shareholders. But GitHub's decay feels different. The bloat doesn't just hurt the user; it hurts Microsoft. They pay the bandwidth costs and the engineering hours required to maintain a ramshackle codebase.
This is not mere technical debt; it is a failure of professional integrity. When a platform's frontend is this inefficient, it raises a critical question: if the "dining room" (the frontend) is this neglected, what does the "kitchen" (the backend and database architecture) look like?
Community Perspectives and Alternatives
The reaction from the developer community is split. Some users remain satisfied, arguing that the scale of GitHub's operation justifies some inefficiency. Others see the writing on the wall and are migrating to leaner alternatives.
"I put that puppy on my tailnet, installed Gitea, and I've been using it exclusively for all my projects. I feel free." — @jodacola
Others warn that the real "lock-in" isn't the code, but the social capital—the GitHub stars. As noted by @ashishb, stars act as a currency for project importance, and the existence of services that sell fake stars further corrupts the signal of software quality.
Summary of Grades
| Service | Grade | Verdict |
|---|---|---|
| Codeberg | C+ | Promising fundamentals, but lacks compression and minification. |
| GitLab | D+ | Struggling with excessive unused JS/CSS and poor garbage collection. |
| GitHub | F | Comically overweight; prioritizes AI prompts over basic performance. |
Conclusion
Software is intended to solve problems for users. When the tools we use to build the world's software become examples of waste and incompetence, it is more than a bad product—it is a crime against the medium. The industry's current obsession with AI-driven "agents" is creating a feedback loop of corrosion, where AI-generated code and AI-driven load are degrading the very platforms that host them. The path forward requires a return to the fundamentals: efficiency, reliability, and a respect for the user's resources.