This lesson looks at how little Allan wrote before an AI built a twelve and a half minute film, what those few words were spent on, and where the rest of the work really was. After it you should be able to plan how to direct an AI build of your own with very few words.
Count the words
Behind the paper plane, the film in the last lesson, is 12:28.8 long. Before it was built, Allan wrote 13 messages about it, 884 words in all, and went to bed. The narrator of the finished film speaks 1,314 words. There were also two corrections: one before the film was built, and one after it was done.
What the words were spent on
The film shows the messages by size, not by text. Grouped by what they were about:
- The first three (229 words): what the film is, who it is for, real screens redrawn in the film’s style, and the idea under everything: a well prepared project gets the right result without wasting tokens.
- Two short rules: say “80+ styles”, never an exact count, and keep the bumps (the mistakes) in the story.
- The long one (365 words, four of every ten): the picture in his head. A blueprint of the old project, a window rising off it as glass, the new project pouring out as liquid metal and setting as a wireframe, a rolodex of style cards with a paper plane on the ones the first film used, a more serious tone, and paper planes hidden in it as a tribute.
- The rest, short: how to run the build, a yes, answers to four questions, “I approve” at eight minutes to midnight, a worry about running out of usage in the night, and a check-in every 30 minutes.
By their topics, none of the messages explains how to write a script, record a voice or render a frame. Allan spent his words on purpose, audience, vision and limits. The how was already in the project.
Let a fresh reader test the plan
Before Allan approved the design, a fresh AI with no chat history read it cold and asked four questions. Allan answered all four in one message. A cheap test: if a reader with only the files can build from them, the files are ready.
Correction one: the record was wrong
Then the script arrived: six parts, every fact traced back to the record. Allan read it and found one line that was wrong. It said he makes videos for clients. He does not.
The wording came from older notes, so the fact was traced, but the record itself was wrong. The lesson: traced is not the same as true. A person who knows the facts still has to read the script at its gate.
Thirty-four hours, built without him
The thirteenth message went at 00:36. What came next took about 34 hours: six parts, each voiced, drawn, checked and exported before the next began. Helper AIs built the pictures, and fresh helpers checked what they built. Every half hour a timed check read the record and carried the build on if it had stopped. The result was 170 saved steps, each with a note saying what changed. Allan’s other messages during the build were about the cost of usage, not about the film.
Correction two: every check passed, and it was still wrong
At 10:54 on the second morning the film was ready. About an hour later Allan had watched it: “it is amazing! That high level video from only 13 messages from me.”
He had also found one error. A time on the screen said 7:20 where he expected 17:20. Then he looked closer. It was not one digit: the line of light mixed clock times from two different days with a moment from inside the film, all in one row, with nothing to tell them apart. Twelve minutes later he wrote: “It is a mess.”
The checks had measured every frame, and not one was broken. But the line did not make sense to a person. Allan’s decision: keep only what the voice says. Seven marks became three, fixed and checked the same afternoon, and the film was posted before the afternoon was over.
Where the work really was
Thirteen messages sounds like very little. It was not. The work was done before the first message, in the folders, the rules and the record.
The stages folder holds a contract for each stage, _shared holds the house rules and the list of voices, and worlds holds each art style of the film as code. The record is the review log and the git history. The messages only had to point the way. The project knew the rest.
What to do with this
Allan’s own advice, from his post about this episode:
- Count your own words. If a short brief gets a big result, the reason is somewhere else, and it is worth finding.
- The checks can pass and the result can still be wrong for a person. Keep a human watch at the end.
- Prepare the project before you prompt. That is where the work is.
This episode was made by the same system, with Claude Code: every frame drawn in code, the screens redrawn from the real project, and a synthetic narrator voice from ElevenLabs.