DEV Community: Yap Pat Yih

I removed my Chinese web font. Every page lost 1 MB

Yap Pat Yih — Sat, 03 Oct 2026 06:18:31 +0000

First published on yappatyih.com.

TL;DR

A system font stack is a list of fonts that are already installed on the reader's device, given to the browser in order of preference, so the page downloads no font at all. On 2 October 2026 I replaced the Chinese web font on this site, Noto Sans SC, with a system font stack. One Chinese post went from 20 font files and 1,107 KB of fonts to 2 files and 54 KB. The whole page went from 1,464 KB to 318 KB. Its Lighthouse mobile score went from 68 and 73 to 84 and 97 across two runs each. The change is four lines of CSS. What I gave up is one identical look on every device. What it did not fix is below too, because the first live measurement was worse than I expected, and the reason turned out to be mostly the measurement itself.

What a Chinese page was carrying

Before the change, every Chinese page on this site carried 94,098 bytes of font instructions inside its own HTML, before a single font file was requested. That is 100 @font-face rules, the same 100 on every page.

This site is bilingual. Every page exists in English and in Simplified Chinese, so the English page is a fair control for its Chinese twin. Same layout, same pictures, same words in another language.

The English version of the mamak table post was 51 KB of HTML. The Chinese version was 143 KB. After the HTML arrived, the Chinese page went on to download 20 font files, 1,107 KB in total. The Chinese home page downloaded 16 files, 857 KB.

On a phone, Lighthouse scored that Chinese post 55 and 65 on two runs. The English one had scored 97 two days earlier.

A reader in Kuala Lumpur on mobile data was paying for a megabyte of font to read one blog post.

Why a Chinese font is so heavy

A Latin font needs a few hundred shapes. A Chinese font needs many thousands, and each one is a drawing.

Google Fonts handles this well for what it is. It cuts a Chinese family into about a hundred slices and tells the browser which characters live in which slice. That is what the 100 rules were. The browser then downloads only the slices that contain the characters on the page.

The catch is that ordinary Chinese prose is spread across many slices. One post of mine needed 20 of them. The slicing saved me from a font of several megabytes and still left me with one megabyte.

It also has a cost that is easy to miss: the 100 rules themselves. They were inlined in every Chinese page so the font could start loading early, which made every Chinese page nearly three times the size of its English twin before any font arrived.

The change: four lines of CSS

The fix was to stop sending a Chinese font and name the ones readers already have. Every iPhone, iPad and Mac ships with PingFang SC. Android ships with Noto Sans CJK, the same design I had been downloading. Windows ships with Microsoft YaHei.

html[lang='zh-Hans'] {
  --font-zh: 'PingFang SC', 'Hiragino Sans GB', 'Noto Sans CJK SC', 'Noto Sans SC', 'Source Han Sans SC', 'Microsoft YaHei', sans-serif;
  --font-sans: 'Geist Variable', var(--font-zh);
}

The third line puts the Latin font first, so English words and numbers inside Chinese text are still drawn in this site's own typeface, Geist. The browser falls through to the Chinese list only for Chinese characters.

That is the whole change in the stylesheet. The rest was deleting things: the font entry in the build configuration, the tag that loaded it, and the 100 rules that came with it.

I work with two Claude sessions, a Brain that plans and a Hand that builds. The Brain proposed this. I did not approve it on the idea. I approved it after the Hand had measured it and put screenshots of both versions side by side.

Before and after

After the change, a Chinese page requests exactly the same two font files as an English page. These are the numbers for the Chinese mamak table post, measured with Lighthouse mobile on the same machine, the same day, two runs each.

	Before	After
Font files	20	2
Font weight	1,107 KB	54 KB
HTML	143 KB	51 KB
HTML, compressed	48 KB	15.6 KB
Whole page	1,464 KB	318 KB
Largest Contentful Paint	3.7 s and 4.4 s	2.9 s and 2.2 s
Lighthouse mobile score	68 and 73	84 and 97

