Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update the-self-driving-ide-is-coming.md #6944

Merged
merged 1 commit into from
May 15, 2024
Merged

Update the-self-driving-ide-is-coming.md #6944

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion content/blogposts/2024/the-self-driving-ide-is-coming.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -119,7 +119,7 @@ The historical driver for our protocol design was that we wanted the VS Code Cod

To make a very long story short, what we came up with is probably closest in spirit to LSP. Our Cody client backend acts a bit like an advanced LSP server, but instead of serving up code intelligence metadata, it mediates interactions with the AI.

The fastest approach for the VS Code Cody team was to code directly against [VS Code’s API](https://code.visualstudio.com/api/references/vscode-api), without worrying about some intermediate facade that we’d be building in parallel for other clients. So the Cody platform engineers, led by the inimitable , didn’t bother with an intermediate parallel API. They just made VS Code’s API the platform.
The fastest approach for the VS Code Cody team was to code directly against [VS Code’s API](https://code.visualstudio.com/api/references/vscode-api), without worrying about some intermediate facade that we’d be building in parallel for other clients. So the Cody platform engineers, led by the inimitable Olaf Geirrson, didn’t bother with an intermediate parallel API. They just made VS Code’s API the platform.

A good extension API should be general. It should be able to hook into just about anything the IDE can do, augment or change it, and bring entirely new functionality altogether, possibly in novel ways suitable to the new domain. Nearly all IDEs have an extension API that can do all these things, and as such could have been our design archetype. But nearly all of them made decisions, both in their APIs and in their extension languages, that [haven’t aged all that well](https://docs.oracle.com/javase/tutorial/uiswing/).

Expand Down
Loading