Hey HN, my co-founder and I built lsproxy (https://github.com/agentic-labs/lsproxy), an open-source dev container that uses language servers and syntax tree parsers to expose an API for code navigation.
This allows you to give coding agents IDE-like `go to definition` and `find reference` capabilities, or to build code graphs for RAG.
1. Start the container with the code mounted.
2. The container starts and configures preinstalled language servers (currently support Python, Typescript/Javascript, and Rust) based on the code mounted in.
3. Incoming requests get routed to the correct language server.
4. The output from the language server is cleaned and standardized for the end user.
There are two main challenges we’re solving for:
1. Each server has different, poorly documented configuration settings, making testing difficult.
2. The protocol they adhere to (Language Server Protocol) is lenient, allowing behavior to differ between servers, and the protocol itself is geared towards visual IDEs and mouse cursors.
We built this because we’ve been working on AI code search and generation, spent a ton of time building coding-specific tools for our agents, and noticed everyone else in the space was building the same tools. We’re solving code navigation first, but we are excited to expand this to a complete development environment for AI agents to plug into.
Amazing! Glad you had a good experience, and thanks for the feedback on improvements. We agree with all of the points you raised and will definitely be rolling those out soon.
If you're interested in staying involved I just created a discord and put a link in one of the comments.
Hey all! Thanks for the great discussion and trying out our app. A few of you pointed out that we should probably have a discord to make it easier to discuss feedback so here it is!
We will definitely add a feedback button, thanks for the suggestion!
We will look into why the Triage edits were not reflected in the plan. And I like your suggestions on being more specific on updates to the Plan.
I have a few suggestions in the meantime that could help to get you part of the way there as we work on these new additions:
- If you select a piece of the plan, you could ask that step to be regenerated based on new edits and then replace that piece either with the "Replace selection with summary" button or copying directly
- You can Ctrl-Z in the document editors to go back. It sounds like this might help a bit with rewinding as you describe
Hi thanks for trying it out! We don't automatically pull in the repos you allow access to. If you go through the configuration on the left side of the screen you should be able to add that repo.
Specifically, in the "Repo to index" section, if you click the dropdown on the right side you should see the repo you have added.
Hopefully that helps but let us know if you're still having issues!
Appreciate the feedback! We still want to add a lot of functionality as we continue to build the product. Are there any specifics you were hoping to see that we missed?
Yes you can. If you click on your profile, and then Settings->Applications->Configure you can see the permissions
If you have it installed for an organization its slightly different. Go to the organization, then Settings->Github Apps->Configure.
For me at least, it lists the permissions the app has. Additionally, if we ever want to request new permissions in the future, you will have to grant them.
We've been thinking about ways to make the user experience more seamless, and I think what you suggest could be a good option. We just need OpenAI to give us more tokens/sec! So you're not watching code generate for 10 minutes before being able to do anything.
Thanks so much for the thoughts! Happy to respond.
-Schema: We agree. After seeing how many times it has asked to see the database schema when working on a task, that is definitely something we will be adding.
-Manual / RAG: We did some RAG magic in the first two iterations of our product and found it was really hard to get right when the task was not well defined and as the size of the codebase grew. We found that our users were watching it do the search for the files and basically saying, "Let's see if it finds the code file I already know we need." So, we decided to go manual so at least the user isn't unpleasantly surprised by the results while we determine the right path forward with RAG. Or maybe even combine both where the user gives an "entry point," and the AI figures out the rest of the files
-I think you're right to be skeptical. In our experience, the LLMs are really best at breaking down a task to be just one notch more specific. So, I think the output here wouldn't be the best for a more high-level task. Our plan to handle this is to allow plans to be solved recursively, where you continually create a tree of subtasks, and only when you get to a specific enough "leaf" do you actually go through with generating code.
-You're right; I think we used the term "technical design doc" more generally to steer people's thinking toward software design in English rather than code. I like that you mention diagrams, though, because we would love to incorporate diagrams into our documents as our tool and LLM's capabilities increase!
-This is a very interesting idea! We used a version of this (a select set of elements of the AST that we tried to rank in importance) in our initial RAG system to give the AI a "starting point" for the RAG code search. It worked pretty well. My concern would be that the quality of the search might then depend on the naming/structure of the code (I'm thinking some 1000-line mega functions or something)
Thanks so much for the thoughtful questions!
EDIT: I see Maks also responded and I think we both offer similar messaging with slightly different delivery :)
Yes, I've seen aider and I think it's a super cool product!
We tried generating code diffs with our initial product. The issue we had was that when that diff started to grow, parsing it to determine whether it did the right thing became increasingly difficult.
We will generate code diffs in the future, but we're happy with generating the instructions for two main reasons:
-The LLMs seem to produce better output when you write out the intermediate steps
-The developer understands the thinking behind the code that was written. We feel that this is an important factor as the team size grows and developers have to interact more with each other's code
We agree Swift would be awesome to support! We're looking into how to turn it on. The Tree Sitter parser for Swift is a bit tough to work with which is why we haven't implemented that yet.
I love this anecdote because we've discussed following "Tesla's model" of autonomy, where they have incrementally delivered more complex driver-assist features.
It's very different from others like Waymo, who are going for more of an all-or-nothing approach.
Similarly, we hope to be useful early with fairly simple features so that we can get it into developers' hands to learn how to incrementally make the product better.
- Checkout the code to a temporary directory (which is deleted when it goes out of scope in python, so at the end of the indexing API call)
- Use Tree Sitter to create an index of just your chosen "Directory to Index" and then store that in a Redis cache
- We clear the index from the Redis cache if you haven't used it in 2 hours.
I don't know why exactly it says the message to "Act on your behalf". I just double-checked in our app, and confirmed that these are the only permissions we get:
- Contents - Read-only
- Metadata - Read-only
- Email addresses - Read-only
We agree that we shouldn't take write access if we are not writing PRs. Hopefully that helps!
Great callout! I think it's similar, but our approach is a bit different from Devin's because we're currently focusing less on autonomy.
It looks like Devin chooses a plan and then writes and runs the code or uses the internet to get feedback on how to change the plan/code accordingly.
We focus on having the engineer work with the AI on the plan before writing the code, and the engineer is responsible for the final implementation.
We found that doing everything autonomously was awesome when it worked but frustrating when it didn't; so we wanted to make the UX interactive enough to be useful even if the AI gives some unexpected results. Does that help?
This allows you to give coding agents IDE-like `go to definition` and `find reference` capabilities, or to build code graphs for RAG.
Interactive demo here: https://demo.lsproxy.dev/
How it works:
1. Start the container with the code mounted. 2. The container starts and configures preinstalled language servers (currently support Python, Typescript/Javascript, and Rust) based on the code mounted in. 3. Incoming requests get routed to the correct language server. 4. The output from the language server is cleaned and standardized for the end user.
There are two main challenges we’re solving for:
1. Each server has different, poorly documented configuration settings, making testing difficult. 2. The protocol they adhere to (Language Server Protocol) is lenient, allowing behavior to differ between servers, and the protocol itself is geared towards visual IDEs and mouse cursors.
We built this because we’ve been working on AI code search and generation, spent a ton of time building coding-specific tools for our agents, and noticed everyone else in the space was building the same tools. We’re solving code navigation first, but we are excited to expand this to a complete development environment for AI agents to plug into.