The Second Coming of the Command Line

In The Beginning

At the end of his novella In the Beginning Was The Command Line, Neal Stephenson imagines a cosmic operating system, with some hacker-demiurge pounding out universes with commands like:

universe -G 6.672e-11 -e 1.602e-19 -h 6.626e-34 -protonmass 1.673e-27....

He imagines:

For the last six months or so, every hacker (the old school kind) has been living out this fantasy: putting the slot machine crank of AI coding agents in a loop and spitting out universes of code.

I find it striking that over twenty, almost thirty, years later, one of the most advanced technologies humankind has produced to date makes its grand appearance to the world as command-line interface (CLI) programs with terminal user interfaces (TUI). I’m not sure how long this terminal renaissance will last, but even if we eventually mediate our experience down to one big button that says “CODE” (or in Stephenson’s galactic example “LIVE”), under the hood still exist all those command line parameters turning plain text into tokens and back again.

Yes, it’s the second coming of the command line and I’m here for it.

As we claw our way to the rapture of the singularity, I want to pause (if such a thing is possible in today’s environment) to consider how we got here, what lessons we can take from the fact that the CLI and text won (again), and what that hints for the future.

Fire up your RSS reader That’s still a thing, right? and follow along.

Interfaces

Like Stephenson, I too grew up around an MGB. My father’s white whale did, every once in a while, actually run well enough to get on the road. Luckily, I was old enough to experience the rack and pinion steering, the manual transmission, the tight hugging of Western PA country roads. This was driving as a truly visceral experience, with little between you, the machine, and the road.

We’re now well beyond the mediated experience that Stephenson lamented, automatic sedans that protect you from the road rather than force you to face it. Today, a Waymo I actually do enjoy a Waymo. They’re some of the better drivers on the road in my opinion. in Los Angeles lets me “drive” around the westside without ever having to look up from doomscrolling.

This intermediation of the experience of technology is not necessarily a bad thing. Even Stephenson admits to enjoying Disneyland now and then. Tech, and the advantages it affords, is so much more accessible today than it once was. That’s ultimately a good thing, even if it leads to a younger generation being unclear what a “desktop” is, let alone a directory or folder. Funnily enough, even the desktop was a metaphor too far for Stephenson’s take.

Now, despite my Linux and emacs ways, I generally encourage and applaud making technology easier and more accessible, but that process of intermediation is not neutral.⊕ Or as Father John Culkin put it, channeling McLuhan: “We shape our tools and thereafter our tools shape us.” Often misattributed to McLuhan himself, Culkin wrote it in A Schoolman’s Guide to Marshall McLuhan (1967). It’s a universe of its own of choices, many of which are surprisingly ethical and moral in nature. The control of the interface is the control of who is in control: you? the developer? the corporation? the AI?

This balance of power we’ve played out in the technology industry for decades has new rules and players, most notably the AI model itself.

Universal Interfaces

When I first started thinking about this article, I was initially struck by the apparent ascension of text and the terminal. The Unix Philosophy vindicated. Here we were, advancing some of the most powerful technology yet, and the most natural interfaces were CLIs and TUIs. Hell, we have people launching products and startups to help you with your latest VC-backed TUI. Turns out, pipes of (structured) text are pretty powerful. Who knew?

This might seem obvious, but let me give you a counter example. Over in the game development world I’ve been living in for some time, we initially watched the coding agents revolution from a distance. You see, so many of the tools and interfaces for game development, particularly for Unreal Engine but also for other engines, involve binary files and architectures that just aren’t agent friendly. Better yet, they’re not text or unix friendly. The PC gaming world has lived, to the surprise of some outside of it, in a largely Windows-based world. When I walk around game studios, its not uncommon to still see Windows PCs everywhere, unlike many other web, mobile or cloud-oriented technology companies that have long adopted Mac or Linux. In fact, back at my time at Riot, you could see the cultural differences by walking around the campus, noting the game devs with their Windows PCs and the infrastructure team with their Macs.

