Why IDEs Won't Die in the Age of AI Coding: Zed Founder Nathan Sobo

Nathan challenges the 'death of the IDE' narrative, arguing that source code is fundamentally a language for humans to read and understand. He explains why visual interfaces remain necessary even with AI coding tools, citing Harold Abelson's principle that programs should be written for people to read and only incidentally for machines to execute.

• •Terminal-based AI tools like Claude Code are limited when reviewing code context beyond small excerpts
• •Source code is a synthetic language optimized for human understanding, not just machine execution
• •Until AGI, humans will need to interact with and understand source code, requiring visual interfaces
• •Even heavy users of terminal AI tools likely run editors alongside to inspect what's happening

Nathan recounts his nearly two-decade journey building IDEs, starting with Atom at GitHub in 2006. He explains how Atom pioneered web-based IDE architecture using Electron, but ultimately hit performance ceilings that led him to start over with Zed in 2017 using Rust and GPU acceleration.

• •Atom was built on Electron (originally created for Atom) to enable extreme extensibility via web technology
• •Microsoft copied the approach with VS Code, which eventually dominated the market
• •Performance is not a feature you can add later—architectural choices determine performance capabilities
• •Web browsers proved unsuitable for the ultimate IDE vision due to fundamental performance limitations
• •Zed achieves near-zero perceptible lag through Rust and GPU-accelerated rendering of the entire UI

Nathan critiques the industry's asynchronous, git-based collaboration model popularized at GitHub, arguing for more real-time, synchronous collaboration directly in code. He explains how Zed was designed to enable Figma-style presence and collaboration for developers, which becomes even more relevant with AI agents.

• •Git-based workflows are asynchronous and email-oriented, appropriate for distributed teams but limiting for tight collaboration
• •The best collaboration happens in real-time in the code, not through delayed PR comments on snapshots
• •Screen sharing for pair programming puts one person in the passenger seat due to keystroke latency
• •Zed's team prefers real-time code discussions over traditional code review processes
• •Linking conversations directly to code in the authoring environment (like Figma for designers) was a core vision

Nathan describes the need for fine-grained tracking of every edit and keystroke to enable permanent, contextual conversations with AI agents. He explains how git's snapshot-based model breaks down when collaborating with agents that stream edits continuously, requiring a new 'commit on every keystroke' paradigm.

• •Conversations with AI agents happen continuously in code, not in delayed PR reviews
• •No git-equivalent exists for tracking and discussing individual agent edits as they stream in
• •Zed is building infrastructure for 'commit on every keystroke' to anchor conversations to specific edits
• •The goal is permanent storage of feedback given to agents, creating a metadata backbone for code
• •This enables LLMs to query 'what conversations happened behind this code' for better context

Nathan explains the Agent Client Protocol (ACP) that positions Zed as a neutral platform for different AI coding agents, similar to how Language Server Protocol democratized IDE intelligence. He discusses partnerships with JetBrains and various agent developers to externalize agent competition while Zed focuses on providing the best UI.

• •ACP mirrors the Language Server Protocol's success in externalizing IDE intelligence to communities
• •Different agents will specialize in different domains and compete, requiring a neutral IDE platform
• •JetBrains adopted ACP despite being a theoretical competitor, validating the approach
• •Zed continues building its own first-party agent while supporting all agents through ACP
• •Terminal-based agent experiences need to be supplemented with proper editors for code review

Nathan shares successful vibe coding experiences, including building a Cloudflare API simulator and generating Rust procedural macros for Tailwind CSS integration. He describes LLMs as 'knowledge extruders' that excel at taking well-known patterns and reshaping them to specific needs, while being less helpful for novel algorithmic challenges.

• •Generated a complete Cloudflare API simulator in an afternoon by feeding API docs to an agent
• •Created Rust procedural macros for Tailwind CSS integration without knowing macro syntax
• •LLMs excel at extracting knowledge from their training distribution and reshaping it to your needs
• •Vibe coding works best when you have a clear vision but lack time to implement or specific technical knowledge
• •The key is using generated code directionally while being aware of its limitations and potential issues

Nathan discusses limitations of current LLMs when working on novel problems like Zed's Delta DB system for fine-grained edit tracking. He explains that when the constraint is thinking through complex architectural decisions rather than writing code, LLMs provide less value, though they remain useful for exploring ideas.

• •LLMs struggle with novel architectural problems that require holding multiple constraints simultaneously
• •For Delta DB work, the challenge is thinking through the right approach, not writing the code itself
• •Still uses LLMs to explore ideas and generate exploratory code to 'see how it feels'
• •Pride in writing fewer, more precise lines of code rather than generating maximum volume
• •Speed improvements (like Haiku) could shift the value proposition by enabling instant diff generation

Nathan shares metrics showing about 50% of Zed's 170,000 active users use edit prediction and 25% use agentic editing. He describes the user base as experienced, hardcore engineers who care about tactile tool performance, while noting that broader audiences may emerge as the full collaborative vision materializes.

• •170,000 active developers use Zed, with ~50% using edit prediction and ~25% using agentic features
• •User base skews toward experienced developers who care about tool performance and craft
• •Seasoned developers notice and care about dropped frames and responsiveness after 40+ hours/week usage
• •Some users opposed AI integration, but Nathan committed to moving toward the future regardless
• •Broader audiences (like the dentist vibe coding practice software) may not yet appreciate performance benefits

Nathan outlines his vision for evolving the IDE beyond the traditional tree-tabs-panel layout toward a conversation-first interface where code becomes a metadata backbone. He describes making conversations editable documents where you can interact directly with embedded code, expand context, and review changes—creating a new kind of editor optimized for human-AI collaboration.

• •Traditional IDE layout (tree left, tabs center, panels right) evolved for one human in one working copy
• •Future involves managing multiple simultaneous conversations with different agents across projects
• •Conversations should be editable documents, not just read-only chat logs
• •Code snippets in conversations should be directly editable and synchronized with actual files
• •Multi-buffer concept allows editing pieces from across codebase as single interface
• •Goal: keyboard-navigable conversation interface that feels like an editor, not just a chat
• •Code becomes a metadata backbone where conversations, edits, and context all hang together permanently