The Chinese home page went from 1,796 KB to 901 KB, and from scores of 40 and 42 to 51 and 55. It is still low, and I know why: the home page runs a 3D scene, which is a separate cost I wrote about. The font was half of that page's weight. It was not the whole problem.

What I gave up

What I gave up is control: the same page now looks slightly different on an iPhone, an Android phone and a Windows laptop. With a web font, every reader saw the same shapes.

One thing had to be checked before I agreed: that bold is really bold. A system font with only one weight makes the browser fake the bold by smearing the regular shape, and it shows. On a Mac, the browser drew the real faces: PingFang SC Regular for body text, Medium for headings, Semibold for bold.

I have not seen this site on Windows or on an Android phone with my own eyes, as of this writing. Microsoft YaHei has fewer weights than PingFang, so headings there may look lighter than I designed. I accepted that. A page that arrives is worth more than a page that matches.

What it did not fix

The first live measurement after shipping scored 76, not 97. The largest element took 5.6 seconds to appear. I had saved a megabyte and the phone score barely showed it.

I went looking for a cause and found a real one. The same day I had changed how analytics loads, and two Google scripts, 297 KB together, were now starting with every page and competing with the content. I moved them to load after the page is idle or at the reader's first touch. Three live runs on the same Chinese post after that: 92, 97 and 99.

But the scripts do not explain the 76. Before that fix went out, the same page on the same code was measured twice more and scored 95 and 92. The 76 was mostly one bad run. Moving the scripts lifted the typical score by a few points, not by twenty.

Two lessons from that. One measurement is not a result: the same page on the same code scored 76 and 95 a few hours apart, and I nearly built a story on the 76. And a page has more than one weight on it. Removing the biggest one mostly reveals the next.

One small thing is still open. In Chinese, a line should not start with a particle like 的. CSS has a property meant to break lines by phrase. I tried it. In the browsers I tested, it did nothing for Chinese. I left it.

How to check your own site

You can find out what your Chinese pages download in about two minutes, with no paid tool.

Open a Chinese page of your site in Chrome on a computer.
Open DevTools, go to Network, choose the Font filter, and reload.
Count the files and read the total at the bottom. If you see twenty files or a megabyte, you have what I had.
View the page source and search for @font-face. If the count is in the dozens, your HTML is carrying the font instructions too.
Open the same page in your other language and compare the two totals. The difference is what your Chinese readers pay.

If the number is large, try the stack above on one page, look at it on your own phone, and decide with your eyes.

FAQ

Should I use a web font or system fonts for a Chinese website?

For body text, use system fonts. A Chinese web font costs roughly a megabyte per page even when it is sliced and loaded well, and every modern phone and computer already has a good Chinese font installed. Keep a web font only for a short headline or a logo where the exact shape is the brand, and only after measuring what it costs.

Why is Noto Sans SC so slow to load?

Because Chinese needs thousands of characters and each one is a drawing. Google Fonts splits Noto Sans SC into about a hundred slices so a page downloads only what it uses, but ordinary prose still touches many slices. One ordinary post on this site needed 20 font files, 1,107 KB.

What is a good CSS font stack for Simplified Chinese?

This site uses "PingFang SC", "Hiragino Sans GB", "Noto Sans CJK SC", "Noto Sans SC", "Source Han Sans SC", "Microsoft YaHei", sans-serif, with the Latin font placed before it. It covers Apple devices, Android and Windows in that order, and ends in the browser's own default.

Do system fonts make a Chinese website look worse?

They make it look slightly different on each device, not worse. PingFang SC, Noto Sans CJK and Microsoft YaHei are the fonts your readers see in every app on their own phone. Check that bold text uses a real bold face, and look at the page on a real device before you decide.

I write about running a company and building with AI at yappatyih.com.

Can AI crawlers read your site? I checked mine

