DEV Community: Andriy Yurchenko

Building Ribbonlab, a 3D Animated Background Generator

Andriy Yurchenko — Fri, 13 Nov 2026 19:32:39 +0000

Originally published on ayurchenko.xyz.

The image above opens the live editor. Ribbonlab is a free browser editor for 3D animated backgrounds. I built it on my own over a few evenings of spare time. Claude Code wrote most of the code. I decided what the tool does, looked at every change in the browser and said what was wrong until it looked right. This piece shows that work on the three parts that took the most of it: the textures, the shape and the settings.

How the work went

Every change went the same way. I opened the editor, looked at the ribbon and wrote what was wrong in one line, usually with a screenshot: one edge of the wave looks buggy, the glitter sits on top and does not move, this texture darkens the ribbon. Claude Code found the cause in the shader or the panel and fixed it. I checked the result in the browser and either moved on or sent the next line. The repository has 243 commits from 8 to 22 October, most of them one change I could see.

The editor on the Aurora preset. The ribbon fills the page and the panel stays to one side.

Textures

One version of the silk read like a muscle with veins. The threads were thick and contrasty, and the light lay across the surface in wavy bundles, pale on dark blue. The fix was a smooth surface with fine, straight threads along the band. Then I tuned the threads by eye and kept the values: Streaks from 0.28 to 0.44, Glow from 1.3 to 0.89, Grain from 3.5 to 3.1. At those values the silk reads as millions of threads.

Left: the silk that read like a muscle. Right: the silk that shipped.

Next I asked for textures as good as the silk, and the answer started with why the silk worked. Its threads follow the band, so every twist bends the pattern with it. Their light depends on how the surface turns, so the pattern moves when the ribbon moves. Leopard, zebra and polygonal were prints laid on top, and they stayed flat. The textures added after that follow both rules: moir√© from two layers of threads drifting in and out of step, guilloch√© lines that swell in shadow and thin in light, chameleon paint whose hue turns with the viewing angle, mercury that mirrors a studio with softboxes sliding over it, and a twill weave. Snake did not look good, so it went.

Glitter took two rounds. The first one lay on the ribbon like a still sticker. Now each flake is fixed to the fabric, twinkles on its own beat and flares when its patch turns to the light. Then the flakes lined up in rows, so they are scattered over two layers, turned and shifted against each other.

Fibre optic took three. The first version was even dark stripes. It became two layers of strands with uneven spacing, each strand with its own thickness and brightness, light gathering in patches that drift down them, and a few strands in the palette‚Äôs accent colors. Then it made the whole ribbon darker. It switched off the silk threads that give the ribbon its pale edge, dimmed the base by 10%, and far strands blurred into a grey veil. Now the strands glow over the silk threads, and the ribbon is as bright as on Silk.

Fibre optic on the same violet ribbon. Left: the first version. Right: the one that shipped.

Lenticular showed that some sliders did nothing. So every Surface slider was tried on each of the 23 textures. Streaks worked only on silk, and now they show only for silk and fibre optic. Texture strength did nothing above 1 on half the textures. Now 0 turns any texture off, 1 is its designed look and 2 doubles it. Pattern density was added for every texture that has a pattern.

Two weeks later I saw polygons on Satin, one per triangle of the mesh, and noticed that picking a texture changed the ribbon‚Äôs base color. The light on the band was computed once per triangle. It is now computed at the corners and blended across. Every texture now keeps the average light of the silk threads, so switching textures keeps the color. In the same pass, Mercury and Liquid chrome reflected in grey and lost the ribbon‚Äôs color, and Pearl and Lenticular bleached it toward grey. All four are now lit in the palette‚Äôs colors. Chameleon and Holo film stayed as they were, because shifting the color is the point of them.

Mercury on the pink Sakura palette. Left: a grey mirror. Right: the same mirror lit in pink.

Fibre optic, glitter, brushed metal and pearl, each from one of the presets.

Shape

The first ribbon was a folded band whose two layers twisted apart. I asked for one band with three plain controls: width, length and thickness. Folded stayed as a second form.

