The Only Window I Need

A tool is a frozen theory of what's scarce

Every tool is built around a belief about what's expensive. The IDE's belief is that producing correct text is the hard part, and nearly everything in it follows: the editor in the center, autocomplete, language servers, vim's whole grammar of motions, each one an optimization for a human pushing characters into a buffer. Fred Brooks argued in 1986 that this was a category error, that the text was the “accident” of programming and the essence was deciding what to build. He was right, and we optimized the accident anyway, because for forty years the accident was still what ate your afternoon.

I should be careful about who I'm speaking for, because the next claim is where these essays usually overreach. I'm not saying programming changed for everyone. If you maintain a legacy monolith the model can't hold in its head, or your day is meetings and reviewing human PRs, your bottleneck is exactly where it was. But for a real and growing group, people doing net-new work on codebases an agent can fit in context, the ratio has flipped. On a normal day my hands produce more English than TypeScript. Claude writes the code; I decide what to build, watch it happen, read what came back, and check that it holds.

So what's scarce for me now isn't keystrokes. It's the attention I spend verifying the model. That is the actual bottleneck of my workday, the thing I run out of, and none of my tools were built to economize it, because until a year ago it wasn't the scarce thing.

The scarce resource has a known failure mode. Two, actually.

Here is the part that made me stop rearranging windows and design something. A verification budget doesn't just get spent. It gets quietly overdrawn, and the two ways it happens both have names in the human-factors literature, from decades before anyone was supervising a language model.

The first is automation complacency (Parasuraman and Riley, 1997): you under-check a tool you've come to trust, even while you're actively engaged with it. This matters because the easy objection to everything I'm about to say is “agent coding isn't passive monitoring, you're driving the whole time.” True, and it doesn't save you. Complacency isn't about idleness; it's about trust. I approve a diff I skimmed because Claude's last twenty were fine, and I'm fully awake when I do it.

The second is the one everyone half-remembers: Bainbridge's Ironies of Automation (1983). The better the automation, the worse the supervisor, because attention decays across processes you're time-sharing and the rare moment that needs judgment arrives when you're least ready. This is the parallel-sessions failure: past two or three Claudes I stop supervising in any honest sense and start stamping, and Bainbridge described that in 1983 about power plants.

Naming both is the whole design, because they ask for opposite fixes. Complacency is a per-check problem: make each individual check so cheap I take it instead of trusting. Multiplexing is a switching problem: make the state of every session glanceable so I don't lose the thread across them. So the control-room fantasy, one calm operator running ten agents, is exactly backwards. More agents is more automation is a worse supervisor. The honest goal isn't scale. It's to keep the verification budget solvent on both axes.

A good tool for this era economizes attention the way the IDE economized keystrokes. That's the sentence I wish I'd had a year ago.

The checking tax

My day used to be a triangle: a terminal running Claude, an editor to read what it wrote, a browser to see whether the thing rendered. Cmd-tab, cmd-tab, cmd-tab.

The obvious rebuttal is right as far as it goes: noticing a blocked agent is solved. Claude Code has notification hooks, the terminal rings a bell, macOS surfaces it. If the cost were only noticing, I'd have built nothing. But noticing is cheap and checking is not. When the diff lives in another app and the rendered page in a third, every verification is a trip, and a check that costs a trip is a check you start trusting your way out of. That's complacency with a user-interface cause: the tool set the price of looking high enough that skimming won.

Co-location doesn't fix this by restoring my mental state. That state is in my head, not on the screen, and no layout hands it back. What one window fixes is narrower and realer: it drops the price of a look to almost nothing, so I look instead of trust. The evidence sits one glance from the change that made it.

Taxing the silent edit

So the reading side is luxurious and the writing side doesn't exist: a git-badged file tree, a syntax-highlighted viewer, diff review that walks hunk by hunk with stage, unstage, and discard on each. No editor. The viewer can't write to disk. No insert mode to fall into.

I want to be precise, because it's easy to oversell. This is not a Ulysses pact. The panes are real terminals, so vim src/foo.ts is always right there, and the tool rewrites itself on request, so “add an editor” is one sentence away. You can't make writing impossible in a system like this. What removing the editor does is cheaper and more durable: it deletes the reflex. Hand-fixing stops being a thoughtless keystroke and becomes a deliberate act you have to choose, on purpose, in a pane. It moves the cheap default from “fix it silently” to “tell the model,” and defaults are most of behavior. The pain-prosthetic story from that Gwern essay, gloves that beeped for patients who can't feel pain and got ignored the instant they were inconvenient, taught me the lesson isn't “make the warning louder.” It's “stop relying on a warning and change what's easy.”

There's a concrete reason the silent edit is worse than it feels, and I want to state it at exactly its true strength, not more. Claude Code mostly survives a hand-edit mechanically: it re-reads files, its edits are guarded against state it didn't see, so it usually fails loudly rather than corrupting anything. What it can't recover is why. Telling the model puts your intent and your correction into the session, where it steers the rest of the work; hand-fixing puts them nowhere. And here's the honest limit, since a session isn't a permanent record, context gets compacted and cleared: the durable loss isn't the transcript, it's the note you now won't write. The fix already worked, so the CLAUDE.md line that would've taught the next session, the commit message that would've explained it, quietly never gets written. The bug comes back and nothing learned.

The fair objection is that routing every correction through words has its own deskilling cost, which is the same irony one level up: lean on the model to phrase the fix and your own hands get slower. I think that's real, and I think it's survivable, because the skill I can't afford to lose isn't typing. It's judgment, the read on whether a diff is actually right, and judgment is the one muscle a reading-only tool makes me use on every single change.

The point was never that I can't type. It's that the cheap path now runs through words, and words are the only thing that checks, steers, and teaches at once.

