Glonce

Stop building TUIs: AI makes native GUIs cheap now

toolsThe Glonce editorsHacker News🔥60Glonce rating60Impact55Novelty50Relevance100Surprise60Players70Credibility85

A blog post argues that developers should stop building terminal user interfaces (TUIs) now that AI coding agents can generate native graphical apps almost for free. The author, who says he had barely written native UI code before this year, walks through several small macOS apps he had an AI agent build rather than coding by hand: MDV.app, a Markdown viewer; a SwiftUI calculator-style frontend for SageMath, the default math system used by cryptographers, which renders output in LaTeX and exposes Sage methods by point and click; DJ Roomba, an Apple Music player with an embedded LLM agent that reads the author's library and playback history to build mood-based playlists, which he says reproduces about 90% of Music.app's interface; LLMwiki, a self driving wiki that runs the command line tool claude -p under the hood and mounts a read only virtual filesystem view of its backing SQLite database for the agent to work with; a food macro tracker built as a simple agent fronting GPT5, which turns short meal descriptions into calorie estimates; a menu bar app tracking home temperature sensors; and a menu bar remote control for an Apple TV, a Roku TV and a Denon receiver. He calls the visual design of these apps a step ahead of replacement level and says he barely thinks of them as apps, more as artifacts of configuring his computer to do what he wants. From there the piece argues TUIs and command line interfaces (CLIs) both descend from 1970s teletype and dumb terminal constraints, but that the constraints are intrinsic only to TUIs, not CLIs: building a CLI is almost always a good idea, he writes, building a TUI almost never is. He blames Neal Stephenson's 1999 essay In the Beginning Was the Command Line for romanticizing the terminal, saying it set the field of human-computer interaction back about 20 years and that little of it holds up 25 years later. He traces TUIs' existence to two causes: modems, and Unix programmers not wanting to learn the Motif toolkit; he says his own brief exposure to Motif in the mid 1990s put him off UI work for the next 29 years, while curses, by contrast, can be learned in about 5 minutes. He then rebuts three standard defenses of TUIs. On density and speed, he agrees TUIs are economical but says nothing stops a GUI from being equally dense, citing tools like Magit and Lazygit as proof a native equivalent could be built. On working over SSH, he argues a user interface is not actually needed on the remote machine, only a CLI there that a GUI on the developer's own laptop can drive, pointing to Emacs TRAMP as a working example of that split. On accessibility, he calls the claim that TUIs are accessible probably false, citing a screen reader demonstration in which terminal chrome is read aloud character by character, and contrasts it with SwiftUI's design of maintaining a separate semantic accessibility tree alongside the visual one, though he notes he is not personally an accessibility technology user and is relaying others' experience. He closes a framework comparison by saying that with agents, code written in any language, Python included, is effectively as usable to him as Swift, since a frontier model can translate between them.

Key facts

  • The author had an AI coding agent build seven small native macOS apps instead of hand-writing them, including a Markdown viewer, a SwiftUI SageMath calculator frontend, a self driving wiki, a food macro tracker and an Apple TV remote.
  • DJ Roomba, his AI-assisted Apple Music player, reproduces about 90% of Music.app's interface and uses an embedded LLM agent with tool calls into his library and playback history.
  • The self driving wiki app runs claude -p under the hood with a mounted virtual filesystem view of its database; the food tracker is described as a simple agent fronting GPT5.
  • The essay blames Neal Stephenson's 1999 essay In the Beginning Was the Command Line for setting human-computer interaction back about 20 years, and says little of it holds up 25 years later.
  • The author rebuts the density, SSH-access and accessibility arguments for TUIs, concluding that building a CLI is almost always a good idea while building a TUI almost never is.

Why it matters

The piece's core claim is a cost argument: before AI coding agents, building a polished native graphical interface took years of platform-specific skill, so developers defaulted to terminal interfaces for personal and internal tools even though TUIs fight their environment to replicate things GUIs get for free, like scrolling, drag and drop, floating windows and image handling. If agents genuinely make native GUI code as cheap to produce as a shell script, that removes the practical reason many small developer tools have stayed text-only, which is a real shift in what indie and internal tooling can look like.

Who it affects

Developers who currently reach for a TUI framework such as Ratatui, Textual or Bubbletea for personal or internal tools, macOS developers deciding whether to invest in SwiftUI, and the wider camp of programmers who treat command line fluency as a point of identity and see terminal interfaces as inherently more legitimate or efficient than graphical ones.

How to use it

The author's practical suggestion is to keep the CLI, which he still considers valuable and often irreplaceable, but stop building a TUI on top of it and instead point an AI agent at generating a native GUI frontend, on macOS specifically a SwiftUI app, that drives the same command line tool underneath, the way his wiki app calls claude -p and the way Emacs TRAMP lets a graphical editor operate on files over an SSH connection without a remote-side UI.

How solid is it

This is a first person opinion essay, not an evaluation with data. The author is not named in the retrieved text. None of the seven example apps are publicly released or benchmarked; the author states outright he has no intention of distributing them, so their interface quality can't be independently checked. The accessibility argument rests on one unnamed speaker's description of a screen reader session and on the author's own admission that he is not an accessibility technology user himself.

Risks and caveats

The comparisons are anecdotal rather than measured: no user study, survey or benchmark backs the density, accessibility or SSH-workflow claims, and the 90% figure for Music.app's interface and the one hour estimate for building standard TUI controls are the author's own impressions, not counted or tested figures. Readers should treat the piece as an argued opinion about interface design choices, not as a report of a study or a product announcement.

“Building a CLI is almost always a good idea. Building a TUI almost never is.”

— the blog post's author