Andrew Kelley, lead developer of the Zig programming language, didn't migrate the project's infrastructure to Codeberg because of a philosophical disagreement about open source. He left because GitHub is technically rotting. The catalyst wasn't a grand ideological schism, but a specific, humiliating failure in GitHub Actions: a regression in a basic sleep script that went unaddressed for months. While GitHub's leadership was busy integrating Copilot into every pixel of the UI, their CI runners were failing to execute a simple sleep command. This is the new reality of "Vibe-Scheduling"—a term Kelley coined to describe the shift from deterministic infrastructure to probabilistic, AI-prioritized chaos.
The Engineering Reality
The core of the dispute lies in a trivial utility script, safe_sleep.sh, used within GitHub Actions to handle timing on Windows runners. In a functional DevOps environment, sleep is a solved problem. In GitHub's current state, it became a blocking regression.
The outage began when a developer introduced a logic error into the script intended to replace POSIX sleep. The script utilized a busy-wait loop that failed to account for process scheduling latencies—latency likely exacerbated by the heavy resource contention on Azure/GitHub hosts.
Here is the logic failure that took down the Zig CI:
This bug was reported in April 2025. It caused 100% CPU usage loops, locking up runners. A fix was technically applied in August, but the relevant thread and the users suffering from it were ignored until the Zig Foundation publicly exited in December.
Resource Contention
What is "Vibe-Scheduling"?
This incident defines "Vibe-Scheduling"—the operational reality where your CI jobs are bin-packed alongside massive AI inference workloads. Unlike standard noisy neighbors, AI workloads create massive, unpredictable spikes in CPU and I/O pressure.
When a platform pivots aggressively to AI, legacy compute resources are often deprioritized or over-provisioned. The hidden liability for CTOs is the fact that your deterministic pipeline (compilation) is now probabilistic. The specific limitation here isn't just bad code; it is execution starvation. GitHub's silence suggests that maintaining legacy infrastructure scripts is low-priority compared to shipping the next Copilot feature, leaving systems engineers to debug race conditions caused by the platform itself.
Platform Economics & Stability
The trade-off is no longer Feature vs. Feature, but Revenue Risk vs. Engineering Autonomy.
| Metric | GitHub Actions | Codeberg (Forgejo) |
|---|---|---|
| Core Stability | Volatile (Prone to "AI pivot" neglect) | High (Deterministic, simple stack) |
| Compute Priority | Shared with massive AI workloads | Dedicated/Isolated for standard DevOps |
| Revenue Model | $170k/yr Revenue at Risk (Sponsors Lock-in) | Donation/Grant based (Diversified funding) |
| Data Sovereignty | None (Code used for training Copilot) | Strict (No non-consensual scraping) |
| Platform Cost | "Free" for Public (paid in data/stability) | <$10k/yr (Hosting Expense) |
What Devs Are Saying (Hacker News)
The community reaction on Hacker News is less about "Open Source purity" and more about competence. Andrew Kelley's announcement provided the definitive critique:
"After the GitHub CEO said to 'embrace AI or get out', it seems the lackeys took the hint."
This quote, widely amplified on HN, is damaging because it attacks the engineering culture, not the product features. It implies that GitHub staff ("lackeys") are incentivized to ignore basic maintenance tickets like a broken bash script because fixing them doesn't align with the executive "AI or die" mandate. The consensus is that GitHub has abandoned the reliability guarantees of a utility provider in favor of the volatility of a feature factory.
Final Verdict
- For Research/Hobby Projects: GitHub remains convenient due to its network effects.
- For Enterprise/Systems Engineering (Hard Reject on Mono-Cloud): If your product requires custom runners, specific OS compilations (like Zig), or strict timing, GitHub is now a stability risk. The "AI Obsession" is not just marketing noise; it is actively eroding the reliability of the underlying compute substrate.
Recommendation
Follow Zig's lead. Do not rely on a single vendor for your CI/CD. Mirror your repositories to a Forgejo/Gitea instance or a bare-metal provider where sleep actually means sleep.