Terminal UIs Are an Abomination, And so is the Chatbot : UX for AI

The terminal UI is back, and people are pretending this is progress.

Claude Code, Codex-style workflows, agent shells, prompt consoles, endless panes of logs, diff spam, and chat windows masquerading as operating systems: this is being sold as the natural interface for AI. It is not.

It is a historical accident dressed up as sophistication. It is what happens when the people building the engines are also the people choosing the interface, and they pick the one that is easiest for them to ship, easiest for them to understand, and easiest for them to mistake for inevitability.

Terminal UIs are not the future of AI. They are the laziest possible bridge between model capability and user experience.

And if we are serious about AI adoption beyond engineers amusing other engineers, we should say it plainly: TUIs are an abomination.

Not because terminals are useless. They are not. The command line remains one of the most powerful interfaces ever created for expert users operating deterministic tools. But AI systems are not grep. They are not awk. They are not even IDEs in the old sense. They are probabilistic, stateful, increasingly asynchronous systems that reason across tools, files, memory, tests, branches, and time. Compressing that into a terminal transcript is not elegant minimalism. It is interface failure.

The industry has confused the easiest interface to build with the right interface to use.

We are mistaking engineering convenience for design truth

Why are terminal and chatbot interfaces everywhere? Not because they are optimal. Because they are cheap.

If your engine emits text, the fastest wrapper is a text box. If your system produces tool calls and logs, the fastest way to show them is a stream. If your early users are developers, the safest aesthetic is one they already recognise: a terminal, a REPL, a chat transcript, a stream of tokens pretending to be thought.

That does not make it good UX. It makes it expedient UX.

This matters because what ships first often becomes what the market starts treating as natural. Builders become evangelists for their own shortcuts. Then the shortcut calcifies into doctrine. Suddenly a crude interface is no longer admitted to be scaffolding; it becomes philosophy. People start saying things like “chat is the native interface for AI” or “the terminal is ideal because it stays out of the way.”

No. It stays out of the way in the same sense that a hospital without instruments “stays out of the way” of surgery.

The terminal works for engineers because engineers are unusually tolerant of invisible state, cryptic feedback, high memory burden, and brittle syntax. They will happily memorise command shapes, reconstruct causality from scrollback, and call it empowerment. Most people will not. Most businesses should not. Most serious AI workflows absolutely cannot.

This is not a conspiracy in the cartoon sense. It is something more banal and more common: builder capture. Engineers have wrapped AI in the interfaces they personally find comfortable, and then inferred that mass adoption will follow if everyone else simply learns to like it.

That is not product design. That is cultural gatekeeping disguised as technical realism.

Chat was fine for single-shot generation. That era is ending.

The chatbot made sense for a narrow phase of AI.

When the dominant use case was “generate me a paragraph,” “summarise this,” “give me ten ideas,” or “write a function,” a chat box was good enough. It fit the illusion. Ask a question, get an answer. Prompt in, response out. One shot. One turn. Maybe a few revisions. Fine.

But we are no longer living in that world.

AI systems now search, edit, retry, call tools, inspect files, spawn subtasks, evaluate outputs, recover from failures, route work across models, maintain context across sessions, and produce long-running chains of dependent actions. In software, research, operations, and knowledge work, the unit of value is no longer a single response. It is an evolving process.

And processes are not naturally represented as conversations.

A conversation is linear. Agentic work is not. A chat transcript is chronological. Real work is causal. A terminal scroll shows what happened in order. Users need to know what happened because of what. A chat box privileges the latest turn. Complex systems demand visibility into state, branching, memory, dependencies, approvals, failures, and alternate paths not taken.

Once AI became multi-step and asynchronous, the chat interface became a lossy compression format for reality.

Chat chronology is not task structure

This is the heart of the problem.

Human-computer interaction has known for decades that good interfaces reduce cognitive load by making system state visible, supporting recognition over recall, and allowing users to manipulate representations directly rather than reconstructing them from memory.

That is why GUIs beat command lines for mass adoption.

That is why visual debugging, version trees, file explorers, calendars, timelines, canvases, maps, and dashboards exist. Visibility matters. Structure matters. Spatial memory matters.

Chatbots and TUIs violate all of this the moment the task becomes non-trivial.

They force users to remember:

• what the system already tried
• which instruction caused which change
• whether a branch failed because of the model, the tool, or the environment
• which edits are stable and which are tentative
• what assumptions the agent is currently operating under
• where a bad decision entered the chain
• what should be replayed versus what should be discarded

A long transcript is not transparency. It is a tax on memory.

Showing me 2,000 lines of agent logs is not “keeping me informed.” It is the UX equivalent of dumping engine oil on the dashboard and claiming I now have superior observability.

Most of the current AI interface stack is built around a perverse assumption: if the machine tells you everything in the order it happened, you understand it. But sequence is not comprehension. Visibility is not verbosity. Exhaust is not explanation.

The terminal is the wrong metaphor for agents

