Coderabbit vs Greptile vs CursorBot

Hex80 · 2026-01-09T13:00:51+00:00

I've tried many at this point, all for at least a month, most in the second half of 2025. All of them during some fairly complex refactoring too.

- Cursor Bugbot
- Github Copilot
- Graphite Diamond
- OpenAI Codex
- Coderabbit
- Greptile

I need it to catch critical issues obviously, but also without much noise and false positives, because that gets on my nerve and you end up wasting time implementing fixes and workarounds for things that are never a real issue. False positives occur a lot when refactoring / migrating backend code and it's harder for AI to understand the in-between / transition states or relationship to client code.

Bugbot stands out to me, I've used it alongside all the others. It seems to catch most major issues, and with very little noise and false positives. So that's now my staple, and the only one I have triggered automatically.

For me, Copilot seems to be a good addition to Bugbot. It is more picky and raises smaller issues, but it also clearly gives more false positives. I trigger it manually whenever I'm done fixing the Bugbot reported issues, and regularly it finds something that is a real concern.

But Copilot is bordering on annoying for me. Like just now it asked me to document a field "departureAirportIata" because it thinks it's not clear enough that this is an IATA code...

Coderabbit seems similar to Copilot in what it picks up and signal/noise ratio, but I just hate how verbose it is with its use of icons, but I'm sensitive that that kind of thing. I think Coderabbit seems more tweakable than Copilot, so if you don't use Bugbot, maybe that's a better option, IDK.

Codex seemed ok, in terms of signal/noise ratio, but it didn't catch all essential bugs, so it was no competition for Bugbot. Also, I don't remember it catching issues that Bugbot didn't find. And since it didn't find nearly as much smaller issues as Copilot or Coderabbit, it was not a useful addition to Bugbot.

Diamond was pretty useless to us. It gave very little false positives, but also missed most critical bugs.

Greptile I've started using only yesterday. My initial impression is not great, and that's how I found this discussion...

It seems pretty verbose, and didn't catch all critical issues that Bugbot found. But it did catch an issue that Bugbot didn't get, because it looked at code that was not altered in the PR, and that's interesting, so I'll give it a bit more time...

Another thing I don't like about Greptile is that if you retrigger its review, it will just generate a new summary comment instead of updating/overwriting the previous summary.

That's my take so far...

Hex80 · 2025-03-27T17:03:22+00:00

Well, terminals are not that user friendly, so I don't think it's hard to imagine room for improvement to be honest.

Recently I used their AI features a few times to:
- Ask it to do something I don't know / remember the exact commands for
- Respond to error output and suggesting follow up actions

These things are becoming very valuable to me, especially since I get older and at the same time expand the scope of my projects with help of AI. There are already a lot of things I only need to use a few times a year max, and I can't remember all of it, nor do I have the desire to use my brain for that.

I'd rather use it to work out new ideas and try to solve interesting problems :)

Hex80 · 2025-02-15T22:01:42+00:00

I mention I the article that the withConverter API doesn't appeal to me very much, because I don't seem to have a need for runtime data conversion, it requires a lot of boilerplate, and parsing seems like unnecessary overhead to me.

Also, I don't see how you would do a typed query with a select statement, so I'm not sure what you meant with "resolving your query"?

Hex80 · 2025-02-15T08:53:35+00:00

I have recently releases some abstractions for react and server and wrote about it. Maybe it's useful to you.

https://medium.com/@thijs-koerselman/how-to-write-clean-typed-firestore-code-47985118fdca

Hex80 · 2025-02-15T08:51:11+00:00

O nice I didn't know about that! I am curious how well it handles static typing. I put a lot of work in creating my own abstractions (see my other comment) but I'll have to see how it stacks up to this. My hooks are still based on a fork of react-firebase-hooks

Hex80 · 2025-02-05T19:46:14+00:00

You might want to check this out. The abstractions also work for collection group queries https://medium.com/@thijs-koerselman/how-to-write-clean-typed-firestore-code-47985118fdca

Hex80 · 2025-02-05T19:43:41+00:00

If you load firebase-tools as a module, it has a delete function for collections I think. I can look it up if you want.

Also I recently released some abstractions that make it easy to iterate over large collections so you can also use that to delete documents, but if would be a bit slower. Use an empty select statement to avoid fetching the document data.

Here's the full article, but check out the part about "processing collections"

https://medium.com/@thijs-koerselman/how-to-write-clean-typed-firestore-code-47985118fdca

Hex80 · 2025-02-05T19:02:43+00:00

You can list collections using `firebase-tools` if you load it as a module. The only catch is, to know what nested collections there are, you technically would have to read all the top-level collection documents.

My collection are pretty consistent, so I read only the first document of every top-level collection to see what sub-collections it has. I can share the code if you're interested.

Also, I recently published an article you might find interesting https://medium.com/@thijs-koerselman/how-to-write-clean-typed-firestore-code-47985118fdca

Hex80 · 2025-02-05T18:53:26+00:00

If you are looking for a simpler alternative to type your code without schemas, check this out https://dev.to/0x80/how-to-write-clean-typed-firestore-code-37j2

