Lex Fridman PodcastJeremy Howard: fast.ai Deep Learning Courses and Research | Lex Fridman Podcast #35
CHAPTERS
- 0:00 – 1:21
Meet Jeremy Howard and the fast.ai ethos
Lex Fridman introduces Jeremy Howard and frames fast.ai as a practical, accessible entry point into deep learning. The tone is set: focus on real-world results, minimal hype, and learning by doing.
- •Jeremy Howard’s background: fast.ai founder, former Kaggle president/competitor, entrepreneur and researcher
- •fast.ai positioned as free, practical, low-BS deep learning education
- •Emphasis on accessibility for both beginners and experts
- 1:21 – 3:01
First code: using a Commodore 64 to search for better musical scales
Jeremy recounts his earliest remembered program: a BASIC search over musical scale sizes to find more accurate harmonic ratios. The discussion ties programming curiosity to a lifelong relationship with music.
- •High-school project: computational search for alternative tuning systems
- •Commodore 64 + BASIC as an early experimentation platform
- •Music as a sustained creative thread; baritone sax as favorite instrument
- •RSI/health issues limiting music practice in later life
- 3:01 – 8:23
Programming environments that make data feel easy: Access, Excel, and relational thinking
Jeremy argues that developer productivity often comes from environment and data tooling more than language elegance. He highlights Microsoft Access as an unusually powerful way to rapidly build data-driven apps, and laments how hard modern stacks make similar workflows.
- •Access + VBA as a standout “complete” environment for small, useful apps
- •Relational databases as a core theme in Jeremy’s programming preferences
- •Modern pain points: servers, ORMs, glue code, and integration overhead
- •Mention of F# type-provider ideas to make databases first-class in tooling
- 8:23 – 12:59
The “third path” in languages: APL lineage, J, and array-oriented programming
Jeremy introduces array-oriented languages as a major (but overlooked) programming family alongside functional and imperative/OO traditions. He explains why J is extraordinarily expressive and how related languages power high-speed finance systems.
- •APL origins: Iverson’s “Notation as a Tool for Thought” → APL → J
- •Array-oriented programming minimizes loops via powerful broadcasting-like operations
- •J as highly composable and concise—often fitting a program on one screen
- •K as a high-performance, expensive niche language used by hedge funds
- 12:59 – 15:01
Pragmatism wins: Perl, Python, and why libraries dictate reality
Despite love for more elegant languages, Jeremy explains why real projects gravitate to ecosystems with libraries and momentum. He discusses building Fastmail entirely in Perl and why Python ultimately replaced Perl in many domains despite being less elegant.
- •Perl as a flexible tool for early web infrastructure when frameworks didn’t exist
- •Fastmail built “everything in Perl” for pragmatic reasons
- •Perl’s decline tied to leadership/community dynamics (Larry Wall stepping back)
- •Python’s dominance driven by data science libraries rather than language design
- 15:01 – 21:42
Making deep learning truly hackable: Swift, MLIR, and DSLs for GPU kernels
Jeremy outlines why Python slows down innovation in core deep learning kernels and argues for an “infinitely hackable” stack. He highlights compiler-based approaches (MLIR, TVM, Halide, tensor DSLs) as the route to high performance without CUDA-level boilerplate.
- •Python becomes “unhackable” when performance forces you into C/CUDA layers
- •Research bottlenecks: RNN/NLP loops and sparse convolutions require kernel work
- •MLIR and related projects aim to compile tensor DSLs into optimized kernels
- •Halide’s separation of algorithm vs scheduling as a key idea
- •Vision: Swift + DSLs + compiler tooling enabling expressive, fast GPU code
- 21:42 – 23:34
Hardware reality: NVIDIA lock-in, TPUs, and the need for competition
The conversation turns to the current dependence on CUDA/NVIDIA and why it limits both cost and innovation. Jeremy critiques TPU programmability and describes how backend-agnostic compiler stacks could open the door to alternative accelerators.
- •Deep learning stacks largely “boil down” to CUDA/NVIDIA today
- •NVIDIA pricing power stems from lack of serious software competition
- •TPUs: faster in some cases but intentionally hard to program; limited transparency
- •Compiler backends (e.g., MLIR targets) could enable portability across devices
- 23:34 – 28:16
From Enlitic to fast.ai: deep learning for medicine and the doctor shortage
Jeremy connects fast.ai’s origin story to his earlier company Enlitic, aimed at deep learning in medicine. He frames the core medical opportunity as amplifying scarce expertise—especially in developing regions—via triage and decision support.
- •Enlitic (2014) as an early deep-learning-in-medicine company
- •Massive global shortage of doctors; training enough would take centuries
- •On-device triage and treatment planning as high-impact near-term use cases
- •Striking example: extreme scarcity of pediatric radiologists in Africa
- •Focus on augmenting clinicians rather than replacing them
- 28:16 – 32:26
Why medical AI adoption is slow: regulation, hospital lawyers, and data portability
Jeremy describes the non-technical barriers that keep medical AI from scaling, emphasizing institutional interpretation of regulation over regulation itself. The discussion expands into privacy, incentives, and why data sharing often fails despite huge potential upside.
- •Early days: the medical community initially had little awareness/interest in deep learning
- •Regulators, guidelines, and institutional inertia slow deployment
- •HIPAA framed as portability, but hospital legal incentives drive risk-avoidant interpretations
- •Benefits of data sharing are often abstract; harms (privacy violations) are concrete
- •Emergence of clinician–deep learning hybrids and fast.ai-trained doctors publishing work
- 32:26 – 37:59
Privacy and “do more with less”: transfer learning as a practical antidote
Jeremy argues many data-hungry narratives are incentive-driven and not strictly necessary. He emphasizes transfer learning’s ability to achieve state-of-the-art results with far less data, and highlights user-controlled medical data as a better model for sharing.
- •Vendors may be incentivized to demand more data/compute to entrench advantage
- •Transfer learning often reduces data requirements by orders of magnitude
- •Recommender systems and cold-start issues don’t justify broad privacy erosion
- •Negative externalities shift costs to society until regulation forces accountability
- •Example: patient-owned data flows (Doc.ai-style) enabling controlled sharing
- 37:59 – 40:56
fast.ai’s mission: empower domain experts (who may not code) to use deep learning
Jeremy explains that after seeing deep learning’s broad applicability, he chose to maximize impact by enabling people already embedded in domain problems. fast.ai is framed as a practical upskilling pathway that respects time constraints and real-world needs.
- •Deep learning reached a tipping point across domains (informed by Kaggle experience)
- •Jeremy’s frustration: one person can’t master every domain’s workflows and data
- •Strategy shift: enable domain experts with data to build solutions themselves
- •Applied/industry background (McKinsey, consulting) shapes this perspective
- •fast.ai focuses on speed-to-impact and pragmatic learning design
- 40:56 – 45:41
Theory vs practice: why much deep learning research misses what matters
Jeremy criticizes academic incentive structures that reward incremental work on fashionable topics rather than practical breakthroughs. He highlights under-invested areas like transfer learning and active learning, and recounts how a course-driven project led to ULMFiT.
- •Publish-or-perish incentives push researchers toward “safe” incremental work
- •High-impact practical areas: transfer learning and active learning are under-studied
- •Industry teams often reinvent active learning out of necessity
- •ULMFiT: applying transfer learning to NLP, built initially for teaching, then published at ACL
- •Critique: deep learning lacks norms for publishing unexplained experimental results
- 45:41 – 52:02
DAWNBench: fast.ai’s speed-and-cost wins and the ImageNet resolution trick
Jeremy tells the story of joining DAWNBench late, rapidly applying best practices, and outperforming major players on CIFAR-10 and later ImageNet. A key insight: train on low-resolution images first, then fine-tune at full resolution to save time while meeting accuracy thresholds.
- •fast.ai’s course-building office culture enabled rapid collaborative experimentation
- •DAWNBench goal: train models fast (and sometimes cheap) to a target accuracy
- •CIFAR-10 success led to ambition on ImageNet (93% target)
- •Resolution curriculum: 64×64 pretraining then brief 224×224 fine-tune
- •Outcome: winning results; later reaching extremely fast ImageNet training times
- 52:02 – 58:57
Single-GPU creativity: smaller benchmarks, DeOldify, and an underused audio frontier
Jeremy argues that multi-machine training often slows iteration and can distort research priorities. He promotes smaller, well-chosen datasets for faster experimentation, discusses GAN-quality results without GANs, and points to audio as an overlooked application area fast.ai wants to support.
- •Multi-GPU/multi-machine training often harms iteration speed and productivity
- •Research value of ImageNet-scale experiments questioned; advocates smaller subsets
- •Introduces “Imagenette” (easy) and “Imagewoof” (hard) as fast proxy datasets
- •GAN-level outputs without GANs; DeOldify for film colorization on a single GPU
- •Computational photography as precedent; audio enhancement as next opportunity; upcoming audio library
- 58:57 – 1:06:16
Learning-rate breakthroughs: superconvergence and the limits of current DL science norms
Jeremy explains Leslie Smith’s “superconvergence” and how fast.ai leveraged it for competitive training speedups. He critiques the field’s resistance to publishing strong empirical results without full theoretical explanations and predicts more automation and fewer tuning dials.
- •Superconvergence: dramatically faster training via much higher effective learning rates
- •Key technique: start low, gradually increase learning rate during training
- •Academic review culture discourages publishing unexplained experimental findings
- •Optimizer behavior depends on interactions (learning rate, weight decay, Adam epsilon, etc.)
- •Trend toward optimizers/schedules that eliminate manual learning-rate tuning
- 1:06:16 – 1:17:51
Cloud, tooling, and frameworks: why fast.ai chose PyTorch (and where Swift fits)
The discussion covers practical compute options (GCP, AWS, one-click notebook platforms) and the teaching impact of lowering setup friction. Jeremy contrasts static-graph frameworks with PyTorch’s dynamic approach, explains fast.ai’s layered API philosophy, and critiques TensorFlow’s technical debt while remaining optimistic about Swift for TensorFlow.
- •Hardware: best NVIDIA GPUs vs TPUs—similar speed, very different programmability
- •Reducing friction: course dropout used to be setup; now one-click environments help
- •Framework evolution: Theano/Keras → TF/Keras → PyTorch → PyTorch + fast.ai
- •Static graphs hinder debugging and interactive work; PyTorch enables normal Python workflows
- •fast.ai library: multi-layered API, “3 lines to train SOTA,” with deeper access when needed
- •TensorFlow Python criticized for complexity and performance; Swift/MLIR seen as a better long-term path
- 1:17:51 – 1:26:59
How to get started (and become an expert): train models, fine-tune, and pick a domain
Jeremy gives concrete advice for learning deep learning: run many experiments, inspect inputs/outputs, and quickly fine-tune models on your own data. He describes fast.ai’s workflow (including scraping datasets and deploying simple apps) and stresses that expertise should be anchored in a domain you care about.
- •Typical timeline: ~70 hours per course for strong coders; longer with broader study
- •Main bottlenecks: coding skills and (sometimes) overreliance on classical stats intuitions
- •Core learning loop: train and fine-tune models; inspect mistakes and confusion matrices
- •Lesson workflow: build a dataset (e.g., via Google Images), clean it, deploy a small app
- •Becoming expert = train lots of models in your domain area; real problems guide useful research
- 1:26:59 – 1:32:21
Startups and independence: tenacity, real problems, and avoiding VC pressure
Jeremy connects startup success to the same trait he sees in learning: not giving up. He advocates for low-cost, revenue-first approaches, warns against commercializing PhD topics that don’t solve real problems, and explains why VC incentives can distort decision-making.
- •Success driver: persistence plus choosing problems you understand and care about
- •Critique: commercializing a deep-learning PhD often fails to map to real customer pain
- •Bootstrapping examples: Fastmail’s low-cost scaling + paywall; consulting-style scoping projects
- •Profitability early by managing burn and charging for value
- •VC risk: growth pressure, misaligned incentives, and optimizing for VC-scale exits
- 1:32:21 – 1:40:05
Learning how to learn: spaced repetition, Anki, and long-horizon consistency
Jeremy explains spaced repetition (Ebbinghaus) and how tools like Anki operationalize memory scheduling. He shares why he uses it primarily for Chinese, emphasizes mnemonics and context, and argues that consistency—and forgiving lapses—is the hardest and most important part.
- •Spaced repetition basics: review intervals expand as memory strengthens; reschedule on failure
- •Anki as practical automation; prevents self-deception about what you truly remember
- •Jeremy’s use case: retaining Chinese despite limited real-world practice opportunities
- •Technique: memorable stories (funny/disgusting/relational) to boost recall
- •Consistency matters most; recovery after long breaks is difficult but possible and faster than initial learning
- 1:40:05 – 1:44:10
What matters next: stop predicting AGI, solve real problems, and take ethics seriously
Jeremy refuses to speculate on human-level AI timelines, arguing there’s no grounding data and the question distracts from urgent, solvable challenges. He focuses on societal impacts like labor displacement and calls on data scientists to treat ethics as a core responsibility in system design and deployment.
- •Skepticism about predicting major breakthroughs or AGI timelines
- •Belief: existing tools already solve many important unsolved problems
- •Major concern: labor displacement and middle-class hollowing out
- •Ethical obligations: human-in-the-loop design, appeals processes, avoiding feedback loops, communicating system limits
- •Data scientists must engage beyond “just engineering” due to high leverage and downstream impact