Then one edge of the band looked broken while the other was clean. The edge is seen side-on, and its light jumped from one row of the mesh to the next, drawing ticks across it. The edge got its own smooth light. Near one side of the band the faces sheared apart under the width twist, so the twist now holds rigid over the outer 8% of the width.

The Shape folder holds the form, width, length and thickness, three twists (along the length, across the width and in depth), a falloff for each twist that sets how quickly it fades, and Wave, the size of the slow waves rolling through the band. I moved them by eye until the ribbon swept across the frame the way I wanted, copied the values out as JSON and made them the defaults. The changes look small in numbers:

Control	Start	Default now
Twist length	-0.65	-0.36
Twist width	0.41	0.62
Twist depth	-0.58	-0.19
Width falloff	0.70	0.88
Length	400	432
Thickness	8	2.5

Same palette, same seed. Left: the starting values. Right: mine, now the default.

Turning the ribbon got its own controls in View: Rotate X, Y and Z sliders, and an axes widget in the corner. Clicking the end of an axis turns that axis toward you, the short way round. Randomize keeps the shape near the default composition. The twists, falloffs and wave move within narrow ranges (Twist width 0.25 to 1, Wave -12 to -3) and the seed does the rest. With wide ranges the ribbon slid to the edge or filled the whole frame.

The Shape folder on the default ribbon.

Settings

The panel has seven folders in the order people tune a background: Color, Adjustments, Shape, Surface, Effects, Motion and View. On the first visit only Color is open. Brightness first sat in Effects. It changes the color, so it moved to a new Adjustments folder with saturation, contrast and hue. Each effect is a switch, and its sliders sit in the same card only while it is on.

There are 53 palettes in eight groups by hue, each with two to six colors, and you can add or remove colors within that range. Picking a palette changes only the colors. Every other slider stays where you put it, so trying palettes never throws work away.

The white palettes exposed a setting nobody could see. A grey ribbon came out blue. One line in the color shader cooled every shaded side: red dropped to 45% and blue only to 75%. It gave the blue and violet ribbons their depth and made grey and warm ones look dirty. I made it a slider, Shadow warmth, with the usual cool shadows in the middle, deeper blue to the left and warm to the right. Each palette sets it when picked. Greys and warm palettes go neutral.

Cobweb, a white palette. Left: the old fixed cool shadows. Right: the neutral shadows it now sets itself.

Neutral values also sat in odd places on their sliders. Brightness ran from 0.3 to 2, so its neutral 1.0 sat at 40% of the track. Ranges with a neutral point are now symmetric, and the neutral value sits in the middle. The slider called Warmth turned out to mix in the accent colors, so it is called Accent mix now.

Randomize works on one folder with the dice on its header, or on everything at once with G. Each slider draws from a range where results look good instead of anywhere on its track: brightness 0.92 to 1.12, saturation 0.85 to 1.3. Loud settings move only sometimes: hue and rainbow in 15% of rolls, iridescence in 30%. Randomize all keeps your texture, because a texture suits some looks and not others. The Surface dice picks textures by weight, Silk most often, and skips Liquid chrome, Marble and Sequins, which gave muddy results at random. Randomize and Reset both show an Undo.

Presets went through ten placements, each prototyped in the working editor: a window of rendered ribbons, a folder in the panel, a stage with the preset name, a card deck and more. Each one covered the ribbon or competed with the panel. What shipped takes no space. The left and right arrow keys flip ten presets with a crossfade, and a small pill names each one, then hides.

Two of the ten preset prototypes: a window of ribbons and a stage.

A background video has to repeat without a jump. With Seamless loop on, the wave blends into the same moment one loop earlier, so the end meets the start. Glitter, sequins and fibre optic run on their own timers, and those blend the same way. Auto-turn makes whole turns per loop. The first export recorded the canvas in real time, added a stray frame at the start and lost frames at the end. Export now renders the loop frame by frame with exact timestamps, so a two-second loop is exactly 60 frames. I asked why export offered two or three loops of something that repeats anyway, so a loop exports as one loop, with its length taken from the Loop length slider in Motion. GIF is offered only for loops.

