Live coding demos & presentations

Why does live coding go wrong on stage?

Live coding is the highest-wire act in a technical talk. The usual two choices are both bad. Typing everything yourself produces typos, missed imports, and twenty-second silences while you search for the right key — stage anxiety typically drops presenters to 60-80 WPM, noticeably slower than their desk speed. Pasting from a file drops the full block in one frame and the audience loses the thread of reading code as it's written.

copypaster is the third option. You prepare code blocks in advance. During the demo you paste the next block, click into your editor, and the code types itself at 80, 120, or 200 WPM — whatever pace keeps your audience oriented. You narrate the reasoning while the keystrokes happen.

What does a live presentation flow look like?

1. Rehearsal — split your demo into 3-8 blocks (imports, main function, test, extensions). Keep each in a file or clipboard manager you can jump between fast.
2. On stage — narrate the setup, then copy block #1.
3. Paste into copypaster — the pill stays at the top of the screen so it never fights with your editor.
4. Trigger typing — click into your editor, start the 3-2-1 countdown, talk through what's appearing.
5. Repeat per block — you stay in conversation mode with the audience the whole time.

How does copypaster compare to other live-coding approaches?

Approach	Typo risk	Pace control	Prep time	Audience readability
Live typing	High	Drops under stress	None	Variable
Paste from clipboard	None	Instant	Low	Too fast
Pre-recorded video	None	Fixed	High	Good
Step-through "Git magic"	None	Commit-by-commit	Very high	Jumpy
copypaster	None (typos optional)	Adjustable WPM	Minutes per block	Matches listening speed

Why does the typing feel natural and not scripted?

The engine produces LogNormal-distributed keystroke intervals with burst sizes of 3-15 words, separated by pauses at paragraph (1.5-4s), sentence (0.8-2.5s), and clause (0.3-1s) boundaries. Adjacent-key typos occur at 40% of all typo events, mirroring observed human error patterns. If you prefer a clean presentation without typos on camera, disable them — the bursty rhythm and natural pauses alone read as human.

What does code mode handle automatically?

Code mode preserves exact indentation, respects bracket auto-pair behavior of your editor, and tunes keystroke timing for the way programmers actually write code (faster in common constructs like for (let i = 0, slower on unfamiliar identifiers). It's the difference between a demo that works on the first take and one that triggers autoformat battles mid-sentence.

Where does it shine most?

• Conference talks — the code that matters is the code you wrote in a quiet room, not what you remember at the podium. See also screencast recording for the async version.
• Workshops and bootcamps — keep pace so no one in row 30 falls behind on line numbers.
• Internal tech talks — demo a refactor or architecture change without re-typing validated code.
• Developer advocacy demos — see sales demos for the commercial angle.
• Remote interviews with screen share — for scripted portions where the interviewer has asked for a known algorithm.

How do I set up for a first-time run?

• Use a 3-second countdown so typing starts after your verbal cue, not in the middle of it.
• Keep WPM at 120 for audiences. That's above average desk speed (65-75 WPM) but below max typing speed, which means it reads well in a 4K-projected editor.
• Rehearse in your actual editor once. Some IDE autocompletions interact oddly with rapid typing; code mode addresses most but a 90-second dry run catches the rest.
• Keep the pill on a secondary monitor if you have one — your primary display is the audience's view.