Terminals were built for issuing commands to systems whose behavior, at least in principle, could be expected to follow deterministic rules. That is why they reward precision, speed, and expertise. The model is: tell the machine exactly what to do, then inspect the output.

That mental model breaks when the system is:

• partially autonomous
• probabilistic
• long-running
• tool-using
• revisable
• branching
• context-sensitive
• capable of acting on its own intermediate conclusions

At that point you are no longer operating a tool in the classical sense. You are supervising a process.

And process supervision has very different UX needs from command execution. It requires:

• durable state representation
• causal traceability
• branch comparison
• selective replay
• rollback and patchability
• provenance
• interrupts and approvals
• confidence signals
• scoped visibility

A terminal gives you almost none of this cleanly. It gives you a river. Rivers are good for transport. They are bad for inspection.

Code editing is the clearest example of how absurd this has become

The present generation of AI coding tools is a perfect demonstration of the interface problem.

An agent reads files, makes plans, edits code, runs tests, retries, changes its approach, updates multiple modules, creates side effects, introduces regressions, repairs them, and gradually builds up a substantial amount of logic. It may add thousands of lines of code over multiple passes. It may take actions based on subgoals that were never clearly surfaced to the user. It may branch internally several times before presenting what looks like a single coherent result.

And how is all of this typically shown?

A terminal transcript. A chat narration. A diff. Maybe a tiny list of touched files if the designer is feeling generous.

This is insane.

We are taking graph-shaped work and squeezing it through a straw designed for conversation.

What should the interface be instead? Not another better transcript. Not a prettier terminal. Not a more apologetic chatbot.

It should be a temporal change graph.

Imagine an interface pinned directly to the source code, symbols, files, tests, and modules themselves. Each agent action becomes a node in a graph rather than another disappearing line in a scrollback buffer. Nodes are annotated with the instruction that triggered the action, the evidence used, the files touched, the tests run, the result produced, and the downstream consequences. Branches are visible. Retries are visible. Dead ends are visible. Dependencies are visible.

Now the user can do what current AI interfaces barely let them imagine:

• inspect why a change happened
• compare alternate branches
• fork from an earlier node
• replace a downstream decision without losing unrelated work
• replay part of the chain with a new instruction
• suppress low-value noise and surface high-value causal points
• collapse or expand detail depending on expertise
• pin graph nodes to code regions, tests, or product requirements
• understand the system as a structure rather than a monologue

This is not some exotic fantasy. We already know from Git commit graphs, CI/CD DAGs, data lineage tools, notebook execution graphs, event-sourced systems, and build pipelines that graph-shaped interfaces become more valuable as systems become more interdependent, more asynchronous, and more branch-heavy. Those systems gained power because they made causality inspectable.

AI interfaces are heading the opposite direction. More autonomy, less inspectability. More capability, worse ergonomics. More action, less structure.

DAGs, event logs, and lineage systems already solved half this problem

One of the most frustrating things about the current AI UX discourse is how little it appears to have learned from adjacent fields.

Distributed systems learned long ago that once multiple actors, retries, events, dependencies, and failures are involved, chronology alone is not enough. You need traces, causal links, event histories, idempotent operations, replay, and observability. Build systems learned that dependency graphs matter. Data platforms learned that lineage matters. Git taught an entire generation of developers that history is more useful when it branches. Notebook environments demonstrated that execution state needs more structure than plain text if you want people to reason about it safely.

And yet AI, the most stateful and failure-prone interface layer we have introduced in years, is routinely surfaced as a chat log.

This is regression disguised as innovation.

The right lesson from event-based systems is not that every user wants to stare at events. It is that powerful systems need internal structure which can be surfaced through the right abstractions. DAGs, event sourcing, and provenance systems create value because they let you isolate causes, replace downstream effects, fork work safely, and audit what happened. That same logic applies directly to agentic software creation, research workflows, enterprise operations, and collaborative machine work.

Once an agent has taken ten actions based on an incorrect assumption, the interface should help you surgically replace the bad branch, not force you into a ritual of pleading with a chatbot to “undo the last few things but keep the good parts.”

The fact that this sounds familiar is an indictment.

The industry keeps calling verbosity “transparency”

A lot of AI product teams think they are being honest because they expose internal chain-of-thought-like summaries, logs, tool traces, and chat transcripts. But an unstructured dump is not transparency. It is abdication.

Real transparency is legibility.

If the user cannot quickly answer:

• what state is the system currently in?
• what is provisional versus committed?
• what caused this change?
• what alternatives were considered?
• what depends on this node?
• where can I intervene safely?
• what can be replayed?
• what is hidden because it is irrelevant rather than because the vendor is secretive?

then the interface is not transparent. It is merely noisy.

The terminal is particularly seductive here because it feels raw. Raw looks honest. Engineers love raw. But raw is not a virtue in itself. The raw database pages are not the best interface to accounting. A packet trace is not the best interface to collaboration. Kernel logs are not the best interface to project management. The proximity of an interface to machine internals tells you almost nothing about its suitability for human use.

If anything, it often tells you the opposite.

AI adoption will stall if users are forced to think like model operators

