Why the IDE needs to be reimagined
codestory.ai
codestory.ai
I kid, but only a little. Working on proprietary software means if AI doesn’t run locally, it doesn’t run. And it doesn’t offer (me) something worth fighting bureaucracy for.
100% agree with you on this.
We want to deploy these AI agents locally and also in a self-hosted fashion for enterprise. The way I imagine this to work is the editor will be a shell and just how LSPs are swapped in and out for different languages or work together, there will be APIs exposed for AI to work with, you want an expert Python AI agent..sure here you go, you want something for Rust.. there we go!
Creating a consistent API layer and getting AI agents to work on top of these APIs is a very important step, and we don't want to or plan on being tied down to just OpenAI.
Enterprise and proprietary software requires local AI agents, and with OSS pushing with great speed here I am sure we will get there in the coming months. (I have prototyped with LLAMA2 locally, on my MacBook Air and its okay, but nowhere close to say GPT4), but the early signs are there and we will be providing this as an option for sure going forward!
this is a bad thing?
deciding on data structures, data flows and abstractions to build is the hard bit of being a software developer, which works perfectly well on paper
turning that into the code is the easy bit, with or without a boilerplate generator
In my experience I spend way too much time fixing the output of AI assistants rather than working on the next thing. It slows me down, even after the speed ups.
And generating the right code at first shot is not something I would expect from any engineer (unless we are working with compiled languages), giving access to simple tools like linters and static analysis tools goes a long way, not just for humans but for these AI agents to improve their work.
AI could provide some different views of project structure (not file/folder). AI could use existing IDE tooling?
None of this is a reimagining of the IDE, just some incremental additions to it.
That being said, this is not accidental because we intend to not fundamentally disrupt the core workflows of today right away (as another comment said — IDEs of today are indeed built on years of user experience research). But we do see the capability to simplify or rethink the developer experience once AI is deeply integrated into every workflow. Its perhaps the same way I'd have never stated writing code as a problem, but after having used Copilot, I don't want to go back to not having it.
When I give a task to another developer on the team, they go out to understand the task, work on it, write tests, run everything and put it up for review (which is then also auto-evaluated by CI first). In this scenario, as a reviewer, we already don't have an absolute need to read every line of code as long as high level design/project principles are followed and all scenarios are covered in tests that are passing.
AI agents can become this other developer picking up and completing end-to-end tasks, but rather than taking hours/days, they take a few seconds/minutes at best — so review comments can actually be shared and incorporated quicker within the IDE itself.
Each interaction the user does with the editor needs to be thought out for the AI agent.. I kind of want to tell the AI agent to "follow these code pointers, and figure out how to add a widget on my website" (similar to how you would tell any other engineer in your team).
We want to build a development environment where AI and humans are working together, rather than humans being guided by the AI agent.
We are not there yet, but engineering the editor right now for these AI agents will pay out in the future as the underlying models improve.
But VSCode's approach of having an extension-first architecture is pretty powerful too (in fact, something I learnt only recently is how much of VSCode's implementation is built on the same extension architecture that is exposed for developers to extend the editor).
Edited to add: it's built with a vast amount of Lisp and so much of the application can be live modified at runtime via Lisp. If you want an extensible editor, you can learn a lot from Emacs.
(I'm sorry about the usage of AI so many times haha. I've been staying away from saying LLMs because they're the state-of-the-art today, but that potentially changes as soon as next year)
In this sense it's not just the literature that needs to be reviewed, it's also feature lists (functional at least, and sometimes UI) of prior commercial and open source products.
> In this sense it's not just the literature that needs to be reviewed, it's also feature lists (functional at least, and sometimes UI) of prior commercial and open source products.
Truly agree with you on this. Building a whole new editor today would be a hard battle for us, getting adoption even harder. We went with the route of modding VSCode for the sole purpose to ease market adoption and the foundation which VSCode provides. We don't want to stick here, but see how much we can push the editor.
I don't think the editors in the future will even look like the traditional code editors we have today, if AI can write functions, modules, whole services, would it really be code we will look at or something else (I don't want to use the word no-code here... and also because I don't want to be in that world where I am so far away from the code)
Not sure where we will end up in the future with editors, but I do believe its going to look and behave vastly difference. There will be new workflows for us to learn, and discover as we figure out how these AI agents can complement and help us out, an early sign with copilot is how my code has gone from
``` // comment if I want to {code} {mode_code} ```
to
``` // comment {copilot_generated} // comment {copilot_generated} ```
These are just early behaviour changes, but the future does look pretty interesting!
We wanted to share our initial thoughts on what the future of IDE will look like, in hindsight I can see why it feels that way, but the onus is on us to figure out the research and build it.