DEV Community: Marcus huang

Treating image prompts like config: a structured brief workflow for Seedream 5.5

Marcus huang — Mon, 26 Oct 2026 00:18:38 +0000

Disclosure: I'm the owner of seedream55ai.com, an independent web workspace for the Seedream 5.5 image model. It is a third-party tool and is not affiliated with ByteDance or any model provider.

Most bad AI images I see come from one-line prompts that mix subject, style and layout in a single run-on sentence. When something comes out wrong, you have no idea which part to change. The fix that worked for me is boring and very developer-friendly: treat the prompt like a config file.

1. Split the brief into fields

Before writing any prose, I fill in a small object:

{
  "subject": "matte white ceramic coffee mug, no logo",
  "setting": "light oak table, soft morning window light from the left",
  "camera": "45-degree angle, 50mm look, shallow depth of field",
  "style": "clean e-commerce product photo",
  "text": null,
  "aspect_ratio": "1:1",
  "avoid": ["extra handles", "warped rim", "busy background"]
}

Each field answers one question. If the light is wrong, you edit setting. If the mug looks warped, you add to avoid or tighten subject. Changes become diffs instead of rewrites.

2. Render the object into a prompt

A tiny function turns the object into the sentence the model actually receives:

function renderPrompt(b) {
  const parts = [
    `${b.style} of ${b.subject}`,
    `on ${b.setting}`,
    b.camera,
    b.text ? `with the exact text "${b.text}"` : null,
    b.avoid?.length ? `avoid: ${b.avoid.join(", ")}` : null,
  ];
  return parts.filter(Boolean).join(". ") + ".";
}

Keep the rendered prompt in version control next to the brief. When a result is good, you can reproduce it later; when it is bad, git diff tells you exactly what changed.

3. Change one field per iteration

This is the same discipline as debugging: one variable at a time. My loop is:

Generate 2 to 4 variations from the same brief.
Pick the closest one and write down what is wrong in one line.
Map that line to a single field and edit only that field.

Three or four iterations usually get a usable product shot. Changing everything at once usually gets you a different, equally wrong image.

4. Text in images needs its own field

Posters and labels fail most often on typography. Put the literal string in a dedicated text field, quote it exactly in the rendered prompt, keep it short, and say where it goes ("centered headline at the top"). For bilingual posters, give the English and Chinese strings separately rather than asking the model to translate.

5. Use reference images for edits, not longer prompts

When you already have a photo and only want to change the background or lighting, an image-to-image edit with the original as a reference beats describing the product in more and more words. The brief then only describes the change: "replace background with a plain warm grey studio sweep, keep the product unchanged".

Where I run this

I built Seedream55ai partly to make this loop less painful: text-to-image and reference edits in one place, aspect ratios like 1:1, 16:9 and 9:16, up to four outputs per request, and a credit quote shown before each generation. It is credit-based (packs from $2.99, plans from $7.99/month), so it is not a free unlimited service. The brief-as-config approach above works with any image model though, so steal the template either way.

Generating Hero Images, Icons and OG Cards for a Side Project with Nano Banana 2.1

Marcus huang — Sat, 24 Oct 2026 01:21:39 +0000

Every side project hits the same wall right before launch: the code works, but the landing page has no images. Here is the workflow I use to generate a consistent asset set with nanobanana21pro.com, an independent third-party web app built on Google's Nano Banana image models.

Disclosure: nanobanana21pro.com is not a Google product and not Google AI Studio. It is a separate service, not affiliated with or endorsed by Google. Writing prompts is free; generating images uses credits.

1. Write an asset spec before any prompt

Treat images like any other dependency. I keep a small spec file in the repo:

brand:
  palette: ["#0F172A", "#38BDF8", "#F8FAFC"]
  style: "soft 3D clay, rounded shapes, studio lighting"
assets:
  - id: hero
    ratio: "16:9"
    size: 2K
  - id: feature-icons
    count: 3
    ratio: "1:1"
    size: 1K
  - id: og-card
    ratio: "1.91:1 (closest available)"
    size: 1K

The point is to reuse the same style string in every prompt, so the set looks like it belongs together.

2. Generate the hero first

The hero sets the visual language. Example prompt:

