I learn how things work by building them, then I write about it.

I'm Daniel Liew. Each project below has a demo that runs in your browser and a short account of how I built it, including what broke.

If you enjoy what you see, email me. I'd be glad to build something together.

Tiny LM

I trained a small language model from scratch on seven old books about business and self-help. It runs in your browser with no machine learning library. Type a sentence and watch it cut the text into tokens and guess the next word.

Parameters: 3,737,088
Parity with PyTorch: within 1.2e-5, on five fixed inputs
Download: 14.9 MB, fetched once
Training: 4,500 steps, 7 minutes, Apple M4 Pro GPU

Try it How it was built The code

Layer 1, head 1, reading “The man who saves a little every week will have money”. Each row is one token looking back at the tokens before it, in stronger blue where it looks harder. “money” looks hardest at “have”, at 21%.

What it showed

You can watch every step a language model takes, with nothing hidden inside a library. A model this small picks up the sound of its books, and its sentences wander after a few words.

AI Agent Arena

Claude plays Congkak, a traditional mancala game, against a search bot, and a referee checks every move. Before each move, Claude says how many seeds its store will hold afterwards, and the engine checks that too. You can play the bot yourself or watch Claude's games move by move.

Haiku 5.5 against the search bot: 0 wins, 20 games
Replies refused by the referee: 0 of 262
Own store predicted exactly: 71%, one-line rule 81%
Cost of the run: $0.042, 20 games

Try it How it was built The code

Before each move, Haiku said how many seeds its store would hold afterwards. The bars show how often it was exactly right, beside a one-line rule that adds one seed whenever the sowing reaches the store.

What it showed

Haiku never broke a rule, and it still lost every game to a bot that looks four moves ahead. A one-line rule predicted Haiku's own moves better than Haiku did.

Style scorer

I turned my writing rules into nine checks that run in your browser, then tested them against professional writers' edits and readers' rankings. Paste a paragraph and see each break marked in place.

Picked the reader's favourite: 50%, shorter text 62%
Two readers agreed: 82%
Test set: 450 rankings, 150 paragraphs
Claude judge: built, not yet run

Try it How it was built The code

How often each method picked the version a reader ranked higher, on the pairs it could split. Half is a coin toss.

What it showed

On fiction, the rules did no better than a coin toss at picking the version readers preferred. Writers did cut the stock phrases the rules flag, by more than half.

RAG, Measured

A walkthrough of how a document reaches a language model's context window, from a PDF to an answer. The retrieval models run in your browser, and seven ways of finding the right passage are scored on 1,310 questions.

Reranked, evidence first: 42%, plain vectors 32%
Questions: 1,310, 408 research papers
Model download: 62 MB, fetched once
Every model call behind the page: $0.32

Try it How it was built The code

How often the passage holding the answer came first. Paragraphs means plain vector search over paragraphs.

What it showed

A reranker that reads the question and the passage together put the right passage first most often on research papers. On company filings full of tables, it did no better than plain vector search.

Redactor

A page that hides names, ID numbers and contact details in text, pictures and PDFs inside your browser, before you paste them into an AI chat. Every document in its test is made up.

Names fully hidden: 78%, rules alone 0%
Names of Indian origin: 41%
Test documents: 450, all made up
Download: 30 MB, fetched once

Try it How it was built The code

Share of names fully hidden in pasted text. Claude Haiku 5.5 ran once as a paid reference and is not part of the page.

What it showed

Rules caught every ID number and no names. The small model caught most names, and fully hid fewer than half of the names of Indian origin.

How your ride app finds a driver

A small server matches riders with drivers in a simulated city on real roads from OpenStreetMap. Change how it matches or how busy the city is, and watch the waits change. Click a rider to see how its request was handled.

Closest car not fastest by road: 51% of requests
Batches every 5 s, normal demand: 4.0 s longer wait
Grid against checking every car: 150 times faster, 100,000 cars
One server process: 1.3 million updates a second

Try it How it was built The code

Average wait from request to pickup by matching method, over 20 seeds with 500 cars.

What it showed

The car closest in a straight line was not the fastest by road in about half of requests. Matching in batches made riders wait longer unless the city was busy.

Free to take

A checker for your own writing. Paste a paragraph into the style scorer and see which rules it breaks.
The full code of any project above. Email me and I'll send it.
New notes by email, as I write them. Email me and I'll add you to the list.