Среда, которая не работает — зависимости как отдельная ось качества кода
Саммари
Кодинг-агент выдаёт функционально правильный проект — и проект не запускается на другой машине. Работа выделяет спецификацию окружения как самостоятельную ось качества генерации кода, независимую от функциональной корректности, и измеряет её через трёхслойный фреймворк: объявленные зависимости, зависимости, установленные рантаймом, и необходимые и достаточные. Ключевой результат: согласие по множеству зависимостей между агентами падает до 7% на одинаковых задачах, и более новые агенты не показывают содержательного улучшения.
Из этого следует: «проект работает у меня» — не тестовое утверждение, а стохастическое. Согласие 7% означает, что при одинаковой задаче два агента дают два несовместимых окружения, и корректность здесь почти случайна.
На практике для Revit: add-in — это ровно случай «код правильный, а у пользователя не запускается». Зависимости Revit API (.NET 8 или .NET 10, версия Revit, SDK-переменные среды) — классический случай, где объявленное и реальное разойдутся, и проверка должна быть отдельной осью, а не приложением к тестам функций.
Важный нюанс: цифра 7% — это согласие между агентами, а не вероятность успеха. Это важное различие: стопроцентное согласие между тремя агентами всё равно могло бы означать общую ошибку. Метрика измеряет согласованность, а не истинность.
Второй нюанс: расхождение между declared и runtime-installed указывает на priors модели, а не на слабость инструментов. Значит, промпт-указание «объяви точные зависимости» вряд ли поможет — нужно либо измерять, либо переносить проверку в среду исполнения.
Третий нюанс: «более новые агенты не лучше» — сильный сигнал против стратегии «обновим модель и всё починится». Качество спецификации окружения — свойство парадигмы, а не версии.