Я прочитал статью про 9 AI-ревьюеров — и сломал свой бюджет на токены

Значит так. Сижу, листаю Hacker News, натыкаюсь на пост от чувака с hamy.xyz: «9 Parallel AI Agents That Review My Code». Девять. Параллельных. Агентов. Которые ревьюят код.

Я разраб и пишу на Claude Code уже год. Скиллы, субагенты, worktrees – всё как у людей. И вот читаю я этот пост и думаю: ну, у меня же уже стоит Superpowers с его code-review скиллом, но он один. А тут – девять штук. Security reviewer, performance reviewer, test quality reviewer, simplification reviewer… Каждый со своей специализацией, каждый в своём контекстном окне, каждый жрёт токены как не в себя.

Естественно, я решил попробовать.

Что вообще придумал этот Hamy

Идея простая до безобразия. У тебя есть Claude Code. У Claude Code есть субагенты – отдельные инстансы модели, которые запускаются параллельно, каждый со своим системным промптом и набором инструментов. Hamy написал slash-команду /code-review, которая спавнит 9 таких субагентов:

1. Test Runner – прогоняет тесты

2. Linter & Static Analysis – линтеры и диагностика IDE

3. Code Reviewer – до 5 конкретных улучшений, ранжированных по impact/effort

4. Security Reviewer – инъекции, секреты, auth

5. Quality & Style – сложность, дублирование, мёртвый код

6. Test Quality – покрытие, flakiness, поведенческие тесты

7. Performance – N+1, блокирующие операции, утечки памяти ^[1]

8. Dependency & Deployment – зависимости, миграции, breaking changes

9. Simplification & Maintainability – а нужна ли вообще эта сложность

Каждый агент работает независимо, возвращает findings по severity (Critical / High / Medium / Low), а главный агент собирает всё в единый отчёт с вердиктом: Ready to Merge, Needs Attention или Needs Work.

Hamy говорит, что ~75% рекомендаций полезны. Critical и High – почти всегда по делу.

Звучит красиво, да?

18 000 токенов в минуту на одного агента

Вот тут начинается самое интересное. Я полез считать.

Каждый субагент в Claude Code – это отдельный инстанс модели с собственным контекстным окном. Ему нужно:

• Инициализация контекста: 5 000–15 000 токенов

• Верификация инструментов: 2 000–8 000 токенов

• Собственно работа: ещё токены

• Поддержание контекста: 500–2 000 токенов в минуту

Один чувак на AICosts.ai задокументировал кейс: 49 параллельных субагентов, 2.5 часа работы, 887 000 токенов в минуту. Каждый агент жрал примерно 18 000 токенов в минуту. Итого за сессию – что-то между $8 000 и $15 000.

Ладно, 49 агентов – это экстрим. У Hamy их 9. Но и 9 – это не один. По грубым прикидкам, если каждый из девяти работает хотя бы минуту-две, это 160 000–360 000 токенов только на один code review. При ценах Opus – ну, баксов 5–10 за один ревью. А если Sonnet – доллара 2–3.

Anthropic недавно выкатили собственный Code Review для Enterprise – $15–25 за PR. То есть кастомный скилл выходит дешевле. Но он и ловит меньше.

Уроборос, которого никто не обсуждает

А теперь про то, что меня реально зацепило и ради чего я вообще сел писать.

Hamy пишет: «I also instruct AI agents to run this skill and iterate before marking tasks complete». То есть AI-агент пишет код, потом другой AI-агент этот код ревьюит, потом первый агент фиксит замечания, потом снова ревью…

AI ревьюит AI. Уроборос. Змея, кусающая свой хвост.

И вот тут возникает вопрос, который я нигде не видел в обсуждениях: а это вообще работает? Не в смысле «даёт ли оно комментарии» – даёт, конечно. А в смысле – ловит ли оно ошибки ^[2], которые LLM сама же и создаёт?

CodeRabbit выкатили отчёт: AI-код содержит в 1.7 раза больше багов, чем человеческий. Логические ошибки – в 1.75 раза чаще. Проблемы с безопасностью – в 2.74 раза. Производительность – в 8 раз больше лишних I/O операций. Это из анализа 470 pull request’ов, 320 от AI, 150 от людей.

Окей, но если AI-ревьюер смотрит на AI-код… он же обучен на тех же данных. У него те же слепые пятна. Ankit Jain из Latent Space формулирует жёстче: «Fresh eyes with AI means another agent with the same blind spots». LLM ненадёжны в self-verification – они уверенно скажут тебе, что код работает, пока он горит.

