Суть
Разделение видно на программировании. Выбрать архитектуру отказоустойчивого высоконагруженного приложения — чистый judgment: у человека либо есть опыт десятка таких систем, либо нет, и правилом «при таких условиях бери PostgreSQL» это не заменяется. Написать код по подробной спецификации от старшего — уже intelligence: решений много, но все внутри понятного протокола.
Внутри intelligence-задачи агент принимает огромное число микрорешений — как назвать переменную, как разбить на классы. Все они в понятных рамках, и именно поэтому работает.
Почему агенты не берут judgment — две технические причины
Нечего положить в контекст. Разработка агента — это в основном работа с контекстом: положить в нужный момент нужную информацию. Для intelligence-задачи понятно, что класть: регламент, документацию, примеры, текущее состояние. Для judgment класть нечего — двадцать лет опыта в промпт не записываются (Context Layers).
Нечем мерить. Без метрик качества агент в продакшен не уедет. В intelligence-задаче есть протокол, и можно оценить, насколько агент ему следует. В judgment-задаче протокола нет, и любая попытка построить метрику превращается в спор экспертов, которые сами друг с другом не согласны (Quality Metric Design).
Правильное разделение труда
Опытные разработчики не пишут «представь, что ты эксперт с двадцатилетним опытом». Они пишут детальную спецификацию: архитектура, модули, интерфейсы, тесты — и только потом отдают задачу. Старший взял на себя judgment, свёл задачу агента к чистому intelligence и проверяет результат в рамках своей спецификации, а не пытаясь оценить, хороший ли это код вообще.
Обратный сценарий ломается предсказуемо: когда не-разработчик пишет продукт через агента, на сложном месте агент вынужден сам сделать judgment-выбор. Он его сделает — но не так, как эксперт, и никто не проверит.
Тест на пригодность процесса
Практическая проверка занимает час: сесть и попробовать написать регламент — что делать, куда ходить, как принимать решения, что считать хорошим результатом.
- Получилось — это intelligence, агент справится.
- Получилось плохо — либо в процессе бардак (тогда чинить надо бардак, а не ставить агента), либо это judgment.
Второй исход — самый ценный результат теста: он экономит проект, который иначе будет полгода упираться в невозможность формализовать предмет.
Связано с
- Agent Use Cases — где агенты оправданы на практике
- Autonomy Risk Profit — второй критерий выбора процесса
- Agent vs Workflow — форма исполнения после того, как процесс выбран
- Quality Metric Design — почему без протокола нет метрики
- Context Layers — что вообще кладётся в контекст
- Human in the Loop — куда девается judgment: остаётся человеку