Notes from coding tutorials and conference talks

Technical talks have a bad ratio. Forty-five minutes of video often contains four minutes you needed, and you cannot tell which four until you have watched all of it. This page is about triaging talks quickly and keeping the parts worth keeping — especially the code.

Deciding whether a talk is worth your time

Before committing forty-five minutes, generate chapters and read them. You learn the actual structure of the argument in about twenty seconds, which is usually enough to tell whether the talk covers what the title implied. When it does not, you have saved most of an hour.

When it does, the AI Highlights walkthrough plays the substantive moments in sequence with spoken narration bridging the gaps, so you can get the shape of a talk while doing something else and come back for a proper pass on the parts that mattered.

Capturing code from a screencast

This is the specific problem with recorded tutorials: the useful artefact is on screen and never spoken aloud. Nobody reads out an import block or a config file. A transcript of a screencast records the narration and loses the entire thing you were watching for.

Screenshot the editor when the code is on screen, and the capture is analysed rather than merely stored — the text and structure inside it can be searched and referenced later. A snippet you grabbed in April is findable in September without rewatching anything.

Recovering the thing you half remember

The most common reason to return to a talk is a fragment: someone mentioned a profiling tool, or gave a number for how long a migration took. Scrubbing for it is miserable. Asking the video is not — you get the answer along with the timestamp it came from, and the screenshots you captured are part of what gets searched, so a tool named only in a terminal window is still findable.

Building a library across many talks

The value compounds once you have twenty talks processed. Because every note is plain Markdown in a folder on your own disk, the whole collection is greppable with ordinary tools and indexable by anything that reads a directory — Obsidian, ripgrep, Spotlight, your editor's project search. There is no per-video export step and no database to query.

Running the local model matters here for a practical reason rather than an ideological one: processing a long backlog through a cloud API has a per-video cost that adds up, while a local model has none once downloaded. If you are working through a conference playlist, that is the difference between watching the meter and not thinking about it.

What this does not do

Common questions

Can it read code from a video?

You capture a screenshot while the code is on screen and the image is analysed, so the text inside it can be searched and referenced later. Reading code from a screenshot is more reliable than the transcript, which records only narration.

Can I process a whole conference playlist at once?

No. Videos are added individually; playlists are not processed in bulk.

Does it work with talks that are not on YouTube?

No. ScribeShot accepts YouTube links only, so talks hosted on Vimeo or a conference platform are not supported.

Is the local model good enough for technical content?

Gemma 4 E4B is the default and handles structured notes and chapters for technical talks. For dense material where you want the strongest summarisation, connect an OpenAI key, or run the 31B local model if you have 24 GB or more of RAM.