Может я придираюсь. Может 75% полезных рекомендаций – это и правда хороший результат. Но есть нюанс.

Контекст деградирует, а агент – нет (или нет?)

У Anthropic есть внутренние данные: качество ответов модели начинает падать после 70% заполнения контекстного окна. Attention weights размазываются – модели приходится решать, какие из 200 000 токенов важнее для текущего вопроса. А когда контекст забит – ответ сжимается, теряет нюансы.

Auto-compaction помогает, но частично. Каждое сжатие – потеря деталей. После 3–4 compaction’ов критический контекст может просто исчезнуть.

Субагенты решают эту проблему элегантно: у каждого свой чистый контекст. Никакого мусора из предыдущих разговоров. Ревьюер видит только diff и свой системный промпт – ничего лишнего.

Но. (Вот он, один на всю статью.)

Результаты всех девяти субагентов возвращаются в главный контекст. 9 агентов × развёрнутый отчёт каждого = внезапно твой главный агент забит ревью-артефактами, и следующая задача будет решаться уже с деградированным контекстом.

Это как нанять девять консультантов и заставить одного менеджера прочитать все девять отчётов за пять минут.

Superpowers и другой подход

Тут надо отступление. Я использую фреймворк Superpowers от Jesse Vincent – это набор скиллов для Claude Code, который превращает его в что-то похожее на дисциплинированного разработчика. TDD, планирование, brainstorming – всё через скиллы.

У Superpowers свой подход к code review. Там нет девяти параллельных агентов. Вместо этого – двухэтапная проверка: сначала соответствие спецификации, потом качество кода. И отдельный скилл requesting-code-review, который активируется автоматически между задачами. Critical issues блокируют прогресс – агент не может перейти к следующей задаче, пока не починит.

Разница в философии: Hamy ставит на ширину (9 специализированных глаз), Superpowers – на глубину (2 этапа, но с блокировкой).

По токенам Superpowers значительно экономнее – один субагент вместо девяти. Но и покрытие у́же. Security-специфичные баги, которые ловит отдельный security reviewer, общий code reviewer может пропустить.

Хотя, честно? Я не замерял.

Архитектурная ловушка: генератор ≠ ревьюер

Latent Space опубликовали разбор, который всё ставит на свои места. Ключевая мысль: генератор кода и ревьюер кода – это разные работы. Они не должны знать друг о друге.

«The coding agent shouldn’t know what verification checks exist» – иначе он начнёт оптимизировать код под ревьюера, а не под задачу.

Adversarial design: один агент пишет, другой проверяет, третий пытается сломать. Модель Swiss cheese – ни один фильтр не ловит всё, но когда их несколько, дырки не совпадают.

Звучит круто в теории. На практике – вот тебе данные от Faros.ai по 1 255 командам: PR review time вырос на 91% у команд с высоким AI-adoption. То есть AI пишет код быстрее, но ревью этого кода занимает почти вдвое больше. Не важно, ревьюит человек или другой AI.

И это я ещё не посчитал cost multiplier. Один агент стоит $3–8 в час. Три агента – $15–40. Десять – $50–150. Двадцать пять – $200–500. Данные с AICosts.ai, и нет, это не линейная зависимость – overhead на координацию растёт нелинейно.

Что делать-то

Я потратил пару вечеров на ресёрч, и вот к чему пришёл. Не претендую на истину.

Если у вас Max-подписка за $100–200 в месяц – 9 параллельных агентов на каждый коммит вас убьют по лимитам за день. Тупо не хватит токенов.

Если API – считайте. $5–10 за ревью × 20 коммитов в день = $100–200 в день. Это $2 000–4 000 в месяц. На одного разработчика.

Рабочий компромисс, который я для себя нашёл: Superpowers с его двухэтапным ревью на каждую задачу (дёшево, автоматически), плюс полный 9-агентный ревью от Hamy перед мержем в main (дорого, но раз в день). Типа ежедневный checkup у терапевта + полный чекап раз в год.

Ну и самое банальное: для простых субагентных задач можно указать model: haiku – это в 10–15 раз дешевле Opus. Линтер и test runner не нуждаются в рассуждениях уровня Opus. Security reviewer – возможно, нуждается.

# Экономный вариант
---
name: linter-reviewer
model: haiku
tools: Read, Grep, Glob, Bash
---
 [3]

