Колонка на Habr / Карьера с охватом 12K попала в нерв отрасли: автор объяснил, почему ИИ в разработке у него вызывает не восторг, а раздражение. Для русскоязычной IT-аудитории это важный сигнал: спор уже давно не о том, умеют ли модели писать код, а о цене такой помощи для качества, скорости и головы самого разработчика.
Как пишет Habr / Карьера, автор текста Arseny88 описывает знакомую для многих команд картину: менеджеры подталкивают или прямо требуют использовать ИИ-агентов, внутри компаний идут воркшопы, появляются инструкции по настройке окружения, а вокруг темы формируется почти обязательный корпоративный оптимизм. Обещание звучит соблазнительно: меньше рутины, меньше шаблонного кода, меньше тестов, больше скорости. На практике автор получил другой результат. На подробные промпты уходит заметное время, иногда сопоставимое с ручной реализацией, а на выходе появляется код, который формально может работать, но регулярно оказывается многословным, избыточным и плохо встроенным в реальные стандарты проекта.
Главная претензия в колонке не сводится к банальному «модель ошибается». Автор бьет по более неприятному месту: ИИ в разработке делает результат недетерминированным. Когда инженер пишет код сам, он хотя бы понимает, к чему идет и какие ограничения держит в голове. Когда задачу отдают агенту, каждый прогон превращается в лотерею: не будет ли использован несуществующий метод, не появится ли выдуманная библиотека, не решит ли система заодно «улучшить» соседние классы и переписать то, о чем никто не просил. Даже удачный результат не снимает проблему, потому что доверять ему вслепую нельзя. Значит, нужно проверять все, а разбор чужого, тем более сгенерированного кода, почти всегда тяжелее, чем написание собственного.
Отдельно автор проходится по тестам, и здесь его аргумент звучит особенно болезненно для команд, где качество держится на покрытии и дисциплине. Несмотря на наличие примеров в проекте, агент, по его словам, генерирует массу лишней обвязки: моки, сетапы, билдеры, инфраструктурный шум. При этом сами тесты нередко либо ничего толком не проверяют, либо не компилируются, либо расходятся с логикой основного кода. Для менеджера в презентации это может выглядеть как ускорение: машина написала сразу и фичу, и тесты. Для разработчика на земле это часто означает обратное: нужно вычищать мусор, перепроверять логику, чинить падения и заново собирать ясную структуру там, где модель оставила расплывчатый след.
Именно здесь критика ИИ в разработке выходит за пределы вкусовщины. Речь не только о стиле кода и не только о том, что агент написал 40 строк там, где опытный инженер уложился бы в 20. Речь о когнитивной нагрузке. Автор прямо пишет, что доведение нейросгенерированных изменений до уровня, пригодного для прода, занимает не меньше, а иногда и больше времени, чем ручная работа. Причем это утомление другого типа: не созидательное, а ревизорское. Вместо того чтобы решать задачу, человек часами просеивает «нейрослоп», пытаясь понять, где модель просто болтлива, а где уже спрятала архитектурную ошибку или потенциальный баг. Такой режим сложно продавать команде как продуктивность, особенно если после восьми часов не остается ресурса ни на размышление, ни на нормальный код-ревью.
В этом сюжете важен и управленческий слой. Корпоративный рынок сейчас активно институционализирует ИИ в разработке: не как личный инструмент по желанию, а как почти обязательную норму. Из текста видно, что раздражение автора вызвано не только качеством генерации, но и разрывом между маркетинговым обещанием и реальной операционной практикой. Снаружи все выглядит как движение к более эффективной инженерии. Внутри команды это может обернуться ростом числа итераций, повышенными требованиями к проверке, размыванием ответственности и скрытым конфликтом между менеджерским KPI на «внедрение ИИ» и фактической стоимостью сопровождения такого кода. Если раньше спорили о том, заменит ли модель джуна, то теперь куда интереснее вопрос, не превращает ли она мидла или сеньора в уставшего редактора машинного текста.
Для бизнеса здесь тоже есть неприятный вывод. Если использование агентов дает нестабильный результат, выигрывает не тот, кто быстрее всех закупил доступ к моделям и разослал сотрудникам гайд по промптингу, а тот, кто научился ограничивать зону их применения. Из колонки читается простая мысль: ИИ полезен там, где цена ошибки низкая, контекст короткий, а результат легко проверить. Но когда речь идет о живом проекте с архитектурными оговорками, историческими компромиссами и кучей негласных правил, модель начинает создавать не только код, но и дополнительную работу по его интерпретации. Для стартапа это риск ложного ускорения. Для крупной компании это риск системно умножить объем малопонятных изменений, которые потом придется дорого обслуживать.
Текст Arseny88 вряд ли закроет спор об ИИ-агентах, но он хорошо фиксирует сдвиг в профессиональной дискуссии. Восторг от самого факта генерации кода проходит, и на первый план выходят вопросы доверия, предсказуемости и ментальной цены автоматизации. Если отрасль продолжит измерять успех внедрения только количеством воркшопов, лицензий и строк, написанных моделью, она может получить не новую производительность, а новую форму усталости, в которой код вроде бы пишет машина, а выгорает по-прежнему человек.