Didko.dev

What it is

Didko.dev is an animated UI component library for React and Vue. Dark theme only, every component animated, MIT license, free to copy. The part that makes it worth writing about: the components are not hand-written, and they are not curated from GitHub. Each one is generated by an AI pipeline — an idea, a brief, then working code — rendered in a sandbox, reviewed by a human, and only then published.

As of July 2026 the database holds 191 generated components, of which 81 are published — 79 React, 2 Vue. The catalog covers buttons, cards, navbars, text effects, cursors, docks, backgrounds and WebGL shaders, with the shader collection — molten lava loops, pixel-art canvases, aurora flows, glitch text — as the current storefront.

The problem

Two problems, one per hat I wear.

The designer's hat. I design in Figma. I don't write React. Between "I can see this component in my head" and "it exists as working code on a page" there has always been a wall: learn to build it, or find a developer, or scroll someone else's library hoping they had the same taste. Component libraries are other people's taste, frozen and shipped.

The observer's hat. Almost every animated-component library looks like every other one. The same glassmorphism cards, the same neon buttons, recycled from the same GitHub gene pool. Copies of copies. If a machine can write components at all, the interesting question is not "can it produce one nice demo" — it's whether you can build a factory: a pipeline that produces components in volume, keeps itself from repeating, tracks what each piece costs, and still ships nothing without a human saying yes.

Didko.dev is that experiment.

The approach

The platform is Laravel 11 with Inertia.js and React 18 on the front, PostgreSQL underneath, Filament v3 as the admin, and a systemd queue worker doing the heavy jobs. Claude Code built it. The CLAUDE.md in the repo opens with a confession that doubles as an architecture decision: "I'm a designer. I'm not a developer and I don't deal with technical details — those decisions are yours." I described what things should look like and how they should behave; the agent implemented, and asked me only about the things that would affect the future of the site.

The generation pipeline went through two versions.

Version one was a chain of three models. Model 1 looked at the database and proposed an idea that didn't exist yet — a fresh combination of category, style and behavior. Model 2 turned the idea into a technical brief. Model 3 wrote the component. React components went through Anthropic models, Vue through OpenAI, and an auto-balancer generated for whichever technology was falling behind. It worked, and it had a certain elegance — three specialists passing work down a line.

Version two is simpler, and better. The idea and brief stages collapsed into a deterministic seed: the orchestrator composes the brief from seed digits, and one strong code model per technology writes the component — Claude Sonnet for React, GPT for Vue. A matrix_rules table encodes which combinations are allowed and which are banned, so uniqueness is enforced by data, not by asking a model to remember. Elegance lost, control gained.

Every generation is measured. Each component carries its own tokens_used and cost_usd, and a generation_logs table records every step with the model that ran it. I can sort the catalog by what a component cost to make. Most AI-generated products can't answer that question; this one logs it from day one.

Key decisions

A runtime contract instead of hand-wiring

The feature I care most about is Customize. Open a component page, and next to the live preview there's a panel of controls — colors, ranges, selects, toggles — that reshape the running component in real time. Not a screenshot with a color picker drawn on top; the actual component, re-rendering as you drag.

The mechanics: a small model (Claude Haiku) reads the component's code and returns a JSON list of its tunable parameters, which is cached in the database so the analysis happens once. The panel renders those as inputs. Every change goes over postMessage into the sandboxed iframe where the component runs, and lands in window.__paramSetters — a registry of state setters that every generated component is required to expose. That requirement, the CUSTOMIZE RULE, lives inside the generation prompt itself.

This is the decision I'd defend hardest: put one small convention into the generation contract, and every component that will ever be generated is customizable for free. No hand-wiring, no per-component work. "Save as Default" persists your values and re-renders the component's screenshot.

Constraints as identity

Didko has rules that sound like limitations and act like a brand. Dark theme only — the background is always #0d0d0d, and no light mode exists. Animated only — no static components, ever. The accent is #EF404F, and the brand doc keeps an explicit blacklist of deprecated oranges marked "never use." The generated code has its own bans — no TypeScript inside components, no template literals — constraints imposed by the in-browser runtime that renders them.

These rules are why eighty-odd machine-made components read as one library instead of a junk drawer. Models produce coherent output when the space they're allowed to explore is shaped in advance. That shaping is design work — it just happens in prompts and rule tables instead of Figma.

Previews that don't lie

Every card in the grid shows the component actually running, not an artist's impression of it. Components render in an iframe with the real runtime — React directly, Vue through an SFC loader — with a fit routine so nothing jumps and the background never flashes white. A queue job screenshots each component, and ffmpeg turns recordings into WebP and H.264 previews for the grid. If it looks broken, it is broken, and it doesn't get published.

Identity and design

The mark is DD, set in Poetsen One — a rounded display face that reads friendly against a near-black canvas. Red #EF404F is the only voice the interface itself is allowed to raise; everything else stays quiet so the components can be loud.

The project didn't start under this name. Early on it sat under a placeholder umbrella brand I reused across a couple of experiments — IL — and moving to Didko.dev was a deliberate step from "fake company" to "personal thing with a name I actually like." The PostgreSQL database is still named after an even earlier incarnation of the idea. Projects mutate; names catch up later.

Dark-only deserves one more sentence, because it's a brand decision disguised as a feature cut. The components are the light source. Shaders, glows, neon text — all of it needs a black canvas to be legible. The site's job is to disappear. The component should be the only bright thing in the room.

What's there now

Live at didko.dev. 81 published components, WebGL shaders as the flagship collection, and a fully operational admin pipeline — generation runs from an artisan command with auto-balancing, or from buttons in Filament.

The honest list of what's rough:

• View and copy counters on the cards are placeholder numbers for now. Real analytics are on the list.

• The Vue side is far behind — 2 published against React's 79. The in-browser Vue loader fights the generated code more than React's runtime does, and I've prioritized volume where the pipeline runs smooth.

• Components generated before the customize contract existed don't expose __paramSetters, and need a manual parameter-extraction pass in the admin.

Planned: user accounts, favorites, real usage stats, CSS and HTML as third and fourth technologies, and search. The business-model sketch is freemium — the library free under MIT with a Pro tier on top — but today everything published is simply free.

Lessons

Prompts are a codebase. The generation prompts live in the repo, versioned per category and per style. When I want the next batch of buttons to feel different, I edit the buttons prompt. Art direction for a machine turns out to be a writing job.

Three models are not better than one strong one. The idea → brief → code chain looked like an assembly line and behaved like a game of telephone. A deterministic seed plus one capable code model produces more consistent components at lower cost. Save the multi-model choreography for problems that actually need it.

Measure cost per artifact from day one. Because every component logs its tokens and dollars, I know what the catalog costs and can make honest calls about volume. Retrofitting that measurement later would have been painful; adding it early was almost free.

My job is the taste gate. With SENU my role was architect and project manager — AI wrote, I judged. Didko pushes that one step further: I don't touch the code at all. The platform was built by an agent, the components are generated by a pipeline, and what's left for me is deciding what ships. Of the 191 components generated, 81 made it through. That ratio is the product. The machines make components; the library is the taste.