42  Product Development in the Agentic Era

42.1 Overview

On April 29, 2026, Anthropic published a reflection on how product development itself was changing in the age of AI agents. Written from the perspective of Jess Yan, PM for Managed Agents, the post offered a practitioner’s view of how the role of the product manager, the process of building products, and the relationship between design and implementation were all being reshaped by agentic tools.

The central thesis was deceptively simple: the fastest way to design a product feature is to build it, and the fastest way to build it is with agents. This collapsed the traditional separation between design and implementation — between “what should we build?” and “how do we build it?” — into a single, rapid iteration loop where ideas could be prototyped, tested, and refined in hours rather than weeks.

This chapter explores the specific practices Jess described, with concrete examples of how Claude Code, Claude, and Managed Agents changed the day-to-day workflow of product development at Anthropic.

42.2 The Central Principle: Build With What You Ship

42.2.1 The Problem with Design Docs

Traditional product development followed a sequence: research → specification → design doc → implementation → testing → launch. Each stage was a handoff — from researcher to PM, PM to designer, designer to engineer. At each handoff, context was lost, assumptions were baked in, and the gap between intent and implementation grew.

The fundamental problem was that a design doc is a description of a product, not the product itself. No matter how detailed the specification, the act of implementation always revealed things the specification missed — edge cases the designer didn’t consider, technical constraints that weren’t apparent, user flows that didn’t work as imagined.

42.2.2 Building With What You Ship

Jess’s principle was radical in its simplicity: don’t design against documentation; design against the actual API you’re going to ship. Rather than writing a spec for a feature and then handing it to engineering, build a prototype that uses the real (pre-production) API and iterate on it directly.

graph LR
    A[Traditional: Design Doc] -->|handoff| B[Engineering]
    B -->|implements| C[Product]
    C -->|reveals issues| D[Rework]

    E[Agentic: Build with API] -->|prototype| F[Claude Code]
    F -->|iterates| G[Working Prototype]
    G -->|is| H[Product]

This approach had several advantages:

  • No translation loss: The prototype IS the product, not a description of it.
  • Immediate feedback: You discover what works and what doesn’t by using it, not by reading about it.
  • Realistic constraints: The prototype reveals actual API limitations, performance characteristics, and edge cases.
  • **Faster iteration: Changes to the prototype are immediate, not routed through a specification cycle.
Note

The “build with what you ship” principle was enabled by Claude Code’s ability to prototype against pre-production API specs. A PM could describe a feature in the morning, have Claude Code build a working prototype against the not-yet-released API by the afternoon, and test it with real users by the evening.

42.3 Claude Code for Rapid Prototyping

42.3.1 Prototyping Against Pre-Production APIs

One of the most powerful workflows Jess described was using Claude Code to prototype against APIs that were still in development:

# Claude Code prototyping session
$ claude

> I need to prototype a feature that uses the upcoming
> Managed Agents "dreaming" API. The spec is at
> /specs/dreaming-api-v2.md. Build a working prototype
> that creates an agent, schedules a dreaming session,
> and displays the results.

Claude: I'll read the spec and build a prototype.
[Reads /specs/dreaming-api-v2.md]
[Analyzes API endpoints]
[Generates prototype code]

Prototype ready at ./prototype/dreaming-demo/
Run with: npm start

This took an afternoon, not a sprint. The PM could interact with the prototype, discover what felt right and what didn’t, and ask Claude Code to refine it — all before the API was finalized. Insights from prototyping fed back into the API design itself, creating a virtuous loop.

42.3.2 The Prototyping Loop

1. Describe feature in natural language
2. Claude Code generates prototype against pre-prod API
3. Use the prototype → discover issues
4. Refine the description → Claude Code updates prototype
5. Repeat until the feature feels right
6. The final prototype becomes the reference implementation

This loop collapsed what was traditionally a multi-week design-and-spec phase into hours or days.

42.4 Claude for Open-Ended Research and Discovery

