AI image prompts that actually work (and the other prompts I use daily)

I write about how I use AI in my actual engineering work fairly often on this blog, but I had never sat down and written out the actual prompts, the ones I keep coming back to instead of retyping some version of the same request every week. That felt like an obvious gap to close, so this is that document: a working library, not a list of clever one-liners. Image prompts get the most space here because they’re the category where the gap between a vague request and a structured one is the widest, but the second half covers the prompts I use for code, debugging, and writing, because none of those are really a separate skill from the image side. It’s the same underlying idea I already wrote about back in day three of the AI log: a prompt behaves like an interface with a contract, not a sentence you hope lands well. Everything below is that idea applied to a specific, reusable case instead of the general one.

One thing worth saying up front so it doesn’t read as a contradiction later: the cover images on this blog, including this post’s, are not AI-generated. They’re hand-drawn SVGs built from one template so every post’s cover reads as the same visual system, converted to PNG at the end. I like AI image generation for a lot of things, but “this site’s brand consistency” isn’t one of them, and I’ll get to why later in this post. Everything else here, client mockups, icons, slide backgrounds, illustrations for things that aren’t this blog, is fair game, and that’s what the prompt templates below are actually for.

Why a one-line image prompt produces a mediocre result

Type “a coffee shop” into an image model and you’ll get a coffee shop. It’ll be lit like every other AI-generated coffee shop, framed the same generic three-quarter angle, with the same warm-but-nothing wood tones, because “a coffee shop” without any other constraint collapses to whatever is statistically the most average coffee shop image in the model’s training distribution. That’s not the model failing. That’s the model doing exactly what an underspecified request should produce: the mean of the category, not anything specific.

The fix isn’t a magic phrase. It’s the same fix as under-specifying an API call: you didn’t leave anything out that the model was supposed to intuit, you left out information that has to come from somewhere, and if you don’t provide it, the model fills the gap with a default. A useful image prompt supplies the specifics a photographer, illustrator, or art director would normally bring to the job themselves: what’s actually in the frame, what medium it’s rendered in, how it’s lit, how it’s composed, what mood it’s going for, and what to leave out.

The anatomy of a prompt that actually works

Every image prompt I write now follows roughly the same skeleton, in roughly this order, because order matters slightly (earlier terms tend to get weighted a bit more heavily by most models):

[Subject and action], [style or medium], [composition/framing],
[lighting], [color palette or mood], [quality/technical modifiers]
--ar [aspect ratio] --no [things to exclude]

Broken into what each piece is actually doing:

• Subject and action — not just a noun, a scene. “A software engineer debugging code” is weaker than “a software engineer leaning toward a monitor, one hand on the keyboard, mid-typo-fix, focused expression.” The second version gives the model an actual pose and moment instead of a category.
• Style or medium — photograph, 3D render, flat vector illustration, watercolor, isometric line art, screen print, whatever matches the actual use case. This single term does more work than almost anything else in the prompt, because it collapses the model’s output space from “any visual representation” down to one rendering approach immediately.
• Composition and framing — close-up, wide shot, overhead flat lay, rule-of-thirds, centered subject with negative space on the left. This matters most when the image needs to hold text later (a slide background, a card layout), because a busy center-framed composition leaves nowhere to put a headline.
• Lighting — soft natural window light, golden hour, hard studio strobe, moody low-key, flat even lighting for product shots. Lighting alone changes the emotional register of an otherwise identical scene more than almost any other single word.
• Color palette or mood — muted earth tones, high-contrast primary colors, monochrome with one accent color, warm and inviting, cold and clinical. Naming an actual palette (three or four colors) works better than an adjective like “professional,” which means nothing concrete to the model.
• Quality and technical modifiers — sharp focus, shallow depth of field, 4k, shot on a specific lens type if it’s photorealistic, clean vector lines with no gradients if it’s flat illustration. These push the output toward “finished asset” instead of “rough sketch.”
• Aspect ratio — decide this before generating, not after. A square icon and a widescreen slide background are different compositions from the first pixel, not a crop applied afterward.
• Negative prompt — what to actively exclude: text, watermarks, extra limbs, busy backgrounds, a specific style you keep getting by accident. Not every tool supports an explicit negative prompt field, but the instruction works even folded into the main prompt as “no [x].”

Prompt templates I actually reuse

These are the shapes I copy and adapt most often, one per use case, each with a filled-in example.

Product or mockup shot, for a client pitch

Useful for the kind of proposal work I do through the freelance side of what I offer: a plausible-looking product shot before any real design work exists yet.

A minimalist smartphone mockup displaying a clean dashboard UI, photographed
at a slight three-quarter angle on a plain light gray background, soft studio
lighting with a subtle shadow beneath the device, shallow depth of field,
professional product photography, muted blue and white color palette
--ar 4:5 --no text, clutter, reflections

Isometric icon or app icon

A single isometric icon of a cloud server rack, flat vector illustration
style, clean geometric shapes, no gradients, three-color palette of teal,
navy, and white, centered composition with even padding, crisp vector lines
--ar 1:1 --no shadows, text, background elements

Presentation or slide background

The composition note matters most here: leave the frame empty where the words are going to sit.

An abstract wide banner of soft flowing geometric shapes, minimal and modern,
gradient from deep teal to soft cream, plenty of negative space on the left
two-thirds of the frame, subtle texture, calm and professional mood
--ar 16:9 --no text, faces, busy detail

Character or avatar portrait

A friendly cartoon avatar of a person with short curly hair, flat vector
illustration style, simple facial features, warm skin tone, solid color
background in soft coral, centered head-and-shoulders framing, clean bold
outlines, no gradients
--ar 1:1 --no realistic detail, text, extra objects

Concept art or mood board for a pitch deck