Export also gives code, and the code went through four designs. A standalone HTML file handed out the whole editor. An npm package would have published the renderer for anyone to copy. A short id with a script tag worked until Framer turned out to strip script tags from embeds. An iframe of the ribbon‚Äôs own page shipped: it loads in Webflow, Framer, WordPress and Shopify, React gets a script snippet and Notion a plain link. Each player version is frozen once it ships, so a ribbon on someone‚Äôs site never changes when I change the look. I also built a lock that kept each ribbon to named sites, and removed it, because it made the first use harder for everyone.

Export, Code tab. One snippet, with a note on where it goes in each site builder.

Speed

PageSpeed Insights first reported Error on every metric. Its test browser has no GPU, and opening WebGL in software froze the page for one to two seconds. The page now checks the GPU in a background worker, shows a still of the ribbon where there is no GPU, and starts the renderer after the page has painted.

PageSpeed	Before	After
Mobile	31	80
Desktop	41	98

Why this matters for your product

Claude Code wrote most of the lines. The decisions in this piece are mine: what each texture should look like and when it was good enough, which sliders exist and in what order, which ranges random values may take, and what to cut. Each one was judged in the running product, so ten versions of one decision took a day.

I work the same way with teams, from deciding what to build to a working release. See Fractional Product Design, start with a Product Diagnosis, or write to me.

Questions

Is Ribbonlab free?

Yes. The editor, every export and the embed code are free, and there is no account to create.

How do I add an animated 3D background to my website?

Open Ribbonlab, tune a ribbon, then choose Export and Code. The HTML snippet goes into a code embed in Webflow, Framer, WordPress or Shopify, React projects use the React snippet, and the guides show each builder step by step.

Which textures does Ribbonlab have?

Twenty-three, in three groups. Fabric: silk, satin, velvet, twill, matte and latex. Metal and shine: mercury, liquid chrome, brushed metal, chameleon, holo film, lenticular, fibre optic, pearl, glitter and sequins. Pattern: moir√©, guilloch√©, marble, topographic, leopard, zebra and polygonal.

Can I export a seamless looping video?

Yes. Turn on Seamless loop in the Motion folder, set the loop length, and export one loop as MP4, WebM or GIF. WebM keeps a transparent background.

How long did Ribbonlab take to build?

A few evenings, in spare time, a little at a time rather than in one stretch.

Who made Ribbonlab?

Andriy Yurchenko, a product designer and design engineer. He made the product decisions, designed and built it on his own, with Claude Code writing most of the code, and takes products for teams from the first decision to a working release.

This article first appeared on ayurchenko.xyz. I am Andriy Yurchenko, a product designer and design engineer. More of my writing is at ayurchenko.xyz/writing.

Design Systems for Coding Agents: 11 Builds, Measured

Andriy Yurchenko — Fri, 13 Nov 2026 19:31:52 +0000

Originally published on ayurchenko.xyz.

I gave one AI agent the same brief again and again: with no design system, on shadcn/ui, and on a product whose look had been decided before the first screen. Then I measured every element it shipped. The first pass turned out to be the easy part. What a system is for now starts after it.

I have built a design system for every product I have worked on, and over 14 years that is dozens of products. The early ones were Figma libraries and pages of documentation for people. The recent ones live in code, and I implement the components in Storybook myself, because the designer who writes the components is the first to see every gap in the system.

Now agents write a lot of the interface. Founders ask me a fair question. If Claude Code or Cursor builds a screen in minutes, and shadcn/ui gives everyone a component library for free, what is a design system still for? I wanted to answer with numbers instead of an opinion, so I ran two tests.

The setup

The product is Halden, a dashboard for a coffee roaster in Portland with six cafes and a wholesale line. I made it as a test bed for a review tool: an agent built it in one evening on a visual direction I set first, a token file and a small kit, with no design system behind it. The tool and that evening are in A canvas for reviewing AI-built UI.

The agent had six screens to build: the home dashboard, a list of transactions, a customer record, the business settings form, a new wholesale order, and an order with its timeline. Every build got the same written brief, the same data and the same model, Claude Sonnet in Claude Code, in one pass. None of them saw a screenshot of Halden or a line of its CSS.

