44 karma · joined February 16, 2025
Having feedback when clicked, feedback when hovered. A loading state, a disabled state, a mix of everything. That's also something I found very frustrating. Like if you take the example of a button that is tied to a service on the back end, clicking this button without any visual feedback doesn't tell you if that button was clicked or not. And if it doesn't have a loading state, you wouldn't know that. something is working behind the scene when you click this button so you would click at multiple times not knowing that it's still working behind the scenes.
1. Start an AI review on the side while I do my own review.
2. Test the app myself, note any bugs or visual issues.
3. Review the code on www.pyor.review, compared to Github, Pyor allows me to categorize the files and changes then review the important stuff and skim the noise Pyor identifies.
4. leave comments on the on the code, and go back and forth with the author until everything is addressed.
5. approve.
When it comes to my own PRs, I usually assign specific team members to specific PRs depending on who is best to review the part of code I'm editing, which moves the review faster
1. Start a session.
2. Grill my requirements.
3. Write an ADR, then either start implementing or separate into pieces.
4. Review the code on pyor.review, compared to Github, Pyor allows me to categorize the files and changes then review the important stuff and skim the noise it identifies.
5. Since I can do local reviews with Pyor, I can do that with Claude and feed back my comments to be addressed without it going to Github first.
6. Create a PR then merge it.
I believe AI should instead help pointing the dev to the important stuff and help identify noise, this would actually make the review go faster.
since the introduction of AI, the bottleneck for shipping code shifted from producing code to reviewing it, and the PR reviewing experience on Github is lackluster, leaving a lot to be desired.
my team now ships too much code and it sits in review for too long, reviewing AI code is not easy and we need a better tool to review code, especially on large PRs, Github no longer meets my needs or use cases so I had to build something myself.
I got frustrated enough that I built my own reviewer around this idea: instead of adding commentary, it groups files into folders by complexity, surfaces the handful of changes that actually need deep review, and marks the mechanical noise so you can blow through it. On migration PRs it cut my review time down a lot.
With AI shipping code quickly we got to some of the long awaited migration work that we wanted to do long ago. And now we're pushing PRs with 10K and 20K lines of code. And that actually helped speed up the review process immensely. Instead of AI adding a new summary article, it just helped me to identify the noise and the repeated patterns. In these migration PRs and skim them quickly, then focus on the important parts of the migration that need a closer look. Since all these files are grouped now, I can just toggle a whole folder as viewed so I can focus on leaving comments on the other files and addressing them while not affecting the parts that are already viewed in the PR. That also made the feedback loop more efficient.
I can share more if people are curious, I'd rather not turn this into an ad.
bug fixes are supposed to be small, contained, if they're rearchitecting the codebase, then they're not _bugs_, but tech improvements, and need to be addressed differently and I agree that this should be flagged in the PR.
a PR review is the final defence line before a QA
The problem with AI reviews, is that they add a lot more text to read, the PR description is another wall of text, test steps are very verbose, most comments are just noise.
I believe AI should instead help pointing the dev to the important stuff and help identify noise, this would actually make the review go faster.
since the introduction of AI, the bottleneck for shipping code shifted from producing code to reviewing it, and the PR reviewing experience on Github is lackluster, leaving a lot to be desired.
my team now ships too much code and it sits in review for too long, reviewing AI code is not easy and we need a better tool to review code, especially on large PRs, Github no longer meets my needs or use cases so I had to build something myself.
I got frustrated enough that I built my own reviewer around this idea: instead of adding commentary, it groups files into folders by complexity, surfaces the handful of changes that actually need deep review, and marks the mechanical noise so you can blow through it. On migration PRs it cut my review time down a lot.
With AI shipping code quickly we got to some of the long awaited migration work that we wanted to do long ago. And now we're pushing PRs with 10K and 20K lines of code. And that actually helped speed up the review process immensely. Instead of AI adding a new summary article, it just helped me to identify the noise and the repeated patterns. In these migration PRs and skim them quickly, then focus on the important parts of the migration that need a closer look. Since all these files are grouped now, I can just toggle a whole folder as viewed so I can focus on leaving comments on the other files and addressing them while not affecting the parts that are already viewed in the PR. That also made the feedback loop more efficient.
I can share more if people are curious, I'd rather not turn this into an ad.
I think AI should complement the human review, not replace it, and I think everyone already agrees with me on this.
The problem with AI reviews, is that they add a lot more text to read, the PR description is another wall of text, test steps are very verbose, most comments are just noise.
I believe AI should instead help pointing the dev to the important stuff and help identify noise, this would actually make the review go faster.
since the introduction of AI, the bottleneck for shipping code shifted from producing code to reviewing it, and the PR reviewing experience on Github is lackluster, leaving a lot to be desired.
my team now ships too much code and it sits in review for too long, reviewing AI code is not easy and we need a better tool to review code, especially on large PRs, Github no longer meets my needs or use cases so I had to build something myself.
I got frustrated enough that I built my own reviewer around this idea: instead of adding commentary, it groups files into folders by complexity, surfaces the handful of changes that actually need deep review, and marks the mechanical noise so you can blow through it. On migration PRs it cut my review time down a lot.
With AI shipping code quickly we got to some of the long awaited migration work that we wanted to do long ago. And now we're pushing PRs with 10K and 20K lines of code. And that actually helped speed up the review process immensely. Instead of AI adding a new summary article, it just helped me to identify the noise and the repeated patterns. In these migration PRs and skim them quickly, then focus on the important parts of the migration that need a closer look. Since all these files are grouped now, I can just toggle a whole folder as viewed so I can focus on leaving comments on the other files and addressing them while not affecting the parts that are already viewed in the PR. That also made the feedback loop more efficient.
I can share more if people are curious, I'd rather not turn this into an ad.
The problem with AI reviews, is that they add a lot more text to read, the PR description is another wall of text, test steps are very verbose, most comments are just noise.
I believe AI should instead help pointing the dev to the important stuff and help identify noise, this would actually make the review go faster.
since the introduction of AI, the bottleneck for shipping code shifted from producing code to reviewing it, and the PR reviewing experience on Github is lackluster, leaving a lot to be desired.
my team now ships too much code and it sits in review for too long, reviewing AI code is not easy and we need a better tool to review code, especially on large PRs, Github no longer meets my needs or use cases so I had to build something myself.
I got frustrated enough that I built my own reviewer around this idea: instead of adding commentary, it groups files into folders by complexity, surfaces the handful of changes that actually need deep review, and marks the mechanical noise so you can blow through it. On migration PRs it cut my review time down a lot.
As a web dev, I know what works and what doesn't, I hated how AI bloats the PR with more text, so I changed that to make the AI help me categorize the files into folders, splitting them by complexity, and pointing me to the important stuff I need to review indepth, and flag the noise so I can skim it faster, that sped up reviewing time immensely, especially on migration PRs where most is mechanical name changes.
I can share more if people are curious, I'd rather not turn this into an ad.
1. Start an AI review.
2. Test the app myself, note any bugs or visual issues.
3. Review the code on www.pyor.review, compared to Github, Pyor allows me to categorize the files and changes then review the important stuff and skim the noise Pyor identifies.
4. leave comments on the on the code, and go back and forth with the author until everything is addressed.
5. approve.
Agentech review raises the floor on how many PRs we can file.But the human review is still the bottleneck here.
I believe that agents can never be the true only one reviewer to stamp a PR with an LGTM stamp. But they can definitely help a human.The human should still be the one who takes responsibility and ownership of the code he ships, but the agent can have the reviewer separating the important stuff from the noise in order to make reviewing code faster and easier. (disclosure: I work on a PR reviewer, Pyor Review, I know the pain well as a web dev so I stare at this a lot.)
That is exactly the problem I'm solving right now. As a software engineer in the AI era, we ship code like crazy. We already move ten times as fast. But the bottleneck is still there. In the past, the bottleneck was actually writing the code because it was the most expensive and slow part of development, but now the slowest part is actually reviewing the code. And pretty much all the solutions I've come across do AI reviews or add AI summaries or add a wall of text to each pull request, which makes the review harder and longer instead of easier and faster.
You still have to read the code anyways. even if the AI reviews the code, the output is still on you. AI is just shifting the bottleneck.
The way I'm approaching this problem is to use AI to reduce the stuff we have to review instead of increasing it. The AI is not that good at dissecting very complex code or architecting better solutions, but it's good at identifying noise or things that are safe to merge. So we could use the AI to handle all the noise and keep the important stuff that we need a human review for. GitHub is no longer a good place for reviewing PRs nowadays.
why is Fable still banned?