Hi! Seeing how many maintainers and repos have issues with PRs made by bots, we decided to do something, and we started building cherry.

We are doing a private beta and we'd love to hear your thoughts on how to solve this without discouraging legitimate junior developers. What kind of heuristics do you currently use manually that we could automate?

The hobbit!

> Biggest risk I've found building solo with AI isn't bad code — it's accepting plausible code without interrogating it

Totally agree. While I am aware of the danger, sometimes I become lazy and something slips.

> Adding AI to the mix might make it a harder sell, not easier.

100%. I think teams that already pairing could try something like this.

Working on migrating Hopp's [1] overlay window, which we use for drawing the remote cursors, from winit + wgpu to gpui. I used claude in the weekend to make a prototype and now I want to make a gpui app, which will replicate all of our requirements, in order to see what is missing and if I need to contribute upstream. I am planning to write a blog post when the migration is over.

[1] https://github.com/gethopp/hopp

OP here, I didn't write the post, but found it interesting and posted it here.

> So i understand correctly, they spend more even thought They can, optimize and spend less

This is what I understand as well, we could utilise the hw better today and make things more efficient but instead we are focusing on making more. TBH I think both need to happen, money should be spent to make better more performant hw and at the same time squeeze any performance we can from what we already have.

What is your setup when pairing remotely? (Full disclosure I am building an OSS app for this purpose and just want to learn what is working for people)

Our team uses IntelliJ so we use Code with Me with Slack for AV. Specifically on Slack we have channels called pairing-room-1, pairing-room-2, etc. Allows colleagues to drop in and out.

I would try Tuple but to be honest we are fine on Code with Me.

Not OP, but Tuple is pretty great.

Indeed Tuple is a great product. The goal is to match their quality and make it the OSS alternative, it's still early though, and I am trying to get some feedback.

With zed you can also share your screen in the editor which makes it a bit better, but still you can't take control of the other machine.

IMO if you only care about coding doing it in the editor is the best approach, you get zero latency and have all the context that you need (most of the times). But if you want to do more, like opening the browser for whatever reason, or teaching how to use a specific cli, etc, then taking control works better.

If you liked pop you might like gethopp.app, which is an OSS pair programming app (full disclosure I am the co-maintainer). Unfortunately because we have chosen tauri for the frontend we can only support macos and windows, but I am working on a solution for Linux too.

While I like rust and use it for my own projects I agree 100% with you. No reason to replace sw that has been working perfectly for many years.

I also like Rust but I honestly don't understand why they are desperately replacing battle tested production quality sw for alpha quality ones. It is insane.

I see your point and I agree that pair programming code reviews give a lot of value but you could also improve and learn from comments that happened async. You need to have teammates, who are willing to put effort to review your patch without having you next to them to ask questions when they don't understand something.

> this kind of interview is way harder to set up

This is a good point.

I will add a note in the post to highlight this.