The Future is Products That Grow Themselves! | Jubin Chheda from Meta

@Scale

AI-assisted summary of The Future is Products That Grow Themselves! | Jubin Chheda from Meta — original source. Check the original for full context.

Source published: 2026-10-30

Key ideas

Code generation has been largely democratized by AI, shifting the primary bottlenecks in the software lifecycle to verification, hardware capacity, and human product judgment. (0:00)
Meta's autonomous optimization platform Volley achieves a higher experiment win rate than human baselines, delivering hundreds of millions in realized infrastructure savings and billions in identified potential savings. (11:50)
Project Ouroboros uses SFT, RFT, and GRPO to distill frontier model trajectories into compact specialist models (like Muse Glimmer), cutting inference costs up to 100x while maintaining quality parity. (14:01)
In recursive self-improving loops, the offline verifier must be powered by a significantly more capable model than the optimizer to prevent the entire loop from collapsing. (9:51)

Detailed notes

## Background This talk by Jubin Chheda from Meta was published on YouTube by @Scale on October 30, 2026. No accompanying video description or show notes were provided in the original upload.

## TL;DR Jubin Chheda explains that while code generation has become trivialized by AI, downstream verification, infrastructure capacity, and product judgment remain critical bottlenecks in software delivery. He outlines Meta's architecture for closed recursively self-improving loops—exemplified by Project WALL-E and the Volley platform—which pair optimizers with multi-tier verifiers and decision engines to autonomously optimize codebase capacity, generating hundreds of millions of dollars in realized infrastructure savings. Chheda further shows how cold-starting verifiers allows engineering teams to transition from human-in-the-loop review to human-on-the-loop oversight. Finally, he presents Project Ouroboros, a method for capturing frontier model trajectories to distill lightweight specialist models using SFT and reinforcement learning, drastically cutting inference latency and cost.

## Atmosphere & style The presentation strikes an authoritative, fast-paced, and pragmatic tone, anchoring futuristic concepts of recursive self-improvement in the hard realities of hyperscale infrastructure. Chheda weaves evocative imagery—swarms scaling hills, Pixar's WALL-E, and the mythic Ouroboros—directly into rigorous system architecture diagrams, mathematical trade-offs, and bottom-line dollar impacts. The talk feels like a technical, insider briefing that demystifies agentic autonomy, moving from the friction of modern engineering bottlenecks to an inspiring blueprint for self-evolving software systems.

## Bulletin - [00:00](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=0s) Code generation has been largely democratized by AI, shifting the primary bottlenecks in the software lifecycle to verification, hardware capacity, and human product judgment. - [11:50](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=710s) Meta's autonomous optimization platform Volley achieves a higher experiment win rate than human baselines, delivering hundreds of millions in realized infrastructure savings and billions in identified potential savings. - [14:01](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=841s) Project Ouroboros uses SFT, RFT, and GRPO to distill frontier model trajectories into compact specialist models (like Muse Glimmer), cutting inference costs up to 100x while maintaining quality parity. - [09:51](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=591s) In recursive self-improving loops, the offline verifier must be powered by a significantly more capable model than the optimizer to prevent the entire loop from collapsing.

## Key takeaways - [00:00](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=0s) Recursive self-improvement mirrors a swarm of agents climbing a hill: successful paths are distilled so the next generation can tackle taller hills in parallel. - [00:00](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=0s) Downstream stages of software delivery—ideation, roadmapping, verification, and experimentation—remain at human-level speeds, creating operational logjams as code generation accelerates. - [02:29](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=149s) Because generative diffs are virtually free to produce, product taste and filtering judgment have replaced generation as the scarce operational asset. - [02:29](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=149s) Even a 1% defect leakage in verification can lead to an untenable volume of defective code reaching production at modern automated scale. - [04:14](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=254s) A closed recursive self-improvement loop requires four discrete stages: an optimizer, a multi-gate verifier, an experimentation decision-maker, and a recursive meta-learner. - [04:14](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=254s) Verification must span three distinct tiers: offline formal semantic verification, predictive risk and outage assessment, and live online A/A or A/B testing. - [07:03](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=423s) Project WALL-E targets latent infrastructure inefficiencies—such as dead feature flags, deprecated logging, and unbatched queries—using a catalog of roughly 50 canonical capacity patterns. - [09:51](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=591s) Cold-starting automated verification begins with human code reviews, distilling acceptance and rejection rationales into automated rule sets over 10 to 50 diffs. - [09:51](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=591s) Engineering teams must shift from a 'human-in-the-loop' operational model to a 'human-on-the-loop' supervisory posture, intervening only on novel edge cases. - [09:51](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=591s) The offline verifier must be substantially more powerful than the proposing optimizer; using a weaker verifier causes the self-improvement loop to collapse. - [11:50](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=710s) Meta's Volley platform leverages historical experiment telemetry to build a trade-off calculus, allowing agents to accurately forecast experiment success before deployment. - [14:01](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=841s) Relying strictly on frontier models introduces cost and compute scaling ceilings, necessitating distillation of execution trajectories into lightweight specialist architectures. - [14:01](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=841s) Applying RFT and GRPO to compact models achieves domain-specific parity with frontier models while slashing inference costs by 8x to 100x and drastically accelerating iteration cycles. - [16:39](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=999s) Autonomous systems increase rather than diminish the value of human leadership, elevating human intent and strategic boundary-setting as the ultimate steering mechanism.

## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=0s) The Promise of Recursive Self-Improvement in Product Development

Jubin Chheda opens with a striking mental model: an entire swarm of autonomous agents attempting to scale a hill. While many paths fail and many attempts fall short, some inevitably reach the summit. The breakthrough occurs when those agents distill their learnings and replicate into a superior generation of agents tasked with climbing an even taller hill—executed not once or twice, but hundreds, thousands, and millions of times simultaneously in parallel. As Chheda frames it, this is recursive self-improvement in practice: “In this talk, we have a dragon that eats its tail, we have a beloved character, and we have billions of dollars of savings to be had.”

While coding itself has been roughly 100% democratized—to the point where nearly all code diffs today are generated by artificial intelligence—the rest of the software delivery lifecycle has lagged dramatically behind. Across product ideation, roadmapping, verification, experimentation, and finding product-market fit, non-coding disciplines still progress at human-level speeds. Because coding velocity has exploded, the traditional downstream stages have been squeezed into severe operational bottlenecks: - **Verification Bottleneck:** Ensuring that generated code behaves precisely as intended without introducing security flaws or operational vulnerabilities has become an all-time red-hot crisis. - **Hardware Capacity Bottleneck:** Hardware constraints, including industry-wide chip, memory, GPU, and CPU shortages, strictly cap how many speculative product changes an engineering organization can physically evaluate simultaneously. - **Decision-Making Bottleneck:** The raw volume of generated diffs overwhelms human capacity to arbitrate what to build, test, and ship.

---

[02:29](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=149s) The Core Bottlenecks: Judgment, Product Taste, and Verification

Because modern generative models can produce candidate code changes at the nominal cost of tokens, the universe of what could theoretically be built has effectively become infinite. The central operational challenge has shifted from generation to filtering and taste. As Chheda observes: “The bottleneck now becomes the judgment around which of those ideas are worth pursuing for your organization.”

Developing that judgment requires nuanced product taste, which functions like an acquired culinary palate: an engineer or system must sample and evaluate thousands of dishes before internalizing true refinement. Compounding the challenge is the harsh arithmetic of verification leakage. If an automated gate allows even a 1% defect rate through thousands of iterations, the sheer throughput of modern automated tooling ensures that an untenable amount of low-quality, high-risk code enters production. Resolving this requires architecting a tightly verified closed loop capable of running millions of autonomous public A/B tests.

---

[04:14](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=254s) Anatomy of a Closed Recursively Self-Improving Loop

To automate product iteration safely, organizations must assemble a closed system comprising four discrete components: an optimizer, a verifier, an experimentation decision-maker, and a meta-learning recursive engine.

```mermaid flowchart TD accTitle: Closed Recursively Self-Improving Loop accDescr: An architecture diagram illustrating the four-stage cycle of an Optimizer, Verifier, Decision Maker, and Learner.

subgraph Generation ["1. Code Generation"] A["Optimizer / Proposer"] end

subgraph Verification ["2. Verification Stage"] B["Formal Verification (Offline)"] C["Risk & Safety Assessment (Offline)"] D["A/A & A/B Live User Testing (Online)"] end

subgraph Evaluation ["3. Decision & Feedback"] E["Decision Maker (Launch / No-Launch)"] F["Learner (RSI Engine)"] end

A -->|"proposes code diffs"| B B -->|"semantic check passed"| C C -->|"risk check passed"| D D -->|"experiment telemetry"| E E -->|"experiment outcomes"| F F -.->|"updates & refines"| A F -.->|"updates & refines"| B F -.->|"updates & refines"| E ```