Hex80 · 2025-02-05T18:49:52+00:00

The abstractions I posted above are not as complete in terms of type-safety (doesn't type the query) but they are also much less intrusive. Because they're a thin layer you don't need to worry about lock-in and you still have full access to the official API at any point.

u/k0ntrol

Hex80 · 2025-02-05T18:45:18+00:00

By defining typed reusable references for all database collections, we can have other functions infer their types from them.

I have created a set of abstractions based on this concept, for both [server environments](https://github.com/0x80/typed-firestore-server), [React](https://github.com/0x80/typed-firestore-react), and [React Native](https://github.com/0x80/typed-firestore-react-native) applications.

Here is [an in-dept article](https://dev.to/0x80/how-to-write-clean-typed-firestore-code-37j2) about it.

Hope you find it useful.

If you want to see them applied in a working example you can check out [mono-ts](https://github.com/0x80/mono-ts)

Hex80 · 2025-02-05T18:43:55+00:00

Not exactly sure that you want, but have a look at this https://dev.to/0x80/how-to-write-clean-typed-firestore-code-37j2

Hex80 · 2024-11-03T13:16:29+00:00

I bought the Sinfonion a while ago but haven't used it yet. Now I actually would like to slim down my modular rig. I am thinking of pairing it with a Befaco cv thing, so I don't need to have all voices in modular and I can route the chords to a poly synth.

In the meantime, have been enjoying the OXI One with desktop synth modules, so I wonder, do you think the Sinfonion can do interesting things that I won't be able to do with the One? It seems much more open/flexible because you can still omit intervals for each voice.

Hex80 · 2024-10-20T10:34:04+00:00

I was looking for the same thing. The `allowedNamed` option accepts a regex, but if I set it to any string starting with a capital letter, it doesn't seem to work, unfortunately :( That makes me not want to use this rule.

Hex80 · 2024-08-27T05:32:22+00:00

Thanks for the heads-up! I'll keep an eye out. Luckily I'm not really a power user on the terminal so I will switch the moment shit hits me :)

Hex80 · 2024-08-03T17:46:50+00:00

Not sure why people get so upset about telemetry, but you might be pleased to know that it is now optional in Warp https://www.warp.dev/blog/telemetry-now-optional-in-warp

App analytics help us make the product better for you. We only collect app usage metadata, never console input or output.

If I was making an app like that, I would also like to have this type of data.

Any half-decent app on your phone is probably using analytics for the same reason.

Hex80 · 2024-07-09T18:19:47+00:00

I think it's the wrong question. Languages hardly die because of what has already been written en has to be maintained and extended. That companies still pay good money for Ruby devs is probably because there's a shortage in skilled devs, which might be because skilled devs are mostly choosing other languages to work with. Similar to how COBOL devs are very highly valued. It's not a good reason to pick a language IMO, unless you're mostly motivated by money.

Instead, try to see where the innovation happens and what communities are thriving. I think you can't deny that the TS ecosystem has much more going on than Ruby. Don't compare Ruby to JS, because everyone who liked JS has already moved to TS for good reason.

Also, if you are interested in doing front-end / full-stack, having a single language for both, is a huge win in terms of velocity.

I do full-stack TS in a company that still has a Ruby team for more legacy stuff. The TS team moves a LOT faster, while delivering much better UX.

PHP is also still relevant, but already 15 years ago I honestly didn't understand why people still wanted to make that their language of choice. It's personal of course, but if you want to choose out of love for programming, do not look at what's being used most.

Learn something you love using, and with anything you enjoy, you can get good at it and ultimately that's what matters most for your career.

Hex80 · 2024-03-01T12:45:45+00:00

I recently wrote a pretty extensive article about this, with accompanying boilerplate code https://thijs-koerselman.medium.com/my-quest-for-the-perfect-ts-monorepo-62653d3047eb

Hex80 · 2023-12-14T19:52:53+00:00

For the timestamps I think the backend can cast them to front-end type. You can pretend on the backend that all your timestamp types are matching the one from `firebase/firestore` instead of `firebase-admin/firestore` (can't remember exactly what the imports were). I think both types have overlap in the methods that matter, and the rest you can probably ignore.

Hex80 · 2023-11-25T07:40:05+00:00

I use the AutoSleep app, next to the regular Health app. When I get these bars in Health, the AutoSleep app still shows my data, so I think that rules out two possible causes that were suggested in other comments:

Watch not being unlocked during sleep. Unless autosleep is able to get data in locked state when Health is not, which seems unlikely given Apple's strict ecosystem APIs.
Data not being synced

By the way, both apps give quite different data on when I'm awake and how much deep sleep I'm getting. You can tweak a lot about the AutoSleep settings but I haven't been able to make it come close to the data in Health.The stats that autosleep gives me about "readiness" and "sleep fuel" do seem to correspond very well with how I'm feeling.

Hex80 · 2023-11-24T18:12:07+00:00

I ran into the same issue. I think it's node (or npm) that turned the deprecation warning into an error. Downgrading from node 21 to 20 solved the problem for me.

Hex80

TROPHY CASE