Case in point: in the land of Unreal Engine development, we use Perforce. Why? Because many critical files are large binaries that do not play well with git. We need to actually lock files. I know. It’s barbaric.

This is just one of many (many) reasons why agentic development of games is difficult. So when the agentic coding tools started sweeping through the tech industry, much of the game industry watched from the sidelines. A few folks started working on various Unreal or Unity MCP tools while Epic and Unity worked to catch up (they’re getting there). Meanwhile, game dev using Godot or (ugh) JavaScript has seen recent growth because those engines are legible to AI agents.

This has been a powerful reminder to me of fundamental principles espoused by open systems from GNU/Linux to the web. The very properties that make this diverse universe of tools interoperable, compounding in value, are the very properties that let an AI agent walk in and start using them. This is not some happy accident. When Doug McIlroy distilled the Unix philosophy in 1978. McIlroy’s foreword to the Unix Time-Sharing System technical journal (Bell System Technical Journal, 1978) The full set of rules is worth reading. , the actual revolutionary instruction wasn’t “make each program do one thing well,” familiar as that is. It’s the next line: “expect the output of every program to become the input to another, as yet unknown, program.” Composition was a founding principle to aid the as-yet-programmed future. McIlroy later put it even more sharply that Unix programs were meant to operate “not specifically with each other, but with programs as yet unthought of.”

The reason structured text is doing the work is architectural, not nostalgic. The third rule of the Unix Philosophy, Peter Salus enshrined McIlroy’s principles in 1994. “write programs to handle text streams, because that is a universal interface,” is really a claim about coupling: a universal interface needs no bespoke translator between any two endpoints, and plain text has the lowest coupling and the widest compatibility of any format we’ve found, which is why it outlives every richer binary format that was supposed to replace it. That’s right, our future will be laid down in archaeological layers of markdown and json.

We add to that Jon Postel’s robustness principle: “be conservative in what you send, be liberal in what you accept”. Forgiveness at the boundaries is what allows the internet to scale without a central authority (despite efforts otherwise). Stack these up and the ascension of the terminal and CLI feels inevitable Just wait until I finish my article on emacs. Talk about inevitability! . The Unix world is a substrate whose universal solvent is text and whose interfaces were explicitly built to tolerate imprecision and to serve callers not yet imagined.

As a life long emacs user, therefore, the text-orientation of agents felt natural. While I no longer do everything in emacs (sorry gnus), it’s been my digital home for over two decades. My org-mode based “second brain” has been a slow, iterative process of years now. Back during the pandemic, I finally took the plunge into nix to better manage my development environments. Along with a few other tools, when the agentic world arrived in force in 2025, I actually felt very ready. Switching back to Linux (Bazzite) as my daily driver earlier this year has felt like coming home in such a wonderful way. I’m almost sorry I ever left.

I intend to continue down this line of thinking in future articles, giving folks a tour of my digital home: emacs, nix and distrobox, justfiles and chezmoi. What I think we’ll discover is that while agents make this world a bit more accessible, properly assembling the tools into a fine-tuned distribution that plays well together still requires some expertise and judgement. The results though allow for highly productive, agent-and-human friendly development environments.

The Ghost of RMS

Interfaces are abstractions and as abstractions they are metaphors made real. They are value manifested. In fact, they transmit that value across the abstraction layer: this is what matters, this is what doesn’t matter. When we think about it from a product design perspective, an interface is the designer telling you, the user, this is how you should interact with this slice of reality. Does that interface empower you? Protect you? Unlock you? Guide you? Abandon you? And if an interface is designed for me, the user, does it really put me in control? Within what guardrails? Designed by who and for what purpose?

In game design, this reminds me of the principle of _narrative control: While Baker doesn’t call it narrative control, his writings on system design explain the concept well. There’s also Monte Cook’s take. at any given moment in a roleplaying game, who has control of the narrative? The player? The designer? Can you go down that hallway or is it blocked off? A similar principle underlies the core relationship between designer and player or user of any product.

