othmanosx
Joined 1 year ago
Karma
44
Submissions
128
Member since
Feb 16
Software Engineer
View on Hacker NewsRecent submissions
Comment · 4 days ago
I’m having issues with agents not applying the rules to begin with, during both implementing and reviewing, it just reads the rules and choses to ignore them sometimes, adding more rules just makes this more likely to happen, and having review cycles can potentially get to a state where two agents talk nonstop and increase the slop I need to read instead of reducing it.
Comment · 4 days ago
What about after the bot reviews, did you come up with any solutions to speed that up?
I’m talking about the human part of the review
Comment · 4 days ago
Been trying that myself, but my goal is a better overall review surface compared to GitHub
https://pyor.review
Comment · 5 days ago
I abandoned reviewing code in VSCode a long time ago, I rarely use it now, I do like reviewing code in github but always hated how slow and outdated it is, but I built my own tool to replace it (pyor.review), try it out and let me know if you find it useful, I see that we kinda share the same pain around outdated code review tooling, hope it helps.
Comment · 7 days ago
Same here, I abandoned reviewing code in VSCode a long time ago, I rarely use it now, I do like reviewing code in github but always hated how slow and outdated it is, but I built my own solution to replace it (pyor.review), try it out and let me know if you find it useful, I see that we kinda share the same review process, hope it helps.
Comment · 13 days ago
You can’t make humans read faster, in order to speed up review time, you need to write less.
AI is very good at writing a ton of overly complex code so the you gotta babysit it sometimes to get a lean code.
On the other hand, reviewing the code needs a better surface. It’s still the hard part, but what kills me is that GitHub is still expecting us to review PRs the same way, and it’s increasingly stressful due to GitHub’s poor support for a good PR review experience, I ended up building my own solution (https://pyor.review) to make reviewing the code a lot less tedious and closer to how I want to look at code.
One of the features that actually makes me read less code confidently is that it highlights the moved code, so in a large refactor PR, i can skip reviewing the parts of the code that just moved without change, it also takes AI-assisted review differently as it groups files depending on importance and flags noise, so it’s not adding more walls of text for me to read.
I found this to be the only way to move faster.
Comment · 16 days ago
I can't do much about the amount of text I gotta read, I do have a line in my claude.md file to ask Claude to keep telling me about stuff that I missed or haven't responded to yet so I make sure I haven't missed any important stuff, and it's usually at the bottom of every response, Claude does talk a lot, (codex tends to be better at communicating) but what I found a bit helpful is the unslop skill by pstack, it can help your claude talk in a more read-friendly way.
https://github.com/cursor/plugins/blob/main/pstack/skills/un...
when it comes to reading the diffs, I created my own app to review the diffs away from github, manage my PRs and do everything I could on github without relying on it's broken UI https://pyor.review
You could also just ask Claude to help you go through stuff bit by bit, you'll slowly build the skill and adapt to reading Claudish.
Comment · 17 days ago
Reviewing the code is that hard part, yes, but what kills me is that GitHub is still expecting us to review PRs the same way, and it’s increasingly stressful due to GitHub’s poor support for a good PR review experience, I ended up building my own solution (https://pyor.review) to make reviewing the code a lot less tedious and closer to how I want to look at code.
Comment · 1 month ago
It does look pretty cool, whether it makes review easier or faster is still yet to be seen, I usually refrain from tools that advertise helping the review process but end up adding more unnecessary information to read and go through like review summaries, but this could maybe replace the file structure that we sometimes use to judge architecture.
Comment · 1 month ago
you might wanna try viewing PRs on https://pyor.review/
Comment · 1 month ago
Interesting, would be cool if it can work inside a PR where files exist out of the context of the codebase
Comment · 1 month ago
That's the pitch I'm trying to make with https://pyor.review
The only way to scale reviews is by using AI to skip rather than add more walls of text
Comment · 1 month ago
https://pyor.review/
An alternative to GitHub for code review that focuses on making the human PR review experience easier and faster.
Comment · 1 month ago
I think you're right, though you're talking about an old era, where the iPhone was truly revolutionary, but how do you think the Duo is different from the other folds now?
the first iPhone was years ahead of its time, but the first Apple foldable is arguably the exact same (if not inferior) to the competition, with the exception of the good user experience we're used to from Apple