How Intercom 2x'd Their Engineering Velocity in 9 Months with Claude Code

Source: Lenny's Newsletter (How I AI) · Author: Lenny Rachitsky (featuring Brian Scanlan, Senior Principal Engineer at Intercom) · Date: 2026-04-20 · Original link

This week's "How I AI" episode features Brian Scanlan, Senior Principal Engineer at Intercom, walking through how the company doubled engineering throughput — measured as merged PRs per R&D employee — in just nine months by going all-in on Claude Code. The story isn't "we bought an AI tool and got faster." It's about the cultural permission, the telemetry, the custom skills, and the mature foundation that made the 2x possible. Below is a teaching summary of the seven biggest takeaways and the four concrete workflows Brian walks through.

---

1. Treat your engineering org like a product — and instrument everything

Intercom's first big shift was epistemological: stop treating "AI adoption" as a vibes-based rollout, and start treating the engineering organization itself like a product you're shipping to. That means the same instrumentation discipline you'd apply to a customer-facing feature.

Concretely:

• Every skill invocation (a "skill" is a custom Claude Code command, like /create-pr) is logged to Honeycomb, the same observability tool they use for production traffic. They can ask "how often is the create-PR skill used? Is its failure rate climbing?" the same way they'd ask about an API endpoint.
• Anonymized Claude Code session transcripts are stored in S3 so they can mine them later — what was Claude struggling with last Tuesday? Which repos cause the most retries?
• Custom dashboards show individual engineers how they compare to peers on AI usage. Brian is explicit that this is not surveillance; it's the same feedback loop a sales rep gets on their pipeline. You can't improve what you don't measure, and you can't scale AI adoption across hundreds of engineers if leadership has no visibility into what's working and what's silently breaking.

The mental model: AI tooling is a product surface inside your company. Ship it, measure it, iterate on it.

2. The 2x velocity gain is real — but only because the foundation was already there

This is the line one commenter called the quiet thesis of the whole episode: AI magnifies your strengths and weaknesses.

Intercom genuinely doubled merged PRs per R&D employee in nine months. But Brian is careful to point out the preconditions: they already had mature CI/CD, comprehensive automated test coverage, and a high-trust culture where engineers were trusted to ship. Drop Claude Code into a team with flaky CI, manual deploys, and a chaotic code review process and you don't get 2x — you get the same chaos at 2x speed. You ship broken code faster.

The practical implication: if you're a leader looking at this case study and thinking "I want that," the prerequisite isn't a Claude Code license. It's fixing your fundamentals — green CI, fast deploys, trusted reviewers — first. Then you pour gasoline on the fire.

3. Custom skills + hooks enforce quality at the point of creation

A "skill" in Claude Code is a named, parameterized workflow — think of it like a slash command that bundles instructions, allowed tools, and guardrails. A "hook" is a script that runs at specific lifecycle points (before tool use, before commit, etc.) and can block the agent.

Intercom's flagship example is a Create PR skill. The naive way Claude Code would open a PR is to shell out to the GitHub CLI (gh pr create) with whatever commit message it generated. The result is usually a PR description that's a thin restatement of the diff: "This PR adds a function foo that returns bar." Useless to a human reviewer.

Intercom's skill blocks Claude from using the GitHub CLI directly — a hook intercepts and rejects it — and forces it down a different path that requires writing a context-rich PR description: what problem this solves, why this approach, what was considered and rejected, what to test. The agent has to gather that context (from the issue tracker, from the conversation, from the diff) before the PR can be opened.

The general principle: build guardrails that make the golden path the only path. Don't write a doc telling engineers "please write good PR descriptions." Make it impossible for the agent to open a low-quality one.

4. Code quality goes up, not down — because you finally have capacity for tech debt

A common fear is that 2x velocity = 2x sloppy code = quality cliff. Intercom partnered with Stanford researchers to actually measure this, and their code quality metrics are trending up.

Brian's explanation is counterintuitive but compelling. In a normal engineering org, tech debt — flaky tests, slow build pipelines, that one ancient module everyone avoids — never gets fixed because the business cost of pulling an engineer off feature work is too high. Tech debt becomes a thing you complain about in retros and never actually pay down.

