How Vibecoding Destroyed Your Team's Attention in Two Weeks

The Slack channel was called #ci-alerts. Twelve people were in it. When I first looked at it on a Monday morning, it had 94 unread notifications from the weekend. All red. All CI failures. All from bot-authored pull requests that nobody was ever going to fix.

I scrolled back to find the last time a human had actually reacted to a message in that channel. Thursday. Four business days of silence. Not because the team was lazy. Because the channel had become physically impossible to use.

This was a six-person engineering team at a startup I advise. They'd given two of their developers access to Cursor and Copilot about a month earlier. Both engineers were enthusiastic. Both started pushing PRs at a pace the team had never seen before. Fifteen, sometimes twenty per day between the two of them. Small changes, mostly. Twelve lines here, thirty lines there. Quick fixes the agent suggested, pushed immediately.

The agents were prolific. They were also wrong about a third of the time.

What 30% failure rate actually looks like in a Slack channel

We analyzed 24,560 pull requests across 447 GitHub repositories. AI-generated PRs in that dataset have a 32% failure rate. Human PRs sit at 25.5%. That 6.5-point gap sounds small until you account for volume.

A human developer might push two or three PRs per day. An engineer using an AI agent pushes ten to twenty. If 30% of those fail, you're looking at three to six failure notifications per developer per day. With two vibecoders on a six-person team, that's six to twelve red alerts daily that nobody can act on, because nobody wrote the code that failed.

The CI channel starts filling up with noise. And once the noise crosses a certain threshold, the channel dies. Not formally. Nobody unsubscribes. People just stop reading it.

12 minutes to 3 hours

I measured the team's response time to CI failures over six weeks. The first two weeks, before the AI tooling ramp, their median response to a genuine failure was about 12 minutes. Someone would see the red badge, click through, read the logs, push a fix or comment on the PR. Fast.

Two weeks after the vibecoding started, the same metric was over 3 hours.

Nothing about the team had changed except the signal-to-noise ratio in their alert channel. The same people, the same codebase, the same pipeline. But where they used to see one or two failures per day (almost always real problems worth investigating), they were now seeing eight to twelve, and most were bot PRs that had already been abandoned.

The human brain is not subtle about this. You train yourself to ignore the thing that lies to you most of the time. After a few dozen false alarms, the instinct to click through evaporates. A real CI failure, a genuine regression in production-bound code, now sits unread in a channel that feels like spam.

The failure that mattered

Week three. A senior engineer pushed a database migration that broke the staging environment. CI caught it. Red badge appeared in #ci-alerts right alongside eleven other red badges from bot PRs that had failed on lint rules.

Nobody noticed for five hours.

The staging environment was down that entire time. A QA engineer eventually found it by accident when she tried to test a feature and couldn't connect. She pinged the channel, and three people replied within minutes. The alert had been sitting there, unread, buried under noise.

That five-hour gap would have been twelve minutes a month earlier. The pipeline caught the bug exactly as designed. The team just wasn't listening anymore.

The math on abandoned PRs

Here's the number that makes the alert fatigue problem structural rather than behavioral. We tracked 7,498 CI failure events across our dataset and checked whether each failed PR was ever repaired.

For human PRs: 23.4% of failures get fixed and eventually pass.

For AI PRs: 9.3%.

Ninety-one percent of failed AI pull requests are never touched again after the initial failure. The agent submitted, CI caught a problem, and nobody came back. Not the agent. Not the developer who prompted it. The PR sits in the queue, red, sending notifications on every dashboard refresh, until someone manually closes it or a stale-bot cleans it up.

Each one of those dead PRs looks exactly like a live failure in your alert channel. Same red badge. Same notification format. Same visual weight. Your team has no way to distinguish between "bot PR that failed on a semicolon and will never be fixed" and "someone pushed a migration that broke staging" without clicking through and reading the logs every single time.

At six to twelve false alarms per day, people stop clicking.

Fixing the channel, not the people

The team lead's first instinct was to tell everyone to pay better attention to CI alerts. That lasted about two days before the noise overwhelmed them again. You cannot solve a signal-to-noise problem by asking people to tolerate more noise.

What actually worked was reducing the noise.

She set up auto-close for any PR labeled ai-generated that failed CI and showed no commit activity for 48 hours. This removed the longest-lingering false positives from the queue. Dead PRs stopped accumulating.

Then she split the notification rules. Bot PRs got routed to a separate channel, #ci-bot, that nobody was required to monitor. Human PRs stayed in #ci-alerts. The main channel went from twelve notifications per day back to two or three. All real.

The team's median response time to CI failures dropped from 3 hours back to about 18 minutes within the first week. Not quite back to the original 12, but close. The senior engineer who pushed the database migration would have had someone looking at it within 20 minutes instead of five hours.

Total setup time for the split and the auto-close: about three hours. The alternative was a team that had been functionally trained to ignore their own build system.