Ultrareview vs zwykły review — kiedy multi-agent ma sens

Code review w Claude Code można robić na trzy sposoby: prosty agent z prompt'em, dedykowany subagent typu code-reviewer, albo /ultrareview, multi-agent cloud review. Pokazuję różnice na konkretach i kiedy każde z trzech ma sens.

Trzy poziomy

/ultrareview jest commercial feature, wymaga osobnego konta i jest billed per-run. Pozostałe są w standardowym Claude Code.

Co robi /ultrareview

Cloud-side, multi-agent. Spawna kilka wyspecjalizowanych agentów paralelnie:

• Type-design-analyzer, sprawdza spójność type'ów, encapsulation
• Silent-failure-hunter, szuka catch blocków zjadających errory
• Pr-test-analyzer, gap testowy, coverage edge cases
• Comment-analyzer, czy komentarze zgodne z kodem, czy nie wprowadzają technical debt
• Code-simplifier, fragmenty które można uprościć

Każdy zwraca raport. Następnie meta-agent agreguje, deduplicate'uje, prioritizuje. Wynik to jeden uporządkowany feedback.

Workflow: jak go uruchamiam

# Z brancha z PR
/ultrareview
 
# Albo dla istniejącego GitHub PR
/ultrareview 1234

Wymaga: git repo, opcjonalnie GitHub remote. Komenda jest user-triggered (Claude sam jej nie odpali, bo to billed).

Konkretny przykład

Ostatni /ultrareview na branchu z auth refactor (~500 LOC zmienione):

Z prompt'a (30 sekund, $0.30):

"Looks good. Consider adding error handling on line 42."

Generic. Niewspółmierne do złożoności changeu.

Z code-reviewer subagent (2 min, $0.50):

3 issues:

1. Race condition in token refresh (auth.ts:67)
2. Missing input validation on email (login.ts:23)
3. Inconsistent error format (5 places)

Lepiej. Ale nadal omija subtelne rzeczy.

Z /ultrareview (8 min, $4.20):

11 issues, sorted by severity: CRITICAL:

• Race condition w token refresh (auth.ts:67) - może powodować logout pętli
• Silent failure w 3 miejscach: catch bez logu HIGH:
• Brak rate limiting na endpoint resetowania hasła
• Test coverage 60% — gap dla flow "expired token + active session"
• Inconsistent error format MEDIUM:
• Komentarz na auth.ts:120 niezgodny z kodem (nie aktualizowany?)
• Type User ma optional fields które logicznie required ...

Znalazł rzeczy których ja sam nie widziałem. Race condition mógł by ugryźć w produkcji.

Kiedy /ultrareview jest worth it

1. Auth/security/payments code. Gdzie cena bug'a w produkcji jest wysoka. $4 vs incident worth $40k.

2. Cross-team PR. Gdy nie ma drugiej osoby do review. Multi-agent zastępuje 2-3 reviewerów.

3. Pre-release final check. Przed merge'em do main na production. Inwestycja jednorazowa, lepiej spać.

4. Onboarding na nieznany kod. Gdy uczę się czyjegoś repo. Ultrareview daje szeroką mapę problemów.

Kiedy NIE worth it

1. Małe PR-y. Zmiana 20 linijek nie potrzebuje 5 agentów. Marnowanie pieniędzy.

2. Drobiazgi cosmetic. Linter to robi. Ultrareview = overkill.

3. Code który już jest reviewed. Drugi pass to 99% redundant.

4. Iteracyjny feature work. Każdy commit z 3 reviewami × $4 = $12/feature. Zostaw na milestone'y.

Hybrydowy workflow który stosuję

1. Każdy commit: linter + automated tests (free, fast)
2. Każdy PR: subagent code-reviewer (~$0.50, 2 min)
3. Pre-merge na auth/security/payment: /ultrareview ($4, 8 min)
4. Pre-release: /ultrareview na całym milestone'cie

Średnio robię 2-3 /ultrareview w miesiącu. Koszt: ~$15. Wartość: minimum 1 nieuwięzniony bug w produkcji per kwartał, łatwo zwraca się 100x.

Ograniczenia

1. Lag czasowy. 8 minut to długo. W IDE flow to przerywa. Lepiej odpalić na końcu dnia, sprawdzić rano.

2. False positives. Mniej niż w pojedynczym agencie, ale są. Multi-agent czasem flagi rzeczy które są intentional. Reviewuj feedback, nie aplikuj automatycznie.

3. Koszt. $4 per run. Jak masz hard budget cap, limit cię uderzy.

4. Nie ma offline. /ultrareview to cloud feature, działa tylko gdy serwer Anthropic działa.

/ultrareview to nie zamiennik human review. To inwestycja w bezpieczeństwo na critical paths. Standardowy review na 95% PR-ów. Ultrareview na 5% gdzie cena błędu jest wysoka. Mierz, używaj świadomie, nie nadużywaj.