From Pixels to Programs: What VIGA, Articraft, and OmniLottie Prove About Code-Native Visual AI

Two Stacks, One Decision: What the Model Actually Emits

Yoko Li's essay "The Next Frontier of Visual AI Is Code" (a16z, June 2, 2026) draws a line through the visual-generation landscape that I find more useful than any leaderboard: there are two stacks, and they differ in what the model is asked to emit. The first stack is pixel-native. Diffusion systems generate images or videos directly in latent space, and they remain dominant for texture, atmosphere, lighting, and realism. If my goal is a cinematic still or a photorealistic moodboard, that is still the stack I reach for. The second stack is code-native: the model produces a representation that another engine executes or renders. As Li puts it, the model "does not directly produce the final pixels; it produces the program that produces the pixels." That program might be an SVG file, an HTML/CSS layout, a React component, a Lottie JSON document, a Blender script, a USD scene graph, a shader, or a game-engine scene.

The distinction sounds academic until you look at what production work actually demands after the first draft. A designer does not need a mockup; they need layers, components, and handoff. An animator does not need a video; they need timing curves, keyframes, and editable motion. A 3D artist does not need a rendered picture; they need geometry, materials, lighting, cameras, and scene structure. A generated raster image is an output — it gets consumed once. A generated visual program is an artifact: it can be edited, reused, versioned, validated against constraints, rendered again under different conditions, and handed off between designers, engineers, and agents. That gap between output and artifact is the entire thesis, and it is the difference between a demo reel and a production pipeline.

What makes the essay worth an operator's time is that it is not a forecast resting on vibes. Li grounds it in a specific stack decomposition and in named systems I could go inspect: Quiver's Arrow models for vector graphics, OmniLottie for Lottie animation, VIGA for Blender scene reconstruction, and Articraft for articulated 3D assets. I read all four closely, plus the inference-time search paper the essay cites as the pixel-native contrast. The rest of this piece is my working notes on how the code-native stack actually fits together, what the published numbers do and do not establish, and where I would expect it to break before I wire it into anything real.

The Three-Part Stack: Authoring Model, Symbolic Artifact, Feedback Engine

Underneath every system in this wave sits the same three-part decomposition: a coding model, a symbolic representation, and a renderer or engine. The coding model is the author and editor of the artifact — it writes the HTML, the SVG paths, the Lottie JSON, the Blender Python, the USD scene. The symbolic representation is the source of truth, and it is the part people underrate. A UI has DOM nodes, layout rules, and components. A Lottie animation has layers, vector shapes, timing curves, keyframes, and motion parameters. A 3D asset has geometry, materials, joints, constraints, and hierarchy. Because that structure exists explicitly, feedback can attach to it: "the spacing is wrong" becomes "change this CSS rule," and "the drawer should slide" becomes "fix this prismatic joint."

The renderer or engine turns structure into pixels, and — this is the conceptual move that matters — it doubles as the feedback environment. The browser renders HTML/CSS. An SVG renderer draws vectors. A Lottie player plays motion. Blender renders and simulates 3D scenes, and a physics simulator can validate whether an articulated asset can actually move. Li's prediction is that renderers become the sandboxes of visual agents the way VMs and container environments are the sandboxes of coding agents today. Having watched coding agents thrive precisely because they can run their own tests, I think the analogy is exact: the engine is where the compiler errors and unit tests of visual work live.

The market is already organizing around those runtimes. Each one creates a different wedge because each has its own source representation, its own feedback loop, and its own production workflow. Vector design tools orbit the browser and SVG. Motion tooling orbits the Lottie player. 3D work orbits Blender, USD, and game engines. That mapping — representation to runtime to workflow — is how I now segment the "visual AI" category, instead of the older and much less useful split by output modality.

Code, Render, Inspect, Revise: The Loop That Converges

The economic argument for the code-native stack is about what happens after the first draft. In pixel-native generation, more inference usually means sampling more outputs: generate twenty images, pick the best one, maybe roll again. Every attempt is a new roll of the dice, and the feedback is global and imprecise — "warmer," "more cinematic." Diffusion research does have real test-time-compute results: the paper "Inference-time Scaling of Diffusion Models through Classical Search" (arXiv 2505.23614) combines annealed Langevin MCMC as local search with breadth-first and depth-first tree search as global exploration, and reports significant gains across planning, offline reinforcement learning, and image generation. But even there the system searches over latent trajectories or finished samples. A reward score can rank two outputs; it cannot map the difference onto a specific source-level edit.