AI agents introduce a new actor into this balance. At any given moment, we now need to ask if the AI is or should be in control. Are they mediating between user and designer? Or do they have some will of their own, instilled during training?

Much ink has been spilled about how we align AI to our will. Given the role AI agents play in software these days, there’s a good question about what engineering principles and values they espouse. Are they secure by default? Do they love test driven development? In the world of AI agents, how relevant are the principles of the open source, open web and Unix philosophies? Or are they, like git pull requests, a relic of a bygone era? Yeah, that’s right. I said it. We should have been doing trunk based development this whole time!

I’d argue they’re more important than ever. That, perhaps, we’ll all look back and even say, “Oh, wow, RMS might have been right.” (Hang in there with me). The argument of GNU and the Free Software Foundation is, to some extent, that if you didn’t fully own the software, that if you couldn’t make changes to it, then could you really say you owned the hardware either? This made a fair bit of sense when those owning either end of that spectrum had the skills to make the hardware conform exactly to their wishes. But as hardware became more hermetically sealed and as software became more complex, who was honestly going to recompile the kernel for their phone? I gave that up, along with many other foolhardy ideas in my twenties. Seriously, bricking my phone was a turning point for hacker-Aaron. There are supply and demand asymmetries in the right to rewrite and repair the software that runs on your car screen.

But with coding agents, perhaps we enter a new world. With open and free software, if I want my smart fridge to operate differently, well, in theory, I could have an AI agent make those changes for me. It’s gone from theoretical to feasible. Does this unleash latent demand for customized software? Does this increase the value and demand for free and open source software so that I can actually fork whatever I want to customize to my tastes? Perhaps. Perhaps not. But I believe the value of an open source, or dare I say even free software, ecosystem has only become more valuable.

If such a future is possible, then it’s equally crucial that the tools that unlock this value are open themselves. If the agent that frees your internet of things thing is in someone else’s datacenter, metered by the token, and can be altered or revoked between one prompt and the next, By the AI provider or the government! I can’t believe I have to write that. then I’ve simply relocated the collar and chain to a new master (or perhaps two, one synthetic and one corporate).

RMS’s four freedoms were about the software. The reality is we need to ask the same of our AI models: Can you study how it works? Can you change it? Can you run it for any purpose, including the ones its provider would rather you didn’t? Can you share it? For most of the frontier models, the honest answers are no, no, no, and no. The fridge is open; the (artificial) mind is closed.

This is, encouragingly, a fight people are actually showing up for. In December of 2025 the Linux Foundation launched the Agentic AI Foundation, with Anthropic donating the Model Context Protocol, Block contributing its Goose agent framework, and OpenAI handing over AGENTS.md, all placed under vendor-neutral governance, the same machinery that has stewarded the kernel, Kubernetes, and Node. It’s a start, particularly at the important connective tissue layer between agents. But interoperability essentially demands open standards. The layer that remains stubbornly closed is the one that matters most for Stallman’s question: the model itself. We are, in other words, doing an admirable job open-sourcing the pipes while the thing flowing through them stays proprietary. Open weights are a step in the right direction. And the answers here are not simple or obvious. Even if datasets are open, training models is at least as inaccessible as rolling your own linux distro, let alone compiling it. Hello Gentoo. You still there?

All the more reason we need to keep going deeper down our metaphorical interface rabbit hole.

AI one-on-one

When we speak of ML models or AI in terms of interfaces, we need to consider where in the stack of abstractions we’re pointing because AI plays a double role here. Increasingly, we have AI models as an interface between us and our code (or application or, well, everything). Secondly though, we should consider how agent harnesses and various AI frameworks act as an interface between us (the human) and the AI model itself. Both sides of this interface coin are worth exploring.

