DEV Community: Yap Pat Yih

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.