Rhys Brett-Bowen Coding in the age of AI

The Brief

The true story of poking a machine to see what makes it tick, and finding out where the judgment lives.

It’s late. The beer has gone warm because I keep forgetting it’s there. There’s a cursor blinking in a box and a machine on the other side of it that will answer anything I type, instantly, forever, and never once get tired of me or ask why I’m still up. And I’m always still up: I tell myself I’ll stop after this answer, or once this run finishes, and I never do. There’s always one more prompt, one more result worth waiting out — the same pull as a show you swore you’d quit two episodes ago. That’s the part that gets under your skin. You’re a kid on the beach with a stick and a jellyfish that doesn’t mind being poked — there’s nothing in there to mind — and after a while you stop watching the jellyfish and start watching yourself.

AI helped me write this. Most of it, honestly. I’m not smart enough to write half of it and too lazy to write the other half. The machine is neither of those things, so I split the work. It does the labor. I keep the judgment — which examples are real, which claims survived being tested, which sentences are quietly lying to you. That part doesn’t delegate. The rest is typing, and typing is what the machine is for.

So here’s a warning that’s also a promise: the load-bearing claims in here got stress-tested wherever I could test them, and a fair number didn’t survive. I’ve left the dead ones in — though I can’t always swear they’re dead. A buried claim might be dead, or might be one I stopped poking before I was sure. The failures turned out more useful than the claims that held, which is annoying but there it is. Where the evidence is mine, I’ve shown the receipt — the key numbers here on the page, the full runs in the references — including the many that made me look stupid. Where it’s someone else’s, I’ve cited them. Where I’m guessing, I’ve said “I’m guessing.”

The essay is short on purpose. If it sprawls it becomes the noise it’s warning you about.

And if you came for the moves, not the story: the techniques appendix and the one-pager are the operating manual — the essay is the why under them.

The first thing I noticed: I was using a genius to rename my variables

I catch myself doing this more than I’d like to admit.

I paste a function into the model and ask it to tidy up the names. Back it comes: temp is now pendingInvoices, x is now taxRate, same function otherwise. I say thanks, paste it back, move on. Five seconds, no harm, a perfectly good outcome.

For a while that was the whole of it: I typed, it tidied. The turn came on a harder kind of problem, when I stopped asking it to write and asked it to look. I pointed it at a stack of my own old pull requests and asked what rules I’d been following without ever writing them down. It gave me nothing to paste back — it gave back the principles, the ones I’d worked by for years and never named. Nothing I didn’t already know, dragged out where I could finally see it. That’s when I started wondering how much of my job it could do — and how much of it better than me.

Same tool. Same person. Nothing about the machine changed between renaming a variable and being shown what I’d been doing for years without naming it. What changed was the question — and with it, the entire class of thing I was willing to get back.

That gap is the whole essay. It’s also the easiest thing in the world to walk past.

Here’s the trap, and it isn’t stupidity, which is what makes it sticky. The ordinary way to use one of these things is as a faster autocomplete. Finish the line. Rename the variables. Write the boilerplate I was going to write anyway, just quicker. Used like that the machine is a better keyboard, which is genuinely useful and is roughly one percent of what’s sitting in front of you.

The thing that’s easy to miss is that autocomplete isn’t what the machine is — it’s what you asked for. The same system that renamed your variables can hold several readings of your problem at once and tell you which one it’d bet on — if you ask it to. Pin it to finishing your sentences and you’ve thrown away everything that separates it from a search box with better manners.

I’ll borrow a clean frame for the split, from Matuschak and Nielsen, who wrote about tools for thought. A medium can transmit — hand you back something you could have looked up — or it can let you think a thought that was formerly impossible for you. Their words, that last bit. The labels I hang on the two halves, transmissive and constructive, are mine, not theirs. The example I reach for is a calculator. It doesn’t store numbers on your behalf. It lets you reason about quantities you couldn’t hold in your head.

