Everything needs to change

AI-assisted coding has accelerated the shift from “helpful typing” to “tool-driven work,” but the next leap likely won’t be more capable sidebars or smarter CLIs. The central claim is that developers need a bigger integrated developer environment—one that orchestrates multiple projects, terminals, browsers, and agent runs inside a single coherent workspace—because today’s patchwork across apps forces constant mental bookkeeping.

The argument starts with how coding tools evolved: autocomplete in editors gave way to sidebars that can steer a codebase, and then to agentic workflows that run through command-line interfaces. Cloud-based coding agents are increasingly practical because terminals and shells are universal entry points. Yet the push for “smaller, deeper” tooling misses the bigger mismatch: modern agentic development changes how work is structured. Instead of one project at a time, agents can run for hours while developers juggle many tasks simultaneously. That breaks the old assumption behind IDEs, where a project-to-window relationship made sense.

Historically, IDEs grew because editors alone couldn’t manage the full toolchain—compilers, type checkers, linters, test runners, and deployment steps. The transcript traces that evolution through the rise of extensible editors and then the dominance of VS Code. Sublime Text represented a minimal, fast editor with a community extension ecosystem. Atom pushed extensibility further using Electron and Chromium, and VS Code followed with a similar architecture but a more polished, performance-focused approach. A personal turning point is described: unit test “play” buttons and repository-specific configuration in VS Code made the editor adapt to a codebase in a way that felt hard to replicate elsewhere.

But as AI features like Copilot and agent-driven interfaces reshape editor behavior, the UI becomes chaotic and—more importantly—the hierarchy stays wrong. IDEs still treat the editor as a container for a single project’s concerns (debugging, running, git workflows), while real work now spans multiple projects and long-running agent sessions. The result is “agentic coding” pain: work gets split across terminals, browser tabs, and editor windows, and developers must constantly map which git tab, workspace, and browser context correspond to the code they’re viewing.

The proposed fix is not necessarily a single product, but a new class of orchestration layer: an IDE that manages codebases as first-class objects and links the terminal, browser, and agent activity together so navigation and context switching become automatic. The transcript points to experiments like Semox (built on lib ghosty) that allow multiple spaces with their own terminals and browsers, but argues the direction needs to go further—toward an infinitely nestable, multi-dimensional canvas where projects and their tools can be arranged and navigated without losing track.

The takeaway is a call to action: no one has the final shape of the next decade’s editor figured out. As agentic development grows, the demand for tools built for orchestration—not just editing—will rise. The speaker frames this as a window of opportunity similar to earlier tool transitions in software history, urging builders to prototype with agents and iterate quickly, even if today’s solutions (including T3 Code) are only stepping stones.