It's insane to me that people are still...

The episode begins with a tweet from Theo saying it is “insane” that developers still use terminals to prompt agents, whether for touring, follow-up, or local development, when they could use “orbs.” The host interprets this as an argument for an agent GUI and pushes back from personal experience: he is using a terminal and local development at that very moment. He says there are constantly people insisting that their preferred workflow is obviously superior, while he still has not figured out the right setup. He lists the tools he has recently used, including Amp with orbs, Claude Desktop, Codex Desktop, phone apps, Dot, Grokbot, and Claude Code. He has opened ChatGPT, responded to a Dot notification on his phone, used Grokbot for PDF manipulation related to an email, and used Claude Code for most of his active work. He says he was once “all in” on Claude Desktop and Codex, but after Opus 5.5 he now uses that model for essentially everything and has returned primarily to terminal-based work. His conclusion is not that one interface wins universally: every tool has strengths and weaknesses, and his own setup keeps changing.

The host explains why the terminal currently works better for him. He compares it to a web browser: he opens tabs, does things, moves between them, lets sessions become stale, and eventually closes them. The terminal does not force him to maintain a folder hierarchy or a project taxonomy. Its state is temporary and disposable. By contrast, applications such as Amp, Codex, and Claude Desktop organize sessions around projects. Claude Desktop, for example, shows a LiveWire project with one item and a computer category with another, automatically assigning conversations to places the user may not want to maintain. The host describes himself as a self-proclaimed ADHD worker who becomes enthusiastic about organizing systems, uses them for a week, then allows them to decay into partial chaos. Once that happens, the tool’s organizational features make him feel bad rather than helping him work. He therefore sees categories as “debt”: a promise of order that eventually becomes another system to manage. He connects this preference to Paraphrame, the SaaS application he is building with Philippe. Because he is now making software rather than only working on projects, he is thinking carefully about avoiding features that can become disorganized. He says a guiding principle for the product is being “allergic to things that can be disorganized.”

The host presents ChatGPT as an example of an interface that avoids organizational burden. He calls ChatGPT.com, in his view, the “ultimate” way to interact with AI because it gives the user one screen and one main action: type into the prompt. He dislikes modes and subdivisions such as a separate work mode, arguing that they fork the experience unnecessarily. Starting a new chat does not require the user to categorize the previous one, and he says he has no pinned chats. He compares this to Google.com. He imagines how unpleasant Google would be if every search were automatically placed into categories, accompanied by reminders, or archived into a required structure. The appeal of Google is that it is minimal and ephemeral: open it from anywhere, type, press Enter, and leave. The host believes ChatGPT works similarly. He uses it on his phone for ordinary but varied needs, including asking how to make pumpkin muffins and asking how to respond when his four-year-old son, River, becomes curious about his body. He jokes that he had to “emergency ChatGPT” the latter question and worries humorously about being flagged as a predator, but the point is that ChatGPT is useful for immediate, context-specific questions without requiring a dedicated project. For him, the lack of organization is a feature. A new thought can become a new conversation, and the user does not have to preserve a structured record of everything.

The host revisits his earlier belief that developers should always read and understand all the code generated by an agent. He still thinks that principle matters when building an open-source library or framework: he needs to know that he has not introduced a security vulnerability, broken abstractions that users rely on, or created problems at the many entry points exposed by a public codebase. Building a SaaS application feels different to him. In Paraphrame, he says, the important surfaces are the UI, user workflows, APIs, MCPs, and other externally visible behaviors. He compares this to a SaaS product, where shipping poor UI is unacceptable, and argues that one should not ship “API slop” or even “implementation slop” either. But the code itself is not always the primary surface in the same way it is for an open-source framework. He says the appropriate amount of code-level involvement depends on context, rather than being a universal rule. He uses this distinction to criticize absolutist claims from both directions. Someone could say that nobody should ship code they have not read, while a SaaS-focused person could say that only the user experience matters and that reading the implementation is antiquated. Similarly, a person focused on desktop software may need to test behavior directly on a Mac at a particular display resolution, while a remote agent environment may be perfectly suitable for other work. The host’s conclusion is that workflow advice becomes misleading when it ignores what is actually being built.