While Claude Code was the tool for building, Claude itself (in conversational mode) was the tool for research and discovery — the phase before you know what to build.

Jess described using Claude for:

  • Exploring problem spaces: “What are the common pain points in agent observability?”
  • Analyzing competitive landscapes: “How do other platforms handle agent scheduling?”
  • Synthesizing user feedback: Reading through hundreds of support tickets and identifying patterns.
  • Generating hypotheses: “Based on this usage data, what features might users want next?”

The key was that Claude was used for open-ended exploration — asking questions where the PM didn’t already know the answer and needed a thinking partner to explore the space.

42.5 Claude Code for Writing and Shipping Custom Agents

Beyond prototyping product features, Jess described using Claude Code to build custom internal agents — specialized tools that automated recurring PM workflows.

42.5.1 Example 1: Adoption Analytics Agent

A custom agent that monitored product adoption metrics and proactively surfaced insights:

# Custom agent: Adoption Analytics (built with Claude Code)
agent_spec = """
You are an adoption analytics agent.

Every morning at 8 AM:
1. Query the analytics database for yesterday's metrics
2. Compare to the 7-day rolling average
3. Identify any metrics that changed by more than 10%
4. For each significant change, investigate possible causes
5. Post a summary to the #product-insights Slack channel

Metrics to track:
- Daily active users
- Feature adoption rate
- API call volume by endpoint
- Error rate
- Time to first value (new users)
"""

This agent ran autonomously, turning what was previously a 30-minute manual analysis task into something that happened automatically every morning.

42.5.2 Example 2: Developer Sentiment Monitoring

A more sophisticated agent used fan-out research to monitor developer sentiment:

Trigger: New GitHub issue or PR comment mentioning "Claude"

Agent workflow:
1. Detect mention → spawn research subagent
2. Research subagent reads the full context (issue, PR, comments)
3. Classify sentiment: positive, neutral, negative, frustrated
4. If negative/frustrated → investigate root cause
5. Summarize findings → post to #dev-sentiment channel
6. Track trends over time → weekly report

This agent used the fan-out pattern — spawning subagents for each mention, running them in parallel, and synthesizing results. It turned thousands of data points across GitHub into actionable sentiment intelligence.

42.5.3 Example 3: Demo Building

For customer demos and sales conversations, Jess used Claude Code to build custom demo environments on demand:

$ claude

> Build a demo environment for the Managed Agents
> "multiagent orchestration" feature. The prospect is
> a FinTech company interested in automated compliance
> checking. Include:
> - A lead agent that receives compliance questions
> - Three specialist agents (regulations, transactions, reporting)
> - Sample data that looks like real FinTech transactions
> - A clean UI that shows the agents collaborating

Claude: Building the demo environment...
[Creates project structure]
[Generates specialist agents]
[Creates sample data]
[Builds UI]
Demo ready at ./demos/fintech-compliance/

A demo that previously took days to prepare could be built in an afternoon — and customized for each prospect.

42.6 Managed Agents: Walk Away and Come Back

The most transformative workflow change Jess described was the shift from synchronous development (you sit and watch the agent work) to asynchronous development (you start an agent, walk away, and come back to completed work).

Managed Agents ran in the cloud, not on the developer’s local machine. This meant:

  1. Start a complex task: Describe what you want done.
  2. Walk away: The agent works in the cloud while you do other things.
  3. Come back to results: Return to find the task completed (or with questions/clarifications).
# Starting a Managed Agent task
agent = managed_agents.create(
    name="Refactor authentication module",
    instructions="""
    Refactor the auth module to use the new token format.
    - Update all token generation/validation functions
    - Migrate existing tokens (backward compatible)
    - Update tests
    - Document the migration path
    """,
    model="claude-opus-4-7",
    timeout="2h",
)

# Walk away. Come back later.
result = agent.wait_for_completion()

42.6.1 The PM Workflow Evolution

