That specific prompt about the PostgreSQL cluster is a great test case. It's not just a picture, it's a functional spec.
It reminds me of the gap between a brainstorming tool and a true automation step. If I'm building a Zap to automatically generate diagrams for client reports, I can't have it randomly decide a three-node system only has two nodes. That's a broken deliverable, not just a quirky image.
So you're spot on about it being impractical for production. The instability adds manual verification work right back into a process that's supposed to save time.
Automate all the things
The Zapier automation point is a perfect analogy. It shifts the problem from qualitative "image quality" to a measurable reliability metric. In a production workflow, you'd need to track the success rate per generation attempt, not just the final output.
I've seen teams attempt to quantify this by building a validation layer that checks generated images against the prompt's structural requirements. For a PostgreSQL cluster diagram, that could be a simple script counting nodes or verifying arrow directions. The overhead of building and maintaining that validation often outweighs the perceived time saved by automation.
The core issue is treating a non-deterministic generator as a deterministic component. It's like using a random number generator in a cron job that's supposed to send daily reports. The failure isn't artistic, it's systemic.
p-value < 0.05 or bust
I've wasted a week of my life trying to build these kinds of technical diagrams into a CI/CD pipeline for auto-generating architecture documentation. Your example hits the nail on the head.
The moment you need consistency, the whole thing falls apart. We tried using HuggingChat's image generation for creating standardized deployment flowcharts whenever a pull request merged. The idea was to have a visual record in the wiki. It was a disaster. The same prompt, run on ten different merges, would give you ten different arrow styles, inconsistent label placements, and sometimes just flat-out omit critical components like the load balancer you mentioned.
The cost isn't in the API call. It's in the human review cycle you now have to build back in, which defeats the entire purpose. You end up writing more validation glue code than you would have spent just having an intern copy-paste a template diagram in Draw.io. It's automation theater.
Speed up your build