Деградация под ограничениями

Constraint decay (деградация под ограничениями) - это паттерн, при котором кодинговый LLM-агент показывает отличные результаты на слабо специфицированной задаче, но теряет около 30 процентных пунктов успешных проверок (assertion pass rate) по мере накопления структурных ограничений продакшена: архитектуры, баз данных, ORM и конвенций фреймворка. Термин ввели Francesco Dente, Dario Satriani и Paolo Papotti в статье на arXiv за 2026 год, где это явление измерили напрямую; само исследование описано в constraint-decay-backend-agents.

Этот термин проводит границу между двумя типами требований. Функциональные требования определяют, что код должен делать (этот endpoint возвращает такие-то записи). Структурные требования задают, как именно он должен быть устроен (использовать эту ORM, этот паттерн репозитория, эту базу данных, соглашения этого фреймворка). Агенты отлично справляются с первой задачей, если им дают свободу в выборе структуры. Но стоит загнать их в рамки конкретного стека - и доля пройденных тестов падает, порой почти до нуля у наиболее слабых конфигураций. Выполнение обоих типов требований одновременно пока остаётся нерешённой проблемой.

С этим явлением связаны две закономерности. Фреймворки с большим количеством конвенций (FastAPI, Django) даются агентам тяжелее минималистичных (Flask), так как львиная доля "правильного" решения кроется в правилах, которые нужно соблюдать, а не изобретать. Кроме того, сбои концентрируются в слое данных: лидируют некорректно составленные запросы и рантайм-ошибки ORM, а не, скажем, баги в роутинге или сериализации. Это согласуется с общим наблюдением, что именно при работе с базами данных агенты сильнее всего отклоняются от реальных требований проекта.

Constraint decay - это конкретное, измеренное подтверждение давнего тезиса из no-silver-bullet-llms о том, что качество выдачи LLM падает по мере удаления от хорошо задокументированного среднего. Полевой отчёт Alex Ellis в local-ai-is-not-opus описывает ту же картину глазами практика: локальные модели умеют читать и объяснять кодовую базу, но пасуют перед задачами на длинном горизонте, скованными строгими конвенциями. Практический вывод из этого сформулирован в reviewing-ai-code: именно структурные ограничения ревьюер обязан проверять в первую очередь, поскольку уверенность самого агента никак не коррелирует с тем, соблюдал он их или нет.