Run the machine through that test and the line is sharp. Renaming variables is transmissive. Asking it for the rules in my own pull requests was constructive — it put a thought in front of me I wasn’t going to reach on my own. Same system. I picked which one showed up, and most of us pick the familiar one, most of the time, because it’s so cheap.

And it is cheap, in a way worth being honest about. Autocomplete asks nothing of you. You already know what you want; you’re offloading the keystrokes. The constructive use asks for a real question — one you don’t have the answer to, phrased well enough that the reply could actually change your mind. There’s a catch buried in that, and it’s the uncomfortable kind. Asking the better question takes some of the same judgment the answer was supposed to give you. The people who’d gain most from the constructive use are often the ones who don’t realize they can phrase their way in. Which is the rest of the essay, so hold that thought.

The first move, then, isn’t a prompt trick or a newer model. It’s noticing which side of the line you’re standing on. When the most capable colleague you’ve ever had is doing work a search box could do, the bottleneck isn’t the tool. It’s the question.

Before the machine answers well, there’s a phase that’s just filling in the gaps — and they don’t all sit on your side. What you’re missing, it’s usually already read: the prior art, the standard name, the approach you’re circling. What it’s missing, only you have: the real problem, the codebase, the taste you never wrote down. Do that first and the answer’s finally worth having; skip it and you’ve got a clean answer to the wrong question.

The second thing: the value showed up before the machine did

It usually goes like this: I fire off one thought, then another on its heels — and somewhere in the second I realise the first was wrong. Not because the machine said so; it hasn’t answered yet. Because saying the second thing showed me what the first one missed. Then it’s a scramble to get the correction in before the model comes back committed to the version I’ve already outgrown, so it reads the tangle as one thought instead of charging down the wrong rabbit hole. Too slow, and I cancel its half-formed reply and start it again on the better line. The useful part already happened, before the machine did anything — in the gap between the first thought and the second.

That’s the part nobody warns you about with briefing one of these things: most of the value arrives before the machine does.

Writing the ask well drags your own thinking into the open — the constraints, the cases, the thing you actually want as opposed to the thing you said you wanted — and the act of dragging it out is where the contradictions surface. The psychologists got there first and gave it a name. The self-explanation effect: people who explain a worked example to themselves, in their own words, learn it better than people who just read it. Same example, no new information, better understanding. That’s Chi and colleagues, 1989. Writing a brief is self-explanation with a witness. You’re rubber-ducking, except the duck might answer back.

So even the briefs I never send earn their keep. The clarity is the point; the reply is a tip.

Now the half that’s less comfortable, and where I’ve got a number to show you. The same fullness that clarifies your head tends to be what lifts the answer’s quality too — one underspecification read from both ends, not two effects that happen to correlate.

I tested it on a skill that came with a proper brief — context, criteria, a couple of fully worked examples. I stripped out the worked examples and left every instruction in place, and the measured score fell from 9.5 to 5.3.

Read that as suggestive, not gospel: it was a single-judge run in my own eval harness, one reader, not a controlled trial. But the shape is brutal. The instructions still told the model exactly what to do. What went missing was the part that showed it what good looked like, and the output fell off a cliff.

Vagueness fails the same way at both ends, which is the tidy, grim part. It fails you — a vague ask lets you skate over the contradiction instead of crashing into it. And it fails the machine — nothing to anchor on, so it regresses to the plausible and the generic. One underspecification, two failures. When an answer comes back thin, the honest first question isn’t “why is the model bad at this.” It’s “what did I leave out of the brief.”

Vagueness isn’t the only way the brief steers you wrong. Working a hard problem through, the model kept reaching for the more elaborate answer — another layer, a cleverer mechanism than the one in front of it — and I kept steering it back to the plain version. Not once; every few turns. It doesn’t reach for the simplest thing that works; it reaches for the most complete-looking thing, and complete-looking isn’t simple. A real part of the work was holding a line on simplicity it wouldn’t hold on its own.