Yap Pat Yih — Sat, 03 Oct 2026 03:38:07 +0000

First published on yappatyih.com.

TL;DR

An AI crawler access check is a test of whether the bots behind ChatGPT, Claude, Perplexity and the others can fetch your pages, by requesting a page with each bot's name and reading the status code. On 30 September 2026 I ran one on this site: eight crawler names, eight answers of 200. Nothing was keeping the machines out. What the same audit found instead was a line in my own robots.txt, Disallow: /og/, that blocked the preview image of every page without a cover, plus a sitemap address that returned 404, one company with two ids, and dates that could claim a post was modified before it was published. All fixed the same day. On 2 October I ran the check again with ten names: ten times 200, 54,570 bytes each. Two of my original eight names turned out not to be crawlers at all. The command, the table and the five checks are below.

Why I checked

Since July 2025, Cloudflare has blocked AI crawlers by default on new domains unless the owner says otherwise. This site runs on Cloudflare. I write here so that people, search engines and answer engines can find what I think, and an answer engine cannot quote a page it was never allowed to fetch.

So before doing anything clever, I wanted the dull question answered: can they get in at all?

I run this site with two Claude sessions, a Brain that plans and a Hand that builds. The audit was the Brain's job, read-only: look at the live site from the outside, change nothing, write down what is true.

The check, in one command

Every crawler announces itself with a user-agent string. You can send the same string yourself and see what your server answers:

curl -s -o /dev/null -w "%{http_code} %{size_download}\n" \
  -A "Mozilla/5.0 (compatible; GPTBot/1.1)" \
  https://yappatyih.com/writing/the-mamak-table-question/

A 200 with the full page size means that name is let in. A 403, a challenge page or a much smaller size means something in front of your site is turning it away.

Here is the run from 2 October 2026, against one post on this site:

Name	Whose	What it does	Status
GPTBot	OpenAI	collects pages for training	200
OAI-SearchBot	OpenAI	builds ChatGPT's search index	200
ChatGPT-User	OpenAI	fetches a page when a user asks	200
ClaudeBot	Anthropic	collects pages for training	200
Claude-User	Anthropic	fetches a page when a user asks	200
PerplexityBot	Perplexity	builds Perplexity's index	200
CCBot	Common Crawl	open web archive many models use	200
Bytespider	ByteDance	collects pages for its models	200
Google-Extended	Google	not a crawler, see below	200
Applebot-Extended	Apple	not a crawler, see below	200

Every one returned the same 54,570 bytes a browser gets.

What the check cannot tell you

A 200 from my laptop proves less than it looks like, and I would rather say so than oversell it.

First, I was pretending. The request came from my own address with a borrowed name. It shows that nothing in front of the site blocks by name. It does not show what happens to the real crawler, coming from its own network, if a firewall judges it by address or behaviour. The only full proof is your server log: the real bot, the real status code.

Second, two of my eight names were wrong. Google-Extended and Applebot-Extended are not crawlers. They are words you put in robots.txt to tell Google and Apple whether pages their normal crawlers already fetched may be used for AI. Nothing ever visits your site calling itself Google-Extended, so testing that name with curl tests nothing. My audit of 30 September listed both as crawlers that "receive 200". That line was true and meaningless. For those two, the check is to read your robots.txt, not to send a request.

What the log says

After this post went out I looked at the log I said I had not checked. Cloudflare keeps one for AI crawlers. From 28 September to the morning of 2 October 2026 it counted 959 requests to this site from 17 crawlers, search engines among them, and no crawler was blocked.

Crawler	Whose	Requests answered
GPTBot	OpenAI	217
ClaudeBot	Anthropic	158
OAI-SearchBot	OpenAI	31
ChatGPT-User	OpenAI	27
CCBot	Common Crawl	24
PerplexityBot	Perplexity	14
Bytespider	ByteDance	4
Claude-User	Anthropic	3

