othmanosx

6 ms·

1.
/pyor:review – Claude skill for human code review(github.com)
1 points by othmanosx 2h ago|0 comments
2.
by othmanosx 6d 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 firs
3.
by othmanosx 6d ago
No longer putting in the effort to make themselves distinct from the competition, or make anything different for that matter
4.
Apple is no longer thinking different
35 points by othmanosx 6d ago|42 comments
5.
by othmanosx 9d ago
I’ve been in your same situation for a long time now and I’ve been building a platform to help myself navigate through so many PRs, and doing all of this on github wasn’t sustainable, you could try it out and see if it helps your situation.
6.
by othmanosx 12d ago
I'm building https://pyor.review to fix this problem, try it out and let me know what you think.
7.
by othmanosx 12d ago
humans are still better at coding, AI is just faster and cheaper, not better. the cheap code is still cheap, and we need real engineers to review it still to convert it to high quality code.
8.
by othmanosx 14d ago
I was waiting for the punch line
9.
by othmanosx 14d ago
I don't disagree with you on this, I worked my whole life in corporate and haven't worked as a OSS maintainer before, though I will _and already did_ reject PRs way less than that, I speak for myself and my team here and it's
10.
by othmanosx 14d ago
Yeah, same here, but I do not pay that much attention to the PR description since it's all written by the same AI, it just narrates its own code. I prefer to skim it then jump to the code. The problem thesis is already in the ticket, s
11.
by othmanosx 16d ago
Curious to know, do you read the code first or the summary? How much value do you think AI generated summaries are adding to the review process?
12.
by othmanosx 17d ago
If you're maintaining OSS, that's understandable, and you're free to say no, but in the corporate world, that's not realistic, AI is here to stay, if they don't harness it they would just be left behind. even if the
13.
by othmanosx 17d ago
Interesting, I built https://pyor.review to fix this exact issue, though it uses AI to categorize the files and groups them by complexity to speed up the review process because most AI generated code is noise, especially migrati
14.
by othmanosx 17d ago
Give https://pyor.review a shot if you’re struggling with PR reviews on github.
15.
by othmanosx 18d ago
Have you tried https://pyor.review ? It’s not an editor in that sense but a tool optimized for reviewing PRs produced by AI.
16.
by othmanosx 19d ago
Tests are also a good mechanical and deterministic guardrails, but they're written by the same AI that wrote the code then what's the difference?
17.
by othmanosx 19d ago
I've recently did a huge migration in the company, migrating the UI library three major versions, which introduced a ton of breaking changes and noise. the migration is self was relativley easy to do with AI, a task that would've
18.
by othmanosx 20d ago
You should be the one building the gates then, but those gates should be mechanical and deterministic so the AI doesn’t wprk around them. Lint rules, type errors, commit lint, anything that tells the AI to stop instead of allowing workarou
19.
by othmanosx 20d ago
Reviewing the code is that hard part, but what makes it stressful is 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 stressfu
20.
by othmanosx 21d ago
Have you tried reviewing code on https://pyor.review instead of checking out the code locally?
21.
by othmanosx 22d ago
Me and my team use https://pyor.review instead of github, which I built myself, it’s a far better alternative and fixes our exact pain points
22.
by othmanosx 22d ago
On the review part, we all know that github could be part of the problem, did you use other solutions for reviewing code like graphite or pyor.review?
23.
by othmanosx 24d ago
I felt that too, but instead of quitting, I made my own UI to make reviewing code easier. Github sucks, I now review code on pyor.review which made it 10X eqsier to read the code myself.
24.
by othmanosx 25d ago
Give pyor.review a try, should help with the human bottleneck
25.
by othmanosx 26d ago
Looks cool, seems this is a common problem, I built my own version too (pyor.review) but that started as a better PR reviewer compared to github, which quickly grew to a local PR reviewer too that let's me communicate with the AI sessi
26.
by othmanosx 26d ago
I use pyor.review
27.
by othmanosx 27d ago
Merging blindly is bad for you as the owner of the code, LLMs are not that good yet, we’re still finding it make mistales and write slop and our responsibility as engineers is to take ownership and verify it. The AI reviewers just make this
28.
by othmanosx 29d ago
I use https://pyor.review/ (that i built myself) to manage my PRs and stay on top of them, it also helps my team review PRs faster so we don't see them piling up.
29.
by othmanosx 1mo ago
I know reviewing code on github sucks, which was my source of frustration when reviewing code at work. Please use pyor.review, it will make reviewing PRs a heck of a lot easier (i built it myself) even though I use the latest and greatest m
30.
by othmanosx 1mo ago
absolutley agree, but better understanding needs a better review surface that syncs with Github, which is why I created pyor.review, It's a blast compared to how I used to review code on Github and now I use it everyday.

More ›