ИИ ускорил разработку. Как бизнесу теперь проверять качество продукта

Мы как компания, которая занимается разработкой цифровых продуктов и ИИ‑решений, разумеется, используем ИИ для ускорения разработки. Например, ИИ‑помощников, которые помогают быстрее собирают черновики решений, создать несколько вариантов реализации. В каких‑то задачах это помогает создать production‑ready решение в несколько раз быстрее.

Казалось бы, больше сделанных задач, быстрее собранные фичи, меньше времени на рутину. Но довольно быстро мы столкнулись с другой стороной процесса: код стал появляться быстрее, чем команда успевает его спокойно и внимательно проверять вручную.

Эта ситуация характерна для индустрии в целом. По данным отчета GitHub Octoverse 2025, активность разработчиков заметно выросла. GitHub — крупнейшая платформа, где разработчики хранят код, вносят изменения и предлагают их для включения в основные версии проектов. Поэтому по ее данным, на мой взгляд, можно судить о том, как меняется поведение команд разработки.

В 2025 году количество запросов на включение изменений в проект (также MR — merge requests или PR — pull requests) выросло на 20,4%. Такой запрос появляется, когда разработчик написал часть кода и предлагает добавить ее в главную ветку репозитория — основное хранилище программного кода, из которого команда собирает новые версии продукта. Количество отправленных изменений в хранилище кода выросло примерно на 25%. Это действие можно представить как сохранение новой версии работы в общей системе, где ее видит команда.

Сам GitHub осторожно говорит, что эти цифры показывают общий рост активности, но не доказывают напрямую, что он произошел только из‑за ИИ. На разработку могли повлиять и другие факторы. Но по времени этот рост совпадает с массовым внедрением ИИ‑сервисов, которые помогают быстрее писать код. Поэтому для бизнеса это сигнал: поток изменений в разработке становится плотнее, а значит, нагрузка на проверку кода тоже растет. По нашему опыту, это действительно так.

Как проверяли код раньше

Разработчик получал задачу и делал изменения не сразу в основной версии продукта, а в отдельной копии кода. Это было нужно, чтобы новая функция или исправление не повлияли на уже работающий продукт, пока их не проверили.

Когда разработчик заканчивал работу, он отправлял запрос: можно ли добавить эти изменения в основную версию кода. Дальше другой разработчик, тимлид или ответственный за проект смотрел, что именно поменялось, не сломается ли из‑за этого существующая логика, нет ли очевидных ошибок и можно ли будет поддерживать это решение дальше.

Если все было в порядке, изменения одобряли, и они попадали в основную версию кода, из которой потом собирали продукт для пользователей. Если появлялись вопросы, автор получал комментарии и дорабатывал решение.

На уровне схемы этот процесс выглядит надежно. В нем есть разделение ролей: один пишет, другой проверяет. Есть возможность поймать ошибку до релиза и обучение внутри команды: более опытные разработчики объясняют менее опытным, почему лучше сделать иначе. Есть защита от случайных решений, которые могут навредить продукту.

На практике код‑ревью всегда было сложной историей. У ревьюера есть свои задачи. У лида есть встречи, планирование, ответственность за сроки, коммуникация с заказчиком, помощь команде. Если ревью занимает много времени, оно начинает конкурировать с остальной работой. А если релиз близко, появляется соблазн посмотреть быстрее.

Еще есть человеческая часть. Замечание к коду — это чувствительная зона. Даже если команда профессиональная и взрослая, автор может воспринимать комментарий как оценку своей компетентности. Иногда два сильных специалиста спорят, потому что у них разные представления об архитектуре. Иногда люди начинают обсуждать правки в комментариях, иногда уходят в личные сообщения, чтобы не выносить конфликт в общий тред. Поэтому честно будет сказать: код‑ревью и раньше не всегда было идеальным.

Что изменилось с вайб‑кодингом

Вайб‑кодинг снижает стоимость первой версии кода. Разработчик быстрее получает черновик, быстрее проверяет гипотезу, быстрее собирает интерфейс, быстрее пишет вспомогательные функции, быстрее пробует альтернативный подход.

Если раньше у тимлида висели один‑два запроса на слияние, он мог выделить время и посмотреть их подробно. Когда таких запросов становится десять или двадцать за день, старый подход начинает трещать.

Ревьюер физически не может одинаково глубоко смотреть все изменения. Он начинает расставлять приоритеты. Где‑то смотрит внимательно, где‑то доверяет автору, где‑то ограничивается тем, что тесты прошли.

