Andrew Norrish: Code Context for AI-Era Incident Response

I'm Andrew Norrish, director of field engineering at Sourcegraph. We work with engineers managing large, complex codebases. Code search, navigation and code graphs that once primarily served humans are increasingly used as a context engine for agents. I want to focus on what faster AI-driven development means for the teams supporting production services.

We hear a recurring story from customers: teams adopt coding agents, produce more code and pull requests, and face pressure to turn that output into releases. In my account, the constraint moves from writing code to the ability of people to review it. I also noticed that a recent customer advisory meeting did not focus on headcount savings in the way earlier AI discussions often did.

I argue that growing volumes of AI-written changes can make incidents harder to prevent and resolve, especially when code is merged with insufficient review or organizational context. Responders may face unfamiliar changes without runbooks. These are patterns I say we hear from customers, rather than a demonstrated rate that applies to every organization.

Review is the first pattern: as agents produce more code, developers may need to spend more time verifying it against requirements and regulations. Agents still hallucinate and can lack context in large organizations with legacy systems. If the full codebase cannot be examined locally, an agent may make decisions from a partial view.

Cross-service incidents can be difficult for engineers and agents to trace, leading teams back to slow manual commit searches. Once a fix is known, applying it across hundreds or thousands of repositories can be another bottleneck when separate teams must each make the change. In financial services, compliance increases the stakes.

I cite industry estimates suggesting more and larger pull requests, more review time, and a gap between developers' trust in AI-generated code and how consistently they verify it. Those figures are estimates shown in the talk; they should not be read as universal measurements or proof that every incident is caused by AI.

I see more promising applications where AI works within bounded domains and has the context needed for organizational and compliance requirements. Examples include vulnerability remediation, security scanning, migrations and prototypes. Site reliability and platform teams already operate semi-autonomous processes, so they can both assess AI's operational impact and apply AI to existing workflows.

Sourcegraph's commercial offering centers on code graphs, search and navigation across an organization's repositories. I describe that combination as a context engine that humans and agents can use to understand code. My team proposes using those capabilities to support incident investigation as well as development.

I group the SRE work into investigation, prevention and remediation. For investigation, deterministic search can query repositories, branches and commits, while agentic search can provide answers with citations. These are product capabilities I describe, not independent evidence that every root cause will be found within a particular time.

For prevention, I describe monitors that flag risky or potentially noncompliant code patterns. For remediation, code search can locate affected areas and bulk changes can propagate a fix across repositories. The goal is to reduce the delay between recognizing a widespread issue and addressing it across teams.

One internal example is security triage. Sourcegraph receives HackerOne reports and uses webhooks to invoke agentic search. The workflow helps classify whether a report merits deeper human security review, a proposed change, or no further action. I present this as our team's implementation, not a guarantee that automated triage cannot miss a report.

At a customer with more than 5,000 developers, an internal root-cause agent responds to downtime or error spikes by connecting logs and traces to code. It first identifies the deployed branch or tag, then searches history for a likely triggering commit. The customer can have the agent initiate a revert and redeployment or share the investigation with SREs.

A second customer maintains a code-review agent for a large monorepo and evaluates it against hundreds of historical branches. I say it uses a read-only code-finder agent to search those branches at scale; passing evaluations triggers the customer's publishing process. The common theme is giving bounded automation access to relevant code context.