An information architect asked me recently, someone who thinks seriously about how systems expose themselves to users, why anyone would still be using the shell in 2026. The question was genuine. From a certain vantage point, the terminal looks like a historical accident the industry has been too sentimental to kill.
The question deserves a serious answer, because the answer matters. Not just for understanding Claude Code, but for understanding what kind of cognitive environment software work actually requires.
The GUI hypothesis
The implicit argument against the shell runs like this: graphical interfaces are higher-bandwidth, more discoverable, more forgiving. They show you what’s possible. They keep you from typing something destructive. They provide context through layout, color and spatial arrangement. By this logic, a sufficiently good IDE should be strictly superior to a terminal for every task, and an AI coding assistant embedded in that IDE should inherit all those advantages.
It’s a reasonable hypothesis. It’s also wrong, in a way that reveals something important about knowledge work.
Composition over presentation
The shell is not a visual interface. It’s a linguistic one, and the difference is not cosmetic.
In a graphical environment, the tool’s designer decides which operations are visible, which sequences are suggested, what the unit of work looks like. The user operates within a vocabulary someone else defined. That is powerful when the problem space is well understood and the operations are predictable.
Software work is not that kind of task. Building systems means constantly composing novel sequences of operations no tool designer anticipated. You grep a log, extract a pattern, feed it into a query, check the result against a schema and pipe the diff to a reviewer, and that exact sequence has never existed before and never will again.
The shell handles this because its fundamental primitive is composition: small tools, connected by a universal interface (text), assembled into ad hoc workflows. This isn’t a limitation of 1970s technology. It’s a design principle that happens to be correct for combinatorial problem spaces.
Why Claude Code runs here
Anthropic built Claude Code terminal-first, rather than only as a plugin inside someone else’s editor. Whatever the product reasoning, the consequence is architectural, not aesthetic.
An agent operating in a shell has the same compositional substrate that makes the shell powerful for people. It can invoke any tool, read any file, chain operations, and use the output of one command as the input to the next. It isn’t confined to whatever API surface a plugin host chooses to expose.
More important, the human and the agent share a common language. When the agent shows you the command it is about to run, you can read it. You can change it, run it yourself, extend it, pipe it somewhere else. No abstraction layer sits between what the agent did and what you see. The representation is the operation.
That matters enormously for trust. An agent behind a graphical abstraction is a black box that occasionally surfaces diffs. An agent in a shell is a collaborator whose every action is legible in the notation you use yourself.
The information architecture argument
Here is where I’d push back on the information architecture framing: the shell is not a lack of information architecture. It’s a different one, optimized for different concerns.
An IDE organizes information spatially: file trees, tab bars, panels, inline annotations. That’s useful for orientation. It answers “where am I?” and “what’s nearby?”
The shell organizes information temporally and compositionally: command history, pipes, output streams. It answers “what did I do?”, “what happened?” and “what should I do next?” For an architect working with an AI agent, the second set of questions is often the more important one.
When I work with Claude Code, my terminal is a transcript of reasoning. Every command, every output, every decision is there in sequence. I can scroll back and see not just what the codebase looks like now but how we got here: what was tried, what failed, what was revised. That is a richer information artifact than any file tree.
The deeper point
“Why would anyone still use the shell?” assumes the shell persists through inertia or nostalgia. It persists because it embodies a principle most graphical interfaces don’t: that the user is a programmer of their own workflow, not a consumer of someone else’s.
Information architects, of all people, know that the structure of an interface shapes which thoughts are easy to have. A shell makes it easy to compose, experiment and chain novel sequences. A GUI makes it easy to perform anticipated operations. Both are valuable. But add an agent that can generate novel compositions at the speed of thought, and the compositional environment becomes dramatically more powerful.
The same conviction shapes Pharos Fabric. Its operator surface is a command line, and its commands are entities in the graph, so a person and an agent reach for the same vocabulary, governed by the same capabilities.
Claude Code in a terminal isn’t a step backward. It’s what happens when you take the Unix philosophy seriously in the age of AI: small tools, clear interfaces, universal composition, and now a collaborator fluent in the same language.
The shell isn’t the thing we haven’t gotten around to replacing. It’s the thing we’ve been building toward.