We rebuilt the DOS prompt and called it AI
A customer email lands. You select it, copy it, switch to a chat window, paste it in, and type some version of an instruction you have typed before. Something like “draft a friendly reply agreeing to the timeline but pushing the start date to the 15th.” You get something good back. You copy that, switch to your mail, paste it in, edit a line, then send.
The most advanced software most people touch is operated by typing a sentence into a box and reading what comes back. The DOS prompt had the same loop in 1981.
Chat would have run on a DOS PC
Strip the rendering and look at the interaction model. You type what you want. It responds. You type again, refining, because your first attempt was underspecified. There’s no state you can see, no direct manipulation, and no buttons or menus to tell you what the system can do. The whole surface is a prompt and a scroll history. It works so well in a terminal window because it more or less is a terminal window. AI chat is a command line with better fonts and a model where DOS had a command interpreter, running the loop we used before every desktop had a mouse on it.
A shell demands exact syntax and chat allows almost anything. That widens the audience without changing the interaction. The loop is identical: compose a request in text, submit it, read what comes back, refine or move on. We spent decades moving away from typing instructions into a box, and the most exciting software of the moment replaced commands with natural language but otherwise threw us back several decades. So much for years of user interface research and innovation.
It won for a good reason
Observing that AI chat is a form of command line isn’t new, and people didn’t forget about DOS. The command line came back because it supported generality in a way that more modern interfaces cannot.
Every graphical interface is specific. There’s no such thing as a universal GUI. HyperCard and Smalltalk are the usual counterexamples and they make the point rather than break it: both let you build a specific interface. The spreadsheet comes closest of anything, but good luck editing video in it. A button does one thing, a menu enumerates a fixed set of things, and a screen laid out for writing email won’t let you edit video. To design a graphical interface at all, you have to decide in advance what the user will want to do.
A command line requires no such decision. It accepts any command the system understands. Chat goes one step further and accepts anything you can express in words, which is a larger set than any shell ever offered. If you’re building something intended to do everything, a text box is an obvious starting point, because the alternative is guessing which handful of tasks matter and building screens for those.
AI chat’s interface isn’t due to a failure of imagination. It supports breadth, and that’s important for a new tool since no one knew how people would use it.
Breadth and efficiency are in tension
The trade shows up the moment a task becomes routine.
You can manage your email by describing what you want to an AI, and some people do. Most don’t, because clicking a button or pressing a key is faster. Gmail has a keyboard shortcut for archive because people archive forty times a day, and pressing one key beats composing a sentence about it.
Nor does anyone type a floor number into an elevator, or say “fourth floor please”. You press the button. The button is a worse interface if you want generality: it does exactly one thing, it had to be installed in advance, and it can’t express anything else. For the task at hand it’s unbeatable, because naming what you want takes longer than tapping the floor button.
For a known, repeated task, a specific control beats a general one. That isn’t a fact about software. It’s a fact about how much work it takes to describe an action versus point at it.
Car makers are relearning this the expensive way. After a decade of moving every control onto a touchscreen, physical buttons are coming back, and the pressure is regulatory rather than nostalgic. From 2026, Euro NCAP assesses the human-machine interface and looks for physical buttons on commonly used functions, on the evidence that hunting through menus takes your eyes off the road. A touchscreen can let you do almost anything, which is exactly why it is worse for the few things you do constantly.
The prompt you keep retyping is the signal
Which brings back the habit at the top. If you find yourself typing roughly the same instruction into a chat window, you have located a task that is known and repeated. You are hand-operating something that has become routine, using the interface designed for generality and open-endedness, not repetition.
The retyped sentence is close to a specification. It names a trigger, a condition and a desired output, in order, every time. The reason it still requires you is that the chat window may not be able to see the message that arrived, doesn’t know what you charge or what you promised this customer in March, and can’t start on its own. So you supply the context by hand, every time. The model does the writing and you handle the logistics.
That’s the general interface doing its job. It showed you the nature of the repeated work. And once you recognize it, you should find something more specific that handles more of the work.
The next transition will be quicker than the last
Transitioning from the DOS prompt to the Macintosh and Windows GUI took most of a decade, and it was slow because the toolkit had to be built. Windows, icons, menus, pointers. Drag and drop. Undo. Progressive disclosure, so a novice and an expert could use the same screen. Direct manipulation, where you move something rather than describe the move. Engelbart and Xerox PARC had demonstrated much of it years earlier, but almost none of it was in general use, and each piece had to be argued about and standardized before it reached a desk.
That toolkit exists now. The transition from chat to whatever comes after it doesn’t need a new theory of interaction, because we’re not starting from a blank screen this time. We already know what a button is, what a list is, what an approval step looks like and how undo should behave. The open question is narrower and more tractable: which tasks are common enough to deserve their own interface, and what that interface looks like with a model behind it.
The counter to this is that the widgets were never the hard part, and that the real work was figuring out which applications mattered. That held in 1984 and it holds less well now, because the usage is legible in a way it has never been before. We can read what people actually bring to these systems: search they used to run on Google, code, trip planning, drafting a reply. The AI features appearing inside existing tools are the first attempt at acting on that, but they aren’t good enough yet to pull anyone out of the chat window. But the question of what to build is much closer to answered than it was in the early days of the PC.
That’s a design problem rather than a research program, which is why it should go faster.
Chat won’t disappear, any more than the shell did. It will remain useful for any task you haven’t done before or don’t have a tool to handle. For the things that people do repeatedly, we’ll see a new generation of AI-powered apps with UI designed for those tasks. Everything you do repeatedly is on its way to becoming a button, a menu item or a keyboard shortcut.