No system, twice. React and Tailwind, no component library, no tokens. What a founder gets from Cursor or Claude Code with a prompt.
shadcn/ui, twice. A fresh shadcn setup with its default theme, the stack Lovable starts from.
Halden, a decided look with a thin system. Four of the six screens come from Halden itself, built in one evening as a test bed for a review tool on a token file and a small kit: no rules for states, no component descriptions, no checks. Halden had no wholesale section, so the other two are the wholesale screens an agent added in the growth test below, from the build that did have a rules file, a catalog and an audit. I took the versions before any review fixes.

For every screen a script opened the page in headless Chrome at 1440 pixels and read the computed style of every element: how many different buttons and fields there are, which values fall outside the build‚Äôs own scale, which looks appear only once. Then it changed the main color, the corner radius and the density in one place, and counted what followed.

What the numbers say

Less than I expected. On the first pass every build came out reasonably consistent.

Across six screens	No system (2 runs)	shadcn/ui (2 runs)	Halden (a decided look, thin system)
Different button looks	9 / 8	13 / 12	12
Different field looks	2 / 3	4 / 3	4
Looks used only once	15 / 17	17 / 15	16
Values off the build‚Äôs own scale	7 / 10	6 / 6	21
Raw Tailwind colors around the theme	no theme	34 / 24	no Tailwind
Main color change followed	100% / 100%	100% / 100%	100%
Radius change followed	100% / 76%	100% / 100%	79%
Every button has a disabled look	no / no	yes / yes	no
Time to build	6.5 / 9.0 min	6.0 / 5.7 min	one evening, with the kit

The builds with no system did not stay without one. Before the first screen, both agents wrote their own small block of tokens and a file of buttons, fields and cards. Tailwind v4 hands them variables for spacing and radius out of the box, so even these builds changed density in one place.

shadcn/ui shipped the most complete states: every button had a disabled look and a loading state. Halden lost on exactly the things a system is for. Five button heights, 21 values off its scale, no disabled look, the browser‚Äôs default focus ring. That is what a look without a system produces, and it is the point of this article: decisions give a product its face, and a system is what keeps that face consistent and complete.

So the first pass is no longer where a product goes wrong. An agent on a modern stack gets the basics close enough by itself.

What the numbers miss

The same dashboard in four builds. Top: Halden, then the first shadcn/ui build. Bottom: the second shadcn/ui build, then the build with no system. Screenshots at 1440 pixels, top of the page.

Put the screens next to each other and the measurements stop being the interesting part. The two shadcn/ui builds are the same product twice: the same grey, the same black bars, the same weight on every card. Any other company that ships the default theme gets this face too, because nobody decided anything about it.

The build with no system picked a brown ‚Äúcoffee‚Äù palette on its own. That is a choice, and the agent made it, not the company.

Halden has a look because someone decided it. One blue accent, used only where it carries meaning. A quiet grey for everything else. Density set for a manager who checks numbers between two cafes. None of that comes in a component library. It is a set of decisions, and tokens are the way those decisions get written down so that an agent can follow them.

Where the default theme had no decision, the agents filled the gap themselves. shadcn‚Äôs theme has no color for success or warning, so both shadcn builds styled their statuses with raw Tailwind colors: 34 classes in one, 24 in the other, all out of reach of the next theme change.

The new order form in three builds: Halden, shadcn/ui, no system. Screenshots at 1440 pixels, top of the page.

A short brief builds a different product every time

I ran a control. The same two stacks, twice each, got a one-paragraph brief, the way founders often write one: six screens and their addresses, the data file, and ‚Äúmake it look good‚Äù.

The screens looked fine. The agents chose palettes, added cards nobody asked for, and one rewrote the shadcn theme to match a brand it imagined. But a third of the concrete decisions disappeared: of 79 items in the detailed brief, the builds kept between 43 and 50. No build had a loading or an error state. Two runs of the same stack disagreed about the product itself, bars against a line, today against the last seven days, different cards on the dashboard. Looks used only once rose to between 23 and 29 in three of the four builds.

