← All speakers

Bio, Work & Ideas

Ryan Lopopolo

Conference affiliation: OpenAI · 2026

Ryan Lopopolo is a member of the technical staff at OpenAI working on OpenAI Frontier and harness engineering: designing the tools, instructions, and feedback systems that allow coding agents to perform substantial software engineering work. His central question is how organizations retain architectural judgment and quality when implementation becomes abundant.

Lopopolo worked at Box and Citadel before joining Stripe, where he founded and led its efficiency engineering team. His work on cloud capacity and reserved instances addressed infrastructure costs, demand forecasting, and the organizational visibility needed to manage both. He subsequently became a group technical lead for developer productivity at Brex and later worked as a technical lead on Snowflake’s data marketplace.

He also created Artichoke Ruby, an open-source Ruby implementation written in Rust and Ruby. Its emphasis on language runtimes and developer infrastructure complements his later focus on the environments surrounding coding models.

At OpenAI, Lopopolo helped develop an internal product with agents responsible for implementation while humans established priorities, architectural constraints, and acceptance criteria. His account of agent-first software development and public harness-engineering field guide describe how teams can make that arrangement dependable.

  • Agent context should arrive when needed. Lopopolo treats architecture decisions, product requirements, and security expectations as operational knowledge that belongs inside the repository. Focused AGENTS.md files, a small set of maintained skills, actionable lint errors, and automated review deliver just-in-time agent context without overwhelming a model upfront.
  • Review feedback should become executable. Recurring human objections can become structural tests, custom lint rules, reliability checks, and specialized reviewers in continuous integration. His AI Engineer Europe appearance grounds this approach in concrete safeguards: enforcing dependency boundaries, eliminating duplicate schemas, and checking network calls for retries and timeouts.
  • Tests must justify their maintenance cost. Lopopolo argues against brittle implementation-focused tests that duplicate coverage or force unnecessary architectural seams. Removing those tests can simplify production code while preserving confidence in observable behavior.
  • Agent scaffolding should become obsolete. Lopopolo argues that model capability ultimately limits agent capability. Better context and tooling can recover existing capability, while failures beyond the model’s current reach should inform subsequent training. Durable product knowledge remains; temporary orchestration should recede as models improve.

Talks by Ryan Lopopolo

1 talk

Key ideas

Scroll to read ↓

Ryan Lopopolo explains how to turn coding agents into reliable software-engineering collaborators by making requirements explicit, delivering context when it matters, and converting recurring human feedback into durable guardrails.

  • Treat human attention, model attention, context windows, compute, and token budgets as the practical constraints; organize engineering work around delegation rather than manual implementation. 1:54 ↗ 4:30 ↗
  • Convert tacit quality standards into documentation, lint rules, structural tests, and specialized review agents that detect and remediate recurring failures. 9:16 ↗ 11:21 ↗ 12:26 ↗ 13:23 ↗
  • Provide just-in-time context through the development workflow instead of overwhelming agents with every requirement in the initial prompt. 24:04 ↗ 25:08 ↗
  • Use clear package boundaries, canonical shared utilities, and consistent repository patterns to conserve context and reduce merge conflicts. 21:26 ↗ 34:00 ↗ 35:12 ↗ 36:46 ↗
  • Start by expanding test coverage and automating the places where humans repeatedly wait, review, or fix the same problems. 30:28 ↗ 31:32 ↗ 37:53 ↗
  • Extend agent support beyond code generation only by supplying the necessary tools, process documentation, and acceptance criteria for QA, operations, support, and production safeguards. 43:35 ↗ 44:46 ↗

References