Vithun's Blog
The Terminal Was Right. It Just Had the Wrong Operator.
Last week I put a Mac Mini on a shelf at home, installed Tailscale on it, and started using Termius on my phone and iPad to talk to it. That was the whole setup. No cloud account, no dashboard, no app for each thing I wanted to do.
During the weekend I was on the road, and by the end of it I had built a fully working native macOS app (will publish it shortly). This was not a proof of concept, but a finished tool that scratches a niche itch of my own: a UI for managing launchd agents on the Mac. I had never built a Mac app before. I did the whole thing through a terminal on my phone and iPad, with the Mini and an AI coding agent doing the actual work. There is an irony in there that I enjoy: I built a GUI without touching one.
What surprised me more than the app was the way of working. With Termius and Tailscale on the client side and herdr keeping things running on the server, I was casually lining up several tasks in parallel, each in its own git worktree of the same project, letting them run, and merging the pull requests at the end. From a phone. It is the most productive personal computing setup I have had in years, and it is architecturally identical to a 1980s green screen wired to a mainframe. The thin client was not a compromise. It let the server do more, not less.
That was the moment a longer thought crystallised, and I think it matters for how large, older companies should be spending their transformation budgets right now.
The pendulum has swung back
The mainframe era had a clear shape: a dumb terminal on the desk, all the compute and all the state on a big machine somewhere else. We spent forty years walking away from that. PCs put the compute on the desk. The web put a thick, JavaScript-heavy client in the browser. Mobile did it again.
Frontier AI has quietly reversed the trend. The model that is actually useful runs in a data centre you do not own, on hardware you cannot buy, and the thing on your desk is once again a fairly dumb window onto it. Structurally, a chat with a frontier model is a 3270 session with better manners.
My Mac Mini setup is the same shape. The phone is the terminal. The Mini is the server. Tailscale is the leased line. The reason it works so well is not that I have rediscovered something clever; it is that the client-server split with a thin, text-based client was a good idea in 1975 and it is still a good idea now. The people who designed green-screen systems were right about the architecture. They were only early.
What they got right about the interface, too
If you have ever watched a travel agent work an Amadeus cryptic terminal, you have seen something most modern software has forgotten how to be: fast. A screen full of dense, positional text. Tab, type, enter. No spinner, no modal, no onboarding tour. The agent is thinking in the system’s language and the system is answering instantly. Then someone built a web front end over it, and the agent got slower.
Terminal UIs are efficient because they are text, keyboard-driven and dense. That is also exactly the profile of interface a language model is good at.
Anyone who has built agents knows this. An agent driving a command line or a well-shaped text API is dependable. An agent driving a GUI, clicking through tabs and reading screenshots, is slow and brittle. The thing that made my home setup click was realising that the same terminal I use from my phone is the one an AI agent uses most comfortably. We are converging on the same interface from both sides.
So there is an uncomfortable question for the transformation industry: did we replace the machine-friendly interface with a human-friendly one just in time for the primary user to become a machine?
But the terminal was never the problem
The reason “legacy modernisation” became a category was not the screen. It was everything behind it.
Batch windows that stop the business at midnight. Positional fields whose meaning lives in one retiring engineer’s head. Licensing priced by CPU consumption, which punishes any new workload. No APIs, no test environments, no way to change one thing without regression-testing the world.
A terminal is text, but it is not a contract. A 3270 screen where field 14 means fare basis unless the previous screen was a refund is not something an AI can reliably drive either. The RPA industry made a fortune screen-scraping green screens, and every one of those bots breaks when someone moves a column.
So “keep the terminal” is not enough on its own. The interesting move is one step further.
The reframe: change who sits at the terminal
The terminal does not die. It changes operator.
The AI becomes the trained agent. The human talks to it in ordinary language: “move Mrs Okafor to the earlier flight and keep her seat preference.” The AI talks cryptic to Amadeus. The expert interface survives, intact, as the machine interface. The human gets a conversational front end that costs almost nothing to build, because the model already knows how to hold a conversation.
That flips the transformation mandate. For fifteen years the brief has been: make the core system pleasant for humans. The new brief is: make the core system legible to machines. Document the screens. Stabilise the protocol. Expose the same operations as a text API with a real contract. Put the model close to the data so the round trip is short.
None of that requires rewriting the core. It is cheaper than a migration, it preserves the efficiency that expert users actually liked, and it aims the investment at the consumer of the system who is about to matter most.
Why older companies don’t frame it this way
A few reasons, and none of them are stupid.
Transformation has been sold by people who sell UIs and cloud migrations, so that is what it came to mean. Boards can see a new web app; they cannot see a stable text contract.
Talent is a real constraint. Nobody graduating this year wants to work on a green screen, and “we are keeping the mainframe” is a hard recruiting pitch.
And the cost structure of these platforms genuinely does penalise new workloads, so “run AI next to the system of record” is not free even when it is architecturally right.
But I think the framing is about to shift anyway, because the economics of agents will force it. Companies that spent the last decade building pretty front ends will discover their agents cannot use them. Companies that kept the ugly, dense, text-based core will discover their agents can.
There is an obvious follow-on question about who benefits if this is right, and the mainframe vendors are the first name that comes to mind. I have not followed that market closely enough to have a view worth publishing, so I will leave it as a question rather than a prediction.
The takeaway
The dumb terminal had the right architecture and the right interface. What it lacked was an operator that did not need three months of training. We now have that operator.
I did not set out to prove any of this. I just wanted to run things on a Mini from my phone. But the setup that fell out is a small, working model of where I think enterprise computing is heading: a thin text client, a capable machine somewhere else, and an AI in between that speaks both languages. If that combination lets someone who has never built a Mac app ship one from a train, with three branches in flight at once, it is worth asking what it does for a company sitting on forty years of systems that already speak text.
If you run a large, old system, the question for your next transformation cycle is not “how do we get off this?” It is “how do we make this readable to something that is very good at text?” That is a smaller, cheaper, and probably more valuable project than the one on the roadmap.