Familiarity feels like control

Open Cursor, Claude Code, and Codex side by side.

Really look at them.

File tree on the left. Editor in the middle. Chat panel on the side. Tab completions as you type.

Three companies. Billions in funding. One interface.

They are almost completely indistinguishable.

And that’s not a coincidence. That’s the same instinct that’s been keeping developers glued to a command line interface designed in the 1970s playing out at a product level.

The instinct is this: when everything is changing fast, familiar feels like control.

It isn’t. But it feels like it. And that feeling is powerful enough to shape an entire industry’s sense of what good software looks like - including the tools that are supposed to be replacing everything.

I’ve built products and shipped systems. I’ve lived inside software long enough to know when something is solid and when it’s just wearing the costume of something solid.

This piece is about the costume.

The command line is the oldest and most successful example of it. Let’s start there.

What the CLI actually is

It’s ugly. Genuinely, structurally ugly. Not in a rough-around-the-edges way. In a “this was designed for a different era and has not evolved” way.

It’s hostile. Not incidentally hostile. Purposefully hostile to anyone who hasn’t memorised its specific vocabulary. One wrong flag and you get an error message that assumes you already know what went wrong. One misplaced argument and you’re debugging output you can barely read to understand a problem you wouldn’t have had in a better-designed tool.

It hides state.

At any given moment in a terminal session you have a limited window into what’s actually happening. What’s running. What’s failed silently. What’s queued. The terminal shows you none of that unless you ask for it, in the right syntax, at exactly the right moment.

It punishes curiosity.

Try something you’re not certain of in a GUI and the worst case is usually reversible. Try it in a terminal and you might have just deleted a directory, overwritten a file, or killed a process that was doing something important.

The learning curve isn’t a curve. It’s a wall.

None of that alone makes the CLI bad. Plenty of genuinely good things are uncomfortable.

But discomfort is not intention. And for decades we’ve been confusing the two.

The lie we told ourselves

We had a working theory in software for a long time: if something was hard to use, it was probably serious. If it required memorisation, it was probably deep. If it resisted casual engagement, it was protecting something important underneath.

That theory hardened into orthodoxy.

Friction meant rigor. Complexity meant capability. The learning curve was proof there was something worth learning.

An entire generation of builders organised their professional identity around fluency in hostile tools. The terminal became not just an interface but a credential.

If you could move fast in it, you signalled membership. If you couldn’t, you were an outsider. A user. Someone who needed a GUI because they couldn’t handle the real thing.

That worldview made sense when skill was genuinely scarce. When the ability to write a bash script or chain commands through pipes was a real differentiator. When output was the bottleneck and fluency in the tool that produced output was the thing worth measuring.

AI collapsed that scarcity almost overnight.

What AI actually exposed

AI didn’t make software worse. It made visible how little structure most software had to begin with.

Syntax no longer signals competence.

Scaffolding is cheap. Anyone can generate a working script, a functional API call, a correct chain of commands, without knowing the underlying language. The knowledge that used to take years to accumulate can now be retrieved in seconds.

So what’s left? What do you point to as proof that you know what you’re doing when the knowing has been commoditised?

Predictably, people reached for the last interface where effort still shows.

The terminal.

Not because it’s faster in the age of AI. Not because it’s clearer. But because it still feels earned. Because moving fluently through a terminal session looks like expertise even when it isn’t. Because the aesthetics of competence survived long after the substance of it was gone.

This is why there’s a strange renaissance of CLI tools in the AI era. Developers wrapping AI agents in terminal interfaces. Building chat-adjacent systems that preserve the look and feel of command-line work. Not because the CLI is the right interface for AI-assisted workflows - in most cases it demonstrably isn’t. But because it protects the feeling of control when the ground is moving.

I’ve watched teams bolt AI agents into CLIs specifically to preserve the feeling of control rather than gain actual control.

The interface choice wasn’t technical. It was psychological.

The problem with chat

Before I’m accused of being a chat evangelist: chat isn’t the answer either.

Chat reveals things. State. Gaps. Uncertainty. It makes visible exactly how unclear your thinking is, which is useful for some things and actively counterproductive for others. When you’re executing a known process reliably, you don’t want a conversation. You want determinism.

The criticism that chat is sloppy isn’t wrong. It’s imprecise. It invites drift.

But here’s what CLI defenders get wrong: precision doesn’t come from a text interface. It comes from constraints. Good systems are precise because they’ve been designed to be precise - because someone decided what matters and removed everything else.

The terminal isn’t precise because of the terminal.

It’s precise when someone wrote precise tooling that happens to live there.

You could write equally imprecise tooling in a terminal. And plenty of people have.

The tools are doing it too

Here’s the part that doesn’t get talked about enough. The familiarity instinct isn’t just happening at the individual developer level. It’s happening at the product level. And the evidence is right in front of us.

Pull up Cursor, Claude Code, and Codex side by side. Look at them properly. A file tree on the left. A code editor in the middle. A chat panel on the side. Tab completions as you type. The interfaces have converged so completely that the screenshots are almost interchangeable. Three different companies. Three different models underneath. One visual language, copied back and forth until the tools are barely distinguishable.

