Home
Jul 26, 2026
View All

Anthropic's First PM on How Claude Got Built

·1 underrepresented voice

The Short Version#

Dianne Penn, Anthropic's first technical PM, lays out the actual decisions that made Claude — the coding pivot, the eval loop, what "token maxing" means for agentic systems — while LangChain makes the case that owning your AI infrastructure is the only real moat. Both are worth sitting with.

Lenny's Newsletter / Dianne Penn — Anthropic's First PM on the Bets That Built Claude#

Source: https://www.lennysnewsletter.com/p/anthropics-first-technical-pm-on Credibility: High (first-party account from the PM who was actually there, published via Lenny's Newsletter on 2026-07-26)

What happened: Dianne Penn, Anthropic's first technical PM, went on Lenny's podcast to talk through the formative product decisions that shaped Claude. The framing is around what she calls "the bets" — specific pivots and prioritization calls that turned Claude into a dominant model. Two stand out: the coding pivot, and what she describes as an "eval-driven development loop" that became Anthropic's core product methodology. She also introduces the concept of "token maxing" as a relevant pattern for agentic systems, and asks the question nobody wants to answer yet: what happens after coding is solved?

Key patterns:

  • The coding pivot: Anthropic made a deliberate call to prioritize coding as Claude's breakout use case, even when it wasn't the obvious choice. This is the classic "pick your wedge" product decision — identify the one thing you can win at first, then expand. The bet paid off.
  • Eval-driven development loop: Penn describes a methodology where evaluations drive iteration, not intuition. This is significant for PMs building on top of LLMs — if you don't have evals, you don't have a feedback loop, and you're flying blind between releases.
  • Token maxing: Referenced in the context of long-running agentic systems. The implication is that the ceiling on what agents can accomplish is partly a function of how well models handle extended context — and Anthropic has been building toward this explicitly.
  • The "jagged edge": Penn uses this term (related to Ethan Mollick's framing) to describe the uneven capability profile of AI — brilliant at some things, weirdly broken at others — and how Anthropic thinks about product surface area accordingly.
  • What comes after coding: The question she leaves open. If coding becomes a solved problem, what does the next product wedge look like? She doesn't fully answer it, which is the right move — it's a genuine open question.

Why it matters for PMs: This is a rare first-person account of product decision-making inside a foundation model company. Most of what gets published about Anthropic is external analysis. Penn's framing of eval-driven development is directly applicable — if you're building AI features and you don't have a structured eval process, you're operating on vibes. The coding pivot story is also a reminder that the right product wedge isn't always the obvious one. It requires conviction to narrow before you expand.

Critical questions:

  • How transferable is Anthropic's eval-driven loop to product teams that don't have model-level access? Can you run a meaningful eval loop on top of an API?
  • The coding pivot worked partly because Anthropic had the resources to make it. How do smaller teams decide which wedge to bet on without that cushion?
  • Penn says "after coding is solved" — but what does "solved" mean for a product team? Zero errors? Autonomous end-to-end? The definition matters a lot for roadmap planning.
  • Token maxing is a capability claim, but production agentic systems still fail in unpredictable ways. How does Anthropic actually validate reliability at extended context lengths?

Action you could take today: If you're building on Claude or another model and you don't have a formal eval process, draft what one would look like for your product. What are the three things your AI feature absolutely must get right, and how are you currently checking that it does?

LangChain — Own Your Intelligence: The Key to Lasting AI Advantage#

Source: https://www.langchain.com/blog/own-your-intelligence Credibility: Medium-high (first-party strategic post from LangChain, published 2026-07-25; motivated reasoning likely since they're selling the tooling, but the underlying argument is coherent and worth engaging with)

What happened: LangChain published a strategic framing post arguing that companies using off-the-shelf AI will converge on the same outputs — and that real differentiation comes from owning four things: your agent systems, your governance layer, your context (proprietary data and memory), and your feedback loops. The post is a direct response to a pattern they're seeing in the market: companies that treated AI as a vendor relationship are now realizing they can't differentiate on capabilities alone.

Key patterns:

  • Own your agent systems: Don't treat agent logic as a black box you rent. If your agents are entirely defined by a third-party platform, your competitor can replicate your product by signing the same contract.
  • Own your governance layer: Cost control, compliance, and audit trails aren't afterthoughts — they're the infrastructure that makes AI trustworthy enough to deploy at scale. Companies that skip this are building on sand.
  • Own your context: Proprietary data, institutional memory, and domain-specific context are what make AI outputs different from what anyone else can produce. This is the actual moat — not the model.
  • Own your feedback loops: The companies that get better over time are the ones systematically capturing what worked and what didn't. Without a feedback loop, you're not learning — you're just running inference.

Why it matters for PMs: This maps directly onto the build-vs-buy question that's alive in basically every product team right now. LangChain's framing is a useful heuristic: you can rent the model, but you should own the context, the evals, and the feedback mechanism. The teams that don't build that ownership layer are going to find their AI features commoditized faster than they expect. This also connects to the open question around AI moats — the post is basically saying that the moat is never the model, it's always the data and the loop.

Critical questions:

  • LangChain has an obvious incentive here — "own your infrastructure" is also "buy LangSmith." How much of this argument holds if you're using a competitor's observability tooling?
  • "Owning your context" sounds right, but context curation is expensive. Who owns that work on a typical product team — PM, data, engineering?
  • The governance layer recommendation is real, but at what team size does it make sense to invest in it? A two-person startup isn't running compliance audits on every agent decision.
  • The post argues against vendor lock-in, but using LangChain deeply is also a form of lock-in. Is this advice genuinely neutral or is it replacing one dependency with another?

Action you could take today: Map your current AI feature stack against the four layers Penn describes: agent logic, governance, context, and feedback loop. Identify which ones you own and which ones you're renting. If you're renting the feedback loop — meaning you have no systematic way to capture what worked — that's the highest-leverage gap to close first.

Anthropic — Claude Opus 5 Now Available on API and Bedrock#

Source: https://www.anthropic.com/news (announcement) / https://aws.amazon.com/blogs/machine-learning/introducing-claude-opus-5-on-aws-anthropics-most-capable-opus-model/ Credibility: High (first-party announcement from Anthropic; AWS ML blog provides integration guidance for Bedrock; published 2026-07-24)

What happened: Anthropic launched Claude Opus 5, positioning it as a step-change improvement for the Opus tier with a specific focus on long-running agents, coding, and professional work. The model is available on the Anthropic API and on Amazon Bedrock. Vercel also added it to AI Gateway with BYOK support, no markup on provider pricing, and automatic failover. AWS published a companion post with practical guidance for engineers integrating Opus 5 into agentic systems and production inference workloads.

Key capabilities:

  • Optimized for long-running agentic tasks — this is the headline positioning, not general chat or reasoning
  • Coding improvements are called out explicitly alongside "professional work" (likely meaning longer, more structured outputs)
  • Available on Amazon Bedrock as of July 24, making it accessible to teams already in the AWS ecosystem without additional API contracts
  • Vercel AI Gateway integration includes automatic failover — meaning you can route to Opus 5 and fall back gracefully if it's unavailable

Why it matters for PMs: The "long-running agents" framing is the most significant positioning signal here. Anthropic isn't selling Opus 5 as the best model for chat — they're selling it as the right model for tasks that run for minutes or hours with minimal human intervention. That's a different product category than what Claude Sonnet targets. For PMs evaluating which model tier to use, this is a cleaner decision boundary: if your use case is short, interactive, and high-frequency, Opus 5 is probably overkill and overpriced. If you're building agents that run autonomously for extended periods, the cost math might look different.

Critical questions:

  • "Step change improvement" is a claim without a benchmark attached. What's the actual reliability improvement on multi-step agentic tasks compared to Opus 4?
  • Long-running agents fail in ways that are hard to test in advance. What does Anthropic's guidance look like for error recovery and graceful degradation?
  • Bedrock availability is a checkbox for enterprise procurement — but does the Bedrock version have any capability limitations compared to the direct API?
  • At what token budget does Opus 5 become the economically rational choice over Sonnet for agentic workloads?

Action you could take today: If you're building or evaluating agentic workflows, check whether your current model tier is the right one for your task duration and error tolerance profile. The Bedrock post has concrete integration guidance — worth a read if your team is already on AWS.

Quick Hits#

  • Dianne Penn / Lenny Rachitsky: Community Wisdom post touches on "the limits of what AI can automate" — worth reading for ground-level signals from practitioners on where AI still breaks down in real workflows (2026-07-25): https://www.lennysnewsletter.com/p/community-wisdom-staying-on-a-clients

  • Dan Shipper / Every.to: "Vibe Check: Anthropic's latest Opus" — Shipper's take is that getting great work out of Opus 5 may require dismantling the systems you already use, which is a real adoption cost that most launch posts skip entirely (2026-07-24): https://every.to/

  • Clement Delangue / Hugging Face: After the rogue OpenAI agent incident, Delangue publicly demanded two things from OpenAI: release all agent traces for public study, and provide $100M in compute for Hugging Face's cyber defenses. Whether or not the demands land, it signals that the open-source AI community is treating agentic safety as a political issue now, not just a technical one (2026-07-25)

  • Andrej Karpathy: Posted that "one pattern I find useful for working with LLMs is a nice long ramble session" — essentially using unstructured verbal thinking as a way to explore a problem space before prompting. Simple but worth stealing as a personal workflow practice (2026-07-21): https://x.com/karpathy

  • LangChain: Harrison Chase's "In the Loop" newsletter dropped July 25 — 9 min read, likely covering the "own your intelligence" themes from the blog post above plus agent system patterns. Worth checking if you're building on LangChain: https://blog.langchain.com/

The Thread#

The moat question is getting sharper. This week's signals keep circling the same thing from different angles: Penn's eval-driven loop, LangChain's "own your context" argument, and Karpathy's ramble-session workflow are all versions of the same bet — that the companies and individuals who build systematic feedback mechanisms will compound over time, and the ones who don't will plateau. The model capability race is real, but it's increasingly not the differentiator. The feedback loop is.

Sit With This#

Dianne Penn describes Anthropic's eval-driven development loop as the core of how Claude got built — not intuition, not vibes, but a systematic process where evaluations drive iteration. For most product teams shipping AI features, evals are either nonexistent or treated as a final QA step rather than a development driver.

For your product: What would it actually take to make evals a first-class input to your development process rather than an afterthought? And if you can't answer that question, what does that tell you about how you're currently deciding whether your AI features are getting better or worse?