When AI writes more of the code, code review becomes more important, not less. The failure mode is rarely dramatic. It is usually ordinary and expensive: plausible patches, incomplete fixes, brittle edge cases, weak self-review, and premature “done” states.
Reading every generated line does not scale. Skipping review is how AI slop becomes production debt.
That is why we built Crosscheck: an open-source assistant workflow for independent AI code review. It watches PRs, runs review, applies targeted fixes when configured, re-checks the result, and handles conflict-resolution steps when the automated path is safe.
Crosscheck is open source. Install @humanbased/crosscheck from npm, connect GitHub plus Codex or Claude Code, and run review loops from your own machine or server.
The product choice is deliberately pragmatic. Crosscheck drives Codex and Claude Code directly for review, fix, re-check, and conflict-resolution steps. Teams can use the CLI tools and subscriptions they already pay for, instead of moving every review into a new hosted service or a separate per-review API bill.
This analysis asks a practical question: which workflow choices protect quality without slowing the team down?
What we analyzed
We joined GitHub PR metadata for humanbased-ai/monorepo with retained local Crosscheck logs. The repository was created on 2026-04-27T10:08:41Z; the first PR in the dataset was opened on April 30; the analysis window runs through June 5, 2026.
The full PR population covers 295 pull requests. The retained Crosscheck logs cover May 24 to June 5, giving us a smaller workflow-observed subset of 96 PRs.
The core measurements:
| Measure | Value |
|---|---|
| PRs since repo creation | 295 |
| Non-doc PRs | 286 |
| PRs in retained Crosscheck logs | 96 |
| Recorded workflow minutes | 2,948.8 |
| Recorded review hours | 49.1 |
| 24-hour days of workflow | 2.0 |
| Recorded tokens | 1,798,577 |
| Unique ticket refs | 157 |
We separate the goal from the implementation:
- Problem complexity is derived from issue or goal signals: title, body, branch, ticket refs, and acceptance wording.
- Solution complexity is derived from the PR: files changed, churn, and implementation shape.
- CR cost is measured from Crosscheck logs: workflow minutes, review/fix minutes, tokens, and repeated review loops.
- Review-risk proxy comes from Crosscheck verdicts and fix loops. It is not production quality yet. We still need post-merge defect, incident, CI, revert, and follow-up-fix joins.
Finding 1: route review from demand and PR shape
The strongest product lesson is not “which telemetry field explains cost afterward.” The useful question is: which setup choices make a PR likely to need more review before we spend the review budget?
In this sample, ticket bundling was the clearest controllable cost signal. Problem complexity and solution complexity also mattered, but they describe different layers. The issue brings demand complexity. The coding agent creates one solution shape.
Crosscheck should route review strength from both.
A practical router should classify the issue, estimate PR shape, capture coding-agent and model provenance, then choose a review lane:
- Small single-domain PRs get fast review.
- High-risk goals get stronger review and re-check.
- Large bundles get review plus explicit decomposition pressure.
- Uncertain agent/model provenance gets stricter inspection.
- Domain-sensitive code gets human-plan or domain-owner gates.
Crosscheck already has workflow tiers such as balanced and thorough. The next product step is to make review strength an automatic routing decision, not a manual habit.
Finding 2: bundle related tickets, but stop before the PR becomes a program
The most practical process question is simple: should we ship a larger PR covering multiple tickets, or keep PRs small and run more review loops?
The answer is not “always split.” In the retained Crosscheck window, PRs with 2-3 ticket refs looked comparable to one-ticket PRs on median computer time and CR rounds, while preserving approve rate. That is a useful bundle size when the tickets form one coherent unit.
The warning sign is 4+ tickets. Those PRs became a different operating mode: higher median computer time, more review/fix time, more rounds, and a much lower approve rate. At that point, bundling stops saving coordination cost and starts hiding risk.
Median per-PR comparison:
| Bundle | Sample | Problem / solution | Workflow / PR | Review + fix / PR | CR rounds / PR | Wall-clock / PR | Tokens / PR | Approve |
|---|---|---|---|---|---|---|---|---|
| 1 ticket | 19 PRs / 19 tickets | 28.5 / 43.3 | 34.6m | 19.2m + 1.6m | 9 | 27.4h | 13,609 | 63% |
| 2-3 tickets | 10 PRs / 20 tickets | 32.3 / 43.5 | 38.7m | 11.6m + 1.1m | 9 | 57.1h | 9,592 | 60% |
| 4+ tickets | 11 PRs / 69 tickets | 52.6 / 82.0 | 86.4m | 46.5m + 10.7m | 13 | 41.5h | 20,567 | 18% |
The operating rule we took from this:
Bundle tickets when they are one evidence unit: same domain, same rollout, shared migration, or one acceptance flow.
Split when they cross domains, need different reviewers, or deserve separate rollback stories.
Finding 3: do not rank coding agents without provenance
The observed agent comparison is useful, but not fair enough to crown a winner.
Codex-origin PRs in this sample were mostly smaller site and product-polish changes. Claude-origin PRs carried more ticket refs, higher problem scores, and more backend/domain-risk work. The measured outcomes reflect task assignment as much as agent ability.
The origin proxy table shows the bias:
| Origin proxy | PRs | Ticket refs | Avg problem | Avg solution | Avg workflow | Avg rounds | Approve |
|---|---|---|---|---|---|---|---|
| Claude | 30 | 89 | 33.4 | 55.7 | 72.2m | 11.6 | 33% |
| Codex | 28 | 8 | 13.8 | 35.9 | 12.2m | 4.5 | 79% |
| Human | 11 | 11 | 27.8 | 40.7 | 37.2m | 8.7 | 82% |
| Unknown | 20 | 4 | 21.1 | 40.4 | 0.0m | 0.0 | 0% |
The conclusion is not “Codex is better” or “Claude is worse.” The conclusion is that Crosscheck needs first-class provenance for:
- original coding agent
- underlying model
- effort setting
- context strategy
- verification path
- original PR state versus Crosscheck-fixed state
Without that, task assignment bias overwhelms model choice.
What model comparison can tell us today
Reviewer model routing is more actionable than original coding-agent ranking because Crosscheck owns that part of the workflow.
In retained review-call logs, Claude Sonnet review calls were much faster and used fewer recorded tokens than Claude Opus calls. Opus appeared on somewhat harder PRs, so this is not a quality ranking. It is a routing hint.
| Reviewer setup | Calls | PRs | Avg problem | Avg duration | Avg tokens | Approve | Needs work | Block |
|---|---|---|---|---|---|---|---|---|
| Claude / Sonnet 4.6 | 61 | 30 | 17.0 | 63.2s | 2,194 | 62% | 36% | 2% |
| Claude / Opus 4.7 | 14 | 13 | 24.4 | 162.4s | 9,106 | 50% | 36% | 14% |
The practical policy: use smaller/faster models by default, then escalate to stronger models for high-risk PRs, reviewer disagreement, or repeated fix loops.
What this means for Crosscheck
Crosscheck does not need to magically make generated code good. Its leverage is more practical: make review reliable, observable, cheap enough to run often, and smart enough to spend effort where risk is highest.
The next product opportunities are clear:
- Issue-ticket enrichment. Join Linear/GitHub issue fields so problem complexity is measured from the goal, not inferred from the PR.
- Agent/model provenance. Record coding agent, model, effort, context strategy, and verification behavior for the original PR attempt.
- Complexity-aware workflow lanes. Route low-risk PRs through fast review, complex PRs through review plus targeted fix, and high-risk PRs through human-plan or domain-owner gates.
- Reliability preflight. Check GitHub auth, vendor CLI auth, repo access, and tunnel state before accepting PR work.
- Original vs. fixed state tracking. Separate original PR quality from Crosscheck-applied fix deltas.
- Real cost accounting. Persist provider, model, input/output/cached tokens, duration, and computed USD per reviewer/fixer call.
- Post-merge quality joins. Track reverts, follow-up fixes, bug issues, incidents, and CI failures after merge.
The practice we want
AI-native engineering should not mean “let agents ship whatever they produce.” It should mean faster loops with better instrumentation.
Small goals should move quickly. Risky goals should get stronger gates. PRs should stay shaped for review. Models should be routed by expected risk, not habit. Every run should leave data behind so the workflow gets easier to improve.
That is how agentic teams can improve cadence and quality together.