The Picture That Could Not Be Drawn

Two attempts at the same image came back wrong in two different ways. A nine-by-ten grid instead of ten-by-ten. Four filled tiles instead of three. A stray letter where a digit should have been. The instinct, the first time something like this happens, is to blame the renderer and ask it to try again more carefully. The actual defect was upstream of the renderer entirely — it was in the brief, and no amount of re-prompting the same structure would ever have produced a correct result, because the brief was asking for something that could not exist.

The brief

The image was for a post about email deliverability, illustrating a complaint-rate threshold: a sending provider throttles a sender once complaints cross roughly three per thousand messages. The original prompt asked for a hundred small square tiles arranged ten by ten, with exactly three of them filled in, captioned with two pieces of text sitting underneath the grid: a headline reading “0.3%” and a caption reading “Three In A Thousand.”

Three filled tiles out of a hundred is three per cent. The headline said zero point three per cent. Those are not the same number — they differ by a factor of ten — and the prompt was asking a single image to display both of them as if they agreed.

Why this fails worse than it looks

A countable grid is not a decorative choice. It is an implicit claim. Ten rows of ten columns, three tiles coloured differently from the rest — a viewer’s eye does the division without being asked to: three divided by one hundred. The image argues 3% through its own structure at the same time its caption insists 0.3%. No rendering model, however good, can produce a picture that is self-consistent when the brief that generated it is not.

This is a different failure from “the model got it wrong.” Two separate generation attempts did get something wrong — a 9×10 field, four filled tiles instead of three — but even a perfect, pixel-exact rendering of the stated brief would still have been wrong, because the brief itself asked for two incompatible facts to appear in the same frame. Fixing the renderer’s execution would have produced an accurate picture of an inaccurate instruction.

The fix that didn’t work, and why it wouldn’t have

The tempting fix is to tighten the specification: be more explicit about the count, add emphasis, repeat the instruction to double-check the numbers before finishing. None of that addresses the actual problem. You can ask a model to count more carefully and it will — the arithmetic error is not in the counting, it is in the premise. Three of a hundred will always read as three per cent to anyone who can count a grid, no matter how precisely the model executes the brief.

The actual fix: stop making the count legible

The real fix did not make the grid more accurate. It made the grid impossible to count. The specification was rewritten to call for a dense field of very many small tiles — described explicitly as needing to read as roughly a thousand rather than a hundred, packed tightly enough that a viewer cannot tally them — with the same three filled tiles now scattered through a field too large to count at a glance. Three of approximately a thousand does agree with 0.3%. The picture stopped contradicting its own caption not because the renderer got better, but because the brief stopped asking for a number the frame could visibly disprove.

The rewrite also tightened a second, related issue: a closing line of text had been drifting into a band of the canvas reserved for branding, because the brief only asked politely for space to be left at the bottom rather than stating it as a hard constraint with a stated percentage. The fix made the reserve an explicit fraction of the canvas with an instruction to shrink the artwork to fit above it, rather than allowing the artwork to push down into it.

The general lesson

When a generated output keeps coming back wrong in different ways on different attempts — not the same mistake twice, but a new mistake each time — that pattern is itself informative. A model making the same category of error against a well-specified target usually means the target is reachable and the model needs a clearer push toward it. A model making a different kind of error each time against a nominally fixed target often means the target itself cannot be hit, because it’s internally contradictory, and each attempt is failing in whatever way is easiest for that particular render rather than converging toward a correct one.

The question worth asking before re-prompting a third time is not “how do I describe this more precisely” but “is there a version of this brief that could actually be satisfied.” A field of a hundred countable tiles asked to represent 0.3% could not be. A field too dense to count, asked to represent the same thing, could be — and was, on the next attempt.

---

Ash Ganda is the founder of Ganda Tech Services. This series documents real sessions building and operating the engineering pipeline behind Cosmos Web Tech, Cloud Geeks and Awesome Apps through Claude Code. Part 7: The Fix for One Security Finding Created the Next One.