나는 위험이 큰 기술 AI 데모를 준비합니다.

How I prepare for high-stakes technical AI demos A practical playbook for when your demo depends on systems that might betray you In the last year, I’ve ended up giving a lot of live demos of AI products. Big rooms. Big stakes. C-suite co-presenters. Professional makeup artists tsk-tsking my skincare beforehand. The thing about AI is that it’s pointedly non-deterministic. You have no idea what’s going to happen. Sometimes the demo gods are kind. Sometimes Azure is down. Sometimes the model is having an incident. And sometimes the AI just decides not to do the thing it did the last 40x you rehearsed it. This is how I prepare so the show still goes on. 1. Use the product until you can explain it casually You know you’ve made it when people start asking you to demo products you don’t actually work on [finger-guns, finger-guns]. But if you don’t really understand what you’re showing, it’s usually obvious - especially when things go wrong. If you end up in this position, take the chance! But start by actually playing with the product, with an emphasis on play. Click around. Touch buttons. Build the silliest thing you can. Try to break it. This makes your demo more believable in any circumstance, and it’s gonna be mission critical when something fails in real time. From there, rehearse until you could explain the demo casually to a friend. The goal isn’t memorization; it’s comfort. You should be able to chat through what’s happening even if someone trips on the wire to the prompter on their way to get some coffee and the whole thing goes dark. Bonus points, conversational understanding makes a demo feel natural instead of rehearsed. It’s also how you get real-time humor, which buys you a lot of grace when things don’t go perfectly. Action items: Use the product end-to-end at least once with no script Try one deliberately dumb use case Rehearse out loud, not silently If you can’t explain a step conversationally, stop and learn it. Talk it through with an AI until it clicks. That’s both a rehearsal gap and a joke opportunity. 2. Choose the right model for a live demo (and always have a backup) The smartest model is often the wrong demo choice. A fast, “good enough” model keeps energy high. Waiting 45 seconds for a first response kills the vibe. Play around with multiple models until you find the fastest one that’s just smart enough to be reliable for your use case. Then: pick a backup. At GitHub Universe, during my first-ever demo with a member of our C-suite, the model I planned to use was down earlier that day. I happen to be in a role where I work closely with our model providers, saw engineers discussing the incident in Slack and was ready to pivot in real time. We ended up getting the all-clear about an hour before the demo - but another team presenting earlier that day wasn’t so lucky and had to switch models live on stage. Action items: Decide your primary and backup model in advance Test both paths end-to-end Optimize for latency over intelligence unless model quality is the actual point of the demo 3. Record a backup demo, but break it into pieces Oh boy, did I learn this one the hard way. I gave the exact same demo twice: once at GitHub Universe, and again at Microsoft Ignite. This demo was cursed. At GitHub Universe, Microsoft Azure went down that day. I made it through the first half, hit the second half, and had nothing to show. So I made a joke and left the stage. My co-presenter (wiser than me) had prerecorded his demo the week before. When things broke, he switched to video and walked through it like nothing was wrong - Smooth. Professional. A shining example to us all. Lesson learned. So at Ignite, I came prepared with a full prerecorded backup. Ironically, everything worked - until minute 14:45 of a 15-minute demo, when the final step failed. Turns out an automated VS Code update earlier that day had quietly uninstalled the final tool I needed. Devastating! At that point, it didn’t make sense to jump into a full 15-minute video just to show the last 15 seconds. So once again, I made a joke and moved on. Here’s the real takeaway: Long demos don’t fail all at once. They fail in pieces. Next time, I’d prerecord the demo in short, modular chunks. Each clip would be fullscreen on a separate desktop, so if something breaks, I can three-finger swipe over and keep going. According to my DevRel friends, if you do it confidently enough, no one even notices. Action items: Record backup demos in short segments, not one long video Make each clip fullscreen on a separate desktop Practice the swipe so it feels invisible in realtime if you need it One more hard-earned tip from this story: Rehearse the entire demo end to end in the hour before you present. Even the easy parts, even if you’ve run it 400x. You never know when an automated VS Code update will decide today is your day. 4. If you need audience participation, be ready to fake it One time in a Microsoft Build demo, my (extremely talented and charismatic)