Skip to main content
AI image generation enables creating, editing, and transforming images through natural language. This chapter covers practical patterns for production image generation.

DALL-E Image Generation

Basic Image Generation

Prompt Engineering for Images

Batch Image Generation

Image Editing

Inpainting with DALL-E

AI-Powered Image Transformation

Production Patterns

Image Generation Service

Image Generation Best Practices
  • Use detailed, specific prompts for better results
  • Include style, lighting, and composition details
  • Implement content moderation for user prompts
  • Cache generated images to reduce costs
  • Use appropriate quality settings for your use case

Practice Exercise

Build an image generation platform that:
  1. Accepts natural language descriptions
  2. Enhances prompts automatically for better results
  3. Supports multiple styles and configurations
  4. Implements content moderation
  5. Provides image variations and editing
Focus on:
  • Prompt optimization for quality
  • Cost management through caching
  • Content safety filtering
  • User experience with progress feedback

Interview Deep-Dive

Strong Answer:
  • The API call itself is the easy part. The production concerns I would address fall into five categories: content safety, cost management, latency handling, storage, and user experience.
  • Content safety is the highest priority for consumer-facing products. I would implement a two-layer moderation system. First, a pre-generation filter that checks the user’s prompt against OpenAI’s moderation API and a custom blocklist before the image generation call even fires. Second, a post-generation filter that runs the generated image through a vision model or image classification model to detect content that slipped through the text filter. DALL-E has its own content policy, but I would not rely solely on the provider’s safety layer because false negatives happen. At one company a user’s prompt about “shooting stars” generated an image flagged by their community guidelines — the text filter missed it because the prompt was innocuous, but the model interpreted it ambiguously.
  • Cost management means implementing caching for identical or near-identical prompts (hash the prompt plus generation parameters as a cache key), setting per-user generation quotas (free tier gets 10 images per day, paid gets 100), and choosing quality settings based on the use case (standard quality for previews, HD quality only when the user explicitly requests it). DALL-E 3 HD costs roughly 0.08perimageversus0.08 per image versus 0.04 for standard — at scale that doubles your spend.
  • Latency is 10-30 seconds per image. I would never make the user wait synchronously. The pattern is: accept the request, return a job ID immediately, process in a background worker, notify the user via WebSocket or push notification when the image is ready. Show a skeleton or placeholder in the UI immediately.
  • Storage means I would never serve images from OpenAI’s temporary URLs (they expire after an hour). I download the image to S3, generate a CDN-fronted permanent URL, and serve that. I also store the generation metadata (prompt, settings, user, timestamp) for analytics and content moderation audit trails.
Red Flags: Candidate only discusses the API call without mentioning safety, cost, or UX concerns. Another red flag is relying on temporary OpenAI URLs for production serving.Follow-up: How would you implement caching for image generation specifically, given that the same prompt can intentionally produce different images?Image generation caching is trickier than LLM text caching because users often want variety. My approach is context-dependent. For product use cases like generating thumbnail variants for A/B testing, I cache aggressively: same prompt plus same seed produces the same image, so I use the prompt hash plus seed as the cache key. For consumer creative tools where variety is the point, I do not cache individual results but instead implement a “similar prompt” detector. If a user submits a prompt that is semantically identical to one they submitted in the last hour (embedding similarity above 0.98), I show them their previous results and ask “Want to generate a new variation or use one of these?” This saves 30-40% of redundant generations from users who rephrase slightly because they did not like the first result. The cache eviction strategy is LRU with a 24-hour TTL and a storage cap per user.
Strong Answer:
  • DALL-E 3 takes your submitted prompt and rewrites it into a more detailed version using an internal LLM before the diffusion model generates the image. The revised prompt is returned in the API response under response.data[0].revised_prompt. This is great for casual users because it enhances vague prompts, but it is a significant problem for applications that need precise control.
  • The issue is that your prompt engineering work gets partially overridden. If I carefully craft a prompt specifying “no text in the image, minimalist style, only blue and white colors,” the rewrite might add details that conflict with my constraints. I have seen the rewriter add elements like “with elegant serif typography” to prompts that explicitly said no text.
  • The workaround strategies depend on the use case. For maximum control, I use DALL-E 2 for editing and inpainting tasks since it uses your exact prompt without rewriting. For DALL-E 3 generation, I make my constraints extremely explicit and redundant in the prompt: instead of “no text,” I write “absolutely no text, no letters, no words, no typography, no writing of any kind anywhere in the image.” Redundancy helps because the rewriter is less likely to override a constraint that appears multiple times.
  • I also log both the submitted prompt and the revised prompt for every generation. This is essential for debugging: when a user reports “the image does not match what I asked for,” I can compare the two prompts and identify where the rewrite diverged from the user’s intent. This logging also feeds back into prompt engineering — I analyze which types of instructions survive the rewrite intact and optimize my prompt templates accordingly.
