Pioneers Insight Method Research Author
No Priors Ep. 113 | With OpenAI's Eric Mitchell and Brandon McKinzie
Back to Episodes

No Priors Ep. 113 | With OpenAI's Eric Mitchell and Brandon McKinzie

Summary

  • o3’s practical value is a higher-level interface to knowledge work, not merely better answers. It can translate “do some due diligence on this company” into browsing, code execution, forecasting, review, and synthesis without the user prescribing every step—moving AI closer to completing workflows than supplying text.

  • Reinforcement learning plus tools makes additional inference-time compute more productive. Without external actions, prolonged reasoning can become internal “ranting” until the model “loses its mind and goes insane”; with tools, o3 can crop an image, execute a calculation, verify an output, and adjust course, producing especially strong test-time-scaling gains in visual reasoning.

  • OpenAI is interested in a more unified, uncertainty-aware experience rather than forcing users to choose among many models. The ideal model answers immediately when it knows and takes a day when the task requires a day. Developers should also be able to steer behavior around latency and use-case constraints, though deciding the right trade-off may itself require reasoning.

  • Coding and research are the clearest near-term compounding wedges. Brandon says he now reaches for models “multiple times a day,” including against complicated internal codebases, and sometimes saves many hours; Eric describes the potential loop in which AI accelerates hardware, training, evaluation, and the research that creates its successors.

  • Computer use could expand the addressable workflow surface dramatically, but reliability determines how autonomy is deployed. Giving a model the “keys to the kingdom” creates asymmetric downside: a saved hour is useful, while an erroneous email, deleted text history, or wiped drive is unacceptable. Capabilities will therefore expand through constrained affordances and sandboxes.

  • Embodied and collaborative work remains harder because intelligence must contend with uncertain environments and real-world clocks. “Gravity’s not going to wait for you,” humans are unpredictable and expensive tool calls, and models’ visual systems can inherit artifacts from static-image data, such as favoring 10:10 because “over 90% or something like that” of pictured clocks show that time.

  • Model quality is a distribution, creating opportunities in evaluation, repeated sampling, and premium inference. A single prompt can either trigger a “moment of magic” or a mediocre trajectory, so Eric recommends running it repeatedly; Sarah’s proposed best-of-100 button—and joking “Sarah tier”—points to willingness to pay for selection, while uncontaminated evals and frontier long-horizon training data become increasingly valuable inputs.

Deep dive

1. Tools make longer reasoning useful

  • McKinzie describes o3 as an o-series model that can “think carefully before they respond,” with two advances: stronger answers and access to browsing and executable code. Intelligence alone has a ceiling when information is stale or arithmetic is inefficient; tools let the model acquire evidence, compute results, inspect them, and adjust course.

  • The main training departure from a conventional pretrainer is reinforcement learning. Instead of only predicting the next token across a large corpus, the model receives a focused objective around solving difficult tasks and can spend substantial time finding an answer.

  • Longer reasoning without tools can fail unproductively: on some visual tasks, the model recognizes that it cannot see the relevant detail, then “loses its mind and goes insane.” Give it tools and it starts cropping or manipulating the image to reduce uncertainty; the observed test-time-scaling slopes are “very noticeably different.”

  • Code supplies the cleanest division of labor. Rather than burn tokens mentally fitting coefficients for a valuation, o3 can write a simple program, execute it, test the result, and know the actual answer—allocating compute to the model’s comparative advantage while delegating deterministic work.

2. The best product hides model choice from the user

  • Mitchell describes the current ChatGPT experience as having a “big crazy model switcher”: a suitable model may exist for every task, but that does little good if users cannot identify it. He frames unification as pushing the routing decision inside the model, where task context can determine the appropriate behavior.

  • The desired interface is governed by calibrated uncertainty: “If they already know the answer, they should just tell you it,” while a problem that genuinely requires a day should get a day. The aspiration is that response time feels necessary rather than arbitrary—“exactly as long as it needs to.”

  • Sarah’s API point is practical: developers sometimes need cheap, controlled inference and cannot let a request think for 10 minutes. Mitchell recasts this as steerability—a smart model should understand the context and do the right thing, including respecting such constraints, though deciding the correct trade-off may itself require reasoning.

  • Deep Research is a natural RL test bed because browsing applies to many current-information queries and exposes whether a model can sustain meaningful long-horizon behavior. Its objective must still encode product choices: will users tolerate a 30-minute rollout, and do they want one page, five pages, or “a gazillion pages”?