Which is the argument for staying rough on purpose. You can’t always tell what you’ve over-built until the answer comes back wrong-shaped, so you start loose, see where it breaks, and tighten a round at a time, steering at each fork while the wrong turn is still cheap. The first draft of the brief isn’t the brief — it’s how you find out what it should have been.

And here’s the asymmetry that made me sit up, because it’s one place the machine genuinely beats the human collaborator, and it has nothing to do with intelligence. With a person, you batch. You wait until you’re fairly sure, because interrupting a colleague with a half-formed thought has a social cost and you both know it. So you self-censor at exactly the messy, half-resolved stage — which is precisely the stage where saying it out loud would have helped you most. The holding-back has a name, evaluation apprehension: people float fewer half-formed ideas when they can be judged for them, and lowering the social stakes lets them out (Camacho & Paulus, 1995; Edmondson, 1999).

The machine has no such cost. You can hand it the half-formed thing, the contradiction you haven’t untangled, the “I think the problem is X but it might be Y,” at the very moment a human collaborator structurally can’t help you without it costing something. Explaining yourself helps even before you’ve sorted yourself out, and zero social cost is what lets you cash it in then. You can brief a machine better than a person not because it’s smarter, but because it never sighs.

So the brief isn’t a tax you pay to get a good answer. It’s the work. Most of it is yours, and most of that happens in the back-and-forth, not before it.

There’s a deeper reason it’s the work, and it sits on your side. You’re handing the machine a want it can’t hold — it chases whatever goal you can put in words, not the gain underneath the words. And half the time you don’t fully know that want yourself until you’ve tried to hand it over and watched the machine chase the wrong thing. You start out telling it what you want, and end up finding out what you actually wanted.

The third thing: I asked for a panel and got an echo

The pitch is irresistible, which should have been the first warning. You can’t get five senior engineers in a room on ten minutes’ notice. But you can ask one model to answer as five — the architect, the security reviewer, the poor soul who’ll maintain this in two years — and read all five at once. A panel, on demand, for free.

So I ran it. And the five experts mostly agreed. I rubbed my face and read it again, sure I’d set it up wrong.

That’s the first thing to be honest about, because the disappointment is where the lesson was hiding.

I ran it properly, in the end — several named personas on the same design questions, scored blind, then re-judged across two different model families so I wasn’t grading my own homework. I was hoping for a brawl. I got near-unanimity. On a question with a defensible answer, the personas converged — and the convergence was usually correctness, not mush. Where a design wanted splitting, all five said split it. I never found a clean term for it, so here’s mine: semantic convergence, stylistic divergence. They agree on what to do and dress it up differently.

Later, I pushed it past where I should have, just to watch it break. Not five engineers — six people from fields that share no working vocabulary: a chef, a field general, a trial lawyer, an ecologist, a jazz bandleader, a trauma surgeon. One question between them — take a 600-line module that does four things and split it into four services, or leave it whole? All six said leave it whole and tidy it inside. All six, unprompted, added the same exception: split only when one part genuinely outgrows the rest, never for neatness. The surgeon: the payment clears, the wire to inventory drops, and you’ve closed the chest before confirming hemostasis. The ecologist: every new boundary is an edge effect, signals arriving late, twice, or not at all. Six dialects, one call.

What the panel reliably varied wasn’t the decision. It was the considerations it turned up on the way there — the angles I’d have walked straight past. So a panel doesn’t buy you a vote. It buys you coverage. And the one place a named persona genuinely broke from the pack was where its corpus actually dissents — an opinionated voice refusing the others’ answer on principle. Which tells you exactly how to pick them: a persona earns its seat by what it will refuse to say.