This is the bigger business point, and it matters more than aesthetics.

If using AI means becoming an amateur prompt engineer, transcript archaeologist, context babysitter, and terminal operator, adoption will plateau. Not because the models are weak, but because the interaction cost is absurd.

Most people do not want to operate the machine. They want the outcome.

Most enterprises do not want a clever shell. They want:

• visibility
• policy
• auditability
• permissioning
• rollback
• reproducibility
• handoffs
• performance at the workflow level, not the prompt level

Most creative users do not want to interrogate a scroll of tool calls. They want timelines, layers, variants, canvases, storyboards, and state they can see.

Most knowledge workers do not want to nurse a chatbot through a branching, multi-day task. They want collaborative surfaces that capture assumptions, alternatives, and consequences.

In other words, AI adoption will be inhibited to the extent that the interface requires users to think like operators of a model rather than beneficiaries of a system.

This is the trap. Engineers see the terminal and think power. Everyone else sees the terminal and sees homework.

“But experts like terminals” is not a serious rebuttal

Of course they do. Experts like all sorts of things that do not generalise.

Some of the most powerful interfaces ever built are hostile to novices. That is not an insult; it is a fact. But AI is not being sold as a niche tool for command-line enthusiasts. It is being sold as a universal layer for work, creativity, coordination, software production, research, and decision support. You do not get to make a universal claim and hide behind a niche interface.

Besides, even for experts, the terminal may not remain optimal as agentic workflows scale in complexity. Experts do not merely need speed; they need leverage. When systems begin running for longer, branching more often, and affecting larger codebases or processes, even technical users benefit from interfaces that externalise structure and reduce memory burden.

The history of computing is full of examples where experts retained access to low-level tools while the dominant interface evolved upward. GUIs did not eliminate shells. IDEs did not eliminate editors. Visual diff tools did not eliminate raw patches. Better abstractions did not kill power; they made it more accessible.

The same will happen with AI. Or should.

Separate the engine from the UX

This is the principle the industry needs to absorb, fast.

The model is not the product. The agent loop is not the interface. The tool trace is not the experience. The shell is not destiny.

We need to separate engines from UX so that interface innovation can breathe again.

Right now too many AI products are vertically collapsing everything into one builder-defined surface. The same team builds the engine, the orchestration layer, the prompt format, the transcript view, and the user interaction model. The result is predictable: whatever is easiest to expose from the engine becomes the user experience.

That is backwards.

If AI is going to become infrastructure, then UX needs room to become a competitive layer in its own right. Different domains will need radically different interaction grammars:

• code wants graphs, provenance, symbol-aware timelines, dependency-aware edits, and replay
• research wants maps of claims, evidence chains, competing hypotheses, and confidence trajectories
• operations wants queues, exceptions, approvals, service states, and intervention points
• creativity wants variants, branching artefacts, layered state, and compositional canvases
• enterprise decision systems want accountability surfaces, rationale trees, escalation paths, and policy-aware workflows

None of these are “just chat.” None of these are improved by pretending the terminal is neutral.

The winners in AI UX will not be the ones who add another pane to the console. They will be the ones who invent new representational forms for machine work.

What comes after the terminal

Not one interface. Many.

That is the point. We should stop asking which single AI interface will win and start asking which abstractions make different classes of machine work understandable, steerable, and composable.

Some likely patterns are already visible:

• temporal change graphs for software and document production
• stateful canvases for creative and analytical work
• workflow maps for multi-agent orchestration
• event-backed audit views for enterprise systems
• branchable knowledge surfaces for research and planning
• domain-native copilots embedded inside existing tools rather than pretending to replace them with chat

The next generation of AI products will be less like talking to a genie and more like directing a visible system. Less séance, more instrumentation.

And that is exactly why the current obsession with terminals is so backwards. We are living through the birth of software that can plan, branch, revise, and act over time, and we are choosing to interface with it as though it were a glorified autocomplete trapped in a black box.

It would be funny if it were not so wasteful.

The terminal revival is a failure of imagination

The return of the terminal as AI’s prestige interface is not evidence of maturity. It is evidence that the industry has temporarily run out of imagination.

It is what happens when the people closest to the machinery mistake proximity for insight. They confuse seeing the gears with understanding how the machine should meet the world. They congratulate themselves for exposing the raw loop while neglecting the harder problem of making complex systems humane, inspectable, and truly useful.

The future of AI will not be won by whoever ships the most charismatic shell.

It will be won by whoever builds interfaces that make autonomy intelligible, causality navigable, and intervention cheap.

So yes, TUIs are an abomination. Not because text is evil. Not because terminals should disappear. Not because engineers are villains.

They are an abomination because they are being elevated far beyond their proper role. They are transitional scaffolding pretending to be architecture. They are a compatibility layer being sold as a civilisation layer. They are what happens when a new computational medium is forced to wear the clothes of an old one.

Chat got us through the demo era. The terminal got us through the operator era. But if AI is going to become a real medium for work, thought, and creation, we need to stop worshipping the shell and start designing for the shape of the work itself.

That is where UX goes next.