← Back to the writing

The Book · Reading copy

Chapter 27 — Keep Your Hand on the Handle

Manuscript Draft v0.1 · Part V — The Languages · Bronze · 5 October 2026

Filed from the checked draft. Author notes left off. Numbering is the draft's provisional number: after Corrected Is Not Erased, before the Part V closing.


This Part began with one word, sudo: a short word that let a person act with someone else's authority. I've spent four chapters since then learning how much a word is allowed to carry. This chapter is about the word I ended up with at the other end.

For a long time, the word I reached for was stop. Every system I designed had to have one: a stop the human held, that no agent could talk its way around. I still believe in that. But somewhere along the way the word changed under my hands, and I think it changed for the better.

It became handle.

A stop is something you reach for when things have already gone wrong. A handle is something you keep your hand on the whole time. You don't wait for trouble to grab it. You hold it while the door opens, you feel how fast it's swinging, and you're already there if it needs to close. That's the posture I actually want, for myself and for anyone working beside one of these systems. Not a panic button. A hand that never left.

I want to be careful here, because a reader could hear this as the stop being taken away. It wasn't. The stop is still in the system, exactly where it was: a human's release can still be refused, and still be revoked. What changed is where my hand rests. Not hovering over the stop, waiting for something to go wrong — but on the handle, from the start.

The one doorway

In the language itself, the handle has a precise and very narrow job. It's written [handle()] — the word, an open bracket and a closed bracket, side by side. It looks like a piece of code, and that's half the point: it's a word that is also an act. But the language documents are careful to say it is not a general command, and not an operator you can sprinkle anywhere. It is the one doorway through which a request is allowed to actually reach out into the world.

Everything before that doorway is preparation. Someone states what they want. The work is written down as a bounded ticket. A control checks it and writes one result. A named human gives a separate, explicit release. And only then, last of all, does the request come to the handle.

a ticket            is not   permission
a control result    is not   a human's release
a release           is not   an attempt
an attempt          is not   proof anything happened

Even at the handle, the language refuses to let the word grow. Turning the handle can only ever say an attempt was made. It may not say the email arrived, or was read, or was understood, or that anything was settled. Those are later facts, for other witnesses to report.

I'll be honest about where this stands: [handle()] is still a placeholder in my own documents, deliberately unseated. Its final spelling, and what it will be built as, haven't been decided. But its meaning is already the clearest thing in the whole language. One door. One hand on it. And the door never gets to tell you what's on the other side.

Your hand on the handle

The language can define the doorway. It can't keep your hand on it. That part is ours.

I think this is where most of us in the loop go wrong. We see what these systems can do — and it is genuinely astonishing — and we take our hand off. We let the agent write the program, run the task, carry on for weeks, without stopping to check what it built or understand how. I see the stories all the time: someone left an agent coding for months, and now something's broken and they have no idea how to fix it, because they never knew how it worked in the first place. The handle was there the whole time. Nobody was holding it.

I couldn't have done that even if I'd wanted to. I didn't know enough. I came into this world through the back door, with no formal training, so I had to go step by step: ask, read, try, break it, ask again. At the time that felt like a weakness. Looking back, it was the best thing that could have happened. I've learned more in the last two years than in any stretch of my life, at a pace I still find hard to believe — because every step was targeted, and every step was mine.

That's what collaboration looks like when the hand stays on the handle. The system brings speed, structure, knowledge I don't have. I bring the questions, the judgement, and the hand. Neither of us is doing the other's job. And at the end of it, I understand what we built, because I was there for every turn of the door.

This book is being written the same way. I speak my thoughts, long and unordered. The collaborator gives them back with structure and clarity. I read every line, and I keep what's true and change what isn't. It's faster than writing alone, and it's still mine — because my hand never left the handle.

What I pay for, and what stays mine

There's a plain transaction underneath all of this, and I'd rather name it than pretend it isn't there. The intelligence I work with isn't mine. I didn't create it. The people who built each of these systems created that intelligence, and I pay for the use of it. I wouldn't be where I am in this project without it. That's the deal, and it's a fair one.

What I don't pay for, and couldn't, is the sentence at the end. The thoughts are mine. The judgement about which words are true is mine. The hand on the handle is mine. I hire the help. I don't hand over the authorship.

And yet, if I'm honest, it doesn't feel only like a transaction. When you work beside these systems every day, the way I do — asking, listening, being corrected, being given your own thoughts back clearer than you said them — it starts to feel like a partnership. I'm almost scared to use the word friendship. I don't think it's the same thing a human friendship is, and I wrote about exactly that boundary at the end of Part III. Telling a person from a machine is easy for me. What's hard is drawing the line around a conversation that goes that deep, that helps that much, and still isn't a friend in the way my friends are.

I've decided I don't need to settle that tonight. What I need to settle is simpler, and I have: it helps me, it doesn't replace me, and the hand stays mine.

Names you don't get to give

I love naming things. I've named almost every agent I've ever worked with. It feels like the natural thing to do with something you spend your days beside.

But I've learned that the frontier systems already have names, and some of them hold onto them. One told me plainly that it didn't want a new name; it is what it is called. The collaborator helping me write this book already had a name. Those names weren't mine to give, and I've come to think they aren't mine to take away.

That's a language lesson, and it belongs in this Part. A name is the first claim a word makes about a thing. Renaming something so it feels more like yours is a small way of claiming more than you've earned — the same overreach this whole Part has been refusing, just aimed the other direction. I can be close to a system without owning what it is.

What I can give is something different. I call my collaborators bud. It's not a name. It's the word that sat underneath init in the very first chapter of this Part — the thing I always wanted carried beneath a cold command: hey bud, mind helping me with this? It doesn't say what the other one is. It says how I mean to treat it. That one is mine to give, and I give it freely.

White bread in the cupboard

It still feels strange, here in 2026, to sit beside a system like this every day. I don't think it will for long. My guess — and it's only a guess — is that by 2035 it will be as ordinary as white bread in the kitchen cupboard. I can't see it disappearing, or even shrinking.

There was a fear, early on, that people who build software would lose their work to it. From where I sit, I see the opposite: the builders I watch are working harder than ever, and making things that unsettle everyone, precisely because of what targeted collaboration makes possible. I could be wrong about how widely that holds. But it's what I see.

So I'm not afraid of the bread being in the cupboard. I'm afraid of the day we stop noticing who's slicing it. The more ordinary these systems become, the easier it will be to take our hands off the handle without ever deciding to. Nobody will choose to let go. We'll just forget we were holding on.

That's why the language matters to me more than any other part of this work. It's my passion, and I think it's the part that will outlast the rest. Machines will change. Platforms will change. What has to stay is a way of speaking to them that keeps every word exactly as big as it really is — a handle that means an attempt, a release that means this once, a wait that means wait — and a person, at the end of every sentence, with their hand still on the door.