How to get better Anime.js results from Codex and Claude Code

I tried to build an animated interface with a coding assistant several times. The code worked, but the result looked cartoonish.

The assistant had added rounded cards, oversized shadows, playful movement, and visual details I never requested. I kept changing the prompt, but the output still felt wrong.

Then I changed what I gave it.

Instead of describing the final idea in one paragraph, I supplied more context, several reference images, the real visual assets, and the exact order in which each part should appear. The result improved immediately.

That experience taught me something useful: the coding assistant was not struggling with Anime.js. It was filling gaps in my design brief.

Anime.js can control timing, movement, easing, transforms, and sequencing. It cannot decide what your product should look like. When you leave the visual direction open, Codex or Claude Code must invent it. The result will often drift toward a generic animated demo.

This guide shows how to remove that guesswork.

What Anime.js is actually responsible for

Anime.js is a JavaScript animation engine. You can use it to animate CSS properties, transforms, SVG attributes, JavaScript objects, and DOM elements.

Its timeline API coordinates several animations through createTimeline(). Its stagger() utility distributes timing or values across several targets. These are useful when interface layers need to enter in a deliberate sequence rather than all at once.

The library handles motion. Your HTML, CSS, images, typography, spacing, and component structure still define the visual result.

That distinction matters when working with an AI coding assistant:

• Your references define the visual language.
• Your asset list defines what appears.
• Your storyboard defines the sequence.
• Anime.js executes the movement.
• Codex or Claude Code connects those decisions to the codebase.

If the first three are vague, polished animation code will still produce the wrong experience.

Why my first result looked cartoonish

My first prompt mostly described the outcome. It did not provide enough evidence about the design.

The assistant had to make several decisions by itself:

• What should the device and interface look like?
• Which elements should appear first?
• How much should they move?
• Should the motion feel serious, playful, physical, or cinematic?
• Which images were structural layers and which were only inspiration?

The assistant answered those questions with common frontend patterns. That is how a technically correct build can still look generic.

The improved attempt worked because I replaced vague taste words with inspectable material. Instead of saying "make it premium," I showed the target composition. Instead of saying "animate the parts," I numbered the assets. Instead of saying "make it smooth," I described the timing and movement of each stage.

The workflow that produces better results

Step 1: build the static frame first

Do not begin with animation.

Ask the assistant to build one accurate static frame using the real assets. Check the layout at desktop and mobile widths. Fix the scale, spacing, cropping, typography, colors, and stacking order before importing Anime.js.

If the static frame is wrong, animation makes the problem harder to diagnose.

Your first acceptance criteria can be simple:

• the composition matches the main reference
• every supplied asset is used in the correct place
• no placeholder illustrations are created
• the interface works at the required breakpoints
• the page has no animation yet

Step 2: separate references from production assets

Put the files into clearly named folders:

project/
references/
target-desktop.png
target-mobile.png
motion-example.mp4
public/
animation/
01-device-shell.png
02-screen-background.png
03-header.png
04-content-card.png
05-navigation.png

References explain the target. Production assets are the files the website will render.

Tell the assistant which is which. Otherwise, it may copy a reference image into the page, recreate a supplied component, or substitute its own shapes.

Numbering the production assets also removes ambiguity. The filenames become a basic storyboard.

Step 3: create a visual specification

Add a short DESIGN.md file to the project. Keep it specific.

# Visual specification

- Use the supplied assets. Do not redraw them.
- Match `references/target-desktop.png` for composition.
- The visual style is restrained and technical.
- Avoid cartoon styling, glossy 3D icons, thick outlines, large shadows,
exaggerated bounce, random gradients, and invented decorations.
- Use the existing project font and color tokens.
- Preserve the original aspect ratio of every image.
- The device remains the main visual focus.

Negative constraints are useful here. "Premium" is subjective. "Do not use thick outlines or bouncing cards" is testable.

Step 4: write the sequence before the code

Create a motion table that the assistant can follow.

Stage

Element

Start

Duration

Movement

Purpose

1

Device shell

0 ms

600 ms

Opacity 0 to 1, scale 0.96 to 1

Establish the frame

2

Screen background

250 ms

500 ms

Opacity 0 to 1

Reveal the surface

3

Header

450 ms

450 ms

Y 14 px to 0

Introduce hierarchy

4

Content cards

600 ms

550 ms

Y 18 px to 0, stagger 80 ms

Build the interface

5

Navigation

950 ms

400 ms

Opacity 0 to 1

Complete the screen

The values are a starting point, not a universal formula. The important part is that every element has an order and a reason.

Step 5: give the assistant project memory

For Codex, place stable project instructions in AGENTS.md. OpenAI's frontend guidance recommends using it for commands, constraints, and established project patterns.

For Claude Code, use CLAUDE.md. Anthropic recommends keeping the file short and focused on architecture, commands, conventions, constraints, and known problems.

You can use the same core rules in both files:

# Animation rules

- Use Anime.js for the main timeline.
- Build and approve the static frame before adding motion.
- Read `DESIGN.md` and inspect every file in `references/` first.
- Use the numbered assets in their filename order.
- Do not create replacement illustrations or decorative shapes.
- Keep movement subtle. Avoid bounce unless the motion specification asks for it.
- Support `prefers-reduced-motion`.
- Validate the result with desktop and mobile screenshots.
- Run the build and existing tests before finishing.

These files should contain durable rules. Keep the current feature request in your prompt.

Step 6: make the assistant inspect before editing

