DEV Community: Abdul Rehman

Don't Wait. Fork It.

Abdul Rehman — Sun, 26 Jul 2026 12:26:35 +0000

Nobody has ever asked you to upstream your dotfiles.

For thirty years that was the deal with every tool we touched: if you didn't like it, you changed it, and the change lived with you. Then the tools started writing the code, and the deal quietly ended.

This essay is about why the deal is back on the table. Because the thing that used to make forking expensive — the labour — is exactly what agents just made cheap.

The Workbench Instinct

Show me a developer who has never touched their config and I'll show you someone who hasn't started yet. Vim users brag about their init.lua the way woodworkers talk about a hand plane they've had for twenty years. Emacs people wrote a whole operating system inside a text editor because they could. VS Code won partly because it shipped an extension API and got out of the way. Dotfiles repos are public artifacts, starred and forked, because the setup is part of the craft.

This isn't productivity theatre. Some of it is genuine need, some of it is fixing a specific annoyance that only you have, and a lot of it is just fun. All three are valid. The workbench is where the joy lives — and nobody ever waited for permission to alias a command.

Then the Harness Era Arrived

Then agentic coding tools showed up and quietly changed the shape of the deal.

The best-in-class agent harnesses are increasingly vendor-controlled. Claude Code is a product, not a repo you can clone and rebuild. Google announced it's retiring Gemini CLI in favour of a closed-source successor. And note where the line falls: Codex CLI is Apache-2.0 and sitting right there on GitHub, but the Codex desktop app — the thing most people actually click on — is not. The terminal stayed open. The interface didn't.

Even the tools that are open source are moving fast enough that they aren't taking your patches. T3 Code's README says it plainly: we are not accepting contributions yet.

Now, let me be fair, because the lazy version of this argument gets torn apart in the comments. These tools are not closed boxes. Claude Code has a real plugin ecosystem — skills, subagents, hooks, MCP servers, marketplaces, thousands of community extensions. That's a genuine, generous surface area, and pretending otherwise is dishonest.

But here's the thing that actually matters:

An extension point is something you are granted. A fork is something you take.

A plugin API defines the seams the vendor chose to expose. Inside those seams you have enormous freedom. Outside them you have exactly zero. Take skills, since they're the best example of a well-designed extension point. You can write as many as you want. You cannot change how they get invoked — the matching logic, when the model decides one is relevant, what gets injected and in what order. You cannot change the UI at all: not the composer, not how a diff renders, not where the token counter sits. You can register a hook on PostToolUse. You cannot change how context gets compacted. You can add a slash command. You cannot change what happens when the model returns a malformed tool call at 2 AM on your production repo.

None of that is a complaint about the design. Those are reasonable places to draw a line — someone has to draw one. It's just that they drew it, not you.

Every extension system is a negotiation where only one side writes the contract. That was fine when the tool was a text editor. It's less fine when the tool is the thing writing most of your code.

Forking Was Always the Escape Hatch

None of this is new. The industry's answer to "the vendor won't ship what I need" has always been the same: take the code and go.

OpenOffice became LibreOffice.
MySQL became MariaDB.
Redis's license change gave us Valkey.
Terraform's gave us OpenTofu.
LinkedIn ran its own Kafka branch for years because upstream couldn't move at their scale.
Every serious low-latency shop tunes its own kernel, because the general-purpose scheduler was never built for their tail latency.

But look at what all of those have in common: they required a team. A fork wasn't a decision, it was a headcount. You needed people to maintain it, rebase it, patch its CVEs, and carry it forward forever. So the honest calculation for most of us was: I want this change, but I don't want it enough to own a fork for the next three years. And so we filed a feature request into the void and moved on.

That calculation is what changed. Not the licenses. The cost.

Code Got Cheap

The thing we're all slowly internalising is that the expensive part of forking was never the idea. It was the labour. Reading forty thousand lines of unfamiliar TypeScript to find the one place a menu gets populated. Understanding the build. Writing the tests. Doing the rebase six weeks later.