When agents can knock out those projects in hours instead of quarters, the business constraint disappears. Fixing flaky tests goes from "a sprint of work nobody wants" to "I'll kick off an agent over lunch." The capacity for maintenance work expands enormously, and the codebase actually gets healthier as you ship faster — the opposite of the usual trade-off.

5. The most important leadership job in the AI era: give permission, take accountability

Brian's framework, stated almost verbatim: "Tell people they can do things, and if anything goes wrong, blame me."

His point: engineers in 2026 don't need more tutorials, more Claude Code documentation, or another internal Confluence page. The information is freely available. What they need is permission — explicit, top-down — to:

• Connect Claude Code to Snowflake and let it write production queries
• Ship code from their phone while on the subway
• Build a CLI that bypasses email verification for testing purposes
• Try things that, if they go wrong, will require a manager to take the heat

The activation energy for experimentation is cultural, not technical. Most orgs are stuck not because the tools don't work, but because no one has told the engineers "yes, you're allowed." A leader's highest-leverage move is signing that permission slip and absorbing the downside risk if an experiment goes sideways.

6. Make your product agent-friendly — or your customers' agents will brute-force it

This takeaway is less about internal velocity and more about product strategy, and it's striking. Brian built an Intercom CLI that lets an agent autonomously sign up for Fin (Intercom's AI agent product), verify the email address by reaching into Gmail, and complete the installation — all without a human in the loop.

Why does this matter? Because increasingly, the "user" arriving at your signup page isn't a human — it's an agent acting on behalf of a human. If your onboarding flow assumes a human (modals, email-link verification, drag-and-drop UI, "click here to continue"), the agent will:

1. Brute-force its way through the website
2. Burn a huge number of tokens fumbling with your UI
3. Get stuck on something dumb (an email confirmation it can't access)
4. Eventually have the human press escape and say "forget it, let's do this differently"

The cost of switching to a competitor is now literally one keystroke. Your conversion funnel becomes invisible — you can't even see where the agent dropped off. So the product imperative is: ship a clean, agent-targeted entry point (a CLI, an MCP server, a documented API path) for onboarding, or watch silent churn you can't measure.

7. All work will become agent-first — and you should set a deadline

Brian's closing vision: by the end of any given month going forward, the default first response to an alarm, a planning meeting, or a customer question should be an agent doing the basic work first. The human shows up to review, decide, and add judgment — not to do the initial gathering and drafting.

He's emphatic that this isn't aspirational science fiction. Given the current state of models and harnesses, it's a realistic expectation today. The bottleneck is organizational willingness to reimagine workflows from first principles rather than bolting agents onto the existing process. Setting a hard deadline ("by end of month X, every alarm goes to an agent first") forces that re-imagining to actually happen.

---

The four workflows walked through in the episode

The episode itself includes detailed walkthroughs of four concrete Claude Code workflows Intercom uses in production. Brief sketches:

1. Automate high-quality PR descriptions with a custom AI skill — the Create PR skill from takeaway #3, with the GitHub-CLI block and context-gathering enforcement.
2. Build a self-improving AI agent to automatically fix flaky tests — an agent that watches CI, identifies flaky tests, attempts fixes, and learns from which fixes stick.
3. Design an agent-friendly CLI to automate SaaS product onboarding — the Intercom CLI from takeaway #6 that lets external agents sign up and install Fin without human intervention.
4. A fourth workflow completing Brian's "4 AI workflows for Claude Code" set, covering broader org-wide patterns.

Full walkthroughs are linked from the original post (chatprd.ai). The episode itself is on YouTube, Spotify, and Apple Podcasts.

---

The thesis in one paragraph

A 2x velocity gain from Claude Code is real and reproducible — but it's downstream of three things, in order: a healthy engineering foundation (CI, tests, deploys, trust), heavy product-style instrumentation of how AI is actually being used, and a leadership culture that grants explicit permission to experiment and absorbs the blame when things break. The tooling is the easy part. The cultural permission slip is the unlock.

Note: this summary is built from the newsletter post and its public takeaways; full episode-level detail lives in the linked podcast and workflow pages.