Home
Apr 20, 2026
View All

How Intercom 2x'd Engineering Velocity with Claude Code

The Short Version#

The week's clearest signal is a real case study with real numbers: Intercom doubled engineering velocity in 9 months using Claude Code — not by replacing engineers, but by pairing deep telemetry with a culture that lets engineers move faster. Meanwhile, Karri Saarinen drops Linear's actual AI agent metrics (57% of bugs solved autonomously), and Simon Willison's "headless everything" framing is the most useful mental model this week for thinking about personal AI infrastructure.

Lenny's Newsletter / Brian Scanlan (Intercom) — How Intercom 2x'd Engineering Velocity in 9 Months with Claude Code#

Source: https://www.lennysnewsletter.com/p/how-intercom-2xd-their-engineering Credibility: High (first-party case study from Intercom's engineering leader, published via Lenny's Newsletter)

What happened: Brian Scanlan, Intercom's VP of Engineering, walks through exactly how Intercom doubled engineering output in under a year using Claude Code. This isn't a vibe — it's a specific playbook involving three levers: Claude Code skills (custom instruction sets that encode Intercom's patterns), deep telemetry on how engineers actually use AI, and a cultural shift that empowers engineers to ship without traditional approval gates. The 9-month timeline makes this one of the most concrete before/after engineering AI transformation stories published so far.

Key patterns:

  • Claude Code "skills" — Intercom built and shared custom Claude Code skill sets across the org, encoding their own coding conventions, architectural patterns, and review criteria. This is the organizational unlock: not just giving engineers a tool, but making the tool understand your product
  • Deep telemetry — They tracked AI usage patterns closely, not just outcomes. Knowing which engineers are getting value (and how) let them identify what to replicate and what to fix
  • Cultural empowerment — The throughput gain required loosening traditional control structures. Engineers needed real autonomy to use the speed AI provides. Without that, the tool's benefit caps out
  • 2x output — Doubled engineering velocity over 9 months is a specific, falsifiable claim from a named executive. That's worth taking seriously

Why it matters for PMs: If you're debating whether to invest in AI coding tools for your eng team, this is the template for how to think about it. The technology alone doesn't double velocity — the skills infrastructure and the culture change are equally necessary. For PMs specifically: if your team adopts Claude Code without building shared skills and giving engineers real autonomy, you'll get 10% improvement, not 2x. The lever is the organizational design around the tool, not the tool itself. This also surfaces an interesting question about PM involvement in engineering workflow — if engineers are shipping faster, the bottleneck may shift upstream to discovery and prioritization.

Critical questions:

  • What does "doubled velocity" actually measure — PRs merged, features shipped, cycle time? The claim needs a denominator
  • Did quality metrics hold? Faster shipping without regression data is only half the story
  • How much of the gain came from the skills/prompts vs. the cultural changes? The two levers aren't separable in this account
  • How did this change the PM/eng relationship? If engineers can prototype and ship faster, does discovery need to scale proportionally?

Action you could take today: If your engineering team uses any AI coding tool, ask your eng lead to pull one week of usage telemetry — which engineers are using it, for what tasks, and what the output quality looks like. That's the starting point Intercom built on.

Karri Saarinen (Linear) — Linear Agent Is Solving 57% of Bugs Autonomously#

Source: https://www.linkedin.com/in/karrisaarinen (LinkedIn post, April 18, 2026) Credibility: High (first-party metrics from Linear's CEO/co-founder)

What happened: Karri Saarinen posted Linear's internal AI agent metrics tracking Q4 2025 through Q1 2026. The headline numbers: resolved work up 80%, bug resolutions up 94%, and by April, the Linear agent is autonomously solving 57% of bugs filed. These are production metrics from a real product team using their own tool — not a benchmark or a demo.

Key metrics:

  • Resolved work: +80% (Q4 2025 → Q1 2026)
  • Bug resolutions: +94%
  • Autonomous bug resolution rate: 57% by April 2026
  • This is the Linear team using Linear's own agent on their own codebase — dogfooding at scale