I didn't derive any of this

I want to be honest about the order of events, because the tidy version would be a lie. I did not sit down with “economize verification” and deduce a feature list. I built these things across a month of annoyed evenings, on instinct, one at a time. The principle is what I noticed afterward, when they all turned out to answer the same question. That's not a weaker story, it's a stronger one: a rule you used as a blueprint only proves you can follow your own plan, but a rule that retrodicts a month of decisions you made before you had it is evidence the rule found something real.

What it retrodicts, cleanly, is the skeleton. Rows fight the multiplexing axis: a project opens as a station (explorer, Claude, viewer), a second stacks beneath with its own Claude, and status is glanceable without a click, tabs carry a dirty-file count and an idle session gets flagged. The flag heuristic is pretty lazy, it watches the buffer for Claude's “esc to interrupt” to vanish, and yes, that flag is itself a little automation I've chosen to trust, which is the whole essay pointed back at me, which is exactly why I keep it dumb and glanceable instead of clever and load-bearing. The panes are honest ptys, every ctrl key passing through, because tterm only intercepts cmd-chords and you don't wreck the agent's habitat. And the browser moved in to fight the complacency axis: the terminal already holds plenty of ground truth (a failing test, a red typecheck), but the truth that isn't text, does the page render, does it feel right, used to live across a boundary I therefore checked too rarely. Now it's real Chromium in a tab, cookies imported with Chrome's own Safe Storage key so everything's logged in, one glance from the diff.

What the principle does not explain is the rest of the tool, and I'd rather show you the theory's edges than pretend it has none. Cmd-shift-G opens ChatGPT because that's where I make images. Favicons on tabs, font zoom, tab reordering: made it easier to move from chrome. And the honest one: the browser is also the YouTube I put on while Claude grinds, which is me spending attention, not saving it, the one place I cheat on my own thesis. Yet, a wise man would say a design principle that explains the skeleton and visibly fails to explain the furniture is one you can actually trust.

The tool that reheats its own theory

There's a palette command called Claude on tterm itself. It opens a Claude session on tterm's own source, inside tterm, and with dev-mount on, saved changes hot-reload the running app. The terminal changes shape while I'm sitting in it. (It's also the one time I deliberately break my own two-session rule: the tterm-on-tterm session is the one extra Claude I allow, and I treat it as the exception it is.)

The plain reason I built it was flow. When something annoyed me mid-task I didn't want to go off, stop the real work, open the repo elsewhere, become a maintainer for twenty minutes. Now the fix is a sentence in an already-open pane and the app patches itself while the work runs two rows down. An annoyance at 9pm is usually gone by 9:15.

But there's a straighter line back to the first section. A tool is a frozen theory of what's scarce, and normally re-freezing takes an industry a decade, which is the real reason your tools always encode the previous bottleneck. The people who tell you “just point an agent at any repo” are right that the capability isn't special. What's special is the collapse of distance: the repo, the running app, and the agent are the same loop, so shaping the tool has no context-switch cost, it's continuous with using it. That's the first exit I've found from tool-fossilization, and it's the same principle again, the tool changes only through words the model can read. The next thing I'm building is tterm reading its own browser, so Claude can act on the page it opened rather than me ferrying screenshots between panes, automating the ferrying, not the judging, because by my own argument the judging is the part I'm not allowed to give away.

What it costs, and why one user is the method

The honest ledger. The missing editor stings about once a day, when a one-character typo has to round-trip through a model; I (could) say the absurdity is sort of the point but it's still absurd. The parallelism ceiling is just Bainbridge with my name on it and no UI moves it much. And there's a security smell I'll say out loud instead of hide: the browser holds my real logged-in web life, imported with Chrome's Safe Storage key into a window whose panes run claude --dangerously-skip-permissions. I take that trade for myself, on my machine, with my eyes on it. I would not take it on your behalf, and you shouldn't accept it from me unexamined.

Because it assumes one user, on macOS, with my exact habits, and that assumption is the method, not an apology. Some shortcuts are shamelessly personal and no product review would sign off (cmd-shift-K globally fullscreens the actual Claude desktop app for Cowork; they've since shipped Cowork to the web, which made me feel both vindicated and slightly obsolete). They exist because I wanted them on a Tuesday, and one-user is exactly what let me delete every requirement that would have stopped me. The editor came out because the only user agreed to the pact.

There's a kind of boat called a skiff: small, flat, built for one person, useless for cargo, perfect for its owner. That's what this is. I can't hand you a tool shaped like your workflow, and I'm not going to pretend a hobby build for my habits is a product for yours. But the loop that shaped it to me is the same loop that would shape it to you, running while you use it, so what I can hand you is a skiff that reshapes itself when you ask, and let it drift toward your habits the way it drifted toward mine.

Words, arranged with care

So, is this just a me thing? Here's the part I'll actually commit to, because I think it's true whether or not you ever touch tterm. Supervising automation is an old discipline with a documented failure mode, and the moment your bottleneck moves from writing to checking, whenever that happens for you and for however much of your work, you inherit that failure mode whether or not you have a name for it. Your attention becomes the scarce resource, and it will get quietly overdrawn in the two ways it always has. A second monitor solves some of it. Knowing what you're defending solves more.

The art on the site, and at the top of this post, is typed: CLOUDS shaped into clouds, BOAT into a sailboat, OCEAN into the sea. I take no credit for the style; I saw it in an Anthropic video recently and couldn't stop thinking about it, and they weren't the first either, concrete poets were doing this on typewriters before software existed. I just wanted one made for me, so I asked, and now a little stencil program types seascapes in my terminal's colors. If you've caught yourself skimming a diff because opening it was annoying, you already know the problem. It's at tterm.sh, free.