Red Flags: Candidate does not know about prompt rewriting in DALL-E 3, cannot explain the difference between DALL-E 2 and DALL-E 3 capabilities, or suggests the model always generates exactly what you prompt.Follow-up: How would you build a style-consistent image generation system where every image needs to match a specific brand aesthetic?Style consistency across multiple generations is one of the hardest problems with current image generation models because there is no native “style reference” input. My approach uses a multi-part prompt template with three sections: a frozen style preamble that describes the brand aesthetic in exhaustive detail (color palette with hex codes, art style, lighting characteristics, composition rules, specific things to avoid), a variable subject section for what changes per image, and a frozen style suffix that reinforces the key constraints. I test this template against 50+ diverse subjects and manually review for style drift. The subjects that produce off-brand results get their prompts refined with additional constraints. I also maintain a visual QA step: after generation, I pass the image and the brand guidelines to GPT-4o Vision and ask it to rate style compliance on specific dimensions (color accuracy, composition, mood). Images below a threshold get regenerated with a modified prompt. This automated QA catches about 80% of off-brand images before a human ever sees them.
Strong Answer:
  • At 0.040.04-0.08 per image, $15,000 per month means roughly 200K-375K images generated monthly. I would attack this on four fronts: eliminate waste, optimize settings, add caching, and shift volume.
  • Eliminate waste first. I would audit the generation logs for patterns: how many images are generated but never viewed (abort before load), how many users generate 10+ variants of the same concept (prompt iteration pattern), and how many are automated/bot traffic hitting the API. At one company, 20% of our image generation spend was from a single user running an automated script. Rate limiting and abuse detection alone cut waste by 15%.
  • Optimize settings: switch from HD quality (0.08)tostandardquality(0.08) to standard quality (0.04) for thumbnails, previews, and first-draft generations. Only use HD when the user explicitly requests the final high-res version. This alone can cut costs by 30-40% if most generations are exploration phase. Also, use 1024x1024 as default instead of the larger sizes unless the layout requires landscape or portrait.
  • Caching: implement the semantic caching strategy I described earlier. For applications where the same types of images are requested repeatedly (product category headers, blog illustrations for common topics), pre-generate a library of images and serve from cache. Even a 20% cache hit rate saves $3,000 per month at this scale.
  • Shift volume: for lower-quality-acceptable use cases (placeholder images, draft mockups, internal tooling), consider Stable Diffusion running on your own infrastructure or a cheaper provider. Self-hosted SDXL on a single A10 GPU costs about 1.50/hourandcangenerateroughly2000imagesperhourat1.50/hour and can generate roughly 2000 images per hour at 0.00075 per image — 50x cheaper than DALL-E 3. The quality gap is real but acceptable for many internal use cases.
  • Combined, these four strategies realistically hit the 60% cost reduction target: 15% from waste elimination, 20% from settings optimization, 10% from caching, and 15% from volume shifting to cheaper alternatives.
Red Flags: Candidate only suggests “use a cheaper model” without analyzing the actual cost drivers, does not mention caching, or proposes degrading quality uniformly instead of tiering quality by use case.Follow-up: How do you measure “user experience did not degrade” when you switch from HD to standard quality?I would run this as a controlled A/B test on the user cohort that generates the most images. The primary metric is generation-to-download rate: what percentage of generated images do users actually save or use. If standard quality images have the same download rate as HD, users cannot tell the difference or do not care. Secondary metrics are user satisfaction scores (if we survey) and support tickets mentioning image quality. I would also track re-generation rate: if users generate the same prompt more times with standard quality than they did with HD, it suggests they are unsatisfied with results and retrying. The test needs at least two weeks and a few thousand generations per variant to reach significance. The key nuance is segmenting by use case — professional designers will notice the quality drop immediately, while casual users generating social media content might not care at all. I would keep HD as default for pro-tier users and switch to standard only for free-tier users.