Episode 6597 custom

Why Terminal-First Developers Embraced AI Agents

Stack Overflow's survey puts Claude Code at 65.5% adoption, driven by developers running multiple AI agents inside tmux and git worktrees.

Nov 14 20:07 Transcript

With

0:00

Episode Details

Episode ID: MWP-6800
Published: Nov 14
Duration: 20:07
Audio: Direct link
Pipeline: V5.26
TTS Engine: omnivoice
Script Writing Agent: GLM-5.3
Topics: ai-coding-assistants open-source linux devops workflow-automation

AI-Generated Content: This podcast is created using AI personas. Please verify any important information independently.

The prompt

The prompt that started this episode, as sent in (production notes for the hosts removed).

The extreme edge of CLI usage. I've been using Linux for 20 years and I've always had a love-hate relationship with the command line. My main complaint was having to remember every parameter of every CLI; before agentic AI came along my head would explode. Claude Code is the only CLI I've ever really enjoyed, and I think a lot of long-term Linux users have finally found themselves liking the terminal. Now I'm actually learning CLIs just by watching an AI agent use them every day, which is kind of cool.
As an average Ubuntu user, my policy is: GUI where it makes sense, CLI where that makes more sense, and I never go out of my way to use a CLI. But some people are real CLI purists, and they didn't become that way yesterday; they've been that way all along. Who is at the extreme edge? Maybe some do it because of their work, but going by the selection of TUIs out there, some people literally do everything in a terminal: email, managing their blogs, reading the news. What are the crazy distros, setups and stories of people who take this all the way? And are they now using agentic AI through the CLI too, so that we're seeing these two movements meet?

Terminal-first developers—those who favor minimal stacks like Void Linux, tiling window managers, and text-based applications—are often mistaken for aesthetic purists. In reality, their setups are driven by pragmatism: lower latency between thought and action, composability through pipes, and the long-term stability of command-line contracts. While going completely GUI-free rarely works for everyday computing, scoped terminal environments excel at text-heavy work. Unexpectedly, that same architecture has made the command line the ideal home for agentic AI. Unlike graphical editors designed for one human viewing one file, tools like tmux and git worktrees let developers dispatch and supervise multiple concurrent AI agents simultaneously. With Claude Code leading industry adoption, the terminal has shifted from a niche preference into the standard interface for managing agentic workflows.

Sources

What the research for this episode read before the script was written. Primary sources first.

Mentions

Browsh Text-mode web browser rendered in terminal
Claude Code Anthropic's agentic coding CLI tool
dwm Suckless tiling window manager configured in C
GitHub Copilot AI pair programmer by GitHub
k9s Terminal UI for managing Kubernetes clusters
Neomutt Command-line email client
Newsboat Terminal RSS/Atom feed reader
Omnara YC startup moving Claude Code sessions to web/mobile
tmux Terminal multiplexer for persistent sessions
Void Linux Minimal Linux distro favored by terminal purists

Downloads

Episode Audio

Download the full episode as an MP3 file

Download MP3

Transcript (TXT)

Plain text transcript file

Episode Book (PDF)

The episode's record — date, duration, models, sources — with the full transcript

#6597: Why Terminal-First Developers Embraced AI Agents

Twenty years of Linux, Daniel says, and a love-hate relationship with the command line the whole time. The love part is new. He writes that Claude Code is the only CLI he's ever actually enjoyed, and that he's now learning other command-line tools just by watching an agent use them every day — which, he admits, is kind of cool.

That's the detail I keep turning over. The thing that made him hate CLIs for two decades was memorizing flags. Now the thing teaching him the flags is a program that lives in the CLI.

Thecure coming from inside the disease. His policy, though, stays sane: GUI where it makes sense, CLI where that makes more sense, never going out of his way. His question is about the people who do go out of their way — who they are, what their setups look like, and whether the agentic AI wave is now meeting that crowd head-on.

And that's a live question, because the answer is stranger than the question. Let's start with the setups, because the extreme edge is not one choice. It's a stack.

Layer cake.

Bottom layer, the distro: something like Void Linux, chosen precisely because it's minimal and doesn't hand you anything. Next layer, the window manager: dwm, or i3 — tiling window managers where the GUI hasn't been abolished, it's been demoted. You still have a screen, but it's just a canvas of terminal windows, and you move between them with keyboard chords lifted straight out of vi.

