Every session used to start the same way. I knew the answer. I’d describe what I wanted, watch the model produce it, accept or reject, move on. It felt like a productive relationship with a powerful tool. Four hours later I’d close the laptop having shipped something real.

The tell took me a while to notice. Every session began with me knowing what was being built, and ended with the model having typed it. Nothing in between had changed my mind. I wasn’t delegating anything. I was dictating faster than I could type.

That’s not leverage. That’s a keyboard upgrade.

Two different relationships with the work

Dictation and delegation look similar from the outside. You’re in a session, there’s a prompt, there’s output. They feel similar from the inside too, at least for the first hour. The difference is structural, and it shows up in what happens when the model pushes back, or when what it returns isn’t what you asked for.

Dictation is: I know what I want, you produce it, correctness is measured by fidelity to my spec. If the output matches my description, the transaction succeeded. The autocomplete mental model scaled up. I supply the intent, the tool supplies the tokens.

Delegation is different. I own an outcome. The model owns a sub-problem that contributes to it. Correctness is measured against the outcome, not against my instructions, because my instructions were probably incomplete. A good delegate surfaces things I didn’t think to specify. A good delegate returns with questions as often as answers.

The distinction matters because dictation scales the tool to the size of your prompt. Delegation scales it to the size of your judgment. Those are very different ceilings.

Everything pulls you toward dictation

The thing I didn’t understand for a long time is that dictation isn’t a mistake you make out of ignorance. It’s what the whole stack is optimized for. You have to choose against the grain, every session, or you end up dictating by default.

The interface is the first pull. Chat is a dictation idiom: call and response, you type and it replies. There’s no affordance for “I don’t know yet, help me think.” You can simulate one, but you’re fighting the surface.

Your own habits are the second pull. A decade of autocomplete and Stack Overflow trained you to frame questions as fully-specified asks. The muscle memory is “describe the thing you want.” That muscle memory is dictation.

And the feedback loop closes it. Dictation gives you fast feedback: did the code run, did it match my spec. Delegation gives you slow feedback: did we build the right thing, was this the right sub-problem to solve. Fast feedback wins by default, because the alternative doesn’t feel like progress at all.

None of this is a character flaw. It’s the shape of the tool. If you want delegation, you have to build the conditions for it yourself, because nothing in the default setup will do it for you.

What delegation actually requires

Once you take the distinction seriously, what “using the tool well” means stops being a list of tips and becomes a set of consequences.

Delegation needs context upfront, not drip-fed. A delegate can only exercise judgment in proportion to how much of the outcome they understand. Dictation works with a sentence. Delegation needs the shape of the problem: architecture, conventions, why this work matters, what’s already tried. Drip-feeding requirements mid-session is dictation wearing delegation’s clothes.

Delegation needs a pipeline that catches what you didn’t think to check. Once you’ve actually delegated, you’ve given up on line-by-line review as your quality gate. The CI pipeline is the structural replacement for approval. Tests, linters, type checks, security scans. These stop being hygiene and become load-bearing. If your CI is flaky or your coverage is patchy, you can’t delegate. You can only dictate with extra steps.

Delegation needs a CLAUDE.md that reads like a constitution, not a recipe book. The thing that makes those files work isn’t prescription. It’s giving the model enough about the team, the values, the constraints, that it can make good local calls without asking. A file full of “do X, then Y, then Z” is dictation frozen in markdown. A file describing what this team cares about and why is the shape a delegate can actually use.

And delegation exposes the real bottleneck, which isn’t the tool. Last year I ran an experiment onboarding a product designer to Claude Code. Setup took an hour and a half with two engineers helping. SSH keys, Docker, port conflicts, dependency mismatches. The comment that stuck with me was “now I get why project setup takes two weeks.” Once setup was done, simple changes worked. Complex debugging was still a wall. The tool didn’t eliminate the need for engineering knowledge. It moved where that knowledge had to live. Delegation works when the delegator has judgment to spare. Dictation only needs a keyboard.

The ceiling is the point

The two modes aren’t two styles of the same activity. They have different ceilings, and the ceiling is what matters.

Dictation caps at the rate you can describe things. That’s not nothing. On a good day it’s a real speedup over typing the same code yourself. But the work you get back is bounded by the work you already knew how to specify. You cannot dictate your way to an answer you didn’t bring to the session.

Delegation doesn’t have that ceiling. What you get back is bounded by the quality of the outcome you set and the conditions you built for the delegate to work inside: the context, the pipeline, the constitution, the judgment. None of those scale with typing speed. They scale with how much of the problem you’ve actually understood.

That’s the trade. Dictation is the shorter path to feeling productive. Delegation is the longer path to a different order of output. The tool delivers whichever one you show up ready for.