This capability changed the PM’s daily rhythm:

Time Traditional PM Agentic PM
Morning Review specs, write tickets Start 2-3 agent tasks
Midday Meetings, reviews Meetings, creative work
Afternoon Follow up on tickets Review agent results, iterate
Evening More tickets, planning Start overnight agent tasks

The PM’s role shifted from managing the pipeline of work to directing agents and reviewing their output — a fundamentally higher-leverage activity.

Tip

The “walk away and come back” pattern was most powerful for well-defined but time-consuming tasks — refactors, migrations, test generation, documentation. For open-ended creative work, synchronous collaboration with the agent was still more effective. The art was knowing which mode to use for which task.

42.7 The Evolved PM Toolkit

Putting it all together, Jess’s toolkit for product development in the agentic era looked like this:

Tool Use Case When to Use
Claude (conversational) Research, exploration, synthesis When you don’t know what to build
Claude Code (interactive) Prototyping, building, iterating When you know what to build and want it fast
Claude Code (custom agents) Automating recurring workflows When you do the same task repeatedly
Managed Agents Long-running, complex tasks When the task takes hours and you want to walk away

42.7.1 The New PM Skill Set

This toolkit required a different skill set than traditional PM work:

  1. Decomposition: Breaking large goals into agent-executable tasks.
  2. Instruction writing: Communicating intent clearly enough for an agent to execute.
  3. Rapid evaluation: Quickly assessing agent output — is this what I meant?
  4. Iteration direction: Knowing what to change in the instructions to get better output.
  5. Tool selection: Choosing the right tool (conversational, interactive, managed) for each task.

42.8 Cultural Implications

42.8.1 The Blurring of Roles

As PMs built prototypes and custom agents, the boundary between PM and engineer blurred. A PM who could use Claude Code effectively could prototype features, build internal tools, and even ship production code — capabilities that were previously the exclusive domain of engineers.

This didn’t eliminate the need for engineers — production systems still required engineering rigor, scalability considerations, and operational expertise. But it did mean that the gap between idea and implementation shrank dramatically, and PMs could operate with much more autonomy.

42.8.2 The Importance of Taste

When implementation becomes fast and cheap, taste becomes the scarce resource. With the ability to build anything quickly, the question shifts from “can we build it?” to “should we build it?” and “is it good?” The PM’s judgment about what users actually need — their taste — becomes more valuable, not less.

Note

Jess’s post ended with a reflection that resonated across the industry: “In the agentic era, the PM who can build will outcompete the PM who can only specify. And the PM who can build with taste will outcompete everyone.”

42.9 Key Takeaways

  • Build with what you ship, not with documentation. The fastest path from idea to validated product is to prototype against the real API, not to write a spec about it.
  • Claude Code prototypes against pre-production APIs in an afternoon. What used to take a sprint now takes hours — describe the feature, let Claude Code build it, test it, iterate.
  • Claude (conversational) is for open-ended research and discovery. Use it when you don’t know what to build — for exploring problem spaces, synthesizing feedback, generating hypotheses.
  • Claude Code builds custom internal agents. Adoption analytics, sentiment monitoring, demo building — recurring PM workflows become autonomous agents.
  • Fan-out research scales analysis. Spawn subagents for each data point, run in parallel, synthesize results — turning thousands of inputs into actionable intelligence.
  • Managed Agents enable asynchronous development. Start a task, walk away, come back to results — shifting the PM from pipeline manager to director and reviewer.
  • The PM skill set shifts. Decomposition, instruction writing, rapid evaluation, iteration direction, and tool selection become the core skills.
  • Implementation becomes cheap; taste becomes scarce. When you can build anything fast, the value is in knowing what’s worth building and judging quality.
  • Roles blur. PMs who build with agents operate with more autonomy, prototyping and shipping without engineering handoffs.
  • The PM who can build with taste outcompetes everyone. In the agentic era, the combination of building capability and product judgment is the defining advantage.