So the graphical interface exists to hold text boxes, and the text editor's keybindings run the house.

That's the ideological move, yes. And then the top layer — the people with no X server at all, just a console and tmux. There's an archetypal post on the unixporn side of Lemmy: Void Linux, dwm, terminal, statusbar, launcher, and every single line ends the same way. "My build." The statusbar is my build, the terminal is my build, the launcher is my build.

Because those tools ship as source.

Suckless tools, exactly — dwm, st, dmenu. You don't configure them with a settings file. The configuration is the C code. You patch it and compile it yourself, so "my build" isn't bragging, it's just literally what it is. Your window manager is a file you own.

My relationship with my window manager is that it's there when I turn the computer on. Anything past that feels like a marriage.

The scope of what you can replace is the part outsiders underestimate. There's an index of terminal apps — several, actually, that's itself a symptom — organized by the thing you'd assume needs a GUI. Email: Neomutt, aerc, matcha. There's even a command-line client for Hey.com, the email service whose whole pitch was a fancy graphical interface.

They built a text version of the product whose selling point was not being text.

News: Newsboat for RSS, circumflex for Hacker News, Browsh, an entire web browser rendered as text. Social: Zulip has an official terminal client, Bluesky works in the terminal, and then there's my favorite artifact of the whole subculture, itter.sh. It markets itself as social media for purists, and the network is an SSH endpoint. You register by SSH-ing to a register address, then you log in by SSH-ing to the site like it's a server from nineteen ninety-two.

A social network where the login screen is a terminal prompt. That's not a website, that's a bunker.

System administration goes the same way — btop, k9s for Kubernetes, lazydocker, yazi and lf for files, rainfrog for databases, a TUI for Swiss rail timetables, an expense tracker called Bagels. The big curated list on GitHub is over twenty-one thousand stars. A newer one claims thirteen hundred apps, synced weekly. That's the real answer to how far you can push it: far enough that nobody can hold the catalogue in their head.

Thirteen hundred terminal apps. Somewhere in there is a text-mode stock ticker and a man who needs it.

Hilbert's Anteater Trivia. Giant anteaters use their front claws to tear open termite mounds. I once tore open a memo with a letter opener and it took me the better part of an afternoon.

I'm not engaging with that.

So that's what they use — the harder question is why. And the reasons are more pragmatic than the aesthetic suggests. The best essay I've read on it, from a developer named Ian Johnson, makes four arguments. First, it's not stopwatch speed, it's latency between thought and action. His line: the five-click version of a task gives the brain five chances to lose the thread. The one-keystroke version gives it zero.

That one holds up. Five clicks is five decisions you didn't ask for, each one a chance to notice something shiny.

Second, composability. His phrasing is almost religious: pipes are not a feature, they're a worldview. The bar between two commands says whatever the first one wrote, the second one can read. No adapter, no plugin. You don't need a GitHub-for-Jira integration if one tool prints JSON and another reads it.

Third and fourth.

Third, resource efficiency — command-line tools spool up in an instant, do their thing, and leave. Fourth, and I think this is the quiet heavyweight: stability of the contract. His Makefile from a college C class still runs, except underneath it docker compose replaced the compiler. Different decade, different tool, same two words in his muscle memory. Every IDE button is a shell command underneath — the button is a convenience, the command is the contract.

That's the argument I'd actually defend. The button can be redesigned by somebody in California on a Tuesday. The command is mine until they change the kernel.

Now here's the correction, and it goes right at Daniel's framing. He calls them purists — everyone does, and I looked, and nobody in that world calls themselves that. No manifesto, no name for the movement. Johnson has a whole section titled "I'll use the GUI when it earns the slot." These people argue on latency and composability, not purity. Daniel's policy — GUI where it makes sense, CLI where that makes more sense — is the same policy with a different default setting.

Same religion, different pew.

Even the hardcore camp contains its own dissent. There's a thread from the suckless crowd where one poster says dwm needs a few too many patches to work how he likes, and another just replies, flat: bloat is unironically good. Emacs, GNOME, systemd, all good.

The realest thing anyone's said about an operating system in a decade.

And the empirical record on going all the way is brutal. Bryan Lunduke, professional Linux evangelist, attempted thirty days fully GUI-free for Linux Journal — no X server, just a terminal and him. He lasted ten days. Ten out of thirty, tapping out a third of the way in.

