Launch HN: Sweep (YC S23) – A bot to create simple PRs in your codebase
41–50 of 117 posts
Re: Launch HN: Sweep (YC S23) – A bot to create simple PRs in your codebase
#42Meta-issue: the purple on black text in the examples page is hard to read. https://docs.sweep.dev/examples
Re: Launch HN: Sweep (YC S23) – A bot to create simple PRs in your codebase
#43What is your data privacy policy?
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
#44Re: Launch HN: Sweep (YC S23) – A bot to create simple PRs in your codebase
#45Your 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.
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
#46What is your data privacy policy?
Re: Launch HN: Sweep (YC S23) – A bot to create simple PRs in your codebase
#47Meta-issue: the purple on black text in the examples page is hard to read. https://docs.sweep.dev/examples
Re: Launch HN: Sweep (YC S23) – A bot to create simple PRs in your codebase
#48What 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?
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
#49Wait 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!
Re: Launch HN: Sweep (YC S23) – A bot to create simple PRs in your codebase
#50Great 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?
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%.