othmanosx

7 ms·

31.
by othmanosx 2mo ago
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 m
32.
by othmanosx 2mo ago
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
33.
Show HN: Stage is sunestting their product, what now?
2 points by othmanosx 2mo ago|0 comments
34.
by othmanosx 2mo ago
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
35.
by othmanosx 2mo ago
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 te
36.
by othmanosx 2mo ago
Have you looked at pyor.review?
37.
by othmanosx 2mo ago
Have you tried pyor.review for reviewing your PRs?
38.
by othmanosx 2mo ago
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 ad
39.
by othmanosx 2mo ago
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.
40.
by othmanosx 2mo ago
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 ad
41.
by othmanosx 2mo ago
>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 se
42.
by othmanosx 2mo ago
Just add an Up Directory button and you’ll be infinitely better than Finder.
43.
by othmanosx 2mo ago
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.
44.
by othmanosx 2mo ago
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&#
45.
by othmanosx 2mo ago
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
46.
by othmanosx 2mo ago
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/ ), surfaci
47.
by othmanosx 2mo ago
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,
48.
by othmanosx 2mo ago
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.
49.
by othmanosx 2mo ago
Yeah, I use VSCode a lot less now, even for code reviews, I built my own code reviewer that's better than Github IMO. I no longer use VSCode or Github, I use Claude to produce the code and use https://pyor.review to review
50.
by othmanosx 2mo ago
One job doesn't really fit the button thing because a button has to do many things, only one of which is being clickable. Having feedback when clicked, feedback when hovered. A loading state, a disabled state, a mix of everything. That
51.
by othmanosx 2mo ago
That's how I review code nowadays: 1. Start an AI review on the side while I do my own review. 2. Test the app myself, note any bugs or visual issues. 3. Review the code on www.pyor.review, compared to Github, Pyor allows me to categor
52.
by othmanosx 2mo ago
it's a wrapper around GitHub APIs. Github is still the BE, Pyor is only the better UI
53.
by othmanosx 3mo ago
YES! and I already love them. haven't heard of obra’s superpowers, will check them out. Thanks.
54.
by othmanosx 3mo ago
looks like we share the same pain. https://www.hatchr.link/
55.
by othmanosx 3mo ago
That's how I code nowadays: 1. Start a session. 2. Grill my requirements. 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
56.
by othmanosx 3mo ago
100% agree. Human reviews do still matter a lot. our goal is to speed this up, not replace it completely with AI reviews. I think AI should complement the human review, not replace it, and I think everyone already agrees with me on this. Th
57.
by othmanosx 3mo ago
Every team should follow a plan, fine on a side project, but if you work in a large codebase with a bunch of devs, you need to have some sort of workflow to avoid stepping on each other's toes. bug fixes are supposed to be small, conta
58.
by othmanosx 3mo ago
I think you're missing the point of code review. By the time when the PR is ready to merge, discussions around the architecture and how the code should be structured should already be part of the tech design of a given feature. So the
59.
by othmanosx 3mo ago
Human reviews do still matter a lot. our goal is to speed this up, not replace it completely with AI reviews. I think AI should complement the human review, not replace it, and I think everyone already agrees with me on this. The problem wi
60.
by othmanosx 3mo ago
I still believe that I can write better code compared to what the AI can produce. But is it really... cost-effective? Probably not.

More ›