Meet the New Stack. Same as the Old Stack.

Seven dimensions of technology. Fifty-six years. Technology matures, accumulates problems, gets replaced by its opposite, which then matures, accumulates the same problems in reverse, and gets replaced again. This is not only history. It is a predictive framework — and right now in 2026, every row has swung back to where it started.

Seven dimensions, one pattern

The diagram tracks technology change across six independent layers of the stack simultaneously. Each row is its own story, but they all follow the same arc. Reading the table below left to right is reading the last five decades of computing in a single glance.

Interface: CLI vs GUI — the tension that never resolved

CLI vs GUI — the tension that never resolved

In 1984, Steve Jobs stood on stage and had the Macintosh speak its own name. The audience gasped. Jobs had seen the mouse-driven interface at Xerox PARC and understood what no one else did: the barrier to computing wasn't power, it was intimidation. Jony Ive carried this further — the iPhone's glass slab with no visible buttons, the iPad a three-year-old could unlock by instinct. Your grandmother could pick it up and video call you within a minute of holding it for the first time. No manual. No syntax. No fear. For thirty years, the GUI steadily made technology accessible to everyone on the planet.

GUI wins

• Apple and chief designer Jony Ive worked tirelessly perfecting every pixel, every gesture deliberate
• Pinch, swipe, long press — intention maps to result
• A grandmother can pick up an iPad and use it immediately
• Stripe dashboard — beautiful for non-developers
• The shop window: what the world sees

And then AI arrived and quietly handed the keyboard back. An AI CLI removes complexity entirely — you say what you want in plain English and the machine figures out the rest. The form is old. The power is new. The command line didn't lose to the GUI. It just waited for the machine to get clever enough to deserve it.

The command line was the original interface — and in the AI era, it is the interface again.

CLI — for AI and builders

• Xcode, Homebrew, Git, pipelines — all CLI
• ollama, pip, aws, gcloud, stripe — sometimes no GUI equivalent
• AWS Lambda configured one command at a time
• Stripe API + CLI — where developers actually integrate
• The engine room: what makes everything run

Why CLI understanding still matters in the AI age

The arrival of AI assistants that respond to plain English might suggest the CLI is finally obsolete. The opposite is true. Prompting an AI is structurally identical to writing a CLI command: precise input produces predictable output, vague input produces garbage. The developers who built their instincts on the command line write dramatically better AI prompts than those who never had to.

GUI made tech beautiful for users. CLI is still what builders use — and always has been, even at Apple. The engineers who built Siri, Face ID, and every app you love did it from a terminal. The question for the AI age is simple: do you want to use the tools, or build them? With AI everyone can become a builder.

Architecture: Edge computing — why compute is leaving the cloud again

Modern chips — Apple M-series, Qualcomm Snapdragon, NVIDIA Jetson — are powerful enough to run serious AI models locally, without a cloud round trip.

Architecture describes where the logic and processing in a system lives. In 1970, all processing happened on a central mainframe: the machine in the basement did all the work, and terminals on desks were dumb screens with no computing power of their own.

Desktop distributed means the PC era, where every desk had a machine capable of running software independently. Logic moved from the centre to the edges.

Cloud centralised reversed this: AWS, Google Cloud, and Azure concentrated computing back into a small number of enormous data centres, and applications ran on remote servers rather than local machines.

Edge computing is the current reversal. Processing is moving back to the device — your phone, your car, a factory sensor, a server in a telecom mast — because sending everything to a distant data centre turns out to have real costs: latency, bandwidth, privacy, and dependency on a network connection.

Why did we centralise to cloud first? Storage and compute were expensive, and sharing via central servers was cheaper. The internet made remote access fast enough for most tasks. Cloud let companies avoid buying hardware entirely. Those reasons were real and they drove a decade of migration.

