How AI helped me give a better talk — Luke Swithenbank

All posts<br>Posted · 5 June 2026 · Sydney<br>How AI helped me give a better talk

#ai<br>#platform<br>#talks<br>#publicspeaking<br>#patrickwinston<br>#slides<br>How I used Claude to structure a talk around Patrick Winston's 'How to Speak', and why the method, not the model, is what made it land.<br>Here’s how I used AI to give a much better talk than I usually do.

AI is really good at structuring your work and editing it. It is also a great partner for helping pull your ideas out of your head. It really sucks at the content though. It doesn’t capture your voice, or novel ideas, or even what “your taste” is. You need to refine your own talk yourself. This is done through you writing your own content, and having AI structure and edit it.

I have been public speaking for most of my career in engineering. I initially started by just giving a weekly “hackernews summary” at our company townhall. I then started to figure out what developers like to hear and how to keep an audience. I found that often, it was just quick slides and just moving through things quickly to keep interest.Take questions at the end. I’d never really dug into a better way to public speak. I knew there was Toastmasters and other forums for it, but it only really came up when I wanted to train engineers or keep them informed. I didn’t need it outside of that. Now that AI is here, and I haven’t done any public speaking in ages, I thought it would be a good time to brush up on new techniques.

The ask

I was asked to do a talk at the SRE meetup in Sydney.<br>The SRE meetup was mainly about digging into really interesting findings within the SRE space and cool bugs and outages that people have had.<br>I came up with a list of possible talks I could give on short notice:

how to spot the difference between a bad SRE and a good one

how to market yourself as a platform engineer

how AI affects being a platform engineer

how to use AI agents effectively with IaC

why platform engineers make great leaders

the lost art of troubleshooting

The organiser recommended I go with “the lost art of troubleshooting”.

The brain dump

Once I got this idea sorted, I wrote a short overview of what I would cover that looked like this:

“Lost Art”: Only platform engineers tend to put the time into troubleshooting

“Why you should troubleshoot more”: Troubleshooting adds up. The amount of random tidbits of knowledge that allow me to do my job more effectively compounds. Sometimes you don’t know why it’s a good idea to know that when you make a change to the way you attach images to your blog post, it will break your newsletter and stop it sending.

[…]

The end.

It has a lot of ideas and is just “write immediately and get shit out” kinda vibe.

Applying Winston’s method

I then prompted Claude to apply Patrick Winston’s “How to Speak” method to this to get a good structure I could use from this wall of writing. I came across Patrick Winston’s method on Instagram and thought “why not apply it here” so I could make this talk more interesting than my usual.

Me: I’m writing a funny talk called “The Lost Art of Troubleshooting”. It’s for a room of platform engineers. It’s a talk that only lasts 15 minutes. I’ve written out some basic mess, and I’d like to organise it and structure it. I want the talk to be easy, full of memes, and entertaining. I want to use the main method of Patrick Winston’s How to Speak when writing this talk. Can you help me structure it well so that it follows the method and also is funny for platform engineers?

Claude gave me a structure like this:

Claude: The rules we’re writing to:

Empowerment promise. Open with what the audience will walk away with. Not a joke, not biography.

Cycle on the idea. State the big idea three times across the talk, in roughly the same words. People drift in and out.

Build a fence. Distinguish your idea from things people will confuse it with.

Verbal punctuation. Number things out loud (“step one… step two…”) so people who drifted off can rejoin.

Ask a question. A non-obvious one. Pulls the room in.

Examples and stories. Stick where claims don’t.

Strong start. No jokes cold. No apologies.

Strong finish. No “thank you.” No “any questions.” Salute, vision, or call to action.

The thing is, Claude actually picked out that the core idea in my paragraph above was:

Claude: “The big idea: Troubleshooting is a compounding skill. Software engineers debug their code. Platform engineers debug the world their code runs in. The payoff doesn’t land today, it lands in five years, and AI didn’t kill it, it made it better. ”

This wasn’t any good.

Picking the big idea

I then asked Claude to pull back and actually just give me the structure. I would need to delve into my paragraph with Claude to get the actual content.

Me: I think you added too much. Let’s pair it back heaps. I think just put his method at the top, and I’ll help write the actual memes and the creative parts. Keep my reference...