Anthropic 如何构建产品：Mike Krieger 谈智能体时代的工程、组织与决策

Brief Description

Mike Krieger, co-founder of Instagram and a technical staff member at Anthropic, discusses how increasingly capable models are changing the way teams build products. In conversation at AI Engineer, he covers delegating outcomes rather than tasks, using agentic systems as proactive teammates, scaling and review practices, the operating model of Anthropic Labs, opportunities for startups and vertical AI, and how to maintain perspective in a fast-moving industry.

Table of Contents

• From product leadership to building with models
• Asking for unreasonable outcomes
• Shipping, migration, and operational control
• Agents as teammates and code review as intent review
• How Anthropic Labs organizes bets
• Product simplification, startups, and vertical AI
• Working sustainably in a fast-moving field

From Product Leadership to Building with Models

Host: Krieger co-founded Instagram and now works at Anthropic. How has his model usage changed as internal models have improved?

Mike Krieger: The change came from both the models and his own role. For his first two years at Anthropic he was Chief Product Officer. He used models as much as possible—for example, writing a product-strategy document and asking Claude to critique it—but that was different from building directly with the models. He spent weekends experimenting and eventually decided that the moment was too interesting to stay away from the work. He has seen a related pattern elsewhere: people who had been CTOs are choosing individual-contributor roles at Anthropic and other companies.

His move happened around the period when Anthropic began getting internal snapshots of what became Mythos and Fable. The important shift was from decomposing an idea in his head, following the engineering steps, and iterating through each one, to describing the desired goal and asking the model to work toward it. The human and model can then discuss trade-offs, surface questions, and evaluate where the work landed.

That requires a new delegation habit. Fable can return work with an account of the trade-offs it made, and Krieger sometimes has to ask it to explain those choices more simply. The central change is to specify the end state, then let the system work on the problem rather than directing every individual task.

Asking for Unreasonable Outcomes

Host: A previous speaker urged people to “be unreasonable.” Where has Krieger become more ambitious with prompting?

Mike Krieger: He likes that framing. One Labs initiative involved an internal product that was not working as someone wanted. Rather than treating the request as something a developer alone should handle, he realized the non-technical person could be taught to ask Claude directly. Product teams and the industry need to teach people to be more unreasonable in their use of these systems.

The first generation of AI products put models too much in a box: they had constrained tool access and limited freedom. That made ambitious requests harder to fulfill. A model might be able to write code but not run it, or inspect its environment only partially. More capable product surfaces change the calculation. A knowledge worker may not seem to need a virtual machine that can write Bash, but it becomes useful when the built-in method fails—for example, when a PDF cannot be parsed and the system can write another script to handle it.

Krieger’s most unreasonable request involved a Labs project written in Python, a language that is personally meaningful to him because Instagram was built in Python. Claude Code found a better deployment approach using Bun, so he asked it to port the whole project to TypeScript. Earlier in his career, porting a few hundred thousand lines of code would have seemed like a bad idea. He set up a dynamic workflow, let the system port and verify the code over a weekend, repeatedly compared the results, and returned on Monday to a completed, deployable version.

Shipping, Migration, and Operational Control

Host: Could the same approach port a product such as Instagram, not just a runtime or compiler?

Mike Krieger: The product case may be neither clearly easier nor harder. When Python 3 arrived, Instagram was able to add type annotations, and the company debated whether Python would eventually hold it back. Krieger believed it could go much further, while types would help the team avoid getting in its own way. Instagram built MonkeyType to capture the runtime types actually used in production and map them back to the codebase.

That pattern suggests useful approaches for conversion or cross-compilation with language models. Teams can lean more heavily on production data and run segmented tests. The difficult part is finding a boundary where migration can begin incrementally instead of attempting to replace everything overnight.

Host: Users ultimately become tests, and rollout infrastructure makes experimentation possible.

Mike Krieger: At Instagram’s launch, the backend struggled during the first week because the team did not yet understand all of its scaling needs. At an infrastructure lunch scheduled by an investor, the team absorbed two pieces of advice that stayed with him. First, measure everything that might conceivably matter before an outage; otherwise, when something breaks, teams cannot tell whether a metric is normal or high because they only just added it. Second, build thoughtful knobs and feature flags.

