Агентное программирование - это ловушка

Аргументы Ларса Файе против идеи "разработки на основе спецификаций, где реализацию берут на себя агенты". Главный довод - замкнутый круг: для эффективного контроля за агентами требуются навыки критического мышления и понимания кода, которые активное использование агентов заметно разрушает. Файе сопоставляет это с тремя другими издержками, о которых индустрия предпочитает умалчивать, - общей атрофией навыков среди разработчиков, вендорлоком и волатильностью стоимости токенов.

Парадокс надзора

Вся модель "человек как оркестратор агентов" держится на людях, способных вычитывать тысячи строк сгенерированного кода и отлавливать ошибки. Файе приводит задокументированные свидетельства того, что именно эти навыки быстро деградируют при работе с агентами: собственное исследование Anthropic показало падение навыков отладки на 47% при агрессивном внедрении ИИ в рабочих процессах; технический директор LinkedIn посоветовал своей команде избегать агентных инструментов во всём, что требует критического мышления. Simon Willison с почти 30-летним стажем отметил, что начинает терять "чёткую ментальную модель того, на что способны приложения и как они работают". Хуже всего приходится джуниорам: проверка сгенерированного кода учит куда меньше, чем его написание.

Это та же рекурсия доверия, которую 0xsid описывает в agentic-coding-fatigue через концепцию "проверяющего для проверяющего". Файе прямо указывает на противоречие: роль оркестратора требует постоянного притока компетентных специалистов, но ежедневная практика этой роли уничтожает их источник.

Код как мышление

Файе подхватывает мысль Dax (создателя OpenCode) - "набор кода - это процесс, в ходе которого я вообще понимаю, что нам нужно делать", - утверждая, что для многих задач код является средой мышления, а не просто его результатом. Замена набора кода спецификацией лишь смещает неопределённость: теперь LLM заполняет пробелы домыслами, вы сжигаете токены на итерации ревью и в итоге оказываетесь дальше от понимания системы, чем были в самом начале.

Это аналог концепции "добродетельной лени" Кантрилла со стороны спроса: нехватка человеческого времени вынуждает всё упрощать, и именно процесс написания кода создаёт это давление. Избавьтесь от написания - и ограничение исчезнет.

Перевёрнутые приоритеты

Приоритеты доагентной эпохи (понимание кода, следование стандартам, лаконичный читаемый код, разумные сроки) оптимизировали систему под осмысление. Агентное программирование выворачивает этот список: скорость на первом месте, объём важнее качества. Файе объясняет эту инверсию организационными стимулами и метриками расхода токенов, а не самими инструментами. История с метриками повторяет то, о чём говорится в ceo-ai-psychosis (рейтинги tokenmaxxing) и что в ai-great-leap-forward сравнивается с культом выплавки стали в кустарных печах.

Зависимость от вендоров

Две статьи расходов, которые сторонники подхода на основе спецификаций часто упускают:

• Риск простоев из-за сбоев. Недавние сбои в Claude парализовали работу целых инженерных команд - разительный контраст с временами, когда "нужны были только клавиатура и редактор". Подписки стали критически важным звеном.
• Волатильность стоимости токенов. Расходы здесь не фиксированы, как зарплаты: они меняются с каждым релизом моделей. Файе ссылается на отчёты, согласно которым новым релизам часто требуется в 2-3 раза больше токенов для достижения прежнего качества. Провайдеры субсидируются, поэтому реальное ценовое дно находится вовсе не там, где предполагают пользователи.

Это операционная сторона аргумента из subprime-ai-crisis / ai-subsidy-economics: на уровне команды зависимость от субсидируемого поставщика означает, что тарифный счётчик может измениться в любой момент без вашего ведома.

Ответственный подход

Файе не призывает к полному отказу. Его рецепт - более жёсткие рамки:

• Использовать LLM для мозгового штурма по спецификациям, но держать реализацию в своих руках (от 20% до 100% вручную в зависимости от задачи)
• Писать псевдокод для связки намерений со сгенерированным результатом
• Делегировать только разовые задачи и поиск по документации
• Никогда не генерировать больше кода, чем получается отрецензировать за одну сессию
• Не позволять агентам реализовывать паттерны или предметные области, в которых вы сами ещё не разбираетесь

Правило "ревью за одну сессию" - это, по сути, ограничение человеческого предела из agentic-coding-fatigue, превращённое в рабочий регламент. Правило "не делегировать незнакомые паттерны" - это сценарий провала, с которым столкнулся Маганти на этапе своего увлечения vibe-coding'ом.

Его собственная оценка: "Я не стал работать быстрее, но делаю работу качественнее". Цитата Jeremy Howard, которой он завершает: "Люди, которые сейчас делают ставку исключительно на ИИ-агентов, гарантируют собственное устаревание".

Место в общей картине

Кластер критики агентного программирования в базе знаний теперь включает четыре взгляда на одно и то же наблюдение:

• peril-of-laziness-lost - философский: у LLM нет ограничения по времени, присущего человеку, которое стимулирует простоту
• no-silver-bullet-llms - теоретический: генерация кода не является узким местом, им остаётся сущностная сложность
• agentic-coding-fatigue - операционный: дневной предел супервизора составляет 4-5 часов
• Этот материал - структурный: роль проверяющего разрушает навыки, которые для неё необходимы; вендорлок и волатильность токенов выступают реальными вторичными издержками

cult-of-vibe-coding выступает процедурным аналогом с противоположной стороны: подход Коэна "аудит - обсуждение - выполнение" - это именно тот рабочий процесс, который подразумевает "ответственный подход" Файе. ceo-ai-psychosis описывает патологию на уровне руководства, на которую реагирует довод Файе об организационных стимулах. clean-code-coding-agents даёт техническое обоснование, почему удобный для агентов код остаётся важным, даже если полностью принять критику Файе.

Отдельная страница понятий skill-atrophy-supervision-paradox детально разбирает эту замкнутость, поскольку к ней сходятся сразу несколько источников.