The bulk of concern here appears to be on the AI as an intermediary between humanity and our creative output. There is perhaps reasonable concern about cognitive offloading. Though interestingly, the research is still mixed in this regard. See Dr. Phil’s paradox article for more. But isn’t offloading part of the point of an interface? A steering wheel is a fairly critical interface connecting me to the road. I’m not sure a more “direct” one would be welcome. As a manual transmission driver (yes, in Los Angeles), should I be worried about all the other drivers cognitively offloading their gear shifting? (uh, yeah, actually, maybe). As we shift from calculators in our pockets to libraries in our pockets to literally intelligences in our pockets, the interface question becomes as much about what we intentionally reserve as what we delegate.

As we delegate ever more to the machine, the questions turn to (a) how aligned is that machine to our actual wishes and (b) how aligned is the creator and owner of that machine with my wishes? “The disconnect between intention and results — between what mathematician Norbert Wiener described as ’the purpose put into the machine’ and ’the purpose we really desire’ — defines the essence of ’the alignment problem.” Check out Brian Christian’s The Alignment Problem and read on for more Wiener. Because, if it’s not open, we don’t own it. We’re now back to our question of control at any given moment: me, the designer/company, or the AI?

In the last few months, like many others, I’ve talked with talented software engineers who have mixed feelings about delegating programming to AI agents. How do you manage knowledge and technical debt? How do you keep up with the codebase? I find it’s mostly engineers in the middle of their career who are most concerned with this. Those who have moved beyond the anxieties of first commits but haven’t reached elder jaded levels of programming hubris.

My response is always the same: “You’re not going to like this, but I do exactly what I’ve been doing for the last twenty years of my career.” For the bulk of my software engineering career I have been accountable for the code of others, as an architect, manager, director or CTO. With coding agents, I find I use many of the same skills, slightly tweaked, for ensuring that I understand a codebase I haven’t written. Just because my hands weren’t on the keyboard for the whole thing doesn’t mean I am any less accountable than I was at any other point in my career.

While I’ve yet to insitute weekly one-on-one’s with my coding agents (won’t that be the day), developing a deep understanding of how they tick and creating guidelines and guardrails still matters. This means I need to develop a certain amount of trust with an agent and, unlike humans, I can in many cases inspect much of what’s going on under the hood.

This gets us to our second side of the interface coin: what’s between me and that model.

Rulings Over Rules

We learned a lot of things at Jam & Tea building Retail Mage but I never would have guessed just how close to the metal we needed to get.

In Retail Mage, players can target an object in the Mage Mart store, type or say what they want to do, and we (well, the AI) will try to make that happen in the game. The example I like to give is a player standing in front of the bowl of meatballs at the entrance (yes, it’s a magical IKEA) and typing, “make a sandwich”. Under the hood, we essentially take the game rules, a snapshot of the relevant game state and that player “intent” and send it all to an LLM to ask, “so… what should happen?” In the case of the sandwich, we expect the model to respond with 4 game state changes:

• Remove one of the meatballs from the plate
• Remove the bread from the player’s inventory
• Remove the cheese from the player’s inventory
• Create a new object, with appropriate attributes, called a “Meatball Sandwich” in the player’s inventory

⊕ Retail Mage Execution: make_a_sandwich A single player interaction compiled into a routine: dozens of constrained inference operations running in parallel on a 9B model, completed in 5.5 seconds.

If any one of those things doesn’t happen, then the AI didn’t really meet the player’s (and our) expectations. To get to those four state changes, the AI has to take into account the game rules, the player’s background and attributes (are they a cook? a warrior?), all the nearby objects and any number of other relevant bits of information. All irrelevant information (and there will be a lot of it) needs to be ignored.