Even early Instagram had simple but effective ramp-up, rollout, and dynamic-configuration mechanisms. Runtime settings sometimes had to change within seconds to handle load. Making that a first-class capability was essential. Krieger sees the same need in AI, where teams are constantly making different trade-offs and need runtime configuration to manage them.

Agents as Teammates and Code Review as Intent Review

Host: Claude Code and similar tools make software development highly dynamic: teams ship one application with thousands of flags. How does that affect everyday work?

Mike Krieger: Anthropic has been working this way for some time. Interactive tools such as Claude Code are useful when someone is iterating closely on a specific problem and wants high-bandwidth back-and-forth. But much of the work is delegated through systems such as Tags. Their multiplayer nature is important: seeing how other people use a system, much as people observed each other’s Midjourney use on Discord, encourages more ambitious use.

Seeing someone tell Claude not merely to fix a bug, but to take responsibility for part of a codebase, monitor a feedback channel, proactively address tasks, and respond when an API changes, reveals a more advanced model of use. The agent becomes more than a glorified version of Claude Code in Slack. It is a teammate with context and memory that can act proactively. That has made internal work more multiplayer, asynchronous, and proactive rather than a collection of people working separately in their CLIs.

Host: Is code review and Git now the bottleneck? Does a person still need to inspect the code before it merges?

Mike Krieger: Reviews remain a bottleneck, especially for architectural changes. The deeper constraint is human ability to fully conceptualize what is happening. Anthropic’s Claude Code artifacts were partly built to address that. Instead of giving a reviewer a two-thousand-line pull request and expecting them to infer it from the code, teams can share an artifact explaining the intention of the change and the trade-offs that were made.

Code can ultimately be verified in various ways, but discussion should increasingly focus on intent and trade-offs, followed by measurement in production. Krieger does not claim to inspect every line of every pull request. He asks Claude to investigate the questions he would ask about the code. That is Claude-powered review, while remaining human-driven. For important changes—and, differently, for cosmetic visual changes—teams can make an informed decision and fix forward when necessary.

How Anthropic Labs Organizes Bets

Host: What does the Anthropic Labs organization look like, given products such as Claude Code and Tags?

Mike Krieger: The team has to balance flexibility with support for people. The importance of engineering management has not disappeared: coaching, interpersonal work, and individual development remain important. In a Labs group, however, the operating cadence is two-week reviews in which every project is considered for “persevere or pivot.” A project may continue, pivot, or be shut down. Projects are closed in many of these cycles, and repeating that process makes shutdown feel less like personal failure and more like the intended consequence of rapid prototyping.

The group prototypes quickly, ships internally, may move work to early access, and winds it down if it does not work. Because projects change so quickly, aligning the organization chart too tightly with individual projects would mean reorganizing every two weeks. Instead, a team working on a given “bet” draws people from across disciplines. There may be a bet lead or directly responsible individual, but that person usually does not manage everyone working on the bet.

This structure makes it easier to disband a project that is not working and move on. Engineering managers concentrate on ensuring that each person is assigned to work they are excited about and can do effectively. When a product proves it has legs, it becomes more solid. Claude Design, for example, began as an ad hoc group; after shipping, gaining traction, and receiving a major second release, it acquired a more dedicated team and more structure.

Host: Where can Claude Design go next?

Mike Krieger: One constraint is how well Anthropic’s product surfaces interact. He wants a more seamless path between a conversation about a design and interactive design work, including work with Claude Code. Services that do not communicate as well as they could hold back many ideas. Another direction is the increasingly blurry line between a design and an app. People have built fully functional experiences, even games, with Claude Design, despite that not being its original purpose. The interesting path is from a polished design to an artifact that can persist data, be shared with others, and become a foundation for further work.

Product Simplification, Startups, and Vertical AI

Host: Instagram famously removed much of its early product to become focused. What would Krieger remove from AI products or Claude?

