From prompt craft to prompt systems

The constraint

Off-the-shelf generative tools were not an option for us. The only models we were cleared to use ran through our own cloud provider, which meant that for a while the answer to "can we generate this" was just no, no matter how useful it would have been.

So the first thing I built was a way to generate inside that boundary. An internal platform on AWS, starting with Amazon Nova Canvas, and later with Flux models added through the API once they were available to us. That part is closer to infrastructure than to design, but it is the reason everything after it exists.

The problem that came next

Once people could actually generate, a different problem showed up. Generating images with AI looks easy at first. Write a prompt, get a result. But when a team uses it every day, the cracks show fast. Everyone describes things differently, emphasizes different details, interprets the visual goal in their own way. You end up with inconsistent outputs, slower iterations, and too much depending on the one or two people who know how to prompt well.

That last part is the real cost. A production pipeline where quality depends on who happened to write the prompt is not a pipeline, it is a bottleneck with extra steps.

The first instinct

Teach everyone prompting. Sounds reasonable, but it doesn't really scale. Prompting isn't just writing instructions. It involves visual judgment, understanding how a specific model behaves, style control, structure, and a lot of knowledge that's hard to transfer. If every output depends on how well each person writes, the system stays fragile.

What I built instead

Instead of expecting every user to become good at prompting, I built a prompt template system. You pick a visual template (pinhole photograph, flat illustration, editorial image, historical engraving) and give it a few keywords. The system does the rest.

Each template carries two different kinds of knowledge. One is the look. For a pinhole template that means infinite depth of field, a natural vignette, film grain, muted tones, the kind of soft daylight that suits it. That part is art direction, the same thing I used to write into style guides for a team of illustrators.

The other is how to talk to the model. That a good prompt reads like a caption and not like an order. That it should stay short. That describing the scene works better than instructing it. Most people using the platform have neither kind of knowledge, and they don't need to. The template has both.

Writing a template is the design work. Deciding that a pinhole image should have a single subject, natural light and an uncluttered background is a direction call, and it is the same call I would make briefing an illustrator. It just gets written down for a different reader.

How it works

The user picks a template and types a few keywords. Those two things go to a language model, which writes the actual prompt. The system parses what comes back and shows it, and from there the image can be generated directly or the prompt can be edited first.

The middle step is the whole design. The system is not dropping variables into a text block. It asks a model that is good at writing to do the writing, following instructions from someone who knows what the image should look like.

Leaving the prompt visible and editable was deliberate. A system that hides the prompt turns the person using it into a passenger. This one hands them a good first draft and then gets out of the way.

What comes out

Two templates, four images each. Within a group the subjects have nothing in common and the images still look like one set. Across groups it is the same system holding a completely different visual language.

Paper collage

Pinhole photograph

What it costs

The approach has a limit worth naming. Templates are opinionated on purpose, and that works as long as what you need falls inside one of them. For an image that doesn't match any template, the system isn't much help and you are back to writing the prompt yourself.

Adding a template is not hard, but it is work, and it needs someone with the visual judgment to decide what that template should enforce. The bottleneck moved from prompting to authoring templates. That is a much better place for it to be, but it did not disappear.

What happened after

The constraint that made this necessary is gone. Generating an image is easy anywhere now. Nobody has to use what I built.

They still do. The platform has been running for two and a half years and several projects depend on it, not because it is the only option but because typing two keywords is still faster than writing a prompt, and because a project made with templates comes out looking like one project instead of forty images made by different people.

That is the part I would point at. Plenty of internal tools get used because there is nothing else. This one kept its users after the alternatives showed up.

It is also the same job I was doing ten years earlier. Back then I wrote style guides so a group of illustrators could draw in one visual language. The technology changed. The problem did not.