This is not a coincidence. It is the same familiarity instinct playing out at a product design level. Each of these tools launched into a market of developers who expected a certain shape of thing. Nobody wanted to build the AI coding tool that felt alien. Nobody wanted to be the company that asked developers to fundamentally rethink how they interact with code. So everyone orbited the same centre of gravity - the editor metaphor, the chat metaphor, the terminal metaphor - and iterated within it until the tools blurred into each other.

The result is genuinely strange if you step back and look at it. The most significant shift in how software gets built in thirty years, and the interfaces we’re using to do it look almost identical to what existed before. We put AI inside the costume of familiar tools and called it a revolution.

But the costume is doing a lot of work here. If you stripped away the AI capabilities and just looked at the interface - the spatial layout, the interaction patterns, the way information is presented - you’d struggle to make a case that anything fundamental had changed. The editor is still the editor. The terminal is still the terminal. Chat got added. That’s mostly it.

What nobody is seriously asking is whether the right interface for AI-assisted development looks like a code editor at all. Whether the editor metaphor is just as historically contingent as the terminal metaphor - a design decision made in a different era for different constraints, carried forward not because it’s optimal but because changing it is commercially risky and nobody wants to be first.

The tools that converge on familiarity are easier to sell. They feel like upgrades rather than replacements. They don’t ask you to change how you think. But “easier to sell” and “actually better for the work” are not the same thing, and right now the market is very efficiently optimising for the first one while not asking hard enough questions about the second.

What’s actually missing

This is where I want to spend a moment, because I think it’s the part of this conversation that gets skipped most often.

The real failure of both the CLI and chat as dominant paradigms isn’t that they exist. It’s that we’ve treated them as the only two options when the actual need is something neither of them serves well.

What most serious builders actually need isn’t a conversation and it isn’t a command prompt. It’s something closer to a workspace. A canvas with edges. A system where actions are explicit, history is visible, state is legible without ceremony, and the relationship between what you did and what happened as a result is always clear.

Not a terminal that forces you to remember. Not a chatbot that forgets. Something with shape. Something that decides what matters and surfaces it. Something where you can see where you are, what changed, and why - without having to ask for it in the right syntax or dig through scrollback.

Calm systems don’t shout. They don’t flex their power at you. They don’t reward activity for its own sake or make you prove your membership before they’ll help you. They feel boring in screenshots. They feel obvious when they’re right.

Most tools don’t aim for that because boring doesn’t signal intelligence. Noise does. Complexity signals seriousness. A dashboard full of numbers feels more capable than a clean interface that shows you exactly what you need to know. But the clean interface is harder to build and harder to sell because it requires someone to make actual decisions about what matters.

The DevClocked bias

I work on DevClocked because I care about signal over noise. Not time tracking. Not streaks. Not vanity metrics that make you feel productive while you’re moving in circles. Actual work that held together long enough to mean something.

That bias leaks into how I think about interfaces across everything I build. I don’t care how fast you ship if the system feels brittle. I don’t care how clever the abstraction is if the seams are loud. And I don’t care how many commands you know if you never actually decided what the product is.

The measure of a good system isn’t how much it can do. It’s how clearly it shows you what’s happening and how reliably it does what it promises. Those are design decisions. They require someone to make choices about shape and clarity that are harder than adding more features or bolting on another integration.

AI didn’t take anything away from people who think like that. If anything, it gave them more leverage. The people who understand what they’re building, who have genuine opinions about systems and shape and what good looks like - those people are more powerful now, not less.

What this is really about

The terminal will survive. It should survive. There are contexts where it’s genuinely the right tool and probably always will be. For automation, for scripting, for close-to-the-metal work where you need to be precise about exactly what you’re telling the system to do - fine. Good. Use it.

Chat will evolve. The current form of AI chat interfaces is already starting to look like an early iteration. More capable, more stateful, more structured versions are coming and they’ll solve some of the current problems.

And other forms will emerge. The workspace model. The canvas model. Interfaces built around legibility and shape rather than power and memorisation. I think those are the ones that’ll matter most for the next decade of how builders actually work.

But the real divide isn’t about which interface wins. It’s between two kinds of people, and this is where I’ll be direct.

There are people who use systems to think more clearly. Who choose tools based on what helps them understand what’s actually happening and make better decisions. Who don’t have a tool identity to protect and therefore feel free to use whatever works.

And there are people who use systems to protect an identity. Whose sense of competence is bound up in specific interfaces staying difficult, specific knowledge staying rare, specific tools staying esoteric. Who feel, on some level, that if this gets easier, something important about who they are gets lost.

AI didn’t create that second group. But it did remove their excuses.

If your sense of worth depends on an interface staying ugly - that’s not principle. That’s fear. And fear is a poor basis for making decisions about the tools that your work depends on.

The ground is moving. Familiarity still feels like control. But control is actually about clarity, and clarity comes from design, not from discomfort.

Those two things have been confused for long enough.