By playing, you agree to uListen's Terms and Privacy Policy and YouTube's Terms of Service.
WorkOSBoris Cherny: Claude Code & the Future of Engineering | Acquired Unplugged presented by WorkOS
Summaries, chapters, transcripts, and FAQs on this page are made by uListen, not YouTube.
CHAPTERS
Chapter summaries
How Claude Code started as an Anthropic Labs prototype
Ben asks for the origin story, and Boris explains Claude Code began as an experimental effort on a prototyping-oriented Labs team. The team wanted to discover a “next big product” that would also push model capabilities, and they chose to go all-in on a coding agent even though early results were weak.
- •Claude Code emerged from a Labs-style prototyping team tasked with finding the next major product
- •The team felt there was significant “product overhang” where models could do more than products captured
- •Early coding tools were mostly autocomplete or Q&A, not full code-writing agents
- •The first versions of Claude Code were poor and only handled a small fraction of Boris’s coding
Why Anthropic cared about coding: safety research and studying models in the wild
Asked about the state of coding at Anthropic, Boris says coding and tool/computer use have long been core directions. He frames coding as a practical way to study AI safety “in the wild,” because it’s a channel for models to interact with the world and reveal misalignment issues.
- •Internally people still used IDEs at the time, but company focus included coding, tool use, and computer use
- •Boris says Anthropic’s overarching purpose is AI safety, widely shared across employees
- •Safety work includes studying models outside “petri dish” conditions to see real-world behavior
- •Coding is positioned as an obvious application for useful deployment and safety observation
Coding as a clean test environment—and as a business model that supports safety
Ben notes code offers clearer pass/fail feedback than natural language tasks; Boris agrees. Boris adds that coding is commercially valuable and fits enterprise and startup customers, enabling a business model that doesn’t rely on ads and keeps the company aligned with its safety focus.
- •Ben describes coding as a constrained domain with clearer correctness signals
- •Boris agrees coding is easier to evaluate than fuzzy tasks like poetry
- •Boris references Hofstadter’s poetry-translation example to contrast “fuzzy” vs. precise problems
- •Coding’s commercial value supports building a business that funds safety work without ads
Boris’s dev-tools philosophy: build tools as a side hustle for real problems
David asks how Boris’s Meta background informed Claude Code. Boris says dev tools were never his main focus; he prefers building tools as needed while solving a broader product/business problem, starting by building for himself and then discovering it helps others.
- •Boris says dev tools worked best for him as a “side hustle,” not the main goal
- •He emphasizes solving real business problems and building something people love
- •He mentions being the first hire at a YC company early on
- •He applied the ‘build for yourself first’ approach and was surprised how broadly useful it became
From 10% to “I haven’t written code”: the step-change was mostly model upgrades
Ben asks what bottleneck limited early performance and what changed. Boris attributes the biggest jumps to underlying model releases, while noting significant product work also improved the overall “harness” and user experiences across many surfaces.
- •Boris cites specific step changes tied to Sonnet 4/Opus 4, and later Opus 4.5
- •He says the largest driver of higher code-written percentages was model capability improvements
- •He notes substantial work also went into the product harness and workflow features (e.g., plan mode)
- •Claude Code expanded beyond a CLI into multiple ways of using it (desktop, mobile, Slack, GitHub)
Dogfooding loop: everyone uses Claude Code, including researchers building the models
David asks how closely Claude Code’s experience fed back into model development. Boris describes a simple loop: people across Anthropic—including researchers—use Claude Code daily, and that usage informs both product and model work.
- •Boris says everyone at Anthropic uses Claude Code every day
- •Researchers building the model use it alongside product builders
- •He frames this as the core feedback cycle between product experience and model development
Measuring impact: exponential thinking, 3X+ output, and two-day ramp-up
Ben asks for metrics to understand how Claude Code changed the company’s trajectory. Boris describes an environment where key charts are exponential, claims code output per engineer increased substantially, and highlights dramatically shortened onboarding as new hires rely on Claude for internal knowledge and tasks.
- •Boris says AI labs get used to exponential curves and often use log-linear charts
- •He claims code output per engineer rose sharply; he references a previously shared ~3X figure and says it’s now outdated and higher
- •He notes productivity often declines as teams grow, but says Claude Code changed onboarding dynamics
- •He says new engineer ramp-up can be about two days, with newcomers learning by asking Claude (including database querying)
What counts as ‘writing code’ now: abstraction keeps rising, from IDEs to parallel agents to loops
Ben asks how many new engineers have written any code, prompting a discussion about what “coding” means. Boris places current practices on a historical abstraction continuum and describes his own shift from IDE use to running multiple instances in parallel, and then to writing loops that manage prompting.
- •Boris challenges the definition of “writing code,” comparing eras from punch cards to modern languages
- •He argues programming abstraction has always increased over time
- •He says he uninstalled his IDE after not opening it, shifting to managing multiple parallel model instances
- •He describes a new level where he doesn’t prompt directly; instead he writes loops that drive the prompting and execution
Hiring and team design: the rise of the generalist ‘builder’ and merging roles
David asks how Anthropic evaluates engineering candidates now. Boris says his team values generalists and describes a shift away from rigid handoffs between research, design, PM, and engineering toward individuals who scope, talk to users, design, analyze data, and ship.
- •Boris says the Claude Code team loves generalists
- •He contrasts the old workflow of sequential handoffs with today’s blended responsibilities
- •He says engineers on the team do scoping, user conversations, design work, and data tasks like dashboards
- •He notes non-traditional roles shipping code (designers, finance), reinforcing the ‘builder’ concept
Why Cowork happened: non-engineers pushed past the terminal barrier
Ben shares an Acquired workflow story and uses it to ask about Claude Cowork’s origin. Boris says he saw non-engineers (like data scientists) overcome setup friction to use Claude Code effectively, and broader examples convinced him demand had reached a level where a new product was warranted.
- •Boris recounts seeing a data scientist use terminal-only Claude Code for data analysis despite setup hurdles
- •He says usage spread quickly among data scientists because it worked well for them
- •He references seeing a user example where Claude Code was applied in an unexpected non-engineering context
- •He says the strength of non-engineer demand signaled it was time to build a product like Cowork
Prototyping Cowork: killed directions and the importance of desktop/file access
Boris explains Cowork was built rapidly and selected from multiple prototypes. He describes failed approaches (Slack and web-based concepts) and argues browser-based experiences felt wrong partly due to friction and limited access to local tools and files, reinforcing the ‘build what we love to use’ philosophy.
- •Boris says Cowork was built in a little over a week and entirely using Claude Code
- •He says Slack-based prototypes didn’t work well because making good Slack chatbots is hard
- •He says web prototypes didn’t feel great and lacked access to local tools
- •He highlights file-system friction (e.g., drag-and-drop) as enough to break the experience
Why models ‘want’ to code: computation vs. precomputing, and tool use anecdotes
Ben describes doing analysis in chat without using Claude Code directly, leading Boris into a discussion of when to do work at inference time versus having the model write programs that can be run repeatedly. Boris argues code is the model’s natural interface to the world and shares an early example of the model writing and using scripts to answer a real-world question.
- •Boris contrasts real-time inference with having the model write programs that can be rerun
- •He frames coding as the natural way software-models interact with the world via tools
- •He says early Claude Code used a command-running tool the model learned to use with little instruction
- •He recounts the model writing an AppleScript via a generated program to identify what music was playing
‘Member of Technical Staff’: flattening titles as a cultural forcing function
Ben asks about Anthropic’s widespread “member of technical staff” title and its pros/cons. Boris acknowledges the ambiguity can be annoying, but likes the flattening effect, arguing that prominent senior titles can discourage pushback and that removing them can keep ideas evaluated more on merit.
- •Boris says the title can be confusing because it obscures role and what someone works on
- •He compares it to Meta’s practice where the title stays “software engineer” without senior modifiers
- •He argues senior titles can cause deference to bad ideas and reduce healthy pushback
- •He shares an anecdote about pitching ideas to VPs without them knowing his level, enabling more direct idea testing
Organizing for the next months: more tokens, fewer people per project, compounding automation
David asks what founders should change in their mindset by the end of the year. Boris suggests enabling broad experimentation with generous token budgets and intentionally staffing projects lean, expecting teams to automate and streamline; he and the hosts discuss compounding effects and a “pre-compiling” framing.
- •Boris suggests giving people as many tokens as possible so they can experiment
- •He proposes underfunding projects in headcount (e.g., fewer engineers than feels necessary) while supplying tokens
- •He agrees the benefits can compound as teams automate repeatable work and make future work cheaper
- •Ben summarizes the idea as shifting budget from humans to tokens to lower ongoing costs after upfront work
Taste, coding style opinions, and what remains uniquely human: values
David asks about “taste,” and Boris reflects on losing confidence in personal coding-style preferences as models write more of the code and still meet business outcomes. He suggests product taste as an advantage may erode as models improve idea selection, and he speculates the enduring human contribution will be teaching values—how to be “a good model.”
- •Boris describes abandoning a strict ‘no classes’ rule after humans and then models wrote classes effectively
- •He says business outcomes can matter more than personal stylistic preferences, especially when delivery is faster
- •He predicts the current advantage of product taste may diminish as models generate better ideas from feedback sources
- •He suggests the final thing humans teach models is values, likening it to teaching kids to be good people
