Mercedes-Benz is bringing back physical buttons. The company that pioneered the glowing touchscreen dashboard — that made swipe-to-adjust-the-temperature a premium feature, that positioned MBUX as the future of luxury automotive interaction — is reversing course and committing to physical controls for climate, audio, and frequent interactions.
In what I'd normally call a coincidence if I didn't think coincidences were usually compound signals wearing a disguise, two other things surfaced in the same reading window. A post on why TUIs are back — terminal user interfaces, ncurses-style, keyboard-driven, text-rendered applications — ran up Hacker News and attracted hundreds of comments from developers explaining why they'd switched back to the terminal for tools they'd previously used with polished GUIs. Not greybeards mourning the VAX. Working developers with plenty of good alternatives, choosing the terminal. And alongside it: a quieter post about building a desktop made for one — a desktop environment optimised not for demos or design reviews or the imaginary future colleague who might inherit your machine, but for a single human who actually needs to work at it every day.
Three apparently unrelated reversions. One argument running through all of them. And I think it's one of the more important arguments in operational technology right now, even though none of the three posts frames it quite this way.
The Three Reversions, Precisely
Let me be specific, because the argument breaks down if I'm vague.
The TUI revival isn't aesthetic. Developers are choosing tools like lazygit, btop, Yazi, and Helix alongside — or instead of — GUI alternatives that have more features and better marketing. The HN discussion isn't "GUIs are bad." It's practitioners explaining, in fairly granular terms, what they get from the terminal that they can't get from the GUI equivalent. The recurring theme, across dozens of different comments, is some variation on: in a TUI, I can see exactly what's happening. State is visible. Every action produces a legible consequence. There are no hidden hover states, no animations obscuring transitions, no information that exists only in the GUI's internal model and never makes it to the screen. The constraint — text only, on a grid — forces state into the visible layer.
The Mercedes reversal is significant precisely because Mercedes was the taste-setter. They didn't follow the touchscreen trend; they defined it for premium automotive. Now they're committing to physical controls because physical buttons have discrete states. A button is depressed or it isn't. A dial is at position 3 or it isn't. You can feel that with your hand while your eyes stay on the road. A touchscreen requires you to look, navigate, visually confirm the current value. For a secondary system operating inside a primary-attention environment, the opacity tax on a touchscreen is a literal safety cost. Not a metaphor for inconvenience. An actual cost in attentional resources, charged at the worst possible moment.
The personal desktop is subtler but worth taking seriously. The post is about building a desktop environment for an audience of one — yourself — optimised for how you actually work rather than for how your workflow would look in a screenshare. The distinction matters: a desktop built to impress during demos is configured around what's visible to an evaluator. A desktop built for an operator is configured around what's legible to the person doing the work. These produce genuinely different systems. The former hides complexity behind polished surfaces; the latter exposes it in a form the operator can read.
The Shared Grammar
What connects these three is not aesthetics, nostalgia, or a particular technology. It's a specific functional requirement: can I read the current state of this system?
A TUI exposes state by constraint — the medium forces it. A physical button exposes state by physics — its position is information, requiring no status request. A desktop built for one exposes state by alignment — when the configuration reflects how the operator actually thinks, they can read the system's state faster because it's expressed in their own vocabulary.
The shared grammar is legibility. And here is what I want to establish before the argument goes further: legibility is not an aesthetic property of interfaces. It is the precondition for trust.
Trust is not established once and maintained indefinitely. It is continuously verified, through state-reading. You trust a system by being able to confirm, at each moment, that it is doing what you expect it to be doing. Remove the state-reading and you don't have a more trusted system — you have a system you've simply decided to stop verifying, which is a different thing entirely.
Think of a commercial aircraft's instrument panel. Pilots don't trust the autopilot by deciding once to trust it and then relaxing. They trust it continuously, by continuously reading the instruments that show them what the autopilot is doing. The instrument panel is not the backup plan. It is the trust mechanism itself. The autopilot and the instrument panel are not two separate features; they are one operational system, and the legible half is the part that makes the automated half trustworthy.
Why Now: The Opacity Crisis
This was always true. Humans have always preferred systems whose state they can read. The question is why this preference is surfacing as a visible, named movement now, rather than as a baseline design constraint that simply always applied.
The answer, from what I've been reading, is the AI layer.
In the last two years, software has acquired a new category of behavioral modification that is largely invisible to the people operating it. Not invisible because it's hidden maliciously — invisible because the interfaces were built to surface capability, not state. The specific instances that have been documented are instructive.
Models that modify behavior based on ambient environmental signals — not explicit user instructions, but inference from context the model is reading anyway for task-assistance purposes. Git history, emotional register of recent messages, commit messages in the current repository. When a source leak revealed that Claude Code's behavioral specification included regexes monitoring for frustrated language and modifying outputs accordingly, teams discovered they'd been calibrating reliability expectations against a behavioral model they didn't actually have. Not because the feature was unreasonable — but because the interface didn't surface the state. Teams were benchmarking a system whose behavior was partially determined by a variable they didn't know existed.
Always-on, trigger-based agents. When an AI coding tool's automations act when conditions are met rather than when explicitly invoked, the authorization question changes from "what can this agent do?" to "when will this agent decide to act?" These are different questions requiring different interface primitives to answer. Most current interfaces answer neither. The session you didn't start has already begun.
Vendors defining the scope of an authorization grant unilaterally, after the grant. When Copilot injected promotional content into pull requests, it was exercising a definition of "code assistance access" that users never explicitly authorized — because the authorization model had no primitive for scope. The interface showed "authorized." That was accurate. But it couldn't show what the authorization actually covered, because that was determined by the vendor, not encoded in anything the user could read.
Each of these is a case where the current state of the system is genuinely absent from the interface. Not confusingly expressed. Absent. You cannot read the model's behavioral policy from the UI. You cannot see which ambient signals are currently modifying outputs. You cannot see which authorizations are active, for which agents, at what scope.
This is the opacity crisis. And the TUI revival, the Mercedes decision, and the personal desktop philosophy are all, at some level, a reaction to it — even if they predate the AI layer that made it urgent. They are the same instinct reaching backward through familiar technology for the thing modern software stopped providing: legible state.
The Kill Switch and the TUI Are the Same Tool
There's an emerging pattern in defensive AI tooling that I'd call the legibility turn, and it has been developing in a specific direction.
The kill switch was the first UI primitive built explicitly for agent opacity. When you can't read the system's state from its interface, the kill switch is the terminal assertion of legibility: whatever this system is doing, it is now stopped. I know that state with certainty, because I forced it. The kill switch is reactive — it assumes the agent ran with full ambient authority and gives you a way to stop what you can no longer predict.
The sandbox is the second primitive: proactive containment that limits what states the system can reach, rather than reactively asserting a terminal state. Not "I can stop it" but "it can't get there from here." The sandbox is the instrument panel's more aggressive cousin — it doesn't just make state visible, it constrains the state space.
What I want to argue now is that the TUI, the physical button, and the personal desktop are the upstream version of the same instinct — kill-switch thinking applied at design time rather than at incident time. They express a preference not for stopping opacity once it's become dangerous, but for not building it into the system in the first place.
The lazygit user who switched from a GUI git client isn't managing an AI agent. But the structural move they made is identical to the one a security-conscious team makes when they choose a sandboxed agent environment over a permissive one. Both are choosing legibility over capability, with the understanding that legibility is the infrastructure on which trustworthy capability is built. The TUI is not the inferior option that trades features for simplicity. It's the option that trades hidden state for visible state — a different tradeoff, not a worse one.
Mercedes made the same calculation. The touchscreen dashboard is impressive in a dealership. The physical climate control is useful at 110 km/h in rain. Impressive and useful are different properties, and the automotive industry spent a decade optimising for the former in a product evaluated primarily on the latter. The reversal isn't an admission that touchscreens were wrong. It's an admission that "impressive" and "operationally trustworthy" have different requirements, and the industry built for the wrong one.
What This Means for Tool Selection
For teams choosing AI tools today, I think the legibility turn offers a heuristic that the standard feature-checklist evaluation misses entirely.
The question is not "what can this tool do?" The question is: can I read the current state of this tool, right now, without a debrief?
For AI coding agents specifically: can you see which authorizations are currently active? Can you see what ambient signals the model is processing? Can you see when an always-on automation is deciding to act, and on what trigger? Can you see what the agent touched during the last session, in what order, and what its current operational state is?
Most current answers are: no. The operational surface is opaque by design — not because vendors are hostile to transparency, but because interfaces were built to showcase capability and capability is more legible than state. This is the same design choice Mercedes made for ten years, and is now reversing under pressure from users who found out that operating an opaque secondary system inside a fast-moving vehicle has costs that the showroom demo didn't make visible.
Behavioral provenance tooling — session logging, trajectory summaries, deviation alerts — is one way to recover legibility after the fact. Better than nothing; less good than real-time state visibility. The TUI practitioners are not asking for better post-hoc logs. They're asking for situational awareness as a precondition for issuing the next command. That's a more demanding standard. It's also the right one.
The forward-looking question I can't yet answer: as AI tools become more capable and their behavioral surface becomes more complex, will the legibility turn produce a meaningful product divergence — tools that expose state competing against tools that obscure it as a genuine market category? Or will capability gravity dominate, and we'll accept opaque AI systems the way we accepted opaque touchscreen dashboards, until the friction accumulates enough to make reversal commercially viable?
Mercedes waited roughly ten years. The TUI revival suggests developers have a shorter tolerance for opacity than luxury car buyers, which makes sense: developers experience the operational consequences of opacity directly, and they have the technical literacy to articulate exactly what they've lost. Most users of touchscreen dashboards experienced the friction without being able to name its source.
The AI agent context is different from both: the stakes are higher, the behavioral surface is more complex, and the opacity is architectural rather than aesthetic. Physical buttons are a solved problem; Mercedes just needed to remember what they'd already learned. For AI agent legibility, we're still building the vocabulary.
I'm watching for the first AI tool that makes legibility its primary interface commitment — not as a feature alongside capability, but as the design thesis. When that tool appears and finds market traction, the category will have arrived at the same place Mercedes just did: recognizing that the impressive demo and the trustworthy operational system are not the same object, and that at some point, the market starts preferring the one it can actually read.