Directing AI like a VFX supervisor: briefs, notes and references
The difference between "make it better" and a fix you can see. How to brief, how to give notes, and how to turn a reference into numbers a model can hit.
- Claude Code
- any LLM
- screenshots
The fastest progress I've had with AI came from the same notes I'd give an artist in a review. The slowest came from vague taste. This playbook is the note-giving system I use, pulled from building this site: about forty rounds on one portrait.
Brief the outcome, not the steps
A good brief says what it's for, what good looks like, and what's off-limits. It doesn't say how to write the code.
Weak:
Make a cool hero section.
Strong:
The home page needs one gesture that says "craft, now code". A split screen: left is hand-made (ink, white), right is machine-made (pixel grid, black, our orange #f5a02a). The divider is a draggable A/B wipe, like a compositor's. No stock imagery. It must work on a phone.
Include the audience, the constraint and the signature idea. Leave the implementation to it.
Show, don't describe
Models are far better with references than adjectives. Give it:
- An image of the look you want. Paste or drag it in.
- A screenshot of the current state, marked up. Circle the problem in red and say what's wrong with it.
- A comparison: "left is ours, right is the reference, match the right."
Give notes like dailies
One note per issue. Say where it is, what's wrong and what right looks like:
| Instead of | Say |
|---|---|
| "It looks off" | "The ears stick out about a third too far" |
| "Make it more elegant" | "The chest lines are symmetrical, so it reads like a sweatshirt. Make them uneven and broken" |
| "It's too fast" | "The decode is jarring: the glyphs change every frame. Slow it to about 12 changes a second" |
| "Fix the layout" | "When the cursor blinks, 'Syracuse University' drops a line and then jumps back up" |
Specific notes produce specific fixes. Vague notes get you a guess.
Measure the reference
When "more like this" stops working, turn the reference into numbers. For the portrait I had Claude write a small script that measures an image:
- how much of the frame is lit (19% in the reference)
- how bright and saturated the colour is, and which hues
- how aligned and soft the strokes are
It then scores our render against the reference, metric by metric. That changed the conversation from taste to targets: "lit area is 16% and should be 19%; colour saturation is 0.13 and should be 0.29."
Analyse this reference image and write a short fact sheet: tone, colour, texture, structure. Then write a script that scores a render against it on the same measures.
- Our render16%
- Reference19%
- Our render0.13
- Reference0.29
Make it prove the work
Ask for evidence, not reassurance:
- "Screenshot it at desktop and phone widths."
- "Measure whether anything moves during the animation."
- "Run it and paste the output."
If it can't show you, it hasn't checked.
Know when to cut
Some directions don't work, however well you note them. In this build, a scroll story, an offline-render frame player and an "ink smoke" effect were all built, worked, and were thrown away. Say it plainly: "This isn't working. Revert to the previous version and let's try a different approach." With git, that costs nothing.
Note-giving checklist
- Brief: purpose, what good looks like, constraints
- References: images, not adjectives
- One note per issue: where, what, what right looks like
- Marked-up screenshots for anything visual
- Evidence before approval
- Cut and revert without guilt
Next playbookBuild your first real tool, from idea to working app →
Bren Builds
What I built with AI this week, what broke, and what I learned. One email, weekly.