Колонка Rust-разработчика о том, что ИИ в разработке не столько забирает работу, сколько меняет ее на менее романтичную, за сутки собрала около 12 тысяч просмотров. В тексте автор спорит не с самой идеей ассистентов, а с иллюзией, что быстрый diff автоматически означает быструю поставку в прод.
Материал опубликован 25 сентября в разделе «Карьера» на Habr / Карьера: автор Никита пишет, что не боится сценария, где модель «получит его должность». Его беспокоит другой вариант: кода станет дешевле и больше, а читать, проверять, чинить и сопровождать этот результат все равно придется людям. Для русскоязычных команд это знакомая боль: план уже хотят считать по скорости генерации, а ответственность остается на ревьюере, платформенной команде и дежурном инженере.
Главный тезис простой: считать нужно не время до первого ответа модели, а время до рабочего изменения. Агент может за пять минут выдать патч, но до этого ему надо передать контекст, объяснить правила проекта, дать ограниченный доступ к инструментам, а после генерации — прочитать diff, запустить проверки и понять, не уехало ли старое поведение. В статье приводится исследование METR 2025 года: участникам казалось, что ИИ ускорил работу на 20%, но по фактическому таймеру задачи заняли на 19% больше времени. Это не приговор всем инструментам, но хороший холодный душ для отчетов в стиле «мы купили лицензии, значит, производительность выросла».
Вторая проблема — инфраструктура. У веб-приложения уже были сайт для человека и API для другого кода. С агентами появляется еще один вход: инструменты с описаниями, схемами параметров, правами и логами. Автор приводит MCP как пример слоя, который помогает подключать внешние возможности к модели, но не заменяет существующий API. Создание задачи в трекере остается кнопкой в интерфейсе и методом API, а теперь становится еще и инструментом для агента. Функциональность та же, точек поддержки больше. Продукт от этого не получил новую кнопку счастья, зато команда получила еще один контракт, который надо тестировать и синхронизировать.
Отдельный кусок работы — harness, то есть окружение, в котором агент может ошибаться без дорогих последствий. В него входят инструкции проекта, sandbox, компилятор, линтеры, CI, тесты и правила доступа к репозиторию. Отчет агента в духе «задача выполнена» ничего не доказывает: важны exit code, реальные тесты и сам diff. Особенно ценными становятся старые регрессионные тесты, потому что они фиксируют поведение, существовавшее до правки. Если агент одновременно пишет код и тест к нему, он может красиво закрепить собственное непонимание требования. Зеленый CI после удаления неудобного assert — это не качество, а фокус с табличкой.
ИИ в разработке также расширяет поверхность атаки. Автодополнение раньше предлагало текст, а агент уже может запускать команды, ставить зависимости, читать файлы и ходить во внешние сервисы. В статье упоминается slopsquatting: модель придумывает несуществующий пакет, атакующий публикует пакет с таким именем, а разработчик или сам агент устанавливает уже настоящую вредоносную зависимость. В исследовании USENIX Security 2025 авторы получили 205 474 уникальных имени несуществующих пакетов в 576 тысячах сгенерированных примеров кода. К этому добавляются секреты в логах, токены в контексте и prompt injection из issue, README или ответа внешнего инструмента.
Есть и менее драматичный, но более ежедневный риск: дешевый код размножается. Генератору проще добавить рядом еще одну реализацию, чем разобраться в старой. Автор ссылается на отчет GitClear за 2025 год, где разобраны 211 млн измененных строк: с 2020 по 2024 год доля copy/paste внутри коммита выросла с 8,3% до 12,3%, churn новых строк за две недели — с 3,1% до 5,7%, а доля перемещенного кода снизилась с 24,1% до 9,5%. Эти данные не доказывают, что виноват именно ИИ, но направление неприятное: писать стало проще, а сопровождать все копии — нет.
Для бизнеса соблазн понятен. Лицензии, токены, принятые подсказки и долю ИИ-кода легко показать в презентации. Время доставки, количество откатов, инциденты и стоимость ревью выглядят скучнее, зато ближе к реальности. Если adoption превращается в KPI, команда начинает играть в метрику: принимает подсказки, переписывает их руками, генерирует тесты пачками и гоняет агента по мелочам. График растет, продукт не обязательно становится лучше.
Практический вывод из этой дискуссии не в том, что агентам надо запретить вход в репозиторий. Скорее наоборот: ИИ в разработке нормально работает там, где задача ограничена, проверки быстрые, права урезаны, а архитектура не держится на устной традиции одного сеньора. В хаосе агент не превращает джуна в мидла и не чинит медленный CI; он просто быстрее подает новые изменения в ту же мясорубку. Следующий спор в командах, похоже, будет не о том, «заменит ли ИИ программиста», а о том, кто оплатит обслуживание машины, которая теперь тоже пишет код.