HNHacker News
TopNewBestAskShowJobs

othmanosx

44 karma · joined February 16, 2025

Software Engineer
submissionscomments
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.
othmanosx··on It's time to stop doing code reviews
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 models, I still have to review the code AI generates, and it still makes mistakes, I still find it making weird decisions, slop blocks of code, unnecessarily long solutions that can be replaced with a couple lines of code.

code review is required to build good software, and that what separates engineers from vibe coders. you're missing the "engineer" part from the role, and that's still here to stay.

othmanosx··on Understanding is the new bottleneck
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.
othmanosx··on Stacked PRs are now live on GitHub
I've been using it for a while and I've actually shipped stacked PRs with github. we usually try to chunk the work so that we don't get in a situation were we have to open PRs with more 1k+ LOC, and we try to plan chunks of max 500 LOC, but I do find myself getting in this situation when the planned work turns out to be more than I anticipated like refactoring or edge cases or review feedback... etc. but that's where stacked PRs come in, I found that they could be useful in this situation to split an unexpectedly large PR into a few smaller ones that are chunkable, individually shippable, and easy to review. but that's where the good stuff ends IMO, stacked PRs just make a bad situation slightly better, and I think we shouldn't get into this situation in the first place. I know that can be impossible sometimes, but I already built my own solution for fix this problem.

even though it's good to have, Github's UI doesn't help it, Github already sucks in terms of the review experience in a pull request and the implementation of the stacked PRs leaves a lot to be desired.

thankfully, I was working on my own solution for this problem and I already integrated a better stacked PRs implementation compared to github, and I'm pretty happy with it.

Pyor (pyor.review), I built it myself, sits on top of github, syncs everything with it, and gives me the benefit of having a better UI and code review experience.

othmanosx··on Stacked PRs are now live on GitHub
have you tried pyor.review? it is actually just github but with better UI, and you get a commits rail that makes it easy to switch between commits on the fly
othmanosx··on Reviewing AI Code Is Not a Viable Argument
honestly the review data here matches my experience, review is the constraint, not writing the code. that's the whole reason i spend my time on it.

where i'd push on the conclusion is the 400 lines/hour ceiling, which assumes you're reading an undifferentiated diff top to bottom. most AI PRs aren't uniform, a big chunk is mechanical (renames, boilerplate, repeated patterns) and a small chunk is the actual logic that needs a careful human look. We see more of these PRs now as companies use AI to clean thier tech debt if you can separate those, you're not reviewing 5000 lines at 400/hr, you're carefully reviewing the 300 that matter and skimming the rest. the throughput math changes a lot, and we can actually save time reviewing PRs this way.

the lower-defect-detection-with-higher-confidence point is real though. skimming has to mean skimming known-safe noise, not the risky parts, but that's where AI can help. that's the bet i'm making with what i work on (pyor.review). Using AI to reduce what you review instead of adding to it, not to hand you another summary to read, which I think is the correct approach for using AI for a code review.

othmanosx··on Perfectly Hitting the Wrong Target: The Story of an AI Code Review Benchmark
I review a lot of PRs in my team, the human comprehension half is the part I care about, so limited attention is the problem.

my worry with most AI tools is that they add text and summaries and walls of AI generated descriptions, verbose test steps, and layers or summaries, that makes me read more text instead of less, which takes more time than a normal PR review.

I still have to read the code anyways, so I would prefer something the makes this job easier for me, I would rather use something like graphite or pyor.review instead.

good product nonetheless, good luck.

othmanosx··on Show HN: I Wanted AI Code Review I Could Own. So I Built Codra
Have you looked at pyor.review?
othmanosx··on Ask HN: Is anyone experimenting with different ways of using LLMs for coding?
Have you tried pyor.review for reviewing your PRs?
othmanosx··on Show HN: R3 – A Local Code Review Tool for You and Your AI Agent
Oh man I was looking for something like this for a while, reviewing code in VSCode is starting to get annoying and I began to think that VSCode is no longer suitable for development in the AI era, but I already built my own solution that addresses the two problems I had with reviewing code: - A better alternative to reviewng a PR on github.

- A way for me to do a local review for my code is if was a PR, before actually filing that PR.

I also built a Claude skill around the local review so it's more seamless to integrate with Claude, I also get more powerful features with the help of AI like grouping files in folders and sprinkling hints as squiggly lines that help me with the review.

you can check it out https://pyor.review.

wishing you the best with your project!

othmanosx··on How to build a GitHub code review agent
Building a code review agent is easy, yes, but building a code review tool for humans is not that easy, been working on my own for a while.
othmanosx··on Local codereview tool for handing structured review to agent
Oh man I was looking for something like this for a while, reviewing code in VSCode is starting to get annoying and I began to think that VSCode is no longer suitable for development in the AI era, but I already built my own solution that addresses the two problems I had with reviewing code:

- A better alternative to reviewng a PR on github.

- A way for me to do a local review for my code is if was a PR, before actually filing that PR.

I also built a Claude skill around the local review so it's more seamless to integrate with Claude, I also get more powerful features with the help of AI like grouping files in folders and sprinkling hints as squiggly lines that help me with the review.

you can check it out https://pyor.review.

wishing you the best with your project!

othmanosx··on Making AI Code Review Measurable
>I have always had a love and hate relationship with code review tools

Same here, we're not happy with todays code review tools, and github itself already sucks, we already looked at tools like graphite and stage but they did not serve our needs much. I eventually built my own review tool and I'm pretty happy with it.

othmanosx··on Show HN: Fast, native Mac file manager (filters, fuzzy find, 9 MB, no Electron)
Just add an Up Directory button and you’ll be infinitely better than Finder.
othmanosx··on Local, CPU-Friendly, High-Quality TTS (Text-to-Speech) with Kokoro
Yeah, we need to keep up with how quickly AI types back to us, typing on the keyboards is no longer quick enough, gotta dictate everything now.
othmanosx··on If you're a button, you have one job
Yeah, I thought of this while writing my comment. I hate this actually, in all devices where you want to cut on the number of button there are, like a headphones for examples, having one button that does stop/play/next/prev/reset/whatever... is really annyoing, one button having too many functions is really bad UX IMO. I'd rather have another button to press once rather than holding the first one for 15 seconds to do some other thing
othmanosx··on Show HN: Open-source guided code reviews
Thanks for the review, that's really good feedback. as we slowly read the code less and less, it only makes sense for AI to help us skim it more, until it becomes good enough for us to not read the code at all. still, on the other hand, do you think AI can tell you what a 5 word long function does in 5 words? probably not, so reading the code itself will stay faster than reading the summary, AI can only help alerting you on what it thinks is a potential bug, or same code moving around.
othmanosx··on Show HN: Open-source guided code reviews
I still don't like the fact that AI is adding more stuff for us to read, it's accelerating the code production but slowing down the code review. I built my own code reviewer as well (https://pyor.review/), surfacing the important stuff first is the right track, but adding more stuff to read is daunting, but asking AI to just point you to what you need to focus on and skim the noise is what I'm leaning more towards.
othmanosx··on I'm opening VSCode less and less every day
That's how I code nowadays:

1. Start a session.

2. Grill my requirements (I use Matt Pocock's skills).

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.

othmanosx··on I'm opening VSCode less and less every day
Good question, If you enjoyed coding itself, you'll have a hard time now, but if you enjoy building stuff, you'll thrive in this era.
← PreviousPage 2 of 4Next →