Blog

Engineering | 9 min read | 2026-04-25 | Updated 2026-04-26 | By Variant Team

How Engineering Teams Can Vibe Code Technical Presentations

A practical guide for engineering teams to vibe code technical presentations using Claude Code, MCP, and code-native slides you can hand-edit.

Author: Variant Team. Variant is built by a small team working on HTML-native presentation tools, MCP workflows, and agent-editable decks.

Engineering teams can vibe code technical presentations by prompting an AI coding agent to generate the deck as HTML and CSS, then editing slides directly on a visual canvas or in code. The combination matters: the prompt gets you 80% of the way there fast, and hand editing handles the parts AI usually botches (exact metrics, in-house jargon, the diagram with three boxes that has to look right).

That's the short version. The longer version is below, with the workflows engineers actually use, why a code-native deck beats a regenerated one, and a few prompts that hold up under real architecture reviews.

#Quick answer: what does it take?

You need three things: an AI coding agent (Claude Code, Cursor, Codex, whatever you already pay for), a presentation tool that speaks code instead of drag-and-drop XML, and the discipline to edit the output instead of re-prompting until something looks right.

Variant fits the second slot. It's Claude Code's presentation canvas. Slides are standard HTML and CSS. You can edit them visually on a canvas, drop into a code tab, or send instructions through the MCP server. The canvas and code stay in sync, so you don't pick a side.

#Why code-native slides fit technical content

Architecture reviews, API demos, and launch plans all share a problem: the content has structure that PowerPoint doesn't really respect. A box-and-arrow diagram of your service mesh isn't art. It's a graph with labels, and you'd rather express it as one. A latency chart isn't a screenshot. It's data.

When a slide is HTML, you get:

• Real layout primitives (flex, grid) instead of dragged rectangles
• Fonts and spacing you can tune by editing values, not nudging
• The ability to paste in a Mermaid diagram, an SVG, a code block, or an embedded chart and have it render the way you'd expect on the web
• A file you can grep, diff, and review like any other artifact

That last one matters for engineering culture. Decks become reviewable. A staff engineer can look at a PR and actually see what changed, rather than opening a binary blob in a desktop app.

#Why hand editing after AI generation matters

AI generation is great at the first pass. It's bad at the things that ruin a technical presentation:

• The p99 number is off by an order of magnitude
• The diagram labels your service "auth-svc" when internally everyone calls it "gatekeeper"
• The headline says "scalable" when your team has banned the word
• The footer doesn't have the right release tag

Generic AI slide tools handle this by regenerating the whole slide. You change one word and the layout shifts. The colors drift. The chart you finally got right comes back wrong. You end up babysitting a generation loop instead of editing a document.

The fix is boring and correct: edit the actual slide. Click the text. Change the number. Move the box. If it's faster to do in code, open the code tab and adjust the value. If you want Claude Code to make the change, point at the selection and say what to fix. Don't regenerate the slide.

This is the difference between AI-generated slides and AI-coded decks. One produces output you fight with. The other produces a document.

#Five workflows engineering teams actually use

#1. Architecture review

Goal: walk a wider group through a system change without the meeting collapsing into "wait, what does that arrow mean?"

Workflow:

• Paste your design doc into Claude Code with: "Generate a 12-slide architecture review from this RFC. Use a system diagram on slide 4 with the four services I mention, and add a slide showing the failure modes table."
• Claude calls deck.create, then slides.batchUpdate to populate the diagram and tables.
• Open the canvas, fix the service names, swap the colors to match your team's convention, drop in the latency numbers from your dashboard.
• Use slide.edit (or just hand edit) to tighten the failure modes slide.
• Export to a single self-contained HTML file and drop it in the doc.

The diagram lives as HTML and CSS, so when someone asks "what if we add a queue here?" you add a div and re-run the review.

#2. Product update

Goal: monthly or weekly summary that doesn't take half a day.

Workflow:

• Pipe your changelog or release notes into a prompt: "Build a 6-slide product update covering the three launches this month. Pull the metrics from this CSV."
• Variant generates the deck. You edit names, fix the screenshots, and replace any AI-paraphrased copy that lost its meaning.
• Export to PDF for the email, HTML for the wiki, PPTX if leadership still wants it in that format.

#3. Launch plan

Goal: a deck the team can review before a release.

This is where reviewability earns its keep. The launch plan deck lives in the repo as an HTML file. Engineers comment on the actual content. The on-call section gets edited like any other doc. When the launch happens, the deck becomes the artifact, not a one-off slide deck someone made and then lost.

#4. API demo

Goal: show how an endpoint works without opening 14 tabs.

Workflow:

• "Create a demo deck for the /search endpoint. Slide 1: what it does. Slide 2: request shape. Slide 3: response shape. Slide 4: a curl example. Slide 5: failure cases."
• Code blocks render the way they should because the slide is HTML. No more screenshots of code.
• During the demo, you can edit the example live. Change the parameters, hit save, and the slide updates.

