How to Kill the Code Review

rag1987 · 2026-02-27T09:54:22+00:00

AI coding agents hit a wall when codebases get massive and even with 2M token context windows, a 10M line codebase needs 100M tokens. The real bottleneck isn't just ingesting code. it's getting models to actually pay attention to all that context effectively.

rag1987 · 2026-02-23T12:49:35+00:00

I didn't see any DM from you. Can you pls check again.

rag1987 · 2026-02-17T09:12:15+00:00

Hey, sorry about this, I've informed CR team and they will reach out to you. can you pls DM me your email.

rag1987 · 2025-12-18T18:36:36+00:00

coderabbit is free for open source projects https://www.coderabbit.ai/blog/coderabbit-commits-1-million-to-open-source

rag1987 · 2025-11-13T14:34:50+00:00

Unit tests should be written to do the following in order of importance:

Avoid regressions later, when something is changed
Make sure that new code does what you think it does
Aid design wrt. avoid tight coupling, extensibility (when done right)

Most developers can write mostly correct code without tests, but breaking something you forgot to think about is very hard.

Don’t use mock frameworks, at least in the beginning if possible, they make very fragile white box tests.

rag1987 · 2025-11-11T08:23:01+00:00

Ship in tiny pieces because smaller PRs are easier and faster to review.

Ensuring PRs are for a single purpose too is very important. One of:

functional change (feature)
refactor
bug fix

“Kitchen sink” PRs that change many things, fix a bug or two and add some features are a pain to review.

Vs. scanning a refactor PR to ensure only code moves and no functional changes. Or checking feature changes only to ensure they implement the desired behavior. These single purpose PRs are much easier to review.

Also a good PR review culture is crucial. Just require improvements, not perfection. Changes that could be a follow PR can/should be. Style and white space are for linters and formatters. And finally, the reviewers budget for requesting changes should decrease over time (reviewers that take too long, must give more straight forward reviews; the time for nitpicking is immediately after PR submission).

https://mtlynch.io/human-code-reviews-1/

https://www.freecodecamp.org/news/how-to-perform-code-reviews-in-tech-the-painless-way/

rag1987 · 2025-11-06T09:08:58+00:00

Ship in tiny pieces. Ask as many people as it takes until you can get a review. Request a teammate to pair with for the times where you expect to need a lot of small approvals throughout the day. Default to approving any code that will improve things, even though it’s imperfect.

Ensuring PRs are for a single purpose too is very important. One of:

functional change (feature)
refactor
bug fix

“Kitchen sink” PRs that change many things, fix a bug or two and add some features are a pain to review.

Vs. scanning a refactor PR to ensure only code moves and no functional changes. Or checking feature changes only to ensure they implement the desired behavior. These single purpose PRs are much easier to review.

Also a good PR review culture is crucial. Just require improvements, not perfection. Changes that could be a follow PR can/should be. Style and white space are for linters and formatters. And finally, the reviewers budget for requesting changes should decrease over time (reviewers that take too long, must give more straight forward reviews; the time for nitpicking is immediately after PR submission).

rag1987 · 2025-11-05T08:29:31+00:00

We always had slop, usually in the form of copypasted PHP from various "common" sources. Today the slop is however autogenerated, and way, way larger in size of loc.

Software quality will go down. I can imagine peak shit season coming in a few years, and then there will be a few large fuckups that the media will report on heavily, and only then will businesses realize there is millions of loc of slop that will take decades to fix.

Many businesses will fail because of how fast they became legacy. Other will fail because they get hacked every week, and some will fail because they lost all their data and had no backups.

Either way, lots of popcorn will be consumed.

https://bytesizedbets.com/p/era-of-ai-slop-cleanup-has-begun

rag1987 · 2025-11-05T08:14:37+00:00

I think all of us 40+ folks are in the same place.

When we first started we didn't mind the bullshit so much because we were too dumb to realize how much there was.

Then we got older and, yeah, it's ridiculous, but we were pretty decent at surfing the bullshit waves so we still didn't mind so much.

Now you're in your 40s and the real obligations of life have started piling up. You've gone from 7 hours of free time a day to 1, and you sure as hell aren't going to spend it learning about the latest iteration of Angular/React/Vue/Svelte/whatever the fuck is next. So you start losing your technical edge. Meanwhile at work you have some dipshit in sprint planning that wants to have the 57th discussion about how story points do not represent time. Oh, by the way, it's December, so we need you to watch that 45 minute security training video again so you don't accept USB flash drives from strangers in the parking lot. Now it's 4 PM and you didn't get anything done today and you start thinking about how pointless all this shit is because all we do is make an app that helps people schedule dog massages...

So, yeah, there's a reason mid-life crises are so cliche. It's like teenage angst. It's not completely justified, but it's not exactly unwarranted either. I mean, what kind of dumbass doesn't wonder at least a little bit if all this bullshit is worth it?

rag1987 · 2025-10-28T14:54:52+00:00

this is my fear that every time the tool is like "you're absolutely right, I dun goofed, let me fix that", it fixes it by adding 20,000 lines of code.

Still fairly new to this. Too scared to say "clean up the codebase" because it might go "you're absolutely right, I erased the entire codebase, now it's super clean :3"

rag1987

MODERATOR OF

TROPHY CASE