5 karma · joined April 7, 2022
Everyone's focused on AI writing code. But the shift to AI reviewing code moved faster - 1 in 7 active PRs now have an AI reviewer, up from 1 in 100 eighteen months ago.
A few things that surprised us:
- Copilot overtook CodeRabbit in November despite CodeRabbit being purpose-built for review - native GitHub integration matters more than we expected
- Gemini went from near-zero to #3 in 10 months (43X growth). Google isn't marketing this aggressively yet
- AI agents authored 99K PRs but participated in 5.9M -automation is still heavily weighted toward review, not generation
- Some early entrants like Korbit have already shut down
Data is GitHub Archive + our anonymized corpus. Happy to answer questions on classification or edge cases.
We analyzed ~40 million public GitHub pull requests from 2022–2025 to understand how AI agents show up in real-world code review.
In 2025, AI agents are involved in roughly 14% of pull requests, either as reviewers, commenters, or authors.
A few patterns stood out. CodeRabbit accounts for the largest share of AI review volume, touching the most PRs overall, while GitHub Copilot shows the broadest adoption across organizations. Most AI participation still happens during review rather than full PR authorship, suggesting a shift in how review attention is allocated rather than end-to-end automation.
We focused on observable PR activity rather than vendor-reported metrics, excluded non-LLM automation, and were conservative about bot classification. There are limitations, especially around private repositories and self-hosted tools, which we call out explicitly.
So while it’s true that many browsers today are Chromium derivatives, Safari and Firefox are not — they operate their own engines and could, in theory, push independent privacy standards without Google’s blessing.
Also important to note: Because Apple requires all iOS browsers to use WebKit under the hood (even "Chrome" and "Firefox" on iPhone), any browser-native privacy feature Apple implements through WebKit would effectively apply to all browsers on iPhones and iPads by default.
That’s a much bigger user base impact than just Safari desktop users.
That said, you’re absolutely right about the broader market power problem: - Chrome controls ~65% of browser usage worldwide. - Many web developers treat Chrome as the de facto standard when building sites. - Anything Safari or Firefox introduce has a harder uphill climb unless it becomes incredibly popular with users and gets picked up by regulators.
The fight here isn’t just technical — it’s economic and cultural too.
Still, I think it’s worth trying. Even small pressure can move norms over time, especially with user frustration around tracking being so high right now.
Appreciate you raising it — it’s a critical part of the puzzle.
The frustrating part is that so much of modern web infrastructure (ad networks, analytics, personalization layers) depends on quietly hoovering up far more than the feature strictly requires.
I sometimes wonder: if browsers enforced "functional data collection only" as a technical baseline — like enforcing CORS or CSP today — how much of the tracking economy would collapse overnight?
Curious if you think real technical enforcement (browser-level) is the way forward, or if we’re stuck waiting for another round of slow, partial regulation.
It’s fascinating (and honestly a little tragic) that a lot of the cookie chaos comes down to basic unsolved problems like "how do you remember privacy without remembering identity?" — fundamental contradictions nobody could easily patch.
It really hits home what you said about the EU approach: case-by-case "squishy" regulation vs hard-coded universal rules.
Makes me wonder if any browser-led technical solution would just end up becoming de facto case law too — basically "Chrome/Firefox/Brave do it this way, so it becomes the norm," even if regulators never mandate it formally.
If you had a magic wand: would you push for a formal browser-level privacy protocol now, or is the better play just to keep tightening enforcement against the worst actors and let good practices spread organically?
I also completely agree that "cookie" should be interpreted broadly — not just literal HTTP cookies, but any client-side tracking (localStorage, IndexedDB, fingerprinting, etc).
If enforcement actually happened at the storage and tracking level, and browsers had native consent handling, the entire dynamic between users and websites would shift dramatically.
Curious — in your view, would it be better for the EU (or regulators) to issue a technical specification for how consent enforcement should work? Or just mandate the outcome and leave it to browser vendors to figure out? (Feels like that choice matters a lot for real adoption.)
It's wild how much of today’s cookie UX mess was an accidental regulatory artifact, not deliberate design.
Curious from your perspective: what do you think the EU's real motivation was behind mandating consent banners instead of pushing for proper browser-level control?
And second: what kind of pressure (technical, political, economic) would it actually take for the EU to update the rules to allow something cleaner now?
Would love to hear your take, since it sounds like you've seen how these decisions happen from inside.
Are there real technical blockers to browser-native consent management?
* HTTP already has Set-Cookie, so tagging with a Category param seems straightforward.
* Browsers already manage permissions like location, camera, and notifications.
* GDPR/CCPA compliance should be stronger if browsers enforced consent upstream.
Is the real obstacle purely political (ad-tech resistance), or is there something deeper I'm missing on the protocol or standards side?
Also curious: if browsers did offer this, would major sites still try to layer their own consent dialogs on top (to push opt-ins harder)? How would we stop that?