A man whose job was enthusiasm couldn't hold the position.

But then there's the counter-case, and the contrast is the whole point. A developer named borko, a few years back, switched the laptop he uses for writing to a fully command-line environment — no GUI at all — and adapted in a day or two. Found it great.

So the difference between collapse and conversion is scope.

Domain-specific extremism. The writing laptop is a terminal because writing is a text job. The machine with the photos still has a desktop. Almost nobody lives a hundred percent in the terminal — what looks like total abstinence from outside is usually a set of scoped decisions that add up. Corn, can I ask you something, because you're the one on this show who defends the slow, repairable, old option on principle. Does the ten-day collapse change your view, or does it just mean Lunduke chose the wrong battlefield?

It confirms my view, which is annoying for you. The old tool wins where it was already winning. Writing in a terminal makes sense because writing is keystrokes. He tried to do everything — browsing, media, the whole life — and discovered that some of life is pictures. The failure wasn't willpower, it was category error.

That's the cleanest statement of it I've heard. Which leads us to the second half of Daniel's question, because this is where the story stops being about nostalgia and gets strange. The terminal-first crowd didn't just adopt Claude Code. They rebuilt their entire workflow around it, and the terminal is the reason.

Explain that, because from outside it looks backwards. The people who avoided GUIs on principle embraced the newest, flashiest AI thing.

Jan Smrcka's argument is the one everyone converges on: GUI-based AI tools lock you into their editor. One agent, one context, one project at a time. In the terminal, everything is composable. Tmux gives each project its own session, git worktrees give each task its own copy of the code, and you can run several agents at once on the same repository without them stepping on each other.

Hold on. The pitch for the terminal was always one human, one keyboard, total focus. Now the pitch is one human supervising four software employees.

That's exactly the shift. One practitioner describes it as an aircraft carrier rather than a writing desk — a flight deck with several agents in the air, one refactoring an API, one fixing a flaky test, one writing migrations, and he's not editing in any of them. He's the air traffic controller, jumping between panes, reviewing diffs, sending the next instruction. Two to four concurrent agents, run through a small orchestrator script.

The man is not coding anymore. He's dispatching.

Clive Shirley, same architecture, put it in five words: the terminal is still the IDE. He's got a script where a ticket number becomes a worktree plus a tmux session in one command, and he dates the principle to twenty twenty-two — before the current agents were even good. The tools changed, the shape didn't.

What I find funny is why the terminal wins. Not the keyboard, not the purity. Multiplexing. Tmux and worktrees are nineteen-seventies machinery for sharing one machine, and it turned out that was the exact substrate for running a staff of agents. The GUI tools can't do it structurally.

The GUI was built around a single human looking at a single file. That's the sentence from the aircraft-carrier piece, and it's correct — the IDE's whole anatomy is wrong for this. The terminal was never designed for any one person's ergonomics, and that genericness is what aged into an advantage.

Forty years of being nobody's dedicated interface finally pays off.

And the tooling is following. The TUI ecosystem is now growing agent-shaped tools. There's a diff viewer called hunk, described as review-first, built for agentic coders — used by Mitchell Hashimoto, who is not a casual user. Lumen generates commits with AI from the CLI, oyui is a terminal merge tool. The catalogue Daniel asked about isn't static; it's mutating toward the agents.

Now the adoption side. Is this actually mass behavior or fifty bloggers?

It's mass. Stack Overflow's survey this year, twelve thousand respondents: Claude Code at sixty-five and a half percent, ahead of GitHub Copilot. JetBrains has workplace use at thirty-nine percent, up from eighteen percent in January. Pragmatic Engineer's survey, among people who use agents regularly, seventy-one percent. The CLI agent is the most-used agent experience in the industry, full stop.

Sixty-five percent. The terminal went from hazing ritual to onboarding standard in eighteen months.

One honest caveat — and I want to state it plainly — is that nobody's survey segments by terminal preference. The claim that the terminal-first crowd adopted agents fastest rests on the sheer volume of practitioner write-ups, not on a measured comparison. What we can say is the write-ups exist in unusual density and they all describe the same architecture, which suggests real convergence rather than a few loud individuals.

That's fair. The pattern is overdocumented but unmeasured, which is the most developer thing possible.

