Coinbase Forge

Executive Summary

Forge is Coinbase's internal coding agent. Linear's current customer account describes requests arriving through Slack, GitHub, or Linear and proposed changes returning to Slack for review. Its importance is the connected workflow: requirements, code, and the place colleagues already discuss work become accessible to the same agent.^[1]

Public evidence supports that workflow more clearly than a precise company-wide productivity gain. The recorded March demonstration stopped after an agent began working, and Coinbase's separate Mux report explicitly acknowledges selection bias in its PR statistics.^[2][3] Neither establishes a universal success rate for Forge.

This profile belongs to the in-house coding agents category. Forge is a case study for teams evaluating internal automation, rather than a product they can currently subscribe to.

Names, Scope, and Availability

The current Linear case study calls the system Forge. The March How I AI episode uses Claude bot and says it can use multiple underlying models. LangChain's March Open SWE announcement calls Coinbase's agent Cloudbot.^[1][2][4] These names help readers connect the public accounts, but the sources do not establish a precise release-by-release rename chronology.

The reviewed sources describe an internal service, with no public Forge source license, subscription, or deployment guide. The fact that Coinbase has more than a thousand engineers does not establish that every engineer actively uses Forge. Likewise, details about other Coinbase agent programs should not be assigned to Forge without an explicit connection.

How the Workflow Fits Together

From bug report to review

The documented path is straightforward: a message becomes a categorized Linear issue, Forge attempts the fix, and the resulting PR returns to the conversation for human review. Code questions also go to Forge, while project-status questions go to Linear.^[1]

The useful design principle is continuity of evidence. An issue should retain the observed behavior, expected behavior, affected version, and reproduction details. An agent should not have to infer all of that from a short instruction such as “fix the trade form.” Returning the result to the original conversation lets the reporter check whether the proposed change addresses the actual problem.

A worked feedback-capture example

In the March episode, Chintan Turakhia demonstrated recording a sample report about numbers failing to appear in a trade form, reviewing a generated summary, creating a Linear ticket, and invoking an internal Slack bot with the repository and ticket. The episode writeup explicitly says it did not show a completed PR.^[2]

The companion workflow recommends preserving the recording or transcript, separating observed behavior from diagnosis, checking for a duplicate issue, and retrieving only authorized repository and observability context. Its intended output is a draft PR and preview returned to the same thread.^[5] Treat that companion as a workflow recipe, not proof that every step completed in the demonstration.

An illustrative task for evaluating the pattern might be:

Investigate issue TRADE-123 in the mobile repository.
Confirm the report against the supplied reproduction steps.
Identify the cause before changing code.
Add a regression check and prepare a draft PR.
Return the test result and any remaining uncertainty to this thread.

This is an example evaluation request, not an official Forge command. It creates several inspectable outcomes: whether the agent retrieved the right issue, reproduced the behavior, chose a relevant check, and left a reviewable artifact. If it cannot reproduce the problem, a clear explanation may be more useful than an unsupported patch.

What is known about the infrastructure

Coinbase's August 2025 engineering account describes shared model access through an internal router, internal MCP integrations, repository sensitivity rules, and a productivity framework combining delivery metrics with surveys. It also reports uneven benefits across work types and warns that increased AI use can increase bugs.^[6] These are organization-wide foundations, not a published diagram of Forge's runtime.

The reviewed Forge accounts do not specify its current sandbox provider, model-routing policy, retention rules, or complete authorization design. Those gaps matter when comparing it with another system. A Slack interface tells you where work begins; it does not tell you which credentials a run receives or whether one task can affect another.

Adoption Practices and Continuous Work

Experiments that make behavior visible

Linear describes a January 2026 experiment in which Turakhia asked his engineering organization to stop using IDEs for two weeks. It also describes recurring live “Speedruns,” where people practice a demonstrated workflow together and keep shared notes.^[1] The account does not establish that every Coinbase engineering group followed the experiment.

The March interview reports a session in which roughly 100 participants opened about 70 PRs in 15 minutes. Those are opened PRs, not a measure of reviewed, merged, or useful changes.^[2] Such sessions can expose setup friction and help colleagues learn a workflow, but production value requires following the changes through review and operation.

Adoption analysis without mistaking usage for performance

The same episode demonstrated analyzing sample Cursor usage data. Its writeup explicitly says the rows and resulting user statistics were invented for the demonstration rather than drawn from Coinbase employee records.^[2]

The companion proposes a reproducible analysis of activity patterns, followed by cohort-specific experiments. It distinguishes agent use, completion use, acceptance, and feature breadth, and warns against treating generated-line counts as employee performance.^[7]

