Procedural Graphics for Websites: Generate the Decorations Instead of Drawing Them

I was watching YouTube one evening, not looking for anything in particular, when a video from a design agency showed up in my feed, about a tool they had built. I opened it out of curiosity, which is usually how the things that end up changing my work begin.

For a few weeks now I’ve been using it for everything visual: the covers of this blog, the patterns on client sites. And it made me rethink a couple of ideas I had about software in general, not just about graphics.

The tool you build in an afternoon

The video was from Pixel Point, a design agency, and it presented Toolcraft: a starter kit for building small creative applications with an AI agent.

The idea is simple. Asking a model to “make me a tool that generates this effect” almost always gives you a toy that breaks the moment you touch a slider. Not because the model can’t write the effect, but because a creative app is mostly everything around it: how the canvas behaves, how the controls are grouped, how export works, what happens to performance when you drag a value. Toolcraft puts all of that in the box, along with instructions for the agent, ready-made controls and verification steps. You only describe the effect you want. You run npx @pixel-point/toolcraft create, open the folder with the agent, write the prompt, and a few dozen minutes later you have an application of your own.

I had already dabbled in procedural graphics years ago, out of curiosity. Seeing how short the path had become between “I’d like a tool that does X” and the tool that does X changed my mind about part of the craft.

From three attempts to three hundred

I started with my own things. I no longer draw the covers of this blog one by one: I have a generator that turns them out within the site’s visual system, and my job is to choose.

Then the real case came along, with a client.

We’re building the Donati Capsolution website from scratch, a company that makes caps and packaging components for perfumery and cosmetics. During the graphic design phase we found a pattern that told the product’s story well. Good, but only one, and no way of knowing whether it was the best possible or just the first that came along.

We built the tool. A few parameters, the ones that really mattered for that pattern, and a button to generate. We produced them by the thousands, which for a manufacturing company is also an acceptable joke, and we looked at them all together. The variant we chose wasn’t among the first three I would have drawn by hand. I wouldn’t have got there by reasoning; I got there by seeing.

This is the part that interests me most: quantity isn’t a whim, it’s a selection method. When generating the hundredth variant costs nothing, you stop defending the first one.

A program made to be reprogrammed

One thing struck me more than the patterns, though, and it concerns software itself.

Toolcraft isn’t a product in the classic sense. It has no interface to learn, no features to compare in a table. It’s an environment containing constraints, instructions and pre-assembled parts, and its stated purpose is to be reprogrammed by an agent. A metaprogram, if you like: its value isn’t in what it does, but in what it makes easy to have someone else do.

If this generalizes, the relationship between those who write software and those who use it changes. Today the user chooses among the options the product has left open. In the model I glimpse here, the user receives a coherent base and builds their own version: they don’t configure, they rewrite. And whoever makes the software stops designing features and starts designing constraints, that is, deciding what must stay true across all the custom versions that will be born.

It’s also why I don’t buy the reading that AI takes work away from designers. The tool generates three hundred variants, but someone has to be able to see the good one. Judgment remains the bottleneck, and judgment can’t be generated.

Decorative elements are no longer images

The other consequence is more down to earth, and it affects every site we build.

Until now a decorative element was an asset: someone drew it, it was exported, it ended up in a folder. From then on it was frozen. Changing the brand palette meant reopening the source file, hoping it still existed, and re-exporting twenty images.

If the decorative element comes from a generator instead, it stays parametric. It lives in the repository as code, not as a PNG. It shares the design system’s controls, so changing a color propagates it everywhere. You can produce a variant for every page without the site looking assembled from different sources, because the grammar is the same. And you can decide whether to render it at build time, if you need a lightweight image, or leave it live in the browser where that makes sense.

The cost of this approach is concentrated at the start, in building the tool. The benefit is spread across the whole life of the site, which is exactly the kind of trade I’m interested in.

Where it doesn’t work

It’s worth saying, because this method has a precise perimeter.

It works when you can judge the result by eye in two seconds. A pattern, a cover, an effect: you look and you know. It doesn’t work where correctness is invisible, where to tell whether something is right you have to think it through or check it against data. There, generating three hundred variants doesn’t help you choose; it gives you three hundred things to check.

So no, it’s not “AI builds the software for us”. It’s a band of problems, the visual and repetitive ones, that has stopped costing what it used to. And that’s enough to change how I design the graphic side of a site.

Let’s talk

If you’re thinking about a new website for your company and want to talk it over with someone, tell us about your project.