# Тяжёлая артиллерия
---
name: security-reviewer
model: opus
tools: Read, Grep, Glob, Bash
---
 [3]

Круговая проблема

Меня не отпускает одна мысль. AI-агент пишет код. Другой AI-агент этот код ревьюит. Первый агент фиксит по замечаниям. Ревьюер проверяет фикс.

А кто проверяет ревьюера?

LLM уверенно говорит «всё ок», когда всё не ок. CodeRabbit это подтверждает числами. Latent Space предлагает adversarial design. Hamy предлагает 9 специализированных глаз. Anthropic предлагает платить $15–25 за официальный ревью.

Проект Ouroboros на GitHub – это self-modifying AI-агент, который пишет свой собственный код, ревьюит его другими LLM и коммитит. За первые 24 часа он прошёл 30+ циклов самомодификации без единого вмешательства человека. Результат? Ну… он работает. Но никто не проверял, что конкретно он туда наревьюил.

В итоге мы получаем систему, где AI пишет код с 1.7x больше багов, AI это ревьюит с теми же слепыми пятнами, а мы платим $5–25 за каждую итерацию этого цирка. Код становится лучше? Наверное. На 75%, если верить Hamy. А оставшиеся 25% – это баги, которые ни один из девяти агентов не поймал, потому что все девять обучены на одних и тех же данных.

Возможно, я неправ. Возможно, специализация агентов достаточно разводит их blind spots. Security reviewer, натасканный на OWASP, видит то, что performance reviewer не видит – и наоборот. Это разумный аргумент. Но это не adversarial design в чистом виде – это всё ещё один и тот же Claude под капотом.

Практическая часть, которая реально полезна

Ладно, хватит философии. Если вы всё-таки хотите попробовать – вот что я выяснил за время ресёрча.

Субагенты в Claude Code определяются как markdown-файлы в .claude/agents/. YAML frontmatter + системный промпт:

---
name: security-reviewer
description: Reviews code for security vulnerabilities. Use proactively after code changes.
tools: Read, Grep, Glob, Bash
model: sonnet
---

You are a security code reviewer. Check for:
- Injection risks (SQL, XSS, command)
- Authentication and authorization issues
- Secrets in code
- Error handling that leaks sensitive info
 [3]

Из скилла (это .claude/skills/) можно спавнить субагентов через инструмент Agent:

Use the security-reviewer subagent to review changes in src/auth/
 [3]

Ключевые настройки, которые экономят деньги:

• model: haiku для простых проверок (линт, тесты, стиль)

• model: sonnet для среднего уровня (код-ревью, зависимости)

• model: opus или inherit только для security и architecture

• maxTurns – ограничить количество ходов, чтобы агент не ушёл в бесконечный ресёрч

• background: true – запускать в фоне и не блокировать основную работу

Ещё одна штука: у субагентов теперь есть persistent memory. Если включить memory: project, ревьюер начинает запоминать паттерны проекта между сессиями. Через неделю использования он уже знает ваши conventions и не повторяет дженерик-замечания.

Зачем всё это пишут в маркдауне

Тут, кстати, надо отступление, не по теме, но не могу не сказать.

Hamy в своём блоге пишет: «I iterate on my workflows in markdown. I’m coding in markdown.» И это правда. Весь этот пайплайн из 9 ревьюеров – это текстовый файл. Не код на Python. Не конфиг на YAML (ну, кроме frontmatter). Маркдаун.

Мы дошли до точки, где «программирование AI-агентов» – это написание текста на английском языке в файлах с расширением .md. Скиллы, субагенты, slash-команды – всё маркдаун. Мой бот для новостей – маркдаун. Код-ревью на 9 агентов – маркдаун.

Я не знаю, что с этим делать. Просто фиксирую.

UPD: Перечитал статью и понял, что забыл главное. Hamy говорит, что использует этот ревью не только для своего кода, а ещё как «validation gate» – заставляет AI-агента прогнать ревью перед тем, как отметить задачу выполненной. То есть это не замена человеческому ревью, а фильтр перед ним. И в этом контексте 75% точности – вполне нормально. Это не последняя проверка, а первая. Человек потом смотрит то, что прошло через фильтр. Может, в этом и есть настоящий смысл всей конструкции – не заменить ревьюера, а убрать из его работы 75% рутины.

Кстати, уже после того как написал, заглянул в issues Superpowers на GitHub – там есть тикет #469 про переход на agent teams для параллельного выполнения планов. То есть они тоже идут в сторону параллельных агентов. Видимо, это неизбежно.