Add Code Review page + BridgeBench source; fix SWE-bench parser

[opencolin]

What

• New /code-review page — ranks 7 AI code reviewers (Tenki, Devin, Cursor, CodeRabbit, Greptile, Copilot, Graphite) on 122 real production bugs. Default sort is F1, not recall — with a prominent caveat box: the benchmark is Tenki's own, and its Add Code Review page + BridgeBench source; fix SWE-bench parser #1 spot holds only on recall (29.9% precision); by F1 it's a near three-way tie. Sortable columns let readers flip the story themselves.
• New BridgeBench source — bridgebench.ai is Cloudflare-walled, but BridgeMind publishes season snapshots in the public repo, so we read snapshots/season-1/ui-bench-snapshot.json via GitHub raw. Auto-updates as they run more models.
• SWE-bench parser fix — openlm.ai removed the per-row "Agent" column; the old parser silently returned 0 rows. Now parsed as the 6-column model-level table (59 models back), benchmark reclassified agent → model.
• Snapshot regenerated: benchmark count 10.

Why one PR

The SWE-bench breakage was found while integrating BridgeBench (both touch build.ts BENCHMARKS/SOURCES/rubric), and the snapshot regen bakes in all three together.

Verification

• tsc clean, next build clean, deployed to production and spot-checked live (/code-review renders, sort works, benchmark count shows 10, SWE-bench shows 59 models).

🤖 Generated with Claude Code

[tenki-reviewer]

Review Complete

Files Reviewed: 8
Findings: 1

By Severity:

• 🟡 Medium: 1

---

This PR adds code-review benchmark data ingestion (BridgeBench, SWE-bench) and a leaderboard code-review page. One medium-severity issue found: BridgeBench URL hardcodes a season identifier that will silently go stale.

Files Reviewed (8 files)

web/src/app/code-review/page.tsx
web/src/components/CodeReviewTable.tsx
web/src/components/SiteHeader.tsx
web/src/data/leaderboard.snapshot.json
web/src/lib/codeReview.ts
web/src/lib/scrape/build.ts
web/src/lib/scrape/sources/bridgeBench.ts
web/src/lib/scrape/sources/swebench.ts

[tenki-reviewer]

Risk: 🟡 Medium (35/100) — 1 medium finding · 5988 LOC across 8 files

---

Overview

This PR introduces a code-review benchmark leaderboard to the ensemble project, adding scraping infrastructure for BridgeBench and SWE-bench datasets, a new /code-review page, and a CodeReviewTable component.

Files Changed (8)

• web/src/lib/scrape/sources/bridgeBench.ts — New: BridgeBench JSON scraper
• web/src/lib/scrape/sources/swebench.ts — Modified: SWE-bench HTML table scraper (agent column removed)
• web/src/lib/scrape/build.ts — Data aggregation pipeline with percentile blending
• web/src/lib/codeReview.ts — Code-review leaderboard data massaging
• web/src/app/code-review/page.tsx — New code-review leaderboard page
• web/src/components/CodeReviewTable.tsx — New table component
• web/src/components/SiteHeader.tsx — Navigation link added
• web/src/data/leaderboard.snapshot.json — Updated snapshot data

Key Finding

Medium — Hardcoded season URL (findings-001): In web/src/lib/scrape/sources/bridgeBench.ts:11, the BRIDGE_BENCH_URL hardcodes /snapshots/season-1/ in its path. The source documentation states the task set is rebuilt every 90 days. When a new season is published, this URL will return stale data or 404 without any detection mechanism. Recommendation: Either dynamically discover the current season via the GitHub API or add response validation with health-check warnings.

Risk Assessment

Overall low risk. The code-review pipeline is new infrastructure that doesn't affect existing leaderboard behavior. The scraping sources have inherent upstream dependency risks (schema drift, season rotation) that are partially mitigated by the existing ok:false failure handling in build.ts. The hardcoded season URL is the most actionable finding and should be addressed before going to production.

[tenki-reviewer]

🟡 Hardcoded snapshot season in BridgeBench URL will silently go stale on next season (bug)

The BRIDGE_BENCH_URL at web/src/lib/scrape/sources/bridgeBench.ts:11 hardcodes /snapshots/season-1/ in the GitHub raw URL. The source comment on line 9 states the task set is rebuilt every 90 days. When a new season is published, this URL will either return stale season-1 data indefinitely or 404, with no mechanism to detect or adapt. The ingestion pipeline in build.ts will treat a 404 as a fetch failure (source marked ok:false) or silently continue ingesting outdated data if the old URL still resolves.

💡 Suggestion: Either (a) fetch a season index or the latest tag from the GitHub repo to discover the current season dynamically, or (b) add a health-check assertion on a season/version field in the response and surface a warning when it drifts. If using a fixed season is intentional, document the refresh cadence and monitoring expectation.