The loop progresses across specific stages: 1. **The Optimizer:** Proposes and writes code changes calibrated toward concrete product key performance indicators (KPIs), such as daily active users (DAU), session duration, platform stability, or compute infrastructure cost recovery. 2. **The Verifier:** An agentic gatekeeper tasked with confirming that code reliably advances the target objective without introducing operational or regulatory debt. Verification happens across three distinct gates: - *Formal Verification (Offline):* Semantically guarantees that the diff accomplishes the explicit objective. - *Risk Assessment (Offline):* Uses predictive models to quantify the probability of an outage, privacy regression, policy violation, or regulatory breach. - *Online Verification:* Deploys the change to a small slice of live traffic in an A/A or A/B test to validate empirical real-world impact. 3. **The Decision Maker:** Ingests post-experiment statistical telemetry across DAU, sessions, latency, reliability, and quality metrics to render an automated launch or no-launch verdict. 4. **The Recursive Learner:** Ingests telemetry, approvals, and post-mortems from every phase—especially the decision-making stage—to continually retrain and fine-tune the optimizer, the verifiers, and the decision engine itself.

---

[07:03](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=423s) Project WALL-E: Autonomous Capacity Optimization

Meta implemented this architecture through an initiative named WALL-E, inspired by the Pixar film where a solitary robot continuously repairs a deserted planet while upgrading its own components. In an infrastructure setting, recursive optimization targets CPU cycles, GPU utilization, and memory footprints, unlocking hundreds of millions of dollars in annualized savings by rooting out subtle code smells that accumulate across large codebases: - **Dead Gates:** Conditional feature flags introduced for rollouts that were either fully shipped or abandoned; though defaulting permanently to `true` or `false`, they still consume CPU cycles during evaluation. - **Dead Logging:** Diagnostic logging originally injected to monitor a rollout or debug an incident, whose downstream data pipelines or dashboards have long been deprecated, turning log emission into pure capacity waste. - **Suboptimal Query Batching:** Missed opportunities to batch database requests or convert latency-sensitive RPC paths into high-throughput asynchronous batch operations.

Meta consolidated these recurring inefficiencies into a library of approximately 50 canonical capacity patterns mined from years of engineering history. To target them, an autonomous optimizer needs only three fundamental tools: - **Code Smell Scanner:** A fast search engine (often as straightforward as tailored regex patterns over repositories) targeting database queries or dead code paths to generate candidate targets. - **Code Editor & Navigator:** Standardized developer tooling allowing an agent to traverse symbols, read dependencies, and apply diffs cleanly. - **Fleet Cost Profiler:** Telemetry tooling that attributes overall CPU, GPU, and memory utilization back to specific function calls as a percentage of the entire fleet, enabling agents to prioritize optimizations by financial impact.

---

[09:51](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=591s) Cold-Starting WALL-E and Transitioning from Human-in-the-Loop to Human-on-the-Loop

Cold-starting a self-improving infrastructure loop begins with human-in-the-loop oversight. In the opening phase, human engineers manually review every diff generated by the optimizer. However, every time an engineer accepts or rejects a proposal, their review rationale is distilled into automated rule sets and prompts within an agentic offline verifier. After processing 10 to 50 diffs in this manner, the offline verifier becomes sufficiently robust that human engineers can step away from manual code review.

Chheda highlights a non-negotiable architectural requirement: “The key step here is to make sure the offline verifier uses a model that is much more powerful than the model that powers the optimizer. If the verifier is weaker than the optimizer, the loop collapses.”

Once offline validation is stable, the system orchestrates online experiments and automates metric readouts, independently deciding whether an experiment should launch to 100%, iterate, or abort. The overarching operational objective is shifting engineers from a *human-in-the-loop* model—where humans are required for routine steps—to a *human-on-the-loop* posture, where humans act purely as supervisors who intervene only when edge-case exceptions arise. Freeing humans from the critical path allows organizations to scale agentic generation and optimization to unprecedented volume.

[11:50](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=710s) Building the Optimizer, Cold-Starting Verifiers, and Volley's Financial Impact

To generate step-function value for an organization, an automated system cannot simply produce tens, hundreds, or thousands of code edits; it must be designed to churn out millions of changes on an hourly, daily, or weekly cadence. Jubin Chheda breaks down the mechanical anatomy of constructing the system's core optimizer (or oracle). The foundation requires a rich historical repository of successful optimization experiments run against the codebase, combined with detailed treatment semantics and comprehensive readouts. Analyzing these thousands of historical runs allows the system to extract patterns, assemble a formal pattern catalog, and construct an explicit mathematical calculus governing the domain's operational trade-offs. Equipped with this calculus, an AI agent can ideate new optimization levers or sample existing levers more aggressively, projecting with high statistical confidence whether a proposed intervention will succeed before deploying it.

```mermaid flowchart TD accTitle: Closed-Loop Optimization and Verification Architecture accDescr: Diagram showing how historical experiments inform an optimizer to generate candidate changes, which are verified by a feedback-trained verifier before deploying at scale.

subgraph Optimization["Optimizer (Oracle)"] A["Historical Experiments & Semantics"] --> B["Pattern Catalog & Trade-off Calculus"] B --> C["AI Optimizer Agent"] C --> D["Candidate Code Changes"] end

subgraph Verification["Verification Harness"] D --> E["Verifier Engine"] F["Human Review & Feedback"] -->|"Cold Start & Novel Rules"| E E --> G{"Passes Verification?"} G -->|"Yes"| H["Production Launch"] G -->|"No"| C end ```

The verification harness follows an evolutionary trajectory that starts with human engineering knowledge. Incoming candidates from the optimizer are initially routed to human reviewers, whose feedback and failure analyses are collated to cold-start the automated verifier. Each time an engineer catches an edge case or supplies a novel critique, that reasoning is codified into the verifier’s test suite, expanding its domain competence. Chheda notes that this flywheel rapidly outpaces manual review boards: “Once you have that, very quickly you will have a verifier that is much more reliable than any particular human team of reviewers you would be able to have.”

At Meta, this architecture powers Volley, an autonomous optimization platform that has delivered massive infrastructure efficiency gains. Volley's experiment success rate now significantly eclipses human engineering baselines. In production, Volley has directly generated hundreds of millions of dollars in realized infrastructure savings, while its optimizer models have identified efficiency pipelines representing billions of dollars in potential savings across Meta's footprint.

- The optimizer relies on past experiment histories, treatment semantics, and comprehensive telemetry to form a pattern catalog and trade-off calculus. - Human review feedback is used to cold-start the verifier, integrating every novel human intervention into subsequent automated verification cycles. - Volley’s win rate for deployed experiments is demonstrably higher than the human baseline. - Realized infrastructure savings from Volley stand in the hundreds of millions of dollars, with identified potential savings reaching into the billions.

---

[14:01](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=841s) Project Ouroboros: Distilling Frontier Trajectories into Specialist Models

Even with Volley's financial returns, relying solely on massive frontier models creates a scaling ceiling. Chheda introduces Meta's Ouroboros concept—named after the ancient symbol of a dragon eating its own tail—to describe a recursive distillation architecture. Rather than routing all inference calls to massive state-of-the-art systems, Ouroboros creates compact, highly specialized models tailored specifically for capacity optimization tasks.

```mermaid flowchart LR accTitle: Ouroboros Recursive Distillation Pipeline accDescr: Shows the pipeline distilling large frontier model trajectories into smaller specialized models using fine-tuning and reinforcement learning.

subgraph Distillation["Trajectory Harvesting"] A["Frontier Model (e.g., Llama / Muse Series)"] -->|"Generates Trajectories"| B["Optimization Trajectory Dataset"] end

subgraph Training["Specialist Optimization"] B --> C["Small Model (e.g., Muse Glimmer)"] C --> D["SFT (Supervised Fine-Tuning)"] D --> E["RL: RFT & GRPO"] E --> F["High-Velocity Specialist Agent"] end ```