So the knock on the door was honest: the real crawlers get the same 200 my borrowed names got. This post itself was fetched 17 times in its first three hours. And Google-Extended and Applebot-Extended appear nowhere in the list, which is what you would expect of two names that are not crawlers.

One more thing the log showed. Something calling itself an AI crawler asked this site for files named .env.production and credentials.json. It got a 404 each time, because those files are not there. A crawler's name is only a name. Let the real ones in, and keep nothing on your site that you would mind a stranger asking for.

What was actually blocked: my own images

The audit's first real finding had nothing to do with AI. My robots.txt said:

User-agent: *
Allow: /
Disallow: /og/

It looked tidy: a folder of utility images, kept away from crawlers. But /og/ held en.png and zh.png, the preview image that every page without its own cover hands to anything that asks for one. Preview fetchers that obey robots.txt were being told, by me, not to pick up the picture I had made for them.

The fix was one deleted line. The file is now four lines long, and /og/en.png answers 200 as image/png.

The same pass found three more things of the same kind, each a small lie the site was telling machines:

A sitemap address that did not exist. /sitemap.xml returned 404 while Bing still had it on file. It now redirects to the real index.
One company, two ids. In the structured data, my profile called BlackRevo by one id and BlackRevo's own page on this site called it by another. To a machine, that is two companies. Now each organisation has one id everywhere, the same one its own website uses.
Dates that ran backwards. A post's lastmod in the sitemap was the day it was last saved, in UTC, so a post saved before its publish time claimed to be modified before it existed. It now reads the publish time until a real edit happens.

The Hand fixed all of it on 30 September and left 102 passing tests behind, including ones that pin the ids and the sitemap dates.

What I stopped chasing

Every post here ends with a FAQ, marked up as FAQPage data. I used to think of that as a way to win the expandable questions under a Google result. That prize is gone: Google limited FAQ rich results to government and health sites in August 2023, and its documentation now says they are no longer shown at all from 7 May 2026.

I kept the FAQ anyway and changed what it is for. Each question is now a real heading with its own link, written the way a person would ask it, with an answer that stands on its own. That is not for a rich result. It is for a reader who skims, and for an answer engine that reads a page in pieces and needs each piece to make sense alone.

The heavy thing on this site, the three.js world behind the pages, was measured in the same audit. That became its own story: the night my post pages scored 39.

The five checks

This is the whole method. It takes ten minutes and no paid tool.

Read your robots.txt as a stranger. Open it in a browser. For every Disallow line, name what lives there. If you cannot, find out before a crawler does.
Knock with each crawler's name. Run the curl command above for each real crawler on one page. Same status and same size as a browser, or you have a block to find.
Fetch everything your pages point to. The og:image, the sitemap, the canonical address, the feed. Check the status and the content type, not just that something came back.
One thing, one id. In your structured data, a person or a company gets exactly one id, the same on every page and on every site you control.
Dates that cannot lie. Published, modified and sitemap dates should agree with each other and with what happened.

None of this makes an answer engine quote you. It only removes your own reasons for it not to. What gets quoted is still a page that says one true, specific thing clearly. This list is how you make sure that page can be reached.

FAQ

How do I check if AI crawlers can access my website?

Send a request to one of your pages with the crawler's user-agent string, for example with curl -A "Mozilla/5.0 (compatible; GPTBot/1.1)", and read the status code and size. A 200 with the full page means that name is allowed. Repeat for each crawler you care about, then confirm in your server log that the real bots receive 200 too.

Does Cloudflare block AI crawlers by default?

For domains added since July 2025, Cloudflare blocks known AI crawlers unless the owner chooses to allow them, and it can also manage your robots.txt. On this site, tested on 30 September and 2 October 2026, nothing was blocked and robots.txt was served exactly as written. If your site is on Cloudflare, look at the AI Crawl Control section of the dashboard and run the check yourself.

Is Google-Extended a crawler?