Same stack, same paragraph, two runs. Screenshots at 1440 pixels, top of the page.

That is the part an agent does not invent: the decisions. The detailed brief did not make the screens prettier. It made them complete, and the same twice. A design system is that brief, written once, for every screen the product will ever have.

Where drift starts: the second screen, and the fiftieth

The first test I ran was about growth. Three agents added the same six-screen wholesale section to Halden, which already had its token file and component kit in the code. One got only the brief. One also got written guidelines, the kind of page a team keeps in Notion. One got the system in a form an agent reads: a rules file, a catalog that says what each component is for and when not to use it, and an audit it had to run until it reported nothing.

On screen, the three sections looked almost the same. The agents copied the existing screens, mistakes included: two of them took a hard-coded field height from Halden‚Äôs settings form straight into their new code. The difference was underneath:

In the new section	Brief only	Plus written guidelines	Plus rules, catalog, audit
Raw values in new code	34	25	0
New CSS classes	31	29	5
Lines of CSS added	233	187	91
Where the styles went	a stylesheet for this section	a stylesheet for this section	shared components, recorded in the catalog
Agent time	8.1 min	7.3 min	4.4 min

The first two forked the product. Each wrote a private stylesheet for one section, with about thirty classes nobody else can reuse and values that will not follow the next token change. Every screen looks right today. The cost arrives with the next fifty screens, when nobody knows which of three similar buttons is the real one.

The third agent added the missing form fields as components of the whole system and wrote them into the catalog, so the next agent finds them. It was also the fastest. A system that answers the agent‚Äôs questions saves the time it would otherwise spend guessing.

One more detail. The written guidelines said cards have 16 pixel corners. The code said 24. The agent followed the code. Documentation that lives apart from the code drifts, and an agent always believes the code.

What I put in a system now that agents read it

What changed in the last two years is the reader. A system used to be documentation for designers and engineers. Now it is also the input a coding agent builds from, and the thing its output gets checked against. These are the parts I add for that reader.

Code is the source of truth. Tokens and components live in the repository and in Storybook. Figma is where the design work happens and gets synced back. When the two disagree, code wins, and the sync merges changes instead of overwriting them, so values that exist only in code survive it.
Names an agent reads the way people do. If a list row lives inside a component called ‚Äúmenu‚Äù, every agent will build menus out of it. Renaming is a design decision.
Descriptions written for an agent. Every component says what it is for, when not to use it and what to use instead. The intent lives in one place. A second copy of the same text goes stale, and a stale description misleads an agent more than no description at all.
A rules file, tested blind. An agent builds a screen without being told about the system. Then I plant violations in clean code and check that the rules catch every one of them, with no false alarms.
States for every component. Hover, focus, disabled, loading, error, empty. Halden skipped them, and the table above shows what that costs.
A Figma file an agent can read. An agent checks layer names, component descriptions and token bindings, so that design-to-code reads intent rather than geometry.
Checks on what ships. A token audit that flags raw values in new code, and an inventory of the running product that finds what drifted (how I review it). The findings go back to the agent as tasks. Whether a person can finish a task is a separate check: the UX audit agent.
A rule for anything new. A new look becomes a variant of an existing component. New behavior gets a component of its own. A new job gets a new component built from the old parts. Anything else turns into a one-off.

This is what the third agent in the growth test read before it touched the wholesale section, shortened. The rules file says where values come from and what to do when nothing fits:

AGENTS.md, excerpt

Read this file and COMPONENTS.md before you write any UI. These rules are checked by npm run audit.

Source of truth
- styles/tokens.css is the only source of values. Every color, size, space, radius, font size, weight, shadow and duration in new code is a var(--token). No hex, rgb, hsl or oklch literals, and no px values except 0 and 1px borders.
- Do not add tokens. If a value you need has no token, use the nearest one and say so in your final message.

When nothing fits
- Add one component to styles/components.css, built only from tokens, plus an entry in COMPONENTS.md. Then use it everywhere it applies.
- Never style an element for one screen only. If a screen needs a look that no component has, that look is a component.

