Inside Snap's software factory

People

Saral JainSVP, Head of Engineering, Snap Inc.

What they set out to solve

CodePal's post states the problem as a straightforward consequence of the rest of the pipeline speeding up: AI tools accelerated how fast code gets written, and code review did not keep pace, larger pull requests and overwhelmed reviewers created merge delays and a risk of accumulating technical debt ². The post states this directly:

Faster code creation without faster code review is a recipe for technical debt.

Snap Engineering

Casper's stated problem is attention scarcity rather than raw task difficulty. Even a well-scoped task consumes an engineer's cognitive bandwidth through context switching and environment setup, and Snap's own codebase adds a further cost: understanding service boundaries, team conventions, and deployment pipelines before a change can be made safely. The post also states that Snap evaluated existing vendor agents and found them lacking the integrations the task required, "interoperability within all of our internal services" and "tight integration with our CodePal and CodeSearch agents" ¹.

Code Search's stated problem is navigational: remote agents could not identify which of Snap's thousands of repositories to edit without cloning each one, engineers and agents alike lacked visibility into prior art, and cross-repo blast radius was invisible to reviewers. A legacy single-VM regex tool could not scale to agent-driven query volume or support per-user access control ³.

On the record from Snap's Head of Engineering, the stated philosophy for adopting agents at all is about ownership rather than authorship:

Ultimately, it is immaterial who writes the code. What is material is who owns the code.

Saral Jain, SVP, Head of Engineering

Maturity level

How Snap's software factory works

Three systems interlock. Code Search is the retrieval layer: an exact-match index built on Zoekt, a trigram-based, language-agnostic engine, sharded so that every repository lives entirely on one high-memory shard with sub-second p95 latency, alongside an "AI Search" mode that answers natural-language questions through an agentic loop running 5 to 10 sequential exact searches rather than a RAG pipeline. Identity propagation scopes every query to the requesting user's own repository permissions, and the whole system is exposed to any agent as an MCP server with "one config line." The post reports that almost all Code Search traffic now originates from agents rather than humans, and that the trend is rising ³.

Casper is the execution layer. A task arrives in plain language, over Slack DM or @mention, a web portal, or an event/scheduled trigger, and Casper spins up an isolated sandbox under a per-user derived identity, gathers context from Slack threads, tickets, documents, and Code Search, plans and implements the smallest safe change with human approval checkpoints, runs tests, builds, and linters, iterates on failures, and produces a pull request in the team's own conventions before handing it to CodePal for automated review. Architecturally, a trusted controller holds source-control credentials rather than the agent process itself, and workspaces persist independently of compute so a session can be reattached mid-task. The post states that Casper produces "thousands of mergeable PRs each week" across the engineering organization, and that some teams built specialized on-call agents "in hours versus weeks" using other approaches ¹.

CodePal is the review layer. It reviews pull requests directly against the GitHub Enterprise API, without cloning repositories, using a two-pass approach: tree-sitter parsing to build a symbol index, then diff analysis to select relevant files within a token budget ². Two bootstrap review passes run concurrently with different sampling parameters; if they disagree, a speculative third pass launches; further passes trigger only when new issues emerge. A "Verifier" stage filters hallucinated or self-contradictory findings before anything is posted. The system detects logic errors, null-pointer risks, race conditions, resource leaks, error handling gaps, type mismatches, and other issues across 12 distinct bug categories, and it draws on Code Search to find cross-repository call sites so a reviewer can catch a breaking change before merge ³.

Operating the software factory: teams, roles, and skills

Casper opens pull requests without a human initiating each one in real time, the post's own framing is explicit that "tasks keep moving while engineers are at lunch, asleep, or working on another task" ¹. CodePal then reviews the resulting code automatically, ahead of any human reviewer, completing within about 10 minutes against a roughly 5-hour median wait for a human review slot ². Saral Jain states the same throughput in his own words: Casper generates thousands of PRs every month, and CodePal reviews 90% of that code within 5 to 10 minutes, surfacing "tens of thousands of bugs" in the process ⁴.

Jain draws an explicit line at risk tier rather than at autonomy itself. Internal-only systems with no sensitive data can run "100% AI-generated with very little human review, maybe even auto-approved in some cases," while anything privacy-sensitive or user-facing at Snap's scale still requires a human to read the code, understand the spec, and vouch for the outcome before merge ⁴. No source discloses what share of Casper's total PR volume falls into the lighter- review tier versus the fully human-reviewed one.

Casper's identity model ties each session to a per-user derived identity, so an agent's permissions match the access of the person who triggered it, and a trusted controller rather than the agent process itself holds long-lived source-control credentials ¹. At the organizational level, Jain describes a much larger inventory of agents (in the thousands) beside a deliberately small "golden path" of 14 managed, blessed agents that his team maintains centrally, covering what he estimates as roughly 90% of an engineer's day-to-day workflow: writing code, reviewing it, investigating bugs and outages, and reading A/B results ⁴. The stated reason for concentrating investment in a small managed set, rather than letting every team build its own, is to avoid duplicated effort on hard problems like code review or crash debugging, while still leaving room for individual engineers to prototype their own smaller-blast-radius agents.

Every managed agent carries what Jain calls a persona: a defined risk tier controlling what data and systems it can reach, gated through a single MCP platform that acts as the control point for which agents can touch the most sensitive information. An agent registry, audit trails, and network sandboxing back this up, and Jain states that agents are not treated as employees, despite having agent-equivalent identities and permission scopes ⁴. He is explicit about where the investment goes:

More than 50% of our investment actually goes into the guardrails, not in terms of actually building stuff.

Saral Jain, SVP, Head of Engineering and CIO