That distinction is useful for an internal rollout. A team could discover that some people cannot access the right repository, while others have access but do not know a suitable first task. Those are different problems. A single adoption score conceals them, and more token consumption alone does not demonstrate better software.

Overnight work still creates a review queue

Linear describes engineers reviewing overnight drafts, starting another group of agents, and spending the day on difficult work. It identifies uninterrupted agent-running time as a metric Turakhia follows.^[1]

Longer autonomous runs can reduce interruptions, but they can also delay discovery of an incorrect assumption. A practical rollout should measure completed, accepted work alongside run duration, review time, rework, and abandoned attempts. Parallel generation is only useful if the team can understand and integrate the output.

Mux: A Separate Concurrency Case Study

Coinbase's May 11 post describes Mux as one tool among several used internally. Each agent gets its own worktree, branch, and terminal; engineers can run different tasks concurrently and review each result. The account also describes integrations with internal cloud agents and deployment workflows, without naming Forge as the mandatory underlying runtime.^[3]

These figures come from Coinbase's own engineering post. Its authors explicitly say Mux users likely skew toward people who were already high-output and enthusiastic about AI.^[3] This is evidence of adoption, not a controlled estimate that installing Mux makes any engineer 3.5 times more productive.

Worktrees keep working files and branches apart. They are not, by themselves, a security sandbox. Even with separate branches, independently reasonable changes can conflict semantically when merged: an API change and its caller update still need coordination and joint tests.

What the Productivity Evidence Establishes

The March podcast summary reports PR review time falling from about 150 hours to 15 hours in Turakhia's team.^[8] It does not isolate Forge's contribution from changes in review habits, tooling, task mix, or staffing. It should not be presented as a controlled tenfold improvement caused by one agent.

The useful evaluation questions are broader than PR volume:

• Did the change satisfy the original request and pass a meaningful check?
• How much human investigation, review, and rework remained?
• Did defects, incidents, or abandoned attempts increase?
• Did the system save time on the work the team actually needs done?

The public sources offer practitioner accounts from Coinbase and customer stories from its vendors. This report did not access private metrics or use Forge. It cannot establish a current company-wide Forge PR share or an independently measured reliability rate.

Open SWE and the Build-Versus-Buy Decision

LangChain released Open SWE in March 2026 as an independent framework inspired by patterns it observed at Coinbase, Ramp, and Stripe. That is an architectural connection, not a release of Coinbase's code.^[4] Features in Open SWE should not be treated as proof of Forge features.

The current Open SWE repository describes a Deep Agents harness, LangGraph runtime, multiple sandbox backends, review and scheduling components, and Slack/Linear/GitHub entry points. Its code is MIT-licensed, while documented production self-hosting uses the LangGraph Agent Server and requires its license key.^[9] A free source license does not make the whole operating system free to run or maintain.

Tembo as a commercial alternative

Disclosure: Ry Walker is Tembo's co-founder and CEO.

Tembo addresses a similar workflow through a commercial platform: background coding agents, selectable coding harnesses, prepared project environments, scheduled runs, and event or webhook triggers.^[10] Its Agent Actions documentation covers workplace-tool context, cross-repository sessions, and PR or merge-request output.^[11]

The decision is which responsibilities the team wants to own. A Forge-like internal platform can encode company-specific development and security practices deeply. Tembo provides common execution and orchestration capabilities that a team can evaluate against those requirements. The sources do not establish a Forge–Tembo integration or equivalent behavior on Coinbase's workloads.

A useful pilot would route the same well-scoped issue through each available option with the same tests and permitted credentials. Include environment preparation, failed-run recovery, reviewer effort, and recurring model and compute cost. Comparing a mature internal deployment with a vendor's first-run demo would obscure those differences.

Strengths, Cautions, and Fit

Forge is valuable to study for its connected task flow and deliberate treatment of organizational context. The supporting adoption material also shows how demonstrations, shared artifacts, and explicit experiments can make new workflows understandable.

The limitations are equally concrete: outsiders cannot inspect the implementation, published metrics use different populations and periods, and a successful handoff is not the same as an accepted fix. Shared company infrastructure is part of the investment; a small initial prototype team does not describe the entire cost of an internal platform.

For a team considering the pattern, start with an observable problem and a reproducible development environment. Preserve the evidence from request through review, and measure the work that reaches users. That provides a firmer basis for expanding automation than copying a headline PR count.

---

Research by Ry Walker Research • methodology