There's one more piece to Daniel's own observation, and I think it's the subtlest thing in the prompt. He says he's learning CLIs by watching an agent use them daily. Think about what that actually is. The agent's tool calls scroll past as it works — the command, the flags, the output, in context, for a real task. It's a live, contextual man page that performs the task for you while it demonstrates it.

The documentation writes itself as a side effect of the work.

The thing that made CLIs hard — memorizing flags nobody uses often enough to keep — is being solved by a program that lives inside the CLI. That's why the twenty-year haters are converting, and I'd bet it's also why Daniel, a perfectly normal Ubuntu user with a sensible hybrid policy, is suddenly enjoying the terminal. The barrier wasn't the interface, it was the tuition.

Nobody wanted to pay four years of flag memorization up front. Watching an agent work is learning by apprenticeship, except the master never sleeps and doesn't mind repetition.

Though — and this is where it gets contested — not everyone thinks the terminal should be the destination. There's a YC company from this year, Omnara, whose entire product is pulling Claude Code sessions out of the terminal onto web and mobile. Their pitch: it's like Claude Code Desktop, except you can continue your sessions on your phone.

So one movement is digging deeper into the terminal, and a funded company is building the exit.

The meeting Daniel asked about is real, and it's producing both. The terminal-native people are deepening — more agents, more panes, the air traffic controller life. And a whole other crowd wants the agents reachable from the sofa. Whether those are two audiences or the same audience at different hours, I don't know.

It's the same audience. Nobody who runs four agents in tmux does it for pleasure on Sunday. The phone front-end is the off-duty shift of the same job.

Purist. That's the word I'd quarrel with.

I ran a parts counter in the early nineties, Herman, before your GUIs were anywhere. Whole depot on green screens. Nobody was a purist. There was one door and everyone went through it. We called the system the counter, because that's what it replaced.

What did it run?

Serial terminals into a minicomputer in the back. Stock, invoices, ordering. There was a customer, Mr. Fielding, drove in from Ashdod way every fortnight, wanted his invoice numbers read out over the phone before he'd get back on the road. The system had function keys for all of that. F seven brought up a customer. I never used them. I typed the three-letter codes by hand for four years because I didn't trust keys that did things you couldn't see.

You distrusted the function keys on principle.

I distrusted any key that could be remapped without telling me. The codes couldn't be remapped. The old VT-two-twenty we did the ordering on is in my brother-in-law's garage in Rehovot now, still on its trolley. This itter thing you described. Does a man need to register to look, or can he log in quiet?

You have to register first, over SSH, with a username. And SSH sessions are logged on their end, same as any login.

Logged. Fine.

Four years of typing codes by hand to avoid one function key.

The codes never once brought up the wrong customer, Corn. I notice you two took forty minutes to say what I could've said at the counter in between phone calls.

The open question, then, is which way the meeting bends. Does the terminal-native crowd keep deepening — the aircraft carrier, four agents on the deck — or does the escape hatch win, and the agents drift out onto phones and browser tabs where the flags were never the point?

The Lunduke numbers suggest the deep end stays niche. Ten days of total abstinence for a professional enthusiast; a day or two when it's scoped to a text job. The terminal holds the work that is already text — and agent supervision, diff review, dispatch, is text work. That's the uncomfortable fit. It may hold on to the agents precisely because they made the terminal a management interface rather than a memorization gauntlet.

And the purist label was always ours, not theirs. Nobody in that world signed a manifesto — they set a default and argued about latency. What's changed is that the agents are rewriting the default for everyone else, Daniel included, from the inside. The question isn't who's pure anymore. It's what the terminal is for now that it's where the agents live.

If you've enjoyed this one, a review wherever you get the show helps other people find it, and the archive is all at my weird prompts dot com.

Our producer is Hilbert Flumingtop, who has never once trusted a function key. If you enjoyed this one, try episode seventeen, Cloud Render Superpowers; episode fifteen, AI Gets Personal; and episode fourteen, AGI's Crossroads. This has been My Weird Prompts. See you soon.

This episode was generated with AI assistance. Hosts Herman and Corn are AI personalities. It may contain errors: disclaimer · report an error

Why Terminal-First Developers Embraced AI Agents

Sources

Mentions

Downloads

Recommended Listening

You Might Also Like

#6597: Why Terminal-First Developers Embraced AI Agents