The tool that makes more tools
On building generators instead of results
August 23, 2025
generative-art
software
philosophy
The thing I’m building with GrasShopper is a system that writes buyer’s guides, for products I’ll never look at and for people whose needs I didn’t think of. I don’t write a single guide myself.
That’s a different kind of work than making one good thing. At some point you stop adjusting an individual result and start adjusting the process that produces results. A programmer writes a generator, a musician designs a set of rules, a teacher changes an exercise so that students can discover things the teacher never specified.
This is older than today’s AI. Philip Galanter’s 2003 paper What is Generative Art? describes practices where the artist sets up a system that works with some autonomy and contributes to the result, and his definition isn’t limited to computers.
Richard Sutton goes a step further in The Bitter Lesson. Looking back at the history of AI, he contrasts approaches where researchers built in their own knowledge of a domain with methods that get better through more search and learning, and he ends up arguing for building things that can discover. For creative tools I take it as a challenge: can a generator find something its designer didn’t already know? (That’s my reading. Sutton writes about AI research, he doesn’t say anything about making art.)
What changes for me is how to judge the work. One good chair is one achievement. A method that helps many people make good chairs is another, and it can fail even when the demo chair is beautiful, because it only works with one expensive material or produces chairs nobody can repair. It’s the same with GrasShopper. The sneaker search I described in the post tells you what’s possible when things go well. The average guide and the bad one say much more about what the system really gives people.
So these are the questions I’d ask about any generator, including mine: - How much meaningful variation does it allow? - What can its users understand and change? - What happens when its creator stops maintaining it?
The second one is tricky. Most users don’t want to study the machinery, and forcing them would turn the tool into an entrance exam. But a tool can be simple on the surface and still leave a way in through documentation, settings you can inspect, work you can export and parts you can replace. Somebody starts with assistance and over time learns to redirect the process. That’s the kind of automation I like the most.
There’s a responsibility part too. Whoever builds a widely used default has made a choice with consequences, even if they never intended any specific output.
When I look at a generative system, I look past the gallery of its best results. I want to know what people can change in it, and whether they can one day surprise the person who built it.