📋 Prompt for AI Agents

In web/src/lib/scrape/sources/bridgeBench.ts around line 10-11, the BRIDGE_BENCH_URL hardcodes season-1 in the path. Modify the fetch logic to either dynamically discover the current season (e.g., fetch a manifest or list tags from the GitHub API/repo) or validate a season field in the JSON response against an expected value, logging a warning on mismatch. Add a comment explaining the season-rotation strategy and how it stays current.

[prelint]

Agent site expands into infrastructure rankings, code review, and deep research with ghost rows on the main board

Product decisions in this change

1. Code review is introduced as a distinct product category, separate from coding agents — with its own page, its own benchmark data, and its own entry in the main navigation.

This is the right taxonomy split. A tool that reads a PR and flags bugs is genuinely a different job than a tool that writes code — different inputs, different success criteria, different user decision (buy vs. run). Modeling them as siblings rather than nesting code review under coding agents keeps the concepts clean and matches how practitioners think about their tooling.

2. F1 is chosen as the default sort over recall on the code review page, even though it demotes the benchmark's author from #1 (by recall) to a near-three-way tie.

F1 is the honest metric for a tool a user actually deploys — precision noise costs reviewer trust, so raw recall overstates usefulness. Defaulting to the metric that tells the more complete story, then making recall one click away, is the right editorial call. The caveat box that explains the Tenki authorship makes the ranking defensible to skeptical readers.

3. The only public code-review benchmark used is authored by the vendor ranked #1 on it (Tenki), disclosed in a caveat box and in the source data comments.

Using the only available benchmark while disclosing its provenance is better than having no page. But the disclosure is text-level only — a user who lands from a search, sees Tenki at #1 and a badge saying "source: Tenki benchmark ↗", and doesn't read the caveat box will come away with a misleading impression. The concern is not the decision to include the data but the weight the UI gives to the conflict signal.

Option	What it gives users	What it costs	Effort to change later
Current: caveat box	Full picture for careful readers	Easy to miss on scroll	No structural change needed
More prominent conflict flag	Conflict is inescapable	Slightly noisy UI	One-line label change
Omit until a second benchmark exists	No conflict risk	No code-review page at all	Full page rebuild

The current approach is correct so long as the conflict signal is impossible to miss — moving the caveat above the table rather than below it, or adding a persistent "⚠ vendor benchmark" badge next to the rank-1 row, would close this gap.

4. SWE-bench is reclassified from an agent-level benchmark to a model-level benchmark, because the source dropped the per-row harness column — so each score is now attributed to a model, not a (harness × model) pair.

The reclassification is forced by upstream data loss, not a product choice, so the decision itself is correct. The concern is downstream: SWE-bench's agentNative rubric score drops from 100 to 65, reducing its weight in the benchmark composite, even though SWE-bench measures exactly the agentic coding capability the site cares about most. Users who relied on SWE-bench scores appearing on agent harness detail pages will no longer see them there. This is an acceptable tradeoff but worth flagging in the benchmark's blurb rather than burying in code comments.

5. Agent infrastructure — sandbox cold-start, object storage throughput, and remote browser latency — is introduced as a first-class product category, with three new pages and nav entries, sourced from ComputeSDK's daily CI benchmarks.

Infrastructure rankings are genuinely useful to practitioners building agents, and the sourcing (daily open CI, raw data in a public repo) is the highest-quality approach on the site. But this is a meaningful scope expansion: the site previously answered "which model is best at coding?" and now also answers "which sandbox/storage/browser provider should you use?" These are different audiences and different decisions.

Option	What it gives users	What it costs	Effort to change later
Current: three nav items at same level as Model/Agent	Infrastructure discoverable alongside model rankings	Nav grows to 8 items; blurs site identity	Moderate restructure
Infrastructure under a grouped sub-nav	Clean separation of concerns	Slightly more clicks	Nav component change only
Separate microsite	No identity dilution	Build and maintain a second domain	High

The infrastructure pages are well-executed, but putting Sandbox/Storage/Browser at the same nav level as Model/Agent/Code-Review implies they answer the same kind of question. A grouped sub-nav or a clear "Agent Infrastructure" section header would preserve the model-ranking identity while surfacing the infrastructure data.

6. **Top-overall models that have never been run on a given harness appear as

The intent — showing users what could be benchmarked — is valuable as a gap-awareness feature. But placing unmeasured models inside the ranked table creates a category error: a user sees GPT-5 at rank 3 on the Claude Code board and may not notice the small "not run on Claude Code" badge. The row renders with empty benchmark cells, which is visually distinguishable, but the rank number and bar chart are live and meaningful-looking.

