GitHub shipped a redesigned pull request dashboard this week. Inbox, saved views, smarter filters, keyboard shortcuts. The author filter now even recognizes agent-created PRs, so author:@me returns the work you told Copilot to open on your behalf.
It’s a good dashboard. It’s also an admission.
The framing is right there in the headline. The review bottleneck is a thing AI created, and GitHub built a triage surface to manage it. The numbers back this up. Faros AI found teams with heavy AI adoption merged 98% more PRs, but review time rose 91% and PR size grew 154%. LinearB looked at 8.1 million PRs and found developers feel 20% faster while end-to-end cycle time is actually 19% slower once you count the review queue.
So the story is clean. AI made code generation cheap. Review is now the constraint. Build a better inbox.
Here is where I disagree with the conclusion.
A quick word on what we do, because it shapes how I read this. I spend my days inside exactly this problem. Multiple PR queues that nobody agreed to create. Security findings sitting in their own lane with no owner. Fix PRs orphaned in repos because the person who could act on them moved on a week ago. I am not reading the GitHub announcement as a spectator. I am reading it as someone who has watched these queues form, watched them rot, and watched teams try to tool their way out of a problem that tooling made worse. So when I say a better sorting does not fix this, it is not a hot take. It is what the last year looks like from where I stand.
A dashboard sorts the queue. It does not shorten it.
The DevOps piece says this itself, near the end. If a team generates PRs faster than it can review them, a better inbox makes the queue easier to see. It does not make it shorter. That is the honest part of the article, and it gets one sentence.
I want to spend the whole post on that sentence.
Better triage is a treatment for the symptom. And to be clear about what the symptom is not: the volume of AI-generated code is not the disease. That volume is the point. We want teams shipping more, faster, with AI carrying the load. The goal is a smarter way to get through that work, not less of it.
The disease is what we pile on top of that volume. Every time AI generates code and then we route the security cleanup into a human queue as its own separate work, we take a volume we wanted and turn it into a backlog we didn’t. Nobody fixes that by improving the sort order. You fix it by not letting AI-generated code create a second stream of AI-generated cleanup in the first place.
Now watch what happens when security gets its own lane.
Here is the move a lot of teams are about to make, and it is the wrong one.
AI floods the PR queue. Security scanning is loud and getting louder because agents write more code, faster, with more surface area. So someone decides security findings shouldn’t clog the normal review flow. Route them to their own queue. Their own dashboard. Their own triage.
Feels clean. It is a disaster.
You just took one overloaded queue and made two. The security queue has all the same problems as the PR inbox, plus three new ones.
The separate queue breaks in three ways
It is decoupled from the code that caused it. The developer who wrote the vulnerable line has moved on to the next ticket by the time the finding lands. Context is gone. Now someone has to rebuild it.
It has no natural owner. Team review requests already rot because everyone assumes someone else will grab them. A separate security queue is that failure mode by design. It is a shared backlog nobody wakes up owning. This is not a hypothetical. The data on machine-generated fix PRs is brutal: bot-authored PRs get accepted at roughly 37 percent versus 73 percent for human-authored ones, and Dependabot security PRs in JavaScript projects see just 13 percent adoption. Route security into its own lane and most of it does not get merged. It gets ignored.
And the fix, if it lands, might make things worse
It arrives after the merge. The code is in main. The fix is now a new PR, which is a new item in the very queue you were trying to unclog. You did not remove work. You created a second copy of it and put it in a slower lane.
And the fix itself is not guaranteed to help. A 2026 analysis of more than 33,000 AI-generated pull requests found that security-related PRs from AI agents sometimes introduce new vulnerabilities instead of closing the ones they targeted, with recurring weaknesses like injection flaws and path traversal showing up in the “fixes.” So the trailing security queue is not just slow and unowned. It is full of changes that need the most careful review of anything in your pipeline, sitting in the lane least equipped to give it. You deferred the work and raised the stakes at the same time.
Separating security from the normal PR is not triage. It is deferral with extra steps. You compound the queue you claimed to be fixing.
“But my scanner opens PRs in the right repo” is not the same thing.
Here is the objection, and it is the one every tool vendor reaches for. Fine, don’t use a separate queue. My scanner is smart. It opens fix PRs into the right repository, at the right time, assigned to the right developer. In context. Problem solved.
It is not solved. A PR in the right place is still an interrupt.
The developer who gets that PR has moved on. They are three tickets deep into something else. Now a fix PR lands, and to act on it they have to stop, reload a mental model of code they wrote last week, re-derive why it looks the way it does, evaluate a change they did not write, and context-switch back out. The PR is in the right repo. It is nowhere near the developer’s actual flow.
In-repo is a location. In-flow is a moment. Getting the location right does not buy you the moment. The only place the fix is genuinely in context is the branch where the code was still warm and the developer, and the agent, still had the whole thing loaded in their head. Every PR-based approach, no matter how well-routed, has already missed that window by definition. The PR only exists because the moment already passed.
Fix it in the loop, and it never becomes a queue item.
The alternative is to test and fix security problems inside the development loop, before the PR opens, as part of the same change that introduced them.
Here is the actual loop, not a slogan. The agent writing the code runs the scan against the branch. A finding comes back with its location and enough context to act on. The agent patches it in the same branch. Then it re-tests to confirm the fix actually closed the issue and did not just move it. Scan, fix, verify. The finding gets resolved by the actor with the most context, at the cheapest possible moment, before anything reaches a human.
The security finding never becomes a separate artifact. The PR that opens is already clean. The reviewer sees one change, not a change plus a trailing security ticket that shows up three days later with no owner.
This is the part the dashboard story misses. The goal is not to sort security work more cleverly. The goal is for security work to never enter the queue as its own line item.
The math, with real numbers.
We ran this. In three weeks, 28 teams using Wingman fixed 1,190 vulnerabilities across high, medium, and low severity inside the development loop.
Run the counterfactual. In the separate-queue model, that is 1,190 new tickets or MAYBE, best case, 1000. New PRs. New line items in the exact inbox GitHub just redesigned to help you survive. Each one decoupled from its original context, each one waiting on an owner who does not exist.
In the loop, those 1,190 fixes folded into the 2 to 4 PRs that were already going to open for the underlying work. Not 1,190 items. A handful. The security work rode along with the code that caused it and never generated a queue of its own.
That is the whole argument in one comparison. A separate security queue adds items. In-loop remediation removes them. One compounds the bottleneck GitHub built a dashboard to survey. The other shrinks it.
What review is actually for
The DevOps piece nods at this in one line. Some teams pair dashboard triage with tools that catch trivial issues before a human opens the PR, freeing reviewers for the judgment calls only a person should make. Whether an abstraction earns its complexity. Whether defensive code will still make sense in six months.
That is exactly right and deserves more than a nod. Here is the point underneath it. Review time is not a security tax. It is where the business value gets made. It is where a senior engineer decides whether the design is right, whether the tradeoff is worth it, whether this code is going to be maintainable a year from now. That is the scarce, expensive, human thing.
Spend reviewer attention on judgment, not cleanup
Every security finding you route to a separate queue spends that attention twice. Once to triage the finding. Once to review the fix PR. And none of that spend goes toward the judgment work review actually exists for. You are burning your most expensive resource on a class of problem a machine should have closed in the branch.
Every finding you resolve in the loop is attention handed back to the work that needs a human. That is the real return. Not fewer vulnerabilities in a dashboard, although that is important. More reviewer attention pointed at the questions only a reviewer can answer.
GitHub built the dashboard because review became the constraint. Fair. But the answer to a queue problem is not a nicer view of the queue, and it is definitely not a second queue with a security label on it. The answer is to stop generating the items, and to protect review for the judgment it is uniquely good at.
Test in the loop. Fix in the loop. Let the clean PR be the only thing that reaches a human, so the human spends their time on the part that was never about security in the first place.
See what your PR queue looks like when security never enters it. Wingman runs the scan-fix-verify loop inside your AI coding agent, so vulnerabilities get fixed in the branch before a PR ever opens. Try Wingman free
