How Anthropic Builds: Lessons from Labs — Mike Krieger, Anthropic

For his first two years at Anthropic, Mike Krieger, Instagram’s co-founder, worked as chief product officer. Claude could critique a strategy document, but that left him watching other people build while he squeezed his own experiments into weekends. The growing FOMO prompted a move into an individual contributor role. The change coincided with more capable internal models—and a different way of assigning engineering work. 1:02

The earlier workflow began with a human decomposing an idea into steps, then guiding the model through them. The newer workflow begins with the desired result: describe the goal, let Claude work, and discuss questions and tradeoffs as they arise. That moves some implementation planning into the delegated work. It also creates an obligation at the other end: understanding the decisions well enough to judge them. A finished result can still require Claude to break down its reasoning before the human can usefully respond.

“Be unreasonable” becomes the interview’s practical challenge. A nontechnical colleague asked Krieger to change an internal product; he realized his own next step would simply be to ask Claude. Why should that person need him as an intermediary? Asking for more ambitious results is partly a learned habit, and the first generation of AI products taught people to ask small by limiting what models could reach and do.

Tool access changes what happens after an obstacle. In the PDF example, a built-in parser cannot handle the document. A model confined to that parser has reached a dead end. A CoWork environment with a virtual machine and the ability to write Bash gives Claude another route: it can try writing a script to parse the file. The knowledge worker may never personally need a shell, yet the agent needs that flexibility to recover from a tool’s limitations.

The larger example starts with a Labs project written in Python. Claude Code had found a better deployment approach using Bun, which made a TypeScript port attractive. The project contained a couple hundred thousand lines of code. Under Krieger’s earlier engineering instincts, rewriting that much working software for deployment would have seemed like a bad idea. This time, he set up a dynamic workflow and asked for the entire port over a weekend. 4:29

The workflow did more than translate once. It ported the code, verified and double-checked it, read both versions, and repeatedly worked over its output. By Monday, Krieger reports a completed port that worked and was deployable. He does not specify the verification checks or establish complete behavioral equivalence; the concrete result is the working port he describes.

What makes this a weekend workflow rather than a single translation request? The diagram separates the deployment goal, conversion, and repeated checks. Its feedback edge is the important relationship: Claude continues working after producing an initial version, while the original Python code remains available for comparison.

The follow-up question asks whether a product can be migrated as readily as a compiler or runtime with extensive tests. Krieger reaches back to MonkeyType, an Instagram tool that captured the types actually used during production execution and mapped them back into the codebase. That suggests another source of guidance for an LLM-assisted conversion: observed runtime behavior, alongside tests for selected segments. His harder problem is choosing a part of the system that can move incrementally, rather than attempting an overnight replacement of everything.

Incremental changes need infrastructure for observation and control. During Instagram’s first week, the backend struggled under load. An already-scheduled infrastructure lunch became an impromptu scaling consultation, leaving Krieger with two pieces of advice from 2010 that still shape his approach. 6:45

• Measure ahead of time: Collect metrics you might need before something breaks. A newly added metric cannot tell you whether an outage’s current value is unusually high, because there is no earlier baseline to compare it with.

• Build runtime controls: Feature flags, gradual rollouts, and dynamic configuration let the team change behavior under load. Early Instagram needed some configuration changes within seconds; making those controls easy to use was part of keeping the service running.

Those controls become useful again when AI products require changing tradeoffs at runtime. Faster implementation expands what a team can attempt, but measurements and adjustable configuration determine whether it can understand and respond to the consequences.

Inside Anthropic, interactive Claude Code sessions still serve work that needs rapid back-and-forth: iterating closely on a particular problem. Claude Tag brings out the more asynchronous delegation Krieger says has already shaped internal work. People tag Claude to hand over assignments, and colleagues can see how they use it. Like watching other people prompt Midjourney on Discord, that shared setting exposes possibilities a private terminal session would hide. 8:23

One colleague’s request expanded Claude’s assignment from fixing a bug to looking after part of the codebase: monitor a feedback channel, proactively take on tasks, fix them, and respond when an API changes. Watching that request made Krieger realize he had been treating the system as little more than Claude Code in Slack. Context and memory support continuing responsibility; proactive work extends the assignment beyond a single prompt.

The change is visible in the work arrangement. Multiple people can observe delegation, learn from it, and collaborate around an agent that continues to hold relevant context. Ambition spreads through examples of actual requests, while execution becomes less dependent on someone continuously steering an individual CLI session.

Delegation produces a review bottleneck, particularly for architectural changes. Allocating more review time addresses only part of it. The deeper constraint is whether a human can conceptualize the change at all. A pull request with 2,000 lines may be readable as code without conveying a clear picture of what changed and why. 10:11

Claude Code Artifacts help communicate that picture. Alongside the pull request, the reviewer receives an explanation of the change’s intention and the tradeoffs made during implementation. This shifts some discussion toward the decisions behind the code, with production measurement supplying feedback on what those decisions actually do.

Krieger acknowledges that he does not read every line of every pull request. Instead, he asks Claude to investigate the questions he would raise about the code. Important reviews remain human-driven: the human identifies concerns and uses Claude to explore them. Cosmetic visual changes receive a lighter approach, with a willingness to fix forward. An explanation makes a large change easier to discuss without itself proving that the implementation is correct.

Labs applies a two-week “persevere or pivot” review to every project. A project can continue, change direction, or shut down. Krieger says projects have been shut down in basically every cycle. That frequency serves the group’s purpose: prototype quickly, ship internally, perhaps reach early access, and stop work that does not succeed. 11:54

