Pulldog Thinks Your PR Inbox Deserves Better Than a Browser Tab Graveyard

The Macro: The Code Review Problem Nobody Talks About Fixing

Here is what a typical senior engineer’s browser looks like on a Tuesday afternoon: seventeen tabs, six of them GitHub pull request pages, two of them the same PR opened twice by accident. Nobody talks about this being a workflow problem. Everyone just lives with it.

The underlying issue is that code review has become load-bearing infrastructure for how software teams ship, and the tooling surface for it is basically a web interface designed in 2012 with incremental updates bolted on. GitHub and GitLab are platforms first and review clients second. That ordering matters.

The broader developer productivity conversation in 2026 is almost entirely about AI-assisted code generation. You can see this in where the money and the attention are going. Tools like Superset, which wants to orchestrate your AI coding agents, or the wave of terminal and IDE enhancements building on top of Claude Code, including one recent tool specifically cleaning up its messy terminal output, are all upstream of the review step. They help you write the code faster. What happens after the PR opens is largely an afterthought.

That gap is real. Code review volume scales with generation speed. If your team is shipping more PRs because AI is helping write more code, the bottleneck moves to the humans doing the reviewing. A faster funnel into a slower drain.

Native desktop clients for developer tools have had a quiet comeback. Git GUI clients like Tower and Fork built real audiences among developers who wanted something that felt like software, not a webpage. The appetite exists. The question is always whether the specific problem being solved is painful enough to justify installing something new.

PR inbox management, I’d argue, is exactly that painful.

The Micro: One Inbox, Smart Filters, No Browser Required

Pulldog is a native macOS application that pulls your GitHub and GitLab pull requests into a single unified inbox. That is the core premise, stated plainly. If you work across multiple accounts or multiple repositories on different platforms, everything shows up in one place instead of scattered across browser sessions.

The product decisions here are interesting. It is built with AppKit and SwiftUI, which means it is doing actual native Mac work, not a web view dressed up in a window frame. The builder posted about this in the AppKit community, which suggests genuine commitment to the platform rather than a quick port.

A few specific features stand out to me. Smart queries let you filter and segment your PR queue, so you can cut through noise and surface what actually needs your attention today. That sounds like a small feature. In practice, if you are triaging thirty open PRs across two organizations, it is the difference between a useful tool and a list you learn to ignore.

Spotlight integration means you can act on PRs without opening the app. Widgets extend that to your desktop or lock screen. These feel like the right instincts for a Mac-native product. Apple Intelligence support is listed as a feature, though what that means functionally in daily use is something I would want to see in practice before getting excited about it.

The no-browser-tabs pitch is honest and specific. That is a better value proposition than the vague productivity language most tools in this space reach for. It did well when it launched, picking up solid traction on its first day.

The honest limitation right now is that there is not much public information about depth of review functionality. Aggregating your inbox is one layer. Whether you can do meaningful review actions, leave comments, request changes, all from within the app, is the next layer, and I do not have a clear answer on how far that goes.

For a category where AI coding agents are generating more PRs than humans can comfortably review, the inbox problem is real. The question is how deep the tool goes.

The Verdict

I think this is a genuinely useful idea built for a real annoyance that engineers accept as ambient background pain. The instinct to make it native, to use Spotlight and widgets, to treat macOS as a first-class platform rather than a deployment target, is the right call.

What makes this work at 30 days is simple: does it actually replace the browser tabs, or does it become another thing you check alongside them. If the in-app review experience is shallow enough that you still end up clicking through to GitHub to leave a comment, the value proposition collapses. The inbox is only as useful as the depth behind it.

At 60 days, retention depends on whether the smart queries are genuinely smarter than what you can cobble together with GitHub’s own filters. If the answer is yes, especially for multi-account or multi-platform users, that is a sticky workflow.

At 90 days, I would want to know if teams are adopting it or if it is staying a solo-developer tool. Team-level workflows, shared query templates, anything that makes PR review a coordinated activity rather than an individual one, would push this into a different category entirely.

Right now it reads as a well-built solution to a specific Mac-user problem. That is not a small thing. I would just want to spend a week with it before calling it a workflow change.