Same Data In, Five Different Posters Out: What the AI Poster Debate Gets Wrong About Templates

One image prompt gives you the same pastel poster every time. A template file plus JSON gives you any style you encoded, in about 50ms per render. Cosy, explained through the debate.

Same Data In, Five Different Posters Out: What the AI Poster Debate Gets Wrong About Templates

The poster everyone makes fun of now took a few years to become a template. Same layout, same pastel palette, same hand-drawn bunting, same cheerful flowy script for the headline. Different town, different bake sale, identical file. On September 19 this complaint hit the front page of Hacker News as "AI-generated posters don't have to be horrible" (1,858 points, 942 comments at the time of writing), and the comment section turned into a group diagnosis of why image generators converge on one look.

The author, John Hartnup, did something more useful than complaining. He prompted the same spring fayre poster through a dozen named styles, Bauhaus to punk fanzine, and got twelve genuinely different designs. His conclusion, near the end of the post: you don't have to accept images you cannot edit. Ask for real text and real layers instead. That sentence is the whole product brief for Cosy, so let's walk through it.

The problem is variance, not quality

Look closely at the "slop" posters and most of them are fine individually. Coherent layout, readable hierarchy, no missing fingers. The failure shows up when twenty organizers in the same county generate theirs. The model regresses to the mode. Nothing in a one-shot image prompt holds variance across runs, and nothing in a flat PNG lets you fix it afterward, because there are no objects to move. The poster is one baked layer.

Style keywords help a bit, as Hartnup showed, but they rely on the model understanding "Bauhaus" the same way you do, and they still hand you a flattened bitmap. You cannot reflow the date when the venue changes. You cannot swap the accent color when the organizer hates purple. Every regeneration is a fresh dice roll.

What a template locks in

Cosy takes the opposite position: design lives in a template file, content lives in data, and rendering is just the meeting point.

  • A template is an SVG with token placeholders plus a JSON schema that types every field: text, number, color, image, boolean.
  • Data is plain JSON with brand fields (colors, logo, background) and per-slide fields (title, date, stats).
  • Rendering is a Rust binary calling resvg. About 50ms per slide. No browser, no Chromium, no canvas service.

The consequence of that split: the design decisions happen once, in the file, and variance disappears by construction. Same data plus same template equals the same pixels, every time. The current release (v0.2.0, August 28) ships 150 templates with validated defaults, background image support with opacity control, a brand footer toggle, and a CLI with machine-friendly flags (--stdin, --json). The repo is public on GitHub under BSL-1.1.

Because the schema validates input before rendering, the system also refuses poster-shaped nonsense. Text longer than the slot fails validation with a message, not a clipped render. Field types are checked. In our own runs this caught overflow that a generative model would have happily baked into pixels.

Is 50ms real?

The README claims ~50ms per slide, which sounded like benchmark theater until we used it for our own pipeline. Cosy has been rendering our internal marketing visuals for weeks, and this post's thumbnail route (background image, overlay, text, pills) runs in tens of milliseconds per iteration on a plain CPU box. When a render costs less than a file save, iteration stops being a chore. You tune the copy, re-render, look, adjust. The loop is human-speed again.

We will publish standalone benchmark numbers separately, with the benchmark runner included, rather than asking you to trust a round number here.

Where this fits in the workflow Cosy targets

The article's final move, generating editable HTML or layered files instead of a raw image, is the right instinct. Cosy is that same instinct turned into infrastructure:

  1. A designer encodes the brand once: fonts, accent colors, margins, dark and light variants.
  2. Anyone (or any script, or any agent) fills JSON and gets consistent output. The CLI flags and the HTTP API exist so a cron job can produce the weekly social cards unattended.
  3. Regeneration is deterministic, so last-minute copy changes do not reopen design decisions.

Event flyers are one template family among 148. The same mechanism covers OG images, stat cards, changelog graphics, and code snippet cards.

Try it your own way

Cosy is public at github.com/codecoradev/cosy, and an HTTP API mode for unattended self-hosting. Pull the repo, run cosy templates, and pick a fight with a template. The fastest way to judge the approach is to break something on purpose: rename a field in the JSON, feed it a number where a color belongs, and watch the validator catch it before the renderer does.

Posters became a punchline because one-shot generation threw away structure. Keep the structure in a file, hand it data, and the same tooling that made the meme boring again costs about 50ms per slide.