By playing, you agree to uListen's Terms and Privacy Policy and YouTube's Terms of Service.

Sequoia Capital

Building the Automated AGI Lab: Core Automation's Jerry Tworek and Rohan Anil

Jerry Tworek led reasoning at OpenAI, convinced that scaling reinforcement learning was the path to AGI. Rohan Anil co-led Gemini pre-training and built the Shampoo optimizer.

Jerry TworekguestPat GradyhostSonya HuanghostRohan Anilguest

Jul 29, 202649mWatch on YouTube ↗

Summaries, chapters, transcripts, and FAQs on this page are made by uListen, not YouTube.

CHAPTERS

Jump to publisher timestamps

Chapter summaries

Learning from experience: why reinforcement learning isn’t the whole story
Jerry contrasts skill learning (like sports) with deep conceptual learning (like math) to argue that “learning from experience” includes multiple mechanisms. He frames reinforcement learning as important but incomplete, expecting new approaches to emerge beyond today’s RL-heavy compute spending.
- •Jerry compares iterative trial-and-error practice to reinforcement learning dynamics
- •Jerry contrasts that with slow, internal conceptual understanding while learning mathematics
- •Both modes are described as learning from experience, but in very different ways
- •Jerry says reinforcement learning isn’t the end state for learning from experience and better approaches will appear
Why replacing Transformers starts with appreciating what they do well
Asked about his “eulogy” tweet, Jerry explains that appreciating Transformers means understanding both their strengths and weaknesses. He argues most architecture work focuses on making Transformers cheaper rather than more powerful, and sets up the idea that the next bottleneck is architectural—not just more scaling.
- •Jerry says understanding a model’s strengths and weaknesses is the same kind of deep understanding
- •He observes that many efforts aim at cheaper/more efficient Transformers rather than increasing expressiveness
- •He frames the current era as mastering large-scale pre-training and large-scale reinforcement learning
- •Jerry says the key question now is “what’s next,” and he suspects architecture is the bottleneck
Why architecture feels like the bottleneck: lab training vs messy real-world deployment
Jerry explains the core tension: models are trained in controlled lab settings but deployed into much messier real-world distributions. He recounts his earlier belief that scaling RL would be a necessary stepping stone to AGI, then describes disappointment when benchmark gains didn’t translate to solving real-world tasks.
- •Jerry describes being an “RL maximalist” and expecting scaled RL to unlock major breakthroughs
- •He saw benchmark scores increase while real-world task performance still lagged
- •Jerry says training tasks and evaluations can become “two sides of the same coin”
- •He emphasizes the real world as messier and not well replicated by current training data
Test-time learning as the missing capability: limits of context and fine-tuning
Jerry argues that models need to learn at test time with users and real data, because current training data can’t cover the full real-world distribution. He outlines two current options—in-context learning and continuous fine-tuning—and explains why each hits hard limits (scale limits for context; forgetting and inefficiency for fine-tuning).
- •Jerry says labs struggle to find sufficiently “hard tasks” to train on, yet still miss real-world coverage
- •He proposes test-time learning: models learning with users on their data and tasks
- •He describes in-context learning as data-efficient and avoiding catastrophic forgetting, but not scalable enough
- •He describes continuous fine-tuning as running into catastrophic forgetting and low data efficiency
- •He concludes an architectural/meta-learned mechanism for learning over longer horizons is needed
Scaling and economics: Transformers weren’t inevitable, but they made scaling pay off
Jerry answers whether new architectures must look transformer-like by emphasizing economics and scaling behavior. He argues other architectures (like LSTMs) could be scaled technically, but Transformers made scaling economically valuable—training cost low enough relative to revenue—driving industry adoption.
- •Jerry claims scaling other architectures was technically possible, but economically unattractive
- •He points to better scaling behavior for Transformers compared to LSTMs
- •He says Transformers’ “majestic” property is economic value: cost-to-train versus revenue generated
- •He describes earlier reluctance in the research community to scale due to it seeming “unscientific,” and frames large-scale scalability as a contrarian bet that paid off
Why Core Automation exists: big labs can’t easily bet on alternatives
Rohan asks why do this work outside a big lab if it needs large compute, and Jerry explains the timing and incentives. He argues top labs are locked into competitive release cycles and short-term wins, making it hard to devote serious attention to alternative architectures, while smaller labs imitate leaders.
- •Jerry says leading labs are in intense competition and prioritize near-term wins
- •He argues profitable Transformers reduce incentive to explore risky alternatives
- •He says many organizations are converging on similar products (e.g., coding agents)
- •Core Automation positions itself as a niche player pursuing different paths and approaches
Rohan’s perspective on Transformers: compute allocation, inference costs, and autoregressive inefficiency
Rohan agrees with the “eulogy” framing and recounts early internal reactions when Transformers first appeared. He argues architecture should be judged by how it spends computation, and highlights that today’s compute burden is increasingly at inference time, where token-by-token generation and RL-driven chain-of-thought can be inefficient.
- •Rohan describes early Transformer reception as muted, with only a few people recognizing its importance
- •He defines architecture in terms of how computation is spent efficiently
- •He notes industry compute is heavily driven by inference and token generation
- •He frames RL for chain-of-thought as adding compute via one-token-at-a-time decoding
- •He calls speculative decoding a “band-aid” around autoregressive constraints
Computational depth problem: why shallow Transformers lean on long chains of thought
Rohan explains “computational depth” and why he views it as a limitation: many Transformers are not very deep in layers. He describes chain-of-thought and inference-time scaling as a way to increase depth through longer sequences, but emphasizes that this increases token costs and remains sequentially inefficient.
- •Rohan says many trained Transformers are relatively shallow in depth (layer count)
- •He frames chain-of-thought reasoning as one way to increase computational depth
- •He links inference-time scaling to stronger results via increased sequence length
- •He highlights the inefficiency of requiring more tokens produced one-at-a-time to get better outcomes
- •He suggests making this process more efficient as a key research direction
When Transformers top out: static training data, drift, and dependence on lab retraining loops
Jerry answers how far Transformers can go by describing their strengths—compressing internet knowledge via pre-training and baking workflows via RL. He then explains the cap: if training stops, models become less useful as the world changes, because usefulness depends on what’s present in training, forcing a slow loop of collecting failures and retraining in the lab.
- •Jerry says pre-training distills knowledge from the internet into a model
- •He says RL can “bake” desired workflows into a model given training data
- •He poses a thought experiment: if labs stopped training, usefulness would decay over time
- •He lists changes that break static training: new events, relationships, tasks, codebases, and tools
- •He describes the current fix as routing failures back into training data and lab retraining, rather than updating in place
Beyond reinforcement learning: “Age of Experience,” multiple learning mechanisms, and RL’s limits
Asked about a paper on experience, Jerry argues RL isn’t new and has repeatedly succeeded when models generate and learn from their own experience. But he emphasizes RL is only one mathematical formulation and may be compute-inefficient relative to how humans learn, suggesting multiple learning algorithms might be needed.
- •Jerry contrasts pre-training as static-data compression with RL as learning from generated experience
- •He says much online text may increasingly be AI-generated, making pre-training partly distillation of older models
- •He lists RL success stories across different domains to argue it’s a proven approach
- •He argues RL is not the only way to learn from experience and new approaches should emerge
- •He criticizes reliance on parallel rollouts/variance reduction as unlike human learning and suggests the brain uses multiple learning mechanisms
Optimization and efficiency: measuring the right thing and unifying pre-training with RL
Rohan argues efficiency improvements start with measurement and that perplexity-centric pre-training metrics miss the end goal. He claims the big win comes from combining pre-training and RL end-to-end, then digs into optimization work, why it was undervalued, and how optimization and architecture co-determine what models become feasible.
- •Rohan describes pre-training as compression driven by perplexity reduction and scaling trends
- •He argues this view is incomplete because RL can invalidate pre-training-centric metrics
- •He says combining pre-training and RL end-to-end is a major source of improvement
- •He recounts working on the Shampoo optimizer and notes initial lack of community excitement
- •He argues optimization and architecture are intertwined: stronger optimizers can enable harder-to-train architectures, and vice versa
Why biological efficiency is hard (and why labs struggle to integrate RL + pre-training)
Rohan doubts current systems will match biological learning efficiency given today’s hardware, and suggests more human-like (possibly analog) hardware could matter. He also explains why combining RL and pre-training isn’t organizationally or technically “obvious,” citing differing optimization dynamics and the pressure of release cycles.
- •Rohan says matching biological learning efficiency seems unlikely with current hardware
- •He contrasts humans “building” their own circuits over a lifetime with how neural networks operate on fixed hardware
- •He suggests more human-like/analog hardware might be necessary to close the gap
- •He says RL and pre-training pose very different optimization problems, making naive combinations fail
- •He points to competitive release cycles and short timelines as barriers to long-term integrated research
Building the most automated lab: empowering small teams to run faster experiments
Sonya asks about automating research, and Jerry reframes Core Automation’s goal as maximizing human agency rather than removing humans entirely. He describes how coding agents and new workflows change iteration speed, and lays out an ambition to rebuild the deep learning stack to enable rapid, repeated experimentation.
- •Jerry defines their automation goal as giving each human maximum agency and leverage
- •He uses analogies (bike, car, farming machines) to explain amplification rather than replacement
- •He says a single researcher can now do much more, changing how labs should be structured
- •He describes rebuilding the deep learning stack and rethinking “almost each operation”
- •He targets high iteration rates (at least one experiment a day, potentially far more) to search architecture space faster
Roadmap and kernel automation: accelerating the path from new ideas to high-performance GPUs
Rohan shares a near-term roadmap focused on kernel generation as a bottleneck for trying new architectures efficiently. He describes a QR kernel competition as evidence that major speedups require rare expertise plus expensive search, and argues today’s models can’t yet produce those results—so automating kernels unlocks a bigger algorithmic design space.
- •Rohan says good architectures must both work conceptually and run efficiently on hardware
- •He identifies kernel generation as the key bottleneck they want to automate away
- •He describes using their hardware stack to shorten the path from an architectural idea to high TFLOPS performance
- •He recounts a QR kernel effort where human expertise plus agent-driven search produced large speedups, while current models couldn’t solve it alone
- •He argues faster kernels change the feasible set of algorithms and open new architectural possibilities
What success looks like: continual learning in deployment and a “vacation test” for autonomy
Jerry summarizes Core Automation’s mission: build models that continuously learn from deployment, which he claims Transformers can’t do. He and Rohan discuss how they’ll know they’ve found the right direction—evidence of meaningful long-horizon adaptation—and joke about measuring progress by whether the lab improves while the team is away.
- •Jerry states their goal: models that continuously learn from deployment and a Transformer replacement to enable that
- •He says they’ll explore architecture space with many experiments and strong priors to search efficiently
- •Jerry says strong research often culminates in a distinctive “plot” that bends differently, typically late after many pieces align
- •He says the key capability target is meaningful long-term adaptability at test time
- •They describe evaluating systems on improving the team’s day-to-day work, including a joke about going on vacation to see if the lab produces better results

Publisher timestamps

Get more out of YouTube videos.

Read along on your phone, search it beside the video, or ask your favorite AI app what was said.