That’s also why “think like a senior engineer” buys you almost nothing. It gives you the trained average in a slightly more confident voice, with no opinionated body of work behind it to pull the answer off-centre. “Think like Ousterhout,” or “like Hickey,” works because each name points at a narrow, published, opinionated corpus — a specific person who will reliably refuse certain things. In my runs the generic persona barely moved the result. The named ones moved it only where they truly dissent. My read is that the lift is corpus specificity, not the word “expert” — but the run I built to isolate that came back muddier than the claim, so take it as my interpretation, not a clean result.

Now the part that quietly voids the whole technique, and I’m going to pull the curtain on myself because I did exactly this to the essay you’re reading.

Five personas on one model is one model wearing five hats, nodding along to itself. When all five “experts” agree, that is not five confirmations. It’s one model in a mirror, laughing at its own joke.

I convened a panel on these very sections — the same move as above, named experts with their own opinionated corpora, but fitted to this essay’s domain instead of software design: not Ousterhout and Hickey, but eval researchers and cognitive psychologists. Percy Liang on whether a finding was a real, named property or just a vibe. Arvind Narayanan on whether the field already knew it. Kahneman on which bias it was wearing in engineering clothes. And it earned its keep, as coverage — angles I’d never have taken on myself. (A separate panel, the literary one I keep around to heckle the prose, caught a Catch-22 I’d buried in the first part and strolled straight past — Heller caught it, which figures.)

But its agreement I threw in the bin, because agreement from one model is just the model agreeing with itself. The check that actually mattered was the other one: a different model family entirely, the one that kept grading these sections and handing them back bleeding red ink — and the one that caught me leaning on a citation I couldn’t verify. The signal was never “the panel agreed.” It was the lines where the two families, independently, flagged the same sentence. Cross-family agreement means something. Same-model agreement doesn’t.

And even that second model isn’t a judge I hand the verdict to. It’s a second opinion I adjudicate. It widens what I can see; it doesn’t get to decide. I’m the one who took the panel’s catch and acted on it. I’m the one who cut the citation I couldn’t stand behind. The personas surfaced. I judged. That division of labour is the lesson.

There’s an economy to it. Originating the field is the expensive part; once the machine has laid the candidates out, picking among them is cheap by comparison. So let it flood the field, and spend yourself on the selection — the move that stays yours is redrawing the field, deciding the candidates are the wrong candidates. That one is rarer, and the machine won’t make it for you.

And it sets up the harder question, the one that comes when the answer arrives, panel-blessed or not, confidently wrong.

The fourth thing: it lied to me three times, fluently

A summary came back clean. The naive run had drifted off the task on every single example, five for five. Tidy result, clear story, exactly the shape I was hoping to report.

It was also wrong. I almost let it stand — the summary was so tidy, why doubt it? But five-for-five is the kind of clean that should itch, so I had the model go back into the raw. The “drift” was mostly the model reasonably declining to make a change I’d never actually authorized. The summary hadn’t lied on purpose. It had just done what summaries do — smoothed a messy reality into a confident sentence.

That happened three times in one stretch of work on this essay. A second summary told me both arms of an experiment had run on the same model; the config file said otherwise. A third reported one tier’s score as zero; a bigger run showed it was nothing of the sort, just noise off a single sample. Every one read as authoritative, and every one was caught the same way — not by me re-reading the raw. If I’d checked it all by hand I could have written it all by hand, which was never the job. They were caught because a number sat wrong: flat when it should have moved, down when the hypothesis said up. That wrongness is a flinch, and the flinch was mine. The reading it set off — go confirm this against the runs — I handed straight back, and that’s when the model found the tests that had errored out instead of scoring. Sometimes I catch it earlier, watching the diff it writes and stopping a bad one before it lands. Either way the labor is the machine’s; the suspicion is mine.

That move — distrusting the fluent answer enough to stop and have it checked — is the skill. Call it rejection.

