Show HN: Bloop – Answer questions about your code with an LLM agent (github.com)
There's a bunch of hype surrounding LLM agents, but we're positive this is one of the first implementations of an agent that can deliver immediate value for engineers working on existing projects, especially larger ones. We'll do a full write up of how the agent works and the tools it can use soon, but we wanted to share our progress, now that we've got a stable release.
bloop is a developer assistant that uses GPT-4 to answer questions about your codebase. The agent searches both your local and remote repositories with natural language, regex and filtered queries.
Some of the ways engineers use bloop to improve their efficiency when working on large codebases:
- Summarise how large files work and how multiple files work together
- Understand how to use open source libraries when documentation is lacking
- Identify the origin of errors
- Ask questions about English-language codebases in other languages
- Reduce code duplication by checking for existing functionality
- Write new code, taking into account existing codebase context (eg: "write a dockerfile for this project")
bloop runs as a free desktop app on Mac, Windows and Linux: https://github.com/bloopAI/bloop/releases/latest. On desktop, your code is indexed with a MiniLM embedding model and stored locally, meaning at index time your codebase stays private. 'Private' here means that no code is shared with us or OpenAI at index time, and when a search is made only relevant code snippets are shared to generate the response. (This is more or less the same data usage as Copilot).
We also have a paid cloud offering for teams ($45 per user per month). Members of the same organisation can search a shared index hosted by us and will get access to enterprise only features down the line (currently there's no feature gap between desktop and cloud).
58 comments
[ 9.5 ms ] story [ 126 ms ] threadWe abandoned most of the common thinking around chain of thought reasoning, finding it didn’t help accuracy much whilst increasing response times significantly.
Full write up to follow in next week or so.
[0] https://github.com/BloopAI/bloop/blob/main/server/bleep/src/...
I shared some notes on HN awhile back on a variety of experiments I did with gpt-3.5-turbo.
https://news.ycombinator.com/item?id=35441666
GitHub Copilot Chat purportedly (I'm also waiting for access) works across files in a workspace, which typically map to a repo.
So if you need it to call a function in another file that hasn’t been called in the current file, you’d have to go open the other file in a new tab then go back to the original and finally get the correct completion
One thing: Could your team have an explanation somewhere on the home page to help the users understand how their private code is being handled (locally and when the chat request happen)?
The only place I could find that information is on the HN launch thread, would be nice if it's available in the home page!
Glad to hear you found it helpful, I’m around if you have any issues.
I’ve seen a similar issue with the syntax highlighter and less common languages. Either way will debug and fix.
when will people learn not to send their entire IP to Microsoft?
I.e anything 'cloud'.
It would be an incredible breach of trust if MS was found to be doing this.
https://www.theverge.com/2022/11/8/23446821/microsoft-openai...
I find that the hardest problems to find are interfaces between projects like a bad frontend call into a backend or backend to backend. I wonder if this could index separate projects & draw links between them
We’re not far off, for example you if you index bloop itself with bloop and ask “What message does the backend send to indicate the frontend should close the eventsource?” bloop will return a decent answer which takes into account the relevant frontend and backend code.
This is an active area of improvement.
GPT4 is the only model that can just about run the agent execution, mainly due to context length and quality.
We use our own model for the embedding based code retrieval, and will be replacing some of the GPT3.5 calls with fine tuned models over the coming months.
I have been working on a related problem for my open source GPT coding tool. I am more focused creating a GPT chat experience that can act as a "junior developer" to write and edit code in your git repo. GPT is great at writing fresh, new self-contained code. I have been trying to improve its ability to make changes to a larger, complex repo.
I wrote up some notes on my current approach and some ideas for future work. I'll be curious to see how it compares to your approach, which seems more focused on search and code analysis.
https://aider.chat/docs/ctags.html
Our working thesis atm is the only approach to context that scales to support massive repos is embedding or text based retrieval.
Code search is going to need to be solved before code editing gets solved. You can't make changes if you can't find where the changes need to be made in a repo. Unless you're willing to make the UX concession that users have to manually select which files need to be edited.
And of course, yes I'd need to be able to provide my gpt4 api key.
If you want to try it out today (not using your own API key), you could sync something open source.
1. For people with only access to gpt3.5 API, does this still work?
2. Also does it work for repositories not hosted in github (ex: gitlab, bitbucket)?
2. It works with any git repos, you just have to clone them on your local machine first
It's also a condition of many LLM providers that application end users are authenticated to prevent abuse, so GitHub auth helps with this.
Building agents is an experimental process. You test an approach, maybe it works, and there's not always an obvious reason why certain experiments fail or succeed. We built three prototype agents in a Python and JS, because those languages favour scrappy fast iteration. This helped us quickly nail down our approach to the 'visible' parts.
Once we nailed down our approach, we rebuilt the agent in Rust because the speed and safety favoured all the 'invisible' parts of the project.