Как ревьюить ИИ-код: что автоматизировать, какую работу оставить человеку и как всё это делать системно
В 2026 году софт всё чаще пишут с участием ИИ: по данным Stack Overflow, 84% разработчиков уже используют ИИ‑инструменты или планируют начать. При этом исследователи Faros AI фиксируют парадокс: в командах с активным использованием ИИ разработчики закрывают на 21% больше задач и на 98% больше мёржат PR, но время ревью выросло на 91%. В статье разберём, как выстроить процесс проверки, который не съедает выигрыш от автоматизации и почему ревью ИИ‑кода нельзя полностью отдать моделям.За консультацию при подготовке материала благодарим:
Golden Armada: трассировки как основа наблюдаемой AI-native системы
Введение В предыдущей статье я описал идею изменения парадигмы программирования в условиях, когда значительная часть кода начинает генерироваться LLM. 👉 Предыдущая статьяТам основная мысль была следующая: код перестаёт быть единственным источником истины, а роль разработчика смещается в сторону архитектуры, контрактов и ограничений. В этой статье я хочу показать следующий шаг — не концепцию, а реализацию. 🌲 От теории к наблюдаемой системе Если предыдущий текст был про “как должно быть”, то Golden Armada — это попытка ответить на вопрос:
Как я перестал исправлять ИИ код и начал проектировать под него архитектуру
Вместо вступленияЗа последний год я заметил странную закономерность. Когда кодовая база была небольшая, все было хорошо, но чем больше кода писал ИИ, тем меньше времени уходило на добавление фичей и больше — на исправление текущего кода. Это сильно раздражало.Я как будто ходил по кругу:Сначала мне казалось: сейчас заставлю ИИ самому для себя писать правила. Кол‑во правил росло, сложность росла. Сначала в них переставал ориентироваться я, потом ИИ.
Как научить ИИ-ассистента писать тесты и моделировать угрозы безопасности в процессе кодинга
Главная уязвимость ИИ-кодогенерацииОсновная претензия к коду, написанному искусственным интеллектом, заключается в низком уровне его надежности и безопасности. Стремясь как можно быстрее выдать работающее решение, языковые модели часто пренебрегают тестами, игнорируют обработку крайних случаев и допускают критические уязвимости вроде SQL-инъекций или межсайтового скриптинга (XSS).
Ааа, всё пропало! AI создаёт дырявый код! Что же делать?
Сегодня за утренним кофе прочитал статью “70% разработчиков считают ИИ-код дырявым, при этом 30% всех опрошенных деплоят его в прод”.Кажется, это ещё одна из статей, написанных с помощью ИИ про ИИ, которые всё заполонили. Поэтому рекомендовать её к прочтению не стану. Да и приведённым там числам я что-то не очень верю.Позабавило: “C-код оказался самым дырявым”. Да, C такой :) Надо иметь прямые руки, чтобы им пользоваться — плата за скорость и экономный расход памяти.
Самая опасная ошибка AI‑агента — не плохой код
ПредысторияДавеча я обсуждал в агентской сессии, почему старая задача перестала находиться после переименования проекта. Ситуация выглядела достаточно простой: у задачи был стабильный идентификатор, проект когда‑то назывался иначе, а текущий механизм поиска, судя по всему, продолжал учитывать не только идентификатор задачи, но и имя проекта, которое давно изменилось. Агент быстро подтвердил проблему, нашёл место, где точечный поиск всё ещё зависел от имени проекта, сформулировал вполне разумную гипотезу исправления, после чего начал читать код, менять несколько файлов и добавлять тесты.
LLM написала, человек одобрил, никто не понял: откуда на самом деле берётся нечитаемый код
«Она написала мне идеальную документацию. Триста страниц. Теперь я не понимаю не только код, но и документацию»1. Знакомое ощущениеКод работает. Тесты проходят. А читать его невозможно. «Я бы написал это иначе» — думает каждый, кто открывал результат работы LLM-агента. Или другая сторона той же монеты: модель выдала исчерпывающий документ, в нём есть всё — а в голове после прочтения не остаётся ничего.Мы привычно называем это «низким качеством». Плохо обучили. Недотюнили. Промпт кривой. Но давайте присмотримся: качество ли это?
Один промпт разросся в регламент: как я разделяю ответственность внутри AI-навыка
У меня был рабочий AI-навык для инженерных задач. Сначала он выглядел как обычная инструкция: роль, задача, формат ответа и несколько ограничений. Этого хватало, пока сценарии были короткими: посмотреть фрагмент кода, подсказать план, разобрать очевидную ошибку.Потом навык начал получать задачи сложнее. Например: “посмотри PR перед merge”. В такой фразе много скрытой работы. Нужно понять, что меняется, какие есть ограничения, где может быть риск, чем подтверждён вывод, какие замечания действительно блокируют принятие изменений, а какие остаются пожеланиями.
Почему плести сети лучше, чем тушить пожары: эффективная разработка ПО с опорой на автоматизацию тестирования
В начале 2024 года я устроилась Senior Software Test Automation Engineer в финтех-стартап. После работы в большой стабильной корпорации это был настоящий вызов ― попасть в живой дышащий мир молодой продуктовой компании, пытающейся занять своё место на рынке. Мне понравился продукт и привлекала возможность влиять на процессы, даже устанавливать новые.
