Как внедрить ИИ в разработку и не остаться без бюджета и без людей

Недавно к нам в подкаст пришла CTO Skyeng Ирина Шанина и почти сразу назвала цифру, после которой хочется переспросить: её команда разработки сократилась почти на треть – а релизы при этом стали выходить быстрее. Не «оптимизировали найм» и не «затянули пояса», а перестроили работу вокруг ИИ так, что часть задач людям делать просто не осталось. Мы досконально разобрали этот кейс: где ИИ действительно заменяет человека, а где лишь красиво имитирует работу – и подсовывает полторы тысячи сломанных тестов за месяц; и во сколько на самом деле обходится «дорогая, а значит хорошая» модель.

Смотреть выпуск подкаста.

А ниже – то, что я как человек, который каждый день внедряет ИИ в enterprise-разработку, вынес из этого разговора: как повторить результат Ирины и при этом не остаться ни без бюджета, ни без людей

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

ИИ нельзя настроить один раз и забыть

Главное заблуждение: ИИ достаточно один раз настроить и оставить работать. Так не выйдет. Без контроля модель почти всегда идёт по короткому пути: формально задача закрыта, а по сути сделана криво. Показательная история была у нас с тестами. ИИ пишет их тысячами, и однажды мы заметили, что вместо исправления ошибки он просто подгонял тест под уже сломанный код. Всё шло автоматически, поэтому проблему увидели только через месяц – когда накопилось около полутора тысяч бракованных тестов. Причём работала не самая слабая модель, Claude Opus: она просто нашла способ формально отчитаться о работе. Вывод один: за исполнителем нужен присмотр, и лучше автоматический.

Дорогая модель – не значит хорошая

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

Закрытый контур не приговор

У банков, промышленности и госсектора почти всегда одно и то же жёсткое требование: всё держать в закрытом контуре, на собственной модели. Кажется, что это автоматически отрезает от современных инструментов. Это не так. Многие облачные модели – по сути открытые веса. Чтобы повторить чужой результат, крупной организации достаточно развернуть такую модель, например Kimi, в своём локальном контуре.

За качество платишь скоростью

Ещё одна деталь, о которой говорят редко: передовые модели медленные – 35–60 токенов в секунду. А если запустить рой агентов и ждать исследования, один запрос может обрабатываться и 25 минут. Само по себе это не проблема – при условии, что процесс выстроен так, что человек в это время занят другой задачей, а не смотрит в прогресс-бар. Приём простой: распараллелить работу и вывести инженера из тех этапов, где его участие всё равно не влияет на результат.

Легаси, которое не осилит ни одна модель

Отдельная головная боль – код, написанный задолго до эпохи ИИ и годами лежавший без обновлений. Мы постоянно сталкиваемся с таким легаси у клиентов: документации, как правило, нет. И тут не спасают ни миллионный контекст, ни рой субагентов. Универсального рецепта не существует.

Каждый случай приходится разбирать отдельно.

Что из этого забрать бизнесу

Если свести всё к тому, что стоит держать в голове руководителю, который всерьёз идёт в ИИ, получится три мысли.