Внедрение ИИ сначала убирает у команды ночные переработки и очереди к сеньорам, а затем может принести тысячи строк кода, которые никто не готов сопровождать. В статье на эту тему руководитель технологических проектов Арсентий Гусев разбирает, как помощники на базе ИИ незаметно меняют роли продактов, разработчиков и стажёров — и почему российским IT-командам пора считать не только скорость генерации, но и стоимость последствий.
Как сообщает Habr / Карьера, отправной точкой для автора стала вполне знакомая картина: после появления новых моделей сотрудники всё реже идут в поиск или на Stack Overflow и всё чаще задают вопрос нейросети. Продакты приносят исследования без отдельных задач, показывают прототипы на непривычных для компании стеках. Разработчики закрывают больше работы и выглядят менее измотанными. Стажёры перестают постоянно спрашивать сеньоров. На первый взгляд это тот редкий случай, когда все метрики счастья сошлись.
Проблема начинается во второй фазе. Продакты, получив возможность быстро собрать скрипт или прототип, рискуют уйти из стратегии в ночное программирование: вместо разговора о рынке, пользователях и горизонте продукта они просят добавить в команду «вайбкодера». Инженеры тоже расходятся в разные стороны. Одни воспринимают освободившееся время как личный бонус, другие начинают интересоваться целями продукта и предлагают менять стек. Сам по себе этот интерес полезен, но он не отменяет разделения ответственности: команде по-прежнему нужен человек, который отвечает за продуктовые решения, а не за самый быстрый путь к работающему демо.
Самый тревожный сигнал в описанном сценарии — подмена поставки кода поставкой результата. Вместо отладки и чтения существующей логики разработчик генерирует новый вариант. Диффы разрастаются, ревью превращается в испытание на выносливость, а количество итераций после автотестов увеличивается. Стажёр может прислать большой коммит, но сеньор отклонит его без разъяснений: проверить две тысячи строк ради исправления двух строк ошибки — плохая экономика для обоих. Формально задач закрыто больше, фактически знание о системе перестаёт передаваться внутри команды.
Отдельно автор описывает управленческую реакцию, которую легко узнать по многим компаниям: «срочно внедрить ИИ», утроить производительность и сократить штат. Но между презентацией такого плана и устойчивым процессом лежат расходы на расширенные подписки, лимиты сервисов, безопасность данных и поддержку инструмента. В тексте фигурирует запрос на локальный ИИ-сервер стоимостью 35 млн рублей, который финансовый директор не согласовал. Одновременно безопасники задают неудобный, но обязательный вопрос: не уходят ли исходный код и персональные данные в личные зарубежные аккаунты сотрудников.
Для бизнеса это означает, что внедрение ИИ нельзя измерять числом оплаченных подписок или объёмом сгенерированного кода. Нужны понятные правила: какие данные допустимо отправлять во внешние сервисы, кто отвечает за результат, как меняется ревью, где хранятся артефакты работы и какие задачи нельзя автоматизировать без проверки. Если сокращать людей, которые держат контекст, одновременно с ростом потока машинно созданных изменений, следующий инцидент окажется некому разбирать. Экономия на штате быстро превращается в дефицит тех, кто способен отличить правдоподобный ответ модели от корректного решения.
Для разработчиков и стажёров вывод тоже не сводится к призыву «освоить промпты». ИИ способен ускорить поиск, черновики, исследования и рутинные фрагменты кода, но не заменяет понимание предметной области, архитектуры и причин, по которым система работает именно так. Сеньоры нужны не как живой поисковик, а как носители инженерного суждения; стажёрам нужна обратная связь, а не только генератор следующей версии коммита. Иначе команда получает быстрый старт, но теряет механизм профессионального роста.
Главный вопрос теперь не в том, использовать ли нейросети: этот выбор многие сотрудники уже сделали без корпоративной программы. Вопрос в том, сумеет ли компания превратить внедрение ИИ в управляемое изменение процесса, а не в гонку за количеством строк и обещаниями трёхкратной эффективности. Когда инструмент снимает часть рутины, освободившееся время стоит вкладывать в качество решений, документацию и разговор о продукте — иначе авария будет не метафорой.