#5. Demo day or investor update

Goal: tell a story with numbers that aren't lies.

Workflow:

• Feed in your KPI dashboard or CSV.
• Prompt: "Generate a 10-slide investor update. Use the actual numbers from this file. Include a chart of MRR by month, a chart of active users, and a slide on what we're doing next quarter."
• Hand edit every number. Yes, every number. AI hallucinates digits.
• Export to HTML for the data room and PDF for the email.

#A small prompt that holds up

Here's a real one that works for an architecture review. It's nothing magical, but it shows the pattern:

Use the Variant MCP server to create a 10-slide deck called
"Notification Service v2 Review". The slides should cover:

1. Title + meeting goals
2. Why we're rebuilding (3 bullet pain points)
3. Current architecture diagram (4 services, labeled)
4. Proposed architecture diagram (5 services + queue, labeled)
5. Data flow walkthrough
6. Migration plan with phases
7. Risks and mitigations table
8. Rollout timeline (Gantt-style)
9. Open questions
10. Appendix: links to RFCs

Use a clean dark theme with monospace headers. Keep diagrams
as HTML/CSS, not images. Use my team's colors: primary
#3D5AFE, accent #00E5FF.

The model calls deck.create, then slides.batchUpdate for the bulk content, then slide.preview to confirm the diagrams look right. You open the canvas and fix the rest.

#Variant's MCP tools, briefly

Variant exposes 18 MCP tools to coding agents. The ones engineering teams hit most:

Setup is OAuth or a scoped bearer token. You point your Claude Code config at the Variant MCP server, authenticate, and the tools show up in your agent.

#Export formats and when to use which

The single-file HTML format is the one to default to. It opens anywhere, you can inspect it, you can host it on any static site. If a colleague asks "where's the deck?" you can paste a URL.

#Why this beats generic AI slide tools for technical content

Generic AI slide tools optimize for marketing decks. They generate a glossy result, you regenerate a slide when something is wrong, and after enough rounds you give up and accept what you've got. That's fine for an internal kickoff with a stock photo of a mountain.

It's not fine for an architecture review where the diagram has to be right.

The difference comes down to:

1. Editability. Code-native slides are editable like a webpage. Generic AI tools make you fight a generation loop.
2. Portability. A single HTML file goes anywhere. Most AI slide tools lock you into their viewer or export blurry PPTX.
3. Review. A diff on an HTML deck is a real diff. A diff on a binary slide file is a guess.
4. Control. When the AI gets a number wrong, you fix the number. You don't re-prompt the slide.

Engineering teams already work in this model for everything else: docs, code, configs. Slides should match.

#How to test the workflow in about 10 minutes

1. Pick a real technical topic you already understand.
2. Ask your coding agent for a five-slide deck with a specific audience and goal.
3. Keep the first draft intentionally small.
4. Edit the parts the AI got wrong by hand.
5. Export to the format your audience needs.

That's the loop. Generate, edit, export. The faster you stop trying to make AI do the whole thing, the faster you get a deck that holds up.

#Related reading

• Create a Presentation with Claude Code: Full Workflow
• Vibe Code Your PowerPoints with HTML Slides
• How to Version Control AI-Generated Slide Decks

#FAQ

#Can I use Variant with Cursor or Codex instead of Claude Code?

Yes. Any agent that supports MCP can call Variant's tools. Claude Code is the smoothest fit because Variant is built around it, but the MCP server is the integration point, not the IDE.

#Do I have to write code to use this?

No. The canvas is a visual editor. Code is there when you want it. Most engineering teams switch back and forth depending on the task. Tweaking copy or moving a box: canvas. Updating a chart's data or fixing alignment math: code.

#What if the AI generates something I don't like?

Edit it. That's the point. Don't regenerate the whole slide for a one-word fix. Click the text, change it, move on. If you want a bigger change, ask the agent to edit that specific slide using slide.edit rather than starting from scratch.

#Can I version control the decks?

Yes. Export to HTML or JSON and commit it. Variant also keeps version history through deck.versions.list and deck.version.restore, so you can roll back inside the app too.

#How do I handle sensitive data in metrics decks?

The deck is just HTML. You control where it lives. Export the HTML, host it where you host your other internal docs, and don't paste real customer numbers into a prompt if your policy says no.

#Will this look good enough for an investor deck?

Yes, if you put the work in. AI-generated decks need a human pass for credibility. The benefit of code-native slides is that the human pass is fast: you're editing a real document, not fighting a generator.

#Wrap-up

The right way to vibe code technical presentations is to treat the deck like code: generate a draft, edit by hand where it matters, version it, export it where it's useful. Variant's canvas plus Claude Code over MCP gives you the toolchain to actually do that.

The important part is the shape of the work. The agent gets you moving. The source stays editable. The final pass still belongs to someone with taste.