Когда одна и та же модель пишет код и проверяет его, она пропускает свои ошибки. Она «помнит», почему приняла именно это решение, и не ставит его под сомнение. Знакомо? Как вычитывать собственный текст: глаз замыливается, мозг подставляет правильный смысл туда, где его нет.

В нормальной команде эта проблема решена давно: автор кода ≠ ревьюер. Два человека с разным контекстом и разными слепыми пятнами. С LLM можно сделать то же самое, взяв две модели от разных вендоров. Другая архитектура, другой pretrain - другие слепые пятна. Одна пишет, другая проверяет.

В англоязычной среде этот подход называют adversarial review, «состязательное ревью». Суть: ревьюер не подтверждает, что все хорошо, а пытается сломать уверенность в решении. Я называю это проще: перекрестное ревью.

У меня Claude (Opus) планирует и пишет код, а Codex (GPT-5.4) ревьюит. Автоматически, в цикле, пока не одобрит. Все это - один файл-скилл для Claude Code. О нем и расскажу.

Запускаем на ноутбуке учебный кластер ClickHouse — шардированный (sharding) и реплицируемый (replication) — на Docker Compose.
Это не один сервер в контейнере, а стенд из 2 шардов × 2 реплики, с координацией через ZooKeeper и балансировкой HAProxy — поднимается за несколько минут.
Зачем: на практике разобрать репликацию и распределение по шардам, увидеть базовую отказоустойчивость и спокойно экспериментировать — всё в контейнерах, всегда можно снести и развернуть заново.
Кому: новичкам, кто хочет «пощупать» кластер; тем, кто знает базовый синтаксис ClickHouse, но не пробовал шардирование/репликацию; тем, кто готовится к собеседованию или приценивается к архитектуре перед продом.
В комплекте — готовые конфиги и docker-compose.yml в репозитории; всё, что нужно, — Docker и несколько команд.