Короткий ответ: ИИ удешевил код, но не ускорил выпуск фич
Написание кода подешевело, а узкое место разработки не исчезло. Оно сместилось: команду тормозит не программирование, а решение о том, что и зачем создавать. Этот тезис разворачивает Кшиштоф Сопыла (Krzysztof Sopyła), руководитель команды разработки, в статье «Что ИИ незаметно сломал в моей команде разработки»; русский перевод опубликован в блоге OTUS на Habr (перевод статьи Кшиштофа Сопылы).
Автор сразу обозначает рамку: он разбирает только негативные последствия, поэтому взгляд односторонний. К ИИ он относится по-прежнему положительно и считает адаптацию обязательной. Трудность в другом: приспосабливаться к изменениям, которых не замечаешь, почти невозможно.
Три опоры, которые ИИ забрал у его команды: высокая стоимость разработки как естественный фильтр идей; лестница профессионального роста, дававшая инженерам статус и профессиональную идентичность; привычка обращаться за помощью к коллегам, державшая отношения и коллективную креативность. Ни одну из трёх потерь не видно на графике скорости разработки. Отвечать за них теперь приходится руководителю.
Почему «ИИ пишет код быстрее» не равно «мы выпускаем фичи быстрее»
Логика, которую автор называет железной, выглядит так: ИИ пишет код быстрее, значит команда быстрее выпускает фичи, значит быстрее закрывает дорожную карту. Верно здесь только первое звено. Код действительно создаётся быстрее. Дальше в цепочку вмешиваются согласование, проверка, интеграция, поддержка и, главное, выбор того, что вообще стоит делать.
Начало года в команде автора прошло под знаком революции ИИ-агентов: ожидания взлетели до небес, а показатели за ними не поспевали. Утроить скорость выполнения задач не получалось, сколько ни старайся. Сам автор описывает состояние как выгорание: «Я чувствовал себя выгоревшим и постоянно спрашивал себя, что не так с моей командой». Вопрос, который звучал в команде в разных формулировках, был один: если ИИ пишет код за минуты, почему задача всё равно занимает квартал?
Узкое место разработки: не код, а решение, что и зачем создавать
Скорость набора кода редко ограничивала команду. Ограничителем было понимание задачи: какой сценарий нужен пользователю, какие компромиссы допустимы, что команда сознательно не делает. Фредерик Брукс объяснил это ещё сорок лет назад в работе No Silver Bullet: добавление ресурсов не снимает концептуальную сложность, а настоящее ограничение - понимание того, что именно нужно разрабатывать.
Дешёвый код меняет экономику не производства, а отбора. Когда кандидатов на реализацию становится в разы больше, а стоит каждый почти ничего, вся нагрузка падает на приоритизацию. Принятие решений в разработке с ИИ перестаёт быть побочной задачей тимлида и становится основной компетенцией команды. Ошибка в ней дорожает: неверно выбранное направление теперь можно очень быстро наполнить очень большим количеством кода.
Про данные DORA о снижении продуктивности при внедрении ИИ без ориентации на пользователей автор упоминает как про внешнюю опору, но в доступном фрагменте перевода конкретные формулировки и показатели не раскрыты. Проценты поэтому не привожу: сам тезис важен (ИИ не даёт прироста автоматически, всё решает ориентация на пользователя и контекст), а детали разобраны ниже, в разделе об исследованиях.
Три вещи, которые ИИ незаметно забрал у команды
Потери связаны между собой. Фильтр идей влиял на качество решений: дорогая разработка заставляла отбрасывать слабое до того, как на него потратят квартал. Лестница роста держала мотивацию: человек понимал, за счёт чего растёт. Привычка просить помощь держала связи: команда знала, кто что умеет, и училась друг у друга. Уберите одно звено, и два других начнут провисать.
Высокая стоимость разработки как естественный фильтр идей
Пока разработка стоит дорого, команда вынуждена выбирать. Каждая идея конкурирует с другими за одни и те же недели, и это отсекает слабое до старта. Когда код дешёвый, фильтр исчезает: сделать можно всё, вопрос только в том, кто и когда будет это сопровождать.
Дальше срабатывает эффект прототипов на вайб-кодинге. Демо, собранное за вечер, выглядит как работающий продукт: кнопки нажимаются, форма отправляется, данные отображаются. За кадром остаются нефункциональные требования: поведение под нагрузкой, безопасность, наблюдаемость, доступность, стоимость эксплуатации. Прототип получает ресурс на развитие, потому что спорить с работающей демонстрацией психологически тяжело.
Лестница профессионального роста и потеря статуса
Профессиональная лестница давала инженеру статус и ощущение собственной идентичности: я умею то, чего пока не умеют другие, и за это меня ценят. ИИ стирает различия между уровнями мастерства. Джуниор с хорошим ассистентом выдаёт результат, неотличимый на вид от работы сеньора, авторитет сеньоров проседает, а уверенность в себе начинает обгонять опыт.
Это бьёт по обеим сторонам. Новичок получает быстрый результат без понимания, почему он работает, и не проходит через ступени, на которых раньше формировалось чутьё. Сеньор теряет сигнал, по которому его отличали. Часть сопротивления ИИ-агентам растёт именно отсюда: люди защищают не привычку печатать руками, а авторство и ответственность за результат, о чём подробнее в разборе почему часть разработчиков не хочет отдавать код ИИ-агентам. Сжатие карьерных ступеней задевает и рынок: закрытые junior-позиции и сдвиг нагрузки на одного фулстек-инженера разобраны в материале ИИ забирает работу по кускам.
Феномен роста уверенности, обгоняющей реальные навыки, руководителю стоит отслеживать отдельно. Человек с ИИ чувствует себя сильнее, чем есть: ассистент отвечает быстро и гладко, сомнение не возникает, проверка сокращается. Полевые эксперименты с разработчиками Microsoft, Accenture и компаний из Fortune 100 в статье упомянуты, но в доступной части перевода их условия и числа не раскрыты, так что переносить оттуда выводы на свою команду без проверки не стоит.
Привычка просить помощь и коллективная креативность
Когда на любой вопрос отвечает ассистент, обращаться к коллеге становится незачем. Экономия очевидна, потеря нет: команда теряет отношения, профессиональные сообщества, коллективную креативность и готовность честно признавать ошибки. Внешний индикатор того же сдвига, который приводит автор, это падение числа новых вопросов на Stack Overflow: публичные обсуждения теряют приток свежих формулировок.
Полезная рамка для разговора с командой - транзактивная память. Команда помнит не только содержимым голов, но и связями: кто с чем уже сталкивался, к кому идти с вопросом про этот модуль, где лежит контекст прошлого решения. ИИ-ассистент такую память не заменяет: у него нет истории вашего продукта и нет репутации, за которую он отвечает. Психологическая безопасность в команде разработки держится на том же механизме. Если спрашивать коллегу стало не нужно, обсуждение исчезает, а ошибки прячутся до инцидента.
Эффект прототипов: почему вайб-кодинг выглядит как готовый продукт
Механика простая. ИИ быстро собирает связный работающий скелет: маршруты, формы, запросы к базе, немного стилей. Внешне это неотличимо от продукта, и именно внешняя целостность усыпляет проверку. Нефункциональные требования не видны в демо, потому что для них нужен другой сценарий проверки: нагрузка, отказ зависимости, попытка авторизоваться чужими правами, чтение логов после сбоя.
Дешёвый прототип проходит дальше, чем должен: раньше дорогая разработка отсекала часть идей на этапе оценки, теперь идея доходит до демо и там получает кредит доверия. Практика показывает, как быстро такой прототип рассыпается на первом же изменении логики: пример с магазином за два вечера, где после добавления скидки ломается самовывоз, разобран в статье ИИ в разработке: почему два вечера до магазина ещё не конец программистов.
Чек-лист вопросов к прототипу, прежде чем называть его продуктом:
- Что произойдёт при десятикратном росте нагрузки и где узкое место?
- Кто и как авторизуется, что видит один пользователь про другого?
- Где хранятся секреты и что попадёт в логи при ошибке?
- Как понять, что система сломалась, до жалобы пользователя?
- Сколько стоит месяц эксплуатации и кто отвечает за инцидент ночью?
- Какая часть кода написана без понимания автором и кто её перепишет?
Ограничение здесь одно и важное: прототипы полезны, они дешёвый способ проверить гипотезу. Проблема возникает, когда между прототипом и продуктом нет явного этапа проверки нефункциональных требований, а переход происходит по умолчанию, потому что «уже работает».
Что показывают исследования: Microsoft, Accenture, Fortune 100, DORA и Stack Overflow
Черновик перевода (оригинал на Habr) ссылается на несколько групп данных: полевые эксперименты с разработчиками Microsoft, Accenture и компаний из Fortune 100; данные DORA о снижении продуктивности при внедрении ИИ без ориентации на пользователей; падение числа новых вопросов на Stack Overflow; работы о транзактивной памяти и психологической безопасности. Оговорка принципиальная: в доступном фрагменте эти ссылки только названы, без выборок, метрик и условий. Пересказывать их как подтверждённые показатели нельзя.
| Источник из статьи | Что известно по доступному фрагменту | Как использовать без искажений |
|---|---|---|
| Полевые эксперименты: Microsoft, Accenture, Fortune 100 | Упомянуты как подтверждение эффектов ИИ на разработчиков, детали не раскрыты | Не переносить выводы на свою команду без проверки своих метрик |
| DORA | Обозначена связка: ИИ без ориентации на пользователей снижает продуктивность | Считать гипотезой для собственных замеров, а не готовым числом |
| Stack Overflow | Указано падение числа новых вопросов | Трактуйте как сигнал сдвига в поведении, а не как доказательство вреда |
| Транзактивная память, психологическая безопасность | Названы как опора аргумента о потере связей | Использовать как рамку для обсуждения в команде |
Граница между наблюдением и данными проходит по авторским формулировкам. «Ничего из этого не видно на графике скорости разработки» - это вывод руководителя из собственной практики. Утверждения про DORA и Stack Overflow - внешние ссылки, которые в доступном тексте не развёрнуты. Смешивать их в одном абзаце с процентами значит создавать факты, которых в источнике нет.
Другая часть картины собрана в отдельном разборе AI-Manual: ИИ-ассистенты в разработке: экономия времени или потеря экспертизы. Там приведены результаты METR о росте времени на сложных задачах и данные Anthropic о падении понимания у тех, кто изучает новые библиотеки с ИИ. Эти цифры привязаны к своим условиям эксперимента: на шаблонных задачах выигрыш есть, на сложных он может обнуляться проверкой и отладкой.
Четыре подхода руководителя: что делать в понедельник
Автор описывает четыре подхода как то, что он пробует сам, а не как проверенную методику. Измерять ценность, а не скорость; поощрять сомневающихся; следить за готовностью признавать ошибки; делиться способами работы с ИИ вместо промптов. Каждый подход возвращает одну из потерянных опор.
Измерять ценность, а не скорость
Скорость написания кода перестаёт быть сигналом, как только код дешевеет: метрика начинает расти сама по себе. Вместо неё нужны показатели, привязанные к результату: доля решений, доведённых до пользователя; число переделок в течение месяца после релиза; стоимость поддержки на фичу; время до рабочего, поддерживаемого и безопасного результата.
Ограничение честное: метрики ценности собираются дольше и запаздывают, ими неудобно отчитываться за неделю. Зато они не создают стимул генерировать больше кода ради движения графика. Практический минимум - зафиксировать, какие решения команда приняла не делать и почему, и возвращаться к этому списку через квартал.
Поощрять сомневающихся и готовность признавать ошибки
Сомнение с ИИ становится навыком, а не тормозом. Ассистент отвечает уверенно и в одном тоне независимо от того, прав он или нет, поэтому единственный источник сигнала об ошибке - человек, который перепроверил и сказал об этом вслух. Психологическая безопасность в команде разработки держится на скорости, с которой люди сообщают о своей ошибке, а не на отсутствии ошибок.
Приёмы, которые дают эффект без лишних ритуалов:
- ретроспективы по решениям, а не по коду: что решили, на каких данных, где ошиблись в оценке;
- постоянный вопрос «что мы решили не делать и почему» вместо обсуждения объёма сделанного;
- разбор случаев, когда ИИ дал уверенный, но неверный ответ, с публичным разбором, а не с поиском виноватого;
- явное правило: сомнение в решении можно высказать до релиза без последствий для репутации.
Делиться способами работы с ИИ вместо промптов
Промпт - артефакт: он живёт в чужом чате и редко воспроизводится на другой задаче. Способ работы - это контекст, который вы даёте модели, ограничения задачи и критерии проверки результата. Обмен промптами экономит минуту. Обмен способами работы восстанавливает привычку обращаться друг к другу, только теперь повод другой: не «как написать запрос», а «как ты проверял, что агент не наврал».
Формат внутренней встречи, который решает задачу: два инженера показывают по одному кейсу за 15 минут. Что формулировали, какой контекст дали, где ИИ ошибся, как поймали ошибку, что изменили в процессе после этого. Никаких «магических промптов» на слайдах, только воспроизводимый процесс.
Как внедрять AI-инструменты в команду разработки без потери этих опор
Рамка внедрения собирается из тех же четырёх опор, о которых пишет автор. Порядок действий:
- Определить, где в процессе принимаются решения о том, что создавать. Если это размыто, дешёвый код просто ускорит движение не туда.
- Встроить обязательный этап проверки нефункциональных требований для прототипов: чек-лист из этой статьи как часть Definition of Done для демо.
- Пересмотреть метрики продуктивности: убрать объём кода и число закрытых задач из ключевых показателей, добавить долю доведённых до пользователя решений и стоимость поддержки.
- Сохранить ритуалы обмена опытом: внутренние разборы кейсов с ИИ, где обсуждают проверку, а не промпты.
- Следить за признаками выгорания и завышенной уверенности: рост скорости на словах при падении числа обсуждений и вопросов внутри команды.
- Отдельно продумать онбординг новичков: дать им задачи, которые нельзя закрыть генерацией без понимания, иначе следующее поколение сеньоров не появится.
Автор подчёркивает: материал не про отказ от инструментов. Он сам относится к ИИ положительно и считает адаптацию необходимой, а разбирает только побочные эффекты. Единого рецепта нет: для команды из пяти человек и для продукта с жёсткими требованиями к надёжности набор мер будет разным, и часть пунктов придётся проверять на своих данных, а не переносить из чужого опыта.
Что запомнить: короткие выводы для команды
- Дешёвый код не ускоряет выпуск фич сам по себе: верно только первое звено цепочки, дальше работают согласование и проверка.
- Узкое место разработки - принятие решений о том, что и зачем создавать; с ИИ эта компетенция становится основной.
- Три потери (фильтр идей, лестница роста, привычка просить помощь) не видны на графике скорости, поэтому за них отвечает руководитель.
- Прототип на вайб-кодинге выглядит как продукт, но скрывает нефункциональные требования: нагрузку, безопасность, наблюдаемость, стоимость эксплуатации.
- Уверенность с ИИ растёт быстрее навыков: проверять результат и озвучивать сомнение нужно явно и без наказания.
- Психологическая безопасность и привычка обращаться к коллегам требуют защиты: транзактивную память команды ассистент не воспроизводит.
- Измеряйте ценность, а не скорость, и делитесь способами работы с ИИ вместо промптов.
Оригинал статьи Кшиштофа Сопылы (перевод в блоге OTUS) стоит прочитать целиком: автор намеренно сосредоточился на негативных последствиях, и это односторонний взгляд руководителя, который продолжает пользоваться ИИ каждый день.