Do not ask it to code immediately.

Start with an inspection task:

Inspect the current frontend, DESIGN.md, the reference files, and the numbered
production assets. Do not edit anything yet.

Return:
1. the existing component and styling patterns you will reuse
2. the role of every supplied asset
3. the proposed DOM layer order
4. the Anime.js timeline in milliseconds
5. any conflict or missing information

Review that plan. If the assistant misunderstands an asset, correct it before implementation.

Claude Code's official guidance recommends using a planning step for work that touches several files. OpenAI's Codex frontend guidance follows the same practical pattern: inspect the existing system, reuse its design tokens and components, then verify the result in the browser.

Step 7: implement one motion system

Once the static frame is accurate, add a single timeline.

import { createTimeline, stagger } from 'animejs'

const timeline = createTimeline({
defaults: {
duration: 550,
ease: 'out(3)',
},
})

timeline
.add('.device-shell', {
opacity: [0, 1],
scale: [0.96, 1],
}, 0)
.add('.screen-background', {
opacity: [0, 1],
}, 250)
.add('.screen-header', {
opacity: [0, 1],
y: [14, 0],
}, 450)
.add('.content-card', {
opacity: [0, 1],
y: [18, 0],
delay: stagger(80),
}, 600)
.add('.screen-navigation', {
opacity: [0, 1],
}, 950)

Explicit start positions make the sequence easier to review. A timeline also keeps related motion in one place instead of scattering delays across components.

If you use React, scope the animation to the component and clean it up when the component unmounts. The Anime.js React guide uses createScope() inside useEffect() and calls scope.revert() during cleanup.

Step 8: respect reduced-motion preferences

Motion should not be required to understand or operate the interface.

Anime.js scopes can react to media queries, including prefers-reduced-motion. Use that preference to remove or shorten nonessential movement. The final state should remain visible and usable when animation is disabled.

Ask the assistant to verify both modes:

Test the normal animation and prefers-reduced-motion. In reduced-motion mode,
render the complete final state without entrance movement. Do not hide content.

Step 9: compare screenshots, not descriptions

The final instruction should require evidence.

Ask Codex or Claude Code to run the project, open the target page, and capture screenshots at the exact widths you care about. For a motion-heavy interaction, ask for a short recording or screenshots at specific timeline points.

OpenAI documents image input for Codex and recommends breakpoint screenshots and interaction evidence for frontend review. Claude Code also accepts screenshots, and its project memory can preserve the rules that should apply across later sessions.

Review these items:

• composition and scale
• asset order
• cropping and image quality
• spacing and alignment
• first frame and final frame
• motion timing
• mobile behavior
• reduced-motion behavior
• console errors and build output

"Looks good" is not an acceptance test. A side-by-side comparison is.

A prompt you can give to Codex or Claude Code

Build the animated interface shown in the supplied references.

Before editing:
- read AGENTS.md or CLAUDE.md
- read DESIGN.md
- inspect every file in references/
- inspect the numbered assets in public/animation/
- inspect the existing components, design tokens, and responsive patterns

Do not create replacement illustrations, cartoon elements, extra gradients,
large shadows, or decorative shapes. Use the supplied production assets.

Work in three checkpoints:

Checkpoint 1: return the asset map, DOM layer order, and motion timeline.
Do not edit code yet.

Checkpoint 2: build the responsive static frame with no animation. Run the
project and provide desktop and mobile screenshots for review.

Checkpoint 3: after the static frame is approved, add one Anime.js timeline
that follows the agreed sequence. Support prefers-reduced-motion and clean up
the animation when the component unmounts.

Before finishing:
- run the build and existing tests
- check the browser console
- capture the final desktop and mobile states
- record the interaction if screenshots cannot show the timing
- list the files changed and any remaining visual differences

The same prompt works with both assistants. Replace the paths, breakpoints, and constraints with your project details.

Common mistakes

Asking for "a smooth premium animation"

This gives the assistant taste words but no measurable target. Supply a reference, a sequence, movement limits, and an acceptance test.

Sending one flattened screenshot

A screenshot shows the destination, but not the layers. Provide separate assets or explain which elements must be built as DOM components.

Animating before approving the layout

You will waste time changing motion when the real problem is scale, typography, or composition.

Letting the assistant invent missing assets

Generated placeholders often change the visual direction. Tell it to stop and report missing files rather than inventing replacements.

Adding animation to every element

More movement does not make an interface more polished. Animate changes that explain hierarchy, state, direction, or cause and effect.

Skipping cleanup and accessibility

Component-based applications need animation cleanup. Users who prefer reduced motion also need a complete, usable final state.

The practical rule

Coding assistants perform better when they can inspect the target, the ingredients, and the definition of done.

My better result did not come from a cleverer sentence. It came from better evidence: more context, more reference images, correctly ordered assets, and a sequence the assistant could follow.

Use Anime.js after the visual design is clear. Give Codex or Claude Code enough material to compare its work against the target. Then review the output in the browser, not only in the code diff.

If you want more practical guides on AI coding, automation, and building production-ready agents, follow me on LinkedIn and visit AhmedSalama.co to stay updated.

Sources

• Anime.js timeline documentation
• Anime.js stagger documentation
• Using Anime.js with React
• Anime.js scope and media query documentation
• OpenAI: Agentic frontend development with Codex
• OpenAI: Codex image input and browser verification
• Anthropic: Give Claude context with CLAUDE.md and better prompts
• Anthropic: Claude Code user FAQ