There's a line in a recent build log that stuck with me. An indie developer shipped a tool called InkDoo that auto-illustrates articles with a consistent hand-drawn character, and in the writeup they said the plainest thing: the expensive part isn't generating the images, it's figuring out which passage deserves a figure and where to put it. Their own words, roughly: the most time-consuming step is deciding "what to draw for this section, and where it goes."
That's the whole insight. Everyone fixates on the render — the model, the style, the character doing something physical. But the judgment call upstream is where the real work lives, and it's the part that's easy to get wrong and annoying to redo. So let's take that admission seriously and rebuild only that half: the planner. Not the picture factory, the decision layer that sits in front of it.
What the planner actually does
Strip InkDoo's description down and the planning stage is a sequence of judgments. Read an article. Pick a handful of points worth illustrating — not every paragraph, just the ones that carry weight. For each chosen point, decide a structure (a process, a before/after, a metaphor). Attach it to a specific anchor paragraph so the figure lands in the right place. The output isn't an image, it's a structured description. In their stack that comes back as JSON from a fast model.
Notice what this is: a model that returns structure, a human who corrects it, and a view that lets the human see the plan against the source before anything irreversible happens. That shape shows up all over the evidence I've been reading lately. One developer built a photo CMS whose entire pitch is "humans manage the photos, AI writes the site" — splitting the judgment work from the mechanical work. Same instinct. The valuable move is isolating the part that needs a person and making it cheap to review and fix.
Rebuilding it on VicroCode
Here's how I'd lay it out, piece by piece.
The brain is a small backend. You write an endpoint that takes an article body, sends it to a model with a prompt that says "act as an art director, choose the points worth a figure, and return a plan," and parses the structured result. You can run Python online for exactly this — a hosted Python endpoint that calls a Model Center model and hands back JSON. The constraint worth stating out loud: Model Center serves the models already available on the platform, so the planning model you reach for has to be one of those. Whether a given model produces art-director-quality plans is something you'd test, not assume. Treat plan quality as unverified until you've eyeballed real output; even InkDoo's author openly asked peers whether their planner's picks felt accurate.
The plan needs somewhere to live that you can touch. Don't let the model's JSON flow straight to the next stage. Land it in a table first — one row per proposed figure, with columns for the point, the chosen structure, the anchor paragraph, and a status flag like proposed / approved / rejected. A SQLite table fits this cleanly, and the reason to use a database instead of a loose file is the editing: you want to open the rows, fix the model's bad calls by hand, flip a few to rejected, and only then commit. A SQLite editor gives you that hand-correction step directly, which is the part the whole design hinges on. The model proposes, you dispose.
Then you need to see it. A plan as a wall of JSON is useless for judgment — you want the article on one side and the proposed figures on the other, each one lined up with its anchor paragraph so you can tell whether it belongs there. Build a review page and run HTML online so it's hosted and shareable, reading from the same SQLite rows. Click to approve or reject, watch the plan sit next to the prose, catch the figure the model wanted to jam into an intro that didn't need one.
That's the loop. Endpoint proposes a plan, table holds it for correction, page shows it against the article, you approve what survives. Three pieces, each one a thin layer, none of them pretending to do the next guy's job.
Where I'd stop, honestly
The render is the boundary, and I'd draw it hard. InkDoo's generation runs on GPT Image 2.5 producing a white-background black-line hand-drawn style, and their app rides on a React stack hosted on Cloudflare Workers with D1. None of that maps to the confirmed VicroCode capabilities. Image generation isn't on the list, and I'm not going to infer it is. Neither is a specific third-party image model, nor that particular hosting setup. So this build gives you a reviewed, corrected, committed insertion plan — the hard part — and then it hands off. The actual picture-making is a separate problem on a separate tool, and I'd rather say that plainly than wave at a capability that isn't there.
Which, if you believe the original premise, is fine. The person who built the real thing told us the generation was never the bottleneck. If the planning layer is where the time goes, then a hosted endpoint, a correctable table, and a side-by-side review page is a genuinely useful tool on its own — and it's buildable within what the platform actually supports. You can publish and share it from there, and if the plan quality holds up across enough articles to be worth charging for, that's a conversation for later, after the output has earned it.
Start with the judgment layer. Let the model draft, keep a human in the commit path, and don't reach past the boundary for the shiny part everyone else is staring at.