There's No Excuse For Boring Presentations Anymore

Introduction

I recently flew to Rio de Janeiro, Brazil to present my fuzzing work FrameShift at ICSE 2026.

ICSE is one of the premier software engineering conferences. It’s a great venue for researchers across all SE-related areas to meet, but this creates a few problems:

1. So many papers that most presenters get just 12 minutes of actual speaking time.
2. The audience has wildly varying baseline understanding — a mix of experts and complete newcomers to your specific field.

Unlike smaller, specialized conferences like SAT where most attendees know a thing or two about SAT solvers, at ICSE there’s no guarantee anyone in the audience has even heard of fuzzing, let alone enough to follow the technical contributions of my work without background.

So the question I was grappling with was: what do you do in this environment?

How do you convey information in just 12 minutes that is simultaneously:

• interesting enough to keep zoomers from staring at their phones (or worse, leaving),
• digestible enough so that any prospective audience member can follow along, and yet
• informative enough to convey some key contribution or insight of your work?

A vibe-coded Manim slide from my presentation showing how a PNG file is parsed sequentially.

I’ve been fascinated with the ability of science-related YouTube channels to make complex topics feel accessible and engaging, in stark contrast to typical dry and boring academic presentations.

And while I don’t have a motion graphics editing team at my disposal, I do have Claude Code on a Max 20x plan.

So for this presentation I dove deep into the world of vibe-coded animations and used Claude Code to write a Manim animation (the lifeblood of 3Blue1Brown videos), then exported it as a series of gifs I could assemble into a slideshow for pacing control. Despite lots of arguing with (an empirically blind) Claude, it was easier than I thought it would be to do, and I got a lot of positive feedback on the talk.

While the original conference talk wasn’t recorded, a re-recording of the talk is below. The rest of this post is 50% rant about why most talks are boring, 40% tutorial on how I did this, and 10% existential AI doomerism (intermingled throughout). If you’re interested, you can also find the code here.

The Quest to Make a Good Talk

Disclaimer: I got a lot of nice feedback after my ICSE talk (and at least three separate people asking for my slides and/or code) so I have a little bit of confidence that it was at least somewhat successful. However, it’s definitely still far from the visual caliber of actual 3Blue1Brown videos, and you can really see that I got lazy towards the end with more text-heavy slides. If I had more energy, I would fix this up…

1. The Default Academic Talk (is boring)

I find a lot of academic talks really boring, and I don’t think I’m alone. Many people I spoke with at ICSE were more interested in touring the city than sitting through a slew of conference talks. (Arguably, the chance to see one of the seven wonders of the world probably dwarfs even the most interesting talks.)

The most common approach I see for a short academic talk is to roughly map the layout of the paper into slides:

• Motivation / Background
• Approach
• Evaluation
• Conclusion

As an audience member who’s an expert in the field, I really just care about the meat of the paper. I want to know what you’re actually doing.

At a fuzzing presentation, I don’t need three slides explaining that software has bugs and we want to find them (just get to the point!). I also probably don’t care about the results: it was accepted, so I assume the numbers are good, and I’m not going to have time to parse a large table or graph as it flashes by.

So ideally you could cut out the cruft and spend most of the time on the approach.

However, as a non-expert, I’d get lost if a presentation dove straight into a complex approach without setting up any background.

This is the dilemma for most people. How do you cater to both crowds?

When I started giving talks, I used the simple structure layout above. The goal, in my mind, was to explain the approach (and some results), but first I needed to set up enough background to make it understandable to non-experts.

I think it is natural (especially for CS-minded authors) to think about a talk as having a complex dependency tree, and to think of preparing the talk as finding some linear ordering of it such that all the prerequisite knowledge comes before the meat of the talk. (in nerd speak: a reverse post-order traversal of the dependency graph)

For FrameShift, the dependency tree might look something like this:

Now over the course of a 12-page paper, you can explain all these points in detail, but in a 12-minute talk there’s just no time for that.

In my experience, non-expert audiences have neither the time nor the patience to internalize enough background to actually understand the meat. Once it starts feeling like a lecture, people zone out. And the more background you front-load, the longer they wait to hear what you’re actually doing.

2. People Like Talks That They Understand (and Remember Them!)

My department at CMU runs a mandatory weekly student seminar where 1–3 students each give a 30-minute presentation. We’re required to give at least one per semester and get feedback from attendees.

