HNHacker News
TopNewBestAskShowJobs

othmanosx

44 karma · joined February 16, 2025

Software Engineer
submissionscomments
othmanosx··on Show HN: LogPhase – See a PR's blast radius as impacted user journeys
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.
othmanosx··on Rendering pull requests in the GitHub Copilot app
you might wanna try viewing PRs on https://pyor.review/
othmanosx··on Show HN: AI Changed How We Write Code. Why Hasn’t Code Review Changed?
Interesting, would be cool if it can work inside a PR where files exist out of the context of the codebase
othmanosx··on Maybe we shouldn't be reviewing all this code
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

othmanosx··on Ask HN: What are you working on? (September 2026)
https://pyor.review/

An alternative to GitHub for code review that focuses on making the human PR review experience easier and faster.

othmanosx··on Apple is no longer thinking different
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

othmanosx··on Apple is no longer thinking different
No longer putting in the effort to make themselves distinct from the competition, or make anything different for that matter
othmanosx··on NetBSD 9.5 released and EOL for NetBSD-9
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. https://pyor.review
othmanosx··on The asteroid currently hitting front end web development
I'm building https://pyor.review to fix this problem, try it out and let me know what you think.
othmanosx··on Ask HN: Code review of AI output, review what?
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.
othmanosx··on Fine, I'll build my own text editor
I was waiting for the punch line
othmanosx··on Debian votes to allow "responsible use of generative AI"
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 unrealistic to ship a single PR as complex as this, we usually plan features as tech designs with PRs of no more than 500 LOC, but that doesn't mean we could never have a 20k PR at all. in my experience, those huge PRs are usually the simple ones where most of it is just noise. I did one recently and moved the UI library in one of our old codebases three major versions up to the very latest, although it was 20k lines of changes, all of it is just mechanical chanes, renames, codemod stuff, test fixes, snapshot updates, ...etc. and it's not realistc to split this into multiple smaller PRs as this can bring other complications like having multiple versions of the same UI library in the codebase, which could cause more problems than it fixes, AI helps with that kinda work a lot and I would've never been able to do this migration is such a short time without it. despite that, reviewing it was a UI challenge, not code, with UI libraries, the breaking changes are usually in the UI so you can't see it from the code, and we did have a special process to review it, although on the code side, Github was a nightmare to deal with reviewing this PR, we noticed that github was the bottleneck here since it lays out the code changes without much context and is already hard to navigate and stuggles with huge PRs, the review surface and the developer experince on github was horrible, and that's why I suggested you look for better alternatives, there are a lot out there and all of them are free for OSS so why not try them?
othmanosx··on Claude Session URL appended to commit messages and PR descriptions by default
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, so we could just reference it in the PR without duplication. The current state and how it's being changed are already the code diff itself under the changes tab, right? Reading it straight makes me question the code better since the AI is usually overconfident in its writing, so I don't focus on it unless I face a hard blocker or constraint that should be mentioned there.

I also do this with my swarm of review agents, asking them to review the code without context, that way, they produce more high-quality feedback that is backed by self-sourcing the context from the codebase instead of relying on the AI-provided PR description that might justify a code change that others might disagree with otherwise. it works well especially with code changes that could miss other parts of the codebase during refactoring or implementing features that touch multiple domains.

othmanosx··on Claude Session URL appended to commit messages and PR descriptions by default
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?
othmanosx··on Debian votes to allow "responsible use of generative AI"
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 AI gets good and stops writing sloppy stuff, it's still gonna write a lot of stuff, and you're gonna review it anyway, and take responsibility and ownership, and it's still gonna take you more time, because the bottleneck is now reviewing and understanding the code.

I agree that the workflow is broken, but only on the reviewing side, AI is a tool we use to make products just like any other we used in the past, punch cards, machine code, assembly, ...etc. AI is just the new tool that sits on top of the code as the next level, no one codes with punch cards, no one writes machine code anymore, we used to write the compiled language and don't care about how it's compiled or turned into machine code, same with AI, although it's not there yet and still requires babysitting by engineers, but that's our new job now, and we need to learn how to use it and make our lifes easier.

othmanosx··on Sloc Cloc and Code 4.0 (scc) – Finding the files that need the most attention
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 migration PRs. Curious to know if this could be done in a deterministic way without the help of AI
othmanosx··on Debian votes to allow "responsible use of generative AI"
Give https://pyor.review a shot if you’re struggling with PR reviews on github.
othmanosx··on Our decision on Cursor following its acquisition by SpaceX
Have you tried https://pyor.review ?

It’s not an editor in that sense but a tool optimized for reviewing PRs produced by AI.

othmanosx··on It’s so hard to finish an idea that is not yours and is just suggested by AI
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?
othmanosx··on We need to talk about migrations with AI
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 taken men months, done in a couple weeks.

the not so good part about such migrations is that the resulting PR is huge, it does contain some important parts but most of it was noise and prop renames and mechanical changes. the problem is that Github wasn't really helpful with the review proccess, it doesn't provide a good experience for reviewing large PRs (it would sometimes just crash) so it got very stressful to review and keep track of the feedback comments from my teammates and followups

later after that, I gathered the pain points we faced during our review proccess and built a platform optimized for reviewing AI PRs (https://pyor.review). firstly it's a web app and has a desktop app, so it's way more performant when reviewing large PRs, it also include a comment inbox to keep track of feedback, has grouping mechanism so reviewing migration PRs becomes a ton less stressful compared to github, surfacing important files first to review then grouping the noise for easy quick skimming, and it makes use of caching so the content loads faster. There's a ton of other small features it adds that just elevates the experience of code review and we no longer review code on github.

othmanosx··on It’s so hard to finish an idea that is not yours and is just suggested by AI
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 workarounds.
othmanosx··on Tell HN: Man, AI is killing my brain
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 stressful.
othmanosx··on Ask HN: How do you code review?
Have you tried reviewing code on https://pyor.review instead of checking out the code locally?
othmanosx··on Ask HN: What tools are you using for human code review of AI-assisted code?
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
othmanosx··on Coding expertise is going to collapse from AI reliance
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?
othmanosx··on Building an (almost) fully self-hosted, sandboxed, agentic software factory
Give pyor.review a try, should help with the human bottleneck
othmanosx··on Show HN: Diffview, a fast Git diff viewer written in Rust
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 session directly to review the files as I move before opening a PR.

mine is web based, not rust, and I built it with @pierre/diffs for rendering the diffs, which does provide a ton of the features I already needed.

I actually tried to build it as a native mac app first but that didn't go well as I couldn't find good libraries for what I was trying to build, so I scratched that and went to a full web app plus an electron unversal app.

Will definitely check it out

othmanosx··on Ask HN: How do you review and validate LLM generated code?
I use pyor.review
othmanosx··on Does anyone find AI code review useful?
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 easier for us, I’m not talking about the walls of text it adds as it is exhausting to read (I know) but the fact that it could catch real bugs before you even read the actual code is the benefit, and I’ve integrated this flow into my routine, a loop of a coder and a reviewer taking turns before handing me the results to read myself.

The more I find stuff, the more I improve my own code review skill. And I actually created my initial skill by distilling the code reviews and comments I made myself on github for the past 2 years, training an AI on how I review and give feedback on PRs, that produced a skill that is like another copy of me reviewing the code and refining the code before I read it myself.

othmanosx··on Ask HN: When code review starts backing up on your team, what happens?
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.
Page 1 of 3Next →