From Templates to Code: Two Routes of AI Slide Generation, and Where Chinese Models Hit Their Ceiling
Part 1 covers the history and current state (the two technical routes, the commercial landscape, why the SOTA is Claude and Codex). Part 2 dissects the code-generation harness I built, and what changes when you swap only the base model.
This is what I concluded after running a PPT harness of my own for a while and then taking apart, one by one, the tools on the market in China and abroad. The takeaway up front: almost every mainstream commercial AI-PPT product is, at heart, "AI generates content + a template/layout engine"; the truly "pure AI generation" route — where the model writes the layout itself, line by line — is done best today by Claude and Codex (OpenAI's code generation). Part 1 unpacks how I got there; Part 2 covers the harness I built and how it behaves on different base models.
- Part 1 · History & state: a short history → the two routes → why the SOTA is Claude and Codex → the commercial state (China & abroad)
- Part 2 · Our harness: architecture (two-axis QA + render-self-check loop) → the model ceiling when you swap base models → conclusions
1. A very short history
Slide software itself has barely changed in twenty years: PowerPoint, Keynote, Google Slides — you open them to a blank rectangle waiting to be filled. "AI for slides" grew out in a few waves.
Wave 1: template intelligence (no LLM). In the mid-2010s, features like PowerPoint Designer shipped — essentially cloud-side layout recommendation. You dump in content, and rules plus lightweight ML hand you a few layouts. It had nothing to do with large models, but it established a division of labor that never changed since: content is content, layout is layout, and layout is done by a dedicated engine.
Wave 2: outline generators (the GPT-3.5 era). Once models could write copy, tools like SlidesAI appeared: "topic → outline → copy", then poured into a fixed template. The model only produced text.
Wave 3: the "narrative" camp and the PPT-killer hype (2022–2024). Tome was the poster child — "tell a story, don't stack bullets" — and grew fast, peaking around twenty million users with $80M+ raised. But it never cracked monetization, and in early 2025 it shut down the presentation product and pivoted the team to CRM. I read that as a signal: making "generation" flashy without solving "can this be delivered as a finished product" doesn't hold up. Over the same period Beautiful.ai took a different path — its Smart Slides are adaptive templates, with the design ceiling locked in by human designers.
Wave 4: the incumbents absorb it + code generation (2023–present). Microsoft put Copilot into PowerPoint (GPT-4 in 2023, now GPT-5.x); Gamma exploded to seventy million users in 2025; Google wired Gemini into Slides. And a route that didn't exist before appeared: have the model write rendering code directly (PptxGenJS / HTML), with the layout coded by the model itself. Claude's artifacts and ChatGPT's skills are both in this camp. This route is what this article actually cares about.
2. Two technical routes
Lay out every "AI PPT" on the market and you find only two kinds:
AContent generation + template/engine fill
The model only produces the outline and copy; the real imagery, color, and layout are done by a separate layout engine. That engine feeds on a template library pre-built by human designers, and its job is "pour structured content into the template's placeholders, handle overflow, apply the palette." On this route the model is a hot-swappable content engine, basically decoupled from design quality.
BCode generation (the LLM does the layout itself)
The model emits PptxGenJS or HTML directly; every coordinate, gap, and z-order on every page is written by it, line by line. On this route, the model's "taste" and "sense of space" directly set the design ceiling.
3. Today's SOTA: why pure generation means Claude and Codex
"Pure AI generation" — Route B, no pre-built templates, the model generates the layout from scratch — currently has only two real contenders: Claude (artifacts / pptx skill) and Codex (OpenAI's code generation + skills). Their approaches have converged hard, onto the same engineering paradigm:
- Design knowledge as a Skill. A markdown
SKILL.mdencodes rules like "use PptxGenJS, not python-pptx", "don't put an underline rule under titles", "alternate light/dark pages", and the model follows it. Both vendors' slides/pptx skills are open-sourced, with nearly identical structure. - The renderer converged on PptxGenJS. Early versions used python-pptx; both later switched to JS-based PptxGenJS — to produce genuinely editable native PowerPoint elements rather than image-baked dead layouts.
- A visual QA loop. This is the soul of Route B: generate code → render to image → model looks at the image → fix overflow/overlap/out-of-bounds → re-render. Not one-shot-and-done.
Why these two and not others? Because Route B feeds on two things at once: (a) the model's own spatial/compositional taste, and (b) a multi-round agentic loop with visual feedback. Only Claude's and OpenAI's frontier models reliably bring both together today. It's also why decks generated directly by ChatGPT/Claude are more custom to the topic than the "skinned template" tools — at the cost of crashing more easily, which is why QA has to catch the fallout.
Here are these two vendors' official Route-B tools, generating a cover/first page for the same open-source project (BettaFish) — the layouts are coded by the model, with no pre-built template:
4. The commercial state (China & abroad)
Back to Route A — the absolute mainstream of the commercial world.
Abroad
| Product | Underlying model | Key fact |
|---|---|---|
| Microsoft 365 Copilot (PowerPoint) | OpenAI GPT, GPT-5.x by mid-2026 (also adding in-house MAI / third-party models to cut cost) | PowerPoint's Designer (layout suggestions) is a separate, non-LLM ML system; layout is not the model's job |
| Gamma 70M users | model-agnostic, design from its own engine | Its gap vs ChatGPT/Claude is architectural — full deck editing + proprietary layout; PPTX export drifts (it's web-native at heart) |
| Canva | explicitly multi-model (GPT / Claude / Gemini) | "Use a third-party model first to get users and behavior, then invest in our own once validated" — the base model is a commodity to them |
| Beautiful.ai | LLM supplies content only | Smart Slides adaptive-template engine, best design consistency + PPT export fidelity — Route A taken to the extreme: template intelligence fully replaces model layout |
In China
Chinese vendors love to flaunt their own models, but the architecture is equally "in-house model writes copy + in-house layout engine":
| Product | Underlying model | Key fact |
|---|---|---|
| iFlytek Zhiwen | Spark V4.0 (separately trained for text gen) | It bolts on an "AI PPT orchestration engine", but the official description is mostly content/structure orchestration (pagination, points per page, hierarchy); the real visual layout is the downstream template library + diagram system |
| Baidu Wenku AI / Yinian | ERNIE | Same copy + template |
| WPS AI / WPS AIPPT | multi-model (DeepSeek, etc.) | model-agnostic |
| AiPPT.cn | integrates DeepSeek, Doubao, Qwen — one-click switch | The most textbook model-agnostic case; design comes from hundreds of templates. It's also the shared backend for "model PPT assistants" like Kimi and Doubao |
| Doubao / DeepSeek | own models | In the PPT scenario they only emit a Markdown outline; you still have to "skin" it onto a template engine (AiPPT / Xunjie / Modao) to get an actual deck |
As Part 1 noted, the commercial world uses templates to sidestep the hard problem of "letting the model do layout." I didn't take the template route — I went Route B, having the model emit PptxGenJS code and do the layout itself. Part 2 covers how that harness is built, and the model ceiling it measures when used as one fixed yardstick.
5. The harness we built: architecture
Architecturally it's two pieces: a two-axis QA framework, plus a render → self-check → fix loop.
Two-axis QA: no-crash × no-ugly
I treat "crashes" and "ugliness" as two orthogonal problems and fix them separately:
- No-crash (structural layer): can the file open, do elements go out of bounds, does text overflow. This layer is deterministic and can be enforced by code assertions.
- No-ugly (design layer): color, hierarchy, layout choice. This layer relies on skill rules + visual judgment.
The payoff of splitting them: no-crash can be a zero-cost, zero-infrastructure hard gate that doesn't depend on the model "noticing from the image"; only no-ugly is left to model taste and a VLM.
The render → self-check → fix loop
After generation, convert to PDF, then to images, then judge whether there's overflow/overlap/out-of-bounds, fix, and re-render. This step is the crux of Route B; without it you have an open loop and quality can't climb.
6. Same harness, swap only the base model: where Chinese models hit their ceiling
With the architecture frozen, I used the same harness, swapping only the base model, on the same BettaFish project, across three models: DeepSeek V4 Pro, Claude Opus 4.8, GPT-5.5. Here's the ceiling I observed.
Claude Opus 4.8 / GPT-5.5: this is what the ceiling looks like
Same harness, swap in these two, and the output is visibly better: a consistent English eyebrow + title system, hierarchy by whitespace rather than underlines, semantic color, even cross-page narrative callbacks. Below are the cover/first pages these two models produced on my harness, same BettaFish project:
What they share: no template feel — the layout is invented for the BettaFish topic; the eyebrow, KPI cards, and colored chips are design vocabulary the model came up with. But GPT-5.5 isn't crash-proof either — I've seen it center text into a chevron's notch on one page, clipping the left edge. That shows even the strongest model can't eliminate the need for the QA loop; it just raises the baseline.
DeepSeek V4 Pro: ceiling and floor both drop
Swap in DeepSeek V4 Pro and the content is fine — outline, copy, information density all hold up. But the design drops a visible notch:
Typical symptoms (including ones I saw on other pages):
- an underline rule under the title — the most classic AI-PPT tell, which good skills explicitly forbid;
- text overflowing past a card's bottom edge (out of bounds);
- the index "01" squeezed onto two lines ("0" / "1") because the text box was too narrow.
These defects share a trait: most are exactly the kind the render-self-check loop should have caught. In other words, V4 Pro's problems are partly model taste (a lower ceiling) and partly an unenforced loop (a soft floor).
7. Conclusions
Abstract the observations and I now use a "ceiling / floor" framework:
| Set by | Across the three models | |
|---|---|---|
| Ceiling | the base model — taste, composition, inventing layouts, narrative | V4 Pro ≪ Opus ≈ GPT-5.5; the QA loop can't build it — the loop removes defects, it won't invent a layout system for you |
| Floor | the QA loop + skill rules — out-of-bounds, overlap, AI tells | independent of which model you use; even GPT-5.5 needs it |
In one line: many things that look like "ugly" are actually an unenforced floor, not an insufficient ceiling. The QA loop can patch that; what it can't patch is the spatial taste at the ceiling.
Chinese models are catching up. The DeepSeek V4 series only recently gained multimodality (vision), which means "letting a Chinese model be the visual judge in a QA loop" has only just become possible. The floor layer they can catch up on; the real gap is spatial taste at the ceiling.
Boiling it all down:
- Engineering-wise, AI PPT has only two routes: content + template engine (Route A) and code generation (Route B).
- Almost every commercial service, in China and abroad, is on Route A. Their design ceiling comes from a human-designed template library; the base model is just a hot-swappable copy engine — which is why they're fast, stable, but formulaic, and why they can afford to be indifferent to the underlying model.
- Pure AI generation (Route B) is done best today by Claude and Codex. Because this route needs both "the model's spatial taste" and "an agentic loop with visual feedback," and only these two assemble both.
- My own harness is on Route B and measured where Chinese models stand today: content is good enough, but the design ceiling (spatial taste) is still a notch lower; and a lot of what looks like "ugly" is actually an unenforced floor — which the QA loop can patch, and which Chinese models, having just gained vision, can catch up on.
One last line for the route debate: the commercial world used templates to sidestep "let the model do layout"; I'm taking it head-on. The sidestep route has its ceiling locked by templates; the head-on route has its ceiling set by model taste — the former is already mature, the latter is still rising along with the base models. I'm betting on the latter.