Soft 3D clay illustration of a small rocket made of stacked code brackets,
launching from a laptop keyboard, navy background (#0F172A),
sky blue accents (#38BDF8), studio lighting, lots of empty space on the left
for a headline. No text.

Two tips:

Ask for empty space where your headline will sit.
Say "No text" when the HTML will carry the copy.

3. Use the hero as a reference for everything else

This is where reference editing pays off. Nano Banana 2.1 accepts up to 14 reference images, so I attach the approved hero and give it a role:

Use the reference image only for style, color palette and lighting.
Create a single soft 3D clay icon of a padlock on a plain #F8FAFC background,
centered, 1:1. No text.

Repeat for each feature icon (padlock, lightning bolt, chart). Because the hero is the style reference, the icons stay on-brand.

4. OG card with real text

For social preview cards I do want text in the image, and this is an area where the 2.1 model is strong at legible lettering:

Use the reference image for style and palette.
Wide social preview card, the words SHIPKIT in bold white letters on the left,
the tagline "Deploy in one command" below it in smaller sky blue letters,
the clay rocket on the right.

Keep text short and quote it exactly. Check every letter before you ship it.

5. Budget the run

The generator shows a credit quote before you submit. On Nano Banana 2.1:

Size	Credits per image
1K	8
2K	12
4K	28

My set above (one 2K hero, three 1K icons, one 1K OG card, plus a few retries) fits in a small credit pack. One-time packs start at $2.99, and monthly plans are $18.99/mo and $44.99/mo. Batch size multiplies the cost, so explore at 1K.

Building a Weighted-Random Birth Simulator on an Open-Source Engine

Marcus huang — Fri, 23 Oct 2026 19:19:00 +0000

Disclosure: I made 1in8billion.live. It's an independent, unofficial fan-made game inspired by "1 in 8 Billion" and isn't affiliated with 1in8b.life. I built it on top of the MIT-licensed open-source born-somewhere engine, which I didn't write.

This is a write-up of the design ideas behind 1 in 8 Billion – Free Life Simulator, my browser game where you're born in a random country and live one life from birth to death. It covers the general patterns: weighted sampling, data-driven events, local saves and i18n. The code snippets are simplified illustrations of each pattern, not the production source.

1. Weighted random selection

The core mechanic is a draw over 172 countries. A uniform Math.random() pick would be wrong, because Tuvalu shouldn't come up as often as India. The game weights the draw by annual births, and the homepage shows the resulting shares: India around 17.6%, China around 6.7%, Nigeria around 5.7%, and so on.

The standard way to do this is cumulative-weight sampling:

function weightedPick(items) {
  // items: [{ id: "IN", weight: 23000000 }, ...]
  const total = items.reduce((s, i) => s + i.weight, 0);
  let r = Math.random() * total;
  for (const item of items) {
    r -= item.weight;
    if (r < 0) return item;
  }
  return items[items.length - 1];
}

For 172 entries a linear scan is plenty fast. If you were sampling millions of times, you'd precompute a prefix-sum array and binary search it, or use the alias method for O(1) draws.

I also added a population mode, which swaps birth weights for population weights. That's a nice example of keeping the sampling function generic and passing in a different weight vector.

2. Data-driven life events

Each country carries real indicators: life expectancy, infant mortality, under-5 mortality and GDP per capita (PPP). A simple way to turn these into gameplay is a yearly hazard. Each simulated year, compute a probability of death (and of other events) from the country's stats and the character's age, then roll for it. Infant and under-5 mortality cover the early years, and life expectancy calibrates the curve for the rest of the life.

Choices sit on top of this. At turning points the player picks an action, or auto mode picks one, and the result nudges stats like health, happiness, knowledge and social standing. The game shows these as 0–100 meters along with net assets in PPP dollars.

3. Batch simulation

Once a single life is a pure-ish function of (country, seed, choices), running many is easy. The game's Lab runs lives in bulk and summarizes the results. If you build something similar, keep the simulation step free of DOM access so you can move it to a Web Worker without changing it.

4. No-backend saves with localStorage

There's no signup. Progress and past lives are saved in the browser on the device, and the site tells players plainly that clearing site storage removes them and that there's no cloud sync. The usual pattern:

const KEY = "lives:v1";
const load = () => JSON.parse(localStorage.getItem(KEY) || "[]");
const save = (lives) => localStorage.setItem(KEY, JSON.stringify(lives.slice(-50)));

Version your keys, cap the history, and wrap setItem in try/catch, because storage quotas and private-browsing modes can throw.

5. i18n across six locales

The UI ships in EN, DE, ES, FR, PT-BR and ZH-CN. Some general lessons for a narrative game:

Keep event text as keyed templates with placeholders, not concatenated strings.
Use Intl.NumberFormat for currency and Intl.PluralRules for "1 year / 2 years".
CJK languages often need different line-height and truncation rules on share cards.

6. Shareable output

At the end of a life you can download a life card image, plus a generated family tree. Drawing to a <canvas> and exporting with toBlob() is the usual browser-only way to make an image like this without a server.

Takeaways

Most of the "feel" comes from two choices: weighting the draw by real births, and letting real indicators drive the yearly odds. The rest is UX: pause, two reading speeds, an auto mode, and an education mode for classrooms.

You can try what I built at 1in8billion.live. It's free to play, with an optional US$2.99 one-time Keepsake card. I'd like to hear how you'd approach the hazard model.