No. Google-Extended is a token for robots.txt that tells Google whether content its normal crawlers fetch may be used for its AI models. Nothing visits your site with that name. Applebot-Extended works the same way for Apple. You control both in robots.txt, not in a firewall.

Is FAQ schema still worth adding in 2026?

Not for a rich result: Google no longer shows FAQ rich results as of 7 May 2026. I still write a FAQ on every post, as real headings with self-contained answers, because readers skim to them and answer engines read pages in pieces. The structured data costs nothing to keep.

I write about running a company and building with AI at yappatyih.com.

The night my post pages scored 39

Yap Pat Yih — Fri, 02 Oct 2026 02:11:16 +0000

First published on yappatyih.com.

TL;DR

This site draws a particle world behind every page, tens of thousands of points in the shape of my mark, in three.js. I chose it knowing the cost and wrote the decision down: weak devices are sacrificed by choice. Then I had it measured. A post page on a simulated phone scored 39 out of 100 on Lighthouse, with 3636 ms of blocked main thread and a largest paint at 5.70 s. The same page without the world scored 97. I kept the world where it is the point, the home page, and stopped loading it on post pages unless the screen is wide, the pointer is a mouse and the reader has not asked for less motion. The post page now scores 97 on a phone and still draws the world on a desktop. A day later the world was crossing the text on desktop too, so a veil went behind the column, taking the worst spot from 1.59:1 contrast to 7.33:1. At the end is the test I now run before I sacrifice anything: what is this page for.

A decision I made on purpose

When this site was rebuilt in September I made a choice most advice says not to make. The background is a live three.js scene: a single brush stroke, drawn with tens of thousands of points, that takes three forms, a stroke, a circuit, a galaxy. It is the mark of the site in motion. It is heavy, and I knew it.

So I wrote the decision down, in the handbook my planning session reads first every day: heavy three.js is accepted; weak devices are sacrificed by choice. Content must still be real HTML for search. I did not want to be talked out of it one small compromise at a time.

I still think that was the right way to decide. Write it down, and you can find out later exactly what you were wrong about.

Measure first, change nothing

I run this site with two Claude sessions, a Brain that plans and a Hand that builds. On 30 September, after an SEO audit, the Brain's prompt to the Hand had one step that was different from the others: measure the world's cost on a post page, and change nothing.

The Hand ran Lighthouse in its mobile simulation against a local copy of the mamak post, once with the world and once without, same page, same build.

Post page, phone	With the world	Without
Score	39	97
Largest Contentful Paint	5.70 s	2.21 s
Total Blocking Time	3636 ms	0 ms
Page weight	733 KB	191 KB

Thirty-nine. Three and a half seconds in which a phone could not respond to a touch, on a page whose only job is to be read.

The home page told a different story: 95 with the world, 97 without. The same scene cost two points there and fifty-eight points on a post. The difference is not the code. It is what the page is for.

Sacrifice by page, not by site

The lazy fix is a switch: world on or world off. The honest one is to ask each page what it is for.

The home page is the mark. The world is the point of it, the thing a visitor came to see, and on a phone it costs two points. It stays.

A post page is for reading. Nobody opens a long essay on a phone to watch particles behind it. There, the world is pure cost, and I had been charging every phone reader 3.6 seconds for a decoration they could barely see behind the text.

So the rule became: a post page draws the world only when all three of these are true. The screen is at least 1024 px wide. The pointer is fine, a mouse or trackpad, which is the cheapest honest signal that this is a laptop and not a phone in landscape. And the reader has not set their system to prefer reduced motion. Fail any one, and the page never downloads the world at all. It gets a still ground instead: the same near-black, one soft crimson glow near the top, not animated.

The Hand built it, with tests that pin the three conditions and all eight combinations of them. Measured again:

Post page	Score	LCP	TBT	Weight	World loaded
Phone	97	2.18 s	0 ms	191 KB	no
Desktop	98	0.98 s	81 ms	734 KB	yes

