Hey there! Thanks for your feedback, we should've have been more clear. What our extension allows you to do on VS Code is:
- Go to a file / highlight a block of code you want to understand at depth
- We take the commit hashes for the lines selected (the whole file if no LOC selected)
- We pass those commit hashes as a parameter to the GitHub/GitLab/Bitbucket API to obtain all the associated PRs
- We sort those PRs by relevance (using number of comments as the heuristic)
- With the title of that PR, we search for the Slack threads and Jira tickets most closely associated to that PR title (if you optinally integrated Slack and/or Jira)
- We aggregate to a GPT prompt the title and body of the most relevant piece of info from each source, to finally generate a summary of that code context.
Very cool idea, but it is asking for access to all github repos, public and private? All personal details as well?
You should really refine what you're asking for. I would like to use this for open source code and it should be able to do a great job, but this is crazy.
Hey, thanks! It's a limitation we have with the scopes that the GitHub API provides.
You can't limit which repos in an organization you're gonna give it access to, but you can limit which organizations you are going to give it access to.
Starting with an organization that has public repos is a good way of starting, indeed.
This is great! Also awesome that it's open source. I was actually in the process of building this exact thing, I'll pause on that. I'm curious- what size companies do you envision as your target customer? And have you gotten any pushback yet about security/compliance concerns?
About the ideal size and security concerns: We've actually seen the most pushback from very small teams (5 or less engineers). I'm not sure why exactly, but my best guess is that as companies grow, it simply becomes more normal for them to give access to these tools and they see that nothing bad happens (they end up getting a lot of value actually).
However, we can't integrate with the self-hosted/enterprise versions of GitHub, VS Code/Slack, etc. yet which is what our potentially best customers in the future use.
Because of that, the ICP is engineering teams sized between 15 and 150
I'll message you, it'd be great to chat! I was working on https://bemi.ai/, which was pretty early stage.
Also random suggestion- I don't think there's a need for the homepage header text & image to be delayed showing with the side swoop in animation, or at least the delay timer could be lessened. I found myself almost scrolling past without seeing it when I tried reloading your page.
Honestly, we start the convo by saying we don't store code. That is what eases them into accepting.
We care about privacy, that's wy we are open source.
Super cool... but these tools always seem to be in the non-existent middle of a Venn diagram of "big enough a dev can't hold all context" and "small enough no one is going to care if we hand over everything".
What are your thoughts on this issue and the future of these kinds of tools where teams have to hand over the key to the city on a ongoing basis and running on dev computers?
Most dev tools are isolated to a certain extent and aren't getting blank checks to the entire engineering department from top to bottom with access to external tools that detail business concerns. These tools seem like extremely ripe pickings for targeting for corporate espionage / hackers to 'pwn' companies.
This is a very good and common question we get, thanks for bringing it to the discussion. We have a very strong conviction that these kinds of tools have to be open-source to solve this trust issue.
You still have to give us read access to your GitHub, Slack, Jira, etc. Which is still asking for access to corporate info, but you know... people are very used to giving access to these tools via oAuth flows.
Regarding running on dev computers, we have one answer to that: Providing value as a GitHub Action. We still haven't launched it (it's gonna happen very soon), but our hypothesis is that by packaging the product in such format, we'll be able to address that very valid concern.
Our attack surface is big, yes, but think about slack or Apple notes, where people keep the actual api keys.
We could be a risk, but I, as CTO have ensured to the best of my knowledge it's hard to do. If you want to talk more about it, I'd love to do so, learning would be great!
Hey there, thanks for your suggestion! Self-hosted is on the roadmap to be able to get enterprise customers for sure. We're focused on SMB right now so it's not the immediate focus, but we do recognize we need to integrate with the self hosted versions of GitHub, Slack, etc. to be able to go sell to the enterprise.
I'd exercise extreme caution-- they may be in violation of their own company policies. Knowingly processing code from these companies may expose you to liability.
Does this at all send code and company communication to any third party servers? Like, GPT stores all prompts does it not? Seems like a no-go for most companies if they don't vet GPT first.
CTO here!
On the github action: it is in development and will soon also be open source!
Find us on twitter if you see any bugs, we don't like fruit flies.
- Go to a file / highlight a block of code you want to understand at depth
- We take the commit hashes for the lines selected (the whole file if no LOC selected)
- We pass those commit hashes as a parameter to the GitHub/GitLab/Bitbucket API to obtain all the associated PRs
- We sort those PRs by relevance (using number of comments as the heuristic)
- With the title of that PR, we search for the Slack threads and Jira tickets most closely associated to that PR title (if you optinally integrated Slack and/or Jira)
- We aggregate to a GPT prompt the title and body of the most relevant piece of info from each source, to finally generate a summary of that code context.
You should really refine what you're asking for. I would like to use this for open source code and it should be able to do a great job, but this is crazy.
You can't limit which repos in an organization you're gonna give it access to, but you can limit which organizations you are going to give it access to.
Starting with an organization that has public repos is a good way of starting, indeed.
About the ideal size and security concerns: We've actually seen the most pushback from very small teams (5 or less engineers). I'm not sure why exactly, but my best guess is that as companies grow, it simply becomes more normal for them to give access to these tools and they see that nothing bad happens (they end up getting a lot of value actually).
However, we can't integrate with the self-hosted/enterprise versions of GitHub, VS Code/Slack, etc. yet which is what our potentially best customers in the future use.
Because of that, the ICP is engineering teams sized between 15 and 150
What are your thoughts on this issue and the future of these kinds of tools where teams have to hand over the key to the city on a ongoing basis and running on dev computers?
Most dev tools are isolated to a certain extent and aren't getting blank checks to the entire engineering department from top to bottom with access to external tools that detail business concerns. These tools seem like extremely ripe pickings for targeting for corporate espionage / hackers to 'pwn' companies.
In fact, we wrote this blog post where we talk about how we're building this without storing your code or passing it through our server at all: https://www.watermelontools.com/post/building-a-code-archeol...
You still have to give us read access to your GitHub, Slack, Jira, etc. Which is still asking for access to corporate info, but you know... people are very used to giving access to these tools via oAuth flows.
Regarding running on dev computers, we have one answer to that: Providing value as a GitHub Action. We still haven't launched it (it's gonna happen very soon), but our hypothesis is that by packaging the product in such format, we'll be able to address that very valid concern.
Thanks!
Looks helpful! What else is on the roadmap?
Besides the GitHub (and its counterparts) Action, I can tell you that we have ideas for:
- A Discord integration
- Fine-tune GPT (with Git, Slack and Jira data) to be able to ask questions specific to your codebase
- An expansion to Intelli J
Aside from an appliance in some local servers, what vendors do you use that solve this problem well ?
git blame with more steps?
Thanks for your comment. It's something we should be more clear about.