How two pieces of this site were made

I teach people to work with Claude, so it seems fair to show my own working. Both pieces below are running on this page, and both took more than one attempt. The attempts are the useful part.

The Crossing: a paper boat that leads to a form

The homepage ends with a booking form, the point at which a visitor slows down and decides. I wanted something to carry the eye there. This was the opening prompt, with the spelling tidied:

I want a Three.js scene as a paper-cut scene of five seconds. A boat floating on a river, that would fit with the site design.

That sentence could have produced a hundred different boats. So before any code was written, Claude Opus turned it into a design brief and saved it as a file. The brief gave every colour a role, set out the layers from sky to reeds, and timed each movement to the tenth of a second. It also set one rule. Rust appears once. Everything is cream or ink except the sail.

Claude Sonnet then built from that file at its extra-high effort setting, and was told to read every screenshot it took. The early rounds had the palette and the layers right. They also had a sail like a tent, a ghost of a shadow under the hull and a grey flash as the layers rose. Each of those went back as a specific note.

Part of the way through, I changed the brief:

I want this as an intro to the booking form, so the scene runs into the form.

Because the plan lived in one file, that change was one new section of the brief and an instruction to read it again. The layers now darken as they come forward, until the foreground is the same ink as the form below it. That is how the join disappears.

On an Intel UHD 770, the sort of graphics found in an ordinary office PC, the scene holds 60 frames a second at 1440 pixels wide and about 40 at 1920. Those are measured figures, taken on real hardware.

How we'd work together: the idea I threw away

The homepage section on how I work has four steps, and it needed an animation. The headline says "tailored to your team", so the first idea took that word literally: one sheet of paper, measured, cut, stitched and altered on a workbench as the visitor scrolled.

The build was sound. It ran at 60 frames a second, reversed exactly when you scrolled back, and passed 73 automated checks. My first note was:

It does not show the finished garment, so it looks a mess.

So the pieces became a waistcoat, with buttons, pockets and neat stitching. Then I looked at it again:

It makes no sense. The diagrams mean nothing. This work is not good enough. Try again.

The tests had measured whether it worked. None of them measured whether it meant anything. A visitor should not have to solve a picture to learn what working with me involves. Polish could not fix that.

We started again with two rough directions, and put them in front of a reader with no background: a fresh Claude Sonnet session that saw only the stills and was asked to judge them as a busy manager would. It scored a table showing a team's plan 6 out of 10, and a panel of moving words 4 out of 10, calling the words "stylish but abstract".

The table scored higher, but it needed example tasks that no client had ever given me. The words needed nothing invented, because every one of them is already in the section. I chose the words, and used the reader's complaints to correct them. A line struck through "shouldn't" had read as an edit and reversed the sentence, so it became an underline. Plus signs had contradicted "or some combination", so they became the commas from the real sentence.

This is the result. Scroll through it, then scroll back.

What the prompting shows

The prompts I typed were short and mattered least. The written brief did the real work. A model on a long task forgets, and fills gaps with the average of what it has read, so decisions belong in a file it can reread.

Three habits mattered. Constraints were specific enough to check: "rust appears once" can be verified by eye, and "tasteful use of colour" cannot. Revision notes began with what to keep, as in "the palette, layers and ink seam are right", because a model told only what is wrong will happily change what was right. And every brief defined finished as evidence: screenshots read, no console errors, real output from the tests.

What the models did

Using one model for everything is a common mistake, and I see it often. These pieces used the same family of models in three different jobs.

What the work involved

1. BriefA few plain sentences about the outcome.
2. Written specificationPalette, layout, timing and rules, saved where the model can reread them.
3. BuildA separate model works to the specification and may touch only the files it is given.
4. LookEvery stage is reviewed as a picture, because a passing test cannot see a sail that looks like a tent.
5. TestAutomated checks, Firefox and Safari's WebKit engine, and frame rates on real graphics hardware.
6. Cold readSomeone with no context says what it means.

The checking found a real fault. A deliberate stress test showed the jigsaw on the booking form failing to build in 10 of 80 runs, because the code was reading an out-of-date scroll notification. Nobody would have seen that on a quick look.

It also caught the models themselves. One builder reported that a check failing on the new code also failed on the old code. Claude Opus ran it again and the old code passed. A side-by-side trace then showed that both versions behaved identically and the check's fixed wait was too short. The code was sound and the report was still wrong. A model's report is a claim until someone has run it.

What the thinking was

The decisions that mattered most were made outside the prompts. Knowing that a thing works and knowing that it means something are separate questions, and only the first can be automated. Knowing when to stop is harder. Adding the waistcoat was polish applied to a wrong idea, and it made the failure clearer. And saying plainly what has not been checked is part of the work. Both browser engines passed, but a real iPhone has not yet had its turn, and a test you did not run is a result you do not have.

What I would take into a training session

• Write decisions down where the model can read them again.
• Say what to keep before you say what to change.
• Give the making to one model and the checking to another.
• Ask for evidence, and then actually read it.
• Test the meaning on someone who was not in the room.

None of that depends on being technical. It is how to get reliable work from anyone, and it is what I teach.