Over the past two or three years, AI doing PPTs has become increasingly hot. It seems like every few months, a new product pops up, telling you it can produce a presentation deck in minutes and even make it look quite good.
But if you actually try a few, you'll find a bunch of problems. It doesn't always seem to work as advertised, producing a ready-to-use PPT in seconds.
And I've found that although they all appear to be doing "AI-generated PPTs," they are actually not doing the same thing at all.
Some products are more like making web pages, some are more like template tools, some generate the visual result first and then patch in some editing capabilities. Recently, some products have started moving towards the native PowerPoint workflow.
Mixing these directions together in discussion easily leads to more confusion.
So it's better to take a step back and first break down the problem: What are the main approaches for AI doing PPTs today? What problems do they each solve, and where do they get stuck?
A PPT is Not as Simple as "Arranging a Few Pages of Text"
Some people might think a PPT is just about splitting content into a few pages and then doing some layout.
But if you've seriously made a few, you know that's not the case.
On the surface, a PPT looks like content production, but in reality, at least three layers are stacked together.
The first layer is, of course, the content itself. You need to know how a presentation should be told, how to divide chapters, which information should be on its own page, and which content should be condensed into a chart or bullet points.
The second layer is the page. How to place text, how to place images, how to create hierarchy between titles and body text, whether there's enough white space, and if the information density is too high.
The third layer is delivery. What you make isn't just something that "looks like a PPT"; what you ultimately hand over must really be a .pptx file. This file might also need to fit a company template, be provided to other colleagues for further collaborative editing, and be sent to clients.
This third layer is crucial and determines why AI doing PPTs ultimately branches into completely different technical routes.
Because some people are solving "how to quickly generate pages," while others are solving "how to make this file actually usable in PowerPoint in the end."
These two things seem close, but in reality, they are quite far apart.
The First Path: Forget PPT for Now, Essentially Make a Web Page First
I think the easiest path to understand is treating a PPT as a kind of "split-screen display content."
That is, it doesn't first think about how PowerPoint internally stores text boxes, shapes, images, and slide masters. Instead, it treats each page as a page. There's an order between pages, visually it looks like slides, and it can switch page by page during presentation, but the underlying logic is closer to a web page than an Office document.
Why this route emerged first and was the first to seize the high ground of AI PPT products is actually easy to understand.
Because web pages are naturally well-suited for display. For large models, generating structured content, styles, and layouts is generally much easier than directly tackling a complex document format. You can usually get it to make the page first; getting it to directly generate a complex PowerPoint file that can be naturally edited later is on a completely different level of difficulty.
So the advantages of the web page route are obvious:
It usually produces drafts quickly and is visually quite flexible. Often, at first glance, it even looks more comfortable than a traditional PPT. Especially for the task of "I need something presentable first," it has a strong advantage.
But the problem also lies right here.
Web pages and PPTs look similar, but that doesn't mean they are the same thing.
What you see on a web page is a laid-out page, but what's needed in PowerPoint is a bunch of objects that can be further modified: text must be individually editable, images must be movable, shapes must have layers, and layouts must connect to the slide master. A "page" on the web doesn't necessarily translate naturally into these things in PowerPoint.
So many web-route products are very suitable for "making something to show people," but when it comes to "making something for people to edit afterwards," things start to get complicated.
This isn't to say it's bad, but rather that the problem it set out to solve wasn't exactly the same from the start.
It's more like creating a new type of display tool, rather than working within the PowerPoint system.
The Second Path: Don't Give AI Too Much Freedom, Constrain It with Templates First
There's another route, and its thinking is almost the opposite. This route is also the most common one taken by AI PPT tools currently; almost all domestic AI PPT products follow this approach.
Since generating everything from scratch is unstable, it's better to fix the big things first: layouts, fonts, colors, components, cover styles, title hierarchies—control these with a template system first. Then the AI is responsible for filling in the content, making some local adjustments, and helping you get a decent first draft faster.
Products like Gamma are basically the most typical examples in this direction.
This route is often underestimated because it doesn't sound "sexy" enough.
People think, templates? Isn't that just advanced fill-in-the-blanks? It sounds less intelligent.
But from a product perspective, it's actually very pragmatic.
Because in real-world usage, many people don't need a wildly creative design system. What they need is a result that is stable, error-free, looks professional, and can align with brand guidelines. Especially in a corporate environment, a PPT is never just about expressing content; it's also part of the organizational style.
So the biggest advantage of the template route is not creativity, but stability.
It doesn't pursue having the AI reinvent the layout every time; it pursues:
Given a piece of content, can I reliably help you place it into a pre-validated visual framework? The title shouldn't run off, font sizes shouldn't be chaotic, the cover shouldn't be too ugly, and the whole thing shouldn't look like it was hastily cobbled together.
Of course, its boundaries are also very clear.
Once the template feel is too strong, the result easily looks "like a template." If you want to do something very unique, with significant structural changes, or heavily reliant on rhythmic design, template tools might not satisfy you.
But a more serious problem is that the AI cannot perfectly match your presentation content. The key point you want to emphasize in this section might be one thing, but your PPT is filled with something else.
The vast majority of people making PPTs often just buy a template from a template site and then fill in the blanks based on the content they want to present. This route essentially lets AI replace you in completing that fill-in-the-blank step.
Ultimately, in many scenarios, what people want isn't creative expression, but to efficiently produce a version that can get through the presentation.
The Third Path: Make the Page Beautiful First, Patch Up Editing Capabilities Later
There's another common term in the industry, called "image PPT" or a more visual-draft-oriented approach.
Especially after the release of Google's Banana model, this route's popularity surged.
Looking at the product results, this type of solution clearly leans more towards "making this page beautiful first." Because its essence is generating images one by one through an image generation model.
The advantage of this approach is very direct.
It's very suitable for making pages that have strong visual impact at first glance, especially covers, poster-like pages, and visual pages with lower information density, often making them stand out more easily.
Because it prioritizes the result.
First, create the visual feel of this page, make it work as a whole, and then find ways to let users modify things on it.
The problem is also obvious:
Visual "completeness" does not equal editing "convenience."
A page looking complete doesn't mean it's easy to disassemble, modify, or move things around in PowerPoint. Truly achieving both design sense and a native editing experience is actually quite difficult.
So this route is about first turning the page into a good result, and then trying to patch back the capabilities needed by office software.
Someone is Starting to Seriously Tackle "Native PowerPoint"
If the previous routes were more or less circling around the level of "how to make a page," a more noteworthy recent change is that some products are starting to move towards the PowerPoint system itself.
Not exporting a barely openable .pptx, nor making a page that looks like a PPT and then converting it, but starting to handle the truly troublesome and truly critical parts of PowerPoint:
Templates, slide masters, existing files, partial editing, native objects, charts, shapes, layout inheritance.
On this point, the most obvious recent signal is Claude's moves in PowerPoint.
I think this is important not because "it can also do PPTs now," but because it's starting to touch a link that many people knew was important in the past but was always hard to do well:
You don't conjure up ten pages from scratch for me; instead, you need to enter my existing workflow and continue from there.
For example, I already have a company template, can you read it?
I already have a deck that's half done, can you just fill in three of the pages?
I only want to change page 7 now, without messing up the formatting of the previous 6 pages. Can you reliably modify just this one page?
I want to organize a section of bullet points into a truly standard, natively editable chart, not just an image. Can you do that?
These questions are the real key to determining whether "AI PPT can move into the office scenario."
Because what people ultimately want has never just been "fast automatic draft generation."
What everyone wants is: to let AI complete the work in a more controllable and precise way.
Why "Editability" Has Recently Been Re-emphasized
A few years ago, when "directly generating PPTs" was mentioned, many people had a poor impression.
This is normal. Because back then, many things produced often looked somewhat decent when opened, but became a mess when edited, skewed when dragged, and broke when switching templates.
Frankly, it's not that people didn't know this path was valuable, but that it was genuinely hard to do well at the time.
The PPT format is inherently very complex. What you see is one page, but underneath it's actually objects, layers, positions, styles, placeholders, slide masters, and themes stacked together. If just one part is handled unstably, the user will perceive the problem immediately upon use.
But the reason this has started to become interesting again recently isn't because PPTs have become simpler, but because the tech community is also helping AI develop various Agent capabilities.
Models are now better at handling structures and also better at making local modifications to existing content.
And product implementation is no longer just about having the model "write a file out of thin air," but starting to have it read existing templates, read the current page, understand the existing layout, and then continue writing on that basis.
This is actually very important.
Because what truly starts making AI usable is often not "how astonishing the generation capability has become," but that it finally no longer works in a vacuum. It starts to attach itself to real software and real workflows, and only then can many previously unstable things slowly become stable.
So rather than saying the current trend is "models have finally learned to directly write PPT files," it's better to say:
Models, combined with deeper PowerPoint integration, have finally started to make native editability a direction that can be seriously discussed, moving from an ideal towards reality.
These Paths Likely Won't End Up as Just One
I believe the technological evolution of AI PPT will not ultimately converge on any single one of the routes mentioned above. The greater likelihood is a move towards "hybrid": templates provide the safety net, web pages handle deep customization, image generation models produce key pages visually first, and when it comes to the actual delivery, collaboration, and further editing in PowerPoint, it will honestly lean towards native objects and workflows.
User demands are actually extremely simple: fast drafting, stable results, smooth secondary editing, and delivery that doesn't cause trouble for others. When technology returns to business, the debate over routes becomes less important. The real watershed is: are you just "flashy" in the first step, or can you truly take over the entire chain of "generation-editing-collaboration-delivery"?
After three years, AI PPT has passed the "showing off skills" stage and officially entered the deep waters of "entering real workflows." Compared to stunning demos, I care more about whether I can get straight to work after generation.
Be a bit faster first, then a bit more stable, and finally, don't leave me to clean up the mess.