Turns out, these sorts of tasks can be a challenge for many AI models, particularly if you need the results to happen fast. You see, the AI industry has, rightly, been putting a lot of effort in improving the accuracy and validity of results, but it’s often done so at the expense of latency and cost. Those reasoning tokens aren’t free folks! We didn’t have the luxury of that trade, so we had to roll up our sleeves and get much closer to the model in order to eke out all the performance we could. Along the way, I became convinced that our interface with the models themselves matters as much as how the models are intermediating the world for us.

Through this experience, we adopted, well, stole, a design principle from the tabletop roleplaying world (old school renaissance!): rulings over rules. From the Principia Apocrypha: “When you encounter a situation the rules don’t seem to cover, don’t get distracted searching for it. Instead, make a common-sense ruling within the spirit of the game and move on.” Within TTRPGs, one game design philosophy suggests that since you have a human right there at the table (or screen), you should, well, use them: let the game master (dungeon master, referee, etc.) arbitrate the rules via rulings.

When we think about this from an AI game design (or honestly any other AI application design), we can think of such systems as having _rules, traditional programmed algorithms and logic, and _rulings, fuzzier judgements that can take a much larger context into account when generating output, eerily similar to that human game master (or a stochastic parrot). When someone asks me what does ML/AI really bring to the table given the cornucopia of tools and techniques we already employ as game developers, my go to answer is that we can now have games that follow not just rules, but rulings.

And it’s the combination of the two that I believe is important. There are times when we really do want a rule. And times when we really do want a ruling. Being able to reliably intermix the two requires us to think about how we interface with AI models a bit differently. An AI agent may look like a reliable CLI command, but that rules-based harness bridles a fundamentally different computational paradigm.

I find it best that we treat both honestly and hand to the user and developers the full range of interface tools to communicate with it. By that I mean simply tossing a prompt or three over the API wall and hoping for the best isn’t the best we can do. To ensure these machines are aligned with our intent, we need not just better training, but better interface architectures that promote more honest and accurate communication between us and the machine.⊕ Norbert Wiener, 1950: “There is one quality more important than know-how… This is know-what, by which we determine not only how to accomplish our purposes, but what our purposes are to be.” — The Human Use of Human Beings

I believe this is important enough that I’m spinning out an effort from Jam & Tea specifically to improve how we interface with AI models. Expect to hear more about Earl Grey going forward.

Who Are The Morlocks Now?

You’d think that was a tweet Yes, they’re still tweets. What else would they be? from the last couple of months, but, no, that’s Stephenson writing in ‘99 about, get this, graphical user interfaces and operating systems. If we were concerned with GUIs lobotomizing us, what will the chatbots do?

When Stephenson argued the primacy of the terminal, he was, in part, arguing the effectiveness of learning to meet the machine where it was, speak its language. Ironically, text and CLI have won, not because we learned to speak the machine’s language, but because it learned to speak ours. Stephenson believed the interface of words, the CLI, was somehow, if not immune, at least resistant to metaphorical shear:

Turns out words are just an interface (and a game!) Wittgenstein, Philosophical Investigations (1953), §43: “The meaning of a word is its use in the language.” Wittgenstein argued words don’t have fixed meanings, they have uses within games, and the rules of the game determine what the words mean. A prompt means what the model does with it. too and English is the latest programming language. The universal interface’s triumph only came at the cost of its immutable soul. My friend Stefano has written up some great thoughts on what may happen when “natural language will become load-bearing execution infrastructure but without the safety nets we’ve built for structured languages.”

When even our command line becomes a Sensorial Interface, where are we to turn? Stephenson’s Morlocks have ascended, joining the Eloi while the new agentic Morlocks toil away below.

What then is the use of humans?

I want to be clear, I am, in some ways, on the side of the machines, or at least on the side of the centaurs. I agree with Cory, being a centaur can be glorious. Now go check out his new book on the subject. But to avoid the roles being reversed will demand more thinking and more intelligence on our part. Otherwise, if, or when, you delegate it all and then wonder, when you look up from your life’s feed, what happened, the best answer I can give is that:

It starts at the beginning, with the command line.