Instacart's AI engineering claims: what the numbers don't establish
At VB Transform 2026, Instacart CTO Anirban Kundu presented a picture of an engineering organization where machines handle most code generation and engineers rarely look at what those machines produce. The specific numbers are attention-grabbing: 97% of cases where builders do not read code, 7,000 automatic evaluations per month, and an agentic SRE system that improved accuracy from roughly 60% to over 90%. The source presents these as evidence that AI has transformed how the company operates. The more relevant question is what those numbers actually measure, whether they generalize, and what they leave out.
The framing of 97% unread code deserves scrutiny before it becomes an industry talking point. The source does not describe what "reading code" means in practice at Instacart. Code review, pair programming, architecture discussion, debugging sessions, and PR approvals are all forms of code engagement that do not fit neatly into reading raw lines. Conflating not-reading-code with not-engaging-with-work-product is a category error that the source does not acknowledge. An engineer who reviews an AI-generated design, validates a prompt output, or approves an automated refactor is still doing engineering work. The 97% figure may describe a narrow reading behavior while the actual review and validation burden shifts to other activities that the source does not count.
The claim that technical debt no longer matters because inactive code gets dropped and rebuilt weekly is a structural statement, not a validation. Regenerating code on a weekly basis is one way to handle accumulation. It works if the regeneration pipeline is reliable, the test coverage is sufficient, and the weekly cadence actually catches drift. The source does not describe the regression, rollback, or quality gates that make weekly rebuilds safe at scale. Legacy systems handling compliance, latency-sensitive paths, and half-active codebases still receive careful human attention, which the source acknowledges as the remaining 3%. That 3% is where operational risk concentrates. Calling it a boatload of dead code does not reduce the complexity of modernizing it.
The SRE agent called Blueberry monitors roughly 200 Slack channels and watches for patterns across human conversations and alerts. In one incident the source describes, Blueberry identified a database shard issue tied to a feature-flag system called "roulette" that human engineers did not catch for about 20 minutes. Kundu frames this as evidence that human intuition holds engineers back. The source presents this as a win for the agentic approach, but a single incident does not establish the pattern. The source does not report false-positive rate, alert volume, or how often Blueberry surfaces patterns human engineers would have found independently or faster. Catching one incident in one Slack thread is not a performance benchmark.
The accuracy jump from roughly 60% to over 90% in SRE detection and mitigation sounds dramatic, but the source does not define what "accuracy" means in this context. Detection accuracy and mitigation accuracy are different properties. False positives can be high while accuracy still appears strong if the metric weights true positives without penalizing noise. The internal evaluation design the source describes is plausible: training on years of Instacart's own incidents and root-cause analyses rather than generic failure data. That is a defensible choice for a system that needs to understand company-specific failure modes. It is not independently validated, and it means the accuracy figures apply to Instacart's infrastructure, not to a transferable product or methodology.
Project Atoms, the initiative to break down monoliths and rebuild with RPC-driven architecture, is the part of the source that reads most clearly as an ongoing engineering program with known constraints. Kundu describes starting with the monoliths and working toward modularity. The source does not specify how much of the monolith has been refactored, what the RPC migration costs, or how the AI code generation pipeline interacts with the architectural transition. These are distinct engineering problems. Treating them as one transformation story flattens work that probably involves significant human coordination, testing, and rollback planning.
The intent model for evaluation is the source's answer to what replaces code review when AI generates code. The idea is that developers learn to ask models the right questions rather than read generated lines. The source does not specify how this intent training works, what error modes it produces, or how it performs against code review on edge cases, security-sensitive paths, or complex architectural decisions. Calling lines of code correct and syntax meeting expectations is the floor, not the ceiling, of engineering quality. The 8,000-plus real-time developer queries with roughly 99.9% accuracy are presented without describing what those queries cover or whether the accuracy rate holds across different query types.
The source frames Instacart's approach as a model for engineering organizations navigating AI adoption. The specifics are concrete enough to be useful as a reference point for teams building internal agentic systems. They do not establish that the reported outcomes generalize, that the metrics are measured consistently, or that the weekly regeneration cadence is reproducible outside Instacart's stack. The 97% unread code figure, the 90% SRE accuracy, and the weekly tech debt overwrite are claims that belong in an engineering retrospective, not an industry benchmark. Whether those numbers hold under independent evaluation, production variance, and organizational scale is the question the source does not answer.