andrewpareles

I think a good use of time while waiting for an LLM is to ask another LLM for something. Until then Slack will do :)

This is completely true, and it's a really common objection.

I don't imagine people will want to fully visualize codebases in a giant unified diagram, but I find it hard to imagine that we won't have digests and overviews that at least stray from plaintext in some way.

I think there are a lot of unexplored ways of using AI to create an intelligent overview of a repo and its data structures, or a React project and its components and state, etc.

I should have been more careful with my wording - I was talking about major VS Code-based IDEs as alternatives. Zed is very impressive, and we've been following them since before Void's launch!

Thanks for writing! Can you try mentioning the file with "@"? Smaller models sometimes don't realize that they should look for files and folders, but "@" always gives the full context of whatever is in the file/folder directly to them.

Small OSS models are going to get better at this when there's more of a focus on tool-use, which we're expecting in the next iteration of models.

Just want to share our thinking on terminal-based tools!

We think in 1-2 years people will write code at a systems level, not a function level, and it's not clear to us that you can do that with text. Text-based tools like Claude Code work in our text-based-code systems today, but I think describing algorithms to a computer in the future might involve more diagrams, and terminal will not be ideal. That's our reasoning against building a tool in the terminal, but it clearly works well today, and is the simplest way for the labs to train/run terminal tool-use agents.

Yep, Void is a VSCode fork, but we're definitely not wed to VSCode! Building our own IDE/browser-port is not out of the picture. We'll have to see where the next iteration of tool-use agents takes us, but we strongly feel writing typescript/rust/react is not the endgame when describing algorithms to a computer, and a text-based editor might not be ideal in 10 years, or even 2.

We considered Theia, and even building our own IDE, but obviously VSCode is just the most popular. Theia might be a good play if Microsoft gets more aggressive about VSCode forks, although it's not clear to us that people will be spending their time writing code in 1-2 years. Chances are definitely not 0 that we end up moving away from VSCode as things progress.

Agreed - this is one of the better solutions today.

This is a good point.We've stayed away from documentation assuming that it's more of a browser agent task, and I agree with other commenters that this would make a good MCP integration.

I wonder if the next round of models trained on tool-use will be good at looking at documentation. That might solve the problem completely, although OSS and offline models will need another solution. We're definitely open to trying things out here, and will likely add a browser-using docs scraper before exiting Beta.

Thanks for the feedback. We'll definitely add a feature list. To answer your question, yes - we support Cursor's features (quick edits, agent mode, chat, inline edits, links to files/folders, fast apply, etc) using open source and openly-available models (for example, we haven't trained our own autocomplete model, but you can bring any autocomplete model or "FIM" model).

We don't have a repomap or codebase summary - right now we're relying on .voidrules and Gather/Agent mode to look around to implement large edits, and we find that works decently well, although we might add something like an auto-summary or Aider's repomap before exiting Beta.

Regarding context - you can customize the context window and reserved amount of token space for each model. You can also use "@ to mention" to include entire files and folders, limited to the context window length. (you can also customize the model's reasoning ability, think tags to parse, tool use format (gemini/openai/anthropic), FIM support, etc).

Interesting, thanks for sharing! We planned on spinning up a new Git branch and shallow Git clone (or possibly worktree/something more optimized) for each agent, and also adding a small auto-merge-with-LLM flow, although something more granular like this might feel better. If we don't use a versioning tool like JJ at first (may just use Git for simplicity at first), we will certainly consider it later on, or might end up building our own.

We think terminal tools like Claude Code are a good way for research teams to experiment with tool use (obviously pure text), but definitely don't see the terminal as the endgame for these tools.

I know some folks like using the terminal, but if you like Claude Code you should consider plugging your API key into Void and using Claude there! Same exact model and provider and price, but with a UI around the tool calls, checkpoints, etc.

Continue is doing great work, but they're an extension (plugin)!

Yes, you can bring OpenRouter or any other provider and connect directly! (We don't route your messages through a backend like others).

Void dev here! The biggest players in AI code today are full IDEs, not just extensions, and we think that's because they simply feel better to use by having more control over the UX.

There are certainly a lot of alternatives that are plugins(!), but our differentiation right now is being a full open source IDE and having all the features you get out of the big players (quick edits, agent mode, autocomplete, checkpoints).

Surprisingly, all of the big IDEs today (Cursor/Windsurf/Copilot) send your messages through their backend whenever you send a message, and there is no open source full IDE alternative (besides Void). Your connection to providers is direct with Void, and it's a lot easier to spin up your own models/providers and host locally or use whatever provider you want.

We're planning on building Git branching for agents in the next iteration when LLMs are more independent, and controlling the full IDE experience for that will be really important. I worry plugins will struggle.

Void dev here! As others have mentioned, VSCode strongly limits the functionality that you can build as an extension. A few things we've built that aren't supported as an extension: - the Accept|Reject UI and UX - Cmd+K - Control over the terminal and tabs - Custom autocomplete - Smaller things like ability to open/close the sidebar, onboarding, etc

It's been a lot harder to build an IDE than an extension, but we think having full control over the IDE (whether that's VSCode or something else we build in the future) will be important in the long run, especially when the next iteration of tool-use LLMs comes out (having native control over Git, the UI/UX around switching between iterations, etc).

> I’d love a good summary on why Cursor, Void (and I assume other tools) decided to build new editors instead of just extending the incumbents (VSCode extension, Jetbrains plugins).

This is a great question. We think extensions are often buggy (e.g. Copilot, where the selection jumps), or unable to integrate very naturally (e.g. Codeium, other open source extensions). For example, a lot of extensions use the quick pick dropdown for the user to enter a prompt, which feels unnatural. Owning the IDE like Cursor is important to get around these issues, and we think this is why Cursor is so popular.

> While adoption for individuals and small companies might be easy, a lot of bigger places already have other integrations with existing IDEs and displacing those for yet another IDE will be a hard ask

You're right about IDE adoption. We want to build on top of an already-popular to help us reach smaller players, and hopefully we can win over larger companies in the long run with privacy and by centralizing nice AI features.

Hey, great question - you're right, extensions are more accessible - the thing is, there is no great way to build the native UI we'd want using them. For example, displaying the before-and-after is vital for us, and doesn't feel natural in an extension.

Extensions like Codeium do the most naive thing possible by writing something like <<<<<<< DIFF >>>>>>>> in your file, literally breaking syntax highlighting. Others like Copilot are super buggy.

Right now Void is built on top of an extension, but we're also modifying and hooking into parts of the IDE to make a more native UX.

Thanks for sharing! If Theia is built on top of monaco, I wonder if a form of one-click switch might work. The monaco editor is theoretically part of the vscode repo, while the "workbench" with settings/configs lives one layer up.

Pear consists largely of a VS Code extension built on top of Continue.dev's VS Code extension. We're building a more native integration into the VS Code editor, similar to Cursor. Is there anything you like about Pear that Cursor doesn't offer?

Great question - we're doing a VS Code clone to have access to features like language servers, debugging, extensions, etc - these are really annoying to build from scratch. We also think it's nice for users to just be able to do a one-click switch from VS Code to Void, and hard to win over Cursor users without it. I'm curious about how you're building your editor - are you building everything from scratch?

We really like about on-prem models as well - it definitely seems they will get comparable and win over paying for API credits.

Will make the first batch of releases ASAP!