How I AIHow to digest 36 weekly podcasts without spending 36 hours listening | Tomasz Tunguz
CHAPTERS
- 0:00 – 3:32
Why Tomasz built a “podcast ripper” to keep up with 36 shows
Tomasz explains the core problem: he wants insights from dozens of weekly podcasts but doesn’t have time to listen. His solution is an automated pipeline that downloads episodes, transcribes them, and produces skimmable outputs he can read quickly.
- •Maintains a list of ~36 must-follow podcasts
- •Automation runs daily to fetch new episodes
- •Prefers reading over listening for speed and control (skipping/scan)
- •Transcription + prompting turns long audio into actionable text
- 3:32 – 5:06
Architecture overview: downloading feeds, converting audio, transcribing locally
Tomasz walks through the system he built (Parakeet Podcast Processor) and the main plumbing that turns audio files into text. The toolchain emphasizes local processing and modular steps that can be swapped as models improve.
- •Podcast processor reads a feed/file and downloads episodes
- •FFmpeg converts audio formats for consistent processing
- •Uses Whisper initially; highlights NVIDIA’s Parakeet as a newer option that runs well on Mac
- •Pipeline approach: ingest → convert → transcribe → post-process
- 5:06 – 6:59
Transcript cleanup: using an LLM as a transcript editor
After transcription, Tomasz cleans transcripts by removing filler words while preserving technical content and length. He demonstrates a “transcript editor” prompt and describes why cleaning mattered more earlier in the project than it does now.
- •Uses Gemma 3 (via Ollama) to clean transcripts
- •Prompt goals: remove ums/ahs, keep technical details, preserve length
- •Improves readability for fast scanning
- •Cleaning’s importance decreased as he moved more tasks to stronger LLMs
- 6:59 – 10:20
Orchestration + storage: tracking processed episodes with DuckDB
To make the workflow reliable, Tomasz stores processing metadata locally so episodes aren’t reprocessed unnecessarily. He describes an orchestrator that pulls daily transcripts from the database and runs summarization prompts in batches.
- •Local DuckDB logs what was processed and when
- •Orchestrator fetches all transcripts for the day
- •Batch processing yields a single daily summary artifact
- •Designed for repeatable, low-friction daily use
- 10:20 – 12:38
Daily digest outputs: summaries, key topics/themes, and the most valuable quotes
Tomasz shows what the daily generated document looks like: each podcast gets host/guest context, a comprehensive summary, key topics, and key themes. He emphasizes that curated quotes are the highest-signal output for his workflow.
- •Per-episode structured summary: host/guest + comprehensive recap
- •Key topics and key themes extracted for quick scanning
- •Quote extraction highlighted as the most useful component
- •Digest is positioned as a daily briefing document
- 12:38 – 15:31
From content to action: investment theses, tweets, and company discovery
Beyond summarization, the pipeline generates venture-style “investment theses,” draft tweets, and lists of companies mentioned in episodes. These outputs connect podcast listening to concrete next steps like market maps, CRM enrichment, and outreach.
- •Actionable investment theses suggested from episodes
- •Noteworthy observations formatted as potential tweets (still iterating)
- •Entity extraction surfaces startups/companies mentioned
- •Unknown companies can be pushed into a CRM for enrichment/research
- 15:31 – 17:34
Why the terminal: speed, low latency, and scriptability
Claire probes why Tomasz stays in the terminal instead of building a UI. Tomasz argues the terminal offers the lowest interaction latency, reduces frustration, and makes it easy to script automations across email, CRM actions, and AI tools.
- •Terminal offers minimal keyboard-to-computer latency (via Dan Luu’s argument)
- •Adopted terminal usage during COVID and now lives in it
- •Scriptable workflows: bulk actions, AI-assisted email replies, CRM updates
- •Sees terminal as a legitimate product surface (e.g., Claude Code)
- 17:34 – 18:25
Hyper-personal tools vs off-the-shelf apps: “glove-like fit” with modern AI
They discuss why personalized internal tools are now practical: AI reduces the cost of building and modifying bespoke software. Tomasz highlights how quickly he can tweak workflows (like reordering sections or emailing digests) using tools like Claude Code.
- •Off-the-shelf apps won’t match niche preferences (e.g., terminal-first)
- •AI makes bespoke utilities cheap to create and maintain
- •Claude Code enables fast repo-wide changes and feature additions
- •Workflow can evolve quickly as needs change
- 18:25 – 22:00
Podcast insights to blog drafts: the blog post generator pipeline
Tomasz introduces a second system that turns a specific podcast quote/topic into a blog post draft. It uses the podcast transcript as context and pulls relevant prior writing to shape content and tone, though a demo bug appears during search.
- •Selects a quote/topic from the podcast digest to anchor a post
- •Uses transcript context to ground the draft
- •Retrieves relevant prior blog posts via local vector search (LanceDB)
- •Generates a draft blog post file; demo includes a search bug
- 22:00 – 26:13
The “AP English teacher” grader: setting a quality bar and iterating
To improve drafts, Tomasz uses an evaluation prompt that grades the post like an AP English teacher, then revises until it reaches roughly an A−. He describes why hooks and conclusions matter most and how he runs multiple improvement passes.
- •Grades output with letter grade + numeric score
- •Emphasis areas: hook/lead and conclusion cohesion
- •Three-iteration loop: draft → grade → improve → re-grade
- •Stops around A− as “good enough” for a working draft
- 26:13 – 28:16
Style matching is hard: model voices, personal quirks, and linking limitations
Both agree AI struggles to capture a writer’s authentic rhythm—especially in short-form. Tomasz compares model “personalities,” notes AI’s tendency toward grammatical perfection, and shares unresolved challenges like automatically linking to related posts.
- •Different models produce different tones (clinical vs warm/verbose)
- •AI often removes intentional stylistic quirks (punctuation, fragments, ampersands)
- •Hard to make AI link to other relevant posts in a coherent way
- •Short-form (tweets) is even harder than long-form style matching
- 28:16 – 30:28
Prompt + rubric details: what his generator optimizes for (brevity, no headers, flow)
Tomasz reveals the blog generator prompt design and the structural constraints he enforces from his own analytics. He explains dynamic style extraction from related posts and why he avoids headers due to dwell-time impacts.
- •Uses past posts (2,000+) as style context; summarizes style patterns dynamically
- •Targets ~500 words or less and fast reader time-to-value
- •No section headers (found they hurt dwell time)
- •Paragraph constraints: smooth transitions, often two long sentences max
- 30:28 – 35:14
AI for writing education + wrap-up: future tiny teams and “AI model cage matches”
They broaden to education: AI can handle first-pass grammar/structure feedback, freeing teachers to focus on creativity. Tomasz then answers rapid questions: his vision of a 30-person $100M company and his tactic of using multiple models to critique each other when outputs degrade.
- •AI as a first-pass writing evaluator (grammar, structure, logic checks)
- •Teachers can focus more on creativity and higher-order feedback
- •Vision: lean, engineering-heavy teams with PLG-driven growth and internal automation
- •When stuck: have multiple models compete/critique to improve outputs; switching models increases robustness
