[Ревью кода] Ревью кода в эпоху ИИ — кто проверяет код, который пишет ИИ? Трансформация разработки ПО в эпоху ИИ — Учим ИИ медленно 174
Рецензирование кода в эпоху ИИ — кто проверяет код, написанный ИИ?
В предыдущей статье (AI173) я назвал «верификацию» третьим новым узким местом, когда код стал практически бесплатным, и в конце оставил фразу «четвёртый раздел разберём отдельно». Сейчас выполняю обещание. Сначала вывод: если оглянуться на середину 2026 года, главной переменной в инструментах ИИ-программирования являются не количество лицензий, не количество рабочих мест, не результаты бенчмарков моделей — это пропускная способность рецензирования.
В отчёте CodeRabbit, опубликованном в конце 2025 года, были проанализированы 470 открытых pull‑запросов на GitHub. Вывод: код, сгенерированный при участии AI, содержит в 1.7 раза больше дефектов, чем код, написанный вручную (в среднем 10.83 vs 6.45 дефектов на PR, без учёта размера файла и сложности). Уязвимости безопасности в разрезе подклассов возросли от 1.57 до 2.74 раз — XSS 2.74×, некорректная обработка паролей 1.88×, небезопасные прямые ссылки на объекты 1.91×, небезопасная десериализация 1.82×; логические/корректностные ошибки 1.75×, читаемость 3×+, форматирование 2.66×, обработка ошибок ≈ 2×.
Apiiro в сентябре 2025 года провела сканирование репозиториев компаний из Fortune 50 (данные охватывают период с декабря 2024 г. по июнь 2025 г.), дополнив картину: AI‑генерируемый код привёл к росту ежемесячных обнаружений уязвимостей примерно с 1 000 до 10 000+ (рост в 10×). При этом уязвимости повышения привилегий выросли на 322 % (абсолютные значения; после нормализации на объём кода рост оценивается в 60‑80 %), а архитектурные дефекты проектирования — на 153 %. Одновременно синтаксические ошибки снизились на 76 %, а логические баги — на 60 %.
Эти два массива данных в совокупности указывают на один важный аспект, особенно значимый в контексте регулирования: значительная часть из тех 322% уязвимостей повышения привилегий, выявленных Apiiro, приходится на границы привилегий — а в финансовом и телекоммуникационном секторах границы привилегий означают непосредственный доступ к средствам и данным клиентов. Код, написанный AI, нередко выполняется, однако число дефектов и уязвимостей растёт пропорционально, причём наиболее опасные из них увеличиваются скрытыми темпами. (Оговорка: данные CodeRabbit представлены позицией вендора, информация Apiiro получена от стороннего поставщика средств безопасности — направленность выводов совпадает, но для корректной интерпретации необходимо учитывать методологию нормализации.)
В контексте конкретного предприятия этот факт порождает два контрintuitивных вывода, и каждый из них противоречит нарративу, транслируемому поставщиками приобретённых вами инструментов.
Один. Два контрintuitивных вывода
Контрintuitивный вывод первый: роль разработчика трансформируется из «создателя кода» в «рецензента кода», однако рецензирование оказывается более трудозатратным, чем написание.
Counterintuitive Insight #2: The stronger the AI tools, the more the organization needs governance, not more tools.
According to JetBrains’ January 2026 survey (10,000+ developers, 8 languages), 90% of developers use at least one AI tool. Another industry survey by Pragmatic Engineer in February 2026 presents an even more alarming finding: 56% of senior engineers say that over 70% of their engineering work depends on AI tools (self-reported by heavy users, not code line ratio). This isn’t about occasionally using AI to write a few lines of code — AI has become the default way of working. The production relationship has undergone a major shift: coding has become AI’s job, while developers spend more time on reading and reviewing. Reading someone else’s code has always been harder and slower than writing it; reading unfamiliar AI-generated code while making judgments within compliance boundaries and business rules significantly increases cognitive load compared to writing one’s own code. This is the root cause behind developers’ persistent feedback during 2025–2026 that “AI makes me more tired” — and it aligns with METR 2026.2’s contradictory narrative (early findings that senior developers were slowed by 19% were partially reversed in new samples, while newly onboarded developers still showed -4%, leading to the overall assessment that “review bandwidth is tighter than production bandwidth”).
Counterintuitive Insight #2: The stronger the AI tools, the more the organization needs governance, not more tools.
Дефекты CodeRabbit, выросшие в 1,7 раза, и уязвимости повышения привилегий Apiiro на 322 % — по отдельности это выглядит как неудача ИИ; однако через призму теории ограничений это неизбежный результат того, что возможности инструмента возросли, а способности к проверке не успевают за ними. Производительность системы определяется самым узким участком. ИИ расширил «написание», и самым узким местом стала «проверка»; если пропускная способность проверки не растёт, чем быстрее ИИ пишет, тем опаснее накапливающийся технический долг организации. Таков вывод AI173 — автоматизация не устраняет узкие места, а лишь перемещает их.
Применительно к ИИ‑программированию стоит добавить: разработка ПО — это не единственный конвейерный узел, а набор параллельных узких мест, которые динамически смещаются. TOC применим в классическом конвейере, но в сценарии параллельного мульти‑bottleneck, каким является ИИ‑программирование, самый узкий участок смещается с «написания» на «проверку», а в «проверке» выделяются три направления — верификация, управление и аудит соответствия, — каждое из которых задерживает процесс само по себе.
Практические последствия этого правила имеют два уровня. Первый — перед внедрением автономных агентов необходимо установить четыре «предохранителя»: обязательный ручной code review, автоматизированное тестирование (код после доработок AI должен запускаться), security scan (по тем же стандартам, что и для кода, написанного людьми), и phased rollout (изменения AI сначала развёртываются на небольшом проценте). Pull request от AI не освобождается от ревью. Это минимальный порог для превращения «AI пишет код» в «AI пишет код + организация справляется» как инженерную задачу; отсутствие любого из этих элементов ведёт к неконтролируемому разрастанию проблем. В январских-февральских записях 2026 года Карлини приводит часто цитируемый пример: исследователи Anthropic заставили 16 агентов Claude Opus 4.6 работать параллельно в течение 2 недель, примерно 2000 сессий и ~20 000 долларов на API-расходы, создать с нуля 100-тысячную строку Rust-based C-компилятор, способный компилировать ядро Linux 6.9 и проходить 99% тестов GCC torture test. Важно подчеркнуть: это контролируемый эксперимент в закрытой области; Карлини не выводил код в продакшен; использование этих данных как «крайнего варианта без ревью» имеет смысл, но использование их как образца для «немедленного внедрения автономных агентов» завышает потенциал масштабирования. Без code review, автоматических тестов, security scan и phased rollout код, написанный AI, неизбежно рано или поздно выйдет из-под контроля.
Второй уровень более скрытый: ключ аудита — не поиск багов, а оценка соответствия архитектуре, границ комплаенса и корректности бизнес-логики. Типичная ошибка опытных инженеров — отождествлять аудит в эпоху ИИ с традиционным code review. Традиционный review отвечает на вопрос «есть ли в коде ошибка», тогда как review в эпоху ИИ — «должен ли этот код существовать в данном файле, проекте, в рамках этих границ комплаенса». Приведённые CodeRabbit показатели уязвимостей (1.82–2.74×) и Apiiro — эскалации привилегий (322%) — это типичные случаи: ИИ написал код корректно, но не в том месте, с неправильными правами или некорректными настройками по умолчанию. Подобные проблемы невозможно исправить в IDE — они требуют понимания на уровне аудита. В индустрии распространён подход, при котором изменения схемы, аутентификации, биллинга или границ комплаенса помечаются в branch protection и CODEOWNERS правилах GitHub/GitLab красным флагом и маршрутизируются на двухэтапное одобрение (в финансовом и телеком-секторах на практике обычно применяется backup veto вместо полного review, а доля выборочных проверок варьируется в зависимости от уровня риска). Architecture Decision Records (ADR), базовые требования безопасности и комплаенса, корректность бизнес-правил — вот где в эпоху ИИ действительно стоит сосредоточить усилия при аудите.
Соединив эти два контрintuitивных момента, картина становится ясной: в эпоху ИИ ревью кода требует от компании трёх изменений — привлечь руководителей разработки к процессу ревью, встроить требования комплаенса и архитектурные базисы в маршрутизацию pull request’ов, вывести показатели governance вроде failure rate на уровень отчётности перед советом директоров. Эти три пункта напрямую соответствуют «трём линиям обороны модели» согласно требованиям 《商业银行互联网贷款管理办法》 (Правила управления интернет-кредитованием коммерческих банков) — бизнес, ИТ, аудит комплаенса, что сразу понятно регулятору. Ниже разберём по четырём уровням.
二、Почему именно «сейчас»: механизм того, как верификация становится новым узким местом
Выполняем обещание из раздела 3 статьи AI173 «отдельный разбор в четвёртой секции». Специфика окна середины 2026 года: автономные агенты (Claude Code, Codex) переходят от «пробного использования» к «использованию по умолчанию»; организации, не модернизировавшие ревью до H2, столкнутся с кластером проблем в пиковый сезон Q4 / период финального релиза в конце года / время плановых регуляторных проверок. Сначала объясним, почему «верификация» недооценена больше всего среди новых узких мест, а затем расположим её рядом с двумя другими (корректная постановка задачи, системная интеграция) на одной схеме.
Корень проблемы — в том, что большинство дискуссий об AI-программировании по умолчанию сводят «верификацию» к CI/CD, модульным тестам и проверкам линтера.
Так устроен мир интернет-продуктов: код деплоится в облако, все тесты зелёные, CI проходит, код мёржится — и вот он уже в продакшене. Эта схема отлично работает в ритме интернет-компаний, но буквально рассыпается при переносе в телеком, финансы, производство или e-commerce: в этих отраслях «верификация» — это Algorithm Registration, 等保 (оценка защищённости информационных систем, аналог западных стандартов безопасности), Cross-border Data Transfer Assessment, Change Advisory Board, аудит сверок, регуляторная отчётность — и всё это не имеет ни малейшего отношения к коду, хотя каждое занимает по нескольку недель. В AI173 уже приводилась диаграмма (ускорение кодинга, узкое место — верификация), повторяться не будем. Но остаётся вопрос: сколько этапов верификации должен пройти AI-код, прежде чем попасть в продакшен?
Минимум семь: автоматизированное тестирование, code review, security scan, архитектурная оценка/ADR, review бизнес-правил, согласование compliance и gradual rollout. Каждый этап забирает свою долю пропускной способности команды. Все семь вместе — это «обратная сторона» диаграммы из AI173: AI ускоряет ту часть, где предельные издержки минимальны (GPU-время, стоимость лицензий), а верификация пожирает ту часть, где институциональные издержки максимальны (регуляторика,备案, сверки).
Вторая причина недооценки — сведение «проверки» к банальному code review.
Две ключевые линии развития code review — предложенная Weinberg в 1971 году концепция egoless programming (сформировавшаяся в среде NASA и академических кругах) и Fagan Inspections от IBM 1976 года (продукт системного подхода IBM) — опираются на единое допущение: код пишется строка за строкой, автор лучше всех знает свой код, а после написания другой человек перечитывает его в поисках ошибок. AI ломает это допущение: код генерируется AI за считанные секунды, автор (AI) не участвует в передаче контекста, а читатель (разработчик) сталкивается с незнакомым сгенерированным результатом. Прежнее допущение о «выискивании багов» перестаёт работать. Новое допущение о проверке звучит так: Должен ли этот код вообще существовать в данном файле? Не обходит ли он существующие архитектурные решения? Находится ли он внутри или за пределами допустимых границ комплаенса? Не превратятся ли его настройки по умолчанию в уязвимости в продакшене?
На каждый из этих трёх вопросов способен ответить только специалист, разбирающийся в бизнесе, архитектуре и регуляторике — инструменты играют лишь вспомогательную роль. Речь идёт о переводе «проверки» с уровня линтера в конвейере CI/CD на уровень полноценного элемента инженерного управления.
三、三层评审模型：AI pre-review、人类把关、治理规则
Сведите этот анализ к практически применимой структуре. Трёхуровневая модель не подразумевает замены одного уровня другим: уровни накладываются друг на друга — каждый PR одновременно проходит все три уровня, и каждый из них выполняет свою отдельную функцию.
Уровень 1 функционирует с интервалами от нескольких секунд до нескольких минут — каждая строка кода, сгенерированная ИИ, сначала проходит проверку специализированными инструментами. Такие решения, как CodeRabbit, GitHub Copilot Review, Sourcery, Cursor BugBot и Antigravity Review, способны выдавать обратную связь в пределах от десятков секунд до нескольких минут после создания pull request, обеспечивая контроль соблюдения стандартов кодирования, выявление уязвимостей безопасности, обнаружение дублирующихся фрагментов, проверку корректности именования и оценку рисков, связанных с зависимостями. Этот уровень отличается предельно низкой стоимостью (независимо от числа PR взимается одна и та же абонентская плата) и максимальным охватом (каждый PR подлежит проверке), формируя фундамент пропускной способности. Однако у него есть очевидные слепые зоны — он не способен решать задачи, связанные с архитектурной согласованностью, соблюдением комплаенс-ограничений и корректностью бизнес-логики. Согласно формулировке отчётов CodeRabbit, инструмент ориентирован на «автоматическое пресечение большинства явных проблем», тогда как остаточные скрытые риски (заложенные в нюансах конфигурации по умолчанию, границ разграничения прав доступа и путей обработки исключительных ситуаций) по-прежнему требуют участия человека. Этот уровень — лишь фундамент, а не конечная точка процесса.
Изменения уровня L2 занимают от часов до дней — высокорисковые доработки (затрагивающие ядро системы, схему базы данных, модули аутентификации, биллинга или комплаенса) в обязательном порядке проходят ручную проверку специалистами: архитектором, владельцем продукта и ответственным за безопасность. Значительная часть уязвимостей, обнаруженных на этом уровне, — например, 1,82–2,74× рост проблем безопасности по данным CodeRabbit и 322%-ный всплеск привилегированных уязвимостей по данным Apiiro — как раз требует ручного анализа. Причина в том, что AI-Generated код выглядит корректным, компилируется и даже работает, но тонкости дефолтных настроек, границ прав доступа и обработки исключений скрыты в деталях, которые автоматика не всегда замечает. Средне- и низкорисковые изменения проходят выборочную проверку (рекомендуемая выборка 20–30%, получена на основе опыта внутренних клиентов, а не отраслевой стандарт) — нет необходимости просматривать каждый Pull Request. По сути, это освобождение человеческого ресурса от тотального ревью и переключение фокуса на критически важные участки. Главная ловушка на этом уровне — размывание критериев: команды, стремясь ускорить работу AI, негласно снижают порог высокорисковых изменений. Кажется, что послабление стандартов экономит время, но любая авария мгновенно всё это перечёркивает.
Перевод на русский
Layer 3 занимает дни-недели — это слой, затрагивающий вопросы комплаенса, регуляторной отчётности, трансграничной передачи данных, SLA и межкомандных архитектурных изменений. Здесь проходят процедуры Change Advisory Board (Change Advisory Board (CAB)), экспертиза регуляторных заявок, оценка защиты информации по нацстандартам и взаимодействие с регуляторами. На диаграмме AI173 это оранжевый блок «AI не справляется» — самый дорогостоящий элемент для строго регулируемых отраслей. Согласно оценке AI174: AI не может обработать Layer 3, однако качественно выполненные Layer 1+2 способны отсеять подавляющее большинство низкорисковых изменений до их попадания в Layer 3 (по данным внутренней выборки клиентов — примерно 80–90%). Оставшиеся 10–20% высокорисковых изменений проходят через Change Advisory Board (CAB), что позволяет сосредоточить пропускную способность Change Advisory Board (CAB) на изменениях, действительно требующих управления. Сокращение времени ожидания в очереди Change Advisory Board (CAB) и ускорение общего ритма поставки — это наиболее недооценённый «дивиденд управленческой ёмкости» от повышения уровня экспертизы.
Комплаенс-подпись для Layer 3 должна быть зафиксирована на бумаге. Каждый PR, инициированный маршрутизацией через Layer 3, требует полной цепочки аудита: diff PR + замечания по ревью + подпись владельца бизнеса + подпись владельца комплаенса + временная метка + приложение с отчётом о валидации модели; сроки хранения — 5 лет для финансового сектора, 3 года для телекоммуникаций (со ссылкой на 152-ФЗ §55 + ЦБ КНР [2020] №24 + директиву MIIT о регуляторном реестре алгоритмов). Для взаимодействия с регуляторами это твёрдая доказательная база, а не формальный комплаенс.
Три уровня ключевой архитектуры: условие срабатывания кодируется уровнем риска, а не количеством строк кода или размером PR
На практике оценка уровня риска не может основываться на самооценке AI — у AI нет понимания соответствия нормативным требованиям, он не осознаёт, что «модификация поля с номером паспорта клиента» является красной чертой по 152-ФЗ. Необходимо двойное подтверждение: вручную заполняемая галочка в шаблоне PR инициатором (затрагиваются ли schema? auth? биллинг? границы комплаенса?) плюс правила CODEOWNERS. По результатам выбора происходит маршрутизация на соответствующий уровень: low-risk PR проходит Layer 1 автоматический merge (внутри белого списка путей + механизм circuit breaker, при возникновении инцидента в продакшене из любого auto-merge PR в течение 30 дней — приостановка и полный откат с переходом на ручной review), medium-risk — Layer 2 spot-check, high-risk — Layer 3 процесс управления. Данный подход «risk adaptive routing» представляет собой высшую форму эскалации ревью.
Четыре, Выбор инструментов ревью: CodeRabbit — не единственный ответ, но текущий фактический бенчмарк
Сжатие трёхуровневой модели до уровня инструментов. Этот раздел решает только выборку для Layer 1 — Layer 2/3 в основном зависят от организации и процессов, инструменты здесь помогают незначительно.
CodeRabbit занимает верхнюю строчку в категории AI-ревью на GitHub Marketplace (оценка Series B — $550 млн в сентябре 2025, прогноз ARR $40 млн к Q2 2026, данные Sacra). Инструмент встраивает «AI-рецензента» прямо в поток комментариев к pull request: каждая рецензия содержит кликабельные пояснения, предложения по исправлению и уровень серьёзности. Особенно эффективен при выявлении слепых зон unit-тестов. Глубина интеграции с GitHub Actions максимальная, ценообразование ступенчатое по количеству PR, корпоративный план добавляет приватные модели, whitelist и внутреннюю базу знаний. Упомянутые показатели — 1,7× по дефектам и 1,82–2,74× по уязвимостям — взяты из собственного исследования CodeRabbit.
GitHub Copilot Review имеет смысл выбирать только при двух условиях: уже используется GitHub Enterprise и нет желания подключать нового вендора. Невозможность глубокой кастомизации правил — критический недостаток, который со временем приведёт к отставанию библиотеки правил от CodeRabbit.
Sourcery — ведущий инструмент автоматического код-ревью в экосистеме Python: он не просто выявляет ошибки в pull requests, но и предлагает готовые варианты рефакторинга, особенно эффективен при дополнении аннотаций типов и устранении технического долга. Для мультиязычных команд возможностей пока недостаточно — поддержка TypeScript и Go только появляется, а охват других языков остаётся ограниченным.
Cursor BugBot отличается тем, что видит контекст диалога непосредственно в редакторе Cursor — всё, о чём вы общались с ИИ, доступно боту для целенаправленного анализа сгенерированного кода. Однако эта функция работает только в проектах, открытых в Cursor.
Antigravity Review — встроенная возможность ревью на платформе Antigravity от Google, представленная в ноябре 2025 года; построена на модели Gemini 3 и обеспечена соответствием корпоративным стандартам Google Cloud. В первой половине 2026 года продукт активно развивается, хотя библиотека правил пока уступает CodeRabbit, а модели ценообразования и развёртывания для корпоративного сегмента ещё проходят доработку.
Критерии выбора располагаются в следующем порядке: настраиваемость правил > качество проверки PR > глубина интеграции > цена. При длительном использовании инструментов уровня 1 невозможность настройки правил означает полную зависимость от встроенной модели безопасности; низкое качество проверки PR (когда ИИ-рецензент лишь указывает «здесь что-то не так», не объясняя причин и способов исправления) — пустая трата времени разработчиков; глубина интеграции определяет затраты на освоение; цена занимает четвёртое место не потому, что неважна, — инструменты одного класса различаются по стоимости менее чем на 30%, тогда как расхождения по первым трём критериям значительно существеннее.
Два контрдовода к распространённым заблуждениям при выборе. Первое: для финансового сектора, госорганов, оборонной промышленности и ключевых областей телекоммуникаций приватное развёртывание или self-hosting — это пропуск на рынок. Однако приватное развёртывание не является финальной точкой: инструменты проверки требуют доступ к полному коду (diff пулл-реквеста и история репозитория), то есть код передаётся третьей стороне, что требует соглашения о поручении обработки данных (152-ФЗ §21 — поручение на обработку данных), одной лишь технической изоляции недостаточно. Второе: ИИ-предварительная проверка и ручная проверка — это не «или то, или другое» — комбинация двух инструментов уровня 1, таких как CodeRabbit и GitHub Copilot Review, в крупных организациях является нормой. У них разные правила и взаимодополняющий охват типов уязвимостей; у любого отдельного инструмента всегда есть слепые зоны.
Пять. Внедрение в четырёх отраслях: различные формы модернизации проверки в контексте каждого регуляторного режима
Телекоммуникации — повышение эффективности экспертизы изменений в тарифах и биллинге.
В материалах внутреннего обучения AI одного из региональных операторов мне встретилась наглядная схема: каждое изменение тарифного плана проходит 11 этапов от кодирования до запуска. AI сократил этап «кодирования» с 2 дней до 0,5 дня, однако пять других этапов — Change Advisory Board (CAB), алгоритмическая регистрация (касающаяся модели тарификации), аудит информационной безопасности по стандарту 等保, оценка трансграничной передачи данных (использовалась зарубежная модель, применялся отдельный негативный список вывода данных в сфере промышленности и информатизации согласно Правилам управления безопасностью данных в промышленности и информационной сфере, которые не могут быть заменены стандартным контрактом 152-ФЗ), а также сверка и аудит — каждый занимает от нескольких дней до месяца. При этом алгоритмическая регистрация от подготовки документов до обратной связи от Министерства промышленности и информатизации обычно занимает 4–6 месяцев — это действительно узкое место. Общий срок поставки практически не изменился.
Направление развития экспертизы: инструменты Layer 1 должны автоматически распознавать изменения в модулях тарификации, аутентификации или соответствия нормативным требованиям и помечать их как высокорисковые, направляя на совместное подписание владельцу бизнеса и ответственному за комплаенс в Layer 2. Уровень Change Advisory Board (CAB) проводит повторную экспертизу только для изменений, действительно затрагивающих регуляторную отчётность.
Суть этого подхода — сократить нагрузку Change Advisory Board (CAB) с 5 000–8 000 заявок в месяц (включая экстренные патчи) до 100–200 заявок в месяц на изменения, действительно требующие управления (высокий риск). До внедрения улучшений узким местом была пропускная способность Change Advisory Board (CAB); после — Change Advisory Board (CAB) стал самым быстрым этапом, поскольку 8 из 11 предшествующих этапов были автоматизированы или обрабатываются по правилам.
Самая скрытая боль в телекоммуникационной отрасли — не Change Advisory Board, а объяснимость модели. Модель биллинга должна объяснять источник тарифа для каждого счёта; после развёртывания AI‑модели типа «чёрный ящик» при поступлении жалоб от клиентов необходимо проводить отслеживание; когда срабатывают три основных сценария жалоб по номеру Роскомнадзор 利用者申立 (перенос номера, доступность счетов, управление приостановкой/возобновлением услуги), перед запуском сервиса требуется пройти предварительную проверку со стороны корпоративного отдела защиты прав потребителей, что не под силу Change Advisory Board.
Финансовый сектор — обновление процесса проверки кредитных моделей управления рисками. В банковских core-системах реальный путь запуска моделей управления рисками выглядит следующим образом: независимая валидация Группа валидации моделей (Model Validation Unit) → одобрение комитета по модельным рискам → подача заявки на регуляторную регистрацию бизнес-подразделением → обратная связь от регулятора → запуск в продуктивную среду после одобрения. Пять этапов выполняются строго последовательно, параллельное выполнение невозможно. Возможности ускорения написания кода с помощью ИИ здесь весьма ограничены (генерация скриптов, кода для feature engineering, кода предобработки данных), однако каждое изменение затрагивает регуляторные границы — модификация меток в Статье 24 «Правил управления интернет-кредитами коммерческих банков» и в документе CBIRC〔2020〕№ 24 квалифицируется как «существенное изменение модели, требующее повторной регистрации». Направление развития проверки: Level 1 должен обязательно распознавать «изменения в фичах, метках, пороговых значениях или весах модели» и принудительно маршрутизировать такие случаи в категорию высокого риска; Level 2 требует двойной подписи — ответственного за кредитные риски бизнес-подразделения и ответственного за данные и комплаенс, при этом Группа валидации моделей должен быть независим как от бизнес-подразделений, так и от ИТ-департамента (это жёсткое требование CBIRC〔2020〕№ 24); Level 3 предполагает прохождение валидации модели, отправку данных в системы ЦБ РФ 規制データ報告 и ЦБ РФ 規制データ報告, оценку на соответствие 152-ФЗ, а также проверку алгоритмической справедливости (пол, возраст и регион не должны использоваться в качестве переменных модели).
慢慢学AI<075>
Настоящая головная боль: после внедрения ИИ-инструмента для feature engineering в одном акционерном банке очередь на валидацию моделей выросла с 8 до 12 недель
Группа валидации моделей обязана в индивидуальном порядке контролировать дрейф PSI/CSI по признакам, сгенерированным искусственным интеллектом, однако взаимодействие с подразделением комплаенса данных сопряжено со значительным трением. Специалистам по валидации моделей необходим доступ к исходным распределениям признаков, но подразделение комплаенса данных, руководствуясь Федеральным законом №152-ФЗ «О персональных данных», запрещает прямой просмотр клиентских данных на уровне отдельных записей. Единственный допустимый путь — использование «песочницы валидации моделей» с агрегированными признаками, прошедшими предварительное обезличивание.
Прежде чем обсуждать инструменты, необходимо укомплектовать персоналом второй эшелон защиты. Какими бы мощными ни были средства автоматизации, без людей, которые одновременно разбираются в бизнес-логике и нормативных требованиях и способны проводить выборочные проверки, любая схема эскалации ревью остаётся пустой конструкцией без опоры.
Производство — повышение уровня ревью при изменениях MES. В производстве ИИ-кодинг вызывает большой интерес (интеграция конвейеров, модели контроля качества, диспетчеризация процессов), но изменения в MES часто затрагивают блокировки безопасности — сдвиг одного параметра способен остановить всю линию. Производственное ноу-хау глубже, чем кажется: вмешательство в связки OEE (общая эффективность оборудования) (Overall Equipment Effectiveness), контрольные карты SPC (статистическое управление процессами) (Statistical Process Control), логику прослеживаемости партий, процессы возврата и дозаправки — всё это зона высокого риска, и одного «порога процесса» здесь недостаточно. Направления апгрейда ревью: на уровне Layer 1 пометки «затрагивает блокировки безопасности / OEE (общая эффективность оборудования) / SPC (статистическое управление процессами) / прослеживаемость партий» должны получать статус максимального риска без права автоматического merge; на уровне Layer 2 обязательно совместное визирование технологом и инженером по безопасности; на уровне Layer 3 — пилотный прогон с раскаткой (сначала малая партия на одной линии, проверка отсутствия побочных эффектов на блокировках безопасности, затем расширение). Узкое место в этом секторе — люди на Layer 2: опытных технологов мало, их время съедает текущее производство, и апгрейд ревью по сути означает перераспределение ресурса — перенос их внимания с ежедневных обходов на разбор высокорисковых PR.
Электронная коммерция — ужесточение ревью в период промо-акций. В e-commerce выигрыш от ИИ-генерации кода наиболее заметен (фронтенд, маркетинговые правила, дашборды, логика рекомендаций), но изменения кода в период крупных распродаж затрагивают транзакционный контур, фрод-мониторинг и финансовые сверки — одна ошибка обходится в десятки миллионов. Подход к эскалации ревью: на уровне Layer 1 любые изменения модулей, связанных с промо, купонами, флеш-сейлами и стоком, помечаются как критический риск; на уровне Layer 2 требуется совместная подпись владельца продукта и владельца фрод-контура; на уровне Layer 3 обязательны раскатка на канареечный сегмент и полное нагрузочное тестирование. Специфика e-commerce — у акций есть окно: за две недели до и после распродажи (по модели «Чёрной пятницы», Prime Day или локальных аналогов) стандарты ревью строже обычного, при этом пропускная способность ревью как раз максимально перегружена продуктовыми задачами. Практический приём в этой отрасли — «расслабленно в обычное время, жёстко в боевом»: за неделю до промо-окна все высокорисковые изменения блокируются, допускаются только баг-фиксы; пропускная способность ревью целиком направляется на закрытие заблокированного бэклога, чтобы высокорисковые изменения не попали в окно распродажи.
Шесть. Что это значит для руководства
Обратная самопроверка. Ваша команда доверяет результатам работы ИИ всё больше или всё меньше? Как устроен ваш AI PR review — стопроцентная ручная проверка, выборочный контроль по уровню риска или молчаливое «пропускаем как есть»? Сколько раз за последние шесть месяцев сработал ваш маршрутизатор Layer 3? В скольких случаях он действительно выявил проблему, а в скольких — предотвратил инцидент? Если правление не получает эти три цифры, ваше управление ИИ — не более чем формальное соответствие регламентам на бумаге.
Урок первый: эволюция code review — это развитие организационных компетенций, а не техническая закупка.
CodeRabbit Pro стоит $24 за место в месяц (Pro Plus — $48 за место в месяц, тарификация по числу разработчиков, создающих PR). Для команды из 200 человек это около $58k в год, а корпоративная лицензия обходится ещё в 3–5 раз дороже — на фоне R&D-бюджетов в миллионы долларов это мелочь. Настоящая стоимость — в том, что на уровне Layer 2 нужно укомплектовать команду людьми, а на уровне Layer 3 — перепроектировать процессы. Эти вещи нельзя купить за деньги: нужна готовность организации меняться и готовность старших инженеров выделять время на ревью. Те, у кого продвижение code review не идёт, почти всегда подходят к нему как к IT-проекту: покупают лицензию, раздают инструменты, ставят KPI. Те, у кого получается, сажают за один стол руководителя разработки и комплаенс-менеджера, чтобы вместе выработать правила маршрутизации PR. Это и есть бюджетный сигнал о переводе governance из cost center в актив полосы пропускания — только тогда деньги смещаются с «купить ещё лицензий» на «добавить bandwidth на ревью».
Урок второй: прежде чем подключать автономных агентов, AI pre-review должен быть уже выстроен. Это оборотная сторона принципа «сначала тормоза, потом двигатель». Автономные агенты вроде Claude Code или Codex способны за один заход переписать十几个 файлов, открыть pull request и выполнить shell-команды. Но пока такие возможности не станут штатными, Layer 1 обязан распознавать «какой модуль затронут, какие границы пересечены» и принудительно маршрутизировать изменения на соответствующий уровень ревью. В качестве измеримого ориентира зрелости предлагаю: автоматический merge на Layer 1 — ≥95 %, выборочная проверка на Layer 2 — ≥20 %, ноль инцидентов уровня P0 на протяжении трёх месяцев подряд. Сэмпл Карлини — компилятор C на 100 000 строк на Rust — не так уж далёк от типичной корпоративной реальности: автономный агент может за две недели выдать production-ready проект, а организация без выстроенного ревью за те же две недели накопит двадцать тысяч production-ready рисков. Ещё более сопоставимый отраслевой пример — агент «Minions» в Stripe: каждую неделю он мерджит около 1 300 PR, при этом ноль строк кода пишется человеком, человек только ревьюит. Полностью автоматическая генерация кода AI плюс человеческое review-only — это и есть признак зрелой эскалации ревью.
Урок третий: и выигрыш, и потери от эскалации ревю считаются в одной единице — пропускной способности. Переопределим термин «review bandwidth» — это не просто человеко-часы за столом ревью, а суммарная способность организации распознавать, маршрутизировать и обрабатывать риски. В отчёте CodeRabbit показатель «автоматически отсечено большинство явных проблем» охватывает лишь часть картины; по-настоящему эффективное использование AI зависит от того, получает ли оставшаяся доля скрытых рисков (архитектурное выравнивание, комплаенс-границы, корректность бизнес-логики) достаточно человеческого ресурса на уровнях Layer 2 и Layer 3.
Самая частая модель провала при эскалации ревю — разрешить AI автоматически мержить PR. Ради того, чтобы «эффективность AI выглядела заметнее», правила Layer 1 тихо ослабляют, Layer 2 переводят на выборочную проверку 5%, а Layer 3 превращают в формальность. В краткосрочной перспективе цифры красивые, в долгосрочной — растёт число инцидентов: AI пишет быстрее + ревью ослаблено = технический долг увеличивается пропорционально. Двойной сигнал — CodeRabbit ×1,7 по дефектам в сочетании с ростом привилегированных доступов на 322% по данным Apiiro — это совокупная цена именно такого «раскрепощения», а не провал в одной конкретной точке. Пропускная способность ревю должна масштабироваться вместе с объёмом PR; любой дисбаланс — путь к потере контроля.
Контрольный список внедрения за 30 дней (с уровнем детализации «о каком совещании в понедельник речь и какой документ править»):
Неделя 1: Провести аудит текущих правил маршрутизации PR и пометить красным четыре категории — изменения schema / auth / billing / комплаенс. Выгрузить данные за последние 90 дней: сколько раз срабатывал Layer 3 и каково среднее время ожидания в очереди — это станет baseline.
Неделя 2: Подключить инструмент Layer 1 (CodeRabbit или GitHub Copilot Review — один из двух, при жёстком требовании on-premise развёртывания остальные варианты отсеиваются), сконфигурировать правила. В шаблон PR добавить чекбокс ручного выбора уровня риска.
Неделя 3: Сформировать пул Layer 2 — бизнес-владельцы + владельцы по комплаенсу, определить долю выборочной проверки spot-check (рекомендуется 20–30%). Довести файл CODEOWNERS до полного покрытия по модулям.
Неделя 4: Вывести в еженедельный отчёт PMO пять метрик — среднее время ревью PR, долю неудачных изменений, долю пропущенных дефектов после ревью, среднее время ожидания в очереди на Layer 2/3, число комплаенс-инцидентов, инициированных маршрутизацией на Layer 3. Параллельно установить пороги допуска к автономным агентам: pass-rate Layer 1 ≥ 95 %, охват выборочной проверки Layer 2 ≥ 20 %, ноль P0-инцидентов подряд в течение трёх месяцев.
Сопутствующие метрики не должны отставать
PR average review time, change failure rate, post-review defect escape rate, average Layer 2/3 queue time, number of compliance events triggered by Layer 3 routing, model validation queue time. В конце AI173 я уже отмечал: многие крупные компании на уровне совета директоров докладывают об ROI ИИ-программирования через метрики вроде «сколько разработчиков охвачено» и «сколько лицензий куплено» — именно так и прячутся реальные узкие места. Стоит вынести на уровень совета директоров перечисленные выше показатели (а не число лицензий и строк кода), и бюджет начнёт смещаться с «купить ещё лицензий» на «усилить полосу пропускания ревью».
Управление теневым ИИ — синхронно с основным контуром
По данным отчёта UpGuard за 2025 год, речь идёт о «сотрудниках по всему миру, использующих неутверждённые генеративные ИИ-инструменты» — и речь не только о разработчиках. Около 80% сотрудников признаются, что применяют ИИ-инструменты без одобрения ИТ-службы. Бизнес-подразделения в обход ИТ пишут код в ChatGPT — именно это сегодня больше всего беспокоит специалистов по комплаенсу. Совершенствовать управление без параллельной работы с теневым ИИ — всё равно что контролировать только «задекларированное оружие», игнорируя «незадекларированное».
Неприменимые сценарии: если в вашей команде меньше 50 человек, вы не работаете в жёстко регулируемой отрасли, не имеете дела с автономными агентами и выпускаете менее 100 PR в месяц — как минимум 60% суждений из этой статьи к вам напрямую неприменимы. Не пытайтесь втиснуть себя в предложенную структуру — достаточно двух уровней: инструменты Layer 1 плюс ключевые spot-check.
Что дальше
Следующий выпуск (AI175) посвящён инструментальному слою: битва за AI-инструменты в 2026 году уже закончилась, но вопрос «а воспользуется ли победитель плодами победы?» — совсем другая история. Речь пойдёт о двух претендентах на трон (Claude Code / Codex), Copilot, который удерживается за счёт инерции закупок, и стартующем Antigravity — а также о том, как именно зрелость governance определяет, кому и на каком уровне эти инструменты доступны. AI174 даёт структуру для эскалации ревью, AI175 — структуру для выбора инструментов; вместе они складываются в целостную картину «после того как AI пишет код — как организация это принимает».
Прочитав этот выпуск, рекомендую сразу перейти к разделу 3 AI173 (о новых узких местах) плюс раздел X AI175 (соответствие зрелости governance и возможностей инструментов) — три ключевых суждения распределены по трём выпускам.
Хотите применить эти выводы в своей компании?
Медленно учим AI: когда AI-инструменты для кода заходят в корпоративную среду
Когда AI-инструменты для программирования заходят в корпоративную среду, реальные вопросы обычно одни и те же: справится ли существующий процесс code review с объёмом, который генерирует AI; сколько людей нужно выделить на Layer 2 (в пересчёте на PR / число модулей / долю FTE); нужно ли перепроектировать Change Advisory Board (CAB) и процедуру регистрации на Layer 3; какими метриками принимать пилот.
С чего начать диагностику. Посмотрите на пять чисел: среднее время ревью PR, долю неудачных изменений (change failure rate), долю дефектов, которые проскочили ревью, среднее время ожидания на Layer 2 и Layer 3, а также число инцидентов комплаенса, сработавших по правилам маршрутизации Layer 3. Если хотя бы одно число не получается достать — вы ещё не готовы к AI pre-review инструменту.
Сейчас предлагаю три формата сотрудничества.
Корпоративное обучение. Берём ваши реальные проекты и проходим всю трёхуровневую модель AI-ревью: выбор Layer 1 (сравнение CodeRabbit, GitHub Copilot Review и т. п. по четырём осям — приватное развёртывание, возможность кастомизации правил, глубина интеграции, цена), перепроектирование процессов Layer 2 и Layer 3 и связанную систему метрик. На выходе: ① оценка текущего состояния команды (насколько загружена полоса ревью); ② дорожная карта внедрения трёхуровневой модели на 3–6 месяцев; ③ дерево решений для выбора инструмента Layer 1; ④ черновик приборной панели метрик. 3 дня ≈ ¥90 000.
（Примечание переводчика: ¥90 000 — это сохранённая из оригинала цена в юанях, без пересчёта по курсу; если вам нужна оценка в евро/рублях, укажите целевой рынок.）
Экспертные консультации: фокус на одном конкретном решении — например, оценка внедрения CodeRabbit, адаптация трёхуровневой модели ревью к условиям жёсткого регулирования (в финсесе — независимая команда минимально жизнеспособного продукта (Группа валидации моделей) с полной цепочкой аудита, в телекоме — регистрация алгоритмов в регуляторе и обработка жалоб по линии Роскомнадзор 利用者申立), перенастройка ритма существующего Change Advisory Board (Change Advisory Board (CAB)) под AI-PR. Цены формируются вокруг темы решения (консультационный пакет 5–15 часов). Итоговые материалы: протокол решения + чек-лист внедрения + одна неделя сопровождения. ¥5 000 / час.
Индивидуальный коучинг / закрытая группа для руководителей: для вице-президентов, директоров и старших инженеров, которые «серьёзно инвестируют в собственное развитие». Вы уже пользуетесь AI-инструментами для программирования и хотите вырастить внутри своей организации компетенции по апгрейду ревью, управлению командами и межфункциональным переговорам. 12 сессий / 6 месяцев, цена привязана к тематике. Итоговые материалы: протоколы коучинговых бесед + поэтапный разбор действий. ¥180 000–360 000.
Выступления для руководства и отраслевые доклады: темы — AI-ревью, организационное управление, корпоративная AI-трансформация и изменения в разработке ПО. Формат — полдня или целый день, в зависимости от запроса организатора.
Статья задаёт общую рамку. Конкретное внедрение требует отдельного проектирования с учётом границ данных, регуляторных требований, инженерной зрелости и существующих процессов ревью в компании. Связаться для сотрудничества: coach@iaiuse.com.
Дополнительное чтение: «Методология “Вывеска” v1.0» (Учим ИИ медленно 187) — системное описание 7-шагового фреймворка корпоративной AI-трансформации.
О серии
«Трансформация разработки ПО в эпоху ИИ» — это исследовательская серия для CIO, CDO, CTO и руководителей цифровой трансформации в телекоме, финансах, промышленности и e-commerce. В фокусе — как AI-инструменты для программирования меняют процессы поставки ПО, оргструктуру, механизмы governance и метрики управления.
За этим каналом стоит небольшая команда — я и 1–2 давних коллеги. Мы распределяем между собой исследование AI-инструментов для разработки, работу с кейсами организационного governance и коучинговые диалоги. Большинство проектов, о которых мы пишем «мы сопровождали компании», — результат нашей совместной работы.
Серия постоянно отслеживает академические статьи, материалы вендоров и отраслевые отчёты; исследовательская база превышает 200 источников. Для ключевых утверждений мы указываем уровень доказательности, стараясь разделять подтверждённые факты, заявления вендоров, отраслевые наблюдения и авторские умозаключения.
У меня почти 8 лет опыта консалтинга и бизнес-анализа в крупных корпорациях, включая IBM, с проектами в телекоме, финансах, страховании и промышленности. После этого я продолжил работу на «передовой» — продуктовая разработка у оператора связи, интернет-продукты и AI-приложения: требования, продуктовый дизайн и кросс-командное внедрение.
Все суждения в этой серии — об эскалации ревью, организационном управлении и перепроектировании процессов — опираются на эти практики и перекрёстно подтверждаются публичными исследованиями и отраслевыми кейсами. Сведения о конкретных проектах обезличены; часть отраслевых сценариев смоделирована на основе типовых проблем, перечень источников приведён в конце.
Источники (по каждому пункту: выходные данные + уровень доказательности + позиция автора)
CodeRabbit State of AI vs Human Code Generation Report (17.12.2025, первичный источник, позиция вендора): проанализировано 470 PR в open-source-репозиториях на GitHub (AI против ручного кода, без попарного сопоставления по размеру/сложности файлов). Совокупный показатель дефектов — 1,7× (в среднем 10,83 на PR против 6,45); уязвимости по подкатегориям — от 1,57× до 2,74×: XSS — 2,74×, некорректная обработка паролей — 1,88×, небезопасные прямые ссылки на объекты (IDOR) — 1,91×, небезопасная десериализация — 1,82×; логика/корректность — 1,75× (тяжёлые — 75%), качество кода — 1,64×, производительность — 1,42×, читаемость — свыше 3×, форматирование — 2,66×, обработка ошибок — около 2×, избыточный ввод-вывод — около 8×. Исследование проведено самой CodeRabbit, поэтому позиция вендора учтена; выборка и методология раскрыты. https://www.coderabbit.ai/whitepapers/state-of-AI-vs-human-code-generation-report / материал The Register от 17.12.2025.
Apiiro, 04.09.2025 (позиция вендора): сканирование репозиториев компании из списка Fortune 50 (данные за декабрь 2024 – июнь 2025). Ежемесячное число находок безопасности в AI-сгенерированном коде выросло с примерно 1 000 до более чем 10 000 (10-кратный рост по абсолютному числу), уязвимости эскалации привилегий +322% (в абсолютных значениях), архитектурные дефекты на уровне дизайна +153%; в нормализованном выражении с поправкой на рост объёма кода оценка роста составляет примерно 60–80%. Синтаксические ошибки снизились на 76%, логические баги — на 60%. Освещение в The Register, Cloud Security Labs и SiliconANGLE.
JetBrains AI Pulse Survey, январь 2026 (первичное исследование): более 10 000 профессиональных разработчиков, 8 языков. 90% разработчиков используют хотя бы один AI-инструмент; 70% применяют от 2 до 4. https://blog.jetbrains.com/research/2026/08/ai-coding-agent-adoption-2026/
Pragmatic Engineer Newsletter (февраль 2026 г., первоисточник): около 906 респондентов, охват — 150 000 читателей; 56% опытных инженеров заявили, что более 70% их инженерной работы зависит от AI-инструментов (самооценка интенсивности использования, а не доля в строках кода); Claude Code — 46% как самый популярный (против Cursor 19%, Copilot 9%); в компаниях до 10 000 сотрудников 75% выбирают Claude Code, в компаниях свыше 10 000 — 56% выбирают Copilot. https://newsletter.pragmaticengineer.com/p/ai-tooling-2026
GitHub Octoverse 2024 / 2025 (первичный источник): согласно отчёту Octoverse 2025, Copilot coding agent за пять месяцев (май–сентябрь 2025 г.) создал более 1 млн PR; 80% новых разработчиков используют Copilot в первую неделю работы. «Доля PR с участием AI 40–60%» — отраслевая оценка, а не прямые данные Octoverse. По материалам GitHub Engineering Blog и The New Stack.
Stripe Minions (март 2026, из первых рук): агенты Stripe «Minions» каждую неделю мерджат около 1 300 PR, при этом человеку остаётся только code review — ни строчки кода вручную; именно полностью автоматическая генерация AI в связке с review-only человеком и есть отличительная черта этой модели. 500+ MCP-инструментов, devbox на AWS EC2, стратегия ветвления Block Goose. https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents / репортаж InfoQ от 20.03.2026.
Система Skills от Anthropic (январь 2026 г., первоисточник, позиция вендора): Anthropic опубликовала проектную документацию по Skills — в основе лежит модульность исполнителя задач (modular folders that teach Claude specific tasks — структура «папка + skill-файл + progressive context loading»), что не имеет отношения к маршрутизации pull request’ов. Защиту PR на уровне отрасли обычно обеспечивают механизмы GitHub/GitLab — branch protection + правила CODEOWNERS, маршрутизирующие pull request’ы по пути файла и назначенному Codeowner’у. Источник: Anthropic Engineering Blog.
Carlini / Anthropic (январь–февраль 2026, уровень 1, первичное исследование): исследователь Anthropic Николас Карлини (Nicholas Carlini) запустил 16 агентов Claude Opus 4.6 параллельно на две недели — около 2000 сессий и примерно 20 000 долларов расходов на API, — и с нуля написал компилятор языка C на основе Rust объёмом 100 000 строк. Компилятор собирает ядро Linux 6.9 (архитектуры x86, ARM и RISC-V) и проходит 99% тестов из GCC torture suite. Это закрытое исследование: до продакшена не доведено, механизмы ревью кода отсутствуют. Подробности освещали The Register (9 февраля 2026) и Ars Technica (февраль 2026).
Обновлённое исследование METR, февраль 2026 года (уровень достоверности I, требует проверки): раннее исследование охватывало 16 опытных разработчиков и 246 реальных задач с использованием Cursor Pro и Claude 3.5/3.7 Sonnet. По его результатам, ИИ замедлял работу на 19% (95% ДИ: 2–39%), хотя участники субъективно полагали, что работали быстрее на 20%. В последующем исследовании METR от февраля 2026 года представлена более неоднозначная картина: у новых разработчиков зафиксировано ускорение на 4%, а по части опытных разработчиков результаты отчасти изменились на противоположные. Методику расчётов необходимо дополнительно сверить с первоначальным отчётом METR. https://metr.org/blog/2026-02-24-uplift-update
Microsoft FY26 Frontier Suite / Кейс EY (первоисточник, со стороны вендора): EY развернула Microsoft 365 Copilot на 150 000 сотрудников и зафиксировала рост продуктивности на 15% (что эквивалентно примерно 14 часам в неделю на человека, высвобожденным для работы с клиентами и обучения); затем планируется тиражирование на более чем 400 000 сотрудников. В сценарии финансовых операций, реализованном на базе Microsoft Power Platform + Copilot Studio, сквозной lead time сократился на 95%, а операционные затраты — на 37% (речь именно о финансовых операциях, не об универсальном показателе по всей компании). Источник: Microsoft Customer Story 25760 / FY26 Investor Page.
Развёртывание Atos Agent 365 (июнь 2026 г., первичный источник, позиция вендора): Atos развернула Microsoft 365 Copilot на 56 000 сотрудников в 54 странах и использует Agent 365 для управления 19 000 внутренних AI-агентов; по заявлению самой Atos, «governance и безопасность — это первый рубеж agentic AI». Microsoft News, 9 июня 2026 г. / CDO Magazine.
Автономные агенты Anthropic Claude Code и OpenAI Codex (первичный источник, позиция вендоров): Claude Code способен самостоятельно редактировать более десятка файлов, выполнять shell-команды, управлять Git и создавать pull request’ы; Codex умеет распараллеливать работу нескольких sub-agent’ов в изолированных копиях и затем объединять результат. Инженерная документация Anthropic / OpenAI.
CodeRabbit — основные показатели компании (2025–2026, первичные источники): лидер рынка AI-инструментов для ревью в GitHub Marketplace; оценка Series B в сентябре 2025 — около 550 млн долларов; ARR в 2025–2026 вырос почти в 10 раз, до примерно 40 млн долларов (Q2 2026, данные Sacra); тарифы Pro — $24 за место в месяц, Pro Plus — $48 за место в месяц (биллинг по разработчикам, создающим PR). Данные подтверждены несколькими источниками: Sacra, Reuters, TechCrunch. https://sacra.com/c/coderabbit
GitHub Copilot Review / Sourcery / Cursor BugBot / Antigravity Review (первичные, позиция вендора): официальная документация и продуктовые страницы ведущих инструментов ревю уровня Layer 1 — для сопоставления покрытия, гибкости настройки правил и глубины интеграции. Antigravity стал общедоступен 18 ноября 2025 (GA), по сообщениям VentureBeat и PCMag.
История code review (уровень 1): два основных истока — ① Weinberg, 1971, «The Psychology of Computer Programming», где сформулирована концепция egoless programming (автор работал в NASA Goddard Space Flight Center и преподавал в Университете Небраски, к IBM отношения не имел); ② IBM Fagan Inspections, систематизированные Майклом Фэганом в IBM в 1976 году (сам Фэган был сотрудником IBM). Обе традиции развивались параллельно. Это историческая точка отсчёта для сравнения классического ревью с ревью в эпоху ИИ.
Финансовое регулирование (первоисточники): ст. 24 «Правил управления интернет-кредитованием коммерческих банков» (КНР) и «Руководство по управлению рисками интернет-кредитования коммерческих банков» (ЦБ РФ 通知〔2020〕24) — три линии обороны в управлении моделями (бизнес, ИТ, комплаенс-аудит) + независимая Группа валидации моделей + повторная регистрация при существенных изменениях модели; ЦБ РФ 規制データ報告 (Examination Analysis System — система анализа проверок НБК, ежемесячные пакеты) + отчётность по форме ЦБ РФ 規制データ報告; проверка персональной кредитной истории Народным банком Китая + аудит алгоритмической справедливости (ограничения на переменные «пол / возраст / регион»). Для ориентира российскому читателю: по духу это ближе всего к требованиям ЦБ РФ к моделям в банковском риск-менеджменте (Положения 590-П, 611-П) и практикам ВАР в рамках 716-П.
参考 по телекоммуникационному регулированию (первоисточник): Правила регистрации алгоритмов Министерства промышленности и информационных технологий КНР (двойной надзор за алгоритмами, связанными с биллингом и финансовыми сервисами); оценка соответствия классу защиты (Приказ ФСТЭК № 21/239 (6 级 защиты), dingbao ceping — китайская система сертификации информационной безопасности, схожая с ISO 27001/SOC 2) — класс 2: 30 рабочих дней, класс 3: 45 рабочих дней; три главные категории жалоб на горячую линию Роскомнадзор 利用者申立 (перенос номера между операторами, доступность счёта, управление приостановкой и восстановлением услуги); негативный список трансграничной передачи данных согласно «Временным мерам по управлению безопасностью данных в области промышленности и информационных технологий» (《工业和信息化领域数据安全管理办法（试行）》).
Передача обработки данных по 152-ФЗ (первоисточник): статьи 21 и 55 Закона КНР «О защите персональной информации» (《个人信息保护法》) — соглашение с третьей стороной-обработчиком и срок хранения журналов 3–5 лет (в зависимости от отрасли). По европейским меркам этот режим сопоставим с обязанностями обработчика по GDPR (ст. 28) и DPA-контрактами.
Stack Overflow Developer Survey 2025 (первоисточник): опрос свыше 49 000 разработчиков. Доля разработчиков, доверяющих точности результатов ИИ, снизилась с 40 % в 2024 году до 29 % в 2025-м (падение на 11 п.п.); при этом 46 % разработчиков активно не доверяют результатам ИИ (против 31 % в 2024-м). Code churn (доля кода, переписанного в течение двух недель после написания) вырос с 3,1 % в 2020 году до 5,7 % в 2024-м. https://survey.stackoverflow.co/2025/
Теневая AI (UpGuard 2025, уровень 2): 80% сотрудников по всему миру используют несанкционированные инструменты генеративного AI (не только разработчики), 68% руководителей по безопасности признают использование несанкционированного AI. Усиление управления без параллельной работы с теневым AI — слепое пятно в комплаенсе. https://www.upguard.com/resources/the-state-of-shadow-ai
Собственные примеры автора (деидентифицированы): ① AI-тренинг для сотрудников регионального оператора связи (Q4 2024, разбор 11 контрольных точек, деидентифицировано); ② обсуждение апгрейда системы кредитного скоринга в одном из акционерных банков Китая (H1 2025, деидентифицировано); ③ редизайн процесса ревью изменений MES на крупном производственном предприятии (H2 2025, деидентифицировано); ④实战 крупной распродажи на ведущей e-commerce платформе (Double 11 / 11.11 2025, деидентифицировано).
Пояснение по деидентификации кейсов: упомянутые в материале примеры из телеком-, финансового, производственного и e-commerce секторов основаны на опыте автора по проведению AI-тренингов и сопровождению команд цифровой трансформации у оператора связи; отраслевые фрагменты представляют типовую проработку проблем, а не результаты конкретных клиентских проектов. При любом цитировании просьба указывать, что данные деидентифицированы.
buymeacoffee
![[Ревью кода] Ревью кода в эпоху ИИ — кто проверяет код, который пишет ИИ? Трансформация разработки ПО в эпоху ИИ — Учим ИИ медленно 174](https://cdn.iaiuse.com/img/2026/08/21/0459c8c3e952e37ec8e0f85245d6701b.webp)
