Why the IDE needs to be reimagined(codestory.ai)
codestory.ai
Why the IDE needs to be reimagined
https://codestory.ai/blog/reimaginging-the-ide
29 comments
> Working on proprietary software means if AI doesn’t run locally, it doesn’t run.
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!
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!
> AI assistants generating code are like senior engineers with only a notepad.
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
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
Hi I am the cofounder of CodeStory!
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.
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.
The article does not answer its own question. Why does the IDE need to be reimagined? Apparently "because AI".
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.
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.
Hey! Author here. That's actually a fair point — in hindsight, I see why the article comes off as 'because AI' and not having clear articulations on how the developer experience changes. The current set of changes we have are indeed incremental additions.
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.
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.
I'll just have to guess the reimagined IDE is not longer very text-centric given that without proprietary JavaScript the page is just a green background.
Not yet, but I'd expect we'll eventually get there. Code always remains the source of truth and thus will have its place in every IDE for finer control, but I imagine shifting our primary interaction with code from the editor panel to an agent controller can become a powerful models once these agents become very good. A neat way to think about this is code reviews.
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.
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.
Hey all!
We are building CodeStory, an AI powered mod of VSCode and wanted to share our thoughts and vision on what the future of IDE's will look like.
We have some open questions about how we will get there, and would love your opinion and thoughts on this.
Reminds me of Cursor. What do you feel are your important differentiators from them?
Cursor looks very much in the ballpark and have done a good job. For us, the most important thing is not just code completion or talking with your code (there are many other tools that can do that), but giving the AI agent the freedom to Cmd+Click, Ask for References, all those things that we do in the editor.
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.
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.
Programmable code editors and IDEs aren't the same thing.
100%. I'd like to hear your thoughts on this, but it's possible to argue that IDEs are purpose built and a lot more powerful for programming. This is exactly where we think building the right tooling would allow us to give an IDE-like experience for AI models to perform the same kind of tasks a developer is able to today with IDEs.
only one of the things you instance (goland) actually seems to be an IDE - the others are text editors with plugins. arguably goland is too.
Hey! I'm the author of this post and this is certainly true! Jetbrains products are certainly the most powerful IDEs in the list due to the amount of custom tooling they've built for each language/framework and provide a great development experience out of the box.
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).
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).
Did you look much into Emacs and its huge variety of packages?
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.
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.
Thanks for this! I've personally never used Emacs but I'm definitely taking a look now. A wild idea we have is to make the interface between AI and dev tools extensible, because we can't potentially build a fine-tuned integration for the full world of developer tools. But if developers are interested and they see the benefit of getting AI to handle these tools for them, they can probably work on implementing the interface and let AI take over.
(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)
(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)
Have you done your literature review?
not yet, do you have any feedback for us?
I'm not the OP, but a word to the wise: 99% of the time that people decide to reimagine something to make it more powerful and advance the state of the art, they leave out important features from previous technology, which "mysteriously" then hampers adoption (and drives some adopters crazy who have those missing features in their needs/workflow)
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.
Someone instantly down modded this? That's just weird.
weird.. but I do want to reply to your quesiton.
> 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!
> 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!
Makes sense. I wish you luck on all this!
sounds like you're asking for users to do your unique research for you.
Hey! sorry if it came off that way.
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.
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.
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.