That's exactly the work agents are now good at. Not the creative part — the archaeology. Point an agent at a repo and ask where the composer's slash menu is assembled, and you have an answer in ninety seconds instead of an evening.

The New Calculation

# The old fork
idea → team → maintenance → rebases → three years of your life

# The new fork
idea → agent → a Tuesday afternoon

So the fork stops being a strategic commitment and becomes a Tuesday.

None of this removes judgment. The agent does the archaeology; you still decide what's worth changing, and you still own what lands in the repo. This is the same shift I wrote about in From Coders to Owners — the typing got cheap, the responsibility didn't move an inch. A fork just makes that concrete: AI writes the diff, you own the workbench.

What I Shipped Into My Fork

I've been running my own fork of T3 Code. It's public — github.com/arjunagi-a-rehman/t3code — and here's what I've shipped into it, for me:

1. OpenCode slash commands in the composer. The slash menu only surfaced built-ins — /model, /plan, /default. Now it discovers OpenCode custom commands: global ones from the config directory, and per-project .opencode/command/*.md files. A new providers.listProjectSlashCommands RPC resolves them against the thread's cwd — a file scan in local mode, command.list against the server in external-server mode. Project commands override snapshot commands on name clashes, matching OpenCode's own precedence. And a leading /name args on a fresh turn routes through session.command instead of getting shipped off as plain prompt text.

2. A custom app background image. Upload an image, stored on-device as a data URL, with adjustable opacity. The shell surfaces relax into a translucent scrim so it shows through.

3. Provider model filtering with bulk hide/show. Sub-provider filtering and hide-all/show-all controls, because the model catalogs have gotten absurd.

Three features. None of them proposed upstream. None of them waiting on anyone's roadmap. That's the point.

A Feature Does Not Have to Be Useful

Notice something about that list. Item 1 is real engineering. Item 3 is a real annoyance. Item 2 is a background image.

It saves me zero seconds. It ships nothing faster. It would not survive a single sentence of justification in a sprint planning meeting. I built it because I wanted the thing I stare at all day to feel like mine, and looking at it makes me feel good.

That used to be a completely normal reason to change software. Somewhere along the way we started requiring every change to defend itself in front of a productivity tribunal, and I think that's most of why the work stopped being fun.

Nobody asks a Vim user to justify their colourscheme. Nobody demands ROI on a custom prompt in your shell. The rice, the fonts, the transparency, the ASCII art on login — none of it was ever about output. It was about the fact that this is your workbench and you get to decide what it looks like. That instinct is the same one that eventually produces the good stuff, because a person who feels ownership over a tool starts noticing things a user never would.

So: build the useless feature. It's yours. That's the whole reason.

Your Desire Is the Limit

Once the fork is cheap, the constraint moves. It stops being can I and becomes what do I actually want.

Small example that bothered me for years: why can't an Express app produce an OpenAPI definition the way FastAPI does, from the code itself? Why am I hand-writing a YAML file that drifts out of sync by Thursday?

For most of my career the answer was: because that's how Express is. Now the answer is: write the middleware. Or fork Express, add the introspection at the router level, and run your fork. Both are afternoons.

Multiply that by every "why doesn't it just—" you've swallowed in the last five years. That backlog is the real opportunity here.

The Fork Is the Destination

Here is the part I want to be loudest about, because it's the part people get backwards.

Your change does not need to go anywhere.

It doesn't need to be merged. It doesn't need a PR. It doesn't need to be reviewed, approved, blessed, or accepted by anybody. It doesn't need to be good enough for strangers. It doesn't need a use case, a benchmark, or a paragraph explaining why it's valuable to the community.

You wanted something. You made it. You use it. That's the entire lifecycle.

We've somehow absorbed the idea that changing open source software means contributing to open source software — that the only legitimate endpoint for a diff is upstream. It isn't. Upstreaming is one option among several, and for most of what you'll build it's the wrong one. My background image should never be in T3 Code. It was never meant for T3 Code. It was meant for me, and it's already exactly where it belongs: in my fork, on my machine, running right now.

That's not a lesser outcome. That's the normal outcome. The fork is the destination, not a waiting room for the PR.

Nobody has ever asked you to upstream your dotfiles.

Now the Discipline Part

Which brings me to the thing I actually worry about, because "just fork it" curdles into something ugly very quickly.

Do not open a pull request as your first move. Please. Maintainers are drowning. Agents made it dramatically easier to produce a diff and did nothing to make it easier to review one, and that asymmetry is landing entirely on unpaid people. T3 Code, for the record, had hundreds of open PRs while explicitly saying it wasn't taking contributions.

So:

Default to your own fork. Ship it there. Live with it for a while. Most changes should stop here permanently, and that's fine.
Read CONTRIBUTING.md before you consider anything else. Every time. If it says no contributions, believe it.
Open an issue and ask before you build for upstream. Describe the problem, not your solution. Half the time you'll learn there's a reason it works that way.
Accept that what you want may not be what the project wants. That's not a rejection of you. A project has a scope, and a maintainer defending that scope is doing their job.

Contributing upstream is a generous thing to do when the change genuinely serves everyone and the maintainers have signalled they want it. It is not a tax you owe on every line you write.

And be honest about what a fork costs you, because it isn't free even now:

You own your security patches. If upstream fixes a vulnerability, you rebase or you're exposed.
Merge debt compounds. The further your fork drifts, the more each upstream sync hurts.
Keep your changes small and surgical. A patch that touches three files survives a year of rebases. One that restructures a module dies on the first major release.
Agent-generated code you haven't read is a liability you're choosing to install into the tool that has write access to all your repositories. Read the diff.

The rule I'd offer: fork freely, keep it, and upstream only when you're sure it's wanted.

Bring Back the Joy

The good news is that the open ecosystem didn't lose. OpenCode is the most-starred harness out there. Pi ships a genuinely minimal, forkable core built on the assumption you'll rewire it. T3 Code puts a real GUI over whichever CLI agent you feel like driving today. The escape hatches exist and they're good.

I've made my own small bet on that openness: the agent stack behind /agent on this site is a few hundred lines of open, forkable, markdown-driven code — I wrote the whole thing up in Software Can Talk. No vendor permission slip required.

What's missing isn't the tools. It's the habit.

We spent a couple of years being consumers of AI tooling — waiting for changelogs, upvoting feature requests, tweeting at vendors, accepting the shape of the thing we were handed. That was a reasonable posture when the cost of doing otherwise was a team.

It isn't a team anymore. It's an afternoon and a bit of nerve.

So stop waiting. Read the contributing guide. Open the issue. Fork the repo. Change the thing that's been annoying you for six months. Put a background image in it for no reason at all.

The workbench was always ours to build.

The Fork, at a Glance

How we went from shaping every tool we touched, to waiting on vendor roadmaps, to an afternoon being enough to take the workbench back.

Before — The Workbench

Dotfiles were public artifacts. Vim configs, Emacs operating systems, VS Code extensions. The setup was part of the craft, and nobody waited for permission to change their own tools.

The workbench was where the joy lived.

Dotfiles · Ricing · Extension APIs · Ownership

Harness Era — Granted, Not Taken

The best agent harnesses became vendor-controlled products. Plugin ecosystems are real and generous — but an extension point is something you're granted, inside seams someone else drew.

Every extension system is a negotiation where only one side writes the contract.

Closed Harnesses · Plugin APIs · Vendor Seams

Now — Code Got Cheap

The expensive part of forking was never the idea — it was the archaeology. Agents do the archaeology now. A fork stops being a strategic commitment and becomes a Tuesday. Judgment and ownership stay exactly where they were: with you.

Agent Archaeology · Cheap Diffs · Tuesday Forks

Next — The Fork Is the Destination

Your change doesn't need to be merged, reviewed, or blessed. You wanted something, you made it, you use it — that's the entire lifecycle. Fork freely, keep it, upstream only when you're sure it's wanted.

Nobody has ever asked you to upstream your dotfiles.

Default to Fork · Read CONTRIBUTING · Own the Diff

Software Can Talk — How the Wall Between Humans and Machines Finally Broke

Abdul Rehman — Fri, 01 May 2026 09:26:41 +0000

For seventy years, software was a wall.

You wanted something from a computer? You learned its language. You memorized syntax. You typed exact commands in exact order. You clicked the exact pixel. You filled the exact form field. One typo and the whole thing collapsed with a stack trace that may as well have been written in Latin.

We called this "using a computer." It was actually translation work. Every human who ever opened a terminal was a translator, converting their messy, ambiguous, human intent into the rigid grammar a machine could parse.

Then, sometime around late 2022, the wall cracked.

The wall, in three acts

Act I: Punch cards. You wrote programs by literally punching holes in paper. Get one hole wrong, your job died at 3 AM and you found out the next morning. The machine had zero tolerance for ambiguity because it had zero capacity for it.

Act II: The command line. Better. Faster. Still a foreign language. grep -rEi "pattern" . | awk '{print $2}' | sort -u is, objectively, magic — but it's also objectively not English. You had to become bilingual.

Act III: The GUI. The big democratization. Pictures, buttons, drag-and-drop. Anyone could use a computer now. But notice what didn't change: you still had to find the right button. You still had to know the menu lived under File > Export > Advanced > As PDF... You weren't speaking to the machine. You were navigating its map.

Every act got friendlier. None of them broke the wall. The human always had to meet the machine on the machine's terms.

What actually changed

The thing that broke isn't "AI got smart." That framing misses it.

What broke is this: for the first time, software can interpret intent.

You can say "find me the bug that's making logins fail on mobile" and a system can reason about what you meant, look at the right files, propose a fix, and explain its reasoning. Not because someone wrote a findBugInMobileLogin() function. Because the interface itself is now negotiable.

That's the shift. The interface used to be a contract — fixed, brittle, take-it-or-leave-it. Now the interface is a conversation. You bring your messy human request. The machine meets you partway. If it misunderstands, you correct it. If you're vague, it asks. If you change your mind, you say so.

This is not a small UX improvement. This is the inversion of seventy years of computing.

What it feels like to build now

I've been writing software for a while. The feeling of building today is genuinely different, and I want to name what changed:

You stop translating. You used to spend half your day converting "I want users to be able to undo their last action" into a state machine, a stack, a serialization format, a UI affordance, a keyboard shortcut, and seventeen edge cases. Now a lot of that translation happens with you, in plain English, and you spend your time on the parts that actually need a human — the taste calls, the product decisions, the architecture trade-offs.

The boundary moves. The interesting line used to be "what's possible in the language." Now it's "what's possible to specify clearly." If you can describe it precisely, you can probably build it. Which means writing — actual prose writing — is suddenly a software engineering skill. The clearest writers are shipping the fastest code.

Reviews matter more, not less. When the machine can produce 500 lines in 30 seconds, the bottleneck moves to judgment. Is this the right abstraction? Does this match how the rest of the system works? Will this be readable in six months? Those questions can't be outsourced. If anything, the premium on engineers who can answer them well just went up.

The thing nobody talks about

Here's what I think the next five years actually look like:

Software stops being something you use and starts being something you talk to. Not in a creepy "Hey Siri" way. In a "the dialog box is a chat" way. The form is a conversation. The settings panel is a request. The error message is a discussion.

This sounds dystopian if you imagine it badly. ("So now I have to small-talk with my spreadsheet?") But imagine it well: every piece of software you use has a knowledgeable colleague sitting inside it, and that colleague speaks your language, knows the docs, has read your code, and never gets tired. The wall is gone. You're not learning the software anymore. The software is learning you.

The implications for accessibility alone are enormous. Anyone who couldn't navigate a GUI — because of vision, motor control, language barrier, age, unfamiliarity — couldn't fully use computers. The CLI was even worse. Now? If you can describe what you want, the machine can probably do it. The set of people who can productively use software just got dramatically larger.

What this means for us

If you build software, the job isn't disappearing. It's changing shape.

The parts that were drudgery — the boilerplate, the glue code, the syntax-wrangling, the "I know what I want, I just don't remember the exact API call" — those parts are getting compressed. Good. They were never the interesting part anyway.

The parts that are getting bigger: figuring out what to build, why, for whom, and how it should feel. Taste. Judgment. Architecture. The ability to look at a working prototype and say "this is wrong, here's why, here's what would be right." That work is more valuable now, not less. Because anyone can produce code now. Producing the right code still requires a person who has thought hard about the problem.

The wall between humans and machines didn't fall because machines got more powerful. It fell because they finally got humble enough to meet us where we are.

That's the part that took seventy years.

That's the part that's worth paying attention to.

If this resonated, I'd love to hear what shifted for you. The first time the wall actually felt gone — what were you doing? What did it feel like?

From CLI to AI: The Evolution of How Humans Talk to Software

Abdul Rehman — Sun, 26 Apr 2026 02:29:55 +0000

Every time you type a command, tap an icon, or ask an AI to do something for you — you are participating in a conversation that started over a hundred years ago. A conversation between humans and machines. And the story of how that conversation evolved is one of the most fascinating, underappreciated narratives in technology.

This isn't a story that moves in clean chapters. The CLI never died when the GUI arrived. The GUI didn't vanish when touchscreens appeared. Each paradigm layered on top of the last, sometimes competing, sometimes merging, always reshaping how we think about what "talking to a computer" even means.

As someone who builds AI agent systems for production today, I find it essential to understand where we came from — because understanding the past interfaces tells you a lot about where the next ones are going.

In This Article

Iron & Paper: The First Inputs
The Green Glow: Birth of the CLI
The Visionaries: Xerox PARC and the GUI
The Great Interception: GUI Wars
The Connected World: Web & Mobile
The False Start: Chatbots Before AI
The CLI Never Died (It Won)
Talking to the Air: The LLM Era

Iron & Paper: The First Inputs
Before screens existed, before keyboards existed, the first human-computer interface was a physical one: holes punched in cardboard.

In the 1890s, Herman Hollerith built an electromechanical tabulating machine for the U.S. Census that used punched cards as input. You didn't "tell" the machine what to do — you physically encoded instructions into stiff paper, fed them through a reader, and waited. The machine's response was the click of mechanical counters.

This paradigm lasted far longer than most people realize. Through the 1950s, 60s, and into the 70s, programmers were still preparing stacks of cards, submitting them to operators, and coming back hours (or days) later for results. There was no "interaction" in any modern sense. You spoke, then you waited. The machine answered on its own schedule.

The punch card taught us something important: the interface is a bottleneck. The machine could compute faster than we could prepare instructions. The gap between human thought and machine execution would become the central tension of every interface revolution that followed.

The Green Glow: Birth of the CLI

The first real conversation between a human and a machine began with the teletype terminal — and later, the CRT (cathode-ray tube) monitor. For the first time, you could type a command on a keyboard, press Enter, and see a response appear on screen in real time. It was a dialogue.

But this dialogue came with strict rules.

The Command Line Interface was a conversation, but only if you had memorized the entire dictionary. You couldn't say "copy this file over there." You had to say cp source.txt /destination/ — exact syntax, exact order, exact grammar. One typo and the machine either did nothing or did the wrong thing.

bash
Terminal — circa 1985

$ ls -la /home/user/documents/
$ grep -r "error" /var/log/syslog
$ find . -name "*.c" -exec wc -l  \;
$ tar -czf backup.tar.gz ./project/
$ chmod 755 deploy.sh && ./deploy.sh

The languages evolved quickly. Assembly gave way to FORTRAN (1957), COBOL (1959), and BASIC (1964). These were remarkable acts of translation — allowing programmers to write something closer to English prose, which compilers would turn into machine instructions. The gap between human thought and machine execution narrowed.

Then came the operating systems that defined the CLI era: UNIX (Bell Labs, 1969) and MS-DOS (Microsoft, 1981). UNIX introduced the philosophy of small, composable tools piped together — a design pattern that still powers modern infrastructure. MS-DOS brought the CLI to millions of personal computers.

The CLI was powerful, efficient, and completely unforgiving. It demanded that humans reshape their thinking to match the machine's architecture. And it worked — for people willing to learn the grammar.

The Visionaries: Xerox PARC and the GUI

In 1970, Xerox — the photocopier company — founded a research center in Palo Alto called PARC. Their mandate was loosely defined: imagine the office of the future. What they actually created was the conceptual foundation of every graphical interface for the next fifty years.

The Xerox Alto, developed in 1973, combined several ideas that seem obvious today but were revolutionary then:

A bitmapped display — where each pixel on screen was individually controllable, turning the monitor into a canvas rather than a text printer
A mouse — Doug Engelbart's 1968 invention, refined by PARC into a practical pointing device
Overlapping windows — visual containers for different tasks, like papers on a desk
Icons and menus — visual representations of files and actions, activated by pointing and clicking
This became known as the WIMP paradigm: Windows, Icons, Menus, Pointer.

The underlying insight was profound: humans are not command parsers. We don't naturally think in precise syntax and directory hierarchies. We think in spaces, objects, and actions. We recognize things visually. We pick things up and move them. The Alto's interface tried to respect human cognition rather than demanding that humans reshape themselves to match machine architecture.

Xerox PARC had built the future. But Xerox the corporation couldn't see it. They were a copier company. The Alto remained a research project, never a product. The future they invented would be commercialized by others.

The Great Interception: GUI Wars

What happened next is one of the most consequential technology land grabs in history. Five factions saw the GUI's potential and each made a different bet:

Apple
Steve Jobs visited PARC in 1979 and immediately understood what he was seeing. Apple shipped the Lisa (1983) and then the Macintosh (1984) — the first commercially successful GUI computer. Their bet: vertical integration. Control the hardware, the OS, and the interface as one unified experience.

Microsoft
Bill Gates saw Apple's Mac and pivoted hard. Windows 1.0 shipped in 1985, rough and tiled. Windows 3.0 (1990) cracked the market. Windows 95 conquered it. Their bet: horizontal scale. Don't build the hardware — build the OS that runs on everyone else's hardware.

UNIX / MIT
The academic world built X Window System (1984) — a network-transparent windowing protocol. Their bet: separation of concerns. The display server, the window manager, and the application are all independent, interchangeable layers. Technically elegant, commercially fragmented.

Commodore / Atari
The home computer underdogs. AmigaOS (1985) had pre-emptive multitasking and a GUI years ahead of its time. Atari's GEM was fast and clean. Their bet: price performance. Get a GUI computer into homes for under $1,000. Both were eventually crushed by the Wintel juggernaut.

Xerox
The tragic irony. Xerox did ship GUI products — the Star (1981), priced at $16,000 per workstation. They aimed for the corporate market and priced themselves into irrelevance. The inventors of the GUI became a footnote in the GUI wars.

By the mid-1990s, the war was effectively over. Microsoft's Windows owned the desktop. Apple survived in creative niches. The GUI had become the default interface for a billion people. Point, click, drag, drop — these verbs replaced cp, mv, rm, and chmod in the public consciousness.

The GUI made computers accessible to everyone. But it also introduced a ceiling: you could only do what the interface designer had anticipated. The CLI had been unforgiving but unlimited. The GUI was friendly but bounded.

The Connected World: Web & Mobile

Two more revolutions transformed HCI in quick succession.

The Web (1990s)
Tim Berners-Lee's World Wide Web turned the interface into a shared, linked document. Suddenly the thing you were interacting with wasn't a local file or application — it was a page on a server in another country. The browser became the universal interface.

Web interfaces evolved from simple hypertext (click a blue link, go to another page) to rich applications (Gmail, Google Maps, Facebook). The line between "using a website" and "using software" blurred completely. AJAX, JavaScript frameworks, and eventually single-page apps made the browser as capable as native software.

Touch & Mobile (2007+)
The iPhone didn't invent the touchscreen, but it perfected the paradigm. Steve Jobs, in his original keynote, described the problem perfectly: existing smartphones used physical keyboards and styluses because they'd inherited the desktop metaphor. The finger, he argued, was the original pointing device.

Touch removed the last physical intermediary between human and interface. You didn't point at things with a proxy (mouse, stylus) — you touched them. Pinch to zoom. Swipe to scroll. Tap to select. The gestures were intuitive because they mapped to physical actions humans already knew.

By 2015, more people accessed the internet on mobile devices than desktop computers. The interface had literally moved into people's pockets — always present, always on, always listening.

The False Start: Chatbots Before AI
Before large language models existed, there was an earlier attempt at natural language interfaces — and it mostly failed.

Around 2015-2016, "chatbots" became a massive industry hype cycle. Facebook opened its Messenger Platform. Microsoft launched Bot Framework. Every enterprise software company promised that soon you'd just talk to your software instead of clicking through menus.

The problem was that these chatbots weren't intelligent. They were decision trees wearing a text input costume. Under the hood, they used keyword matching, intent classification, and rigid dialogue flows. If you said something the designer hadn't anticipated, the bot fell apart:

Typical 2016 Chatbot

User: "I need to change my flight to Tuesday"
Bot:  "I can help you with flights! Would you like to:
       1. Book a new flight
       2. Check flight status
       3. Cancel a flight"
User: "None of those. Change my existing booking."
Bot:  "I'm sorry, I didn't understand. Would you like to:
       1. Book a new flight
       2. Check flight status
       3. Cancel a flight"

The chatbot era taught us something crucial: a text input is not the same as understanding language. Putting a conversational UI on top of rigid logic just creates a worse version of both paradigms. Users got the frustration of strict syntax (like the CLI) combined with the bounded options of a GUI — the worst of both worlds.

The technology wasn't ready. But the desire was real. People wanted to talk to their software naturally. The industry was right about the destination — just a decade early on the vehicle.

The CLI Never Died (It Won)

Here's the plot twist most people miss: while the world was clicking icons and tapping touchscreens, the command line didn't just survive — it became more powerful than ever.

Every modern system that matters runs on CLIs under the hood:

Cloud infrastructure — aws, gcloud, az, terraform, kubectl
DevOps pipelines — every CI/CD system is a sequence of CLI commands
Package management — npm, pip, cargo, go mod
Containerization — docker build, docker compose up
Version control — git is a CLI-first tool; GUIs are wrappers around it
bash
Modern Infrastructure — 2026
Deploy an entire production stack with CLI tools
terraform plan && terraform apply
docker compose -f docker-compose.prod.yml up -d
aws ecs update-service --cluster prod --service api --force-new-deployment
kubectl rollout status deployment/frontend -n production
The CLI became the invisible infrastructure beneath every beautiful GUI. When you click "Deploy" in a GitHub Actions UI, it runs shell commands. When you drag a file into an S3 bucket in the AWS Console, it's calling the same API that aws s3 cp does.

The reason is fundamental: text is composable. You can pipe commands together, script them, version-control them, share them, and automate them. GUIs are designed for human eyeballs. CLIs are designed for both humans and machines. And in a world where automation matters more than ever, that distinction is everything.

As someone who deploys production AI agents with docker compose and manages fleet telemetry via aws iot CLI, I live this reality daily. The CLI didn't lose the interface war. It became the foundation the winners were built on.

Talking to the Air: The LLM Era

And now we arrive at the present — and what I believe is the most significant shift in human-computer interaction since the GUI. Not an incremental improvement. A paradigm break.

Large Language Models (GPT-4, Claude, Gemini) didn't just improve chatbots. They solved the fundamental problem that made every previous natural language interface fail: understanding context, intent, and nuance at a level that actually works. But here's what makes this moment truly historic — it's not just about better AI. The entire UI layer is being rewritten.

We are living through a shift as big as the one from CLI to GUI. And just like that era, different groups are adopting it at wildly different levels.

The New GUI War Is Happening Right Now
Think about what's changed in just the last year or two. This isn't theoretical — this is what's actually happening in teams right now:

Programmers
Many developers have stopped opening their code editor entirely. They describe what they need to Claude Code, Cursor, or Copilot Workspace, review the diff, and merge. The IDE isn't gone — but it's becoming a review tool, not a writing tool. The terminal prompt is the new IDE.

Product Managers
PMs now ask Claude Code to check the status of a sprint — "where are we lagging?", "which tickets haven't moved this week?", "summarize what shipped since Monday." They're getting engineering-level visibility without opening Jira or Linear. The AI is the dashboard.

Designers
Figma-to-code pipelines are becoming AI-mediated. Designers describe interactions in natural language, AI generates the component code, engineers review. The handoff document is being replaced by a conversation.

Non-Technical Users
Business users who never touched a terminal are now building automations, querying databases, and generating reports by describing what they want in plain English. The barrier between "technical" and "non-technical" is dissolving.

Sound familiar? It should. This is exactly what happened in the 1980s when the GUI arrived. Some people got it immediately (Apple). Some adapted fast (Microsoft). Some resisted and stuck with what they knew (the UNIX purists). Some were too early or too niche (Commodore, Atari). And just like then, the ones who adopt the new paradigm fastest will define the next era.

What Changed Under the Hood
The difference between the 2016 chatbot failure and today isn't just better NLP. It's the concept of AI agents — systems that don't just respond to queries but autonomously take actions:

text
2016 Chatbot vs 2025 AI Agent
2016 Chatbot

User: "Move my meeting with Sarah to next week"
Bot:  "I don't understand. Try: 'Schedule meeting' or 'Cancel meeting'"

2025 AI Agent

User: "Move my meeting with Sarah to next week,
       same time, and let her know"
Agent: Found: "1:1 with Sarah Chen" - Thursday 2pm
       Moved to: Next Thursday, 2pm
       Email sent to sarah.chen@company.com
       Calendar updated. Anything else?

The agent understands the goal, breaks it into subtasks, executes them using real tools (calendar APIs, email APIs, database queries), handles errors, and reports back. This isn't a demo — it's how production systems work today.

The Full Circle
Here's what fascinates me most: look at what's happening under the hood when a PM asks Claude Code "where are we lagging this sprint?"

text
What Actually Happens
PM types in natural language:
"Where are we lagging this sprint?"

AI translates to structured actions:

→ git log --since="2025-03-24" --oneline
→ gh issue list --label="sprint-12" --state=open
→ gh pr list --state=open --json title,createdAt
→ Linear API: GET /issues?sprint=current&state=started

AI synthesizes and responds:
"3 tickets haven't moved since Monday. The auth
refactor PR has been open 6 days with no review.
You're on track for 14/18 story points."
The PM speaks in natural language (the chatbot dream, finally realized). The AI translates that into CLI commands and API calls — the same paradigm from 1969. And the response comes back as a natural language summary — no dashboard, no Jira board, no chart to interpret.

The entire stack is present: natural language at the top, graphical feedback in the middle, command-line execution at the bottom. We didn't replace the CLI with the GUI, or the GUI with touch, or touch with AI. We layered them. Each generation of interface became the substrate for the next.

The programmer who used to type git log now describes what they want. The PM who used to open three dashboards now asks one question. The designer who used to write a handoff spec now describes the interaction. Everyone is converging on the same interface: just say what you mean.

What Comes Next?
If the pattern holds, AI-powered natural language won't replace GUIs or CLIs — it will layer on top of them, just like every previous paradigm. We'll still have terminals for composability and automation. We'll still have graphical interfaces for visual tasks. But increasingly, the entry point will be natural language.

The real question isn't whether this shift will happen. It's already happening. The question is which side of it you're on. In the 1980s, the people who clung to the CLI as their only interface got left behind — not because the CLI was bad, but because the GUI unlocked capabilities they couldn't see from the terminal. The same thing is happening now.

Developers who let AI handle the boilerplate ship faster. PMs who query their codebase directly make better decisions. Teams that treat AI as a team member, not a toy, are building things that were impossible two years ago.

The conversation between humans and machines started with holes punched in cardboard. It evolved through green-glowing terminals, graphical desktops, web browsers, touchscreens, and failed chatbots. Now, with large language models and AI agent architectures, the machine finally speaks our language.

A hundred and thirty years of iteration. Eight paradigm shifts. One ongoing conversation.

And we're just getting to the good part.