Live data from Hacker News

Launch HN: Sweep (YC S23) – A bot to create simple PRs in your codebase

github.com

41–50 of 117 posts

Re: Launch HN: Sweep (YC S23) – A bot to create simple PRs in your codebase

#43
post #41

What is your data privacy policy?

Here it is: https://docs.sweep.dev/privacy

The logs from Sweep(which contain snippets of code) are logged for debugging purposes. We don't train on any of your code. These will only be stored for 30 days. We send this data to OpenAI to generate code. We're using the OpenAI api, and OpenAI has an agreement stating they will not train on this data and will persist it for 30 days to monitor trust and safety.

We index your codebase for search, but we use a system that only reads your repo at runtime in Modal. This runs as a serverless function which is torn down after your request completes. Here's a blog we wrote about it! https://docs.sweep.dev/blogs/search-infra

Re: Launch HN: Sweep (YC S23) – A bot to create simple PRs in your codebase

#45
post #44

Your demo video https://www.youtube.com/watch?v=WBVna_ow8vo is ridiculously compelling. You need to make a better version of the video, and maybe a few more of them.

Much appreciated! I just got a new mic so the audio won't be so bad.

What kinds of videos would you like? We can make anything, the two repos we use the most are Sweep itself and our landing page

Re: Launch HN: Sweep (YC S23) – A bot to create simple PRs in your codebase

#48
post #46
post #41

What is your data privacy policy?

I think this is a huge point! Surprised no one asked it sooner. Where does all the code go which you tokenise?

Our code is messy (sweep hasn't gotten around to it yet), but here's where we save the code! https://github.com/sweepai/sweep/blob/main/sweepai/core/vect...

So for context, this is running in a ephemeral function from Modal https://modal.com/docs/reference/modal.Function#modalfunctio....

We need a way to store the computed embeddings, because the function doesn't persist any state by default, so we use Redis. But we don't want to store the actual code as the key, so we hash the code + add some versioning. Because it's a cache, it supports concurrent writes + reads, which a lot of vector dbs do poorly.

So the actual code is only accessed at runtime (using the GitHub app authentication to clone the repo), and we also build the vector db in memory at runtime. It's slow(redis call, embedding the misses, constructing the index), but 1-2s is negligible in the context of Sweep because a single openai call could be 7s+.

And one nice feature is that when you have Sweep running on 10+ branches (which probably share 95%+ of the code) we just use the cache hits/misses to automatically handle diffs in the vector db. It's super easy to setup, we don't need to manage different indices (imagine a new index per branch), and it's very cost efficient.

Re: Launch HN: Sweep (YC S23) – A bot to create simple PRs in your codebase

#49

Wait for deluge of these PR generators to increase the commit count on GitHub.

Thats a good point, I really dislike when Sweep fails. That's why we're so focused on PR validation like self-review and GitHub actions, which brings it even closer to a junior dev. We wrote another blog on it here: https://docs.sweep.dev/blogs/giving-dev-tools There's still a long way to go on automated testing, building, and running code, but I don't see any reason it's not possible!

Another buisness idea is to make repos look more active by giving Sweep different personas.

Re: Launch HN: Sweep (YC S23) – A bot to create simple PRs in your codebase

#50
post #31
post #18

Great I think you made a good choice by interfacing directly to PRs. I'd like to see if I'm able to get my code coverage to 100% with this bot.

If I may ask - why? Why is increasing your code coverage to 100% matter? Would that reduce bugs or speed up development in any way? Wouldn't it just add lots more code to maintain and make refactors more time consuming?

100% code coverage doesn't guarantee there are no bugs, but less than 100% code coverage does mean that there is code that you definitely aren't testing.

To put it another way, code coverage isn't a direct measure of how good your testing is, but it is still a useful metric to try and improve.

In most cases 100% is too hardcore a target, but you should probably aim for at least 80%.

Post reply on HN