Mike Krieger: Anthropic has a Slack channel called Project Unhip for considering what should be removed. At Instagram, a feature used by four or five percent of people could seem small, but many such features could each be valuable to different user groups—the familiar Microsoft Word problem of disjoint usage. It is always hard to decide what to remove.

Anthropic is still a younger product and may have fewer such cases. It recently removed Styles, which was used by a small share of users and was too prescriptive; Skills offered a better approach. Product teams need to be willing to unship primitives from one generation of AI, or supplement and replace them with the next generation.

The bigger issue is product complexity. Users are asked to distinguish among Claude Code, Cowork, and chat even though the surfaces do not interoperate well or delegate to one another. An ordinary person may not be able to explain why they are separate. Removing some of that complexity would let Claude do what it needs to do more directly. A workflow where someone maps out a build in Cowork and then has to request a paragraph to paste into Claude Code should no longer be necessary.

Host: Why should startups continue building if Anthropic might release capabilities that reshape their industries?

Mike Krieger: One reason he joined Anthropic was that stronger models would unlock a new generation of startups. They do not solve a founder’s ideation or taste, but they make experimentation simpler and help teams move faster. He remains convinced of that. Instagram once faced questions about what would happen when Google launched a photo product. Google would make a product shaped by its own integrations and strengths.

There is still ample room for teams that are intensely focused on a vertical, industry, or group of users they know deeply—knowledge a general-purpose lab will not reach at the same level. That focus can earn adoption and user love. The models make some work harder to defend, and some capabilities may become skills rather than standalone products, but the hard work remains: understanding people’s needs, reaching them, listening, and iterating quickly. Four or five people obsessed with a problem can still move faster than the same people inside a more complex organization. Writing code was never the sole thing that made or broke a startup; user understanding and fit matter more.

Host: What does that mean for vertical AI in areas such as healthcare and finance?

Mike Krieger: Finance is an area where model capability is visibly improving from generation to generation, and finance-focused startups have developed their own evaluations that help show whether models are getting better for those use cases. The promising mix is a model flexible enough to create just-in-time analyses, dashboards, and workflows, combined with a verified set of data. Making everything completely free-form would create confusion and would not meet the needs of most financial-services companies.

The design challenge is to establish verifiability, audit logging, and data provenance without constraining the applications that can be built on top. Done well, that provides both flexibility and trust. Existing systems built for verifiability are often not very flexible for agentic workloads, so there is opportunity on both sides of the stack.

Working Sustainably in a Fast-Moving Field

Host: How should people working intensely in AI avoid burnout?

Mike Krieger: It is difficult because the industry is moving much more quickly. At Instagram, the major questions might have been an annual Apple announcement or a competitor launch every few months. At Anthropic, a weekly all-hands can already include a “weekend AI” slide by Wednesday because a competitor has shipped a model, a new product has appeared, or regulation has changed.

The first answer is to deliberately take time off. Burnout can leave people unable to continue and can take a long time to recover from. No job should be so important that a person cannot be offline for a couple of days. If it is, something is probably wrong, and the person should talk with a mentor about how to unblock it.

He also draws on a lesson from sports: people are never as good as their best game or as bad as their worst one. In AI, the emotional cycle can swing quickly between believing everything is over and believing everything is back. Remembering that the cycle will recur provides perspective. Startup teams may feel that a setback is unrecoverable, as Instagram did at times, but working through those moments is what defines a company.

The work is fast-moving but also a long game. It is not only about today’s model launch, product launch, or immediate reaction. Teams need to trust that they are building the culture and capability to get through setbacks, zoom out even if the relevant perspective is only a few months, and avoid letting their sense of self or success be driven by the day-to-day.

Host: Is there advice from a coach or mentor that he repeats during difficult moments?

Mike Krieger: When one person is feeling something, others on the team are often feeling it too. A coach encouraged him to verbalize emotions: saying that he is stressed, or that he is sad an initiative is being shut down. He recently opened a meeting about a project he had worked hard on by saying that he was sad and frustrated that it had not worked out. That gave others room to say they were upset or sad as well. Openness and vulnerability let a team name what is happening, after which it becomes easier to ask what to do next.

Host: The conversation closes by encouraging people to talk about their feelings, manage their mental health, and keep shipping.