Summary of "Everything needs to change"

Overview

Thesis: The shape of developer tooling must change again. Current editors/IDEs and terminal-based UIs (and emerging CLI/agent tools) are insufficient for the multi-project, agent-driven workflows that are becoming common.

The presenter argues for a “bigger IDE”: an orchestration layer that holds multiple projects, terminals, browsers, agents and contexts together—rather than many isolated windows, tabs, or single-project IDE instances.

Historical context (how we got here)

Text editors → IDEs: editors incorporated compilers, linters, test runners, debuggers, etc., creating the “IDE” concept (Visual Studio, Xcode, Eclipse).
Sublime Text: a fast, minimal native editor with an extensions ecosystem.
Atom + Electron: introduced a cross-platform, extensible web-based editor approach.
VS Code: Microsoft’s highly successful, extensible editor that popularized shaping the editor to a codebase (workspace settings, integrated test play buttons).

AI and editor evolution

Copilot and newer tools (Cursor, agent integrations) changed editor UX: sidebars, large UI surfaces, agent modes and dynamic layouts have altered the editor’s role and introduced more chaotic interfaces.
CLI/agent tools (Cloud Code, Codeex, terminal-first agents) are powerful because everyone has a terminal—but shrinking interfaces toward CLI-only isn’t presented as the only or best path.

Problems identified

Multi-project and agentic workflows
- Agents can run concurrently for many projects; developers often work across multiple projects in parallel. A 1:1 project-to-editor relationship is limiting.
Context fragmentation
- Code, terminals, browser tabs, dev servers, GitHub pages and agent runs are scattered across apps. Mapping which terminal or browser tab belongs to which repo or workspace is error-prone and cognitively expensive.
Editor UI complexity
- Sidebars and dynamic UIs (e.g., Cursor, Copilot) can become chaotic and obscure context and navigation.
OS-level workspaces are inadequate
- Existing virtual desktop/workspace features don’t solve the app-level orchestration problem; the fix can be at the application level.
Legacy design assumptions
- Current tools were built for earlier workflows and don’t easily support orchestrating many simultaneous contexts/agents.

Proposed direction: “Bigger IDE” / Desired features

An orchestration-first app that:

Manages multiple projects/workspaces simultaneously, with easy hopping between contexts.
Contains browser instances tied to each workspace so agents can use real browsers with secrets/OAuth.
Integrates terminals, editors, test runners, debuggers, agent consoles and web previews in a single orchestrated UI.
Lets you group/label named “spaces” for projects with their own tabs/terminals/browsers.
Supports multi-dimensional canvases (zooming out, arranging nested spaces, visual layout/navigation across projects).
Exposes agent orchestration primitives (run agents, view agents’ browser sessions, pass secrets safely).
Keeps native developer tooling quality (type safety, debugging experience).

The presenter stresses this is an open design problem—solutions might also emerge at the OS level or via automated Slackbot-like workflows.

Products, demos, and examples mentioned

Kernel (sponsor)
- Cloud browser + managed OAuth for agents.
- Demo: ~70 lines of code to sign in via Kernel-managed OAuth, handle 2FA, let cloud browser access private GitHub repos, and reuse profiles across instances. Shows that giving agents a real browser + credentials improves capability.
VS Code
- Praised for shaping itself to a repo (workspace config) and showing integrated features (e.g., test play buttons).
Copilot and Cursor
- Examples of AI features reshaping editor UIs; Cursor’s frequent UI rearrangements illustrate the UI complexity problem.
T3 Code
- A start toward the “bigger IDE”; features include terminal workspaces and early-stage multi-project orientation. Missing horizontal scroll, multiple chats, built-in browser. Julius (contributor) focused on terminal and app ergonomics.
Semox (lib-ghosty fork)
- Demo video showing multi-space UI with an embedded browser and terminal per space—moving toward a single-app multi-space workflow.
Create T3 App / T3 Stack
- Prior work by the presenter assembling fullstack TypeScript tooling; used as a precedent for building opinionated tooling.

Practical notes and recommendations

Try agents and experiment: spin up agents and prototypes to explore UI/UX patterns for multi-project orchestration.
Use T3 Code now if you want to experiment with multi-project tooling, but expect the space to evolve quickly.
There is a large opportunity to design editor/orchestration UIs for agentic development—many will be tried and many will fail; rapid experimentation is encouraged.

Reviews / guides / demos to check

Kernel demo (cloud browser, OAuth/2FA, private GitHub access) — working example; ~70 lines to integrate.
VS Code test-runner feature — the small play button next to unit tests cited as a decisive UX for switching editors.
Semox / lib-ghosty demo — shows named spaces with embedded terminals and browsers.
T3 Code — early-stage product; praised for terminal features and multi-project thinking but still missing several UX pieces.

Uncertainties and alternative paths

The “bigger IDE” may not be the final answer. Alternatives include:
- OS-level solutions that better manage app-level contexts.
- Slackbot/agent-first automation that hides orchestration entirely.
- Other paradigms not yet imagined.
This is a nascent design problem with no final answer; many attempts and iterations are expected.

Main speakers and sources

Video narrator / presenter (creator of the T3 stack and T3 Code).
Andrej Karpathy (referenced as an inspiration/provocateur pushing for a “bigger IDE”).
Kernel (sponsor and demo provider).
T3 Code and Julius (project and contributor).
Semox / lib-ghosty (demoed multi-space UI).
Microsoft / VS Code, GitHub / Atom, Sublime Text, Electron (historical/tooling context).
Copilot and Cursor (AI editor tools discussed).