← All speakers

Eugene Yan is a member of technical staff at Anthropic who builds safe, reliable AI systems. His career spans e-commerce recommendations, Amazon search and generative AI, and cybersecurity, with a consistent emphasis on evaluation-driven development: measure whether systems work under real conditions before trusting their outputs.

Yan studied psychology and business at Singapore Management University and began his career working on policy and trade agreements at Singapore’s Ministry of Trade and Industry. After developing his technical skills, he joined IBM, working on workforce analytics, fraud-related problems, job-demand forecasting, and recommendations.

A product-classification project helped bring him to Lazada, where he became vice president of machine learning and built systems for ranking, push notifications, and automated classification. He subsequently led machine learning at healthcare startup uCare.ai, including work on disease detection and healthcare-cost estimation. At Amazon, he rose to principal applied scientist, developing real-time retrieval, bandit-based ranking, search recommendations, and AI products for summarization, translation, and question answering. He joined Anthropic in 2026.

What makes AI dependable

  • Evaluation-driven development: Yan favors realistic, task-specific tests over broad benchmark scores: execute generated SQL, validate extracted JSON, and check whether individual sentences in a summary follow from their source. His product-evaluation framework starts with representative labeled examples, calibrates automated judgments against human preferences, and reruns evaluations after system changes. His analysis of model-based evaluators examines ordering effects, bias, and the tradeoffs between flexible language-model judges and faster specialized classifiers.
  • Retrieval and feedback must reflect actual behavior: Relevant documents can become ineffective when buried among distractions, and larger context windows do not rescue poor ranking. Yan applies recommendation-system principles to retrieval: prioritize relevant evidence, exclude weak matches, and distinguish genuine user satisfaction from misleading signals such as copying incorrect generated code. His production-systems talk connects retrieval quality, factuality guardrails, and interfaces that naturally capture useful feedback.
  • Semantic identifiers improve discovery: Conventional item identifiers reveal little about new or rarely encountered products. Yan’s semantic-ids-llm project explores semantic identifiers that connect item meaning with language-model reasoning, enabling more steerable recommendations. His recommendation-systems keynote also examines synthetic labels, multimodal representations, and unified search-and-recommendation models, carefully distinguishing external company examples from his own work.
  • Security agents need independent verification: Yan’s source-code security workflow comprises threat modeling, isolated sandboxes, vulnerability discovery, exploit verification, triage, and patch validation. Discovery optimizes for recall; an independent verifier tests suspected vulnerabilities in a fresh environment to establish precision. Patches must stop the original exploit without breaking existing tests, while severity assessments incorporate operational context such as firewalls, internal access, and sensitive data. As Yan observed publicly, stronger models shift the security bottleneck from finding vulnerabilities toward verifying, prioritizing, and fixing them.

Yan also makes production engineering knowledge reusable. His Applied Machine Learning repository collects papers and technical accounts of deployed systems, while Machine Learning Design Documents shares practical planning examples. His more recent writing on working with AI extends those concerns to human-model collaboration: durable context, feedback, and reliable performance on difficult tasks determine whether capable models translate into finished work.

Read the topics behind these talks

5 conference talks

Key ideas

Scroll to read ↓

Task-specific evaluations, carefully ranked context, factuality checks, and useful feedback turn model capabilities into products that can improve reliably.

  • Did that change actually improve the product?
    0:39 ↗
  • What does a benchmark score measure?
    1:38 ↗
  • Start small and make the task measurable
    3:54 ↗
  • An answer in the context can still be missed
    5:44 ↗
  • When the context does not support a recommendation
    7:49 ↗
  • Check factual consistency one claim at a time
    9:44 ↗
  • Agreement and strong-model judging
    11:41 ↗
  • A copied answer is not a correct answer
    12:32 ↗
  • Make preference visible through normal use
    14:14 ↗
  • Automate the checks and reuse what works
    15:43 ↗

Key ideas

Scroll to read ↓

Copilot’s evolution from ghost text to editable implementation plans shows how AI can reduce interruptions, expose hidden work, and leave developers more time to create.

  • A model that could write JavaScript and Python
    0:19 ↗
  • Why ghost text fit the developer’s workflow
    3:49 ↗
  • From an issue to an editable implementation
    7:26 ↗
  • A plan can reveal what a user story leaves out
    9:26 ↗
  • Learning in your own language, asking without embarrassment
    10:41 ↗
  • An agent should wash the dishes
    13:10 ↗
  • Make room for the enjoyment of building
    16:40 ↗

Key ideas

Scroll to read ↓

Semantic IDs, synthetic labels, and shared models help recommendation systems learn from sparse interactions, improve discovery, and reduce duplicated engineering.

  • Learning the next item from a sequence
    0:15 ↗
  • Give new items a representation before they have interactions
    1:36 ↗
  • Use language models to supply missing data
    5:39 ↗
  • Indeed: distill a judgment into an online filter
    6:28 ↗
  • Spotify: help users discover what they can search for
    10:40 ↗
  • Netflix: unify tasks through a shared input schema
    13:37 ↗
  • Etsy: retrieve for intent, preferences, and quality
    16:49 ↗
  • Share models until the tasks conflict
    20:00 ↗

Key ideas

Scroll to read ↓

A security agent needs more than source code: it needs system context, a safe testbed, independent verification, and a path from confirmed vulnerabilities to reviewed patches.

  • What happens when finding vulnerabilities gets easier?
    0:00 ↗
  • From more findings to more unfinished work
    1:58 ↗
  • Build the setup once, then run the loop
    3:48 ↗
  • Give the model the system, not just the code
    5:30 ↗
  • Make exploit testing isolated and reproducible
    7:42 ↗
  • Discover with context, simpler prompts, and tools
    9:13 ↗
  • Let a separate agent try to disprove the finding
    11:34 ↗
  • A real vulnerability still needs business context
    13:26 ↗
  • Validate the patch and preserve what you learned
    15:52 ↗
  • Scale the decisions around the harness
    17:14 ↗
  • Start interactively before automating
    20:05 ↗

Key ideas

Scroll to read ↓

Useful LLM products depend on domain expertise, deliberate hiring, and a feedback loop that turns real user interactions into evaluations, better decisions, and production guardrails.

  • Six practitioners encounter the same problems
    0:24 ↗
  • Build a product advantage that survives better models
    3:23 ↗
  • Evaluation belongs inside an improvement loop
    6:06 ↗
  • Get real interactions into the loop
    10:01 ↗
  • Prototype for economics that may become possible
    11:57 ↗
  • Buying another shovel does not tell you where to dig
    14:52 ↗
  • Premature model ownership creates the wrong work
    16:23 ↗
  • Evaluation is a core engineering skill
    18:24 ↗
  • Hire for the next stage of the product
    21:00 ↗
  • Turn broad quality goals into testable criteria
    23:54 ↗
  • Choose an evaluator you can align and maintain
    25:41 ↗
  • Inspect recognizable failures with their execution context
    28:34 ↗
  • Turn reference-free evaluations into guardrails
    30:43 ↗
  • The surrounding system still needs maintenance
    32:32 ↗
  • A compelling demo can precede a product by decades
    34:17 ↗

References