How LLMs Actually Draw: Code-Based Rendering vs. Native Image Generation
When a large language model outputs SVG code that renders into an image, is it really "generating" pictures? This article breaks down the two fundamentally different technical paths behind AI drawing: code-driven rendering, where the model produces drawing instructions for external engines such as browsers, and native multimodal generation, where diffusion models learn visual distributions and output image tensors directly. It compares the two paths across output type, rendering responsibility, strengths, failure modes, and editability, explains why product-level capabilities should not be conflated with single-model capabilities, and offers a practical framework for evaluating image generation features along with concrete selection advice for developers.
1. Where the Debate Starts: What Counts as “Generating Images”
A recurring argument in technical communities goes like this: when a large language model (LLM) outputs a piece of SVG code that a frontend renders into an image, can we say the model “can generate images”? Supporters argue that users do end up seeing a picture, so from their point of view the model can generate images. Critics counter that the model only ever outputs text—the rendering is done by an external engine, which is something entirely different from true image generation.
The root of the dispute is that the two sides are using different definitions. In everyday usage, “can it generate images” is about the end user’s experience. In technical usage, “generating an image” is about the data transformation that happens inside the model. Neither definition is inherently wrong, but mixing the two in technical discussions, capability assessments, and engineering decisions produces a great deal of unproductive argument. This article dissects the question from first principles.
2. Path One: Code-Driven, Indirect Drawing
2.1 SVG: Describing Graphics with Text
SVG is an XML-based vector graphics format—essentially a piece of structured text. For example:
<svg width="200" height="200" xmlns="http://www.w3.org/2000/svg"><rect x="10" y="10" width="180" height="180" fill="#4A90D9" rx="16"/><circle cx="100" cy="100" r="50" fill="#FFFFFF"/><text x="100" y="105" text-anchor="middle" fill="#333">Logo</text></svg>
A rendering engine reads this text and draws the rounded rectangle, the circle, and the label. For LLMs, this lands squarely in their strongest area: structured text generation. Having seen vast amounts of SVG, frontend code, and technical documentation during pretraining, models can produce syntactically valid, well-structured graphics descriptions with impressive reliability.
The advantages of this path are clear:
- Precise and controllable: coordinates, colors, and text content are explicitly specified as parameters, so data labels in charts almost never come out garbled;
- Highly editable: the output is source code, and humans can go on to tweak any detail;
- Lossless scaling: vector formats stay sharp at any resolution.
The limitations are just as clear: SVG can only cover “regular graphics”—geometric shapes, icons, flowcharts, and data charts. It cannot express photorealistic textures, lighting, or complex artistic styles. Asking a model to “draw” a lifelike cat in SVG is essentially trying to approximate a continuous visual distribution with a finite set of tags, and it is destined to fall short.
2.2 Canvas and Other Drawing Instruction Systems
HTML Canvas is another representative example: it is an imperative drawing API, so the model generates a program that is executed step by step, while the actual pixel painting is done by the browser’s runtime. Similar approaches include configuration code for charting libraries, flowchart description languages, typesetting markup languages, scientific plotting scripts, and more.
These solutions share the same technical essence: the model generates “drawing instructions,” not “the image itself.” The rendering step is outsourced to a deterministic external engine. Once you understand this, you can see what each side of the debate gets right: the image the user sees does exist, but it was not directly “painted” by the LLM.
3. Path Two: Native Multimodal Image Generation
The counterpart to the code path is native multimodal generation, whose mainstream solution is the diffusion model. The working principle can be summarized as follows:
- During training, noise is progressively added to real images, and the model learns to recover an image from pure noise;
- During inference, a text encoder converts the prompt into semantic vectors that guide the model through iterative denoising in latent space;
- The result is finally decoded into a pixel-level image.
On this path, the model directly learns the continuous distribution of visual data and outputs image tensors rather than text. It is therefore naturally suited to photorealistic rendering, artistic stylization, and complex lighting effects. Historically, these models have been weaker at rendering text inside images and at precise structural control, but as the models evolve, this shortcoming is gradually being closed.
There are also autoregressive image-token approaches, which discretize images into token sequences for generation. The underlying principles differ in detail, but they share one thing in common: the pixel generation process happens inside the model.
4. The Fundamental Differences Between the Two Paths
| Dimension | Code-based drawing | Native image generation |
|---|---|---|
| Model output | Structured text / instructions | Image tensors |
| Rendering | Performed by an external engine | Completed inside the model |
| Best at | Charts, diagrams, icons | Photorealistic images, artistic creation |
| Typical failure mode | Syntax errors break rendering | Semantic drift, distorted details |
| Editability | Precise source-level modifications | Regeneration or local inpainting only |
It is worth stressing that the two paths are not competitors; they cover different task spaces. Judging a model with a binary “can it generate an image or not” discards exactly the information that matters.
5. The Product Perspective: Unified Entry Points and Model Orchestration
Another common cognitive bias in these debates is conflating “what the product entry point can do” with “what a single model can do.” The typical architecture of a modern AI assistant is multi-model orchestration: the entry layer performs intent recognition to decide whether a request is text Q&A, code generation, or image creation, routes the request to the corresponding backend capability module, and then aggregates the results. The user sees a single, unified conversation interface, while underneath, multiple heterogeneous models may be working together.
From this angle, a statement like “product X can generate images” is technically imprecise. The rigorous version is: which mechanism implements this product’s image generation—a code rendering pipeline, or a standalone multimodal generation service? User experience and implementation are two different layers. The product framing and the technical framing each serve different purposes, so align on definitions before exchanging views.
6. How to Rigorously Evaluate “Image Generation Capability”
Based on the analysis above, here is a practical evaluation methodology:
- Define the task first: chart drawing, flowchart generation, poster design, and photo synthesis are entirely different tasks, and conclusions about capability do not transfer between them;
- Measure along multiple dimensions: text rendering accuracy, structural controllability, aesthetic quality, generation stability, and other dimensions should each be scored separately;
- Combine benchmarks with human review: automated metrics capture objective properties, while human reviewers assess subjective quality;
- Reject anecdotal evidence: one success does not prove capability, and one failure does not disprove it. Sample sufficiency and task representativeness are baseline requirements.
7. Practical Recommendations for Developers
In real projects, choose an approach based on the characteristics of the task:
- For precise, maintainable diagrams and charts (architecture diagrams, data reports, illustrations): prefer the code generation path. Have the model output SVG or chart configurations and render them on the frontend; the deterministic output is easier to bring under version control and automation pipelines.
- For creative and photorealistic imagery (marketing assets, concept design): integrate multimodal content generation services, such as the image generation API categories commonly offered by major cloud platforms.
- For complex scenarios, use a hybrid pipeline: use an LLM for intent understanding and parameter extraction, then drive a generation engine to render. For example, host the generated images on object storage, run the rendering services on function compute or a container platform, and use logging services plus monitoring and alerting to keep the pipeline stable. This is a mature, widely adopted architecture pattern in the industry today.
8. Closing Thoughts
“Can a large language model generate images?” is not a yes-or-no question with a simple answer. In the code-based drawing path, the model generates drawing instructions and an external engine handles rendering; in the native image generation path, the model directly learns and outputs visual distributions. Each has its own boundaries in principle, capability, and applicable scenarios. For developers, the genuinely valuable work is not arguing endlessly about “can or can’t,” but understanding the technical essence of each path, establishing clear evaluation criteria, and making sound engineering choices for specific business tasks. That is what technical discussion should look like.