Code-native generation changes the unit of iteration. The loop is: write the artifact, render it, inspect what broke, patch the source, render again. If a logo curve is off, edit the SVG path. If the animation feels slow, adjust the timing parameter. If a wheel does not spin, fix the joint definition. Every iteration improves the underlying artifact rather than replacing it, which is why Li argues this stack sits on the direct path of test-time compute: the model is debugging a visual program in a closed-loop, verifiable environment, not resampling pixels and hoping.

flowchart TD
    P[Intent: text prompt or reference image] --> A[Authoring model: VLM writes the artifact]
    A --> S[Symbolic artifact: SVG, Lottie JSON, Blender Python, USD]
    S --> R[Feedback engine: browser, SVG renderer, Lottie player, Blender, simulator]
    R --> O[Rendered output]
    O --> C{Verification: compiler checks, VLM inspection, physics tests}
    C -->|discrepancy traced to source| A
    C -->|checks pass| E[Editable versionable production artifact]
    A -.-> MEM[(Contextual memory: plans, code diffs, render history)]

Two properties of this loop deserve emphasis. First, convergence is a property of the feedback, not of the model's mood: a render is a deterministic function of the artifact, so the same edit reliably produces the same improvement, unlike a re-rolled diffusion sample. Second, the loop's ceiling is set by how precisely the inspector can translate a visual discrepancy into a source-level fix. A VLM that can only say "looks wrong" is no better than a human squinting at re-rolls. Every system below is, at its core, a different answer to the question: how do you give the loop an inspector that points at the line of code to change?

VIGA: One Agent Wearing Two Hats Inside Blender

VIGA (Vision-as-Inverse-Graphics Agent, arXiv 2601.11109, from UC Berkeley, CMU, Max Planck, and Impossible Inc.) is the purest expression of the loop I have seen. It reconstructs an input image as an editable Blender scene program through analysis-by-synthesis: it writes executable scene code, renders it, compares the renders against the target from multiple viewpoints, and revises. One self-reflective agent alternates between two roles. As generator, it plans and writes scene programs using tools for code execution, asset retrieval, and scene queries. As verifier, it examines renders, identifies visual discrepancies, and writes feedback for the next iteration. The agent maintains an evolving contextual memory — plans, code diffs, and render history — so it can sustain evidence-based edits over long horizons, and the whole write-run-compare-revise loop is training-free.

sequenceDiagram
    participant O as Operator
    participant G as Generator role
    participant B as Blender runtime
    participant V as Verifier role
    participant M as Contextual memory
    O->>G: target image and task
    G->>M: record initial plan
    G->>B: execute scene program
    B-->>V: renders from chosen viewpoints
    V->>M: store diff and critique
    V->>G: source-level edit instructions
    G->>B: revised program
    B-->>V: updated renders
    V-->>O: converged editable scene

The verifier's toolbox is the part most teams would skip and shouldn't. VIGA can change camera views, query scene state, and isolate objects before judging a render — because a render from a bad angle looks wrong for reasons that have nothing to do with the scene code. It can also bootstrap quality by pulling in off-the-shelf generators like Meshy or SAM-3D for individual assets, then compose and physically interact with them in Blender: scenes can be knocked over by a thrown ball, shaken by a simulated earthquake, or reflected in a reconstructed mirror. The domains table in the README is broader than 3D: BlenderBench for multi-step 3D editing, BlenderGym for single-step edits, and SlideBench, which synthesizes 2D slide layouts and emits PowerPoint files — same loop, different symbolic artifact.

The operational cost is real, and I want to state it plainly because essays like this rarely do. Running VIGA means four separate conda environments (agent on Python 3.10, Blender tooling on 3.11, SAM on 3.10, SAM-3D on 3.11), a minimal Infinigen install inside Blender, a downloaded SAM ViT-H checkpoint, and both an OpenAI key and a Meshy key, with the run command pinning the model (the README shows --model=gpt-5) and an explicit generator-tools list. NVIDIA GPU support is recommended. This is a research artifact wearing a quickstart, not a product; the MIT-licensed repo is honest about that, and my plan would be to treat it as a reference architecture to strip down rather than a dependency to adopt wholesale.

Articraft: Compile, Test, Simulate, Then Export the USDZ

Articraft attacks the 3D problem from the artifact side. The framing in its paper (arXiv 2605.15187) is exact: reduce generating an articulated 3D asset to writing the program that builds it. The model writes Python against a domain-specific SDK for defining parts, composing geometry, specifying joints, and writing tests that validate the result. A harness gives the model a restricted workspace, compiles the code, validates the asset, and returns structured feedback — deliberately keeping the model away from raw URDF authoring and environment management. The current repo (articraftresearch/Articraft, Apache 2.0, explicitly pre-1.0) turns that research into a usable tool: uv run articraft "a jet engine" produces a run, and a viewer lets you inspect each version and move its joints. The export format is the detail that won me over: a posable USDZ file, which drops into the pipelines game and AR teams already run.