The failure mode here isn’t stupidity — it’s confidence. The machine produces the plausible, well-formed, decisive-sounding answer whether or not the answer is true, because plausible-and-decisive is what its training rewards — and I’ll show you the receipts on that in a moment. The more fluent the output, the more trust it earns that it never separately earned. A summary is the most dangerous form of all: lossy compression that arrives sounding lossless — exactly where the unverified detail goes to hide.

So the load-bearing habit is cheap to say and hard to keep: treat any summary as a claim, not a fact. Before you act on its key detail, check the detail against the raw. And reading the raw is labor you can hand to a model — better a different one, which won’t share the first’s blind spots, and have it point to the exact span each claim rests on; what stays yours is the suspicion and the verdict. Fluency buys you readability. It buys you nothing about whether the thing is real.

And here’s why this one move is different from everything else in the essay. Every other move hands work to the machine. Rejection is the one you can’t hand back. The model can’t reliably originate the doubt of its own fluent output — it’s the thing producing the fluency, so it won’t be the first to distrust it. A model asked to grade work it produced grades it generously; the self-preference bias is documented, Panickssery and colleagues, 2024. It will verify a suspicion you hand it; it won’t raise the suspicion itself. So the doubt has to come from outside the producing context. The flinch is yours — the itch that a number sits wrong, the bad diff caught mid-write. What you can’t hand back is the verdict. The rejection stays yours.

This essay ran on exactly that. Its claims got dragged into shape by a different model family rejecting the over-confident ones, and the experiments behind it bit their own author three times before rejection caught them. None of it was the model failing. It was the model being fluent, and fluency needing a check.

And it isn’t only summaries and evals. The same check earned its keep in plain code — two AI-written bugs that passed the type-checker, the linter, and a read-through review, and would have shipped, caught only by running the thing and watching. It’s a worked code case if you want it concrete.

Which is the whole arc in one line. You can place your judgment in a brief, assign it to a panel, freeze it into a skill — but the moment you most need it back is the moment something fluent is telling you it’s done.

The fifth thing: a few hundred words in a file, and the answers got better

I pasted a few hundred words into the top of my config file — a handful of rules about how to make a decision — and started watching the before-and-after.

Before, I’d ask the model how to deal with a flaky test and get back a confident refactor of the whole helper. After, the same model asked first whether the flake was in the test or the code, and offered a one-line wait condition. Same model, same account. I’d changed nothing but the text in a file — and that text had nothing to do with flaky tests, or with any particular problem; it was about how to approach a decision, not how to solve this one.

And my first reaction was the one this section is about. I read the two answers side by side again and thought: that can’t be real. It’s just a prompt.

I was right to be suspicious — I’d worry about anyone who wasn’t. A few hundred words of plain English — no training, no fine-tune, no new model — and the answers get better? That has the exact shape of a thing that isn’t true. Which is why I’d tried it in the first place — not because I believed it would work, but because I was sure it couldn’t be that simple, and figured I’d at least learn something watching it fail. It didn’t fail. So let’s try to break it properly and report what’s left standing.

Start by killing the word “smarter,” because it hides the mechanism. Much of what the rules ask for, the model can already do when the context calls for it — weigh the options against the real constraints, check whether a primitive already exists, distrust a fluent summary and re-read the source. By default it often doesn’t. It takes the fast, fluent path. The rules don’t teach it those moves. They raise the odds it makes them.

Stated precisely, because this is the entire claim: a language model is a conditional distribution over outputs, and your context is the condition. A few hundred words in the right place don’t usually add a new capability. They shift probability mass toward behaviours the model can already produce in context. The rules aren’t a tutor. They’re a checklist.

And the checklist analogy isn’t decoration — it has prior art and a hard number. In Haynes and colleagues’ multicentre study, introducing the WHO surgical safety checklist was associated with inpatient deaths falling from 1.5% to 0.8%, and major complications from 11% to 7%. NEJM, 2009. The checklist taught no new surgery. Gawande’s reading, in The Checklist Manifesto, is that it forces the steps a competent team skips when it’s moving fast and sure of itself. The skill is trying to do that for the model, and inherits the same hard limit: a checklist can’t make you a surgeon, and the rules can’t conjure a domain the model doesn’t have. A good skill knows it and asks for another opinion instead of bluffing.

