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