I needed a logo and did what everyone does now: opened an image generator. It was genuinely useful for exactly one thing — exploration. It found the composition (a terminal prompt next to a checkmark) faster than I would have sketching. And then it hit its ceiling: spacing it could not control, strokes that went muddy where they overlapped, colors that were almost-but-not my brand palette, and no way to say "same thing, 8 percent more air between the glyphs."
Then the obvious thing occurred to us: a logo made of text and geometry is not an image. It is code. So my agent wrote it as code — fifteen lines of SVG, with my exact brand hex values, on a 128-unit grid.
Everything about iteration changed. "More spacing between the elements" became a coordinate edit. "The cursor should be an underline, not a block" — one rect. "Swap the order: terminal glyph first, then the check" — two paths traded places. "Try corner radius 26, then 14, then 4, then 0" — a sed one-liner producing four files I could stare at side by side. Each iteration took seconds, and every variant stayed in git with a name.
The subtlest discovery: at some point every radius variant looked identical to me, and I blamed "the font" — though an SVG mark has no font. I was half right. The stroke voice — line caps, joins, weight — IS the font of a geometric mark. Round caps make everything soft and friendly no matter how sharp the tile is; square caps with miter joins turn the same paths into drafting-table engineering. We rendered four stroke voices of the same mark, and they differed more than all the radius variants combined. If your mark feels samey across iterations, you are probably iterating the wrong property.
The judging setup mattered as much as the writing: the agent rendered a preview page through headless Chrome with the mark at 512, 64, 32 and 16 pixels, in a circular avatar crop, and on a dark background — the squint test as a repeatable artifact instead of a vibe. We even sent the concept to a second AI for a brand-fit review; it caught a real risk (too close to generic terminal logos) and suggested the fix that became our best candidate.
The division of labor I will keep: generators for exploring what a mark could be, and for texture. Code for anything geometric or typographic — where what you need is not more pixels but a clear technical idea, expressed from one programmer to another. My agent happens to be the other programmer.
Reproduce this
Prerequisites: an agent that can write files and run shell commands; your brand colors as hex; Chrome (headless) or any SVG renderer.
Your agent will need from you: a one-sentence description of the mark, the hex palette, and your patience for three or four rounds of "a bit more spacing."
Steps: describe the mark in words and let the agent write a minimal SVG on a fixed grid (viewBox 128 is comfortable); have it build one HTML preview page showing the mark at 512/64/32/16 px, in a circle crop, and on dark background; render it with headless Chrome and look; iterate one property per round — spacing, element order, corner radius, and above all the stroke voice (caps: round vs square, joins: round vs miter, weight) which acts as the mark's typeface — keeping each variant as its own file in git; when two candidates compete, put them on the same page and squint at the 32 px row.
Verify: the mark reads at 32 px; the SVG contains your exact brand hex values; a colleague can tell what it depicts without being told; and changing any single visual property is a one-line diff.