В системе задач при этом все может выглядеть корректно: запрос на слияние создан, ревью назначено, одобрение получено, время списано. Но руководителю важно понимать, что формальный след процесса не всегда равен реальному контролю.

Новые подходы к проверке кода

Самый очевидный подход — попросить ту же модель проверить код, который она помогла написать. Разработчик описывает задачу, получает решение, а потом просит ИИ найти ошибки, улучшить структуру, добавить тесты или объяснить риски.

Такой подход полезен как быстрая самопроверка. Он помогает поймать очевидные недочеты, увидеть лишний код, попросить модель еще раз пройтись по краевым случаям. Но полагаться только на него рискованно. По нашему опыту, модель часто не замечает собственные ошибки и подтверждает неудачные решения или слишком уверенно объясняет, почему все в порядке. Для выпуска в продукт этого недостаточно.

Второй подход — использовать отдельные сервисы автоматической проверки кода. Они подключаются к хранилищу кода, смотрят изменения и оставляют комментарии: где может быть ошибка, где нарушен стиль проекта, где не хватает тестов, где есть риск для безопасности или поддержки. По сути, это дополнительный проверяющий, который делает первый проход до человека.

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

У них тоже есть ограничения, например, безопасность. У нас есть проекты под NDA, где нельзя отправлять код во внешний сервис, даже если он удобный и хорошо работает. Иногда есть ограничения по трансграничной передаче данных или заказчик прямо запрещает выносить код или части контекста за пределы согласованного контура.

К тому же, есть экономический фактор. Проверка кода через ИИ стоит денег. Если отправлять в модель все подряд, расходы могут быстро стать непрозрачными. Для бизнеса важно понимать, какой контекст передается на проверку, как он сокращается, где можно экономить без потери смысла, какие запросы действительно требуют глубокой проверки.

Для себя мы выбрали подход, при котором ИИ‑агент помогает проверять код до того, как к нему перейдет человек. Такой агент не заменяет ответственного разработчика и не принимает финальное решение, но снимает часть рутинной нагрузки: находит типовые проблемы, оставляет комментарии, готовит краткое описание изменений и помогает быстрее понять, где нужна особенно внимательная проверка.

Какие есть способы повысить контролируемость кроме проверки кода

Автоматическая проверка кода помогает снизить нагрузку на команду. Например, ИИ‑агент может первым посмотреть изменения, найти типовые проблемы, оставить комментарии и показать ревьюеру, где нужно быть внимательнее. Но сама по себе такая проверка не решает другой важный вопрос: что ИИ вообще разрешено делать.

Это особенно важно, если ИИ получает доступ к рабочей среде, может читать файлы проекта, запускать команды, менять настройки, работать с базами данных или инфраструктурой. В таком сценарии компании нужны защитные ограничения, которые не дают случайной ошибке превратиться в серьезный инцидент.

В разработке такие ограничения называют guardrails. По сути, это ограждения вокруг опасных действий. Они нужны и людям, и ИИ. Человек тоже может ошибиться, удалить не тот файл, запустить команду не в той среде, перепутать тестовую базу с рабочей. Разница в том, что ИИ может сделать это очень быстро и уверенно, а потом так же уверенно объяснить.

Поэтому недостаточно написать в инструкции для агента: «Не удаляй важные данные», «Спроси перед опасным действием», «Не делай ничего разрушительного». Такие просьбы полезны, но они не заменяют настоящих ограничений. Если у агента есть техническая возможность удалить рабочую базу данных и резервные копии, риск остается.

На мой взгляд, более надежный подход — не давать таких прав по умолчанию. Например, агенту для проверки кода обычно не нужен доступ к изменению продакшн‑инфраструктуры.

Ему не нужно право удалять данные, менять боевые настройки или выполнять команды, которые могут повлиять на пользователей. Его задача — анализировать изменения, комментировать код, подсвечивать риски и готовить материал для человека. Значит, права должны соответствовать этой задаче.

Чек‑лист: что спросить у команды разработки, если она использует ИИ

Где мы разрешаем использовать ИИ в разработке? Есть задачи, где ИИ‑помощник дает хороший эффект и не создает существенных рисков: помогает собрать черновик интерфейса, написать вспомогательную функцию, предложить вариант теста, объяснить ошибку.

А есть зоны, где цена ошибки выше: платежи, персональные данные, авторизация, права доступа, безопасность, инфраструктура. В таких местах важно заранее понимать, можно ли использовать ИИ свободно, можно ли использовать его только после согласования или нельзя давать ему определенный контекст вообще.