Before you finish
Run npm run audit. Fix every finding, then run it again. Repeat until it reports 0 findings, or explain in your final message why a finding must stay.

The catalog answers the question the other two agents answered by guessing: which piece is the right one. Every row says what it is for and what to use instead:

COMPONENTS.md, four of 21 rows

badge(label): every status; tone comes from the tones map. Not for categories or counts.
stat({label, value, change, note}): one headline number with an optional change. Not for lists of numbers (use table or .facts).
segmented(q, key, options): switching between 2 to 5 views of the same list. Not for filters with many values (use chip).
timeline([{label, note, state}]): the steps one record has gone through. Not for steps the user fills in (use .stepper).

Neither file is long. The rules file is 23 lines and the catalog 29. What makes them work is the last rule: the audit runs until it reports nothing, so the agent cannot finish with a raw value in the code.

Your own system, shadcn‚Äôs skeleton, or shadcn as it is

shadcn/ui is a good start, and the test shows why: its components came with the most complete states of any build. The question is what you need on top of it, and that depends on the time you have and what the product has to do.

shadcn as it is fits a prototype, an internal tool, or a product where looking like everyone else costs nothing.
shadcn‚Äôs skeleton, reworked fits most startups. Keep the behavior and replace the decisions: your color roles, including success and warning, your density, your type, your corners, and component descriptions written for agents.
A system of your own fits when the product‚Äôs look is part of what you sell, when several products or brands share one system, or when the team will grow past the point where anyone remembers the exceptions. In my experience shadcn‚Äôs tokens and interactions are not consistent enough from one component to the next for that, so I build from one token logic and one set of interaction rules. It takes longer at the start. Afterwards the team, and its agents, read the logic instead of memorising exceptions.

Whichever you choose, the test that decides it is the same, and it takes more than one round: give an agent a real task, look at what it shipped, find where it guessed, and fix the system there.

Where this comes from

I have built a design system for every product I worked on. The ones I can show, and what they changed, are in the case studies: TrueFi, Deva and 10Planet, Equi and Fully AI.

What to do this week

Take an inventory of what your product ships: every button, every field, every value outside your tokens. Count them.
Write down the decisions an agent keeps guessing: color roles including success and warning, density, type, corners.
Give each component a description: what it is for, when not to use it, what to use instead.
Add a rules file, then test it: let an agent build one screen and see where it guessed.
Check new code for raw values before every merge.

If you would rather have someone do the first step, that is what the Consistency Review is.

How I ran the test

Eleven one-pass builds in total: four from the detailed brief, four from the one-paragraph brief, two of each per stack, plus three in the growth test, one per condition. Claude Sonnet, in the background, checked with a production build only. The agents were not told it was a test.
The agents ran with my general coding preferences, which already favor CSS variables. That makes the builds with no system better than a typical one, so the gaps here are conservative.
Halden‚Äôs brief did not ask for interaction states. The other builds‚Äô briefs did.
Two runs per stack is a small sample. The spread between two runs of one stack was sometimes as large as the spread between stacks.
A ‚Äúlook‚Äù is an exact match of computed styles, so two nearly identical buttons count as two.
The rebrand check changed the main color, multiplied the corner radius by 1.6 and the density by 1.25, and counted the share of elements that moved.

Cheap and expensive

Anyone can build a product now. An agent will give a founder a working app in an evening, and every screen in it will look reasonable. That is the new floor, and most products will stand on it, in the stack‚Äôs default theme or a palette the agent picked, looking like every other app built the same way.

What lifts a product off that floor is a set of decisions the agent will not make: which states every control has, which color means success, how dense a table can get for the person who reads it between two meetings, where the one accent goes and where it never goes, which of three similar buttons is the real one. In both tests, the builds that had those decisions written down came out complete and the same twice. The ones that did not were reasonable and different every time.

Making those decisions well takes taste and having watched real people use real products many times. Writing them down so an agent follows them is now part of the same job. Agents made building cheap; the decisions are the expensive part.

This article first appeared on ayurchenko.xyz. I am Andriy Yurchenko, a product designer and design engineer. More of my writing is at ayurchenko.xyz/writing.