>_TheQuery
← All Articles

Vibe Coding Broke GitHub. That Is Not the Surprising Part.

By Addy · April 30, 2026

On April 23, 2026, code started disappearing.

Not visibly. No error message. No red flag in the CI pipeline. Teams using GitHub's merge queue with squash merges were watching their pull requests complete normally: green checkmarks, successful deployments, clean histories. What they could not see was that the second pull request in a merge group could quietly undo the first. Work that had been reviewed, approved, and confirmed as merged was being reverted underneath the UI that said everything was fine.

It took GitHub approximately three hours and thirty-three minutes to notice. Not through automated monitoring. Through customer reports. GitHub's own incident write-up says the issue was not detected automatically because it affected merge commit correctness rather than availability.

That distinction is the story. The platform was up. The merges were completing. The code was wrong. All three things were true at once.

What Actually Broke

A squash merge is the tidy-history workflow most teams know well: many commits on a feature branch are condensed into one commit on the default branch. Merge queue is GitHub's throughput layer for busy repositories: instead of merging one pull request at a time, GitHub tests and merges groups of pull requests together so teams do not have to serialize every change behind CI.

On April 23, those two features interacted badly.

GitHub's root cause analysis says the regression affected pull requests merged through merge queue using the squash merge method when the merge group contained more than one pull request. The new code path adjusted merge base computation for merge queue ref updates. It was intended to be gated behind a feature flag for an unreleased feature. The gating was incomplete. The result was an incorrect three-way merge that caused subsequent squash merges to revert changes from earlier pull requests and, in some cases, changes between their starting points.

The test gap was as revealing as the feature-flag gap. GitHub says existing automated coverage primarily exercised single-PR merge queue groups. Multi-PR squash groups were not validated for merge correctness, so the defect surfaced only in production.

During the impact window, 658 repositories and 2,092 pull requests were affected. GitHub says there was no data loss because the commits themselves remained stored in Git. But the state of affected default branches was wrong, and GitHub could not safely repair every repository automatically.

Three Different Failures, Same Trust Problem

The merge queue regression would be serious enough on its own. It did not happen on its own.

On April 27, GitHub says an overloaded Elasticsearch subsystem likely triggered by a botnet attack caused search-backed parts of pull requests, issues, and projects to show no results in the UI while the underlying data remained intact.

On April 28, GitHub disclosed a critical remote code execution vulnerability in its git push pipeline. According to GitHub's security post, Wiz reported the issue on March 4, 2026. GitHub reproduced it within 40 minutes, deployed a fix to github.com by 7:00 p.m. UTC that same day, and concluded there was no exploitation. The bug allowed a crafted push option to influence internal metadata and bypass the sandboxing protections that normally constrained hook execution.

These were different incidents with different root causes. But they all touched the same trust boundary: developers rely on GitHub not just to stay online, but to preserve code correctly, display repository state correctly, and process core Git operations safely.

GitHub's Own Explanation Points to Agentic Scale

GitHub's CTO was unusually direct about the bigger backdrop.

In GitHub's April 28 availability update, Vlad Fedorov wrote that GitHub began a plan to increase capacity by 10X in October 2025. By February 2026, he said, it had become clear the company needed to design for 30X today's scale. The main driver, in GitHub's words, is that since the second half of December 2025, agentic development workflows have accelerated sharply.

GitHub's own charts in that post show merged pull requests peaking at 90 million and commits peaking at 1.4 billion.

That does not prove every extra pull request came from AI agents. It does not need to. GitHub itself is explicit about the direction: repository creation, pull request activity, API usage, automation, and large-repository workloads are all rising together, and the company is planning infrastructure around that reality.

This is why the headline matters. Vibe coding did not "break GitHub" in the literal sense that one prompt caused one outage. But the way software is now being built and shipped is clearly changing GitHub's operating envelope. Merge queue exists to help repositories handle high-throughput parallel change. GitHub says it is now optimizing that path specifically because some repositories are dealing with many thousands of pull requests a day.

That is an agentic systems story before it is anything else.

Vercel Already Hit the Same Loop

GitHub was not the only developer platform to get pulled into this pattern.

A few days earlier, Vercel disclosed an April 2026 security incident that began with the compromise of Context.ai, a third-party AI tool used by a Vercel employee. According to Vercel, the attacker used that access to take over the employee's individual Vercel Google Workspace account, pivot into a Vercel environment, and enumerate and decrypt environment variables that were not marked as sensitive.

The timing is almost too on the nose. On April 9, Vercel published a post called "Agentic Infrastructure" explaining that agents are already driving more than 30% of deployments on Vercel and that its CLI, API, MCP servers, and git integration give agents native access to a deployment surface where they can generate code, open a pull request, get a preview URL, verify the output, and ship.

Then, days later, the deployment platform being rebuilt around agents had to disclose an incident that started with a compromised AI tool.

That does not mean Vercel's agent infrastructure caused the breach. Vercel's own bulletin points to a third-party AI tool and account compromise, not a direct failure of its deployment product. But it does make the larger pattern harder to ignore. The companies building the rails for agentic software are also becoming test cases for the new risks that agentic software introduces.

At this point it is not just irony. It is a loop.

The Important Gap Is Not Downtime. It Is Wrongness.

Most reliability systems are built to answer a straightforward question: is the service up?

The April 23 incident exposed a different question: is the service producing the correct result?

GitHub's own incident report says the regression escaped detection because automated monitoring was tuned for availability, not merge correctness. That is not a minor monitoring miss. It is a preview of the failure mode that matters most in agentic software workflows.

When humans write code slowly, one pull request at a time, wrongness is often caught socially. A reviewer notices. A developer spots something odd in the branch. A deploy goes sideways and the team narrows the blast radius quickly.

When agents generate, review, and route work at much higher volume, the dangerous failures are the quiet ones. The UI says merged. CI says passed. The deployment succeeds. The code is still wrong.

That is a harder problem than uptime.

What This Actually Signals

The easy reading of last week is that GitHub had a bad run: one merge queue regression, one search-related disruption, one serious security disclosure.

The more interesting reading is that GitHub is colliding with a future it can already see coming.

The code-generation layer is moving faster than the infrastructure layer underneath it. The models can already produce more changes, more pull requests, and more automation than the surrounding systems were designed to reason about safely. GitHub's own 30X planning language is an admission that the old assumptions no longer hold.

The surprising part is not that something broke. At this scale, under this much change, things break.

The surprising part is where the break happened. Not in model inference. Not in a chatbot UI. In the oldest, hardest part of software collaboration: preserving the integrity of history while many changes land at once.

GitHub's merge queue bug was not a random embarrassing outage. It was a glimpse of what happens when infrastructure built for human commit velocity meets a world where agents are helping produce software at machine speed.

That world is already here. The stack beneath it is still catching up.

Sources:

Previously on TheQuery: Cursor 3 Bets on a Different Kind of Developer and The Day Claude Code's Moat Disappeared