Why it matters for PMs: 57% autonomous bug resolution is a threshold number. When agents can reliably close more than half of incoming bugs without human intervention, the team's capacity equation changes fundamentally. The 46% that still requires human attention is now the higher-value work — the bugs that are genuinely complex, ambiguous, or cross-system. For PMs, this is a preview of how engineering capacity will be reallocated: fewer engineers triaging and patching, more working on architectural problems and new capabilities. The 94% increase in bug resolutions also suggests the backlog clearance rate is real, not just a shifted queue. Worth watching whether this translates to faster feature velocity or gets absorbed into product quality improvements.

Critical questions:

  • What's the false-positive rate? If the agent "resolves" bugs by closing them incorrectly, the 57% figure is misleading
  • Is the 80% resolved work increase additive (more total work done) or substitutive (same work, fewer engineers)?
  • Does this change Linear's headcount plans? That would be the clearest signal the numbers are real
  • How does this generalize? Linear's codebase is a specific product with specific patterns — how well does this translate to other codebases?

Action you could take today: Pull your team's bug backlog from the last quarter and categorize bugs by type (reproduction clarity, scope, affected systems). If 50%+ are clearly scoped, single-system bugs with repro steps, your codebase may already be a candidate for agentic bug resolution — and you'd know where to start a pilot.

Simon Willison — "Headless Everything for Personal AI"#

Source: https://simonwillison.net/2026/Apr/19/headless-everything/#atom-everything Credibility: High (Simon Willison is a recognized expert and builder; this is first-person synthesis from direct tool usage)

What happened: Willison published a piece arguing for what he calls "headless everything" — designing personal AI setups so that every tool, data source, and workflow can be accessed programmatically, without a GUI. The core argument: if your data and tools are locked in interfaces, AI agents can't reach them. Building a "headless" personal infrastructure (APIs over UIs, structured data over PDFs, programmatic access everywhere) is the prerequisite for AI to actually help with personal knowledge work.

Key patterns:

  • The bottleneck for personal AI isn't the model — it's whether your data and tools are accessible to agents
  • "Headless" means: APIs over GUIs, text/structured formats over binary files, services that can be called programmatically vs. clicked through
  • This is a design principle for information architecture, not just a technical setup
  • Willison built Datasette for exactly this purpose — making personal data queryable by agents. The "SQL functions in Google Sheets to fetch data from Datasette" post published the same day is the applied version of this principle

Why it matters for PMs: This is the most useful reframe of "AI integration" I've seen for non-engineers. The question isn't "does this tool have an AI feature?" — it's "can an AI agent reach this tool's data?" If your team's critical data lives in dashboards, PDFs, or interfaces that require clicking, it's not accessible to agents regardless of which AI you're using. For PMs thinking about where AI can actually improve their workflows: start by auditing which of your sources of truth are programmatically accessible. The ones that aren't are your AI blockers, not your AI opportunities. This also connects directly to how AI agents interact with your product — if users can't give agents access to their data in your product, your AI features will plateau.

Critical questions:

  • "Headless" setups require technical sophistication most PMs don't have — what's the non-engineer path to this?
  • There's a privacy and security argument against making everything programmatically accessible. Where's the right line?
  • Does this principle apply at the team level, or is it fundamentally personal infrastructure?

Action you could take today: List the five data sources you reference most in a typical work week. For each, ask: can an AI agent access this without me manually copying content in? If fewer than two are accessible, you've found your personal AI infrastructure gap.

Quick Hits#

The Thread#

The velocity question is getting concrete answers. Three items this week — Intercom's 2x engineering output, Linear's 57% autonomous bug resolution, and Karri Saarinen's Q4→Q1 metrics — share a structure: real teams, real numbers, real timelines. We're moving past "AI will accelerate development" into "here's what acceleration actually looks like and what organizational conditions make it happen." The next question every PM should be sitting with: if engineering velocity doubles, what happens to the PM work upstream? Does discovery and prioritization need to scale at the same rate, or does faster shipping expose that that's the new bottleneck?

Sit With This#

Intercom doubled engineering velocity in 9 months using Claude Code — but Scanlan's account makes clear the technology alone wasn't the lever. Shared skill sets and cultural empowerment were equally necessary.

For your team: If your engineering org adopted Claude Code tomorrow, which organizational constraint would actually cap the velocity gain — the absence of shared prompt/skill infrastructure, the approval and review culture, or the PM team's capacity to feed a faster-shipping engine with clear, prioritized work?