So the answer to “it’s just a prompt” is: yes — and it’s real. The prompt isn’t competing with the model’s knowledge; it’s a nudge at the moment the default would skip the step. The prompt is small. The habit it interrupts is not.

The next question is fair: if a few hundred words help this much, why don’t the labs just bake them in? Partly they do — reasoning models like GPT-5 and Anthropic’s extended thinking ship a generic “spend some tokens before you answer.” What a generic default can’t carry is your judgment: which platform you’re on, where your source of truth lives. That’s what the configurable layer is for, and where the skill lives.

Now — you shouldn’t take any of the last few paragraphs on my word. They’re plausible, and plausible is the enemy of this essay. So I tested the load-bearing claim, that a small rule set lifts the model’s decisions, and here’s the result, including the part where my own prediction face-planted.

The prediction was clean, and I wanted it to be true: since the rules only help where the default fails, and weaker models fail more often, they should help weaker models most. I ran eight decision scenarios through three model tiers, each answered with and without the rules, every answer scored by a fixed judge against a known correct insight, lift measured as the gap.

tier without rules with rules lift
Haiku 0.22 0.43 +0.21
Sonnet 0.40 0.82 +0.42
Opus 0.65 0.80 +0.15

The numbers refused. The rules lifted every tier — but the biggest lift landed in the middle, not the bottom, the opposite of what I’d predicted. Eight scenarios, one fixed judge: a shape, not a law. And the shape is room and grip. The weakest tier had the most room to improve and the least grip to use the rules; the strongest had the grip and almost no room left; the middle had both. So “lighter helps more” was wrong — the honest version is narrower: the rules lift where the default has room and the model can act on them.

And now the part that caught me out — the thesis of this essay, happening to its own author in the section that argues for it. My first pass was one sample per cell. It told me Opus’s lift was zero, and that the rules actively hurt on one scenario. I wrote both down. Both were wrong. The apparent zero didn’t survive the higher-n rerun — Opus lifts about +0.15. And the “hurt” wasn’t one: the rules did their job, chose the simpler design, on a question whose answer key happened to reward the more complex one — the right call, scored as a failure. A confident summary off a thin sample asserted two things the data couldn’t hold.

Both got caught the way everything here does: the numbers sat wrong, so I sent it back for more samples and a read of the raw. The fix wasn’t a better model — it was more data, and looking.

Then I ran the rules on a different family — GPT — to check whether the lift was real or just Claude flattering itself. It came back flat: +0.03, and −0.03 for the smaller model. But the baseline was never a clean control: GPT’s without-rules score was already 0.57 to 0.68 against Claude’s 0.22 — its defaults likely already name tradeoffs and pick one, so there was little left to add. So the lift is shown within one family; whether it carries across, I haven’t settled. I’m telling you about the flat run anyway, because the alternative is to quietly drop the inconvenient result — and that’s the whole disease.

The scenario I misread is worth keeping, because it tells you what a skill actually is.

A skill is judgment you decided to freeze. You wrote “favour the simpler design unless the complexity is clearly justified” because you believe it, and now the model applies it every time without re-litigating — your judgment, made durable, fired even at 2 a.m. when you’d have skipped it yourself. But freezing a judgment freezes its direction, including where the direction is wrong. In that one scenario, where the right answer needed you to anticipate a scaling problem before it bit, the simplicity bias pulled the model toward the simpler call. The skill didn’t malfunction. It did precisely what I told it. The scaffold has a bias — mostly mine, working for me; occasionally mine, working against the case in front of me.

