AI код-ревью на практике — как ИИ проверяет PR по вашим ADR и инцидентам
Чем AI-ревью кода отличается от линтера и обычного ассистента: проверка каждого pull request по архитектурным решениям, прошлым инцидентам и правилам команды.
Большинство инструментов «AI-ревью» делают одно и то же: подключаются к pull request и пишут общие замечания про стиль, именование и потенциальные баги. Это полезно, но не решает главную проблему ревью в зрелой команде — контекст. Линтер не знает, что полгода назад вы приняли архитектурное решение проводить все возвраты через ledger-сервис. Он не помнит инцидент, который случился из-за отсутствия идемпотентности в платежах. Он не в курсе ваших внутренних конвенций.
В этой статье разберём, чем осмысленное AI код-ревью отличается от «умного линтера» и как автоматизировать проверку pull request так, чтобы она опиралась на реальный контекст вашего проекта.
Проблема: ревью без памяти
Классический code review держится на нескольких сеньорах, которые помнят историю проекта. Они знают, почему сделали именно так, какие грабли уже прошли и где тонкие места. Но это знание:
- не масштабируется — на 40 инженеров не хватит ревьюеров с полным контекстом;
- теряется — люди уходят, а вместе с ними уходит история решений;
- неравномерно — джуниор и сеньор ревьюят один и тот же diff по-разному.
Обычные AI-ассистенты эту проблему не решают, потому что у них нет доступа к вашей истории. Они работают только с текстом diff.
Решение: ревью, привязанное к контексту
Осмысленное AI код-ревью сверяет каждый diff не с абстрактными «лучшими практиками», а с конкретными артефактами вашего проекта:
- Архитектурные решения (ADR). Если изменение нарушает принятое решение — например, «все запросы должны фильтроваться по
tenant_id» — это всплывает до мержа. - Прошлые инциденты. Если похожий код уже приводил к аварии, ревьюер об этом напомнит.
- Правила и конвенции команды. Именование, границы модулей, паттерны — проверяются автоматически на каждом PR.
Результат — не «100 стилистических придирок», а несколько точных замечаний по существу: что нарушает архитектуру, что повторяет старую ошибку, что разойдётся с требованиями.
Как это выглядит в ShipGrid
Когда открывается pull request, ShipGrid собирает контекст из связанного графа знаний — ADR, инциденты, требования, история — и проверяет diff против него. В комментарии к PR вы видите оценку, нарушения архитектуры со ссылкой на конкретный ADR и предложенные исправления в стиле ваших паттернов.
$ shipgrid review PR #847
Score 8.5 / 10
Security PASS (0 critical, 1 low)
Architecture 2 нарушения ADR
→ ADR-007: платёжный сервис должен использовать ключи идемпотентности
→ ADR-012: все запросы должны фильтровать по tenant_id
✓ Ревью отправлено в GitHub PR #847
Что это даёт команде
- Меньше шума. Ревьюеры тратят время на смысл, а не на стиль.
- Сохранённая память. Контекст не уходит вместе с людьми.
- Единый стандарт. Каждый PR проверяется одинаково — независимо от того, кто его открыл.
Автоматизация код-ревью с ИИ — это не замена сеньоров, а способ дать каждому инженеру их контекст в момент, когда он нужен: при ревью изменения.
Хотите попробовать AI-ревью на своём репозитории? Напишите нам — подберём формат пилота под вашу команду и стек.