An AI IDE is a code editor with an agent built in, so the agent can read your files, run commands and change code without you leaving the window. I built one, then killed it about three months after starting. A chat panel in an editor turned out to be the one part of an AI IDE not worth owning, and the SDK underneath broke before I could prove otherwise.
What I set out to build
In August 2026 I started a distribution of Eclipse Theia, an open-source editor platform, where the Contenox agent engine was the core. Not a panel bolted onto someone else’s editor.
I had used Antigravity IDE v1 myself, before Google pivoted towards the 2.0 desktop app. Its editor with an Agent Manager next to it was my quality bar.
The reason I did not write a VS Code extension is in VS Code’s own product.json. It names its chat agent at build time: defaultChatAgent points at GitHub.copilot. The proposed chat APIs, such as chatSessionsProvider and defaultChatParticipant, are granted per extension ID by that file, and extensionEnabledApiProposals is empty in the open-source build. A third party cannot be granted them.
So an extension is another participant in someone else’s chat. It sits in their session list, behind their approval widgets and their model policy, next to their default agent. It can add a capability. It cannot be the agent.
The size of what you would plug into says the same. At the checkout I inspected on 2026-10-03:
| Part of VS Code | Files | Lines |
|---|---|---|
extensions/copilot | 2,583 | 660,437, declaring 68 proposed APIs |
src/vs/workbench/contrib/chat | 1,546 | 600,776 |
Theia has no such wall. Its AI stack is 26 ai-* packages among 81 at version 1.76, and each application picks its own in its package.json. There is no default-agent constant. Being the default agent is isDefault?: boolean on your own class.
One thing I never confirmed: Theia’s chat and language-model bridge is about 687 lines, and I did not verify that streaming, diff and approval rendering hold up under a real extension. That part was designed, not proven.
I had been here before. The earlier Contenox VS Code extension bundled the engine and spoke JSON-RPC over stdio with 18 client-to-agent methods and around 35 palette commands. It was good work, and it was still a guest in Copilot’s house.
What would move to the host
Owning the editor meant I could delete code. The engine-boundary notes from 3 October record the rule: the host supplies the environment, the engine supplies the work.
| Moves to the host | Lines |
|---|---|
beam, the terminal UI | 33,331 |
| Environment half of the local tools | 17,102 |
| Language intelligence | 7,534 |
| Virtual filesystem, in the local case | 6,099 |
| Shell and process services | 2,766 |
What stayed as the product: the task engine (24,165 lines for the kernel, 14,470 of them the task engine itself), agent declarations (9,099), approvals (8,933), unattended work, model serving, and the sandbox for foreign agent code. Approvals have to survive a restart. An agent waiting for a human must not lose its place when the window closes.
The decision on 3 October 2026
Writing the curation notes forced a question: what does the IDE do that the terminal client does not? My answer that day: a distribution that adds a chat panel to an editor is not worth shipping. The terminal client already carries the conversation, in the place the work happens, and does it better.
Only three things justified owning the surface. All three are things a terminal cannot do:
- Completions in the editor. The engine already served fill-in-the-middle completions; the editor supplies the inline surface.
- Retrieval over the workspace. A search over a local index that stays current as files change.
- The editor’s own events reaching the engine. Open files, cursor, diagnostics. They flow from editor to agent, a direction a terminal cannot supply at all, and they make the agent’s context live instead of pasted.
Missions, approvals and evidence followed from those three. Conversation was where a result might show up. It was not the product.
Why I killed it
I killed it when I saw it was broken. The SDK it was built on top of was broken, by an AI agent. Redoing it now would give a fixed version quickly.
I did not redo it. When I posted about the IDE, I got zero signal.
So instead of continuing on a broken SDK, I forked my own code from 40 days earlier. I took what I had learned about building desktop apps and releases, and used it to ship what Contenox is now: a desktop app, Windows first.
There was an economic reason underneath the technical one. An editor with completions on every keystroke only pays for itself with a local model: the IDE needed modeld, our local inference daemon, serving fill-in-the-middle from the user’s own GPU, or every keystroke would have been a billable request. modeld is not dead either; I can’t afford to build and test it right now, and it belongs as an extension rather than something bundled. The enterprise tree is not dead. Its event-driven multi-agent workflows and other parts will be harvested later.
The market made the same move
Google is narrowing the Antigravity IDE and moving multi-agent work into the 2.0 app. An upcoming IDE release removes the agent manager, and the IDE is not supported for enterprise accounts as of October 2026. Details: Google Antigravity. Windsurf, after Cognition bought it, became Devin Desktop on 2 June 2026, with an agent command center as the default view instead of the editor. Cursor stays an editor, with its agent in a side pane.
If there is ever an editor again
It will be closer to Sublime than to VS Code or Theia. A remote file viewer. Something like Notepad++ built on Monaco. Maybe language-server support. A proper git review workflow. No magic features.
What to use instead
If you want an AI IDE, these are the ones to look at, as described on their own pages.
| Tool | What it is | Pick it if |
|---|---|---|
| Cursor | Editor with an agent in a side pane and its own Tab completion | Completions and inline edits are why you open it. See Cursor alternatives |
| Antigravity IDE | Google’s editor with an agent manager | You already use it. Google is narrowing it, so read the Antigravity page first |
| Zed | Editor with its own agent, open edit predictions, and external agents over ACP | You want your own API keys or a local model through Ollama |
| VS Code with Copilot | The editor where Copilot holds the chat seat | You want to stay in VS Code; other agents plug in as extensions |
| JetBrains | IDEs with AI Assistant, which can run ACP agents | You already live in an IntelliJ-family IDE |
| Kiro | Development environment with specs, steering and hooks, one agent behind IDE and CLI | You want a written plan before the code |
Most of these end up in the same place I did: the editor is the editor, and the agent is a separate thing it talks to. The protocol for that is ACP. The agents that never had an editor are in terminal coding agents.
What this does not solve
- Completions and live editor context are real. If you want an agent that sees your cursor and diagnostics, a terminal does not give you that. Cursor and Zed do.
- My evidence is one product. I stopped it on a broken SDK and no signal. That says something about my situation, not about the whole category.
- The Theia path was never finished. The claim that one extension could ship inside Theia and in VS Code was a design, not something I ran.
Contenox
Contenox is a desktop app for coding agents, Windows first, with permission rules you can read per project. It is what I shipped instead of an IDE. Download it here.
Related guides
- Google Antigravity: the IDE, the CLI and the 2.0 app, and which one has a future
- Cursor alternatives: what to keep and what to swap if the editor is the point
- Agent Client Protocol (ACP): how an agent plugs into any editor
- Terminal coding agents: the shape I kept