Using Claude to Prepare a Technical Talk Without Losing Your Voice

Preparing a technical talk takes far more time than seems reasonable: structure, pacing, examples that work live, transitions that don't sound forced. A developer published a detailed account this week on his blog about how he used AI assistance to improve a real presentation, and the post circulated on Hacker News with enough traction to warrant analysis.

What's interesting isn't that "the AI wrote his talk." It's exactly the opposite: the author keeps his voice, his arguments, and his examples. The model acts as a critical sounding board, not as a ghostwriter.

What he actually did

The workflow described in the article has several concrete phases:

• Initial structure: he dumped his raw notes and asked the model to identify argumentative gaps, not to rewrite anything. The goal was to spot what he took for granted versus what he actually explained.
• Simulated rehearsal: he described the expected audience (technical profile, time constraints, conference context) and asked for tough questions a skeptical attendee might pose. This let him prepare answers before stepping on stage.
• Transition review: he pasted the script and asked the model to flag abrupt jumps between sections, without automatically suggesting alternative phrasings.
• Density adjustment: he identified segments where the density of new concepts was too high for the allotted time.

The article doesn't specify which model he used, so we're not assuming. What is clear is that the prompt engineering applied is deliberately restrictive: the author asks for analysis, not content generation.

Why this approach differs from common use

Most tutorials on "AI for presentations" end in generated templates, automated slides, or executive summaries of dubious value. The problem with that approach is the presenter loses familiarity with their own material: when someone in the audience asks a tangential question, there's no personal context to draw from.

The described workflow inverts that logic. The model never has authorship; it has the role of reviewer with explicit criteria. This aligns with something we've seen in other documented cases: Claude tends to be more useful when the user knows exactly what friction they want to introduce to their process, rather than delegating the entire process.

For those who prepare talks regularly, developer advocates, engineers who present at conferences, technical consultants, this type of use makes immediate practical sense. It requires no complex integrations or special setup: it's structured conversation with well-designed prompts.

What the article misses

The original post is honest about its limitations: it doesn't measure whether the talk objectively improved (difficult to do), doesn't compare with previous preparations, and doesn't document the exact prompts used, which would reduce reproducibility. These are reasonable limitations for a personal account, but worth keeping in mind before adopting the method without adaptation.

It also leaves unexplored whether this workflow scales to longer talks or multiple speakers, where coordinating voices adds another layer of complexity.

Who this helps

The case has direct application for:

• Developers who present at meetups or conferences without a dedicated communications team.
• Technical teachers or trainers who prepare sessions frequently and need quick feedback before each delivery.
• Anyone who's faced the problem of "I have the content, but I'm not sure it flows" without a colleague available to listen.

It's not a workflow designed for those who need someone to write their content from scratch. In that case, results tend to be generic and the presenter ends up distanced from their own material.

---

At ClaudeWave, we value this kind of practical documentation precisely because it focuses on process, not spectacular results. When someone takes the time to explain how they used a tool thoughtfully and deliberately, it's more useful for the ecosystem than another success story without methodology.