Why is compute moving back? AI inference needs low latency — a self-driving car cannot wait 100ms for a cloud round trip before deciding whether to brake. Privacy regulation means Face ID, health data, and voice recognition must stay on the device and never reach a server. And chips have become powerful enough that the speed advantage of central servers no longer justifies the latency and privacy costs.

Real examples

• Face ID — the neural engine on your iPhone processes your face locally, with zero server contact
• Self-driving cars — all critical inference runs on hardware in the vehicle
• Factory sensors — detect faults locally and send only summaries to the cloud, not raw data streams
• Siri / Google Assistant — first-pass processing is now done on-device before anything reaches a server
• GitHub Copilot local models — code suggestions without sending your code to an external server

Mainframes (central) → PCs (local) → Cloud (central again) → Edge AI (local again)

Languages: C++ and Rust — performance back on the agenda

Close to the metal means a programming language that compiles directly to the machine's own instructions, with minimal translation layers between the code and the hardware. C and C++ are the classic examples: they give the programmer direct control over memory and processing, which makes programs fast but difficult and dangerous to write correctly.

Java and C# introduced managed runtimes — a layer between the code and the hardware that handles memory automatically. This made programming much safer and more productive, at the cost of some performance.

JavaScript and Python moved even further in this direction, prioritising developer experience and flexibility over raw speed.

Why did we move away from C++? Developer productivity mattered more than raw speed for most web and business software in the 2000s and 2010s. Cloud auto-scaling meant you could throw more servers at a slow app rather than optimise the code. For most use cases, Python was good enough.

Rust is the new answer to the old problem: it offers the performance of C++ with memory safety built into the language itself. In C++, a buffer overflow — writing past the end of allocated memory — is one of the most common sources of security vulnerabilities. Rust's ownership system makes this class of bug impossible to compile, without adding the garbage collection pauses of Java or Python.

Why is low-level performance critical again? Training a large AI model costs millions of pounds per run. A 2x speed improvement through more efficient code saves real money at that scale. LLM inference serving billions of requests demands maximum hardware efficiency. And WebAssembly now lets C++ and Rust run in the browser at near-native speed, opening the web to a new class of high-performance applications.

Real examples

• PyTorch / TensorFlow — Python API on top, C++ and CUDA engine underneath
• Chrome V8 engine — written in C++, running every JavaScript application you use
• Linux kernel — accepted Rust in 2022, the first new language added in 50 years
• Cloudflare Workers — Rust for edge functions, 10x faster cold starts than Node.js
• Figma desktop app — rewritten in C++ for performance, replacing the Electron version

C++ (fast, dangerous) → Java / JS / Python (easy, slower) → C++ / Rust (fast, now safer)

Network: Decentralisation — open vs walled, on repeat

Closed networks in the early era meant CompuServe, AOL, and corporate intranets: computers that could only talk to each other within a controlled, proprietary system. The operator decided what content existed and who could access it.

The open internet of the 1990s replaced this with a shared protocol stack (TCP/IP, HTTP) that any computer could join. No central gatekeeper decided what websites existed or who could publish. The web was the most radical decentralisation of information distribution in history.

Walled gardens are what the smartphone era built on top of the open internet: Apple's App Store, Google's Play Store, Facebook, WeChat. The underlying network remained open, but the majority of human attention migrated inside closed platforms that controlled distribution, payment, and what could be built. Platform owners could change the rules, take a 30% cut, or remove an app with a single decision.

Decentralisation is the current pushback. Federated protocols like ActivityPub (used by Mastodon) and AT Protocol (used by Bluesky) let social networks run across many independent servers with no single owner who can ban you platform-wide. Self-hosted AI means running models locally on your own hardware, with data that never leaves your machine. The EU's Digital Markets Act is forcing Apple to allow third-party app stores, breaking the most significant walled garden in consumer technology.

Real examples