The host says there are legitimate arguments for several very different development environments. One option is a traditional local setup: a sites folder containing projects, local development configured with Herd or something similar, Claude Code running in a terminal, and a few tabs. He calls this a perfectly good and highly productive workflow. At the opposite extreme is a cloud-based, multiplayer system with scheduled agents that check on work, prepare changes, and prompt the developer about what needs attention. He also considers that world valid, but says it is much less focused. The central distinction for him is between building mode and maintenance mode. When he is building a product or working closely on a bug, feature, pixel, workflow, or interaction, he wants one lane and one local project. He does not want twelve agents working in twelve orbs, worktrees, playgrounds, or copied environments. Claude Code in a terminal gives him a feeling of being close and connected to the thing he is making. When he is in maintenance mode, he wants the reverse: many agents fixing many issues automatically, preparing briefs, organizing email, identifying references, or turning material about something such as Flux into a newsletter workflow. He has experienced the appeal of managing a huge number of tasks at once, and says it can make him feel as if he is operating at a larger scale. But that experience is also distracting, chaotic, full of context switching, and painful. The best setup therefore changes with the mode of work.

The host says he has tried Amp three times but has not become a believer. His current desktop-app work is a practical reason: an orb or remote environment may not let him immediately determine whether the application behaves correctly on a Mac at the resolution of his Studio Display. He acknowledges that Amp may be excellent and notes that many people become firm believers after trying it, but that has not been his experience. His objections are largely about cognitive and interface complexity. When he opens Amp, he feels there are ten new concepts to learn, a busy UI, project-based organization, multi-project thread behavior, connections, and an expectation that the system can understand and do everything. He mentions a newspaper-like pop-up with many new things to read and a mascot playing a lute, then asks what a “portal” or an “orb” actually is and how local or browser-based orbs fit together. He describes the experience as requiring full buy-in, unlike opening Claude Code in a terminal, where he feels there is nothing he cannot do. He makes a similar point about agent integrations. Grokbot or Dot may connect to Google Calendar, but a missing Help Scout plugin can prevent the workflow he wants. Claude Code feels more universal to him because it can write a script, open a browser, or use another method when a direct integration does not exist. He does sometimes switch to Claude Desktop when he needs browser access, though authentication creates its own problems. He is interested in Dot’s idea of connecting to 1Password so an isolated session can authenticate for itself, but his general preference is to grant agents broad permissions and let them pursue the task without repeatedly asking for approval.

The host broadens the argument beyond terminals and orbs. He says people make the same absolutist claims about voice prompting, WhisperFlow, overnight agents, editors, Git integration, built-in debuggers, strict types, compiled languages, VPSs, and serverless hosting. He uses the repeated phrase “I can’t believe you’re not…” to show how every technology’s advocates treat their own choice as the obvious baseline and everyone else’s choice as irrational. He does use WhisperFlow and agrees that voice can provide more context than typing, but he does not always want to speak. Sometimes he wants to sit quietly in his office and type, even though he knows a recorded explanation might be richer. He also tried talking to Dot while running and found that experience unsuccessful, saying Dot currently “sucks” in his opinion. He is more optimistic about trying Grokbot on a run, especially because it can connect to Google services, but he has not yet concluded that it solves his broader workflow needs. The episode ends with a defense of the terminal’s simplicity. The host says its value is not that terminals are inherently fashionable; it is that they free him from the mouse, mandatory menus, toolbars, notification systems, and layers of interface affordances. A terminal gives him a text input, lets him request something, and lets him press Enter. It is already a universal computing convention, requires no new organizational model, and leaves an ephemeral state behind. He calls that experience serene and pure, and says treating it as insane is itself the insane behavior. His final message is that listeners are not insane for choosing a different workflow: the right choice depends on the work, the desired level of focus, and how much complexity they are willing to maintain.