The correct approach is correct only if the ghost rows are visually loud enough that no user could mistake them for measured entries. The current 25% opacity reduction may not be sufficient — a "coverage gap" section below the measured table, with a clear heading, would remove the ambiguity entirely while still communicating the same information.

7. The main home board now ranks models by their breadth-weighted overall composite (across every benchmark the site tracks), rather than by per-harness composite — and the column header changes from "Score" to "Overall."

This is a fundamental change to what the home page leaderboard answers. Previously: "which model performs best on the Claude Code harness?" Now: "which model is best overall across all benchmarks?" The change is coherent with the site's expansion beyond a single harness, but it means the board no longer cleanly answers the question implied by the harness-switcher pill above it. A user who selects the "Claude Code" harness view but sees overall scores in the right column may be confused about what they're looking at. The harness-specific composite should remain accessible (it is, as a tiebreaker) but the primary ranking column should either match the selected harness or be clearly labeled "all benchmarks" in the harness header rather than just in the column tooltip.

8. The "All" filter label is renamed to "Frontier" on the main harness board.

Frontier" is not a synonym for "all models including open-weight ones.

9. A new evidence-weighted composite formula penalizes models with few benchmarks: one benchmark caps at ~75 composite; three or more benchmarks face negligible penalty.

This directly addresses a real artifact: a model that tops a single niche benchmark could otherwise outrank models measured broadly. The 1/n prior approach is principled — it's a standard Bayesian shrinkage toward the population median, and the penalty is transparent (a flagship model topping three major benchmarks scores normally). The formula change will re-rank existing models, so users may be confused if scores change without an explanation, but the change is correct.

10. Deep research agents are introduced as a distinct category — separate from coding agents and code review — with their own page sourced from DeepResearch-Bench on HuggingFace.

Multi-step web investigation → cited report is a genuinely distinct agent capability. The sourcing (HF raw CSV, auto-updates) is clean and the "A different axis" explanatory card correctly positions it as completeness-of-landscape rather than a core coding metric. No concerns.

11. FrontierMath (Epoch AI Tier 4) is added as a model benchmark despite having agentNative: 0 and realism: 60 — meaning it measures math reasoning on a private held-out set, not coding agent behavior.

FrontierMath's contamination resistance is genuinely valuable signal, and Epoch AI's scoring methodology (private set, verified answers) is among the most rigorous on the site. The low agentNative weight will keep it from distorting the composite. The concern is user perception: a user browsing the benchmarks page will see FrontierMath alongside SWE-bench and coding evaluations and may infer it measures coding ability. The blurb ("exceptionally difficult research-level math") is accurate but its placement in a coding-agent leaderboard without a clear "math reasoning" category tag could mislead.

12. The main navigation drops "Top Team" and adds Code Review, Deep Research, Sandbox, Storage, and Browser — growing from 6 items to 9 items across substantially different product categories.

Each individual addition is defensible, but the aggregate effect is a nav with 9 items spanning model rankings, agent rankings, code review, research agents, sandboxes, storage, and browsers — with no grouping or hierarchy. This creates navigation that is hard to scan and no longer communicates a clear site identity. Users arriving for the first time will not immediately understand what the site is about. A two-level nav (or at minimum visual grouping: "Rankings" | "Infrastructure" | "Benchmarks/Gaps/Method") would restore scannability without removing any content.

Open questions

• Is the caveat about the Tenki-authored benchmark visible enough to users who land directly on /code-review from search? (Would moving the caveat above the table change behavior?)

• Does the ghost-row feature need a user study or A/B test before the home board ships it? Specifically: do test users read the 'not run on [harness]' badge as a warning, or do they treat the rank number as a real harness ranking?

• What is the intended audience hierarchy — practitioners choosing models, practitioners choosing infrastructure, or benchmark researchers? The navigation now serves all three without prioritizing any.

• The PR description says it's adding BridgeBench, but the RUBRIC comment says BridgeBench was removed in 2026-07. Is the PR description outdated, or is there a version of BridgeBench integration being removed in the same PR it was added?

• For the Sandbox/Storage/Browser pages sourced from ComputeSDK benchmarks: is ComputeSDK a neutral third party with no financial relationship to the providers it ranks? (Same conflict-of-interest concern as Tenki.)

• The 'Frontier' filter label implies open-weight models are not frontier. As open-weight models approach closed-weight quality, will this label require revisiting, and if so how soon?

Recommendation

Ship with changes
The SWE-bench fix, new tasks, and composite formula change are clearly correct and should ship. The code review page, infrastructure pages, and deep research page are well-executed additions. However, two decisions need changes before shipping: the 'Frontier' filter label is semantically wrong (rename back to 'All' or find a more accurate term), and ghost rows need stronger visual differentiation from measured entries — the 25% opacity reduction is insufficient to prevent users from treating inferred overall ranks as harness-specific benchmark results.