I'm a high-load systems engineer, and I recently launched a small frontend project without writing any of the frontend code myself. An AI coding agent produced the implementation while I guided it. The project lets someone send a question with YES and NO buttons, where the NO button dodges the pointer. It has been live for about two months.
The surprising part is that the code itself was not the difficult bit. The hardest part was explaining the animations I imagined. I repeatedly tried to describe the timing, movement, and overall feeling, but the result often looked nothing like what I had in mind. The biggest failure was a black-hole animation where the button gets pulled inward, the surrounding elements rotate and disappear into the hole, and fragments come back out. I even experimented with real physics, but it still did not capture the effect I wanted.
The project also started spreading on its own after a few posts, with people sharing it and sending traffic and payments even when I was not actively promoting it. That was the most rewarding part: making something that continued to echo outward by itself.
Some people have interpreted the dodging NO button as refusing to accept an answer. I see it more as a teasing toy, not a date invitation. Users can close the page whenever they want, every invite has a report control, and I built a test that performs twenty NO interactions in sequence and fails if any of them becomes a YES. The button dodges, but the person remains in control.
For anyone using AI agents to build frontend interfaces, what techniques help you translate motion and visual ideas from your imagination into something the agent can implement accurately?
3 Answers
Use visual references instead of trying to describe the entire animation in prose. A screen recording, GIF, or even a somewhat similar interactive example gives the agent concrete timing, easing, and movement to work from. Then explain only how your desired result differs from the reference. Agents tend to modify an existing motion pattern more successfully than they invent one from an abstract description.
Plan the feature before asking the agent to implement it. I usually open a separate conversation, describe the idea in detail, and have the agent produce an implementation plan. I go back and forth until the plan reflects what I actually mean, then pass that cleaned-up plan into a fresh implementation conversation. Separating planning from coding makes the results much more predictable.
That is pretty close to my workflow too. The same basic rule applies here as with a normal project: plan first, implementation second.
Chaotic motion is especially hard to communicate because words describe mechanics, while the thing you are chasing is often a feeling of timing and momentum. References help, but it also makes sense to break the effect into stages: attraction, rotation, entry, disappearance, and debris coming back out. Tune each stage separately instead of asking for the whole black-hole effect at once. Also, the automated test for twenty NO interactions is a smart way to verify that the joke stays a joke rather than becoming misleading.
Exactly. I eventually realized I was not really describing mechanics anymore; I was trying to explain a visual feeling that only existed in my head. And thanks—the repeated-NO test was added specifically to keep the interaction from becoming sketchy.
That is a useful approach. The exact reference will not always exist, but starting from something visually close seems much better than explaining a feeling from scratch.