Why Your LLM Slides Suck (And What To Do About It)

You’ve done this. I’ve done this. Everyone with access to Claude or ChatGPT has done this.

“Make me a 10-slide deck for the client presentation on Thursday.”

And what you get back is… technically a presentation. White background. Black text. Maybe a blue title if the model is feeling creative. No logo, no brand colors, no layout that matches anything your company has ever produced.

It looks like a homework assignment from 2004.

The weird thing is, the content is usually fine. Sometimes excellent. LLMs can structure an argument, find the narrative arc, write tight headlines. They’ve gotten scary good at the writing part of presentations.

The rest of it? The layout, the visual hierarchy, the way a well-built deck actually looks and flows? Not so much.

Everyone knows about this part, nobody has an answer for it: every company with more than 50 employees has a PowerPoint template. A .potx file sitting on SharePoint, lovingly crafted by some design agency three years ago, with master slides and approved color palettes and a very specific way the logo sits in the bottom-right corner. Your brand team will reject slides that don’t use it. They should.

No LLM can use that template. Not really. Not in any way that would survive a five-second glance from your marketing department.

What Exists Today

When an LLM generates a .pptx file, it’s using one of three methods under the hood. They all suck in different ways.

Each deserves a closer look.

Method 1: Raw OOXML

Token-burning XML generation with brutal failure rates.

A .pptx file is just a ZIP archive. Rename it to .zip, unzip it, and you’ll find a bunch of XML files, some relationship manifests, and maybe some embedded images. It’s all XML under the hood.

This format is called OOXML (Office Open XML), and it’s governed by ECMA-376.

The spec is roughly 6,000 pages long.

Six thousand pages. The HTML5 spec is about 1,200. The entire Lord of the Rings trilogy is around 1,200 pages. You could read Tolkien five times before you finished the OOXML specification.

So naturally, someone thought: “Let’s just have the LLM output raw XML!”

A single slide with a title, a subtitle, and a couple of shapes runs about 500 lines of XML. Maybe more if you want, you know, colors. A modest 10-slide deck burns through 50,000 tokens just on the XML output alone… before you even count the prompt, the reasoning, the planning. You’re paying for the model to write angle brackets.

And it’s unbelievably fragile. One wrong namespace prefix. One missing relationship entry in _rels/.rels. One slightly malformed a:bodyPr element. And PowerPoint gives you that helpful little dialog:

We found a problem with some content in presentation.pptx.

No line number. No hint. Just… “a problem.” Good luck.

LLMs hallucinate OOXML structure constantly. They’ll invent namespace prefixes. They’ll nest elements in impossible orders. They’ll reference slide layouts that don’t exist. The XML looks plausible (it’s a language model, making things look plausible is literally the job) but PowerPoint’s parser is ruthlessly strict. Plausible isn’t good enough.

High token cost, low visual quality, high failure rate. Hard to recommend.

Method 2: python-pptx

The standard library for template work, but the project has stalled.

This is what most people reach for, and for good reason. python-pptx is the standard Python library for creating PowerPoint files. About 2,200 GitHub stars. It works. It’s documented. Most LLM-powered slide tools are built on it.

The main selling point: it can load existing .pptx templates. You hand it your corporate template, reference the slide layouts by name, drop content into the placeholders, and out comes a file that actually looks like it belongs to your company.

But.

The last release (v1.0.2) was August 2024. There are 439 open issues. 77 open PRs gathering dust. SBB (Swiss Federal Railways, not a small outfit) filed a formal dependency risk notice because they’re running it in production and… nobody’s home.

