Every AI article I'm reading eventually lands on the same question: are coding agents going to replace engineers? Claude Code and Codex write real code now, so engineers must be next, right?
Maybe. But that's not what I'm seeing in my own work. The first casualty in my world wasn't an engineering job. It was PowerPoint.
Think about what we actually produce
I'm a TPM. Most of what I make in a week isn't code, and honestly it isn't specs either — it's stuff for conversations. A customer call to walk through the roadmap. A leadership review: updates, risks, dependencies, outcomes. A stakeholder session on last month's incidents and what we're doing about them over the next four weeks.
For the last thirty years the answer to all of these was the same: open PowerPoint. Or a doc, if your company was a Confluence or Google Docs kind of place. Or maybe a new generation tool like Notion.
Lately I skip all of that. I give Claude the context — the data, the risks, who's going to be in the room — and get back a purpose-built HTML page.
The customer clicks into the part of the roadmap they actually care about instead of sitting through my slide order. Nothing gets squeezed into a corporate template. And when someone asks mid-meeting, "can we see this by team instead?" — I regenerate it, sometimes before the call is over.
Recently we rolled out a big new capability and had to enable our customer-facing teams. Not generic enablement — account-focused. What has this specific account complained about, and what's our plan for them. We tried the classic combo first, a generic enablement deck plus account-specific sheets. It fell flat. The picture was scattered across two artifacts and neither tool would bend.
So I generated HTML instead — fed in the account context, set up tabs for how each conversation would actually go — and it just worked. The clarity it gave every person in the room, I honestly wasn't expecting.
Why the deck is losing
The deck survived thirty years for one reason: custom was expensive. PPT was the deal we all took — generic, but cheap.
Coding agents broke that deal.
And what replaces it is a weird new thing: disposable software. These pages are single-use. Built for one call, never maintained, forgotten after. Software with the lifespan of a meeting. Decks were disposable too, of course — we just never thought of them as software.
Where the deck still wins
I don't want to oversell this. Decks have survived because they're a shared format. Anyone can forward one, edit slide 7, pull three of them into a QBR, dig one out of the archive next quarter. My HTML page is a snowflake — nobody else can easily edit it, versioning is a mess, and plenty of execs still want their sixteen slides in the standard template. So for now this lives in working sessions, walkthroughs, readouts. Meetings where the artifact has exactly one job: make this discussion go well.
The skill underneath
This connects to my earlier note on AI-Native Roles.
Boris Cherny talks about roles dissolving into modes of value, and one of his modes is the Prototyper.
Zeb Evans says the scarce skills now are direction and review, not execution. I'm watching both play out at slide level.
Slide-craft — layout, build order, story-by-bullet — matters a little less every month. What matters now is context-craft: whoever briefs the agent with the sharpest context gets the sharpest artifact. Prototyping isn't an engineer-only thing anymore. It's a much needed skill now.
Why this matters to me
My default deliverable changed in a matter of months, and my prep time moved with it — less formatting, more thinking, because the artifact is only ever as good as the context I feed it. It also changed the question I ask about teams. Not "what tools do you use," but "what artifacts do you make, and who's allowed to make them?"
When the answer is "anyone with context" — that's an AI-native team.