Building an AI-native editor from scratch

Grant Hinkle
architecture electron editor

When we started building Nimbalyst, the obvious path was to fork VS Code or build an extension. We chose not to, and here’s why.

The problem with bolt-on AI

Most AI coding tools today are extensions or plugins to existing editors. They sit in a sidebar, they get limited context, and they can’t truly change the editing experience. They’re guests in someone else’s house.

We wanted AI to be a first-class citizen — not an add-on, but a foundational part of how the editor works. That meant building from scratch.

Multi-editor architecture

Nimbalyst’s core insight is that different content types deserve different editors. A code file, a diagram, a data model, and a document are all fundamentally different things. Trying to edit them all with a single text editor is like using a hammer for every job.

Each file type in Nimbalyst gets its own purpose-built editor:

  • Code files get a full code editor with syntax highlighting, LSP, and AI inline edits
  • Excalidraw files get the native Excalidraw canvas
  • Data models get a visual schema designer
  • Mockups get a live HTML preview with AI generation

All of these editors share the same AI context. The AI can see your code and your diagrams and your data models, and reason across all of them.

What’s next

In upcoming posts, we’ll dive into the specifics of how we handle AI context across file types, our approach to real-time collaboration, and the extension system that lets anyone add new editor types.