Technology Evolution Doesn't Move in a Straight Line—It Spirals
written by Stefan Christoph
Technology Evolution Doesn’t Move in a Straight Line. It Spirals
The Proud Ops Colleague
Years ago, an Ops colleague proudly showed me something new. ClusterSSH, cssh [1]. A tool that opens multiple terminals to multiple machines, at the same time. You type once, it executes everywhere.
Back then, machines still had names. Ops folks knew their history, their specs, their quirks. They could tell you which server had been acting up last Thursday and what firmware it was running. And cssh? It let them follow the runbook consistently across every node. No more SSH-ing into machines one by one, hoping you didn’t forget a step on node 7.
It was a big deal. Before that, customers might have hit nodes where the service hadn’t been properly updated. One machine running an old version. One with a missed config change. cssh improved the ops life, and the customer experience.
I remember thinking: this changes everything.
Then Everything Changed
A lot happened since that demo. Configuration management tools like Puppet and Chef arrived. Then deployment pipelines. CI/CD became state of the art [2]. Infrastructure as Code turned server provisioning from an art into a repeatable process.
Ops moved from terminals to web frontends, more or less beautiful ones. Dashboards. Monitoring UIs. Deployment consoles with big green buttons. No more SSH sessions. No more named machines. Infrastructure became cattle, not pets [3].
And developers? They mostly left their terminals too. IDEs took over, rich graphical environments with syntax highlighting, integrated debugging, and git GUIs. Only the very geeky ops folks or developers still lived in the command line.
The terminal was dead. Long live the GUI.
And Now… Look Around
Fast forward to today. What are the most exciting tools in the developer and ops space? Terminal-based AI agents. Claude Code. Kiro CLI. Aider. Cursor’s terminal mode. The hottest tools in tech are running in a black window with a blinking cursor.
And what do we use to run multiple agents in parallel? tmux, a terminal multiplexer [4]. The spiritual successor to cssh. Blog posts are being written about optimal tmux layouts for watching your AI agent team work [5]. People are building dedicated “agent multiplexers” like amux [6] to manage parallel Claude Code sessions.
The parallel is almost poetic. In 2005, we used cssh to send the same keystrokes to multiple machines. In 2026, we use tmux to send different intents to multiple AI agents, each working on their own task. Same pattern. Higher altitude.
Beyond Code
Here’s what surprises people most: this isn’t just about coding.
Right now, I’m using Kiro CLI, a terminal-based AI assistant, not to write code, but to run my entire workday. Preparing customer meetings by pulling context from Slack, calendar, and our CRM. Doing my weekly activity reporting. Researching technical questions by cross-referencing AWS documentation with field experience. Managing my Salesforce pipeline.
And yes. I’m writing this very article with it.
The terminal has become my cockpit for everything. Not because it’s retro, but because natural language plus tools turns out to be the most efficient interface for complex, multi-step work. No clicking through five different UIs. No context-switching between browser tabs. Just describe what you need, and the agent orchestrates the tools.
It’s the same insight my ops colleague had with cssh: why do the same thing manually across multiple systems when a tool can do it consistently and in parallel?
The Human Cost: AI Brain Fry
But there’s a twist my ops colleague didn’t face. When you watched cssh execute commands across 20 machines, the terminals scrolled for a few seconds and it was done. Today, when you have multiple AI agents working in parallel, each one thinking, planning, executing, sometimes failing and retrying, you’re watching a much longer, more complex process unfold.
And it turns out, that’s exhausting.
A recent study published in the Harvard Business Review coined the term “AI Brain Fry”, mental fatigue from excessive oversight of AI tools beyond one’s cognitive capacity [7]. Among workers using AI, those experiencing brain fry reported 11% more minor errors and 39% more major errors. Their intention to resign was 39% higher [8].
This is the new version of an old problem. In aviation and industrial automation, researchers have long studied “automation complacency”, the tendency for human operators to reduce their vigilance when working with automated systems that normally function reliably [9]. The challenge isn’t the automation itself. It’s the human caught between needing to supervise and being unable to sustain that supervision.
We solved the ops version of this problem with CI/CD pipelines and monitoring dashboards. The agent version? We’re still figuring that out. But the spiral suggests the answer will rhyme with what came before: better abstractions, better feedback loops, and systems that surface only what needs human attention.
The Spiral
Technology doesn’t move in circles, it spirals. We return to familiar patterns, but at a higher level of abstraction.
The thin client/thick client cycle has been documented since the 1980s [10]. Mainframe terminals (thin) → PCs (thick) → web browsers (thin) → native apps (thick) → SaaS (thin) → local AI models (thick again). Each turn of the spiral carries forward the lessons of the previous one.
The same pattern plays out in computing architecture. Centralized mainframes → distributed PCs → centralized cloud → distributed edge computing. And now: centralized AI APIs → local models running on your machine.
And in our tools: terminals → GUIs → terminals again. But the terminal of 2026 is not the terminal of 2005. The human isn’t typing commands, they’re having conversations. The machines on the other end don’t have names, they’re ephemeral. And the runbook? It’s not a wiki page, it’s encoded in the agent’s context.
Recognize the Spiral
If you’ve been in tech long enough, you’ve seen these cycles. Recognizing the spiral gives you an edge. You’re not starting from scratch, you’re building on patterns that worked before, at a new altitude.
The problems we’ll face with AI agents, reliability, observability, human oversight fatigue, are not new problems. They’re the same problems ops teams faced with distributed systems, that pilots face with autopilot, that factory workers face with industrial automation. The solutions will be different in implementation but familiar in structure.
So next time someone shows you a “major new tool”, ask yourself: what’s the previous turn of the spiral? Understanding where we’ve been is the best way to see where we’re going.
And if you see someone proudly demoing their tmux setup with four AI agents running in parallel, smile. I’ve seen that demo before. It was called cssh. And it was just as exciting.
Sources
[1] ClusterSSH — https://github.com/duncs/clusterssh [2] Humble, J. & Farley, D. “Continuous Delivery” (2010), the book that defined CI/CD as we know it [3] Bias, R. “Pets vs Cattle” — the metaphor that changed how we think about infrastructure — https://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/ [4] tmux — terminal multiplexer — https://github.com/tmux/tmux [5] “Watch Claude Code Agents Work Side by Side: A tmux Setup Guide” — https://ksingh7.medium.com/watch-claude-code-agents-work-side-by-side-a-tmux-setup-guide-1ef3ba1531c4 [6] amux — Agent Multiplexer for parallel Claude Code sessions — https://amux.io/ [7] Bedard, J., Kellerman, G.R. et al. “When Using AI Leads to Brain Fry” — Harvard Business Review, March 2026 — https://hbr.org/2026/03/when-using-ai-leads-to-brain-fry [8] Chosun, “AI Supervision Causes ‘Brain Fry’ Stress Among Office Workers”, reporting 11% more minor errors, 39% more major errors among affected workers [9] Parasuraman, R. & Manzey, D. “Complacency and Bias in Human Use of Automation” — Frontiers in Psychology — https://www.frontiersin.org/articles/10.3389/fpsyg.2019.00225 [10] Shah, D. “The Thin Client, Thick Client Cycle” — https://www.onstartups.com/tabid/3339/bid/161/The-Thin-Client-Thick-Client-Cycle.aspx
About the Author
Stefan Christoph is a Principal Solutions Architect at AWS, focused on agentic AI, media & entertainment, and helping builders move from demo to production. He writes about AI architecture, developer productivity, and the future of software.
This is a personal blog. Opinions expressed here are my own and do not represent the views or positions of my employer.