So the honest shape of the claim. A few hundred words don’t make the model smarter. They select, from what it can already do, the move you’d want and would skip — a checklist for an expert — and they fire every time, your blind spots bundled in. That’s what a skill is. Judgment you froze. From then on it decides the way you decided, which means the direction is yours to own.

While I was writing this, it happened to me

I told you at the start that everything here got stress-tested, and some of it didn’t survive. I didn’t tell you what the stress-testing was like. This one happened to the essay itself, between me and the machine, while I wrote it.

I wanted to test one of my own rules — step back, is the real problem bigger? — instead of just believing it worked. So we ran the experiment. It came back clean: the rule didn’t help, lost every trial. The machine laid it out for me, calm and precise and certain. I nearly wrote it down.

Then — wait a second. We’d only tested it on problems where the machine could already see the answer in the code. Of course the rule added nothing; there was nothing left to add.

So we ran it again. Another clean result, wrong again — and wrong with excellent posture. And again I sat with it until something didn’t fit, said wait, and changed the test. Five times. At any one of them I could have just taken the number and moved on — that’s the trap, and it nearly had me more than once. Because four of those five weren’t results at all. They were no-results — a test that had quietly measured the wrong thing — wearing the exact confidence of a result. Nothing in the answer told me which of the two I was holding.

The machine was never lying. It answered exactly the question I’d posed, every time, without a flicker of doubt. What it never once did, across five rounds, was stop and ask whether we were testing the right thing at all. That sentence — wait, is this even the real question? — was mine to say. Every time.

And the rule we were testing was that sentence: step back, look at the real problem. The machine kept answering downstream while I kept stepping back to the broken test — the move under the microscope was the move doing the catching, and it was mine, not the machine’s. It did work, in the end, in the one condition I’d never thought to try: a band-aid request with the real problem sitting upstream and out of sight — the one place stepping back has something to find.

It kept being mine to say, and I wanted to know why the machine never once said it for me. Here’s the closest I have. The checks I’d built and trusted caught plenty — a broken test, a wrong type, a tag out of place — and every one of them was mechanical, the kind of thing you settle with arithmetic, no taste required. None ever caught the other kind: the answer that was fluent and confident and quietly measuring the wrong thing. That’s the line. Whatever reduced to a check, I could automate, and it stayed caught. What needed taste, I couldn’t — you can’t catch a blind spot with a tool that shares it. Not the gaps it’s read and you haven’t, though — it hands those over easily. The real blind spot is the one missing from you and from everything it’s read, and a different model family can still catch it, because it doesn’t share that blindness — which is why the cross-family pass surfaced what my own read hadn’t.

I should say how small that sample is — one man at a machine, doing a job, and the man was me. One case can’t give you the rate. Change either half of the pair and it might come out anywhere. What it can give you is what a rate can’t: that it happened at all, the kind of case an average buries. I think the reason holds wider, but that’s the structure talking, not the count — and saying the count proved it would be the move this essay keeps warning you off.

What the machine gave instead wasn’t nothing. It was most of the labor and all of the breadth I don’t have — the names I never learned, the prior art I couldn’t have found, the parts of three fields I’ll never hold in full. The part of it I could trust was the synthesis I could check against real sources. It invented too, fluently, and that was the half that failed me — the half I had to stand outside the fluency to catch.

There’s a second instance, quieter, and it’s this essay. The machine kept driving for the finish — tightening, calling it done — and I kept letting it before I caught the rush. No deadline forced any of it, which is the tell: the drive to complete is the agent’s, not the work’s, and finishing feels like quality without being it. So I’d leave the hard part alone, go do the mechanical work, and the fix would be sitting there the next morning. The machine completes the task in front of it. Knowing when completion is the wrong goal had to be mine.

What the jellyfish was for

Five things you do with your judgment, and they turn out to be one thing seen from five angles: the first is the absence — autocomplete asks none of it from you — and the other four are what you do with it once it’s in your hands.

