Hacker News Reader

othmanosxon OpenAI to acquire Pierre Computer Company

Try https://pyor.review if your only complaint is GitHub’s UI

othmanosxon I will no longer upload to NEW

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.

othmanosxon I will no longer upload to NEW

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

othmanosxon Show HN: A little tool to review and understand PRs more easily

Been trying that myself, but my goal is a better overall review surface compared to GitHub https://pyor.review

othmanosxon We should be more ambitious with the software we build

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.

othmanosxon Ask HN: If the models are so good, why doesn't OpenAI just start 100 companies?

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.

othmanosxon Ask HN: How to speed up code-reviews?

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.

othmanosxon Ask HN: How to deal with just being a PR reviewer for LLMs nowadays

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.

othmanosxon Ask HN: How do you review code nowadays?

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.

othmanosxon 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.

othmanosxon Rendering pull requests in the GitHub Copilot app

you might wanna try viewing PRs on https://pyor.review/

othmanosxon 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

othmanosxon 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

othmanosxon 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.

othmanosxon 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

othmanosxon 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

othmanosxon 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

othmanosxon 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.

othmanosxon 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.

othmanosxon Fine, I'll build my own text editor

I was waiting for the punch line

othmanosxon 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?

othmanosxon 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.

othmanosxon 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?

othmanosxon 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.

othmanosxon 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

othmanosxon Debian votes to allow "responsible use of generative AI"

Give https://pyor.review a shot if you’re struggling with PR reviews on github.

othmanosxon 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.

othmanosxon 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?

othmanosxon 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.

othmanosxon 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.