3. Coding compounds first, while computer control stays bounded

  • Coding and research appear to be crossing a usability threshold. McKinzie says recent models genuinely investigate questions in complicated internal codebases and return work that saves “many hours”; unlike earlier systems that remained slightly behind expectations, these are useful enough for him to consult “multiple times a day.”

  • Mitchell describes the recursive-development thesis: each model can help make the next model better, faster, and cheaper. McKinzie adds that AI research contains separable work across hardware, training, and evaluation, each of which can become an optimized task—leaving “plenty of room to squeeze out improvements” throughout the stack.

  • McKinzie wants models present throughout ordinary computer work: watching with the user’s ability to opt out, understanding the current context, and responding when he asks, “All right, what am I supposed to do with this?” He finds their tool behavior “weirdly humanlike,” plausibly because of the data they have seen.

  • Mitchell supplies the caution: open-ended computer access has asymmetric costs, so deployment remains iterative and sandboxed. A model might save time, but the same autonomy could send “some crazy email to your boss,” delete texts, or erase a drive; the safe set of delegated actions should be larger tomorrow than yesterday, not unlimited today.

4. Environment uncertainty is the hard frontier

  • Mitchell highlights two dimensions among several factors: how much external uncertainty a task requires the model to resolve, and how much of that environment can be simulated without being bottlenecked by real-world time. Recalling the first US president is internal; coding requires execution and testing; physical work adds experiments whose outcomes and timing cannot simply be memorized.

  • Guo points to GitHub Copilot’s progression from specialized Codex to general-purpose models. Mitchell sees no fundamental reason robotics must remain separate. But embodiment adds a non-negotiable frame rate: an answer after two minutes is useless when a ball is arriving now—“gravity’s not going to wait for you.”

  • Elad notes that frogs and ants perform responsive physical behavior with tiny amounts of compute, raising the question of how much intelligence embodiment actually needs. McKinzie responds with a vision example: human vision was shaped by acting in the world, whereas model vision was learned in a very different way from static-image data.

  • The clock example makes that distribution failure concrete: ask a model to read an analog clock and it strongly favors 10:10 because “over 90% or something like that” of online clock images use the smiling display. Closing the perception-action loop might let models reduce such uncertainty through real-world action instead of more internal thought.

5. Collaboration, evals, and variance become the bottlenecks

  • Mitchell tentatively suggests training two models together: o3 already approximates one browser-equipped worker, and multi-agent RL might be a useful starting point for teaching cooperation with other agents before working directly with people. Brandon notes that related work is already underway. Humans remain “a super expensive tool call”; as Mitchell jokes, interactions with Brandon are the hardest part of research, while “writing the code is—that’s the easy part.”

  • The hosts ask whether RL-driven progress will look spikier because labs choose domains and environments. McKinzie calls that a reasonable hypothesis but resists the conclusion that gains stop at math and code, citing a creative-writing example that may update intuitions. Mitchell says labs also pursue algorithmic changes intended to “lift all boats” beyond a specific RL dataset.

  • Asked for ideal data, Mitchell’s deliberate dodge is “uncontaminated evals.” He distinguishes evaluation data from training data: evals must be rigorous and uncontaminated, and they are increasingly important as generally capable models exhaust reliable tests. On the training side, McKinzie wants data at the next frontier of capability—not basic tool use, which o3 and o4-mini already handle—including a million-line codebase, a two-week feature task, multiple pull requests, and dense supervision throughout.

  • Their most actionable usage advice is to send the identical prompt “many times.” o3’s peak trajectory can be extraordinary, yet another run may miss the “moment of magic”; Sarah therefore wants an expensive best-of-100 button that ranks the outputs, while synthesis may risk reverting toward the mean.

  • In practice, McKinzie treats the model as a background queue: dispatch programming tasks even when success seems unlikely, accept occasional “disappointed father” results, and keep the upside when a run unexpectedly works and saves substantial time. Variance is not merely a defect—it can be harvested when retries are cheap enough.