CodePal itself is framed inside that logic as a guardrail rather than a coding tool, since it was the first Snap agent to see wide adoption specifically because it reviews rather than writes. Token spend is tracked through a per-engineer consumption dashboard, and Jain states Snap deliberately avoided building a leaderboard-style "token-maxing" dashboard, since raw token or PR counts are activity metrics with no stated correlation to output. Model selection increasingly routes between frontier and open-weight models rather than defaulting to the most capable model for every task ⁴.

Beyond engineering, Jain points to customer support as the largest adjacent use of agents, deflecting more than 3.5 million user questions a month, alongside earlier-stage use in trust and safety, sales, and finance and people operations ⁴. He frames the underlying philosophy as ownership over authorship:

The risk is not AI-generated code or human-generated code. The risk is unowned code.

Saral Jain, SVP, Head of Engineering and CIO

Implementation journey

1. Unstated date
   Code Search replaces a legacy single-VM regex tool, motivated by agents needing to identify which of thousands of repositories to touch without cloning each one ³.
2. Unstated date
   CodePal launches; PR coverage moves from 0% to 90% within a single quarter, reaching 200,000+ reviews in its first four months ².
3. Unstated date
   Casper reaches general availability; "hundreds" of custom Casper agents are built afterward, and some on-call agents that once took weeks are built in hours ¹.
4. June 24, 2026
   Saral Jain, SVP and Head of Engineering, describes the combined system on the Modern CTO podcast, citing roughly 14 "managed, blessed" agents spanning the workflow from code writing through A/B testing ⁵.
5. August 21, 2026
   Jain appears on CXOTalk and gives the entry's most complete figures: more than 90% of code now written by agents, per-engineer commits up 75% year-over-year, severe outages down 57% over the same period, and Code Search traffic running 60x higher from agents than from humans ⁴.

None of the three primary eng.snap.com posts carries a publication date, so this sequence is inferred from what each system depends on rather than from dated evidence: Casper's post states it invokes CodePal for review and gathers context via Code Search, implying both existed first, but no source states this as a stated order or gives relative dates ¹.

Measuring the software factory

CodePal is the only one of the three systems with a published measurement basis. Over its first four months it performed more than 200,000 reviews, reaching 90% of all pull requests after starting from 0% at the beginning of the same quarter, at an estimated cost of about $0.40 per review. Its own account of improving is candid about the mechanism: recall rose from 30% to 80%, and the post attributes the gain to context rather than model choice, "the bigger issue was with the context supplied to the model." Engineer sentiment toward its findings is reported at 80% positive ². The post's own framing of what this changes, rather than replaces, is stated plainly:

AI review doesn't yet replace human review, it reshapes it.

Snap Engineering

Casper and Code Search are otherwise measured mostly in throughput terms: "thousands of mergeable PRs each week" for Casper per the eng.snap.com post, corroborated as "thousands of PRs every month" by Jain, and "almost all" traffic from agents for Code Search, which Jain separately quantifies as roughly 60 times the traffic volume of human queries ^1,3,4. Jain states Snap deliberately measures output rather than activity, explicitly rejecting PR count and token count as gameable input metrics, and instead grounding on whether software ships faster, safer, and cheaper: the per-engineer commit rate up 75% year-over-year against a 57% fall in severe outages is the concrete result he offers for that framing. He also states Snap never went through an industry-wide "token-maxing" phase, having avoided building dashboards that would have rewarded raw token consumption ⁴.

Lessons learned

CodePal's own post states two things it learned by trial. First, that model quality was not the binding constraint on review accuracy, better context supplied to the model mattered more than a larger or newer model, which the post frames as "context over top-tier model." Second, that review disagreement, not a single-pass judgment, was the useful signal. Its review loop escalates to a speculative third pass only when the first two bootstrap passes give conflicting answers, and a dedicated "Verifier" step filters hallucinated or self-contradictory findings before anything reaches a human ².

Casper's post frames the choice to build in-house, rather than adopt an existing vendor agent, as a lesson about integration depth: existing solutions were evaluated and found to lack the necessary internal service integrations, security controls, and Snap-specific workflow optimization the task required ¹.

Jain states two things Snap's own experience taught it, offered as advice to other engineering leaders: first, that "context beats model 100 out of 100 times," since most frontier models are now competent at spotting bugs and the harder problem is feeding them Snap's own institutional knowledge, not chasing the newest model ⁴. Second, that guardrail investment is not a tax on velocity but the precondition for it, stated as his own summary of the tradeoff:

That investment actually does not slow us down. It actually helps us move faster.

Saral Jain, SVP, Head of Engineering and CIO

He frames CodePal's own gain in similar terms: recall improved from 30% to 80% between iterations, and the post attributes this to context supplied to the model, not a larger or newer model, which the post states directly as "context over top-tier model" ². Jain separately points to two risks that guardrails specifically exist to catch: that agents "can be wrong in very subtle ways" and confidently so, and that industry-wide security vulnerabilities have risen as more code is generated, a trend he states Snap is not immune to.

What's next for Snap's software factory

No source retrieved states a forward-looking roadmap, planned feature, or stated future direction for Casper, CodePal, or Code Search as individual systems. Jain gives a direction rather than a roadmap: more long-running, complex agents, and more auto-approvals in lower-risk areas, stated with a caveat that Snap considers itself in "very early days" of agentic software development. He is candid that the underlying tooling is not settled science, describing Snap's own experimentation with open-weight models and dynamic model routing as still "exploratory" ⁴. The other forward-looking material in the corpus is his framing of a shift in required engineering skill, toward taste, judgment, and ownership, which he presents as a durable change already underway rather than a plan ^4,5.