This forced practice has been a great way to hone presentation skills and get a sense for what people do and don’t like.

Over the past 4 years, the talk that got the most positive feedback (by far) was also the one where I presented the most technically simple work (STRIDE).

This work solves a pretty obvious problem (decompilation is hard to read) with a pretty simple solution (match N-grams of neighboring words).

I spent around 10 minutes of that presentation walking through a very simple example of how a human might deduce clues about variable names and types by looking at the surrounding code, drawing from my experience of capture-the-flag addiction.

Something I realized while giving this talk was that people actually seemed to be really engaged with the content, able to follow along and understand each step without getting lost or distracted. And even more than a year later, I’ve spoken with people who remember details from that talk, which isn’t something I can say for most of my others.

In contrast, when I’ve presented more technically complex work, even with similar example-based walkthroughs, I’ve quickly lost the attention battle. People start to go on their computers, check their phones, or just zone out.

And the problem is that if people lose focus and miss the dependency A required to understand B, it becomes much harder for them to get back on track when they want to rejoin the talk. Patrick Winston discusses a related idea in his How to Speak lecture.

(There’s maybe something interesting here thinking about “error-correcting” presentations, where it’s still understandable even if you randomly skip x% of slides…)

3. Stealing the YouTube Playbook

Linguist Stephen Krashen promotes Comprehensible Input: the idea that you learn a foreign language best by consuming easy content just beyond your current proficiency, rather than reading intensively through difficult material. Part of the hypothesis is that if content is naturally understandable and interesting enough, learners compel themselves to pay attention. I think the same applies to academic presentations. The presentation should not feel difficult, it should feel comfortable.

So what do you do if you need to explain a system that is just too complicated?

Well this is where science YouTubers have already figured out the answer. Somehow channels like Veritasium, Numberphile, and 3Blue1Brown can make an entertaining and engaging 45 minute video about an obscure physics concept or number theory problem and get millions of views.

And while they are definitely doing a bit of selection bias to choose topics that are perhaps more stimulating, they aren’t necessarily picking easy topics.

In my observation, there are two main tactics at play:

1. Careful illusions of understanding
2. Information-dense visuals

Careful Illusions of Understanding

A very valuable trick is that you can provide the illusion of understanding to the audience (thus keeping them interested and engaged) through the use of simplified models and metaphors.

For example, part of this Veritasium video explains Diffie-Hellman key exchange using the analogy of mixing paint colors to arrive at the same shared secret. It’s a good analogy because the properties of mixing paint are similar to the properties of the actual math involved, and it’s immediately accessible to non-experts.

But it is a tradeoff: it’s hard to internalize the difficulty of what it means to “unmix” a paint color (as would be required to decode the shared secret).

In practice, for the subsequent explanation (explaining how ssh works), it doesn’t actually matter. A viewer just needs to know that it is possible to establish a shared secret even with a man-in-the-middle. So in this case, using the simplified explanation to give the viewer just enough of a mental model to accept the next step is enough. Trying to explain deeper (or worse, put equations on the screen) would only serve to introduce unnecessary friction.

Different channels also use this trick to different extents. For example, 3Blue1Brown tends to be more comfortable showing actual math and equations, without trying to hide or simplify them too much (and as a result, those videos tend to be appealing to a more math-oriented audience).

In my presentation, one of the ways I did this was with the extended metaphor of frameshifts in DNA compared to frameshifts in binary data.

It’s much easier to explain frameshifts in DNA because of the repetitive structure (letters are always read in groups of three), and audience members might have already heard of these from biology class.

In contrast, there are actually lots of different ways that frameshifts can happen in binary data, some of them quite different from DNA, especially once you start talking about finding nested fields or dealing with files that have lots of indirect pointers (like ELF files).

But for the purposes of the presentation, it’s enough just to explain the concept and show the bridge to binary data. I intentionally picked the PNG file format because it was possible to illustrate a type of frameshift that is structurally analogous to DNA frameshifts, and thus people can accept the bridge without friction.

Information-Dense Visuals

The other, more straightforward tactic is just that the visuals in high-quality YouTube videos are much more informative and supportive.

In a different part of the same Veritasium video, they explain how a Huffman tree is constructed for a given plaintext by actually animating each step of building the tree.

Animations like this serve to both make the content more visually appealing (providing a constant stream of dopamine for low attention span viewers) and more structurally informative (showing exactly what is happening step by step).

