Agentic Coding Has A HUGE Problem

Agentic coding is making it dramatically easier to build multiple things at once—but the day-to-day UX breaks down when those parallel tasks spill across separate apps, ports, and browser sessions. The result is a new kind of friction: debugging and even basic navigation become harder than the coding itself, especially when long-running agent jobs finish without clear context about which project, terminal, or localhost port they belonged to.

The creator describes a typical single-project workflow: one editor, one browser tab set (often including localhost and GitHub), and one terminal with dev-server and git tooling. That setup works because everything maps cleanly to one mental model—terminal, editor, and browser all belong to the same project. The trouble starts when two or more projects run concurrently. Switching between terminals, browser windows/tabs, and IDE contexts becomes unreliable and slow. On macOS, moving work across “desktops” (virtual desktops) can cause focus flicker, incorrect tab switching, and sluggish navigation. Even when the mechanics are technically possible, the workflow becomes “unusable” in practice because the user must constantly re-orient: which terminal window is running which project, which browser tab corresponds to which repo, and where the right GitHub context lives.

As agentic tools increase parallelism, these problems compound. Long agent runs—such as Codex jobs taking one to two hours—mean the user can’t just wait in one place; they end up juggling multiple branches, worktrees, and projects simultaneously. Notifications from background workflows (“ding” when a Cloud Code workflow finishes) don’t tell the user where the job ran. The user then hunts across terminal tabs to find the right project, discovers which localhost port was assigned, and only then realizes that authentication and redirects are broken because the app expects a different port. A concrete example: project A and project B end up on different localhost ports (e.g., 3000 vs 3001), causing OAuth/sign-in redirects and cookie/session behavior to fail until the correct dev server is restarted with the expected port.

The pain isn’t limited to window switching. Localhost itself introduces cross-project coupling: browser storage under localhost is shared across ports, so multiple services can overwrite cookies and break each other. Redirect logic tied to specific ports or production domains also becomes fragile when several local apps run at once. The creator argues that common “fixes” like terminal multiplexers (e.g., tmux), orchestration GUIs, IDE-integrated browsers, or Docker don’t solve the core issue: the editor/terminal/browser split remains, and the user still has to manage identity, ports, and context across separate surfaces.

A key hypothesis follows: the hype around background agents likely grows because parallel work is so hard locally. Cloud-style “run in the background” features may reduce local terminal pressure, but they often just shift complexity into the browser and can generate stale pull requests that no one revisits. The creator’s bottom line is a call for experimentation rather than a single silver bullet—build new workflows, hit these UX failure modes, and iterate on solutions. The next step hinted at is a major environment change (Linux), framed as a UI that may fit the parallel-work problem better, though the details are deferred to a future video.