3 Hours to Create 79 Assets. Go.

By the time I sat down to generate visual assets for 20 articles, I'd already spent weeks in content review, fact-checking, and building out the editorial agent pipeline. I didn't realize it at the time, but that earlier work was the real preparation for this session.

The lower dB had about 20 published articles with no supplemental visuals. For a reader-facing health content site, that's a problem. Visuals aren't decoration. They help readers understand the most complex and most important points in an article. They break up long-form content, reinforce important points, and increase comprehension. For health content in particular, the stakes are higher. A well-placed diagram can be the difference between a reader understanding how their medication works and bouncing to a simpler but less accurate source.

I needed 2-5 assets per article, which meant potentially 100 images. I couldn't do this one at a time in Canva. I needed a system.

Flowchart of the 79-asset generation workflow, from content audit through constraint-setting, first-article iteration, scaled generation, and final review

The prep work that made the session possible

Before touching any image tool, I did a full content audit of every article on the site. Not "which articles need pictures" but "what are the hardest concepts in each article, and where would a visual actually help a reader understand them?"

For each article, I wrote specific asset recommendations. Not "add an image here" but "a mechanism pathway diagram showing how GLP-1s work from injection to effect" or "a two-column panel showing what evidence is settled vs. what's extrapolated from general research." Each recommendation included the type of visual, what it should contain, and which section of the article it would anchor to.

This audit was informed by all the time I'd already spent inside the editorial pipeline - reviewing content, fact-checking claims, iterating on enrichment flows. I already had a strong sense of what each article's key ideas were, where readers might get lost, and where the density of information was highest. That wasn't extra prep. It was a byproduct of the earlier work.

I also set constraints before generating anything:

Two permitted visual styles. Excalidraw sketchy style (black ink, white background, slight line wobble) for technical diagrams, flowcharts, and comparison tables. Woodcut/letterpress style (bold black ink on warm cream parchment) for reference cards, checklists, and anatomical illustrations.
A programmatic chart path for anything data-driven - clinical trial results, cost breakdowns, dose timelines, symptom matrices.
Editorial guidelines: use reputable sources only, avoid "red flag/green flag" framing, maintain the same clinical objectivity as the articles themselves.

Start with one, iterate, then scale

I chose Manus for the generation session because of its strength with structured content assets. But I didn't start with all 20 articles. I started with one.

The first batch came back close but not right. The legend on a clinical trial bar chart overlapped with the section label. I asked for it moved below the chart and changed from stacked to side-by-side to make better use of the space. A reference card checklist was generated at 16:9 aspect ratio, which made the text too small to read. It needed 4:3. One of the woodcut reference cards included a hand holding the card in a 3D perspective. That wasn't the style.

Woodcut-style reference card listing the iteration rules locked in during the first article: legends below charts, 4:3 aspect ratio for reference cards, no 3D perspective, no generic labels, timeline format rules, and no side arrows on pyramid diagrams

Each round of feedback became a reusable rule. By the end of the first article, I had documented iteration rules that applied to every future asset:

Legends always go below the chart, horizontal, outside the plot area.
Reference cards use 4:3 aspect ratio, not 16:9.
No hands holding cards, no 3D perspective on flat reference cards.
No generic labels like "Event 1" or "Position 1." Every node uses its actual content.
Timeline nodes use "[Year]: [Event Name]" format directly. No positional descriptors.
Never add directional arrows along the sides of a pyramid diagram. The shape communicates the hierarchy on its own.

Once those rules were locked in, scaling to the remaining articles was fast. The agent needed almost no steering because the constraints were already defined.

Scripts, not just an LLM

Here's the detail that surprises people: most of the data-driven visuals on the site were generated by Python scripts, not by an image model. Clinical trial bar charts, half-life comparisons, cost waterfalls, dose schedule timelines, symptom severity matrices - all generated programmatically with Matplotlib.

The scripts use a standardized boilerplate with the lower dB's brand colors, monospace typography, consistent spine and grid styles, legend placement rules, and footnote formatting all baked in. Every chart that comes out of that boilerplate looks like it belongs on the same site.

That's why those charts are consistent across 20 articles. An image model generating each one independently would have produced 20 slightly different visual styles, even with the same prompt. The LLM's role here was writing the scripts, not drawing the charts. That distinction matters for output quality.

Two-column comparison showing LLM image generation versus programmatic Matplotlib charts, with the LLM writing scripts rather than drawing the data-driven visuals

The output

A few hours, 79 reviewed and approved visual assets across the full article library. The asset types ranged widely - mechanism pathway diagrams, comparison tables, flowcharts, decision trees, regulatory timelines, evidence panels, exercise priority pyramids, anatomical illustrations, reference card checklists, and every variety of data chart. Each asset was assigned a layout for placement in its article; either full-width to break the text flow, or inset to float alongside the text with wrapping, depending on whether the visual stands alone or supports the surrounding paragraph.

Every asset has a visual-asset-requirements.md documenting the original requirement, the generation method, and any editorial decisions made during review. That documentation isn't overhead. It's what makes the next round of assets faster.

Systematizing it

Timeline of the Manus session showing how the work compressed into a few hours once constraints, the first-article iteration loop, and the programmatic chart path were in place

At the end of the Manus session, I had the LLM create a comprehensive style guide documenting everything: the brand principles, the prompts that worked for each asset type, the Matplotlib boilerplate, all nine iteration rules, export standards, and a QA checklist. That style guide became the canonical reference for all future visual asset work.

Then we built the workflow into the lower dB's admin system itself. Editors can now propose a visual plan from an approved article draft, review and edit typed visual specs before generation begins, and approve final assets before publication. The generation providers mirror the same split that came out of the Manus session - programmatic_svg for diagrams, cards, timelines, and charts, and openrouter_image for model-backed illustrations.

The visual workflow has the same human-in-the-loop philosophy as the editorial pipeline. Specs are reviewed before generation. Generated assets are reviewed before publication. Nothing goes live without explicit approval.

The compounding effect

The visual asset session was smooth because of everything that came before it. The content review gave me the audit. The editorial pipeline taught me where constraints beat prompt engineering. The enrichment iteration taught me to start narrow and scale only after the first pass was right.

This is the same principle that shows up in building LLM evaluation systems where the upfront work of creating your golden dataset is what determines whether your evaluations are meaningful. Skip the preparation, and the outputs are inconsistent no matter how good the model is. Invest in the preparation, and the generation becomes the easy part. We'll have more to say about evals in a future post.

Whether you're measuring site speed, designing an agent pipeline, or generating 79 images, the preparation and the constraints are the actual product.