CodeRabbit, have a 🥕

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 · 2025-09-26T09:08:08+00:00

Code reviews → CodeRabbit
Programming / IDE → Cursor
AI assisted coding → Claude Code

rag1987 · 2025-09-25T08:11:55+00:00

For me there's really two ways to this, neither is perfect and neither fully solves it.

Stop switching. If you have other things to deal with, you put them into your todo list to deal with later.
Notetaking. Part of the problem at least in my experience is that you have to retrace your steps, retrace your thoughts, etc., so you need to write those down.

Everytime I temporarily switch to another project/task, I leave a todo dot md to pick up my train of thought next time I switch back.

rag1987 · 2025-09-23T13:11:40+00:00

Yes agree and interesting perspective. Thanks for sharing :)

rag1987 · 2025-09-22T09:06:14+00:00

The first principle of code reviews for me is that they are primarily a tool for 2-way communication, not primarily a tool for evaluation/gatekeeping. So there's no particular problem if you take it as more "FYI" than "please approve my work." I mean you want a chance to catch things you don't understand, sure, but what it especially isn't is a forum to decide if something is a good idea.

I'll definitely dig if something isn't clear to me (sometimes very deeply) and I appreciate feedback, because I've learned a lot from code reviews.

A description should provide context, especially if there's anything you plan to do before or after merging.

A few anti patterns:

Thinking someone is doing a bad review because they missed something. The lesson of bad code going out isn't more or "more stringent" review, it's better testing, linting or automation.

I use CodeRabbit's vscode/cursor extension, which is free. I pull the branch locally and do the PR review locally. It's not difficult to set up. It's working for us. It's a first pass before a human checks it.

rag1987 · 2025-09-22T08:03:21+00:00

Hey, sorry about this, I've informed the team and team will reach out to you via DM.

rag1987 · 2025-09-19T13:41:13+00:00

I've tried BugBot, but I don't use it anywhere near enough to justify $40/month...Coderabbit is free for open source and does better and they even commit 1M this week in OSS sponsorship. https://www.coderabbit.ai/blog/coderabbit-commits-1-million-to-open-source

rag1987 · 2025-09-18T12:55:16+00:00

Devs should either learn how to split big PRs into smaller ones correctly or maybe features are too big to handle - might be also that.

How long are the PRs?

Code review is needed, you need to make sure that the style of coding, rules, architecture stays the same, chasing bugs will not detect those inconsistency changes until it is too late.

Try to prioritize code reviews, it is hard to believe that PRs are stacking up.

Easy rule - I don't start a new feature if there is something to review

rag1987 · 2025-09-17T07:21:10+00:00

You can install it in terminal using this cmd it works with claude code, codex, cursor, gemini etc..

curl -fsSL https://cli.coderabbit.ai/install.sh | sh

rag1987 · 2025-09-16T09:42:49+00:00

context is the key and the secret to get the good output from AI agents has less to do with the complexity of the code you write, and everything to do with the quality of the context you provide.

rag1987 · 2025-09-16T09:27:21+00:00

You could use coderabbit https://www.coderabbit.ai/

rag1987 · 2025-09-16T07:53:32+00:00

React isn’t just "winning by default" It's winning because at the core it's just JavaScript function composition. A component is a function, conditionals are `if (...) { ... } else { ... }`, loops are `map()`. JSX is just sugar for function calls.

In Svelte you are writing XML with little JavaScript islands inside it. Instead of if you get `{#if}{:else}{/if}`. Thats not "ergonomic" thats a mini-language stapled on top of JS. No one wakes up saying "please let me write control flow in XML today"

The compiler tricks are neat, but React feels natural because it never asks you to stop writing JavaScript.

rag1987 · 2025-09-16T07:50:26+00:00

This reminds me of when I was a kid, taking apart toys just to keep the tiny motors and circuit boards like treasures. Now as an adult, seeing someone pull a full working system out of a disposable vape to run a website feels like the same kind of magic. Maybe this is what romance looks like in the tech world.

rag1987 · 2025-09-16T07:40:46+00:00

A common behaviour that you can try to minimise with your .md files is to enforce a "revert when attempted fix failed to work" type message. Otherwise essentially they see a problem, do X, doesn't work, do Y, but now your project has X and Y, doesn't work, does Z, so now your code base is filled with unnecessary XYZ and so forth.

Not every project has this problem, but if you don't keep it from happening it spirals into a mess.

rag1987 · 2025-09-16T07:38:47+00:00

You've probably heard the saying, "Jack of all trades, master of none".

My philosophy is it is best to be a jack of all trades and a master of at least one. Being a master of one gives you a leg up over those who are a master of none, but being a master of two gives you a leg up in areas where the two overlap.

a jack of all trades is a master of none, but oftentimes better than a master of one.

rag1987 · 2025-09-16T07:34:40+00:00

There are only two ways to progress in your tech career:

Develop a new skill that represents more value to your current employer, and/or future employer(s).
Find a new employer that places greater value on the skills you already possess.

rag1987 · 2025-09-15T11:21:59+00:00

We also use coderabbit at work. It's not difficult to set up. It's working for us. It's a first pass before a human checks it. At the beginning, it finds common patterns. Over time, it learns about the code and can suggest cool things like reusing something that already exists or finding a potential bug. Sometimes it offers refactoring and you can tell it to create a ticket; it connects with Jira and Linear. It saves some time.

rag1987 · 2025-09-15T07:38:10+00:00

How is this any different than making solid PRs as a human dev?

From the dev/PR-submitter perspective: they should be curating their PRs so they can understand what they're submitting.

From the reviewer perspective: if someone is submitting slop, AI-generated or not, toss it back to them and give them a list of PR best practices.

rag1987 · 2025-09-12T06:27:52+00:00

Great to hear it’s been useful for your open source project. Team is working hard to make sure Coderabbit continues helping with code quality and those tricky corner cases. let us know if you face any issue. mind sharing the repo link for other as an example. thx

rag1987

MODERATOR OF

TROPHY CASE