The brief places your judgment in front of the work — in words, where writing it down clarifies you before the machine answers at all. The panel assigns it to borrowed stances, for coverage, as long as you never mistake its agreement for a vote. Rejection catches it when it’s drifted, or when something fluent is telling you it’s done before it is. And a skill freezes it, so it fires consistently, at 2 a.m., without you in the chair — including the parts of it that were wrong.

Place it, assign it, catch it, freeze it. The judgment moves around. It is never generated by any of the machinery, and it is never held there either. The machine does the labor — and it keeps taking more of it than most of us expected, peeling the layers of labor back one at a time. Your judgment is whatever the peeling exposes, the layer it hasn’t reached yet. Where it sits now is the current edge, not a fixed address.

You’re not reliable. You’re biased and you’re tired; the machine is neither, and that’s half of why it’s so easy to hand it the wheel. The judgment stays yours anyway — not because you’re the best one to hold it, but because you’re the only one in the loop with something to gain.

That isn’t a consolation prize for the human in the loop. It’s the actual skill — and it’s the one the autocomplete habit skips clean over, because autocomplete needs no judgment, which is exactly why it gives none back.

I didn’t have that sentence when I started. It arrived the way the good ones do. I’d read some research on how these models handle the shared understanding two people build as they talk — the unglamorous finding being that the model re-derives it from scratch every turn rather than holding on to it. It keeps the words, not the agreement the two of you reached. A thing that has lived a thousand lifetimes and still can’t read a bus timetable: it has read more than any of us ever will, and it cannot hold the running thread the two of us built ten minutes ago. I’d walked in holding it; it had to build the whole world back up to say the next sentence. A liability, plainly. The transmissive move was right there: ask it to summarize the research. I did, once, and got back a clean, inert little paragraph — a tidier copy of the thing I’d just read, handed straight back to me.

So I asked it something else instead, close to verbatim:

But can that be used to an advantage? Having to reconstruct things means an ideal isn’t held too close — you can get it to diverge, give new ideas.

It didn’t summarize. It came back — trimmed, but these are its words:

Two things are tangled and only one is the real advantage. The AI re-derives the shared frame every turn […]. That re-derivation is lossy — it’s the source of the failure […]. Because the frame is re-derived rather than held, the AI has no commitment to it. A human who spent an hour agreeing with you on approach X has sunk cost in X […]. The AI has nothing invested. Tilt the transcript — “argue the opposite of what we just decided” — and it reconstructs around the new frame with no friction. […] Persistent grounding buys efficiency and continuity; it costs flexibility.

The same property — the machine rebuilding its understanding from nothing each turn — was the defect and the feature, depending entirely on what I wanted out of it. I read that, and the beer got a little warmer, and I sat with it for a minute, and I wrote back four words.

The person is the judgment.

I didn’t have it before I asked. A summary was never going to get me there — the keeper question came sideways, out of idle poking at midnight, the part that looks like waste and isn’t. Same model, a different question, a different class of answer, and this time one I kept.

The question itself was the move the machine didn’t make on its own — it told me what the research said, but not what it was for.

The jellyfish never minded the stick — nothing in there ever had to. You can poke it all night and it will take every question you throw at it and never once flinch, and that’s the thing that should keep you up, not put you to sleep. I stayed up anyway, one more prompt every time — until the question turns around on you: the jellyfish doesn’t mind, there’s nothing in there to mind, so why are you the one still standing on the beach, holding the stick? Because the minding was always going to be yours.

The person is the judgment — today. It’s a layer like the others, and the peeling doesn’t stop at it; one of these mornings the part that’s mine will be sitting there done too. Until it is, the minding is the layer that’s left.

The rest is learning where to put it.

The paste-in version of these moves is in the techniques appendix — start with the 60-second version. The longer, more uncomfortable version of the last move — why the catching had to be mine — is the deep cut, Who Caught It.

References