<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: othmanosx</title><link>https://news.ycombinator.com/user?id=othmanosx</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Fri, 04 Sep 2026 09:08:42 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=othmanosx" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by othmanosx in "The asteroid currently hitting front end web development"]]></title><description><![CDATA[
<p>I'm building <a href="https://pyor.review" rel="nofollow">https://pyor.review</a> to fix this problem, try it out and let me know what you think.</p>
]]></description><pubDate>Fri, 04 Sep 2026 06:28:23 +0000</pubDate><link>https://news.ycombinator.com/item?id=49561191</link><dc:creator>othmanosx</dc:creator><comments>https://news.ycombinator.com/item?id=49561191</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49561191</guid></item><item><title><![CDATA[New comment by othmanosx in "Ask HN: Code review of AI output, review what?"]]></title><description><![CDATA[
<p>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.</p>
]]></description><pubDate>Fri, 04 Sep 2026 06:25:13 +0000</pubDate><link>https://news.ycombinator.com/item?id=49561175</link><dc:creator>othmanosx</dc:creator><comments>https://news.ycombinator.com/item?id=49561175</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49561175</guid></item><item><title><![CDATA[New comment by othmanosx in "Fine, I'll build my own text editor"]]></title><description><![CDATA[
<p>I was waiting for the punch line</p>
]]></description><pubDate>Wed, 02 Sep 2026 21:19:21 +0000</pubDate><link>https://news.ycombinator.com/item?id=49542720</link><dc:creator>othmanosx</dc:creator><comments>https://news.ycombinator.com/item?id=49542720</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49542720</guid></item><item><title><![CDATA[New comment by othmanosx in "Debian votes to allow "responsible use of generative AI""]]></title><description><![CDATA[
<p>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?</p>
]]></description><pubDate>Wed, 02 Sep 2026 16:36:40 +0000</pubDate><link>https://news.ycombinator.com/item?id=49538806</link><dc:creator>othmanosx</dc:creator><comments>https://news.ycombinator.com/item?id=49538806</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49538806</guid></item><item><title><![CDATA[New comment by othmanosx in "Claude Session URL appended to commit messages and PR descriptions by default"]]></title><description><![CDATA[
<p>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.<p>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.</p>
]]></description><pubDate>Wed, 02 Sep 2026 16:18:32 +0000</pubDate><link>https://news.ycombinator.com/item?id=49538541</link><dc:creator>othmanosx</dc:creator><comments>https://news.ycombinator.com/item?id=49538541</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49538541</guid></item><item><title><![CDATA[New comment by othmanosx in "Claude Session URL appended to commit messages and PR descriptions by default"]]></title><description><![CDATA[
<p>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?</p>
]]></description><pubDate>Mon, 31 Aug 2026 18:02:50 +0000</pubDate><link>https://news.ycombinator.com/item?id=49512741</link><dc:creator>othmanosx</dc:creator><comments>https://news.ycombinator.com/item?id=49512741</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49512741</guid></item><item><title><![CDATA[New comment by othmanosx in "Debian votes to allow "responsible use of generative AI""]]></title><description><![CDATA[
<p>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.<p>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.</p>
]]></description><pubDate>Sun, 30 Aug 2026 19:00:53 +0000</pubDate><link>https://news.ycombinator.com/item?id=49501719</link><dc:creator>othmanosx</dc:creator><comments>https://news.ycombinator.com/item?id=49501719</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49501719</guid></item><item><title><![CDATA[New comment by othmanosx in "Sloc Cloc and Code 4.0 (scc) – Finding the files that need the most attention"]]></title><description><![CDATA[
<p>Interesting, I built <a href="https://pyor.review" rel="nofollow">https://pyor.review</a> 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</p>
]]></description><pubDate>Sun, 30 Aug 2026 06:48:13 +0000</pubDate><link>https://news.ycombinator.com/item?id=49496275</link><dc:creator>othmanosx</dc:creator><comments>https://news.ycombinator.com/item?id=49496275</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49496275</guid></item><item><title><![CDATA[New comment by othmanosx in "Debian votes to allow "responsible use of generative AI""]]></title><description><![CDATA[
<p>Give <a href="https://pyor.review" rel="nofollow">https://pyor.review</a> a shot if you’re struggling with PR reviews on github.</p>
]]></description><pubDate>Sun, 30 Aug 2026 06:43:12 +0000</pubDate><link>https://news.ycombinator.com/item?id=49496252</link><dc:creator>othmanosx</dc:creator><comments>https://news.ycombinator.com/item?id=49496252</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49496252</guid></item><item><title><![CDATA[New comment by othmanosx in "Our decision on Cursor following its acquisition by SpaceX"]]></title><description><![CDATA[
<p>Have you tried <a href="https://pyor.review" rel="nofollow">https://pyor.review</a> ?<p>It’s not an editor in that sense but a tool optimized for reviewing PRs produced by AI.</p>
]]></description><pubDate>Sat, 29 Aug 2026 18:26:30 +0000</pubDate><link>https://news.ycombinator.com/item?id=49492110</link><dc:creator>othmanosx</dc:creator><comments>https://news.ycombinator.com/item?id=49492110</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49492110</guid></item><item><title><![CDATA[New comment by othmanosx in "It’s so hard to finish an idea that is not yours and is just suggested by AI"]]></title><description><![CDATA[
<p>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?</p>
]]></description><pubDate>Fri, 28 Aug 2026 20:57:21 +0000</pubDate><link>https://news.ycombinator.com/item?id=49484166</link><dc:creator>othmanosx</dc:creator><comments>https://news.ycombinator.com/item?id=49484166</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49484166</guid></item><item><title><![CDATA[New comment by othmanosx in "We need to talk about migrations with AI"]]></title><description><![CDATA[
<p>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.<p>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<p>later after that, I gathered the pain points we faced during our review proccess and built a platform optimized for reviewing AI PRs (<a href="https://pyor.review" rel="nofollow">https://pyor.review</a>).
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.</p>
]]></description><pubDate>Fri, 28 Aug 2026 18:17:20 +0000</pubDate><link>https://news.ycombinator.com/item?id=49482439</link><dc:creator>othmanosx</dc:creator><comments>https://news.ycombinator.com/item?id=49482439</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49482439</guid></item><item><title><![CDATA[New comment by othmanosx in "It’s so hard to finish an idea that is not yours and is just suggested by AI"]]></title><description><![CDATA[
<p>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.</p>
]]></description><pubDate>Thu, 27 Aug 2026 21:31:33 +0000</pubDate><link>https://news.ycombinator.com/item?id=49471540</link><dc:creator>othmanosx</dc:creator><comments>https://news.ycombinator.com/item?id=49471540</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49471540</guid></item><item><title><![CDATA[New comment by othmanosx in "Tell HN: Man, AI is killing my brain"]]></title><description><![CDATA[
<p>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 (<a href="https://pyor.review" rel="nofollow">https://pyor.review</a>) to make reviewing the code a lot less stressful.</p>
]]></description><pubDate>Thu, 27 Aug 2026 21:27:24 +0000</pubDate><link>https://news.ycombinator.com/item?id=49471501</link><dc:creator>othmanosx</dc:creator><comments>https://news.ycombinator.com/item?id=49471501</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49471501</guid></item><item><title><![CDATA[New comment by othmanosx in "Ask HN: How do you code review?"]]></title><description><![CDATA[
<p>Have you tried reviewing code on <a href="https://pyor.review" rel="nofollow">https://pyor.review</a> instead of checking out the code locally?</p>
]]></description><pubDate>Wed, 26 Aug 2026 18:07:14 +0000</pubDate><link>https://news.ycombinator.com/item?id=49453338</link><dc:creator>othmanosx</dc:creator><comments>https://news.ycombinator.com/item?id=49453338</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49453338</guid></item><item><title><![CDATA[New comment by othmanosx in "Ask HN: What tools are you using for human code review of AI-assisted code?"]]></title><description><![CDATA[
<p>Me and my team use <a href="https://pyor.review" rel="nofollow">https://pyor.review</a> instead of github, which I built myself, it’s a far better alternative and fixes our exact pain points</p>
]]></description><pubDate>Tue, 25 Aug 2026 18:25:54 +0000</pubDate><link>https://news.ycombinator.com/item?id=49438416</link><dc:creator>othmanosx</dc:creator><comments>https://news.ycombinator.com/item?id=49438416</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49438416</guid></item><item><title><![CDATA[New comment by othmanosx in "Coding expertise is going to collapse from AI reliance"]]></title><description><![CDATA[
<p>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?</p>
]]></description><pubDate>Tue, 25 Aug 2026 13:55:43 +0000</pubDate><link>https://news.ycombinator.com/item?id=49434209</link><dc:creator>othmanosx</dc:creator><comments>https://news.ycombinator.com/item?id=49434209</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49434209</guid></item><item><title><![CDATA[New comment by othmanosx in "Building an (almost) fully self-hosted, sandboxed, agentic software factory"]]></title><description><![CDATA[
<p>Give pyor.review a try, should help with the human bottleneck</p>
]]></description><pubDate>Sat, 22 Aug 2026 06:13:29 +0000</pubDate><link>https://news.ycombinator.com/item?id=49397057</link><dc:creator>othmanosx</dc:creator><comments>https://news.ycombinator.com/item?id=49397057</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49397057</guid></item><item><title><![CDATA[New comment by othmanosx in "Show HN: Diffview, a fast Git diff viewer written in Rust"]]></title><description><![CDATA[
<p>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.<p>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.<p>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.<p>Will definitely check it out</p>
]]></description><pubDate>Fri, 21 Aug 2026 18:44:42 +0000</pubDate><link>https://news.ycombinator.com/item?id=49392294</link><dc:creator>othmanosx</dc:creator><comments>https://news.ycombinator.com/item?id=49392294</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49392294</guid></item><item><title><![CDATA[New comment by othmanosx in "Ask HN: How do you review and validate LLM generated code?"]]></title><description><![CDATA[
<p>I use pyor.review</p>
]]></description><pubDate>Fri, 21 Aug 2026 14:08:28 +0000</pubDate><link>https://news.ycombinator.com/item?id=49388308</link><dc:creator>othmanosx</dc:creator><comments>https://news.ycombinator.com/item?id=49388308</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49388308</guid></item></channel></rss>