За последний год разработка с помощью ИИ изменилась довольно заметно. Ещё недавно модели использовали в основном как продвинутый автокомплит: попросить написать функцию, объяснить ошибку или предложить вариант реализации. Сейчас агенту можно поставить задачу целиком, дать доступ к проекту и получить готовое изменение с кодом, тестами и исправлениями.
Производительность действительно растёт. Один разработчик способен за день сделать объём работы, на который раньше ушло бы несколько дней. Но вместе с этим появляется менее очевидная проблема: код теперь можно производить быстрее, чем компания способна его проверять.
В свежем исследовании SmartBear приняли участие 1 436 разработчиков и руководителей из США и Великобритании, использующих ИИ в разработке. 46% опрошенных команд сообщили, что уже выпускали созданный с помощью ИИ код, который впоследствии дал сбой в рабочей среде. При этом среди столкнувшихся с такими случаями 69% всё равно сохраняют высокую уверенность в качестве ИИ-кода. Ещё интереснее разрыв между ощущением контроля и самим контролем: только четверть команд проверяет человеком более 80% работы агентов. Это исследование производителя инструментов тестирования, поэтому его цифры не стоит воспринимать как универсальную статистику всей отрасли, но сам разрыв между скоростью разработки и скоростью проверки оно показывает довольно хорошо.
Проблема здесь не в том, что ИИ пишет «плохой код». Проблема в другом: мы сильно ускорили один этап процесса и почти не изменили всё, что происходит после него.
Код — только промежуточный результат
Для бизнеса результат разработки — не количество написанных строк и даже не закрытая задача в трекере. Результат появляется тогда, когда изменение работает в реальной системе и решает ту задачу, ради которой его делали.
Между этими точками находится довольно длинная цепочка. Нужно правильно понять требование, выбрать способ реализации, проверить изменение, убедиться, что оно не сломало соседнюю функциональность, протестировать его на реальных сценариях, выкатить и посмотреть, что происходит после запуска.
ИИ очень сильно ускорил участок, связанный непосредственно с созданием реализации. Остальные этапы автоматически быстрее не стали.
Представим, что раньше разработчик делал две небольшие задачи в день. Руководитель или старший разработчик успевал посмотреть изменения, тестировщик — проверить их, а заказчик — принять результат. Теперь с агентом тот же разработчик способен подготовить восемь задач. Если остальная система работы не изменилась, компания получает не восьмикратное ускорение, а очередь из изменений, ожидающих проверки.
В этот момент новое узкое место возникает уже не в программировании.
Особенно опасно то, что результат выглядит убедительно
У обычной ошибки разработчика есть полезное свойство: человек часто сам чувствует, где он не уверен. Он долго разбирался в незнакомой части проекта, сделал обходное решение или не успел проверить редкий сценарий и поэтому обращает на это дополнительное внимание.
Агент такой сигнал даёт далеко не всегда. Он может быстро сделать большое изменение, аккуратно оформить код, добавить тесты и уверенно сообщить, что задача выполнена.
Внешне всё выглядит значительно надёжнее, чем пятнадцать минут хаотичного ручного программирования.
Но аккуратный код всё ещё может решать не ту задачу.
Это одна из самых неприятных особенностей разработки с ИИ. Проверять приходится не только вопрос «работает ли программа», но и более ранний вопрос: правильно ли агент вообще понял, что от него требовалось.
SmartBear в том же исследовании обнаружил, что только 46% команд проверяют спецификацию до того, как ИИ начинает писать по ней код. Иными словами, проблема может появиться ещё до первой сгенерированной строки. Агент способен идеально реализовать неверно сформулированное требование.
Автоматические тесты становятся важнее, а не менее важны
Иногда развитие ИИ воспринимают так: раз модель умеет рассуждать о коде, значит часть старой инженерной дисциплины становится не нужна. На практике происходит почти обратное.
Чем быстрее система производит изменения, тем важнее иметь автоматические механизмы, которые способны с той же скоростью отсекать очевидные ошибки.
Если можно формально проверить типы — их нужно проверять автоматически. Если есть линтер — он должен запускаться автоматически. Если критичная логика покрывается тестом — этот тест должен запускаться при каждом изменении. Если программный интерфейс обязан соответствовать определённой схеме — лучше проверять схему программой, а не просить другую языковую модель посмотреть код и решить, всё ли нормально.
У SmartBear есть даже собственный пример этой проблемы: компания пишет, что скорость разработки у них выросла быстрее, чем возможности существующего набора тестов, поэтому им пришлось отдельно усиливать контроль контрактов API. Здесь интересна не конкретная технология, а сам симптом: ускорение разработки сдвигает ограничение дальше по конвейеру.
Это вполне нормальная эволюция процесса. Если станок начал выпускать деталей в десять раз больше, контроль качества тоже придётся перестроить.
Но зелёные тесты ещё не означают правильный результат
Есть и обратная ошибка: считать, что если агент сам написал тесты и они прошли, задача решена.
Тест проверяет только то, что в него заложили.
Допустим, нужно изменить расчёт скидки для определённой категории клиентов. Агент понял условие немного иначе, изменил функцию и написал тесты именно под своё понимание. Все тесты зелёные. Код технически исправен. Но бизнес-правило реализовано неправильно.
Поэтому проверка результата должна происходить на нескольких уровнях. Программные свойства хорошо проверяются программами. Соответствие требованиям — уже через заранее определённые сценарии. А там, где изменение затрагивает существенную бизнес-логику, деньги, права пользователей или критичные данные, остаётся человеческая приёмка.
Это не недостаток ИИ. Так вообще устроена нормальная инженерия.
Просто раньше высокая стоимость написания кода естественным образом ограничивала количество изменений. Теперь этот ограничитель постепенно исчезает, и слабые места следующих этапов становятся гораздо заметнее.
Большие изменения от агента особенно трудно проверять
Ещё одна практическая проблема появляется, когда агенту ставят слишком крупную задачу.
Человеку удобно сказать: «Переделай весь модуль авторизации» или «Перенеси старый сервис на новую архитектуру». Агент способен выполнить такую задачу и изменить десятки файлов за один проход.
После этого кто-то должен разобраться в нескольких тысячах строк изменений.
Формально работа сделана быстрее. Практически стоимость проверки резко выросла.
Поэтому при разработке с агентами особенно полезно сохранять изменения небольшими. Одна понятная задача, ограниченная область проекта, небольшой набор файлов и ясный критерий готовности. Это выглядит менее впечатляюще, чем агент, который самостоятельно переписал половину приложения, зато результат можно реально проверить.
В разработке с ИИ размер изменения становится не только вопросом организации работы, но и элементом контроля риска.
ИИ не должен проверять только сам себя
Можно решить проблему очень соблазнительным способом: один агент пишет код, второй агент его проверяет.
Такой подход полезен. Независимый проход другой модели действительно способен находить ошибки, пропущенные первой. Но это дополнительный слой проверки, а не доказательство корректности.
Обе модели могут одинаково неправильно понять исходное требование. Обе могут не знать скрытое бизнес-правило. Обе могут решить, что реализация выглядит логично, хотя реальная система ведёт себя иначе.
Поэтому хороший контур проверки обычно сочетает разные механизмы. Модель может искать подозрительные места и проводить дополнительное ревью, код — проверять формальные свойства, автоматические тесты — воспроизводить известные сценарии, а человек — оценивать смысл изменения там, где цена ошибки достаточно высока.
Чем независимее эти способы проверки друг от друга, тем полезнее вся конструкция.
Это проблема не только программистов
Тот же эффект появляется практически в любой автоматизации с ИИ.
Представим обработку документов. Раньше бухгалтер вручную разбирал 100 счетов. После внедрения системы ИИ способен за несколько минут обработать все 100. Но в 12 документах он не уверен. Если эти 12 случаев просто оказываются в общей очереди без понятного объяснения, человек может потратить на их разбор больше времени, чем ожидалось.
Или клиентская поддержка. ИИ классифицирует две тысячи обращений, но часть из них требует ручного решения. Если система просто увеличила скорость поступления исключений, она могла переместить нагрузку с первой линии на вторую.
То же самое происходит с отчётами, договорами, CRM и внутренними документами. Генерация результата становится дешёвой. Проверка результата остаётся реальной работой.
Поэтому перед автоматизацией полезно задавать не только вопрос «какую операцию мы ускорим», но и следующий: что произойдёт сразу после неё?
Human-in-the-loop не означает проверять всё вручную
На этом месте обычно возникает логичный контраргумент: если каждый результат ИИ всё равно должен проверять человек, где тогда экономия?
Если проверять всё одинаково подробно — действительно, экономия быстро исчезнет.
Но хороший процесс устроен иначе. Очевидные и формально проверяемые случаи проходят автоматически. Человеку показываются исключения, неоднозначные ситуации и действия с высокой ценой ошибки.
В разработке большая часть простых проблем может отсекаться тестами, статическим анализом и автоматическими проверками. Разработчику остаются изменения, которые действительно требуют инженерного решения.
При обработке документов обычный код проверяет формат ИНН, номер счёта, обязательные поля и дубли. Человек разбирает документ, в котором данные противоречат друг другу.
В платёжном процессе система может сама подготовить черновик, но финансово значимое действие требует подтверждения.
Цель human-in-the-loop не в том, чтобы поставить человека после каждого шага ИИ. Цель — правильно выбрать место, где человеческая проверка действительно дороже автоматической ошибки.
Измерять нужно полный цикл, а не скорость агента
Самая опасная метрика при внедрении ИИ — показать, насколько быстрее он выполняет собственную часть задачи.
Агент написал функцию за десять минут вместо двух часов. Это интересно, но ещё не говорит об экономическом эффекте.
Нужно посмотреть на полный цикл: сколько прошло времени от постановки задачи до работающего изменения в production. Сколько времени ушло на проверку. Сколько изменений вернули на доработку. Сколько дефектов нашли после запуска. Сколько потребовалось откатов. Сколько времени команда потратила на разбор кода, который сама не писала.
Если генерация ускорилась в десять раз, а очередь ревью выросла в пять, это не означает, что ИИ бесполезен. Это означает, что автоматизация пока улучшила только один участок процесса.
И следующий проект должен быть посвящён уже не ускорению генерации, а перестройке контроля качества.
Что я бы менял в процессе разработки
Если команда активно использует ИИ для программирования, я бы не вводил отдельный большой «регламент работы с нейросетями». Гораздо полезнее встроить контроль в существующий процесс разработки.
Задачи стоит делать достаточно маленькими, чтобы результат можно было понять и проверить. До генерации нужно явно сформулировать критерий готовности. Всё, что возможно проверить детерминированно, должно проверяться автоматически. Агент не должен самостоятельно расширять область задачи только потому, что нашёл соседний код, который ему захотелось улучшить.
Для критичных изменений должна сохраняться человеческая приёмка, а история работы должна позволять понять, что именно менялось, какие проверки прошли и почему изменение было принято.
Это не делает разработку медленнее. Наоборот, такая дисциплина позволяет безопасно использовать ту скорость, которую дали новые инструменты.
Главное изменение произошло не в программировании
ИИ действительно сильно снизил стоимость создания первой версии решения. И это хорошая новость.
Но из неё следует не то, что теперь можно меньше думать о проверке. Скорее наоборот: производство результата стало настолько дешёвым, что проверка постепенно становится главным ограничивающим ресурсом.
Поэтому следующий этап внедрения ИИ — не научиться генерировать ещё больше кода, документов, отчётов или ответов клиентам. Нужно научиться с той же скоростью отделять правильный результат от убедительно выглядящего неправильного.
На ИИ-аудите я бы именно так и смотрел на процесс: не только где сотрудники долго выполняют работу, но и где после ускорения возникнет новая очередь. Что можно проверить обычным кодом, где достаточно автоматического теста, какие исключения нужно показать человеку и какие действия вообще нельзя выполнять без подтверждения.
Потому что автоматизированный процесс считается быстрым не тогда, когда ИИ мгновенно сказал «готово». Он становится быстрым тогда, когда проверенный результат действительно дошёл до бизнеса.
