"We're designing Cursor's BugBot — an AI agent that automatically reviews pull requests for logic bugs, security vulnerabilities, and performance issues before code reaches production. The core challenge: use LLMs to find real bugs humans would miss, not stylistic nitpicks. BugBot processes 2M+ PRs per month for Fortune 500 companies, achieves a 70% resolution rate (meaning developers fix 70% of flagged issues), and catches ~0.7 bugs per run. It evolved from a pipeline-based system with majority voting into a fully agentic architecture — one of the most instructive examples of taking an LLM product from prototype to production at scale."

"The system has four stages: (1) GitHub event ingestion and diff extraction, (2) context assembly — gathering the diff plus surrounding code, project rules, and repo structure, (3) the analysis engine — either V1 multi-pass pipeline or V2 agentic loop — which produces bug candidates, and (4) result delivery — posting inline comments on the PR with fix links. A separate metrics pipeline tracks resolution rates to hill-climb on quality."

"The pipeline architecture had a fundamental limitation: it was one-size-fits-all. Every PR got exactly 8 LLM passes regardless of complexity. A one-line typo fix consumed the same resources as a 500-line refactor of authentication logic. The agentic approach lets the system adapt. The agent reasons about the diff, identifies suspicious patterns, and decides how deep to investigate. For simple PRs, it might finish in 2-3 tool calls. For complex ones, it might trace call chains across 10 files. This produces better results at lower average cost. The second insight was about context. V1 loaded all context upfront — you had to guess what the model would need. V2 starts minimal and the agent pulls in context dynamically, only fetching files it actually needs to investigate a specific pattern. This is both more efficient and more targeted. The third shift was prompting: V1 used conservative prompts to minimize false positives. V2 uses aggressive prompts that flag everything suspicious, then relies on the iterative loop to verify or dismiss. This catches more real bugs while maintaining precision."

"The metric that unlocked BugBot's improvement was resolution rate: what fraction of flagged bugs do developers actually fix before merging? This is brilliant because it's a proxy for 'was this useful?' — if a developer took the time to fix the issue, it was probably a real bug. If they ignored it, it was probably noise. It's computed by an AI judge that compares flagged issues against the final merged diff, so it scales to millions of PRs without human annotation. For offline evaluation, they use BugBench — a curated set of real diffs with human-labeled bugs. This gives fast iteration without waiting for production data. The combination is key: BugBench prevents shipping regressions quickly, while resolution rate measures actual real-world value. I'd also track false positive rate (via developer dismissals), time-to-review (minutes from webhook to first comment), and adoption metrics (what % of teams make BugBot a required check)."

"LLMs have well-documented positional biases. Content at the beginning and end of the context window gets disproportionate attention, while content in the middle can be under-attended. In code review, this means the model might scrutinize the first few files closely and skim the last ones. By randomizing the order of diff hunks across 8 passes, each pass 'notices' different sections of the code. A bug buried in the middle of a large diff might be missed in 7 out of 8 passes, but the one pass where that code appears near the beginning catches it. Majority voting then aggregates: if 2+ passes flag the same issue, it's likely real regardless of which pass caught it. This is essentially an ensemble technique that exploits the stochastic nature of LLM attention to achieve broader coverage than any single pass."

"GitHub rate limits. Every PR requires multiple API calls: fetch the diff, read surrounding files for context, post inline comments, update check statuses. At 2M PRs/month, that's potentially hundreds of millions of API calls against GitHub's 5,000/hour per-installation limit. Cursor rebuilt their Git layer in Rust specifically for this — minimizing data fetches and making every API call count. They added a proxy layer that monitors rate limits across all installations, batches requests, and queues work when quotas are close to exhaustion. The second challenge is cost. V1's 8-pass architecture meant ~16M LLM inference calls per month. At frontier model pricing, that's an enormous bill. The agentic architecture helps by letting simple PRs use fewer calls, but you still need careful model selection — using the most powerful model for investigation, cheaper models for validation, and routing based on PR complexity."

"Autofix creates a fundamentally different threat model from review-only BugBot. When BugBot only posts comments, the worst case is bad advice that a human ignores. When Autofix spawns a Cloud Agent that clones repos, writes code, and pushes commits, you have: (1) prompt injection risk — malicious code in the PR could manipulate the agent into introducing vulnerabilities or exfiltrating secrets; (2) supply chain risk — the agent has write access to the repo and could modify dependencies; (3) infrastructure risk — the agent runs on Cursor's servers with access to customer code. Mitigations: sandbox the agent's environment (no network access except to the repo), diff-review before merge (auto-generated commits should be clearly labeled and require human approval), limit the scope of changes (the agent should only modify files related to the flagged bug), and rate-limit auto-generated commits per PR. Cursor acknowledges this explicitly: their docs warn about prompt injection and note their infra hasn't been audited by third parties yet."

"As AI coding tools — Cursor Agent, GitHub Copilot, Claude Code — get better at generating code, they produce more code faster than humans can review. This creates a gap: generation throughput is skyrocketing while verification throughput (human code review) remains roughly constant. The result is either a review bottleneck that slows everything down, or reviews get rushed and bugs slip through. BugBot closes this gap by applying AI to the verification side. It's the natural counterpart to AI code generation. Interestingly, BugBot is especially strong at reviewing AI-generated code because AI-generated code tends to have predictable failure modes: it's syntactically correct but may miss edge cases, use deprecated APIs, or introduce subtle logic errors that a pattern-matching review catches. This makes BugBot not just useful but increasingly necessary as the fraction of AI-generated code in production grows — reportedly 41% of code is now AI-generated."