Creative Coding

IBM Research Taught a Small Open Model to Write the Code That Draws Your Slides

Palette splits deck-making into a designer role and a coder role, served by a single LoRA adapter — the designer plans each slide's content, the coder writes the pptxgenjs JavaScript that places it, pixel by pixel.

Ask a frontier model for a slide deck and you’ll get a good one. Ask for ten and they start to look alike — the same tasteful defaults, the same house style, a faint “AI-generated deck” look that doesn’t match whatever template you actually need it to follow. Palette, a project from IBM Research published November 3, tackles that by training a small open model to write slides in code, the way a person actually builds one: plan first, then draw.

Two roles, one adapter

Palette fine-tunes a 20B open-weight model with a single LoRA adapter that serves two distinct roles in sequence, rather than one pass trying to do both planning and layout at once.

The designer reads a content plan and writes a structured JSON brief: the color palette, the type system, and for each slide its layout, its exact content, and a short rationale for why that layout was chosen. The coder then takes one slide’s spec from that brief and writes the actual pptxgenjs JavaScript that draws it — positioning every element at an x, y, width, and font size — preceded by its own reasoning about the geometry.

Splitting the work this way means each role only has to make one kind of decision: the designer handles editorial judgment (does this data want a chart or a table? what gets cut?), and the coder handles arithmetic (will a 62-character title at 44pt wrap into the chart below it?). Because every slide’s spec is fixed before any code gets written, the coder calls for different slides run in parallel, which IBM Research says makes the coding stage roughly 6–7× faster than a single sequential pass.

Training data nobody had

There’s no public corpus of decks paired with the reasoning behind their design choices and the code that produced them, so IBM Research generated one: roughly 1,000 decks covering about 10,000 slides, synthesized by a larger open teacher model from recipes that fixed each deck’s genre, length, layouts, and any user-specific directives. Every example carries its reasoning as a counterfactual — the trace weighs an alternative choice and states why it was rejected, so the model learns the underlying rule rather than memorizing a single answer.

Every synthesized slide was also rendered and checked by the same overlap/overflow checker the inference harness uses, with broken slides repaired and their reasoning rewritten to explain what the original layout got wrong — turning each caught mistake into a better training example rather than a discarded one.

Where it ranks

On PresentBench, IBM Research’s own benchmark for this task, Palette ranks first on two of the three measured domains — a notable result for a model small enough to self-host, going up against frontier systems with no comparable ownership or data-privacy constraints. The core pitch isn’t that Palette beats frontier models on raw quality everywhere; it’s that a self-hosted, design-language-specific model can get close enough to be worth the control it gives back: open weights, your own infrastructure, and decks that don’t drift back toward whatever house style a frontier provider defaults to.