To talk through the features, we engineered the following:
- A proactive agent
Agent which iterates on the linter errors (powered by the Language Server) and pulls in relevant context by doing go-to-definitions, go-to-references etc and propose fixes or ask for more files which might be missing in the context.
- Developer control
We encourage you to do edits on top of your coding sessions. To enable this, we built a VSCode native rollback feature which gets rid of all the edits made by the agent in a single click if there were mistakes, without messing up your changes from before.
- A combined chat+edit flow which you can use to brainstorm and edit
You can brainstorm a problem in chat by @’ting the files and then jump into edits (which can happen across multiple files) or go from a smaller set of edits and discuss the side-effects of it
- Inline editing widget
We took inspiration from the macos spotlight widget and created a similar one inside the editor, you can highlight part of the code, do Cmd+K and just give your instructions freely
- Local running AI brain
We ship a binary called sidecar which takes care of talking to the LLM providers, preparing the prompts and using the editor for the LLM. All of this is local first and you get full control over the prompts/responses without anything leaking to our end (unless you choose to use your subscription and share the data with us)
We spent the last 15 months learning about the internals of VSCode (its a non-trivial codebase) and also powering up our AI game, the framework is also at the top of swebench-lite with 43% score. On top of this, since the whole AI side of the logic runs locally on your machine you have complete control over the data, from the prompt to the responses and you can use your own API Keys as well (can be any LLM provider) and talk to them directly.
There’s still a whole lot to build and we are at 1% of the journey. Right now the editor feels robust and does not break on any of the flows which we aimed to solve for.
Let us know if there’s anything else you would like to see us build. We also want to empower extensibility and work together with the community to build the next set of features and set a new milestone of AI native editors.
Do you want to spend 90% of your time on AI or troubleshooting odd Linux VSCode bugs in your fork? I'd highly recommend the team to evaluate a different direction for growth to maximize sustainable future growth.
I would love to know your workflow, you mention CLI tool or VSCode plugin, which one of them work for you? Whats missing from them where Aide can fill in the gap
Having a deeper integration with the editor allows for some really nice paradigms: - Rollbacks feel more native, in the sense that I do not loose my undo or redo stack - cmd+k is more in line with what you would expect with a floating widget for input instead of it being shown at the very top of your screen which is the case with any extension for now.
Going further, the changes which Microsoft are making to enable copilot editing features are only open to "copilot-chat" and no other extension (fair game for Microsoft IMHO) So keeping these things in mind, we designed the architecture in a way that we can go towards any interface (editor/extension). We did put energy into making this work deeply with the VSCode ecosystem of APIs and also added our own.
If the editor does not work to our benefit, we will take a call on moving to a different interface and thats where an extension or cloud based solution might also make sense
https://github.com/codestoryai/aide
https://aide.dev/
So just taking these things for face value, I think there is lots to innovate. No editor (bias view of mine) has really captured the idea of a pair programmer working alongside you. Even now the most beloved feature is copilot or cursor tab with the inline completions.
So we are ways further from a saturated market or even a feature set level saturation. Until we get there, I do think forks have a way to work towards their own version of an ideal AI native editor, I do think the editors of the future will look different given the upwards trend of AI abilities.
I had this feeling for the first time with Cline. It adjusted the code, accessed the terminal, rebuilt the image, ran the container, saw an error, suggested new edits, ran again... All while only asking for a few confirmations. And it's very verbose: it tells you with details what it's doing every step of the way.
But I migrated to the new Copilot a few days ago because I was easily spending $5 in a day.
For the people comparing to Cursor on features, I suspect the winner is going to be hard to articulate in an A:B comparison.
There's such a difference in feel that may be rooted in a philosophy, but boils down to how much the creator's vision aligns with my own.
- arm64 build: https://github.com/codestoryai/binaries/releases/download/1....
- x86 build: https://github.com/codestoryai/binaries/releases/download/1....
> There's such a difference in feel that may be rooted in a philosophy, but boils down to how much the creator's vision aligns with my own.
Hard agree! I do think AI will find its way into our productivity tool kit in different ways. There are still so many ways we can go about doing this, A:B comparison aside I do feel the giving people to power to mold the tool to work for themselves is the right way.
Since they perform vastly different functions (the above is a replacement for tripwire[2]), it's unlikely anyone will be confused, but be aware that it exists. There's always someone who will mistake one for the other.
[0] https://aide.github.io/
[1] https://en.wikipedia.org/wiki/Advanced_Intrusion_Detection_E...
[2] https://en.wikipedia.org/wiki/Open_Source_Tripwire