Кто проверяет код, написанный с помощью ИИ? Для нас принципиально, чтобы у каждого изменения был человек, который понимает, что попадает в продукт.

Даже если значительную часть кода помог написать ИИ, финальное решение не должно растворяться в формулировке «так предложила модель». Если изменение влияет на пользователей, деньги, данные или безопасность, его должен посмотреть ответственный разработчик.

Какие изменения мы считаем рискованными? В каждом продукте есть участки, где ошибка особенно дорога. Где‑то это оплата, где‑то личный кабинет, где‑то база клиентов, интеграции с внешними сервисами, отправка уведомлений или система ролей для сотрудников.

Такие изменения нельзя проверять по той же логике, что и мелкие визуальные правки. Для них нужен более внимательный маршрут: больше контекста для ревьюера, отдельная проверка, иногда участие лида или нескольких специалистов.

Какие права получает ИИ? Это один из самых важных пунктов. Если агент помогает проверять код, ему обычно не нужны права менять рабочую инфраструктуру, удалять данные, работать с боевой базой или выполнять команды, которые могут повлиять на пользователей.

Мы исходим из принципа, что инструмент должен получать только те права, которые нужны для его задачи. Если действие потенциально опасное, оно должно требовать отдельного доступа, подтверждения человека и понятного обоснования.

Что нельзя отправлять во внешние ИИ‑сервисы? В разработке может быть код под NDA, коммерческая тайна, данные клиентов, внутренняя документация, переписка с заказчиком. Если такие данные без правил попадают во внешний сервис, это уже не только технический, но и юридический риск. Поэтому важно заранее разделить контекст: что можно использовать в ИИ‑инструментах, что можно только в закрытом контуре, а что нельзя передавать вообще.

Как мы проверяем, что ИИ не добавил лишнее? Модель может предложить решение, которое выглядит рабочим, но тянет за собой ненужную библиотеку, устаревший подход, лишнюю сложность или неочевидный риск для поддержки.

Бизнесу не нужно разбираться в этих деталях самостоятельно, но в процессе должен быть человек или автоматическая проверка, которые отдельно смотрят новые зависимости, изменения в безопасности, платежах, доступах и работе с данными.

Что мы делаем с большими изменениями? Чем больше кода попадает на проверку одним куском, тем выше риск формального ревью. Человеку сложнее внимательно разобрать большой объем, особенно если у него параллельно свои задачи.

Поэтому большие изменения лучше дробить на части или хотя бы сопровождаем объяснением: что поменялось, зачем это сделано, какие зоны затронуты и где ревьюеру нужно быть особенно внимательным.

Кто отвечает, если после релиза что‑то сломалось? Важно, чтобы у каждого изменения был владелец: человек, который понимает, почему изменение выпустили, кто его проверил и как действовать, если возникла проблема. ИИ может быть участником процесса, но ответственность должна оставаться в человеческом контуре.

Не нарушаем ли мы права авторов библиотек с открытым исходным кодом? В разработке часто используют библиотеки и открытые программные компоненты, которые помогают не писать все с нуля. У таких компонентов есть лицензии, и они бывают разными. Одни позволяют свободно использовать библиотеку в коммерческом продукте, другие требуют указывать автора или сохранять текст лицензии. Есть и такие, которые могут накладывать более жесткие условия, например обязывать открыть часть собственного кода при распространении продукта.

Поэтому у команды должен быть понятный список: какие типы лицензий допустимы для проекта, какие требуют согласования с юристом или техническим руководителем, а какие нельзя использовать вообще. Это особенно важно для закрытых коммерческих продуктов, проектов под NDA и решений, которые разрабатываются для заказчика.

Какие показатели мы смотрим после релиза? Сам факт, что код прошел проверку, еще не означает, что качество под контролем — мы подробно обсуждали это в подкасте «Гости из IT», когда говорили об ИИ в контексте код‑ревью. Важно смотреть, сколько ошибок дошло до пользователей, как часто приходится срочно исправлять релизы, сколько времени занимает устранение проблем, повторяются ли одни и те же сбои. Именно эти показатели отражают, работает ли процесс проверки или он существует только формально.

Для себя я формулирую это так: бизнесу не нужно контролировать каждую техническую деталь, но важно контролировать рамку. Где ИИ можно применять, где нужны ограничения, кто проверяет результат, какие действия запрещены без человека и кто отвечает за изменения в продукте.