A moody concept illustration of a small home office at dusk, warm desk lamp
lighting against a cool blue window light, digital painting style, muted
autumn color palette, cozy and focused atmosphere, wide establishing shot
--ar 16:9 --no people, text, logos

Simple flat illustration for a web page

A flat vector illustration of two people collaborating over a laptop, simple
geometric shapes, limited three-color palette of sage green, cream, and
charcoal, generous white space around the subject, friendly and approachable
style, no outlines on shadows
--ar 3:2 --no realistic rendering, gradients, text

Iterating instead of expecting a single perfect result

None of the templates above are meant to be one-shot. The actual workflow is generate, look at what came back, and adjust one variable at a time, the same debugging instinct as changing one thing in a failing test instead of rewriting the whole function. If the composition is right but the lighting is wrong, change only the lighting phrase and keep everything else fixed, so the next result is a controlled comparison instead of a completely different roll.

Different tools expose this differently, and it’s worth knowing which lever you’re actually pulling. Midjourney takes explicit trailing parameters (--ar for aspect ratio, --style raw to reduce its default stylization, --seed to keep re-rolling variations of the same underlying image instead of a totally new one). A conversational image tool like GPT’s image generation or Gemini’s image models works more like a design review: you describe the change in plain language against the last result (“keep the composition, make the lighting warmer”) instead of restating the whole prompt from scratch. Stable Diffusion setups usually expose an explicit negative prompt field and per-term weighting (bracketing a term to push it harder or softer), which is the most literal version of the same idea every other tool does implicitly. None of these are better or worse in the abstract, they’re different control surfaces over the same underlying skeleton from the section above.

The mistakes that quietly wreck an otherwise good prompt

A few things I’ve gotten burned by enough times that they’re worth naming directly:

• Stacking contradictory styles. “Photorealistic flat vector illustration” is not a style, it’s two styles fighting for the same output, and the model will blend them into something that looks like neither. Pick one rendering approach and describe it consistently.
• Deciding aspect ratio after generating. A cropped square doesn’t become a good square, it becomes a cropped rectangle. Decide the final placement (hero banner, icon, social card) before writing the prompt, not after.
• Expecting exact text to render correctly. Image models are still unreliable at rendering legible, correctly spelled text inside an image. If a design needs a real headline, generate the background art without any text in the prompt at all, and add the actual text afterward in a design tool. Fighting the model to spell a word right is a wasted iteration every time.
• Overloading the subject count. “A group of five people in a meeting” reliably produces the wrong number of people, extra limbs, or duplicated faces, because counting and consistent anatomy across multiple figures is one of the harder things for these models to get right. One or two clear subjects renders far more reliably than a crowd.
• Describing a feeling instead of a visual. “Make it look premium” or “make it pop” aren’t visual instructions, they’re the kind of note a client gives a designer that a designer then has to translate into an actual decision. Do that translation yourself in the prompt: premium usually means restrained color palette, generous negative space, and soft, even lighting, not more detail crammed into the frame.

Beyond images: the prompts in the same file

I keep all of this, image templates included, in one plain text file I actually reuse, the same instinct as a personal snippets library for code instead of retyping a boilerplate block from memory every time. The image prompts get the most attention in this post, but most of what’s in that file isn’t images at all.

Code review, scoped to one concern at a time

Review this diff for [correctness / security / performance] only. Do not
comment on style or naming unless it actively causes a bug. For each issue
found, give the file and line, the concrete failure scenario (specific input
or state that triggers it), and the smallest fix. If nothing in this
category is wrong, say so plainly instead of inventing a minor nit to fill
space.

Scoping the review to one concern is the part that actually changes the output quality. An unscoped “review this” prompt produces a grab-bag of style opinions mixed in with the one real bug, and the real bug is easy to miss in the noise.

Explaining an error without a rewrite offered up front

Explain what this error message means and why it's happening given the code
above. Do not suggest a fix yet, just explain the mechanism causing it. Wait
for me to confirm the diagnosis before proposing a change.

This one is less about the AI and more about my own habit of accepting the first fix offered before I’ve actually understood the failure. Separating diagnosis from fix forces both of us to slow down at the step that actually matters.

Generating test cases from a function’s actual behavior, not its name

Given this function, list the input cases that would actually exercise
different code paths: the happy path, each boundary condition, and each
error path. For each case, state the input and the expected output or
error, not just a description of what the test checks.

Tightening a draft without changing the point being made

Tighten this paragraph. Cut filler words and redundant phrases, keep every
concrete claim and example, and do not add new points or soften any claim
into a hedge. If a sentence isn't doing real work, cut it instead of
rephrasing it.

A commit message from a diff, not a guess at intent

Write a commit message for this diff. Describe what changed and, in one
line, why, based only on what's visible in the diff and the message I give
you about intent. Do not invent a reason that isn't supported by either.

A meta description that actually reflects the content

Useful for exactly the kind of SEO meta descriptions every page on a site like this one needs:

Write a one-sentence meta description for this piece of content, under 160
characters, that describes the specific angle or conclusion, not a generic
summary of the topic. No marketing language, no superlatives, plain
description of what's actually inside.

Building a library instead of retyping the request

None of these templates are precious. I edit them every time one produces a result I don’t like, the same way I’d edit a code snippet that turned out to be missing an edge case. The actual value isn’t in any single prompt being clever, it’s in not having to reconstruct the same structure from memory every time, and in having a record of which phrasing already produced a good result for a given kind of ask. Treat a prompt like a small piece of reusable code: version it, keep the ones that work, and throw out the ones that don’t survive contact with a second use case.

If the part you actually want is the why behind all of this, how a model turns any of these prompts into an image or a piece of text in the first place, that’s what the AI log series is for. This post is the practical half. That one is the mechanical half underneath it.