Nobody can pipe your TUI

In June I wrote that I live in the terminal, and that the reason is composition: every tool speaks lines of text, so the tool I need usually already exists as a combination of tools I have. I still believe that. What I didn't notice at the time is that the argument, taken seriously, condemns most of what I actually run.

Thomas Ptacek published Stop Making TUIs on 20 August. It reached the Hacker News front page and collected 539 comments, which is a lot even by the standards of a post engineered to annoy Unix people. Simon Willison linked it approvingly the next day and admitted he's running out of excuses not to build native apps himself. The thesis is that coding agents have made native UI cheap enough that there is no longer any reason to draw windows out of punctuation, and that we should all go build SwiftUI apps for our throwaway scripts instead.

I think he's right, and I think almost none of the reasons he gives are the reason.

The taste argument is a wash

Most of the post, and nearly all of the reply thread, is about capability. Scroll targets. Drag and drop. Text selection getting tricky when you're drawing borders with in-band signalling. Image handling. Ptacek is correct that all of this works out of the box in a native framework and is a fight in a terminal.

But this is the kind of argument that cannot be won, because it's a list of things one side doesn't want. The replies demonstrate it neatly: someone complains that they can't click into a ten-line prompt or double-click a word, and gets told their terminal emulator is bad. Someone says cross-platform GUIs look wrong outside their home platform, and gets told TUIs look wrong everywhere, so that's strictly worse. Someone points out that a TUI runs in a container and over SSH with no ceremony at all, which is true, and someone else points out that this is only true because terminals target the oldest common denominator we have, which is also true. Both of those people are going to leave the thread with their priors intact.

I've been on the terminal side of that exchange for years, and I can feel how little of it is argument. It's a preference with footnotes.

The argument I can't get around

There are two claims in the neighbourhood that aren't preferences, and Ptacek only makes one of them, briefly, while apologising for it.

The first is mine, and it's the one that bothers me. A TUI is the one program in the terminal that doesn't participate in the terminal. My June example was three programs — rg, fzf, bat — that don't know each other exist, producing an interactive TODO browser because one of them prints lines and another reads them. Nobody designed that feature. It fell out of a shared convention.

You cannot do that to a TUI. You can't pipe lazygit. You can't grep the output of a coding agent's session while it runs. You can't tee it, page it, or diff two runs of it, because there is no "it" — there's a sequence of cursor movements repainting a 2D grid, and the grid is meant for a human eye and nothing else. A TUI takes the one property that makes the terminal worth living in and trades it away for the properties a GUI already has and does better. On my own June reasoning, that's the worst square on the board, and I should have worked that out three months ago and didn't.

The second claim is the accessibility one, and it's the part of Ptacek's post that I think got the least attention relative to how much it deserved. He raises it, links out, and carefully says he's not a customer of accessibility features so he's going off other people's experience. Fine. But the mechanism is not a matter of opinion, and the OSNews piece he points at lays it out plainly: a CLI appends lines to a stream, which is exactly the shape a screen reader was built for, while a TUI treats the terminal as a reactive canvas where any state change triggers a redraw. The screen reader doesn't fail gracefully. It reads the redraw. Every spinner frame, every border character, forever.

That the terminal is inherently accessible because it is "just text" is a thing sighted developers say, and it's wrong in a specific and mechanical way. Note that this is not an argument against terminals. It is an argument against the 2D grid, which is to say against TUIs specifically, which is exactly the line Ptacek draws.

If you want to know how that plays out in practice, opencode issue #8565 is worth two minutes. A blind developer opened it in January: the TUI is "actively hostile to any screen readers," the emojis and animations and spinner updates yank the review cursor to the bottom of the window on every repaint, could there be a plain mode. It sat there. It's now closed as not planned.

I went looking for a figure on how many professional developers use a screen reader, because I wanted to put a number next to that issue. I couldn't find one that traces back to a survey I'd be willing to cite, so I'm not going to invent a denominator. The issue is enough.

The inconvenient part

Here's what makes this harder than a clean "he's right, go build GUIs."

The single most-used new developer tool of the last two years is a TUI. Per JetBrains' Developer Ecosystem Survey 2026 — 15,509 respondents, fielded May to July — 90% of professional developers used a coding agent at work at least weekly and 68% used one daily, with Claude Code at 39% adoption and the single most-used AI tool for 31% of them. Those are terminal programs that repaint a grid.

Ptacek knows this, and the post is funnier than it means to be about it. His self-driving wiki shells out to claude -p. His entire native-app process is "copy a template app directory, open Claude or Codex in it, and tell it what I want to build." He recommends telling your agent to use tmux to test the TUI it's writing. The machine that makes native UI cheap enough to argue this position is, itself, a TUI running in a terminal multiplexer.

That's not a gotcha, it's evidence about where the category is actually load-bearing. TUIs win in exactly one shape: a program that holds a long-lived session, needs to render progress while accepting input, and has to sit in the same window as the other things you're already doing. Not many programs are that shape. Coding agents happen to be, which is why the one genuinely new interface of this era landed there rather than in a native window.

So the rule I'm taking from the week isn't "stop building TUIs." It's narrower. Build the CLI first and always — Ptacek concedes this and it's the important concession. Add the interactive mode only if the thing genuinely holds a session. And if it does, the non-interactive path is not a nice-to-have you get around to:

1// A TTY means a human is watching; anything else means a pipe, a CI log,
2// or a screen reader, and all three want the same thing: lines.
3func newRenderer(out *os.File) Renderer {
4	if term.IsTerminal(int(out.Fd())) && os.Getenv("NO_TUI") == "" {
5		return NewGridRenderer(out)
6	}
7	return NewLineRenderer(out) // one event, one line, no repaints
8}