By Geoffrey Huntley in AI — 26 Jun 2025

AI coding tools are perhaps our new terminal emulators

So, I'm currently over in San Francisco. I've been here for almost two weeks now. I'll be heading home to my family in a couple of days. However, over the weekend, I had the opportunity to visit the Computer History Museum. I'm not going to lie, being able to spend some time on a functioning PDP-1 is way up there on my bucket list.

Now, something strange happened while I was down at the Computer History Museum. One of my mates I was with had an incident on their Kubernetes cluster.

Typically, if you're the on-call engineer in such a scenario, you would open your laptop, open a terminal, and then log on to the cluster manually. That's the usual way that people have been doing incident response as a site reliability engineer for a very long time.

Now, this engineer didn't pop open their terminal. Instead, they remotely controlled a command-line coding agent and issued a series of prompts, which made function calls into the cluster using standard command-line tools from their phone.

We were sitting outside the Computer History Museum, watching as the agent enumerated through the cluster in a read-only fashion and correctly diagnosed a corrupted ETCD database. Not only did it correctly diagnose the root cause of the cluster's issue, but it also automatically authored a 95% complete post-incident review document (a GitHub issue) with the necessary action steps for resolution before the incident was even over.

Previously, I had theorised (see my talk) that this type of thing is possible, but here we were with an SRE agent, a human in the loop, controlling an agent and automating their job function.

Throughout the day, I kept pondering the above, and then, while walking through the Computer History Museum, I stumbled upon this exhibit...

The Compaq 386 and the introduction of AutoCAD. If you've been following my writing, you should know by now of the analogies I like to draw between AutoCAD and software engineering.

Before AutoCAD, we used to have rooms full of architects, then CAD came along and completely changed how the architecture profession was done. Not only were they asked to do drafting, but they were also expected to do design.

I think there are many analogies here that explain the transition happening now in our profession with AI. Software engineers are still needed, but their roles have evolved.

These days, I spend a lot of time thinking about what is changing and what has changed. One thing I've noticed that has changed is best illustrated in the chart below.

Now, the Amp team is fortunate enough to be open to hiring senior curmudgeons like me, as well as juniors. When I was having this conversation with the junior, who was about 20 years old and still in university, I remember discussing with him and another coworker that the junior should learn the CLI and learn the beauty of Unix POSIX and how to chain together commands.

The junior challenged me and said, "But why? All I need to do is prompt."

I've been working with Unix for a long time. I've worked with various operating systems, including SunOS, HP-UX, IRIX, and Solaris, among others, using different shells such as CSH, KSH, Bash, ZSH, and Fish.

In that moment, I realised that I was the person on top of the bell curve, and when I looked at how I'd been using Amp over the last couple of weeks and other tools similar to it, I realised none of it matters anymore.

All you need to do is prompt.

These days, when I'm in a terminal emulator, I'm running a tool such as Claude Code or Amp and driving it via speech-to-text. I'm finding myself using the classic terminal emulator experience less and less with each passing day.

For example, here's a prompt I do often...

Run a production build of the VS Code extension, look at the PNPM targets, then install the compiled artifact into VS Code.

now imagine 10 of these sessions running concurrently and yourself switching between them with speech-to-text

Perhaps this is not the best use or demonstration, as it could be easily turned into a deterministic shell script. However, upon reflection, if I needed to build such a deterministic shell script, I would use a coding tool to generate it. I would no longer be creating it by hand...

So, I've been thinking that perhaps the next form of the terminal emulator will be an agent with a library of standard prompts. These standard prompts essentially function as shell scripts because they can compose and execute commands or perform activities via MCP, and there's nearly no limit to what they can do.

It's also pretty impressive, to be honest, for doing one-shot-type activities. For example, the images at the top of this blog post were resized with the prompt below.