Why I run my company on a Brain and a Hand

The problem with one session doing everything

The first way everyone uses an AI coding tool is one long conversation. You think out loud, it builds, you correct, it builds again. It works for an afternoon. Then the conversation is holding your strategy, your half-finished decisions, four hundred file reads and every wrong turn, and the model that is supposed to be thinking about what to build is spending its attention on how it built the last thing.

Two jobs are fighting for one context. Judgement and execution.

The split

So I separate them into two sessions with two names.

The Brain reads the sources, investigates the repository without editing it, proposes, asks me numbered questions when a decision is mine, and then writes one self-contained brief. It runs on the most capable model I can get, because judgement is where quality is decided.

The Hand is a fresh session. It gets the brief pasted in, and nothing else. It builds, verifies in the browser, commits after each step with a plain-language subject, and ends with a report in the format the brief asked for. It never pushes, never deploys, never touches production, unless the brief says so in those words.

Then I paste the Hand's report back into the Brain, and the Brain reviews it before writing the next brief.

What a brief contains

Every brief has the same shape. It is the shape of a good handover to a person.

1. Where to work and what to read first, by file name.
2. What it must not do. No push, no deploy, no credentials, no production resources.
3. What this is: two paragraphs of context, so the Hand understands the why, not only the what.
4. Standing rules for the project. No em-dashes in copy. Every string in both languages. No inline scripts because of the security policy. Verify in the browser.
5. Numbered steps, each ending in a commit with a given subject.
6. Report back: exactly what I want to see, including "anything you changed that this brief did not ask for" and "anything you could not do, with the reason".

That last section is the whole trick. A Hand that must confess its unasked changes makes better ones. A Hand that must explain what it could not do stops pretending.

Two days, in numbers

This site is the freshest example. On 27 September I decided to rebuild it. By the evening of the 28th:

• One Brain session, six Hand sessions.
• Just over a hundred commits, every one with a subject a human can read.
• A particle world in three.js, two languages, a database-backed blog, an owner login built to a written security checklist, a new mark with an identity film, and a go-live runbook.
• Zero lines of code written by the Brain.

I did not review a hundred commits. I reviewed six reports.

Where it broke, and why that was fine

The method is not magic, and the honest part is where it bent.

The Hand discovered mid-brief that the hosting adapter could not build for the platform I had planned. It stopped and asked instead of guessing. I chose. That is the rule working.

The Brain specified a two-step sign-in with an authenticator app. The Hand built it well. Then I decided I did not want it, so the next brief switched it off and kept the code behind a setting. Decisions belong to the owner, and the method makes that cheap.

One of the logo's three forms came out wrong. The Brain looked at the frames, said exactly what was wrong, and the next brief rebuilt only that form. A brief that names the fault is cheaper than a conversation about it.

Why a General Manager likes this

Running a company is mostly briefing people well, setting boundaries, and reading reports honestly. Nobody senior does the work and the deciding in one breath. You would not hire a builder and then stand behind them narrating.

The Brain and Hand split is that discipline, applied to a tool. The brief is the boundary. The report is the feedback loop. The rule that the Brain never codes is the same rule that says a manager should not grab the keyboard: the moment you do, you stop seeing the system.

There is a line I keep coming back to: fairness is giving people what they need to succeed, not treating everyone the same. A Hand needs a complete brief and clear limits. A Brain needs the full picture and no keyboard. Give each what it needs.

How to start

1. Open two sessions and name them. Brain, Hand. The names matter more than they should.
2. Tell the Brain, in one sentence, that it only writes briefs and never edits code. Tell it what the Hand may not do.
3. Make the report section of every brief the longest part. What you can measure, you can delegate again.

FAQ

Do the Brain and the Hand have to be different models?

No. The split is about context and roles, not models. I put the most capable model on the Brain because judgement decides quality, and a strong model on the Hand because execution still has to be right.

Why not let one session plan and then build?

Because the conversation that planned is then carrying every detail of the build, and the next decision gets made with less room to think. A fresh Hand starts with only the brief.

What goes wrong most often?

A brief that leaves a decision open. The Hand will make it, and it will be reasonable, and it will be wrong for you. Ask the Brain to send you numbered questions before it writes.

Is this only for software?

No. I use the same split for keyword research and content briefs. Anything with a plan and an execution can be run this way.