Same page, same essay. The desktop reader still gets the world. The phone reader gets the essay.

The world came back for the text

A day later I was reading the bottom of a post on my own laptop and could barely make out the author box. The ring was crossing the text column. The dark pool behind the article was a soft radial gradient, fine in the middle of a short page, gone by the bottom of a long one.

Measured at the worst spot, where the ring crossed an excerpt, the text had 1.59:1 contrast against the pixels behind it. The minimum for body text is 4.5:1.

The fix is a veil: a dark band at 0.8 opacity behind the whole text column, full height, feathered at the sides so there is no box, and only on desktop where the world runs. The same spot now measures 7.33:1. The ring is still there, at the sides and faintly through the band. The words come first.

Two days, two corrections to one decision, and I would make the decision again. The world is still the identity of this site. It just stopped charging people who came to read.

The page's-job test

Before I let any page pay for anything, four questions.

What is this page for? One verb. Watch, read, decide, buy. If the expensive thing is not the verb, it is a decoration, and decorations are the first thing to go on a slow device.
Measure on the phone, not the laptop. My laptop said the world was fine. It was fine, on a laptop. Lighthouse's mobile simulation was the first thing that told me the truth, and it took one prompt.
Sacrifice by page, not by site. Global switches punish the page where the expensive thing was the point. Decide per page, and write down the conditions so they can be tested.
Keep the identity in a still form. Removing the world from phones did not mean removing the brand. The still ground is the same colour and the same glow. Nobody who arrives on a phone sees a different site, only a quieter one.

And write the original decision down before you measure it. A decision you cannot find is one you cannot correct.

FAQ

What is Lighthouse?

Google's open-source page audit, built into Chrome. It loads a page under a simulated slow phone and network and scores it from 0 to 100 on performance, from metrics such as Largest Contentful Paint, Total Blocking Time and Cumulative Layout Shift. The numbers in this post are its mobile simulation on a local preview, so they compare like with like.

Why not just remove three.js from the site?

Because on the home page it is the point, and there it costs two points on a phone. The cost was only unacceptable on pages whose job is reading. So the decision is per page: the home page always draws the world; a post page draws it only on a wide screen with a fine pointer and no reduced-motion preference.

How does a page know it is on a phone?

It does not, exactly. It asks three media queries: is the viewport at least 1024 px wide, is the pointer fine, and has the reader not asked for reduced motion. All three must be true before the world is downloaded. A phone in landscape fails the pointer test; a small laptop window fails the width test and gets the still ground, which is acceptable.

Did the change hurt the desktop experience?

No. The same post page scores 98 on desktop with the world loaded. What the desktop needed was a reading veil behind the text column, added the next day, which took the worst contrast on the page from 1.59:1 to 7.33:1.

I write about running a company and building with AI at yappatyih.com.

Why I run my company on a Brain and a Hand

Yap Pat Yih — Fri, 02 Oct 2026 02:11:06 +0000

First published on yappatyih.com.

TL;DR

I run two kinds of Claude Code session. The Brain reads, investigates, decides and writes a brief. The Hand pastes that brief, builds, commits and reports back. The Brain never touches code. This site was rebuilt that way in two days: one Brain session, six Hand sessions, just over a hundred commits. The same split runs Lumen, the internal system at BlackRevo, and Habitus Mind. It works because it is delegation, and delegation is a craft I already had to learn as a General Manager.

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.

Where to work and what to read first, by file name.
What it must not do. No push, no deploy, no credentials, no production resources.
What this is: two paragraphs of context, so the Hand understands the why, not only the what.
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.
Numbered steps, each ending in a commit with a given subject.
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

Open two sessions and name them. Brain, Hand. The names matter more than they should.
Tell the Brain, in one sentence, that it only writes briefs and never edits code. Tell it what the Hand may not do.
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.

I write about running a company and building with AI at yappatyih.com.