Words are control surfaces
Last week, I was struggling with a liquid animation I’d spent hours on. I wanted a shape to emerge from a larger menu like a droplet of water.
Here’s the initial prompt I used alongside my Figma designs:
When the previous button is clicked, this menu opens. We want it to open from the cursor’s trigger point and the button’s placement, not from a fixed left or right side.
It should emerge like a smooth, liquid-morphed rectangle flowing out of the main button. Use this liquid UI code example as a reference for the feel.
This was frustrating because it kept producing a rectangle that simply slid out of another rectangle. It was basically just a change in Y position, even after I gave it a direct codebase reference for a liquid-gooey morph.
Now compare that to the result when I explained the morph mechanism with better vocabulary:
The customise bottom tray should emerge from the main menu like a gooey, liquid tray. Think of the bottom tray as a child component that comes out of the main menu: it should start as a droplet and scale or morph into the full tray. Once the tray has formed, its icons should animate in from their original positions.
As the droplet separates, it should leave a small liquid trail that lingers until everything fully solidifies. The main menu should also show a subtle trail effect.
Some rules to keep in mind:
- Treat
LiquidItemas the main component. effect="morph"→ merging blobs for groups, menus, and avatars.effect="move"→ rubbery slider or tab indicators with trailing tails.- Use
morphandmoveobjects like tuning knobs:0..1for bounce, wobble, and springiness.speedfor tempo.dissolveto control how much content melts where items touch.
- Assume the file’s whole job is:
- Normalize: turn designer-friendly knobs into stable physics.
- Protect: warn or block combinations that look visually wrong, such as
dissolve+move.
I shared Jakub’s GitHub repo, asked my browser to explain the code to me, and used that explanation to shape the prompt.
With my first prompt, I just wanted to get the idea out without overthinking it. That can also be an efficient approach: get something small and tangible out instead of writing huge markdown files that clutter the context window. Start rough, then zoom in on different components and polish through iterations.
“Iteration is key. None of the current interfaces fully solve the problem of specifying your intent to the model in the most efficient way.” Silas Alberti, Cognition
Referencing later, curating first
Types of referencing:
- Media: photos and videos
- Other websites
- Open-source codebases and GitHub links
- Code snippets for micro-level component behaviours
- States and storyboards
- Articles from design engineers, designers, and technical breakdowns
Meng To talks about using screenshots and screen recordings when building 0–1 tools with AI. Screenshots and recordings are one way to reference, but there are many more powerful options.
Here, more ≠ better.
The more precise the references, the better. If I want a right sidebar on my website, it’s best if I reference, via a link, screen recording, or states, exactly how I want the sidebar to behave instead of attaching ten inspiration images of different sidebars without specifying behaviour.
Another approach I find useful is to bookmark as many technical articles as possible, even if you’re not particularly technical or don’t fully understand them. When used with the right context, these articles teach your agent the mechanics of what you’re trying to build.
For example, I’d reference make exit animations feel better to apply across all my menus at once, so my agent understands that exit animations should not mirror entry animations, with one-off conditions excluded. The context consumed here is minimal because I’m referencing one small part of an article to improve exit animations across my site. You don’t need a whole 500-word skill for this. Being concise and articulate is better.
A library of strong references is a goldmine for building. It’s less about having everything memorized, and more about using the same references often enough that you start remembering what applies where.
Josh’s animation blogs are another treasure trove. Reading them on a car ride home beats blindly prompting with them. After all, my agent’s performance is only as good as my understanding. Consider this component alone: it was made with Codex by referencing squash and stretch.
We can take this a step further by referencing snippets from a course you bought. I use content from Interface Craft a lot to reference relevant builds with my agent, because prompting is knowledge transfer. Transferring knowledge from the greats also transfers some taste into the output.
For something like liquid UI on frontend, referencing open-source codebases like Jakub Antalik’s liquid-gooey is another shortcut: it teaches an agent the feel and mechanics we’re aiming for.
Generative design tools can be another way to reference and explore ideas in code. Variant helps with components and shaders in React; you can attach those React snippets to your agent and then tweak where needed. Almost all shader prototypes on this website were generated with Variant, then refined with 5.6 Sol.
Referencing starts with the art of collecting because you can’t reference what you don’t know exists. There are countless useful, time-saving resources built by amazing people on the internet, and we’d be foolish not to use them and build on top of them.
Skills cannot save you (alone)
I like to think of skills with this analogy: imagine you hire someone to do your dishes. You’d hand them a set of instructions showing where each kind of plate goes, the sizing arrangement, and so on. That would be super useful. Now imagine you hand them a manual and blueprint of your entire house instead of just stating where the dishes go in the kitchen. Think about the cognitive load they’d have to endure just to reach the part that matters.
A lot of us use whole web-improvement skills to improve a single button. That’s one reason a model’s output can degrade over time on the same task, even if it does the job well at first: cognitive load for humans is what context load is for models.
Here’s a list of all my skills, but I find myself using fewer and fewer over time. I usually use them for audits instead of creation. When I do use them, it’s for highly specific tasks rather than “overall improvements.”
Rules create stability
Context equilibria: a balance between newly injected code or tool outputs and the model’s intrinsic tendency to dilute past instructions.
Having a tight set of rules before starting a project helps keep my agent on track. These rules apply throughout the project. They can live in a markdown file, but they can also be as simple as a few guiding facets or pointers.
For example, my guiding facets for this article are:
- Observations with practical examples
- Avoid jargon; if I use it, add contextual explanations
- References, lots of them
I like to check these at a few points during writing so I don’t drift. Managing agents with project-specific facets like this gives them a recurring evaluation frame.
For a design project, these could look like:
- No serif fonts anywhere by default. Only use them if explicitly asked.
- Only two typefaces at a time: title or subtitle, and body.
- Enter animations should ease out; exit animations should ease in.
- All animations should stay under 350ms; repeating animations should be under 200ms.
- Use a four-point grid system for all layouts and sizing.
- After coding every animation, check its behaviour before the final pass.
Anchoring prompts at the end of a context window also helps the agent stay aligned. For now, it’s helpful to know exactly when my agent’s output starts degrading so I can course-correct. Methods for context finessing should probably end up in a new article once I have more information through trial and error.
Tile artwork: horse model and gallop by Mirada for ROME, adapted into binary. CC BY-NC-SA 3.0.