← All speakers

Bio, Work & Ideas

Beyang Liu

Conference affiliation: Amp · 2025

Beyang Liu co-founded Amp, the independent coding-agent company, and Sourcegraph, the code-search company he previously led as chief technology officer. His work addresses a foundational challenge for AI-assisted programming: giving developers and their agents enough understanding of complex software to change it intelligently.

Liu studied computer science at Stanford, including machine-learning research in probabilistic graphical models and computer vision, before working at Palantir on data-analysis software for large companies and banks. In 2013, he and Quinn Slack founded Sourcegraph, initially focused on making sprawling codebases searchable. The company expanded into code intelligence, large-scale code changes, and Cody, an AI coding assistant that grounds its responses in relevant material retrieved from across an organization’s software.

His writing on developer productivity distinguishes the broader software-delivery process from the developer’s immediate cycle of reading code, making changes, testing, and iterating. That systems-level perspective rejects simplistic proxies such as lines written: productivity depends on whether engineers can understand their environment, maintain momentum, and deliver useful work.

As models progressed from autocomplete and retrieval-assisted chat to autonomous tool use, Liu helped build Amp around agent-native workflows. In December 2025, he and Slack launched Amp as an independent company, while Dan Adler became Sourcegraph’s chief executive. Liu remains on Sourcegraph’s board.

  • Codebase context determines agent usefulness. Effective assistance requires finding relevant implementations, dependencies, conventions, and architectural constraints beyond the currently open file. Liu treats retrieval as an engineering problem with two competing failure modes: exhausting the agent’s context window through excessive searching, or gathering so little information that it repeatedly attempts the wrong fix.
  • Specialized subagents preserve working context. Amp delegates bounded tasks to separate agents: Finder searches codebases, Oracle handles difficult reasoning, Librarian examines external dependencies, and the experimental Kraken targets large refactors. Each returns concentrated results to the primary agent. Liu favors tightly integrated tools and matched models over generic integrations or a user-facing model picker, as he explains in his account of Amp’s architecture.
  • Agent evaluation should measure organizational outcomes. Liu assesses coding tools through controlled comparisons, carefully interpreted usage data, developer feedback, and concrete engineering priorities such as delivery speed, test coverage, code review, or modernization. Generated lines and accepted completions cannot, by themselves, establish software quality or business value.
  • Human accountability depends on fast feedback loops. Detailed instructions, tests, browser automation, diagnostics, and diff-based review help agents correct their own work while keeping developers responsible for shipped code. In a production-code demonstration, an apparently simple interface change required exposing the appropriate configuration field without leaking administrative secrets—a practical example of why plausible generated code is insufficient without architectural understanding.

Read the topics behind these talks

4 conference talks

Key ideas

Scroll to read ↓

A Help-button demo leads into Amp’s architecture: specialized tools and subagents conserve context, while distinct execution modes and review interfaces shape how developers work.

  • Adding a Help button to the agent itself
    0:28 ↗
  • The few levers inside an agent loop
    3:19 ↗
  • Tune the tools, then protect the context window
    4:40 ↗
  • Finder, Oracle, Librarian, and Kraken
    7:34 ↗
  • Choose a working mode, not a model
    9:05 ↗
  • The editor becomes a readitor
    11:21 ↗
  • Make activity readable, and make practice shareable
    12:30 ↗
  • The experiment with sponsored inference
    14:14 ↗
  • A community for experimenting with agents
    15:35 ↗

Key ideas

Scroll to read ↓

Booking.com’s work with Sourcegraph connects AI adoption to delivery metrics, then tackles GraphQL generation, legacy migration, and code review through carefully selected context and explicit rules.

  • What did adopting AI actually change?
    0:51 ↗
  • Experimentation creates a cleanup problem
    1:51 ↗
  • Search first, then an assistant people can use
    5:17 ↗
  • Measure delivery, quality, and modernization
    8:30 ↗
  • Prompt customization becomes agent development
    11:49 ↗
  • Retrieve schema paths before generating GraphQL
    12:36 ↗
  • Scope the migration before attempting the rewrite
    13:54 ↗
  • Make code review specific and selective
    15:50 ↗
  • Declare service rules and enforce them earlier
    17:16 ↗
  • Education turns access into regular practice
    19:38 ↗

Key ideas

Scroll to read ↓

A small connector-icon change reveals the larger skill: give coding agents useful context and fast feedback, then use the time they save to understand and review the code.

  • Why capable programmers disagree
    0:16 ↗
  • Capabilities reshape the application
    4:25 ↗
  • Let the agent work; keep the human steering
    6:31 ↗
  • A text box backed by tools
    10:53 ↗
  • Find the issue, then change the connector icon
    12:45 ↗
  • Use execution time to understand the code
    16:26 ↗
  • The missing icon is a data-access problem
    19:44 ↗
  • Detailed prompts become a product behavior
    21:07 ↗
  • Give the agent a way to check its work
    24:17 ↗
  • Expose the endpoint, preserve the boundary
    26:30 ↗
  • Review more deeply and manage context deliberately
    27:44 ↗
  • From detailed instructions to parallel engineering
    30:30 ↗
  • Practice changes the workflow—and habits lag behind
    33:16 ↗

Key ideas

Scroll to read ↓

Six ways to evaluate coding assistants connect developer flow to business value, without pretending that software productivity has a single precise measure.

  • Who can actually measure the return?
    0:36 ↗
  • A straightforward feature becomes a series of side quests
    3:50 ↗
  • More beans, or better beans?
    5:36 ↗
  • Roles eliminated
    9:15 ↗
  • A/B testing velocity
    11:16 ↗
  • Time saved as a function of engagement
    13:24 ↗
  • KPIs tied to desired changes
    16:32 ↗
  • Impact on key initiatives
    18:19 ↗
  • Developer surveys within a budget
    19:35 ↗
  • Define success, then make room to learn
    20:42 ↗
  • From completions to agents, with code still at the center
    21:51 ↗

References