The process begins by deploying a state-of-the-art frontier model (such as Meta's internal large models from the Muse series) to generate optimization attempts and trajectories over several months. Meta captures the end-to-end execution trajectories produced by these large models and uses them as synthetic training data to distill smaller open architectures, such as Muse Glimmer. The team applies Supervised Fine-Tuning (SFT) alongside advanced reinforcement learning paradigms—specifically Rejection Sampling Fine-Tuning (RFT) and Group Relative Policy Optimization (GRPO)—enabling the smaller network to hill-climb aggressively on capacity optimization tasks.

This specialized training narrows the performance delta between model tiers. The compact specialist matches and occasionally outperforms the larger frontier model, which, while more novel, carries excess generalist baggage. Distillation also unlocks a “triple whammy” advantage across cost, speed, and transferability: 1. **Quality parity:** The specialist hones in on the target domain without distraction. 2. **Drastic cost reductions:** Inference costs plummet to 1/8th, 1/20th, or even 1/100th of the cost of running frontier models. 3. **Latency and iteration speed:** Lower inference latency accelerates the cycle time of the recursive self-improvement (RSI) loop, allowing significantly more candidate evaluations per hour. 4. **Domain transfer:** Techniques and models fine-tuned on capacity optimization transfer effectively to adjacent engineering constraints, including service reliability and latency tuning.

---

[16:39](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=999s) The Strategic Imperatives of Recursive Self-Improvement

Chheda concludes by outlining three strategic lessons for engineering leaders navigating agentic software development:

First, automation does not render human judgment obsolete; rather, human intent becomes the ultimate steering mechanism. As Chheda states: “The role of human decision making is now at an all-time high with recursively self-improving agents.” While autonomous loops dramatically accelerate shipping velocity, human engineers must still decide what product bets to fund, what organizational outcomes matter, and which boundaries the agents must respect.

Second, the closed verification loop serves as the critical bottleneck. Recursive self-improvement cannot begin without a deterministic or highly reliable automated harness to evaluate outputs. Once an organization makes the foundational investment to close this loop, the agents can independently improve the codebase, optimize product behavior, and streamline company operations.

Third, system architectures must adopt specialist models to navigate compute constraints. With mounting pressure on GPU allocations, CPU capacity, and memory bandwidth, running every step through heavyweight frontier models is economically unsustainable. Deploying fast, inexpensive specialist agents preserves the latency and economic headroom needed to maximize the velocity of self-improving systems.

Chheda ends with an open invitation to collaborate and leaves the audience with a guiding mantra for the agentic era: “Define the loop. Let the agents climb.”

## Notable quotes > [16:39](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=999s) The role of human decision making is now at an all-time high with recursively self-improving agents. — Jubin Chheda

> [09:51](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=591s) The key step here is to make sure the offline verifier uses a model that is much more powerful than the model that powers the optimizer. If the verifier is weaker than the optimizer, the loop collapses. — Jubin Chheda

## Mentioned Jubin Chheda, Meta, Pixar, WALL-E, Volley, Ouroboros, Llama, Muse, Muse Glimmer

[Source](https://www.youtube.com/watch?v=ZNL2ir1EoIY)

中文简报

未来属于自我进化的产品！| Meta的Jubin Chheda Jubin Chheda解释说，尽管代码生成已被AI大幅简化，但下游验证、基础设施算力容量以及产品判断依然是软件交付中的关键瓶颈。他概述了Meta的闭环递归自我改进架构——以Project WALL-E和Volley平台为例——该架构将优化器与多层验证器和决策引擎相结合，以自主优化代码库容量，实现了数亿美元的基础设施成本节约。Chheda进一步展示了冷启动验证器如何让工程团队从“人在环路内”（human-in-the-loop）审查转变为“人在环路上”（human-on-the-loop）监督。最后，他介绍了Project Ouroboros，这是一种通过捕获前沿模型轨迹，并利用SFT和强化学习蒸馏出轻量级专用模型的方法，从而大幅降低了推理延迟和成本。代码生成已在很大程度上被AI普及化，软件生命周期中的主要瓶颈由此转移到了验证、硬件容量和人类产品判断上。 (0:00) Meta的自主优化平台Volley实现了比人类基准更高的实验胜率，带来了数亿美元已实现的基础设施节省，并发现了数十亿美元的潜在节省空间。 (11:50) Project Ouroboros利用SFT、RFT和GRPO将前沿模型轨迹蒸馏为紧凑的专用模型（如Muse Glimmer），在保持同等质量的同时将推理成本降低高达100倍。 (14:01) 在递归自我改进循环中，离线验证器必须由比优化器能力强得多的模型来驱动，以防止整个闭环崩溃。 (9:51)

Reading summary

Meta's Jubin Chheda argues that while AI has commoditized code generation, realizing scalable software progress requires closed, recursively self-improving loops where autonomous agents propose, verify, and launch changes against concrete product metrics. The Bottleneck Shift to Verification and Judgment (2:29) Because generative models produce candidate code changes at negligible token cost, code generation is no longer the primary constraint in software engineering. Instead, downstream stages—ideation, verification, experimentation, and decision-making—remain bound to human velocity. This dynamic creates operational friction around judgment and safety. With effectively infinite diff proposals, determining which interventions are worth pursuing requires refined organizational taste. Compounding this challenge is the risk of verification leakage. Chheda notes that even a 1% defect rate passing through automated evaluation produces an unacceptable volume of production failures when run across thousands of iterations. Furthermore, physical hardware constraints, including industry-wide shortages of GPUs, CPUs, and memory, strictly limit how many speculative code paths an organization can simultaneously benchmark in production. Anatomy of an Asymmetric Closed Loop (4:14) Safely automating code iteration requires a closed system operating across four roles: an optimizer that proposes code diffs aligned with key performance indicators; a verifier that screens diffs; an experimentation decision maker that executes automated launch or no-launch calls; and a recursive learner that refines the entire system using post-experiment telemetry. Verification functions across three gates: offline formal semantic checks, predictive offline risk modeling for outages or policy violations, and online A/A or A/B testing on live traffic. Crucially, Chheda emphasizes that the offline verifier must run on a significantly more capable model than the optimizer proposing the code. If the verifier is weaker than the proposer, the closed loop degrades. Cold-starting the loop relies on human engineers reviewing early proposals; by capturing the rationale behind 10 to 50 accepted or rejected diffs, the system codifies automated rules that allow humans to transition from active participants (human-in-the-loop) to exception-handling supervisors (human-on-the-loop). Autonomous Infrastructure Optimization with WALL-E and Volley (7:03) Meta operationalized this architecture through initiatives named Project WALL-E and Volley, focusing on infrastructure capacity recovery across CPU cycles, GPU utilization, and memory footprints. The system targets approximately 50 canonical capacity patterns mined from historical data, including dead feature flags that still burn CPU cycles during evaluation, deprecated diagnostic logging pipelines, and unbatched database queries. The autonomous optimizer operates using three core components: a pattern scanner over code repositories, a code editor and symbol navigator, and a fleet cost profiler that maps resource utilization directly to function calls. According to Chheda, Volley's automated experiment win rate has surpassed human engineering baselines, yielding hundreds of millions of dollars in realized infrastructure savings and uncovering pipelines with billions of dollars in prospective efficiency gains. Project Ouroboros: Model Distillation for Scalability (14:01) Relying exclusively on massive frontier models to drive continuous optimization introduces severe compute and cost bottlenecks. Meta's Project Ouroboros addresses this scaling ceiling by distilling execution trajectories from large frontier models (such as internal Muse models) into smaller, highly specialized architectures like Muse Glimmer. By combining supervised fine-tuning with reinforcement learning techniques—specifically Rejection Sampling Fine-Tuning and Group Relative Policy Optimization—the smaller models achieve parity with, and occasionally outperform, generalist frontier models on domain-specific capacity tasks. This specialized distillation cuts inference costs to between 1/8th and 1/100th of frontier levels, lowers execution latency to allow faster cycle times, and yields optimization techniques that transfer cleanly to adjacent engineering challenges like service reliability and latency reduction. Chheda concludes that while autonomous recursive loops shift execution entirely to agents, the importance of human judgment reaches an all-time high. Human engineers remain necessary to set organizational targets, allocate capital, and establish operational guardrails, after which deterministic verification harnesses allow agents to scale optimization autonomously.

精炼阅读摘要

Meta 的 Jubin Chheda 提出，随着人工智能生成代码的普及，软件工程的瓶颈已转向验证、判断与硬件算力限制；通过构建具备递归自优化的闭环系统与专用小模型，产品与底层架构可以实现自主迭代与规模化降本。软件交付新瓶颈与判断力的转移 (0:00) Chheda 指出，当前代码编写本身已基本普及，几乎所有代码 diff 均可由人工智能生成，但构思、规划、验证、实验与产品契合度探索等非编码环节仍停留在人工速度。生成成本的降低使得理论上可构建的内容趋于无限，工程的核心挑战因而从“能否生成”转变为“如何过滤和判断哪些想法值得投入”。与此同时，验证漏洞、决策过载以及行业范围内的芯片、内存、GPU 和 CPU 硬件短缺，严格限制了团队并行评估投机性代码变更的能力。Chheda 强调，若自动化验证存在哪怕 1% 的缺陷遗漏率，在巨大的吞吐量下也会导致不可承受的高风险代码流入生产环境，因此必须依赖严格的自动化闭环来解决质量与安全问题。递归自优化闭环的四大核心组件 (4:14) 为了安全地实现自主产品迭代，组织需要搭建一个包含四个环节的递归自优化闭环：第一是优化器（Optimizer），根据日活跃用户、停留时长、稳定性或基础设施算力成本等具体关键绩效指标提出并编写代码变更；第二是验证器（Verifier），设立离线形式化语义验证、离线风险与合规预测模型评估，以及在线小流量 A/A 或 A/B 测试这三道防线，确保变更不会引入故障或合规债务；第三是决策引擎（Decision Maker），基于实验后的多维遥测数据自主判定是否全量发布或中止；第四是递归学习器（Recursive Learner），将各阶段的数据与决策记录用于重新训练和微调优化器与验证器。Chheda 强调，系统能够稳定运行的一个不可妥协的前提，是离线验证器所采用的模型能力必须远强于优化器所用的模型，否则整个优化循环将会崩溃。从人工介入到人巡回路的冷启动实践 (7:03) Meta 在代号为 WALL-E 的基础设施容量优化项目中验证了这套闭环机制。该系统梳理出过去工程经验中沉淀的约 50 种典型容量损耗模式，包括虽已全量或废弃但仍在空转评估的废弃特性开关、无下游消费的废弃日志输出，以及未合并的低效数据库查询。系统通过扫描代码异味、调用标准开发工具修改依赖，并结合成本遥测工具定位消耗 CPU、GPU 与内存的具体函数调用。在系统冷启动阶段，人类工程师人工审查优化器生成的代码，但每次审核理由都会被固化为离线验证器的规则与提示词；Chheda 称在处理 10 到 50 个 diff 后，离线验证器的可靠性即足以让人类退出常规审查。工程师的角色由此从必须参与常规流程的“人工在回路”（Human-in-the-loop），转变为仅在异常边界情况下介入监督的“人巡回路”（Human-on-the-loop）。 Volley 系统成效与 Ouroboros 模型蒸馏 (11:50) 基于该架构构建的 Meta 自主优化平台 Volley，其上线实验成功率已超过人类工程师基线，已实现数亿美元的基础设施成本节省，且优化器模型识别出的潜在优化管线规模达到数十亿美元。然而，完全依赖庞大的通用前沿模型会遭遇算力与成本上限。为此，Meta 推出了代号为 Ouroboros 的递归蒸馏方案：首先利用 Muse 系列等前沿大模型在数月内累积优化轨迹数据，随后将其作为合成数据，结合监督微调（SFT）以及排斥采样微调（RFT）与组相对策略优化（GRPO）等强化学习算法，训练出专精于容量优化的紧凑型模型（如 Muse Glimmer）。此类专精小模型在目标任务上的表现比肩甚至偶超前沿模型，同时推理成本降至前沿模型的八分之一、二十分之一乃至百分之一，更低的延迟加快了闭环迭代速度，且相关优化技术可迁移至延迟调优和服务可靠性等工程领域。 Chheda 总结指出，递归自优化并不意味着人类判断力的终结，人类的意图与边界设定反而在系统治理中处于最高战略地位。建立确定且高可靠的闭环验证体系是启动自优化的核心瓶颈，而结合低成本专精模型是克服算力制约、维持高频自主迭代的必要路径。

Detailed notes — zh

## Background 本内容由 YouTube 频道 @Scale 于 2026 年 10 月 30 日发布，主讲人为来自 Meta 的 Jubin Chheda。视频页面未提供额外的简介说明，核心聚焦于能够实现自我增长与递归自改进的产品架构。 ## TL;DR Meta 的 Jubin Chheda 探讨了AI代码生成普及后引发的验证、算力与决策瓶颈，并提出了基于优化器、验证器与决策者的“闭环可验证系统”（RSI）。演讲结合 Meta 内部的 Wally 和 Volley 系统实战，展示了如何利用自动化闭环消除死代码与低效查询，从而带来数亿美元级的算力成本节约。此外，Chheda 还介绍了“衔尾蛇架构”，即通过前沿大模型蒸馏微调小型专精模型以实现更高吞吐与更低推理成本。最后他强调，人类在战略决策与闭环定义上的定位依然不可替代。 ## Atmosphere & style 演讲整体呈现出极具前瞻性与扎实工程感的技术分享氛围，语调既富有远见又严谨落地。Chheda 借用智能体登山、机器人 WALL-E 以及衔尾蛇等生动意象，将复杂的系统架构与工程挑战剖析得引人入胜。整场分享节奏明快，从行业瓶颈的现实警示逐步走向突破性的落地成果与降本数据，最终在富有号召力的行业愿景中收尾，给观众带来兼具震撼力与启发性的听觉体验。 ## Bulletin - [11:50](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=710s) Meta 内部落地的递归自改进（RSI）系统 Volley 已经运行了数千次线上优化实验，其实际实验成功率已显著超越人类工程师基线，为 Meta 实际节省数亿美元成本，挖掘的潜在节省空间高达数十亿美元。 - [00:00](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=0s) 随着 AI 代码生成普及率逼近 100%，研发核心瓶颈已全面转移至形式化验证、风险评估、芯片算力容量以及决定‘构建与发布什么’的顶层决策制定。 - [09:51](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=591s) 在自演化系统的工程实践中存在一条铁律：离线验证器所采用的模型必须远强于驱动优化器的模型，否则整个验证闭环将直接崩溃失效。 - [14:01](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=841s) 通过对前沿大模型轨迹进行蒸馏并结合强化学习（GRPO），团队打造出小型专精模型，在特定优化任务上质量比肩甚至超越通用大模型，推理成本降低至 1/8 到 1/20（极端情况达 1/100）且大幅压缩了延迟。 ## Key takeaways - [00:00](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=0s) 代码编写已近乎 100% 普及，当前绝大部分代码差异（diff）均由 AI 生成，但产品开发全周期的其他环节仍受限于人类时间尺度。 - [00:00](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=0s) AI 代码井喷使四大要素成为新型研发瓶颈：验证困难度、芯片算力容量、产品品味沉淀以及发布层面的决策制定。 - [03:52](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=232s) 闭环可验证系统由优化器（Optimizer）、验证器（Verifier）、决策者（Decision Maker）和学习器（Learner）四大核心组件构成，实现自闭环驱动。 - [03:52](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=232s) 严密的验证架构应包含离线层面的形式化语义验证与故障/合规风险评估，结合在线流量环境下的 A/A 或 A/B 测试多层把关。 - [07:03](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=423s) 针对算力容量优化的实战智能体 Wally 重点清理死逻辑门、僵尸日志以及未批处理查询等约 50 种常见工程反模式。 - [09:51](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=591s) 研发运维模式应从人在回路中（Human-in-the-loop）逐步跃迁为人在回路之上（Human-on-the-loop），工程师仅在异常时介入。 - [09:51](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=591s) 验证器所使用的模型能力必须严格强于优化器所用的模型，这是保障递归自改进闭环不崩溃的基石法则。 - [11:50](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=710s) 利用历史优化实验数据沉淀出的模式目录和权衡法则，优化器能自主构想优化假设并精准预测线上 A/B 测试的胜率。 - [14:01](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=841s) 衔尾蛇（Ouroboros）架构通过 SFT/RFT 与 GRPO 强化学习，将前沿大模型的轨迹知识蒸馏迁移至小型专精模型中。 - [14:01](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=841s) 小型专精模型不仅在垂直优化任务上表现出高精度，更以 1/8 至 1/20 的推理成本与更低延迟，为系统实现高频次大规模 RSI 闭环提供了可能。 - [14:01](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=841s) 算力容量优化场景中训练出的小型专精智能体，对系统可靠性（Reliability）和延迟（Latency）优化任务表现出良好的跨域迁移学习能力。 - [16:39](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=999s) 在智能体具备超高执行效率的时代，人类在顶层战略方向、资金配置、核心业务领域指引与最终发布拍板上的决策价值达到历史新高。 ## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=0s) 递归自我改进：智能体蜂群的崛起与全新瓶颈 Meta 的 Jubin Chheda 提出了一个思想实验：想象一群智能体（swarm of agents）正在攀登一座山峰。它们进行了无数次尝试，探索了无数条路径，虽然经历了大量的失败，但最终仍有一部分成功登顶。接着，这群智能体将所有学到的经验教训复制并迭代为更强大的蜂群，去攀登更高耸的山脉；而这一过程在底层以成百、成千乃至数百万次的规模全并行展开。这种机制正是所谓的“递归自我改进”（Recursive Self-Improvement，RSI）。Chheda 形象地比喻，这就像一条衔尾蛇（Ouroboros）、一个深受喜爱的机器人角色，以及背后等待被释放的数十亿美元潜在节约。在当前的工程实践中，代码编写已基本实现了 100% 的平民化普及。正如 Jubin Chheda 所断言：“Coding has democratized about 100%. I would say almost all diffs today are AI generated.”（代码编写已几乎 100% 普及；如今几乎所有代码差异/diff 都是由 AI 生成的）。然而，纵观从产品构想、功能发布到寻找产品市场契合点（PMF）的整个完整产品开发周期，除了单纯编写代码以外，其他所有环节在客观上仍然按照人类的时间尺度在运转。写代码的速度呈爆炸式增长，使得未经提速的其他环节瞬间变成了严峻的瓶颈： - **验证（Verification）瓶颈**：已达到前所未有的白热化状态，要确保 AI 生成的代码完全符合意图、且不引入安全等各类潜在风险，变得极其困难。 - **算力容量（Capacity）瓶颈**：内存、GPU 和 CPU 等芯片层面的短缺，极大限制了一次性能够并行探索和落地的产品变更数量。 - **决策制定（Decision-making）瓶颈**：随着 diff 数量井喷，决定“构建什么、测试什么、发布什么”的能力已成为最大瓶颈；当可选候选方案由于极低的 token 成本而逼近无限时，如何针对组织目标精准判断哪些 idea 值得推进便成了核心挑战。 - **产品品味（Product Taste）与验证容错**：产品品味需要大量试错来积累（“就像必须吃过很多道菜才能提升品味一样”）；此外，若验证机制在成千上万次迭代中漏掉了哪怕 1% 的不良变更，累积流入生产环境的劣质代码也将相当惊人。 --- ### [03:52](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=232s) 闭环可验证系统：优化器、验证器与决策者的协同针对上述挑战，Jubin Chheda 提出了解决之道：构建一个闭环可验证系统（Closed Verifiable Loop），并在公共 A/B 测试中运行成百上千万次，从而为产品和企业创造巨大价值。他将本次演讲的核心内容概括为三点：闭环验证流程、一套用于节省算力容量的 RSI 方案，以及针对模型与测试框架层（Harness Layer）的 RSI 系统。 ```mermaid flowchart TD accTitle: Closed Verifiable Loop Architecture accDescr: An iterative loop showing the optimizer, verifier, decision maker, and learner stages. subgraph Execution ["执行与评估阶段"] A["Optimizer（优化器）<br/>生成代码变更"] --> B["Verifier（验证器）<br/>离线/在线风险把关"] B --> C["Decision Maker（决策者）<br/>评估 A/B 测试指标并拍板"] end subgraph Feedback ["自改进阶段"] C --> D["Learner（学习器）<br/>提取决策与执行数据"] D -.->|"提升生成质量"| A D -.->|"严密安全网"| B D -.->|"校准发布标准"| C end ``` 这种递归自改进闭环由几个紧密串联的核心组件构成： 1. **优化器（Optimizer）**：负责提出并编写能够针对性优化产品核心指标（如会话数 Session、DAU、系统稳定性或成本回收）的代码改动。 2. **验证器（Verifier）**：一个基于智能体（Agentic）的关卡，确保只放行那些能稳定提升目标函数且不引入额外风险的改动；分为离线验证和在线验证。 3. **决策者（Decision Maker）**：当变更通过验证并部署到部分用户群体进行 A/B 测试后，根据 DAU、留存、性能、可靠性等全方位指标数据，做出最终的“发布（Launch）”或“不发布（No-launch）”判定。 4. **学习器（Learner）**：这是赋予整个系统“递归自改进”属性的关键。它捕获决策环节及各阶段的最终结果，提炼出反馈信号，反哺并强化优化器、验证器和决策者本身，让闭环能够无限循环自我进化。关于验证环节的纵深设计，主要涵盖两道离线关卡与一道在线关卡： - **形式化验证（Formal Verification，离线）**：从语义层面确认代码变更确实达成了预期的业务目标。 - **风险评估（Risk Assessment，离线）**：预测此项变更引发系统故障（Outage）的概率，并排查是否会暴露在政策、隐私或监管合规风险之下。 - **在线验证（Online Verification）**：在真实用户流量中跑 A/A 或 A/B 测试，利用实验数据实地核验代码改动是否确实命中预期优化目标。 --- ### [07:03](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=423s) 实战应用 WALL-E：面向算力节省的 RSI 架构落地为了将理论落入实操，Jubin Chheda 介绍了以经典电影角色 WALL-E 命名的落地项目“Wally”。在电影中，当人类离开地球移居太空后，机器人 WALL-E 依然不知疲倦地清理并改进周围环境，同时不断自我修补升级；在 Meta，Wally 正是一个典型的递归自改进智能体范式。 Wally 专注于系统容量（Capacity）的优化节约，直接瞄准 CPU、GPU 计算周期和内存开销，这些优化可转化为数百万乃至数亿美元的硬成本节约。Jubin Chheda 指出，庞大的浪费通常始于非常简单的常见模式，他在演讲中分析了几种代表性反模式： - **死逻辑门（Dead Gates）**：为了灰度上线新功能而嵌入的代码开关。在功能全量上线或彻底废弃后，开关永远固定返回 true 或 false，却依然白白消耗着条件评估的算力。 - **僵尸日志（Zombie Logging）**：开发者最初为了排查 Bug 或观测指标而打出的日志，后期下游消费者早已不再使用，无人查看却持续耗费 IO 与存储。 - **未批处理的查询（Unbatched Queries）**：将低延迟模式错误地套用在原本应注重吞吐量的场景。Wally 团队从 Meta 多年的实验历史中，提炼总结了约 50 种此类典型模式。要搭建像 Wally 这样的优化器，需要赋予其三项核心工具： - **坏代码味道快速检索工具（Fast search for code smells）**：可以简单到只是一个用正则表达式（grep）匹配死代码、无效数据库查询的脚本，以此拉取待优化的候选目标。 - **代码导航与编辑工具（Code navigation & edit）**：标准的智能体工具集，用于浏览代码库并实施修改。 - **成本画像工具（Cost profiling）**：精准测算特定函数在全网服务器集群（Entire fleet）中所占用的内存、CPU 或 GPU 开销比例，让系统能够量化函数成本，从而确定性能瓶颈的优化优先级。 --- ### [09:51](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=591s) 闭环构建路线：从 Human-in-the-loop 走向 Human-on-the-loop 在构建 Wally 的自改进闭环时，初期往往面临冷启动问题。系统最开始依赖人工介入（Manual Verification），由人类工程师逐一审查 AI 优化器生成的 diff。但每一次人类完成审查后，核心原则是将背后的评审逻辑提炼并沉淀为一个离线智能体验证器（Agentic Offline Verifier）。在经历了 10 到 50 个 diff 的洗礼后，离线验证器将变得越来越全面完备，工程师便可逐步退后，将重担交由离线验证器承担。在这一演进过程中，Jubin Chheda 强调了一条绝不能触碰的铁律：“The key step here is to make sure the offline verifier uses a model that is much more powerful than the model that powers the optimizer. If the verifier is weaker than the optimizer, the loop collapses.”（这里的关键步骤在于，务必确保离线验证器所采用的模型，要远远强于驱动优化器的模型。如果验证器比优化器弱，整个闭环就会崩溃）。在这套机制下，工作流逐步走向完全自动化： 1. **自动线上实验**：通过离线验证后，系统触发线上灰度实验，观测其容量优化是否生效且无负向退化。 2. **自动化读数与裁决**：随着实验数据累积，系统学会自动解读测试报表，自动判定是该全量发布、继续迭代还是直接中止失败实验。 3. **闭环学习器反哺**：学习器将各阶段输出作为训练信号持续喂回，驱动各组件递归自进。即使企业只实现了这套流水线中的部分模块，也能立刻收获极高的工程价值。 4. **范式跃迁**：团队的运维模式最终应实现本质蜕变——从人在回路中（Human-in-the-loop，人类逐一排查干预）逐步过渡到人在回路之上（Human-on-the-loop，系统全自动流转，人类仅在发生异常时才介入处理），从而真正解开吞吐量枷锁，大幅扩展优化器的运转规模。 ### [11:50](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=710s) 闭环优化器（Optimizer）与验证器（Verifier）的底层构建机制为了让自增长飞轮真正产生跨越式的商业价值，系统生成的改动不能仅仅停留在几十、几百或几千次，而是必须达到每周、每天甚至每小时生成数百万次代码与参数调整的规模。Jubin Chheda 深入拆解了系统中核心组件——优化器（Optimizer，亦称 Oracle）与验证器（Verifier）的具体搭建路径。要构建一个强大的优化器，团队需要具备三大基石：代码库历史上所有优质优化实验的完整记录、精准的实验组处理语义（treatment semantics），以及详尽深入的实验读数（readouts）。通过对数千次历史实验数据的归纳与模式挖掘，系统得以建立起包含各类成功策略的模式目录（pattern catalog），并摸清该业务领域内部复杂的权衡法则（calculus about trade-offs）。一旦这两项资产完备，AI 智能体便能自主构想出全新的优化杠杆，或者针对现有杠杆高频采样生成更多变体，并依靠先前建立的权衡模型准确预测每次实验的成功概率。 ```mermaid flowchart TD accTitle: 优化器与验证器的构建闭环 accDescr: 展示历史数据如何驱动优化器生成假设，以及人工反馈如何冷启动并持续增强自动化验证器 subgraph OPT["优化器体系 (Optimizer)"] H["历史优化实验记录"] --> P["模式目录 (Pattern Catalog)"] T["处理语义与实验读数"] --> C["权衡法则 (Trade-off Calculus)"] P & C --> AG["AI Agent 策略构想"] AG --> GEN["生成优化实验候选"] end subgraph VER["验证器闭环 (Verifier Loop)"] GEN --> HR["人工评审与反馈"] HR --> CS["冷启动验证器"] CS -->|"持续摄入人类新反馈"| UV["高可靠自动化验证器"] end ``` 在验证端，冷启动的关键在于将优化器产生的所有候选变更交由工程师评审，系统汇聚人类专家给出的反馈数据来构建第一代验证器。随着验证闭环持续运转，每当人工介入并给出新的见解或边缘案例反馈时，验证器都会立刻吸收该反馈并纳入未来的自动化检验流程。 - 随着时间推移，该自动化验证器的可靠性迅速超越任何纯人工评审团队。 - Meta 内部系统 Volley 已经运行了数千次优化实验，并成功上线了其中相当可观的比例。 - Jubin Chheda 强调：“At this point, Volley's likelihood of having a successful experiment is much higher than the human baseline.”（此时此刻，Volley 产生成功实验的概率已经远高于人类工程师的基线水平。） - 在商业回报层面，Volley 已经为 Meta 实际节省了数亿美元的成本，而其内部优化器在 Meta 的庞大规模下所挖掘出的潜在节省空间已高达数十亿美元。 --- ### [14:01](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=841s) 衔尾蛇架构（Ouroboros）：从前沿大模型到小专精模型的蒸馏与强化学习即便 Volley 取得了数十亿美元级潜力的成果，工程团队依然希望突破极限，让模型与评测基准框架（harness）更加精准高效。Jubin Chheda 借用神话中象征自我循环与再生的“衔尾蛇”（Ouroboros）意象，引出了系统自演进的下一阶段：打造专门针对“寻找容量优化点”这一垂直任务的小型专用模型（Specialist Model）。在过往的 6 个月里，团队首先依赖 Meta 内部的顶尖大模型（如 Mu 系列前沿模型）源源不断地生成优化轨迹。随后，团队利用这些由大模型产出的丰富轨迹数据，对较小规模的开源模型（如 Muse Glimmer）进行监督微调（SFT / RFT，Rejection Sampling Fine-Tuning）以及强化学习训练（GRPO，Group Relative Policy Optimization）。通过这种方式，小模型得以在寻找算力容量优化这一特定垂直任务上持续“爬山”（hill climb），最终蜕变为高水平的专家模型。 ```mermaid flowchart LR accTitle: 衔尾蛇自演化与模型蒸馏流程 accDescr: 前沿大模型生成的轨迹通过 SFT 与 GRPO 训练小专精模型，获得更高性价比与吞吐量 A["前沿基础模型 (Mu 系列)"] -->|"产出高质量优化轨迹"| B["训练数据集"] B -->|"监督微调 (RFT) + 强化学习 (GRPO)"| C["小型专精模型 (Muse Glimmer)"] C -->|"推断速度更快 / 成本降低"| D["更大规模递归自改进 (RSI) 闭环"] D -.->|"持续回馈优质实验数据"| A ``` 通过这种定向特化，小模型不仅在输出质量上迅速逼近顶尖大模型，在某些特定场景下甚至实现了反超。大模型往往具备宽泛任务上的新颖性与通识能力，但在高度垂直的任务中，经过严格对抗与强化学习淬炼的小模型表现更为专精和稳定。 - **三重收益（Triple Whammy）：** 1. **质量持平乃至超越：** 专精模型在特定优化任务上的精确度比肩或优于泛化大模型。 2. **推理成本极具优势：** 小型专精模型的推理成本仅为大模型的 $1/8$ 到 $1/20$，在极端情况下甚至可以压缩到 $1/100$。 3. **延迟大幅下降：** 更低的时延换取了更高的系统吞吐，使得递归自改进（RSI）闭环的运转频率能实现数量级的扩展。 - **迁移学习能力（Transfer Learning）：** 针对算力容量节省（Capacity Savings）训练出的专精优化器，在面对系统可靠性（Reliability）优化与延迟（Latency）优化等其他工程任务时，同样展现出了优异的跨域泛化与迁移表现。 --- ### [16:39](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=999s) 核心总结：人类决策新定位、闭环验证与专精智能体在演讲尾声，Jubin Chheda 总结了构建“能自我增长的产品”所必须掌握的三项核心认知。首先，在递归自改进智能体（RSI Agents）时代，人类决策的重要性不仅没有降低，反而达到了历史新高。尽管智能体能带来前所未有的产品发布与迭代速度，但在战略方向上，人类不可替代：团队仍然需要人类来决定资金投向哪里、该构建什么产品功能、决定何时发布上线，以及为智能体指明攻坚的核心业务领域。其次，闭环验证系统是自改进生态的生命线。唯有前期下苦功搭建起严密、无须人工干预的闭环验证机制，才能真正启动递归自改进系统；一旦闭环成型，智能体就会日夜不停地自我演进，进而全面优化代码库、产品体验和组织效能。最后，架构设计必须将专精智能体纳入核心工作流中。当前全行业在 GPU、CPU 与内存资源上面临巨大的硬件压力，迫使每个工程团队都必须精打细算；而专精模型在质量、低延迟与极低成本之间取得的黄金平衡，正是决定企业能否将递归自改进红利最大化变现的关键杠杆。 Jubin Chheda 在全场热烈的掌声中为演讲收尾，他说道：“The future is very exciting and if you're working on similar problems, we'd love to hear from you. With that said, I want to leave you with a final thought: Define the loop. Let the agents climb. Thank you.”（未来充满令人振奋的可能；如果你也在探索类似的问题，我们非常期待与你交流。最后，我想送给大家一句话作为结语：定义好你的闭环，让智能体自己去向上攀登。谢谢大家。） ## Notable quotes > [09:51](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=591s) The key step here is to make sure the offline verifier uses a model that is much more powerful than the model that powers the optimizer. If the verifier is weaker than the optimizer, the loop collapses. — Jubin Chheda > [00:00](https://www.youtube.com/watch?v=ZNL2ir1EoIY&t=0s) Coding has democratized about 100%. I would say almost all diffs today are AI generated. — Jubin Chheda ## Mentioned Jubin Chheda, Meta, Scale, WALL-E, Wally, Volley, Mu, Muse Glimmer [Source](https://www.youtube.com/watch?v=ZNL2ir1EoIY)

Source quotes

[9:51] Jubin Chheda: The key step here is to make sure the offline verifier uses a model that is much more powerful than the model that powers the optimizer. If the verifier is weaker than the optimizer, the loop collapses. [0:00] Jubin Chheda: Coding has democratized about 100%. I would say almost all diffs today are AI generated.

Source quotes

[16:39] Jubin Chheda: The role of human decision making is now at an all-time high with recursively self-improving agents. [9:51] Jubin Chheda: The key step here is to make sure the offline verifier uses a model that is much more powerful than the model that powers the optimizer. If the verifier is weaker than the optimizer, the loop collapses.

Original transcript

[0:00] Imagine [0:06] a swarm of agents climbing a hill. Many [0:10] attempts, many parts, some successful, [0:15] many, many failures, but eventually some [0:17] of them do get to the top. [0:20] Now imagine those same agents take all [0:25] of their learnings and replicate into a [0:29] better swarm of agents. And this better [0:31] swarm of agents is now climbing an even [0:35] taller hill. [0:38] Now imagine that this is happening [0:41] hundreds, [0:43] thousands, [0:44] millions of times all in parallel. [0:49] This is recursive self-improvement. This [0:52] is here [0:55] in this talk. We have a dragon that eats [0:58] its tail. We have a beloved character [1:01] and we have billions of dollars of [1:03] savings to be had. [1:05] Coding has democratized about 100%. I [1:09] would say almost all diffs today are AI [1:11] generated. However, [1:14] if you look at the entire product [1:16] development cycle, right from product [1:18] ideation [1:20] all the way to launching and finding [1:22] product market fit, most of the other [1:24] activities apart from coding are [1:26] observably still running at human level [1:28] time scales. So, we haven't really sped [1:31] those up and they have now become the [1:34] bottlenecks. [1:36] Some of these bottlenecks are in a state [1:39] that's even more challenging than [1:40] they've ever been. And that's down to [1:42] the volume of how quickly coding has [1:45] expanded. [1:46] So verification is at an alltime red-hot [1:51] bottleneck. Making sure that the code is [1:53] doing exactly what you intended to do. [1:56] It's not having risk in terms of [1:58] security, in terms of other risks is [2:01] very very hard. Capacity is another [2:03] bottleneck. The chip shortage on memory [2:06] and GPUs and CPUs has meant that we are [2:09] only able to do these many ideas of [2:12] product changes at a time. And then [2:15] finally, just because of the scale up in [2:17] the amount of volume of diffs coming [2:19] through, our ability to make decisions [2:22] around what to ship, what to build, what [2:25] to test is at an all-time bottleneck. [2:29] So the biggest bottleneck is really [2:31] around choosing what to build, what to [2:34] launch when the universe of candidates [2:36] of what can be built is now infinite and [2:39] much of this is actually a you should be [2:41] able to distill just at the rate of [2:44] token cost. [2:46] The bottleneck now becomes the judgment [2:49] around which of those ideas are worth [2:51] pursuing for your organization. [2:56] The other challenge is that you need a [2:58] lot more refined product taste. And [3:02] product taste is actually an acquired [3:04] taste, right? You have to eat a lot of [3:07] dishes to improve your taste. [3:11] And finally, verification is quite hard. [3:16] If your verification lets past 1% of bad [3:20] changes over thousands and thousands of [3:22] iterations, it becomes a sizable amount [3:26] of poor quality code going out the [3:29] factory. So, however, I'll say there is [3:32] hope. We will cover how to build a [3:36] closed verifiable loop and then how to [3:39] run it hundreds, thousands, millions of [3:43] times for public AB tests and how to use [3:47] that to build value for your product and [3:50] your company. [3:52] These are the three things that I'll [3:54] cover today. the closed verification [3:57] loop, a recipe for a capacity saving [4:01] recursive self-improving loop and then [4:04] finally I will talk about or which is [4:07] our recursive self-improving loop for [4:10] the model and the harness layer. [4:14] So let's understand the basics around [4:16] what we mean by a closed loop. You have [4:19] a optimizer [4:21] whose task is to propose and code [4:26] changes that will actually improve the [4:30] specific objectives of your product. [4:33] This could be things like improving [4:35] sessions. It could be DAOU. It could be [4:39] stability. It could be recovery of [4:41] costs. Any of those things. [4:45] The work of the optimizer then lands to [4:48] a verifier. A verifier is effectively an [4:51] agendic step that is trying to make sure [4:54] that it only passes through [4:57] code changes that are actually reliably [5:02] going to make a difference into your [5:04] objective function and are not adding an [5:08] additional burden of risk. There are [5:11] offline verifiers and there are online [5:12] verifiers and we'll cover these. [5:15] Once you pass the verification and you [5:18] run an AB test on some section of your [5:20] user user universe, you have a decision [5:23] to be made. Here you look at data around [5:27] what impact that particular code change [5:29] might have in terms of your of the [5:32] different objectives you care about [5:33] things like DAO, sessions, performance, [5:36] reliability, quality, all those sort of [5:38] things. and you make a launch or a no- [5:40] launch decision based on this. Finally, [5:44] and this is the stage that makes the [5:45] whole thing self-improving, is to take [5:48] the outcome of each stage, especially [5:50] the decision-m stage, and using those [5:53] learnings to improve the optimizer, the [5:56] verifier, and the decision maker. And [5:58] you can do this again and again and [6:01] again. And that's the recursive part. [6:03] So, this is how you define a recursively [6:05] self-improving closed loop. [6:09] Let's look a bit deeper into [6:12] verification. So the first two steps [6:14] here are offline and the last step is [6:16] online. [6:18] The most important offline verification [6:20] stage is formal verification. It is to [6:24] be able to semantically confirm that the [6:26] code change is hitting the objective you [6:28] had in mind. The second step is risk [6:32] assessment. So here we are going to [6:34] predict what is the likelihood of this [6:36] code change to become an outage. What is [6:38] the likelihood of it to expose your you [6:41] to policy, privacy or regulatory risks? [6:45] And then finally the online verification [6:47] stage is when you run an AA or an AB [6:51] test on a certain proportion of users [6:53] and use the data from that experiment to [6:56] verify whether the code change would [6:58] indeed hit the objective you wanted to [7:01] achieve. [7:03] So let's take this learnings and now [7:05] apply this for a fully functioning [7:08] practical loop Wally. [7:11] So Wally is named after the character [7:13] Wall E which is a beloved movie about a [7:17] robot that continues to roam the the [7:20] earth trying to make improvements all [7:23] the time when the humans have left and [7:25] live in space. and Voli kind of [7:28] continues to improve not just the earth [7:30] around it but also itself. So it's a [7:33] canonical example of a recursively [7:36] self-improving agent if you will. We [7:39] will talk about the details of all these [7:41] stages that I have here in a moment. So [7:45] for capacity savings we are talking [7:47] about CPU, GPU or memory cycle savings. [7:51] These add up to millions or hundreds of [7:53] millions millions of dollars worth of [7:54] saving. But they actually originate with [7:57] very simple patterns and I suspect all [8:00] of you have these kind of patterns in [8:01] your codebase. We often have dead gates. [8:05] These are gates that were introduced in [8:07] the code to introduce a new feature. The [8:09] feature is either launched or never [8:11] launched and the gate is effectively [8:13] defaulting to true or false all the time [8:15] but is still taking capacity costs of [8:17] evaluating the gate. [8:19] Another example is logging. We often add [8:21] logging to debug problems or to observe [8:24] the impact of a feature. [8:26] However, the downstream consumer of [8:28] these logs is no longer functional. [8:31] Nobody's looking at these logs and they [8:32] are effectively dead code again as well. [8:36] Likewise, there are opportunities often [8:37] to batch queries to convert [8:41] low latency workflows into perhaps [8:43] throughut focused workflows. There's a [8:46] bunch of these sort of patterns that [8:47] repeat themselves again and again. And [8:49] for Wally, we have about 50 canonical [8:51] patterns that we have gleaned from a [8:53] history of several years of [8:55] experimentation. [8:58] The Oracle or the optimizer that I spoke [9:00] about for Wally needs access to three [9:02] tools and actually all of you all can [9:04] build an optimizer like Voli. What you [9:07] need is a fast search for code smells. [9:09] This could be as simple as a reg x gp on [9:12] dead code or on database queries and [9:15] those sort of things that will generate [9:16] a bunch of candidates that the optimizer [9:18] should be considering to optimize. Then [9:21] you have the ability to navigate and [9:23] edit code changes which is a very [9:25] standard tool all agents have access to. [9:28] And finally you have cost profiling [9:30] which is given a function being able to [9:32] tell what is the memory impact and the [9:34] CPU or GPU impact of that function as a [9:38] proportion of the entire fleet. So it's [9:40] effectively a way to say this is how [9:41] costly this particular function is and [9:44] that can help you prioritize and [9:46] diagnose where there are possible [9:49] bottlenecks in your capacity. [9:51] So let's look at the volley RSI loop. We [9:54] spoke about the optimizer. [9:56] Once we have cold started the optimizer, [9:58] we would start with manual verification [10:00] which is humans reviewing the diffs that [10:02] are generated. But every time you review [10:05] a diff, you try to convert that logic [10:08] into an agentic verifier, an offline [10:10] verifier. Once you do this over a period [10:13] of like 10 or 20 or 30 or 50 diffs, [10:17] slowly your agentic verifier becomes [10:18] more and more comprehensive and you can [10:21] step back from doing manual verification [10:23] and rely a lot more on the agentic [10:26] offline verifier. The key step here is [10:29] to make sure the offline verifier uses a [10:31] model that is much more powerful than [10:33] the model that powers the optimizer. If [10:36] the verifier is weaker than the [10:37] optimizer, the loop collapses. [10:40] After you have the offline verifier, you [10:42] have a stage where you can kick off [10:43] online experiments so that you can [10:46] confirm from online usage that you are [10:49] actually making a saving on capacity and [10:51] it's not regressing other things you [10:52] care about. Once you run several of [10:55] these experiments, you can get very good [10:57] at automating the readout of the [10:59] experiments, effectively being able to [11:01] tell whether this experiment is worth [11:02] launching. Should we iterate on it or [11:04] should we just fail the experiment? Once [11:06] we have this, we can then put together a [11:09] learner that will take the outputs of [11:11] each of these stages and use that as [11:14] signal to improve all these stages. The [11:17] learner is what makes this a recursively [11:19] self-improving loop. But each individual [11:22] stage here is is in independently very [11:24] valuable as well. And for for code bases [11:26] and companies that do even some of these [11:29] steps, you will immediately reap a lot [11:31] of value. [11:34] What you want to do is you want to start [11:36] with humans in the loop trying to make [11:38] these agents really reliable and then [11:40] slowly step back so that humans jobs is [11:42] only to step in when there's an [11:44] exception. The more you can move to a [11:46] human on the loop model, you will then [11:49] be able to scale up the optimizer and [11:50] have it generate not just tens, hundreds [11:53] or thousands of changes but millions of [11:55] changes on a weekly, daily or hourly [11:58] basis even. And that way you can [12:00] actually let the loop run and and and [12:03] create step changes in terms of how much [12:05] value it generates for your [12:06] organization. [12:09] So let's look at a little bit more [12:10] detail on the how the optimizer or [12:13] Oracle is actually built. You need a [12:16] past history of good optimization [12:18] experiments that you have done on the on [12:20] your codebase. You need to look at [12:22] treatment semantics and you need to have [12:24] somewhat level of comprehensive readouts [12:26] of these experiments. Essentially, these [12:29] are going to be used to to identify [12:31] trends or patterns in those thousands of [12:33] experiments so that you can create a [12:34] pattern catalog and also to understand [12:37] the calculus about trade-offs in that [12:39] domain. Once you have these two things [12:42] in place, an AI agent can actually use [12:45] that to ideulate new levers or just more [12:48] samples of the existing levers and be [12:51] able to use the trade-off universe or [12:53] the calculus you created to be able to [12:55] predict how likely that experiment is at [12:58] succeeding. [13:00] Likewise, for verification, you can [13:02] basically use all the incoming [13:04] candidates from the optimizer and have [13:07] humans review these changes and give [13:10] feedback and you can collate all that [13:13] feedback to cold start a verifier. And [13:16] over time, each time you have a human [13:18] giving some novel feedback, that should [13:20] be taken up by the verifier and become [13:22] part of the verification cycle going [13:24] forward. Once you have that, very [13:27] quickly you will have a verifier that is [13:28] much more reliable than any particular [13:30] human team of reviewers you would be [13:32] able to have. In our case, we've seen [13:35] phenomenal results from this. We've run [13:37] thousands of experiments and launched a [13:40] significant portion of them. At this [13:42] point, Volley's likelihood of having a [13:44] successful experiment is much higher [13:46] than the human baseline. And also like [13:49] Wally ends up saving hundreds of [13:50] millions of dollars worth of savings and [13:53] Wally's optimizers have actually found [13:55] savings potential worth in the billions [13:57] of dollars at meta scale. [14:01] However, this is not enough. We want to [14:02] take it to the next stage. We want to [14:04] make the volley model and harness even [14:08] more accurate and even better. [14:10] And this is where your dragon with [14:12] eating its own tail comes in. Ouroros. [14:16] So Oruro actually takes this idea even [14:19] further and here what we do is we want [14:21] to have smaller [14:23] highly optimized models for that [14:26] particular task. In this case it's [14:27] finding optimizations. [14:30] So what we do is we start with a [14:31] frontier or a large sotar model and we [14:34] have it produce optimizations which has [14:36] been doing for the last 6 months. We [14:39] have the luxury of having a a large [14:42] firstparty model in the MU series of [14:44] models and we're able to use all the [14:47] trajectories that are created by these [14:49] first party models and then are able to [14:52] use that to train a smaller model like [14:55] Muse Glimmer which is available in open [14:57] source apply supervised fine-tuning and [15:00] reinforcement learning. So RFT and GRPO [15:03] to have the smaller muse glimmer model [15:07] hill climb on becoming very very good at [15:10] a specialist model for finding capacity [15:13] optimizations. [15:14] By doing this we are able to get the [15:16] quality of the output of the small model [15:19] come very close to the quality of the [15:21] output of a large model and in some [15:23] cases surpass it because large models [15:25] tend to have a lot more novelty for many [15:26] tasks whereas the small model tends to [15:29] get very good at that particular task. [15:33] So obviously there's advantages in [15:34] quality but there's also advantages on [15:36] cost because these the smaller models is [15:39] often times 1/8 or even 120th the cost [15:43] in some cases even smaller so 100th of [15:46] the cost and then finally the triple [15:48] whammy is when you get latency savings [15:50] as well because inference on these [15:52] smaller models runs even faster so [15:55] you're able to scale up your RSI loop [15:57] even further by having a smaller model [16:01] so you need to have a good frontier [16:03] model, perfect your recursive [16:05] self-improving loop with this frontier [16:07] model, capture all its runs and use that [16:11] as means to train a smaller specialist [16:14] model. Over time, you start to see that [16:16] the smaller specialist model performs [16:18] very well at that particular specialist [16:20] task. But also some of this has transfer [16:23] learnings to other domains like capacity [16:26] savings optimizers also show good [16:29] performance on tasks like reliability [16:32] optimizers or latency optimizers and so [16:34] on and so forth. So there is a transfer [16:36] learning that comes out of it as well. I [16:39] think finally I want to leave you all [16:41] with the key messages here. The role of [16:45] human decision making is now at an [16:47] all-time high with recursively [16:50] self-improving agents. We are going to [16:52] see a huge change in velocity of product [16:55] shipping through our company. But the [16:57] role of humans is still hyper crucial. [17:01] We still need humans to make decisions [17:03] of where to invest, what to build, what [17:06] to ship, what should the agents focus [17:08] on. The second piece I'll leave you with [17:11] is the role of closed verification [17:13] loops. Once you invest into the effort [17:16] of building a closed verify loop, you [17:19] can kick off recursive self-improvement. [17:22] And once you have that, the agents [17:26] self-improve and improve your codebase, [17:29] your product, and your organization. [17:33] And finally, it's crucial to consider [17:36] specialist agents as part of your [17:39] harness too. The pressures on GPU, CPU, [17:42] and memory are going to force all of us [17:44] to think about cost. But there is a big [17:47] quality lever and a latency lever as [17:50] well which absolutely dictates the [17:52] velocity at which we are able to reap [17:55] benefits out of recursive sets and [17:57] proving agents. [17:59] The future is very exciting [18:03] and if you're working on similar [18:05] problems, we'd love to hear from you. [18:08] With that said, I want to leave you with [18:09] a final thought. [18:11] Define the loop. Let the agents climb. [18:16] Thank you.