If each experimental project owned a permanent reporting structure, this cadence would demand a reorganization every two weeks. Labs instead assembles temporary teams around “bets,” drawing people from product and engineering. A bet lead, or directly responsible individual, coordinates the work but usually does not manage the other participants.

• Bet leadership: Gives a temporary project someone responsible for its progress while allowing the team to disband when the experiment ends.

• Engineering management: Supports coaching, interpersonal needs, and personal development, while helping individuals find work they are excited about and do it well.

• Product teams after traction: Add a more settled structure when a bet proves worthwhile. Claude Design began as an ad hoc group; after shipping, gaining traction, and making a second release in June, it received hires for a specific team.

How can projects end frequently without constantly rebuilding the organization? The diagram shows a temporary bet moving through review while management continues to support the people. Claude Design illustrates the other outcome: successful experiments can become more structured product teams. Ending a bet and changing a person’s manager are separate decisions.

Claude Design’s next opportunities follow the earlier concern about constraining the model. One is better interaction with other Anthropic products: a conversation in Claude Code, an interactive design, and further implementation should connect more readily. Poor communication between services blocks possibilities even when the individual services are capable. 14:08

Another opportunity is the increasingly blurry line between a design and an application. Claude Design generates HTML and JavaScript, so people have built functional experiences, including games, beyond its intended use. Those examples lacked persistence at the time described. Saving data and sharing the result with others are directions Krieger wants to explore: capabilities that would let an interactive design grow into something people can continue using.

Removing features is harder than a usage percentage makes it look. Anthropic has a Slack channel called Project Unship for discussing what to remove. Krieger recalls Instagram features used by only 4% to 5% of users. Twenty such features can serve different groups, much like Microsoft Word’s many functions: each person uses a subset. Low usage for one feature therefore does not settle whether removing it simplifies the product at an acceptable cost.

Krieger recalls Styles being removed and sees Skills as a better successor to its prescriptive approach. A new generation of AI capability can justify replacing an earlier product primitive. His larger target is the distinction users must make between code, CoWork, and chat. The products do not interoperate or delegate to one another well enough, and ordinary users may not understand why the split exists.

The friction becomes concrete when a CoWork session has already worked out what to build, yet the user must ask it to write a paragraph to paste into Claude Code. The human is carrying context between products that should be able to hand the work over. Removing that manual transfer would help Claude act on the plan and reduce the product distinctions the user has to manage.

Rapid lab releases raise an uncomfortable startup question: why build a company if a model provider can absorb its functionality? Krieger’s optimism rests on cheaper, faster experimentation, coupled with work models do not automatically resolve: choosing an idea, exercising taste, understanding users, and reaching them. His Instagram comparison is that a large incumbent’s product will reflect its existing integrations and strengths, leaving room for a team focused on a different experience. 17:44

That room is not unlimited. Some capabilities may become Skills and no longer warrant a separate product. Krieger nevertheless expects four or five people obsessed with a particular problem to move faster than those same people inside a more complex organization. His case for startups centers on detailed knowledge of an industry or group of users, fast listening and iteration, and fewer coordination demands. Faster coding improves the timeline; it does not by itself determine whether the company understands a worthwhile problem.

Finance gives this discussion a concrete technical shape. Krieger sees models improving across generations and treats finance startups’ domain-specific evaluations as useful barometers. The architectural opportunity is to combine flexible, just-in-time analyses, dashboards, and workflows with a verified set of underlying data. 20:18

• Verified data and traceable work: Verifiability, audit logging, and data provenance give a financial company a way to inspect the basis of an analysis. Making everything free-form risks confusion.

• Flexible applications above that data: The agent should still be able to create the analysis or workflow a task needs. Existing systems built for verification and auditability often make these agent-driven workloads difficult, creating opportunities both in the data infrastructure and in applications built on it.

The design decision is where to draw that separation. A system can preserve a trustworthy basis for work without prescribing every application that uses it. Reaching that combination requires working through infrastructure built to control and record work, often with little flexibility for an agent assembling new workflows on demand.

The closing question turns from technical throughput to burnout. Instagram’s external rhythm included an annual Apple announcement and competitor launches every three or four months. Anthropic’s weekly all-hands has a slide called “The week in AI,” followed by “And it’s only Wednesday.” Models, products, and regulatory developments arrive fast enough to make constant reaction exhausting. 22:03

Krieger’s first response is to carve out actual time off. He has seen people close to him burn out and take a long time to recover. His working belief is that no job is so important that someone cannot be offline for a couple of days. If stepping away feels impossible, he recommends working with a mentor to understand and remove what is preventing it.

The second response is perspective. His sports analogy is that a person is never as good as their best game or as bad as their worst. AI’s “it’s so over, we’re so back” cycle can turn each launch into a verdict on the team or the self. Remembering a similar crisis—even one only three months earlier—helps place today’s reaction inside a longer effort to build a team and culture that can keep going.

The final lesson returns to the emotional cost of ending experiments. A coach advised Krieger that other people on the team often feel what he is feeling, and that saying it aloud can help. At a meeting about shutting down a Labs initiative he had worked hard on, he opened by naming his sadness and frustration that it had not worked out. 24:50

His point is that such an admission can make it easier for colleagues to express their own anger or disappointment, then ask what to do next. Frequent shutdowns may be an intentional part of Labs, but intention does not erase attachment to the work. Naming the loss offers a way toward the next decision without requiring everyone to pretend the last one was painless.