ИИ не заменяет разработчиков, но создает новую, утомительную рутину: почему скорость генерации обманчива
Согласно новым данным исследования METR 2025 года, разработчики主观но чувствуют рост производительности на 20% благодаря использованию ИИ-агентов, однако объективные таймеры фиксируют увеличение времени на выполнение задач на 19%. Эксперты отмечают, что вместо устранения рутинных операций, технологии генерации кода лишь удваивают инфраструктурную нагрузку, создавая сложные слои проверки и безопасности, которые приходится обслуживать людям.
# Я не боюсь, что меня заменит ИИ. Я боюсь работать с ИИ
Тема искусственного интеллекта часто вызывает страхи о потере работы. Однако для многих инженеров реальная угроза кроется не в исчезновении должностей, а в трансформации ежедневной рутины. Вместо того чтобы работать с чистым кодом, специалисты вынуждены тратить время на чтение чужих диффов, построение сложной инфраструктуры вокруг агентских систем и отчитываться по токенам, а не по реальному продукту.
В этой статье мы разберем, почему ощущение скорости от ИИ-инструментов является иллюзией, и как эти технологии меняют архитектуру программного обеспечения, заставляя команды поддерживать дублирующую инфраструктуру.
Иллюзия экономии времени
Популярный мем гласит, что ИИ — это «умный стажер», который делает всю черную работу, позволяя опытным разработчикам заниматься только сложными задачами. Однако статистика опровергает эту романтическую картину.
В исследовании METR 2025 года участники экспериментов субъективно оценивали ускорение своей работы в 20%. При этом фактическое время выполнения задач росло на 19%. Разница заключается в том, как мы измеряем эффективность.
Когда вы видите, как агент за минуту генерирует код вместо часа ручной работы, кажется, что экономия очевидна. Но процесс разработки программного обеспечения — это не только написание функционала. Это цикл, включающий: 1. Подготовку контекста: передача модели знаний о проекте, соглашениях и зависимостях. 2. Верификацию: чтение сгенерированного кода, поиск нетривиальных решений и анализ изменений в нецелевых модулях. 3. Исправление ошибок: повторение цикла генерации для упрощения результата. 4. Интеграцию: запуск сборки, тестирование и ревью.
Агент ускоряет лишь один этап — написание первичного варианта кода. Остальные этапы остаются неизменными или даже усложняются. В результате, реальное время до рабочего изменения часто превышает время работы человека вручную.
Удвоение инфраструктуры: проблема harness
Появление автономных агентов требует от проектов создания нового слоя абстракции, который часто называют *harness*. Это окружение, которое задает границы для модели, предоставляет инструменты и проверяет результат.
Для работы агента необходим специальный набор компонентов: * Инструкции: файлы вроде CLAUDE.md или AGENTS.md, описывающие правила работы. * Sandbox: изолированная среда для выполнения кода. * Компиляторы и линтеры: инструменты, которые должны уметь давать понятные ошибки машине. * CI/CD: системы непрерывной интеграции, способные работать в циклическом режиме с моделями.
В типичном веб-приложении уже существуют два интерфейса: сайт для человека и API для других программ. С приходом агентов появляется третий клиент. Функционал дублируется: методы API превращаются в инструменты для моделей с понятными описаниями, а доступы к репозиторию требуют отдельной настройки через протоколы, такие как MCP (Model Context Protocol).
Это означает, что одна и та же бизнес-логика должна поддерживаться в нескольких формах. Если в бэкенде вносят изменения, нужно синхронизировать их не только в API и интерфейс, но и в описание инструментов для ИИ. Архитектура усложняется без прироста новых возможностей для конечного пользователя.
Что такое MCP?
MCP (Model Context Protocol) — это стандартный интерфейс, который позволяет ИИ-моделям подключаться к инструментам и данным. Представьте, что MCP-сервер — это переводчик, который объясняет модели, как работать с вашей базой данных или системой управления задачами, предоставляя безопасный доступ без раскрытия внутренних ключей.
Усиление хаоса и новые уязвимости
Принцип работы ИИ-агентов заключается в усилении того, что уже есть в проекте. Если архитектура чистая, есть строгие типы и хорошие тесты, агент помогает быстрее находить решение. Если же в проекте хаос, отсутствие тестов и неясные зависимости, агент лишь ускорит накопление ошибок.
Данные компании GitClear показывают тревожную тенденцию: с 2020 по 2024 год доля копипасты внутри коммитов выросла с 8,3% до 12,3%, а количество перемещаемого кода сократилось. Генератору проще дописать новую реализацию рядом с устаревшей, чем разобраться в контексте и рефакторить старый код. Это приводит к надуванию объема репозитория и увеличению количества багов.
Безопасность также страдает от появления нового контура атаки. Раньше ошибка модели могла привести к странному коду, но не к прямому исполнению вредоносных действий. Теперь ситуация изменилась:
* Словесные подделки (Slopsquatting): модели могут предлагать установку несуществующих библиотек. Атакующий регистрирует пакет с таким же названием и вставляет вредоносный код, который затем устанавливается при следующей генерации. * Раскрытие секретов: агент получает контекст из файлов и логов. Если туда попало слово «пароль» или токен, модель может их сгенерировать. Правила «не показывать секреты» могут быть нарушены, если модель решит, что это необходимо для выполнения задачи. * Встраивание команд (Prompt Injection): инструкции для модели могут находиться не в прямом запросе пользователя, а в README, issue трекера или ответе другого агента. Модель может принять внешние данные за команду, что приведет к выполнению несанкционированных действий.
Метрики, которые ничего не значат
Когда компании внедряют ИИ, руководство требует отчетов об эффективности. Возникает соблазн использовать удобные метрики, предоставленные платформами, такими как Copilot или GitHub.
Часто в отчеты попадают такие показатели, как: * Доля кода, написанного ИИ. * Количество принятых подсказок. * Траты на токены.
Эти метрики легко накручиваются. Разработчик может тратить час на решение задачи, но если ИИ сгенерировал 90% решения и он его принял, это зачтется как высокая эффективность. Напротив, специалист, который долго думал и написал код вручную, может выглядеть как саботажник в отчетах. Это приводит к тому, что команды начинают оптимизировать цифры, а не качество кода: агентов просят форматировать файлы или писать бессмысленные тесты ради статистики.
Вместо того чтобы оценивать время доставки функционала, количество инцидентов и качество архитектуры, фокус смещается на количество потраченных ресурсов ИИ. Закон Гудхарта здесь работает на благо метрик: «Когда вы измеряете то, что вы знаете, а не то, что важно, вы получаете то, что хотите».
Вывод: агент усиливает, но не меняет
ИИ-агенты не отменяют необходимость верификации кода. Бинарники, сгенерированные моделью, все равно требуют сборки, тестирования и анализа безопасности. Источником кода становится не человек, а вероятностная модель, но процесс контроля качества остается на людях.
Технологии ИИ не являются панацеей для плохой инженерной культуры. Они выступают как усилитель: хорошие практики становятся еще более эффективными, а плохие — еще более разрушительными. Разработчики должны готовиться к работе с новыми слоями инфраструктуры, безопасности и контроля качества, понимая, что скорость генерации не равна скорости создания ценности.
В конечном счете, проблема не в замене человека, а в том, чтобы не превратить разработку в бесконечный цикл обслуживания чужих диффов и токсичных метрик.