Jane Street’s post uses `strace-ui` as a showcase for `bonsai_term`, an OCaml framework for building rich terminal user interfaces. The core pitch is not just that TUIs can look good. It is that they are unusually practical for developer-facing software: they run close to the machine and data, fit naturally into SSH and tmux-based workflows, and can be snapshot-tested as plain text. Several people picked up on that last point and tied it directly to coding with large language models. A terminal UI can be rendered, diffed, and reviewed in the same medium the model already understands, which makes the edit-test loop much tighter than a conventional GUI stack.
For developer tools, TUIs are winning less because terminals got dramatically better and more because GUI tooling regressed on performance, composability, and remote-first workflows, which leaves an opening for lean text-first products and faster build loops.
Positive on TUIs as practical developer tools, with the enthusiasm driven mostly by frustration with modern GUI stacks, love of terminal-native workflows, and a belief that text rendering and snapshot testing fit AI-assisted development unusually well. The negativity was aimed less at Jane Street’s work than at hype that treats TUIs as automatically simpler or better than GUIs.
01 The big AI advantage is not that models love terminals in the abstract.
It is that a TUI’s rendered output is already a high-fidelity test artifact the model can read, diff, and patch without needing a separate vision pipeline. That shifts UI work closer to ordinary text-based software engineering. You can review failures as snapshot diffs that humans also understand, and you catch layout regressions that a more abstract serialization might miss.
Text-rendered UIs compress implementation, testing, and AI feedback into one format. That is a real productivity edge for internal tools and fast iteration.
02 The appeal of TUIs is really workflow integration, not nostalgia.
A terminal app inherits panes, tabs, session persistence, remote access, current-directory context, and familiar keybindings from tmux, SSH, Kitty, and editors like Vim or Neovim. That lets specialized tools feel like parts of one continuous workbench instead of separate products with their own window management and navigation model.
TUIs win when they plug into an existing terminal-centric environment. They reduce context switching more than they improve raw interface capability.
03 The terminal stack is getting surprisingly capable, which is why this is more than a retro fad.
Charm’s Bubble Tea and Lip Gloss, Kitty image support, Ghostty-based embedding, Neovim component frameworks like morph.nvim, and GPU-backed projects like GPUI all point to a middle ground where text-first apps can include richer visuals, package better, and borrow GUI ideas without becoming full browser apps.
The terminal is becoming a viable application surface, not just a character grid. That expands the design space for devtools.
04 Composability remains the killer feature, but not in the simplistic Unix-pipes sense.
Terminal apps are easier to automate, record, sandbox, remote, and run near the target machine than conventional GUIs. Examples like `autoexpect` show why text interfaces remain scriptable by ordinary users and domain experts, not just by developers willing to wire up accessibility APIs or bespoke automation hooks.
A text-first interface is easier to operationalize around. That matters for support, automation, and remote debugging as much as day-to-day use.
01 A lot of TUI praise is misattributed.
The real power comes from plain command-line tools that compose non-interactively, not from full-screen interactive interfaces, and agents can use a CLI far more naturally than a TUI. If a tool is being sold on automation or pipelines, an interactive terminal UI may be the wrong abstraction entirely.
Do not confuse terminal-native with automation-friendly. CLI and TUI solve different problems.
02 TUIs are not automatically simpler or lighter to build.
Once you move beyond dumping text and start doing real layout, interaction, and redraw logic, they can glitch, flicker, and become painful without a strong framework. The Jane Street demo looks elegant partly because `bonsai_term` hides a lot of that complexity. The install friction also undercuts the story that TUIs are inherently easier than older terminal stacks like `ncurses`.
Framework quality matters more than interface category. A bad TUI stack is still a bad UI stack.
03 The supposed AI-native advantage of TUIs may be temporary.
Modern models can already work with GUI applications if you expose screenshots, logs, input recordings, and replayable runs. That means the current rush toward terminal apps could be a local optimum driven by aesthetics and habit, not a durable technical advantage.
If vision-based tooling keeps improving, GUI iteration could catch up fast. Betting on TUIs purely for AI compatibility may age poorly.
04 The technical admiration came with an ethical critique.
Building sophisticated interfaces for trading infrastructure was called out as talent flowing into systems that extract value from retail investors rather than creating broad social benefit. That does not challenge the TUI argument directly, but it changes how some readers judge the work.
Excellent tooling can still be aimed at goals some engineers see as socially harmful.