• Bluesky / ActivityPub — federated social networks with no single owner
• Ollama / LM Studio — run Llama 3, Mistral, or Phi locally; data never leaves your machine
• EU Digital Markets Act — forcing Apple to allow third-party app stores from 2024
• MCP servers — your own AI tooling infrastructure, not locked to one vendor's platform
• Direct card acquiring — businesses moving payment processing off platforms to own the relationship

Closed networks (AOL) → Open internet → Walled gardens (App Store) → Decentralised protocols

Data: SQL is back — structure wins again

Flat files and spreadsheets were the original data storage: text files and Excel sheets with no enforced structure, no query language, no relationships between records. Simple, universal, and completely unscalable beyond a few thousand rows.

Relational SQL (SQL stands for Structured Query Language) replaced flat files from the 1980s. Databases like Oracle, SQL Server, and later PostgreSQL stored data in tables with defined columns and enforced relationships between them. SQL became the universal language for asking questions of data: SELECT, FROM, WHERE, JOIN. It was powerful but rigid — adding a new column or changing a schema required careful planning and often downtime.

NoSQL (Not Only SQL) was the web-scale response. When Facebook needed to store billions of rows changing by the second, or Amazon needed a shopping cart that could survive a database server going down, relational databases struggled. NoSQL stores like MongoDB, Cassandra, and Redis abandoned rigid schemas for flexibility and horizontal scaling. JSON — the data format used by APIs and web applications — mapped naturally to document stores, avoiding the translation layer that object-relational mappers required.

DuckDB is the most visible symbol of SQL's return. It is an in-process analytical database: it runs inside your Python script, your laptop, or your browser tab, with no server to install or manage. It can query Parquet files, S3 buckets, Pandas DataFrames, and CSV files directly, using standard SQL, faster than most purpose-built NoSQL analytics stores. The data quality disasters of the NoSQL era proved that schema enforcement is not bureaucracy — it is correctness. Analysts discovered that schemaless flexibility meant inconsistency, which meant wrong answers.

Real examples

• DuckDB — SQL on local files with no server; data scientists replacing Pandas for analytics
• SQLite — the default database in iOS, Android, Firefox, Chrome, and Python's standard library
• Postgres resurgence — engineering teams migrating back from MongoDB after schema chaos
• Cloudflare D1 — SQLite running at the edge in 300+ global locations
• LLM tool use — AI agents query databases using SQL, not bespoke NoSQL APIs

Flat files → Relational SQL → NoSQL / JSON → SQL back (DuckDB, SQLite)

Code: Vibe coding — manual to automated and back to intent

Manual coding meant writing every instruction yourself — you owned every line, and if it broke, you knew exactly why. Visual tools in the 1990s (Visual Basic, Dreamweaver) let non-programmers build by dragging components; no-code platforms in the 2010s took this further, running entire businesses without traditional programming. Vibe coding is the AI-era equivalent: describe what you want in plain English, and the machine writes the code. The cycle closes — you are back to specifying intent and reading output, exactly as in the CLI era, except the interpreter now understands English.

But the guard rails still apply. AI can write and run code — the developers who understand what correct code looks like are the ones who catch mistakes before they reach production. The tools change; the need to understand what the tools are doing does not.

What this means for anyone building today

The diagram is not a history lesson. It is a map of where pressure builds. Every centralised system creates the conditions for its own decentralisation. Every abstraction that makes things easy accumulates the technical debt that makes performance critical again. Every walled garden creates the platform risk that drives migration to open protocols.

Right now in 2026, the AI era looks structurally like the mainframe era of 1970 across nearly every dimension: a text-based interface, centralised Unix infrastructure, close-to-the-metal languages for performance, and code that you specify rather than write. The tools are unrecognisably more powerful. The underlying structure rhymes.

The engineers who understand the cycle see further. Today's centralised AI infrastructure will predictably create the cost and dependency pressures that drive the next push toward on-device, self-hosted models. Understanding why the last reversal happened is the clearest guide to when the next one will.