I want to be upfront about what this post is. It is not a manifesto. It is not a recommendation. It is a confession - a set of observations about what has worked for me over a long time, offered honestly, with full awareness that reasonable people land somewhere different.
With that said: I think we are doing this wrong, and I've thought so for a while.
The Terminal as Identity
Somewhere along the way, the developer terminal became a statement. Custom prompts with git branch indicators and battery levels and exit codes rendered in custom glyphs. Themes that require a specific font or the icons become boxes. Forty shell aliases. A .zshrc that takes fifteen minutes to reconstruct on a new machine and represents years of accumulated tweaks that nobody else understands.
I've had versions of all of this. I still have a prompt customization tool configured, if I'm being completely honest - the prompt, the git indicators, the whole thing. At various points in my career I've spent real hours tuning my environment, and I understand the appeal - it feels like craft, it signals membership in a community, and there is genuine pleasure in a well-configured tool. I'm not writing this from a position of purity. I'm writing it from a position of recognizing the pattern for what it is.
But here is what I've noticed: the developers with the most elaborate setups are sometimes the least portable. Sit them at a fresh machine - a client's laptop, a pair programming session, a new employer's hardware - and the first hour goes to configuration. Not to work. To making the environment feel like home before anything useful can happen.
That dependency is a cost, and it's a cost I've chosen to stop paying.
Default Is Not Laziness
The stock terminal. A mainstream editor with a handful of extensions - the ones that add capability, not the ones that change how things look. No custom theme. Default keybindings. The standard tools the ecosystem ships with, used as they were designed to be used.
This isn't laziness and it isn't lack of curiosity. It's a deliberate choice about where to spend the learning budget. Every hour spent mastering a custom setup is an hour not spent mastering the underlying tools. And the underlying tools transfer. The custom setup doesn't.
A developer who knows a mainstream editor deeply - the debugger, the built-in git integration, the terminal, the settings sync, the refactoring tools - can sit at any machine in the world with that editor installed and work at full capacity within minutes. That developer's skills are portable in a way that no amount of carefully tuned configuration can replicate.
The "any machine" test is the one I come back to. If you had to work tomorrow on a fresh install with only the tools that ship by default, how long before you're productive? That gap - between where you are now and where you could be - is the cost of the configuration you've accumulated.
TUIs Are Nostalgia in a Rust Crate
I want to say something that will upset people: the TUI renaissance is going backwards.
The git clients, the cluster managers, the beautiful terminal dashboards, the Rust-powered everything with box-drawing characters and vim keybindings and carefully crafted color schemes - this is genuinely impressive engineering. The developers who built these tools are talented and the tools themselves are often excellent. I am not saying otherwise.
What I am saying is that we have GPUs. We have native UI frameworks. We have high-DPI displays and smooth animation and the full capability of modern operating systems available to any application that wants to use it. And a significant portion of the developer tooling community has decided that the correct response to all of this is to draw boxes with ASCII characters and call it modern.
It isn't modern. It's 1987 with better syntax highlighting.
The terminal made sense when it was the only interface available. Today it's a choice - and for local development on a machine with a full operating system, it is often the wrong choice dressed up as craft.
The server argument is real and I'll concede it immediately: when you're SSH'd into a production machine at 2am, you're at defaults, and knowing the terminal deeply matters. But that's the server. On your local machine, with a trackpad and a Retina display and 64GB of RAM, reaching for a TUI because it feels like serious engineering is a different thing.
Plugins Are Technical Debt You Don't Track
Let me be precise here, because there's a version of this argument that goes too far. Modern editors sync your extensions across devices automatically, so the machine-switching problem is largely solved - what syncs with you is the list you've built, for better or worse. Extensions that earn their place are fine - more than fine. A bracket highlighter is a genuine quality-of-life improvement that costs almost nothing and saves real cognitive effort every day. Language support, a spell checker, a git diff viewer - these add capability the editor doesn't ship with and the case for them is obvious. I use them. It would be nuts not to.
The problem is a different category entirely: the editor you switch to because one feature went viral on social media. A new tool appears, it does one impressive thing, it gets screenshotted and shared and talked about for two weeks, and a certain kind of developer installs it immediately and reorganizes their entire workflow around it. Three months later the hype has moved on, the tool has a breaking update, and the workflow is half-dismantled.
A related one that has always puzzled me: the obsession with editor startup time. I open my editor at nine in the morning and close it at ten at night. Whether it takes 0.2 or 2 seconds to start is so far outside the list of things I care about that benchmarking it feels like measuring how fast a chair unfolds. The tools that lead with startup time as a selling point are usually the ones that don't have enough of the other things to talk about.
This is the menace. Not extensions that serve real needs - extensions and tools chased for their social signal rather than their utility.
The test is simple: does this solve a problem I actually have, or does it solve a problem I didn't know I had until someone on the internet told me I did?
The first category belongs in the editor. The second belongs in a bookmark you never open again.
Something New Is Forming
Here is where the confession gets more interesting, because I don't think the answer is "go back to the terminal and suffer virtuously." Something genuinely new is forming, and it's neither the old GUI nor the TUI revival.
Tools like Claude Code and Codex are not terminal tools pretending to be modern. They're not GUI applications pretending to be terminals. They're a different interface category for a different kind of work - AI-native, context-aware, operating at a level of abstraction that makes the question of "terminal vs GUI" feel slightly beside the point.
I find it meaningful that these tools are native applications rather than terminal wrappers. Not because native is inherently better, but because the people building them chose to use the full capability of the platform rather than retreating to the lowest common denominator. That choice signals something about where serious tooling is going - and it isn't toward more box-drawing characters.
What I Actually Do
For what it's worth: I work daily across Windows, macOS, and Linux. The native terminal on each of them is fine. More than fine - each one does what a terminal needs to do, and knowing that means I've never spent a day blocked because I was on the wrong OS. A mainstream editor with default settings and a short extension list I could rebuild in ten minutes. The standard CLI tools that ship with the OS or install with a single command. A prompt customization tool that shows me the git branch, the project context, the things I'd otherwise have to ask the terminal - a quality of life addition I could live without but choose not to. No theme beyond that. No aliases beyond the handful I've had for so long I can no longer imagine which ones they are.
I can work on any machine. I can pair with anyone without apologizing for my setup. When something breaks, I know where to look because I know what I've changed - which is almost nothing. When a new colleague joins, I can describe my environment in two sentences.
This is not the most impressive setup. It is not the one that gets admired at conferences or screenshotted for social media. It is the one that still works the same way after three years, after five machine changes, after a hundred "let me just SSH in quickly" moments. And when a colleague is stuck on something, I can help them directly - because we're both looking at the same tools, the same defaults, the same interface. No "oh, I have a plugin for that" that they don't have.
The best tool is the one you don't have to think about. Default settings are how a tool's authors intended it to be used, with the full weight of their design decisions behind them. Overriding those defaults is sometimes necessary. More often, it's a way of spending energy on the environment instead of on the work.
That's the observation. Take it or leave it.