There is an AI code review bubble

Post by atq2119 » Tue, Jan 27, 2026, 12:57 PM UTC

eieio wrote: post #144

Quarrelsome wrote: post #75

Earlier quoted context omitted.

> but the signal to noise ratio is poor Nail on the head. Every time I've seen it applied, its awful at this. However this is the one thing I loathe in human reviews as well, where people are leaving twenty comments about naming and then the actual FUNCTIONAL issue is just inside all of that mess. A good code reviewer knows how to just drop all the things that irk them and hyperfocus on what matters, if there's a fun…

at my last job code review was done directly in your editor (with tooling to show you diffs as well). What this meant was that instead of leaving nitpicky comments, people would just change things that were nitpicky but clear improvements. They'd only leave comments (which blocked release) for stuff that was interesting enough to discuss. This was typically a big shock for new hires who were used to the "comment for…

Post by eieio » Tue, Jan 27, 2026, 1:03 PM UTC

atq2119 wrote: post #201

eieio wrote: post #144

Earlier quoted context omitted.

at my last job code review was done directly in your editor (with tooling to show you diffs as well). What this meant was that instead of leaving nitpicky comments, people would just change things that were nitpicky but clear improvements. They'd only leave comments (which blocked release) for stuff that was interesting enough to discuss. This was typically a big shock for new hires who were used to the "comment for…

Was that Jane Street? I remember watching a presentation from someone there about such a system. If not, any chance this tooling is openly available?

Post by scott_w » Tue, Jan 27, 2026, 1:31 PM UTC

wtetzner wrote: post #198

hdjrudni wrote: post #179

Earlier quoted context omitted.

Yes, but I don't know how effective it is. 99% of the time someone leaves a 'nit' the other person fixes it. So we're still dealing with most of them like regular comments. Only once or twice I've been like "nah, I like my way better" but I can only do that if they also leave an LGTM. Sometimes they do. There's one or two people that will hold your code hostage until you reply to every little nit. At that point they…

I wonder if there's a psychological benefit though. If someone states up front that they know something is just a nitpick, the author might be less likely to push back, and therefore it's less likely to end up in a bike shedding back-and-forth.

Post by delusional » Tue, Jan 27, 2026, 1:57 PM UTC

eieio wrote: post #144

Quarrelsome wrote: post #75

Earlier quoted context omitted.

> but the signal to noise ratio is poor Nail on the head. Every time I've seen it applied, its awful at this. However this is the one thing I loathe in human reviews as well, where people are leaving twenty comments about naming and then the actual FUNCTIONAL issue is just inside all of that mess. A good code reviewer knows how to just drop all the things that irk them and hyperfocus on what matters, if there's a fun…

at my last job code review was done directly in your editor (with tooling to show you diffs as well). What this meant was that instead of leaving nitpicky comments, people would just change things that were nitpicky but clear improvements. They'd only leave comments (which blocked release) for stuff that was interesting enough to discuss. This was typically a big shock for new hires who were used to the "comment for…

Post by shagie » Tue, Jan 27, 2026, 2:14 PM UTC

tayo42 wrote: post #155

shagie wrote: post #134

Earlier quoted context omitted.

Trying to write the easiest code that I could test... I don't think I can without writing an excessively brittle test that would break at the slightest implementation change. So you've got this Java: public List someCall() { return IntStream.range(1,10).boxed().toList(); } public List filterEvens(List ints) { return ints.stream() .filter(i -> i % 2 == 0) .toList(); } int aMethod() { List data = someCall(); return fil…

You mention the tools you can use to make it happen. I think we're at the point where you need concrete examples to talk about whether it's worth it or not. If you have functions that can't be called twice, then you have no other option to test details in the implementation like that. Yeah there's a tradeoff between torturing your code to make everything about it testable and enforce certain behavior or keeping it si…

    std::vector doThing(const std::vector& nums) {
        std::vector tmp1;
        std::vector tmp2;
        std::ranges::copy_if(data,
                             std::back_inserter(tmp1),
                             [](int n) { return n % 2 == 0; }
        );
        std::ranges::copy_if(tmp1,
                             std::back_inserter(tmp2),
                             [](int n) { return n % 2 == 0; }
        );
        return tmp2;
    }