Now it’s difficult to match the caliber of a legitimate motion graphics team for creating high-quality animations.

But Grant Sanderson (the creator of 3Blue1Brown) does all his videos with the use of custom-built software called Manim – and this is just code!

For my presentation, there were a lot of explanations that I thought could benefit from animations, specifically:

• showing how different mutations have different effects (in DNA and binary data)
• showing how a PNG file is parsed sequentially
• illustrating the double-mutant DNA experiment

And I also thought that some animations could also just enhance the visual appeal of the presentation, making it more engaging to look at.

4. Vibe-Coding Manim Animations with Claude Code

Now creating all these animations by hand in a slideshow editor would be a huge time sink, so my goal was to see if I could automate most of it with Claude Code.

I ended up vibe-coding a bespoke framework for rendering a Manim scene to a bunch of gifs that could each be placed in a separate slide, allowing me to control the pacing. (I was able to then add my school logos and page numbers on top of each gif, to create a consistent look.)

Roughly my process was the following:

First, I wrote a full draft of what I would say in the presentation, and planned out visually what I wanted to convey in each part. For example, here’s what the start of the final draft ended up looking like:

...

> microbiology title comes in
And I actually wanted to start with something a bit unusual for a software engineering conference, by talking about microbiology.

> slide title
There's a pretty interesting biological metaphor that underpins our work. And my advisors didn't let me put in the paper -- but they can't stop me here.

> dna sequence in, triplet grouping arrow, grouping visualized with boxes, all on top half
So as a refresher, DNA is this long string of A, T, C, and G, and it gets translated into this sequence of amino acids in groups of three at a time. This specific grouping of three letters is called the reading frame.

> swap letter, turns red, red arrow for that group, amino acid switches turns red
Now mutations happen naturally to DNA all the time, and we can ask what happens for different types of mutations.
So for example if we just change a single letter in the DNA sequence this has a very localized effect -- we just get a single different amino acid.

> duplicated dna/aa sequence below, insertion shifts DNA sequence, red arrows propagate, amino acids all flip
But on the other hand, if we try to insert a letter, it shifts the reading frame of everything downstream. This is called a FrameShift mutation -- you might recognize from our title. So even though the actual mutation is very small, the resulting effect is global: all of the downstream DNA is interpreted in a different reading frame and so all those amino acids are likely different, completely destroying the structure.

I ended up going through about five separate drafts. Claude was pretty useful for helping plan out a rough structure, but I ended up rewriting all of the wording in my own voice (instead of clankerese).

One of the key challenges as well was getting the biology metaphor to work properly. In an early draft, I tried starting with both the explanation of frameshifts in DNA and the double-mutant experiment back-to-back, but it ended up being way too much irrelevant information up-front about biology, failing to get to the actual point quickly enough. So in the final version, I moved the double-mutant experiment later, after we’ve already established the bridge to binary data.

Then I iterated on the visuals, using Claude Code to generate and render the scenes, and then providing a bunch of feedback on visual tweaks. In general I had to be really descriptive and opinionated about the visuals. Claude was generally pretty inconsistent at understanding 2D layout, and would inevitably end up with overlapping text, shapes that were too small or too big, and would sometimes even forget to remove slide content before switching to a new slide.

Coincidentally, Claude Design was released the day of my presentation (which I have yet to try), which might demonstrate a better spatial understanding.

Another key challenge was that by completely vibe-coding the animations, it was impossible for me to edit by hand. On the max plan, this wasn’t a big deal, I could just throw more tokens at the problem. But there were generally a lot of small tweaks that could have been done in a simpler way with a visual editor.

Humorously, as I was cleaning up the little bespoke framework to release it, I realized that someone else had already created a similar (much more feature-rich) framework to render Manim scenes to slides, called manim-slides. I do wonder a bit about the utility of actually releasing these sorts of frameworks now that they are conceptually so easy to recreate.

I have released my framework (and example code) as a sort of proof of concept, but to be honest, if you want to do something similar, maybe just try to vibe-code your own software for your particular use case. It seems like we’re entering an era where just the idea of a concept is enough to get started.

Conclusion

In any case, our clanker friends are here to stay and we should use them to our advantage.

If you get one thing out of this post, it’s that you can do more than you think with a bit of vibe-coding (and a lot of tokens).

Please go and make cool presentations, I want my next ICSE to feel like a film festival :)

If you make something cool, I’d love to see it! You can reach me at @hgarrereyn.