What makes Articraft the strongest example of verification-as- first-class-citizen is its simulation gate. Install the optional sim tools and articraft simulate runs a default drop test; the simulator can also exercise sliding friction and released joints. That is the "doors should open, hinges should rotate, drawers should slide" requirement from Li's essay made executable. A plausible-looking chair is not a chair until physics agrees, and Articraft checks physics before a human ever reviews the asset. The provider story is pragmatic: OpenAI by default, with Anthropic and Gemini also accepting reference images for reconstruction tasks, and OpenRouter limited to text-only. There is even a recorded-replay test lane so development does not burn paid model calls.

The paper's results claim is breadth, not just quality: Articraft produces higher-quality assets than both state-of-the-art articulated-asset generators and general-purpose coding agents, and the team used it to build Articraft-10K, a curated dataset of over 10,000 articulated assets across 245 categories, aimed at training downstream models for robotics simulation and VR. That last move — using the generator as a dataset factory — is an under-discussed production pattern. If your bottleneck is labeled simulation-ready assets rather than one hero asset, a code-native generator with a physics gate is a data engine, and the dataset may be worth more than the tool.

OmniLottie and Quiver: Fix the Representation, Not the Prompt

The 2D entries in this wave teach a subtler lesson: before the loop can work, the representation itself has to become model-native. OmniLottie (arXiv 2603.02138) generates vector animations from multimodal instructions, and its authors found raw Lottie JSON hostile to learn from — it is packed with invariant structural metadata and formatting tokens. Their fix is a Lottie tokenizer that transforms JSON files into structured sequences of commands and parameters covering shapes, animation functions, and control parameters. On top of that representation they build on pretrained vision-language models, and to train and evaluate they curated MMLottie-2M, a large-scale dataset of professionally designed vector animations paired with text and image annotations. The payoff is exactly the property the code-native thesis needs: once motion lives as shapes, layers, timing, and parameters, "it moves too slowly" maps to a timing parameter instead of a re-roll.

Quiver is the commercial proof that this works as a product. Its Arrow models generate, edit, and animate vector graphics — the essay's designer example used Arrow 1.0 in May 2026 for a logo that went straight into Figma refinement; the site currently ships Arrow 1.1. The surface area is telling: an API at api.quiver.ai with model listing, text-to-SVG, and image-to-SVG endpoints; an MCP server (announced June 9, 2026) so agent workflows can request structured SVG generation; and integrations where the artifact, not a screenshot, is the deliverable — Paper (May 12, 2026) and Timbal AI (May 19, 2026). Quiver raised an $8.3 million seed round led by a16z. Typography and animation are marked coming soon; logos and illustrations are live. A design-tool vendor wiring SVG generation directly into its editor is the "artifact over output" thesis passing the market test.

Reading OmniLottie and Quiver side by side changed how I think about prompting. The bottleneck in code-native generation is rarely the authoring model; it is whether the symbolic representation exposes the right levers at the right granularity. Raw formats evolve for human tooling and carry decades of inertia. The systems that win each runtime will likely be the ones that define a parallel, model-facing encoding of the same artifact — tokens for the model, clean JSON for the player — and translate at the boundary.

What the Benchmarks Actually Show

The numbers I could verify from project pages and papers are narrower than the vision, but they point one direction. VIGA reports a 124.70 percent average improvement on BlenderBench, its 30-task benchmark covering camera adjustment, multi-step editing, and compositional editing; 35.32 percent on the pre-existing BlenderGym; and 117.17 percent on SlideBench. Against one-shot GPT-4o on BlenderBench Task 1, photometric loss drops from 48.16 to 5.47 and the VLM score climbs from 0.58 to 3.25 at best-of-4. The comparison I find most informative is internal: BlenderAlchemy, a memory-less variant, improves far less than the full system with memory — at best-of-4 on Task 1, 14.50 photometric loss versus VIGA's 5.47. Remembering what you already tried is not an implementation detail; it is most of the gain. That matches everything I know about long-horizon agents: the loop converges only if the agent can avoid re-breaking what it already fixed.

The honest caveats: BlenderBench ships with VIGA, so "we built the benchmark and won it" discounts automatically; photometric loss and VLM-judge scores are proxies that can be gamed; and the baselines are one-shot or memory-less by construction, which flatters any iterative system. Articraft's paper claims quality above both specialized articulated generators and general coding agents, but the deeper evidence is structural — compile errors, joint tests, and physics simulation are checkable facts, not judge opinions. Quiver publishes no benchmark at all; its evidence is commercial adoption, which is the kind I weight most when a category is this young.

