Talking to AI in a Terminal Reminds Me of Computing in the ’90s

The familiar part

Most of my working day now happens in a terminal window, talking to an AI assistant. Claude Code is the one I use most; OpenAI’s Codex CLI does the same job from the same kind of window. A prompt, something typed, text coming back, and then a file changes or a command runs. The first time I noticed how comfortable that felt, I realized why. It is where I started.

My first computers ran DOS, a story I told in from DOS to AI. A blinking cursor, a drive letter, and the understanding that nothing would happen until I typed something correct. Later it was Unix shells, router consoles and a Network Operations Center, where the screen was still text and the work was still typed. We spent the next two decades building graphical interfaces so people would never have to do that. And here I am, back at a prompt, with the satisfaction of making something happen without clicking through a single menu.

Talking to an AI assistant in a terminal feels like the command line of the DOS and early Unix years because the shape is identical: a prompt, typed instructions, text output, and real effects on the machine. What is different is the language. The old prompt needed exact syntax. The new one accepts intent.

C:\> copy report.txt a:\
        1 file(s) copied
C:\> _

spawn ssh router01
expect "#"
send "show int summary\r"
expect "#"

> api won't start, find out why

  api.log: port 8080 is held by
  an older instance (pid 4312).
  Stop it and restart? [y/N] _

What changed

DOS and the Unix shells were unforgiving in a way younger engineers may not have met. The command had to be right: the name, the flags, the order, the path. A typo was an error, or worse, a different command. You learned by reading manuals, by trial, and by remembering, which is why so much of early expertise was simply knowing the incantations. I wrote about letting go of that in you don’t need to remember everything, and the terminal assistants are the strongest version of the argument.

Claude Code and Codex CLI interpret what I mean. I can describe the outcome, and the assistant proposes the command, reads the files, edits them, runs the tests and reads the error back to me when something fails. It can look at a stack trace and suggest where the bug is. It can draft a script I would have written from memory, badly, in twenty minutes.

What has not changed is the part underneath. When the assistant runs a command, the command runs, with my user’s permissions and the consequences that go with them. A deleted directory is deleted. A migration against the wrong database is applied. The natural-language layer makes the terminal approachable. It does not make it safe. I still read what it is about to run before it runs, the way I read a script before I executed it in a data center.

Why the terminal never went away

The terminal survived the graphical era for reasons that have nothing to do with nostalgia. Anything you can type you can script, and anything you can script you can repeat exactly, on a schedule, on a hundred machines. Remote access is a terminal by nature; the server on the other side of an SSH session has no desktop. And the Unix habit of small tools joined by pipes turned out to be the most durable idea in computing: each tool does one thing, the output of one becomes the input of the next, and the combination does something none of them could alone.

I spent years inside that model. On the carrier network we automated deployments and routine operations with Expect and KornShell scripts, which I described in DevOps from Expect scripts to AI agents. Expect is a good example of the lineage: it typed into a console so a person did not have to, waited for the prompt, and typed the next thing. The AI assistant in my terminal is Expect’s descendant. It types into the console so I do not have to, and it decides what to type by understanding what I asked for.

Remembering a command versus describing a problem

Here is an illustrative version of the difference, not a transcript of anything in particular. A service will not start. The old way: remember which log to read and the command that tails it, spot the line that matters, remember the command that shows what holds the port, work out that a previous instance is still running, remember how to find and stop it, restart, and tail the log again. Six commands, each from memory, each with its own flags.

The new way: tell the assistant the service will not start and ask it to find out why. It reads the log, notices the port conflict, finds the process, explains the cause, and proposes the fix, which is the same six commands, now shown to me for approval. I read them, I agree, it runs them. The work done is identical. What I supplied was the intent and the judgment; what the assistant supplied was the recall and the typing.

I would not want to pretend the first way was better. It was slower, and the recall was a skill I kept sharp mainly because I had no choice. I would also not want to pretend the second way removes the need to understand what happened. If the proposed fix had been to stop the wrong process, the only thing standing between the assistant and a worse outage is a person who reads the command and knows what it does.

What it means for the people I lead

A more approachable interface is good news for anyone starting out. The command line used to gate the work behind months of memorization, and now a new engineer can be useful in a terminal in their first week. I welcome that without reservation.

It also moves the bar rather than lowering it. When execution is nearly free, the scarce things are knowing what you want, saying it clearly, and recognizing when what you got is wrong. Reviewing a change the assistant made is the same discipline as reviewing a pull request from a fast colleague who has not been with the company long: trust the work, check the work, and check harder when it touches production. Verifying results, by running the tests, reading the output and looking at the system afterwards, is not a step the assistant can take for you, because it is the step that decides whether you believe the assistant. I wrote about keeping that line in what hasn’t changed about building software, and I hold the people I lead to it as much as I hold myself.

Faster execution makes clear intent and sound judgment more valuable. That is the whole leadership lesson, and it would have been true of a very fast junior engineer too.

Same prompt, different conversation

So the interface feels familiar, and I think the feeling is honest. A prompt and a cursor, text in and text out, a machine that does what the words say. I learned computing that way, kept networks running that way, and automated operations that way with scripts that typed on my behalf.

What changed is who the words are for. In DOS and in every shell since, I spoke the machine’s language and the machine did exactly what I said. Now I speak my own language and the assistant works out what I meant, then asks me to confirm what it is about to do. The prompt is the same. The conversation is not. I was never more at home in an interface, and I have never had to pay closer attention to what I say in one.

Short answers