We’ve been building our own Review Pipeline, including automated review guides, risk detection and much more.
There’s SO much to be done around Code Review, I’m very surprised GitHub isn’t doing more.
They have the reach already, they have years of real review data. And yet, the PR itself is not using any of the newly available methods for more efficient review.
Agents are hammering PRs out left and right, and yet here I am still staring at the raw diff of 35 PRs and end up being called the bottleneck.
Working on autonomous development with agents and no human code review. The future is human oversight, without humans in the loop. A PR centric cycle is like being in a factory and standing next to a conveyor belt of PRs. Humans can't possibly review properly. They have to take a few steps back and start looking at the entire machine, evaluating the system as a whole.
Code review is a problem only because it is a backstop for everything else. We skip architecture review, we skip prototyping, we one-shot a result in isolation from our team and then expect a human at the end of the line to do our job for us??
Code review is great if the code isn't a surprise, the architecture was already agreed on, the AI reviewers are already happy, and you just need a final pass.
Code review was already terrible before AI if you were slopping down weeks of work on a poor teammate to sift through.
I tell the younger engineers at my company the same thing today I said 5 and 10 years ago. Make the review easy for another engineer to do it, and they'll do it. Make it hard on them, and you won't ship shit.
I wish they would instead focus on fixing the regressions with PRs first...
For example: There is a nasty bug that got introduced recently where you click "Merge when ready" but your chances of things actually going to the merge queue seem to be only at about 60-70%. When it happens the way you usually find out if things still aren't merged the next day.
Their support has acknowledged the issue to us over a month ago but no fix as of now.
Same. What’s even worse is that there is no visibility into it.
Became so bad for us that we switched to an external merge queue provider (trunk.io, not affiliated)
P90 of merge queue entry _started_ dropped from up to 40! minutes to 16 seconds. And it’s the same underlying mechanism, creating a branch and running CI on it.
Just the other day my teammate approved my PR and despite the repo having that merge when ready feature enabled, it kept not working and throwing some random error.
IIRC we unapproved it, approved without that enabled, and then manually merged it.
Their workflow scheduler is broken too. I noticed that workflows were getting scheduled hours late or not at all, so I had my own workflow orchestrator trigger them.
The fact Github published this while another team is off not doing your pet feature is likely a side effect of the company having more than one employee and of those employees having different tasks they're currently working on
Companies are generally not monolithic and are made up of more than one person who often don't communicate with one another and often don't do the exact things you'd like them to.
This has been a fact for quite some time, but it seemed like you might benefit from an explanation. Hope you're not having too bad of a week as a result of your fix not landing fast enough.
I tried it this morning, I guess it's for business rather than open source? The first PR I opened was slop that violated the project's policies. The new UI is missing both report and block.
There's not really any improvement to the core problem with PRs. You still have to read up and down the entire comments tab and then again the entire diff tab (hunting and clicking each "load more" and re-opening every "resolved" thread to find invisible replies) to reconstruct the timeline of what's happened in your head because nothing's in temporal order and there's still no interdiff.
NGL, I know GH gets a lot of shit about the stability, that's well deserved, but they've been really doing nice UI improvements recently. Hopefully this is a new trend that will also continue with the stability.
> As people need to review more and more pull requests, time spent scrolling adds up
I can’t believe people would write this as the justification. You can press PgDn on your keyboard a few times or just End once to go to the bottom. If you are on a MacBook and your keyboard doesn’t have these keys, press Fn-Down instead of PgDn and Fn-Right instead of End. I have never once found that scrolling takes too much time.
Shovel manufacturer responds to complaints about customers throwing piles of manure in neighbors’ yards: “We’re trialing a free window cleaning service to help you get a clearer view of the manure”
These were not really my beef with the PR review page. My beef is that the first round of PR comments becomes unmoored from ground truth after any subsequent commits, making it difficult to see whether comments were addressed, and how.
Can you fix the inbox first please before reinventing more UI? The inbox is utterly broken and slow. It frequently says my PRs are waiting for review when they’ve already been approved.
There’s SO much to be done around Code Review, I’m very surprised GitHub isn’t doing more.
They have the reach already, they have years of real review data. And yet, the PR itself is not using any of the newly available methods for more efficient review.
Agents are hammering PRs out left and right, and yet here I am still staring at the raw diff of 35 PRs and end up being called the bottleneck.
Working on autonomous development with agents and no human code review. The future is human oversight, without humans in the loop. A PR centric cycle is like being in a factory and standing next to a conveyor belt of PRs. Humans can't possibly review properly. They have to take a few steps back and start looking at the entire machine, evaluating the system as a whole.
https://github.com/pullboard-dev/pullboard
Code review is great if the code isn't a surprise, the architecture was already agreed on, the AI reviewers are already happy, and you just need a final pass.
Code review was already terrible before AI if you were slopping down weeks of work on a poor teammate to sift through.
I tell the younger engineers at my company the same thing today I said 5 and 10 years ago. Make the review easy for another engineer to do it, and they'll do it. Make it hard on them, and you won't ship shit.
Their support has acknowledged the issue to us over a month ago but no fix as of now.
Became so bad for us that we switched to an external merge queue provider (trunk.io, not affiliated)
P90 of merge queue entry _started_ dropped from up to 40! minutes to 16 seconds. And it’s the same underlying mechanism, creating a branch and running CI on it.
IIRC we unapproved it, approved without that enabled, and then manually merged it.
Companies are generally not monolithic and are made up of more than one person who often don't communicate with one another and often don't do the exact things you'd like them to.
This has been a fact for quite some time, but it seemed like you might benefit from an explanation. Hope you're not having too bad of a week as a result of your fix not landing fast enough.
There's not really any improvement to the core problem with PRs. You still have to read up and down the entire comments tab and then again the entire diff tab (hunting and clicking each "load more" and re-opening every "resolved" thread to find invisible replies) to reconstruct the timeline of what's happened in your head because nothing's in temporal order and there's still no interdiff.
I can’t believe people would write this as the justification. You can press PgDn on your keyboard a few times or just End once to go to the bottom. If you are on a MacBook and your keyboard doesn’t have these keys, press Fn-Down instead of PgDn and Fn-Right instead of End. I have never once found that scrolling takes too much time.
Ugh