Заменит ли ИИ разработчиков? На короткой дистанции — уже почти заменил, и у этого есть цифры. На дистанции живого продукта — нет, и у этого тоже есть цифры. Разница между двумя ответами стоит денег, поэтому её стоит разобрать до того, как вы согласуете смету.
Anthropic выложила исследование на 400 000 реальных сессий работы с ИИ-агентом: полгода наблюдений, около 235 000 человек. Вывод, который они вынесли в заголовок: выигрывает не тот, кто умеет писать код, а тот, кто разбирается в своём деле.
С цифрами я спорить не буду, они убедительные. А вот с выводом — буду: он верен ровно до того момента, когда прототип надо превратить в продукт.
Заменит ли ИИ разработчиков: что показали 400 000 сессий
Профессия влияет на результат слабее, чем принято думать. У специалистов по разработке 30% задач доведено до подтверждённого конца, у людей других профессий — 26%. Все десять крупнейших профессиональных групп уложились в коридор семи пунктов от инженеров, а руководители инженерных команд даже немного обогнали своих подчинённых.
Влияет другое — насколько человек разбирается в задаче, которую ставит.
| Кто ведёт диалог с агентом | Задача доведена до конца | Вытащил зависшую сессию | Действий агента на одну команду |
|---|---|---|---|
| Новичок | 15% | 4% | 5 |
| Эксперт в своём деле | около 30% | 15% | 12 |
Эксперт получает от того же агента в разы больше: 12 действий против 5 на одну инструкцию, около 3200 слов ответа против 600. Когда агент заходит в тупик, новичок бросает сессию в 19% случаев, эксперт — в 5–7%. Один и тот же инструмент, разный результат.
Ещё одна цифра про разделение труда: человек принимает около 70% решений «что делать», агент — около 80% решений «как делать». Стратегия осталась у людей, реализация ушла модели.
Для заказчика это хорошая новость. Ваш главный бухгалтер, который знает правила сверки, объяснит агенту задачу не хуже программиста. Иногда лучше — потому что он знает, где в этой сверке подводные камни.
Где заканчивается прототип и начинается продукт
Исследование мерит одну сессию: довёл человек задачу до конца или нет. Это короткая дистанция. И на ней эксперт-одиночка действительно обгоняет инженера — он понимает, что нужно конечному клиенту, и собирает работающую штуку быстрее.
Проблема в том, что «работает сегодня» и «живёт год под нагрузкой» — разные вещи. Именно здесь вопрос «заменит ли ИИ разработчиков» распадается на два разных вопроса с разными ответами.
Эксперт без инженера соберёт прототип, который производит сильное впечатление, и решит, что продукт готов. Дальше начинается масштабирование, и всплывает всё сразу: нет тестов, не заложена нагрузка, не продуман доступ к данным, выбраны библиотеки, которые никто не поддерживает, нет процесса обновления без простоя. Не потому что человек слабый — потому что это другая профессия.
Сами авторы исследования это признают. В разделе ограничений написано прямо: мы не можем измерить, развёрнут ли код в реальности и приносит ли он пользу. То есть в успех засчитана сессия, где простая и незащищённая штука работает первое время. Что с ней будет через три месяца, метрика не видит. Оговорка ушла в примечания, а в заголовок — оптимистичный вывод.
Отсюда практический вывод для сметы. Прототип и продукт — разные строки бюджета, и путать их дорого. Мы поэтому и показываем работающий прототип до подписания договора: чтобы разговор про полноценный продукт начинался с уже понятной картинки, а не с обещаний.
Что это значит для бюджета
В смете вопрос «заменит ли ИИ разработчиков» превращается в другой: какие именно строки стали дешевле. Подешевела реализация, а не проект целиком. Черновой код, типовые интеграции, тесты по описанию — эту часть ИИ действительно закрывает быстро, и именно на ней мы сокращаем стоимость и сроки.
Не подешевело всё остальное:
- проектирование — что именно строим и в каком порядке;
- проверка — тесты, ревью, прогон на реальных данных;
- безопасность и доступы;
- нагрузка и запас на рост;
- процесс обновлений, чтобы через полгода продукт можно было менять, а не переписывать;
- ответственность за результат перед вашим клиентом.
В смете это основная часть. Поэтому экономия от ИИ появляется на скорости прохождения этапов, а не на исчезновении ролей. Если подрядчик обещает минус 80% просто потому, что «у нас ИИ», спросите, какую именно работу он убрал из состава.
И отдельно про переписывание. Прототип, собранный без расчёта на нагрузку, редко доводится правками — чаще его разбирают и строят заново на нормальном основании. В деньгах это означает, что вы заплатили дважды: за впечатление и за продукт.
Рабочая связка: ваш эксперт плюс инженер
Хорошо получается только вместе. Поэтому на вопрос, заменит ли ИИ разработчиков, у меня короткий ответ: роль не исчезла, а сместилась. Инженер теперь отвечает не за набор символов, а за то, выдержит ли результат нагрузку.
Без эксперта инженер сделает технически чистую вещь, которая не нужна в таком виде. Если делаем бота для продаж — садимся вплотную с руководителем отдела продаж и разбираем реальные возражения его клиентов. Как это выглядит на практике, я показывал в разборе ИИ-бота для продаж: там половина работы — про то, чего бот не должен говорить, и это знание приходит от заказчика, а не от нас.
Без инженера эксперт получит быстрый эффект и долгое разочарование. Маленький инструмент для себя — пожалуйста. Продукт, на котором держится выручка, — сомневаюсь.
Любопытно, что нужда в инженере зашита в сами цифры исследования. Агент силён именно в коде, поэтому в реализации он редко уходит не туда. А вот в архитектуре, безопасности и нагрузке он спокойно срежет угол — и эксперт этого не поймает, потому что это не его язык. Поймает инженер.
Обратная крайность: «вы программисты, вам виднее»
Вторая яма ровно напротив первой, и она обходится не дешевле.
Когда бизнес приходит за продуктом, часто звучит: вы эксперты, вы всё сделаете сами. Но эксперты в вашем бизнесе — вы. Мы знаем, как строить систему. Как устроены ваши продажи, какие у ваших клиентов настоящие возражения, где в вашей сверке подводные камни — знаете только вы.
Самые тяжёлые проекты в моей практике — не технически сложные. Тяжёлые те, где эксперт самоустранился: «разберётесь сами». В инженерной части разберёмся. В вашей предметной области — нет, и не должны.
Справедливости ради, крен бывает и в нашу сторону. Инженер с сильным агентом за спиной за пару недель начинает верить, что разбирается в чужой предметной области лучше человека, который в ней двадцать лет. Не разбирается. Он быстро пишет код, это другое умение. Связка работает, когда эксперт не решает за инженера архитектуру, а инженер не решает за эксперта, как устроены продажи.
Как ставить задачу: «что» вместо «как»
Описывайте результат и ограничения, а не способ их достичь. Это касается и работы с агентом, и брифа для подрядчика.
В исследовании 80% решений «как делать» уходят агенту, и это не случайность. Если зажать модель в жёсткие рамки и расписать каждый шаг, растёт число выдумок и падает качество. То же самое происходит с командой: чем детальнее заказчик диктует реализацию, тем меньше шансов получить хорошее решение.
Так задача сформулирована плохо:
Сделайте лендинг. Шапка 80 пикселей, логотип слева, кнопка синяя, скругление 8, три карточки в ряд, иконки сверху.
А так — хорошо:
Нужен лендинг для B2B-сервиса с гарантией ответа за 24 часа. Тёмная тема, ощущение надёжности и скорости. Структуру выберите сами, но клиенту должно быть сразу понятно, что мы быстрые и серьёзные.
Разница в том, что во втором случае вы отдали эстетику и реализацию, а сохранили за собой то, что действительно ваше: обещание клиенту и срок.
Ограничения при этом нужны — но те, которые идут от бизнеса. Гарантия 24 часа, требование не выносить данные за пределы контура, формат обмена с 1С — это ваши правила, и их надо проговаривать жёстко. А количество пикселей в шапке лучше не проговаривать вовсе.
Что спросить до старта
Пять вопросов подрядчику и один себе.
- Что именно вы мне отдаёте на первом этапе: прототип для проверки идеи или систему, которую можно нагружать? Это разные деньги и разные сроки.
- Какие тесты будут и на чём вы проверяете, что ничего не сломалось после правки?
- Что произойдёт, когда пользователей станет в десять раз больше? Хочется услышать про конкретные узкие места, а не «масштабируется».
- Кто отвечает за доступы и за данные клиентов?
- Как продукт будет обновляться через полгода и что для этого нужно не переписывать.
А себе: кто с нашей стороны будет отвечать на вопросы и смотреть промежуточные результаты, и есть ли у этого человека на это время. Если такого человека нет, проект стоит отложить, а не начать.
Заменит ли ИИ разработчиков: мой ответ
Исследование право наполовину, и это хорошая половина. Понимание своего дела действительно стало важнее умения писать код — на коротком плече. Профессия действительно значит меньше, чем казалось.
Но «эксперт вместо инженера» — это про прототип. «Эксперт вместе с инженером» — это про продукт, который живёт. Померили первое, а в заголовок пошло почти второе.
Ни одна из ролей никуда не делась, у обеих поменялась суть. Эксперт теперь учит агента работать правильно. Инженер строит обвес вокруг агента и отвечает за то, чтобы впечатляющий прототип дорос до системы. Что это за обвес и из чего он состоит, я разбирал в материале про специализированных агентов.
Про инженерную сторону — как мы оркеструем агентов, что ломается и какие метрики я снимаю — пишу в канале @maslennikovigor. Там же выкладываю то, что в статьи не попадает: неудачные прогоны и разборы чужих провалов.