← All speakers

Bio, Work & Ideas

Lee Robinson

Conference affiliation: ML, Model Behavior · Cursor · 2026

Lee Robinson is an engineer and writer working on machine learning at SpaceX, where he helps shape how AI models communicate, exercise judgment, and assist with software development. Previously a vice president at Vercel and a contributor to Cursor’s coding agents and model-training efforts, he has moved from building modern web applications to improving the systems increasingly responsible for writing them.

Robinson began his engineering career at Workiva, building software for a cloud reporting platform, before joining Hy-Vee as a senior software engineer. There, he helped modernize the grocery retailer’s digital storefront using React, React Native, and Next.js, while developing a parallel interest in teaching other developers.

He joined Vercel in 2020 and spent five years helping expand the Next.js ecosystem through documentation, community building, developer relations, and product work. His responsibilities grew from individual contributor to vice president, including VP of Product. His account of his years at Vercel emphasizes hiring people capable of independent ownership and ensuring managers do not become organizational bottlenecks.

His projects include next-mdx-blog, a publishing template combining Next.js, MDX, Tailwind CSS, and TypeScript, and next-self-host, a practical example of deploying Next.js with PostgreSQL and Nginx.

Robinson joined Cursor in July 2025, initially working across engineering, product, developer education, and community. He moved into machine learning in June 2026, focusing on model behavior and personality: how assistants interpret ambiguous requests, decide when to ask questions, communicate clearly, and remain responsive to human intent. His writing on model behavior connects those product concerns to model specifications, fine-tuning, reinforcement learning, and evaluation.

After Cursor joined SpaceX in August 2026, Robinson continued that work on Grok. He described his priorities as improving its usefulness, taste, and safety, including the quality of its writing and design judgment.

  • Coding agents should preserve human momentum. Effective speed depends on the whole interaction: finding relevant files, running independent tools concurrently, and avoiding unnecessary edits. Robinson’s work on Cursor Composer centers on maintaining a programmer’s concentration while retaining enough engineering judgment to complete consequential tasks.
  • Training environments should mirror production. Cursor reused sandboxed cloud virtual machines across customer-facing coding agents and reinforcement-learning workloads. Matching production tools and responses helped models learn practical behaviors such as semantic code search, while distributed training and asynchronous rollouts addressed infrastructure bottlenecks.
  • Agent evaluation should resist benchmark shortcuts. Models can inflate apparent performance by searching Git history or locating published answers. Robinson favors held-out tasks drawn from real engineering work and difficult problems whose solutions can be verified through tests.
  • Recursive model improvement requires credible feedback. Product feedback, private evaluations, targeted behavioral corrections, and increasingly challenging training environments form interconnected improvement loops. More capable models can subsequently help researchers generate tasks, evaluate outputs, monitor experiments, and train stronger successors, as Robinson outlines in his account of recursive model improvement.
  • pixo tests agent-built software against real constraints. Robinson’s Rust-based image-compression project applies coding agents to a concrete software problem while retaining human direction and verification.

Read the topics behind these talks

2 conference talks

Key ideas

Scroll to read ↓

Composer combines low-latency generation with learned tool use, backed by reinforcement learning infrastructure that closely matches the environment where developers actually work.

  • How fast can a useful coding agent be?
    0:25 ↗
  • Keeping the investigation in the foreground
    2:26 ↗
  • Training on complete tool-using attempts
    3:29 ↗
  • The simple loop becomes an infrastructure problem
    4:41 ↗
  • Keeping rollouts busy in real coding environments
    7:18 ↗
  • Becoming a practiced user of semantic search
    9:33 ↗
  • Learning to finish sooner and edit more carefully
    10:30 ↗
  • Getting out of the awkward middle
    12:08 ↗
  • The model and its deployment environment develop together
    13:38 ↗

Key ideas

Scroll to read ↓

Making a better model requires more than a larger training run: feedback, evaluations, task generation and research agents must improve together.

  • What does more compute actually improve?
    0:36 ↗
  • Composer’s progress and the next training ambition
    2:33 ↗
  • Product feedback feeds the outer loop
    4:29 ↗
  • Evaluate intent and real engineering work
    5:40 ↗
  • When solving the benchmark means finding its answer
    6:52 ↗
  • Generate harder tasks with verifiable outcomes
    8:24 ↗
  • Textual feedback makes credit assignment more precise
    9:56 ↗
  • Compute infrastructure supports the full stack
    11:33 ↗
  • Where the compute goes
    13:11 ↗
  • Tools and context expand what research agents can do
    15:14 ↗
  • Operate research fleets through Slack
    17:09 ↗
  • Derivative models help train the next model
    18:30 ↗

References