One Claude ships Docs and Slides: where custom document generators still defend

I maintain a handful of deck and document generators: JSON spec in, deterministic renderer, PDF and HTML out, with geometric validation gates that fail the build if a title overflows or a table walks off the page. On September 16 Anthropic announced that Claude Chat and Cowork are merging into one Claude, with native Docs and Slides in beta and Design running inside the chat. My first reaction was a small, unglamorous flinch. My second was to write down what, exactly, I'd been selling myself.

Here is what was announced, per the coverage in The Verge and Engadget. Claude Docs drafts a document in the conversation and exports to Google Docs or Word. Claude Slides exports to PowerPoint or PDF. Claude Design now lives in chat instead of a separate surface. Rollout goes to Pro and Max on web, desktop and mobile over the coming weeks, and Enterprise gets at least 30 days of notice. I haven't used any of it yet, so everything below is reasoning about the shape of the thing, not a review.

What the platform now gives away

Being able to produce a decent deck is no longer a skill or a product. It is a default. A person who used to ask me for a “quick presentation about X” can now get a plausible one, in their own chat, with an export button. The generation step, the part that once justified a custom pipeline, has been absorbed into the surface everyone already has open.

That also removes a whole layer of friction I underrated. Custom generators live outside the conversation: you assemble a spec, call a script, open a file. Native Docs and Slides skip the handoff. For the first draft, the throwaway internal deck, the meeting summary that nobody will archive, I expect the native path to win, and I'll use it myself.

Where a custom generator still earns its keep

Three places, and I'd rather name them precisely than wave at “quality”.

Brand consistency is the first. My generators encode a visual system: fixed palette, fixed type, fixed grid, fourteen slide types in one of them, and every output looks like it came from the same hand. A general model prompted with a style description gets close, and close is exactly the problem, because drift is invisible until someone lays two decks side by side. I don't know how well native Slides holds a brand across fifty generations. If the platform grows a proper template mechanism, this argument weakens a lot.

Determinism is the second. Same spec in, same bytes out. That sounds pedantic until a client asks why page 7 changed between Tuesday's draft and Thursday's, and the honest answer for a sampled model is “because it was sampled”. A renderer has no such excuse. It is a boring property, and regulated or contractual documents lean on boring properties.

Validation is the third, and the one I'd defend hardest. My deck generator runs twelve gates, the guide generator thirteen, the one-pager eleven. They check geometry: overflow, collisions, minimum font sizes, orphaned headings. These are properties you can test with code rather than judge with taste, so they either pass or they don't. A model reviewing its own slide by eye can miss a clipped line that a bounding-box check catches every time.

The moat is not that I can make a deck. It is that I can prove this deck is the deck I meant to make.

The uncomfortable arithmetic

Suppose a client asks why they should pay for a custom pipeline when Claude does it natively. The answer has to survive a fair comparison. If they produce four decks a year, none branded, none audited: they shouldn't. Buy nothing, use the built-in. If they produce forty a quarter under a brand guideline, with a compliance reviewer who needs the same layout every time, the pipeline pays for itself in review hours alone. The crossover is somewhere between those cases, and I can't give you an honest number for it without measuring native output on their actual templates.

There is an in-between design I find more interesting than either extreme: let the native surface do the drafting and let a deterministic layer do the rendering and checking. Content from the conversation, layout from the spec, validation from code. That keeps the part where a model is useful and removes the part where it is unreliable. I wouldn't call it settled, since it depends on what the native exports let you intercept (a Word file is a lot easier to re-render than a chat bubble).

My plan is dull. Wait for the rollout to reach my account, generate the same three documents both ways, and run my existing gates over the native output. If it passes, I'll happily stop maintaining a few things.