Thomas Ptacek thinks you should stop defaulting to terminal UIs for your personal tools, and his reasoning is simple: LLMs changed the cost structure.

The traditional logic was sound. If you’re building something just for yourself, a TUI is the fastest path from idea to working software. You don’t need to learn a GUI framework, wrestle with layout engines, or figure out how to package a desktop app. You just print to stdout and you’re done.

But that calculus assumed you were writing all the code yourself. When Simon Willison vibe-coded a bandwidth monitor for his macOS menu bar back in March, he wasn’t fighting with AppKit documentation or debugging Auto Layout constraints. He had Claude write most of it. The result was a real native app that he still uses daily, and the friction to get there was low enough that he also built a GPU monitor the same way.

Ptacek’s argument is that this should be the new default. Not because TUIs are bad, but because the excuse for not building a proper GUI just evaporated. If you can describe what you want and an LLM can scaffold 80% of a working interface, why settle for less?

The pattern Willison describes is worth paying attention to. He’s not claiming the AI wrote perfect code that never needed human intervention. He’s saying the AI handled the boring parts, the boilerplate he’d never have bothered to write himself, and that pushed the project over the threshold from “nice idea” to “thing that exists.”

Learning still happens

One common worry about leaning on AI for code is that you stop learning how things work. Matt Webb pushes back on this. When he needed to implement 3D rotations for an app, he didn’t ask ChatGPT to write the quaternion math for him. He used it as a tutor to finally understand how quaternions actually work, after years of bouncing off textbooks and mathematician friends.

This matches what a lot of developers are finding: the AI doesn’t replace learning, it changes what you choose to learn and when. You can now build things that would have required mastering five different domains first, and then go back and learn the parts that matter to you. The bandwidth monitor doesn’t require Willison to become an AppKit expert. But if he wanted to understand how the rendering pipeline works, that door’s still open.

The quality question

There’s an obvious counterargument here. AI-generated GUIs are often kind of bad. They work, but they don’t feel polished. They handle edge cases poorly. They have weird bugs in states the model didn’t think to test.

All true. But that’s also true of most TUIs built by humans. The question isn’t whether AI gives you a perfect interface. It’s whether it gives you something better than the ncurses app you would have actually built, and whether the gap between “working” and “good” is small enough that you’ll close it.

For personal tools, the bar is low. You’re the only user. You know the workarounds. If the menu bar app crashes when you background it, you just don’t background it. That’s not acceptable for software you ship to other people, but for the scripts and utilities you build for yourself, it’s fine.

The interesting shift is that “good enough” now includes actual windows and buttons instead of just text on a black screen. That’s a meaningful upgrade, and it’s weird that it happened so quietly. We spent decades accepting that personal tools had to look like 1980s UNIX utilities because anything else was too much work. Now it’s not, and we’re still writing TUIs out of habit.

Maybe it’s time to stop.