I keep seeing the same thing as AI agents move into our daily work. Hand two equally capable engineers the same agentic coding tool in the same week, and one takes to it almost at once while the other keeps wrestling with it. They prompt, they get a mess back, they decide the tool is overhyped, and they go back to doing it by hand.
I think one important difference is whether the person is comfortable in the terminal rather than talent or years on the job. Living in a shell, piping things into other things, reaching for the command line before the GUI, build an intuition for agents fast. Living inside a polished IDE makes it a struggle to picture what the agent is even doing. Plenty of those IDE-first engineers are excellent, so why would terminal comfort matter for a brand new way of working?
This sound like that old game
I was talking this over with a friend and mentor who had landed on the same observation on his own. Then he said something that sounded like a joke and turned out to be the useful part of the conversation. "Maybe we should just make people play Zork."
For anyone who missed it, Zork is a text adventure from the late 1970s. No graphics. You read a description of a room and type what you want to do. "Open mailbox." "Go north." "Take lantern." A parser tries to make sense of your words, and the world answers in text. Get it wrong and it tells you, often with some attitude, that it has no idea what you mean.
His point (half jokingly) was that a game like Zork builds a specific set of mental muscles, and those muscles look a lot like the ones you need to work better with an AI agent.
What living in the terminal teaches
In 1978, Doug McIlroy summed up the philosophy behind Unix in a few lines that have aged well. Write programs that do one thing well. Write programs to work together. Expect the output of one to become the input of the next, because text is the universal interface. grep, sort, sed, awk are all modest on their own, but chaining them until a one-line incantation does what none of them could do by itself offers great power.
Spend years there and you internalize a way of thinking. You look at the small tools you have, work out how to compose them, track how state flows from step to step, and run a loop: execute, read the output, adjust, execute again.
You treat the system as capabilities you orchestrate, not buttons you press. And when the tools you have run out, you write a new one or install it. The toolbox is open, and growing it is a reflex.
Now look at what an AI agent is. An orchestrator with a set of tools. Each tool does one narrow thing: read a file, run a command, search the code, call an API. The interface between them is text. The whole thing runs in a loop: act, read the result, decide what's next.
The coding agents we use every day are command-line programs by design, because the shape of the problem is the shape of the shell.
The person who already thinks in tools, composition, extensions, and loops picks up an agent and recognizes the shape. The model is old. Only the surface is new.
Why an old text game maps onto agents
Ok, back to Zork.
A text adventure asks a lot of you. You can't see the world, so you build a model of it in your head from text alone and keep it current as you move. You don't know which commands the parser accepts, so you learn them by experimenting. You hold state across a long sequence of actions: what you're carrying, what you've solved, what's still locked. When the game says "you can't do that," you read it as feedback and try another phrasing.
Read that again with an agent in mind. You can't see what it sees, so you build a model of what it knows and refine it as you go. You learn the phrasings that work by trial and error. You manage context across a long back-and-forth. When it returns something confused, you read the failure as information and steer, instead of declaring the tool broken.
That last part trips people up most. Engineers who struggle with agents treat a bad response as proof the thing doesn't work. Engineers who thrive treat it the way a Zork player treats "I don't understand that": a normal step in the loop.
There's one place the game stops short. You can't teach Zork a new verb; its world is sealed. The terminal goes further: when the commands run out, you write the missing one, and an agent inherits this directly. Hand it a script you wrote or a tool you installed, and it can do something it couldn't a minute ago. Even here, though, Zork plants the seed.
The way you crack a hard puzzle is by importing knowledge from outside the game, what you know about how lamps, locks, and rivers behave, and bringing it to bear on the room in front of you. Writing a tool is that instinct grown up: you take knowledge the system doesn't have, a language, a library, a domain you know cold, and hand it over as a new capability.
We understand new things through what we already know
So why does prior comfort with this loop matter so much? The most useful thing I read on it wasn't about software.
In Why Don't Students Like School?, cognitive scientist Daniel Willingham makes a point that sounds obvious until you sit with it: we understand new things almost entirely in terms of things we already know. New, abstract ideas attach to the scaffolding already in your long-term memory. The richer the relevant background, the easier the new idea lands.
That's the real why under the whole pattern. For the terminal-fluent engineer, agentic development has somewhere to land. Tools you compose? Years of that. Text as the interface? Native language. A run-read-adjust loop? Tuesday. The agent slots into furniture already in the room. For the engineer whose whole model of programming is the visual, click-and-see world of a modern IDE, there's far less to attach to. They learn the agent and build the schema it rests on at once, which is harder, and says nothing about how good they are.
It also reframes the joke. You don't need fifteen years of shell scripting, just the schema: the felt sense of modeling an unseen system and iterating against its feedback. A text adventure builds that in an afternoon, through play, which teaches the transferable kind of understanding better than any guardrailed tutorial.
This isn't terminal worship
Modern IDEs are extraordinary. Seeing the thing you're working on and acting on it directly is one of software's genuine triumphs, and I use them too. The point is the mental model the terminal happens to teach, and you can carry that model into a windowed, agent-in-a-side-panel workflow without ever opening a shell. None of it requires you to live in bash.
That cuts against a comfort I notice in a lot of us, myself included. We've settled so far into our IDEs that we've stopped reaching for the flexibility underneath them. Borrowing the terminal's model, even a little, is one of the higher-leverage moves an engineer can make right now, because so much of what's arriving is shaped like it.
Open mailbox, go north
Looking back, my mentor wasn't really proposing a corporate Zork tournament (though I'd attend). The engineers best positioned for this stretch are the ones who can hold a model of tools running in a loop and steer it with intent, whatever editor they happen to use. The funny part is that we've been practicing for decades without knowing. Every piped command, every cryptic error read as a clue instead of a wall, every room imagined from a paragraph of text.
Perhaps the next time someone on a team keeps bouncing off agents, I'll hand them an old text game for an afternoon. Let them learn in the lowest-stakes way there is that you find the edges of a system by exploring it, and that "you can't do that" is the start of a conversation.
Open mailbox. Go north. See what happens.