EnglishРусский Map

Агентное программирование меня выжигает

title
Агентное программирование меня выжигает
type
summary
summary
0xsid об усталости от решений как скрытом барьере: психология gacha-петли, сломанный темп и регресс верификации верификаторов
tags
llm, ai-agents, vibe-coding, software-quality, critique
created
2026-05-02
updated
2026-09-13
lang
ru
source_updated
2026-09-13
translated
2026-09-14
translator
lllm/antigravity/gemini-3.7-flash-medium

Короткая заметка 0xsid за май 2026 года, в которой утверждается, что агентное программирование сжимает естественный ритм работы над софтом в непрерывный поток решений с переменным вознаграждением, и что главным ограничением продуктивности становится уже не скорость набора кода, а ментальная выносливость оператора.

cognitive-debt рассматривает ту же проблему со стороны понимания: 0xsid описывает истощение ресурсов, а исследование MIT - деградацию навыков. Рецепт Османи (сначала сформулировать гипотезу, попросить объяснить логику до генерации кода, воспроизвести вручную) служит практическим ответом сразу на оба вызова.

Слом темпа

Традиционное программирование содержало фазы восстановления прямо в процессе. Связывание компонентов, написание очевидного связующего кода (glue), перестройка импортов - всё это были передышки между сложными задачами. При этом они выполняли реальную работу: формировали ментальную модель, на которую опиралось следующее трудное решение. Когда задачи выполняются вручную, контекст накапливается как побочный эффект самого процесса исполнения.

Агенты избавляют от рутинного связывания и оставляют только принятие решений. Код "просто появляется перед глазами" - 0xsid приводит аналогию с татуировками из Memento, когда каждая сессия начинается с нуля, потому что вы не прожили процесс сборки. Модель удерживает контекст, который человек так и не успел выстроить.

Gacha-петля

В посте надзор за агентами называется "чередой психологических вознаграждений с переменным подкреплением, за которой следует когнитивная усталость" - напрямую сравниваясь с механикой gacha или игровых автоматов. Иногда агент решает сложную задачу с первой попытки (one-shot); иногда выдаёт нечто с малозаметными скрытыми дефектами. Непредсказуемый график отдачи в точности повторяет схему, которую казино используют для вовлечения игроков.

Это стоит в одном ряду с ai-sycophancy-loop и концепцией "киберпсихоза" - обе описывают системы, которые создают ощущение продуктивности, незаметно ухудшая способность здраво судить о вещах. Вклад 0xsid заключается в том, что он назвал сам механизм: переменный график вознаграждений вкупе с операционной неопределённостью. В prolific-ai-psychosis используется тот же образ игрового автомата и указывается самый опасный случай: проигрыш, который выглядит точь-в-точь как выигрыш.

Усталость от решений как потолок

Кульминация поста - простая арифметика. Обычное традиционное программирование позволяет выдерживать "от восьми до десяти продуктивных часов". Контроль над агентами выматывает оператора за "четыре-пять предельно напряжённых часов". Знакомые автора уже выгорают и не говорят об этом вслух - 0xsid утверждает, что видит это по тому, как они подходят к проектам.

ai-superpowers-focus-followthrough упирается в ту же стену, но считает не решения, а проекты. Рик Манелиус (Rick Manelius) с помощью агентов закрывал обязательные рабочие задачи, а освободившееся пространство забил примерно 40 одновременно запущенными pet-проектами с проверкой концепций (proof-of-concept) - и каждый превратился в незавершённый цикл, требующий внимания. То же самое истощение, только вызванное аппетитом, а не самим надзором.

Механизм здесь - постоянное переключение контекста плюс гораздо более высокая частота принятия решений в час. Архитектурные и концептуальные решения при контроле над "бешеным джуном" ("cracked junior dev") оказываются тяжелее самостоятельного выполнения стандартных задач разработки, поскольку каждая пауза на проверку сбивает темп. Когнитивная нагрузка не масштабируется параллелизмом: запуск большего числа агентов не добавляет вам внимания.

Утрата операционного контроля

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

Та же претензия, которую Кантрилл предъявляет со стороны предложения в peril-of-laziness-lost (у LLM нет человеческого дефицита времени, подталкивающего к простоте), и та же, которую высказывает Брэм Коэн по поводу принципиального отказа читать код. 0xsid формулирует её со стороны спроса: даже при искреннем желании проводить ревью пропускная способность кода превышает способность человека делать это качественно.

Проблема верификатора верификаторов

Очевидный ответ - "стройте более качественные циклы ревью и проверки" - упирается в бесконечный регресс. Кто создаёт верификатор? Если LLM, приходится доверять системе проверки, созданной тем самым инструментом, чьим основным результатам вы не доверяете. А затем приходится верифицировать, что сама система проверки проверяет нужные части и тестирует их корректно. 0xsid не претендует на готовый ответ.

Это более мягкая версия проблемы византийского отказа, применённая к инструментарию: сбоящий валидатор хуже отсутствия валидатора, поскольку порождает ложную уверенность. Это та же рекурсия доверия, из-за которой усложняется supply-chain-security в сфере ИИ.

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

Ветка критики LLM в вики теперь рассматривает это наблюдение с трёх сторон:

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

building-syntaqlite-ai - живой практический пример: две фазы у Маганти описывают в точности gacha-петлю и выход из неё (возврат контроля над архитектурой человеку). ai-assisted-workflow - один из предлагаемых способов смягчения: выносить обдумывание на начальный этап, чтобы каждый вызов агента был небольшим проверяемым шагом, а не броском монеты в игровой автомат.

Тезис "average is all you need" служит оптимистичным зеркалом: если согласиться с тем, что базовый уровень растёт, а дефицитным ресурсом становится фильтрация, то претензия 0xsid - это описание дефицитного ресурса. Не изъян системы, а жёсткое ограничение на то, какой объём фильтрации способен выполнить один человек за день.

Ларс Файе формулирует структурную версию проблемы верификатора верификаторов: роль проверяющего опирается на навыки, которые размываются самой практикой поднадзорной работы. Блок материалов вокруг этой замкнутости собран на отдельной странице skill-atrophy-supervision-paradox.