System	What the model writes	Feedback environment	Final output	Status and license
Quiver Arrow 1.1	SVG paths, primitives, gradients	SVG renderer in the browser	Production-ready vector logos and illustrations	Commercial API and MCP server; $8.3M seed led by a16z
OmniLottie	Tokenized Lottie command sequences	Lottie player	Editable vector animations from text and images	Research paper (March 2026) plus MMLottie-2M dataset
VIGA	Blender Python scene programs	Headless Blender renders plus VLM verifier	Editable scenes with physics and 4D interaction; PowerPoint via SlideBench	Open source, MIT; research-grade setup, four conda environments
Articraft	Python against a 3D authoring SDK	Compiler checks, joint tests, drop-test simulation	Posable USDZ assets; Articraft-10K dataset	Apache 2.0, pre-1.0, actively developed
Pixel-native diffusion (contrast)	Nothing — latents decoded straight to pixels	Best-of-N sampling or latent-space search	Raster images and video	Mature, dominant for texture and realism

The Failure Modes I'd Watch Before Betting a Pipeline on This

First, inspection precision. Li is blunt that the loop only works if the agent has the right tools and context: changing camera views, querying scene state, isolating objects, comparing against the target, remembering prior attempts. An inspector that can only say "wrong" produces oscillation, and small errors in structure or feedback compound across iterations instead of washing out. VIGA's memory result is the quantitative version of this; my rule of thumb is that if I cannot articulate what the verifier checks, I do not have a loop, I have a slot machine with extra steps.

Second, review-stage fatigue. Code artifacts invite code review, and code review invites rubber-stamping once volume rises. If the authoring model produces syntactically clean but semantically wrong programs often enough, the human gate degrades into approving diffs nobody read — the classic human-in-the-loop failure, now wearing a compiler's clothing. Articraft's answer is to push verification below the human: physics tests and joint checks catch functional nonsense mechanically, so the human reviews only what machines cannot. I would not deploy any pipeline in this family without an equivalent mechanical gate ahead of the human one.

Third, abstraction leakage: visually significant detail that the symbolic representation simply cannot express. Li's own open questions concede the boundary — which representation wins each domain, whether the engines themselves need rebuilding for model-native use, and how much visual taste can actually be captured by constraints, tests, and loops. The essay's conclusion is hybrid, and I agree: pixel-native models keep the crown for realism, texture, and exploration; code-native systems own structure, iteration, and handoff. The failure mode to avoid is ideological purity — forcing a code-native stack onto a problem whose value is purely atmospheric, or accepting diffusion re-rolls for an artifact that must survive ten rounds of client edits.

Fourth, operational weight. VIGA's four conda environments and dual API keys, Articraft's pre-1.0 churn, and the absence of any SLA-backed product in the 3D tier mean the 2D tier is the only place this is boring technology today. That is fine — boring is where I want my first deployment anyway.

Where I'd Deploy This Stack First

The lowest-risk, highest-feedback deployment is vector brand assets through Quiver's API: text-to-SVG for logo and illustration exploration, the output dropping straight into Figma as editable paths, with the MCP server letting internal agents generate on-brand SVGs on demand. The artifact-is-source property is immediately monetizable — recoloring a logo across fifty contexts is a find-and-replace, not fifty re-generations. Second, motion: Lottie already dominates app onboarding and micro-interactions, and OmniLottie-style tokenized editing means a copy change or timing tweak is a parameter edit reviewed in a diff, which shrinks the design-engineering round trip that every mobile team I have seen suffers through.

Third, and most ambitious: Articraft as a game-studio asset drafting engine. Text or reference image in, simulation-gated posable USDZ out, artists reviewing only assets that passed the drop test — with the Articraft-10K pattern repurposed internally, generating scenario libraries for robotics or VR testing instead of buying them. The pilot I would run before committing anywhere: take one pipeline that currently gates on human pixel review, insert the mechanical checks ahead of the render step, and measure review time per asset and defect escape rate for two weeks. If review hours fall without escapes rising, the loop is real in my context, not just in Berkeley's.

Resources

• The Next Frontier of Visual AI Is Code — Yoko Li, a16z
• VIGA: Vision-as-Inverse-Graphics Agent — project page
• VIGA — GitHub repository
• VIGA paper — arXiv 2601.11109
• Articraft — GitHub repository
• Articraft paper — arXiv 2605.15187
• OmniLottie paper — arXiv 2603.02138
• Inference-time Scaling of Diffusion Models through Classical Search — arXiv 2505.23614
• QuiverAI — product site