The architectural limitations hit you fast once you try anything beyond basic text-in-placeholder work. You can’t add new layout types programmatically (Issue #413, open since 2018). If your template has a “Two Content” layout and you need a “Comparison” layout that doesn’t exist in the file… you’re stuck. The library manipulates what’s already there. It doesn’t understand PowerPoint enough to create new structures.

It’s also Python-only. If you want the user to iterate on slides in a browser (where most LLM interfaces live), you need a server round-trip for every regeneration. No quick local previews. No client-side tweaking.

Best option for simple template fill-in. “Put Q3 numbers on slide 4.” That works. Anything more creative with a complex template and it falls apart. And building on a library with no active maintainer is a risk.

Method 3: PptxGenJS

Best standalone visual quality, but can't import corporate templates.

PptxGenJS is the best JavaScript library for generating PowerPoint files. About 2,400 GitHub stars, active development, solid API. It runs in the browser and Node.js. Anthropic’s own official pptx generation skill uses it.

The API is pleasant. You describe slides in terms of objects with properties (position, size, color, font) rather than wrestling with XML namespaces. You can create complex layouts, add charts, embed images, control every visual detail. The output quality is the best of the three methods by a comfortable margin.

The catch: PptxGenJS cannot import existing .pptx templates.

Issue #712. Users have been asking for years. The maintainer (one person, doing heroic work) explicitly declined to implement it. Fair enough… parsing the full OOXML spec to import arbitrary templates is a massive undertaking. But the consequence is real.

Every presentation PptxGenJS creates starts from a blank canvas. You can approximate your corporate branding by specifying the right hex colors, the right fonts, the right logo placement. But it’s a fresh guess every time. If your template updates (new logo, new accent color, new footer format), someone has to manually update the code. There’s no “just load the template” escape hatch.

Best standalone visual quality, worst corporate integration. Your slides look good in isolation and wrong next to everyone else’s.

The Microsoft-shaped hole in all of this

Microsoft wrote the 6,000-page spec. They own PowerPoint. They built the ecosystem every Fortune 500 runs on. They have not shipped a sane API for creating presentations. Not once, in 30 years.

The Open XML SDK exists (C#/.NET), but it’s low-level XML manipulation wearing a thin object-oriented disguise. There is no Microsoft.PowerPoint.Create(). No “add a slide that looks like layout #3 from the template.” You get to manipulate XML nodes and feel grateful for the privilege.

So the entire ecosystem… every tool, every startup, every internal hackathon project… rests on python-pptx (abandoned), PptxGenJS (one maintainer), and Apache POI (Java, mostly Excel). Three open-source projects. Combined bus factor of maybe four people. For a format used by hundreds of millions of workers.

Meanwhile, Copilot in PowerPoint uses internal APIs that Microsoft doesn’t expose to anyone else. And even Copilot can’t do complex data-dense slides properly… ask it for a chart and you’ll get a suggestion to “add a chart.” Thanks.

The Broader Landscape

There’s actually a lot of activity in this space. HTML-to-PPTX pipelines, Anthropic’s Claude in PowerPoint add-in, markdown-to-slides tools, commercial SaaS (Templafy, Beautiful.ai, Slidebean), your company’s internal AI chatbot, academic research papers. None of it solves the template problem.

The full landscape survey (expand for details on each approach)

The HTML→PPTX pipeline. Probably the most creative approach. tfriedel’s claude-office-skills pioneered a workflow where Claude designs slides as HTML/CSS (720pt x 405pt for 16:9), renders them in a headless browser via Playwright, then a custom html2pptx.js library walks the DOM and maps CSS properties to PptxGenJS API calls. It’s clever… backgrounds become shapes, flex positioning is preserved, text elements map to text boxes. Anthropic’s own official pptx skill borrows from this pattern.

The trade-off: every iteration cycle launches a headless Chromium instance. The CSS-to-PPTX mapping has real limits (no CSS gradients, no custom fonts, text must be in semantic tags or it’s silently dropped). And the HTML canvas defaults to 720x405pt (10” x 5.625”), which may not match corporate templates that use 13.33” x 7.5” widescreen layouts. Still, for visual quality on a blank canvas, it’s probably the best available approach for from-scratch generation.

Claude in PowerPoint. Anthropic launched this as a Microsoft 365 add-in in February 2026. Three modes: blank-deck builder, pinpoint editor (modify slides while preserving formatting), and a bullet-to-visual converter. It generates native PowerPoint objects, which is a step up from most tools. But it’s in beta, has a 30MB file limit, and… it’s an external add-in. IT departments that block third-party add-ins will block this too, even if the same company is paying for Claude licenses elsewhere. The provisioning path for add-ins and the provisioning path for API access are completely different animals in enterprise IT.

PPTAgent (2025 research). Uses a two-stage approach: analyze reference presentations to extract functional slide types, then generate new slides using an HTML intermediate representation. Interesting idea… emulate an existing style rather than start from scratch. But it requires a reference presentation and the pipeline is complex.

Marp, Slidev, reveal.js. Markdown-to-slides tools. Marp can export to PPTX, but it creates slides as images (not editable). Slidev is Vue-based, web presentations only. reveal.js does HTML presentations with PDF export. None of these produce editable .pptx files that your colleagues can open in PowerPoint and modify normally.

Pandoc. Converts Markdown to .pptx using a reference template. Decent for text-heavy slides, limited control over layout. If your slides are mostly paragraphs and bullet points, it works. If you need data tables, charts, or anything visual… it doesn’t.

Commercial SaaS tools (Templafy, Beautiful.ai, Slidebean, and others). Smaller players, some of which your company may be running a pilot with. They solve pieces of the problem but are unlikely to be widely deployed across a large enterprise. Yet another tool to procure, provision, and get approved.

Your company’s internal AI chatbot. Most large companies have deployed some version of ChatGPT, Gemini, or Claude internally by now. Many of these include a slide generation feature. In practice, they tend to mirror the same limitations as the consumer versions… text-heavy output, no template awareness, basic formatting. The enterprise wrapper doesn’t magically solve the design problem.

Google Slides API. Actually pretty good for programmatic creation. Supports templates, placeholders, batch updates. But it locks you into Google’s ecosystem, and most enterprises standardize on Microsoft.

Every approach either can’t use your corporate template, can use it in limited ways, or requires an environment your IT department won’t approve. That last part is worse than you think.

The Corporate Firewall Problem

So let’s say you’re a consultant at Deloitte, or a PM at some Fortune 500, and you’ve heard the good news about AI-generated presentations. You want to fire up Claude and start generating decks. Every approach hits the same wall: your corporate laptop isn’t yours.

Cowork + Plugins

Anthropic keeps pushing Cowork as the thing for “non-technical knowledge workers.” It spins up a full Linux VM inside Hyper-V on your Windows machine. To get there, you need Hyper-V enabled at the BIOS level, MSIX sideloading permissions, the Host Compute Service running, admin elevation, and roughly 10GB of disk for the VM bundle.

Now think about your corporate laptop.

Group Policy blocks Hyper-V on workstations. You don’t have admin rights. Sideloading is disabled. IT departments have reasons for these restrictions… letting random employees spin up hypervisors on domain-joined machines isn’t exactly conservative security practice.

And that’s just the happy path. The actual path is worse.

The bug parade (expand for the grim details)

The issue count isn’t the point. These are structural problems, not things you patch. Split-account environments (standard user + separate admin, the kind every enterprise uses) break the installer. Virtualization detection fails even when Hyper-V is enabled. The VM’s Hyper-V configuration can break WSL2 networking in ways that require manual HNS cleanup.

Then there’s VPN. Every corporate machine runs a VPN. Cowork picks the wrong network adapter, and the documented “fix” is to disable your VPN. On a corporate machine. Where the VPN is mandatory and enforced by policy.

One Reddit user spent a full day troubleshooting: if someone who debugs Hyper-V networking as a hobby spent hours in PowerShell diagnosing this, a typical knowledge worker isn’t getting through it.

Cowork is positioned at knowledge workers… people who make slides and write reports. Setting it up requires a level of Windows systems expertise that most of those workers don’t have. It might get better (it’s still relatively new), but the gap between target audience and required technical skill is wide.

Oh, and Windows Home doesn’t support Hyper-V at all. That’s not just a corporate issue… a lot of personal laptops ship with Home. If you were hoping to try Cowork on your own machine before pitching it at work, you might be out of luck there too.

The security angle

Even if you got Cowork running (you won’t, but hypothetically), there’s a deeper issue. Whatever permissions the worker has, the AI agent has. Your corporate account can access SharePoint, internal wikis, email, maybe financial systems. Cowork’s VM inherits all of that. A Citrix blog post made the case that everyone’s worrying about the wrong AI risk… not secrets leaking into training data, but AI agents executing actions with the worker’s permissions. Forwarding confidential docs, falling for prompt injection, deleting things the worker didn’t intend. The risk isn’t exfiltration. It’s execution.

Most enterprise security teams aren’t going to sign off on an unmanaged VM with full user permissions running on domain-joined hardware. You can see their point.

Claude Code + Skills

Forget Cowork. What about Claude Code with presentation skills? There’s tfriedel’s claude-office-skills and Anthropic’s own official pptx skill. Different approach… they use libraries to generate files directly.

The requirements look more modest until you actually read them. npm and pip need to be available. Playwright browsers need to download (~400MB of Chromium). You need LibreOffice for format conversion. Poppler for PDF handling. Pandoc for document processing.

Anthropic’s own SKILL.md file casually states: “System tools (usually pre-installed): LibreOffice, Poppler, Pandoc.”

Usually pre-installed where, exactly? These tools aren’t on any corporate Windows machine I’ve encountered.

On actual corporate Windows: npm and pip aren’t installed. Software deployment is controlled by SCCM or Intune. AppLocker blocks unsigned executables. Network egress is restricted so Playwright can’t download its browser bundles even if you could run the installer.

All of these tools assume you control your own machine. In most enterprise environments, you don’t.

The Obvious Alternative Nobody’s Building

There’s something obvious that keeps getting ignored.

Every corporate Windows machine already has PowerPoint installed. No Hyper-V, no pip, no sideloading. PowerPoint exposes a full COM automation interface. You can open, create, and edit presentations in the running instance. Slide masters, layouts, themes, placeholders… the whole object model. No additional software required.

COM: The Ugly Duckling

COM (Component Object Model) is Microsoft’s automation framework from the ’90s. You can drive it from Python via pywin32, from VBA inside Office itself, or from C#. The documentation is scattered across ancient MSDN pages and random blog posts from 2008. The API surface is enormous and inconsistent.

But it works. It’s been working for 25 years. And it requires zero additional software on a corporate machine. There are a few early projects exploring this… KAIST published Talk-to-Your-Slides (May 2025), an LLM agent that edits slides via COM, and powerpoint-mcp exposes MCP tools for PowerPoint via COM. Both early-stage, but both actually work on the machines where people make presentations.

It’s Windows-only. But enterprise slide-making happens on Windows. The Mac users in the org are designers and developers who aren’t making quarterly business reviews in PowerPoint.

Office.js: The Cross-Platform Option

If you need cross-platform, Office.js is Microsoft’s official add-in framework. Works on Windows, Mac, and PowerPoint Online. Deploys as a web app with a manifest file. IT can push it through the centralized add-in catalog.

More limited than COM, but Microsoft keeps expanding it. And the deployment story is the real draw… “IT-approved add-in deployed through existing enterprise channels” sounds a lot better in a procurement meeting than “please enable Hyper-V and give me admin rights.”

So Why Isn’t Anyone Building This Properly?

The AI and LLM community is overwhelmingly Mac and Linux-first. Go to any AI meetup, any hackathon, any open source sprint. MacBooks everywhere. The people building AI tools don’t use COM because COM doesn’t exist on their machines.

COM documentation is miserable. Win32-era stuff scattered across deprecated MSDN pages and Stack Overflow answers from 2011. Compare that to python-pptx with its clean docs and pip install. Of course developers reach for python-pptx.

And there’s the stigma. VBA and COM automation have been the domain of “that one person in accounting who wrote macros” for two decades. Nobody at a YC startup wants to pitch “we built the VBA thing.”

Finally, there’s a fundamental mismatch. The people building AI slide tools are developers who use Keynote or Google Slides and think PowerPoint is quaint. The people who desperately need better corporate slides are consultants, PMs, and analysts who couldn’t install a Python package if their bonus depended on it. These two groups don’t overlap, don’t talk to each other, and don’t understand each other’s constraints.

The developers build what works on their machine. The consultants can’t run what the developers built. The gap persists.

The Solution: Front-Load the Template Work

So: generating templates on the fly doesn’t work, burning tokens on iterative PPTX generation is wasteful, and your IT department won’t install anything. What’s left?

Doing the boring work upfront.

Extract your corporate template into code once, commit it, and reuse it. Every future presentation starts from the same foundation. The LLM’s job shrinks from “reverse-engineer a visual system while also writing content” to just “write content.” Which is the part it’s actually decent at.

The workflow

1. Extract your template into code. Take your .potx or .pptx and convert the slide masters into PptxGenJS definitions. The fiddly stuff (color scheme resolution, placeholder positioning, font mappings, background images) gets handled once. You can do this manually, have an LLM do it, or automate it.

2. Commit those masters somewhere shared. They’re just JavaScript files. Your whole team uses the same foundation.

3. Iterate on content as HTML. Instead of generating a .pptx file every time you want to see how a slide looks, have the LLM output HTML. It renders instantly in a browser. You can say “make the bullet points shorter” and get a new version in seconds for almost no tokens.

4. Export to PPTX at the end. Once the content is right, a single export pass applies the pre-built masters.

The slide masters show up in PowerPoint’s layout picker. Not as some weird programmatic hack… as actual layouts that your colleagues can use normally. Someone who’s never heard of PptxGenJS opens the deck and sees the same layout options they’d see in any corporate template.

The iteration cost matters here. If your LLM is regenerating a full .pptx every feedback round (5-10 rounds is typical), that’s thousands of tokens per cycle spent on XML serialization that has nothing to do with what the slide says. Doing the extraction once and iterating in HTML collapses most of that cost. You pay for formatting once instead of every time.

The initial extraction (parsing XML, resolving color references, mapping placeholders) is exactly the kind of tedious, detail-oriented work LLMs are good at. You’re playing to the strengths instead of against them.

What it actually took

I spent three full sessions with Claude Code trying to get a single corporate template extracted correctly. Four context windows. Hours of it and its sub-agents going back and forth. ~15 build-test-debug cycles.

On raw OOXML (why we moved away from it):

Charts are basically a non-starter. A single bar chart in OOXML is ~200 lines of XML across multiple files (chart XML, chart rels, embedded Excel data, graphic frame in the slide). Tables scale badly. Images are fragile… every image needs a file in ppt/media/, a relationship in .rels, EMU dimensions, and content type registration. Miss one step and the slide is broken.

On library choice (the python-pptx temptation):

Claude kept gravitating toward python-pptx as the “obvious” library, even after we’d already established that PptxGenJS was the target. Had to redirect it multiple times. LLMs default to what’s most common in their training data, not what’s best for the task.

On the fundamental gap (across all methods):

There’s no path today that gives you both “use the corporate template” AND “easy chart/table/image creation.”

On PptxGenJS master building (where most of the pain was):

Slide number positioning alone took ~15 debug cycles. First they didn’t show (the master XML had sldNum="0", disabling them globally). Then wrong position. Then off by 2 pixels because PptxGenJS silently adds padding to text boxes that footer elements don’t have.

Claude placed a black logo on a black background slide. Invisible. Then grabbed a 112x114px thumbnail instead of the 834x834px full-res version. Half-cropped on the end slide.

It hallucinated a “green accent line” that didn’t exist in the template and spent real time searching slide master XML for a shape it had invented. That kind of confident incorrectness is the hardest thing to catch when you’re directing an agent… it looks like productive work until you inspect the output.

On font/theme inheritance (a PptxGenJS limitation):

Theme colors weren’t being applied. Charts and text kept using Office defaults because master placeholders don’t propagate font/color to addText calls properly. Every single text element needs explicit fontFace: 'Aptos'. You only discover this after building, looking, and counting the ways it’s subtly wrong.

After first visual QA:

First generated deck had missing images, center-aligned titles that should have been left-aligned, default Office colors instead of the extracted theme, a phantom line above the footer, wrong copyright text color, and imprecise sizing throughout. Basically everything that wasn’t a text string was wrong.

8MB of conversation across all three sessions. End result: 350 lines of working JavaScript. That ratio is why this should be a one-time exercise, not something you repeat for every template.

Automating the Extraction

Directing Claude through template extraction by hand was painful enough to motivate automating it.

The mapping from OOXML to PptxGenJS is mostly mechanical. Parse XML, resolve colors, measure positions. The kind of work that’s tedious for a human and error-prone for an LLM because the details compound. So I started automating step 1.

The result is pptx-masters, a small open-source package. Still early, v0.x, plenty of rough edges. But the core idea works: point it at your .potx or .pptx file, get usable code out.

npx pptx-masters your-template.potx -o ./slide-masters

It cracks open the .pptx (just a ZIP archive), parses the theme XML, walks the slide masters and layouts, and maps everything to PptxGenJS code. The fiddliest part turned out to be color resolution… PowerPoint uses scheme color references that chain through color maps with tint and shade transformations. Getting “accent1 with 40% tint” wrong by a few points means your blues are slightly off in a way that makes brand people twitchy. So there’s proper math for that.

What you get out the other end:

• JavaScript code with your slide masters, ready to import and use
• A reference doc for AI agents describing every layout, placeholder, color, and font in a format an LLM can actually follow
• An editable style guide for your team’s design preferences (never overwritten when you re-extract)
• A preview deck so you can visually compare the extraction against the original template
• Theme data, extracted media (logos, backgrounds), and an extraction report flagging anything it couldn’t handle

Some templates are surprisingly broken. Google Slides exports, for example, sometimes set all accent colors to white. The extraction detects this and falls back to sampling colors from the master slide backgrounds instead. Weird, but it comes up more than you’d think.

There are real limitations. Gradient fills get flattened to a solid color. Grouped shapes are skipped. Animations aren’t supported (PptxGenJS doesn’t do them, so neither does this). Complex templates with lots of custom XML or embedded OLE objects will probably need manual cleanup. For the typical corporate template… logo, color scheme, half a dozen layout variations… it covers most of what you’d need. But I’d call it early days.

It works with any AI coding agent (Claude Code, Cursor, Windsurf, whatever). The agent reads the reference doc, imports the code, builds presentations. If you don’t want to wrestle with the extraction yourself, that’s what this is for.

Where This Is Going

The gap is pretty specific. Microsoft doesn’t provide a way to extract templates into code. python-pptx is stagnating. PptxGenJS can’t import templates. Between “I have a .potx file” and “I can programmatically generate presentations that match it,” there wasn’t much. pptx-masters is an attempt at filling that.

Still early, still finding edge cases. What’s next:

• Native theme colors in PPTX. The colors are correct in slides but PowerPoint’s color picker still shows defaults instead of your palette. Fixing that means writing the extracted theme into theme1.xml. Small thing, matters to the people it matters to.
• Windows testing. Works on Mac and Linux. Should work on Windows. “Should” is doing some load-bearing work in that sentence.
• Direct PowerPoint integration via COM or Office.js. Skip the intermediary format entirely. Manipulate PowerPoint in-place using the extracted theme and master data. That’s the path that actually meets enterprise users where they are.

The template problem isn’t going away. Microsoft isn’t going to solve it. The open-source libraries each solve half of it. pptx-masters is an attempt at bridging the gap. It reads a ZIP file, writes some JavaScript, and saves you from having three sessions with an LLM about slide number padding.