Корневую проблему всей разработки ПО, которую LLM не решили — а только обострили.
Короткий ответ: да, люди не умеют объяснять. И это не их вина. Это фундаментальное ограничение того, как работает человеческое мышление и коммуникация.
Главный парадокс
Нефть не спрашивает «а куда ты хочешь, чтобы я текла?» Её заставляют законы физики.
Поезд не говорит «мне кажется, рельсы кривые» — он или едет, или сходит с них.
А программист (и LLM) каждый раз заново интерпретирует: «А что значит "быстро"? А что значит "удобно"? А что значит "правильно"?»
Почему люди не умеют объяснять
Причина 1. Мы думаем картинками, а объясняем словами
В голове у заказчика (или у вас) есть идеальный образ результата. Но когда вы начинаете его описывать:
- Вы теряете 80% деталей (они «очевидны»)
- Вы используете слова-хамелеоны: «надёжный», «масштабируемый», «интуитивный»
- Вы не замечаете противоречий: «быстро» и «дёшево» одновременно
Пример:
Заказчик: «Сделайте кнопку красной, чтобы привлекала внимание.»
Программист делает красную.
Заказчик: «Нет, не такую. Она кричит, а должна привлекать.»
Программист: «...»
Красный для одного — #FF0000, для другого — #990000, для третьего — «с оттенком терракоты».
Причина 2. Неявное знание (Tacit Knowledge)
Михаил Полани (химик и философ) доказал: мы знаем больше, чем можем сказать.
Вы умеете завязывать шнурки, но не можете описать алгоритм словами.
Вы узнаёте лицо друга в толпе, но не можете перечислить все признаки.
Вы чувствуете, что код «пахнет», но не можете формализовать это чувство.
Это же происходит с требованиями:
«Сделайте, как в том старом приложении, но лучше.»
«Ну вы же профессионалы, должны понять.»
«Я не знаю, как это описать, но когда увижу — пойму.»
LLM не имеет доступа к вашему неявному знанию. Она знает только то, что вы написали.
Причина 3. Проблема индукции (Юм)
Даже если вы описали идеально — вы описали прошлый опыт. А программа будет работать в будущих ситуациях.
Вы сказали: «При вводе числа от 1 до 10 делать X.»
LLM сделала.
Пользователь ввёл 11.
Программа упала.
Вы не объяснили, что делать с 11, потому что не подумали, что кто-то введёт 11. А пользователь ввёл.
Почему тестирование, ревью и переделки — это не баг, а фича
«Пэтому приходится тестировать, ревьюить, переделывать?»
Да. Именно поэтому.
Но важно: тестирование — это не исправление ошибок программиста. Это перевод неявного знания в явное.
Итерации — это не провал. Это способ превратить «я знаю, но не могу сказать» в код.
Что это значит для LLM и оркестрации агентов
Проблема не в LLM, а в спецификациях
LLM стремится создавать код по спецификации, опираясь на статистически частые примеры. Если спецификация "широкая" — код будет "творческий".
Люди думают: «LLM глупая, не поняла меня».
Реальность: «Я не смог объяснить».
Провокационный тезис: LLM не делает ошибок. Она делает статистически подходящее следование инструкциям.
Что делает оркестрация агентов с этой проблемой
TDD (тесты до кода) — это способ превратить «я хочу, чтобы работало» в формальное утверждение.
Spec-driven цикл — это принуждение вас к явному описанию.
MCP-серверы — это доступ к контексту, который вы забыли бы написать в промпте.
Автофикс крашей — это когда пользователь сделал то, о чём вы не подумали (ввёл 11), и система сама это чинит.
Оркестратор не решает проблему неявного знания. Он создаёт пайплайн, в котором неявное становится явным через итерации.
Что с этим делать (практически)
1. Признать, что «хорошо объяснить» — это и есть основная работа
Программист не пишет код. Программист переводит неявное знание в явное через диалог, прототипы, тесты, ревью.
LLM не меняет этого. Она просто ускоряет перевод.
2. Использовать итерации как метод, а не как признак провала
- Пытайтесь написать идеальный spec с первого раза, но не ожидайте что получится
- Напишите spec → получите код → уточните spec → получите код
- Это не «LLM тупит». Это «я уточнил требования»
3. Тестировать не код, а понимание
Если тест упал — значит, ваше объяснение было неполным. Хороший тест ловит не баг, а пробел в спецификации.
4. Учиться писать спецификации для LLM как для очень буквального джуниора
- Без «сделай красиво» (что значит красиво?)
- Без «как в прошлый раз» (в прошлый раз было по-другому)
- С примерами: «Если пользователь ввел 11, то показать ошибку»
- С граничными случаями: «А что если БД не ответила? А что если пользователь не авторизован?»
Итог:
Люди не умеют объяснять программистам (и LLM), что должно получиться, потому что:
Мы думаем картинками, а объясняем словами
Мы знаем больше, чем можем сказать (неявное знание)
Мы не можем предсказать все будущие ситуации
Поэтому приходится тестировать, ревьюить, переделывать.
Это не ошибка процесса. Это процесс перевода неявного в явное.
LLM и оркестрация агентов не решают эту проблему. Они делают итерации быстрее и дешевле.
Что раньше занимало неделю на одного программиста — теперь занимает час на агента. Но количество итераций не уменьшилось. Уменьшилось время итерации.
Ключевая компетенция как дирижёра — не писать код, а быстро и точно переводить неявное знание в явные спецификации. И учить агентов делать то же самое.
При создании задания для проектирования.планирования стоит опираться на уже проверенные методы. Сетевые графики, машины состояний и типобезопасность — это отличная основа. В дополнение к ним существует целый спектр формальных методов, которые можно рассматривать как «стройматериалы» для точного, недвусмысленного описания поведения системы, особенно если речь идет об оркестрации агентов .
Их ключевое преимущество — математическая строгость, позволяющая не просто описать, но и проверить свойства системы до того, как написан хоть один строка кода .
Вот несколько наиболее хороших «инструментов»:
1. Логические исчисления (для описания правил и времени)
Это язык для формулировки утверждений о системе, которые должны быть истинны всегда.
- Логика предикатов первого порядка: Позволяет описывать сложные инварианты и условия, например: «Все агенты, получившие задачу, должны иметь статус "активен"». Это база для любой формальной спецификации .
- Темпоральная логика (LTL, CTL): Незаменима для систем, которые живут во времени. Позволяет ответить на вопрос: «Верно ли, что если произошло событие А, то когда-нибудь в будущем обязательно произойдет событие Б?» Это идеальный инструмент для проверки свойств живых, реактивных систем .
2. Алгебраические спецификации (для описания типов данных)
Способ описания типов данных не через их внутреннее устройство (поля и методы), а через аксиомы, определяющие результат операций.
- Суть: Вы говорите «что» должна делать операция, а не «как». Например, для стека определяется, что pop(push(empty, x)) = x. Это позволяет реализовать тип данных множеством способов, сохраняя корректность .
- Где пригодится: Для задания четкой, независимой от реализации семантики обмена сообщениями между агентами.
3. Алгебры процессов (CSP, CCS) (для описания взаимодействий)
Это настоящий язык для описания общающихся систем. Алгебры процессов (CSP — Communicating Sequential Processes) позволяют моделировать систему как набор параллельных сущностей, которые обмениваются сообщениями по каналам .
- Для вашей задачи: Подходит для описания оркестратора, который рассылает задания, и агентов, которые на них отвечают. Позволяет формально верифицировать, не возникнет ли deadlock (взаимной блокировки) или livelock (бесконечного цикла обмена).
4. Сети Петри (для описания параллелизма и ресурсов)
Мощный графический и математический аппарат для моделирования систем с параллелизмом, синхронизацией и разделением ресурсов. Состоит из позиций (условия/ресурсы), переходов (события) и фишек (токены), которые перемещаются .
- Для вашей задачи: Вы уже рассматривали сетевые графики — сети Петри идут дальше. Они отлично подходят для моделирования пула агентов (ресурсов) и очереди задач. Позволяют выявлять узкие места и дефицит ресурсов .
5. Model Checking (проверка моделей) (для автоматической верификации)
Это не столько язык, сколько метод, который использует все вышеперечисленное. Вы создаете формальную модель системы (на одном из языков), формулируете свойства, которые хотите проверить (например, на темпоральной логике), и инструмент (model checker) автоматически исследует все возможные состояния системы, чтобы доказать или опровергнуть ваши утверждения .
- Для вашей задачи: Представьте, что перед тем как отдать задание агентам, вы прогоняете spec через model checker и получаете ответ: *«При таком сценарии 15% задач зависнут в ожидании ответа от MCP-сервера»*. Это мощнейший способ обнаружения логических ошибок на этапе проектирования.
Стремление к spec-driven циклу и типобезопасности — это первый шаг на пути к использованию формальных методов.
- Spec-driven цикл — это попытка приблизиться к формальной спецификации, где spec — это не просто текст, а формальный, верифицируемый документ.
- Типобезопасность — это один из самых простых и широко распространенных формальных методов, который уже встроен в компилятор.
Следующий шаг, который сделает вашу оркестрацию еще надежнее — это внедрение Model Checking для проверки ваших spec'ов, особенно в критически важных местах, где сложно предусмотреть все сценарии взаимодействия агентов.
1. OODA Loop (Observe-Orient-Decide-Act)
Откуда: Разработан полковником ВВС США Джоном Бойдом, используется в тактической авиации и управлении боем.
Суть: Цикл принятия решений быстрее, чем у противника. Побеждает тот, кто проходит цикл быстрее.
Как применить к агентам:
OODA — это идеальная архитектура для автономного агента :
Почему это важно: OODA даёт агенту цикличность, а не линейный «запрос-ответ». Агент не просто выполняет команду — он постоянно пересматривает ситуацию и корректирует действия.
Пример для вашей системы:
text
Observe: Crashlytics зафиксировал новый краш
Orient: Агент определяет, что крах связан с null pointer в модуле auth
Decide: Нужно добавить проверку на null в 3 местах
Act: Агент пишет код и отправляет PR
→ Loop повторяется: Observe проверяет, ушёл ли краш
2. HTN Planning (Hierarchical Task Network Planning)
Откуда: Классический метод AI-планирования, активно применяется в военных системах для автоматического планирования операций .
Суть: Высокоуровневая задача («захватить объект», «создать приложение») рекурсивно декомпозируется на подзадачи, пока не останутся только атомарные действия.
Как применить к агентам:
Вместо того чтобы давать агенту один огромный промпт «сделай приложение», вы даёте иерархию задач:
text
Создать приложение (top-level compound task)
├── Спроектировать архитектуру
│ ├── Определить сущности БД
│ ├── Спроектировать API endpoints
│ └── Выбрать технологии
├── Реализовать backend
│ ├── Создать модели БД
│ ├── Написать API handlers
│ └── Добавить аутентификацию
├── Реализовать frontend
└── Настроить CI/CD
Важный нюанс: Чистые LLM не могут гарантировать корректность иерархического планирования . Но их можно комбинировать с символическим HTN-планировщиком (как в ChatHTN): LLM генерирует «правдоподобную» декомпозицию там, где нет готовых методов, а символический планировщик проверяет и достраивает .
3. SCEPTER (DARPA)
Откуда: Программа DARPA для стратегического планирования в условиях хаоса .
Суть: Генерация и исследование тысяч вариантов действий (Courses of Action — COAs) с помощью goal-oriented агентов. Агенты исследуют пространство возможных действий в 10 000–100 000 раз быстрее реального времени для сценариев с 10 000+ агентов .
Как применить к агентам:
SCEPTER даёт методы управления комбинаторным взрывом при планировании:
Ключевая идея: Не пытайтесь смоделировать все возможные взаимодействия агентов. Используйте агрегацию и локальность, чтобы сложность оставалась управляемой.
4. Принципы Agile для военного планирования
Откуда: NATO и US Air Force активно адаптируют Scrum и Kanban для оперативного планирования .
Суть: Гибкие методологии (итеративность, короткие циклы обратной связи, адаптация к изменениям) критически важны для современного боя, где ситуация меняется быстрее, чем можно создать детальный план .
Как применить к агентам:
- Sprints (Scrum): Ваш утренний запуск → вечерняя ретроспектива — это спринт. Агенты работают итеративно, а не пишут всё за один раз.
- Kanban: Ограничение Work In Progress (WIP) для агентов. Не больше 3-х агентов одновременно пишут код в один репозиторий.
- Daily Standup: Автоматический отчёт агентов о прогрессе (через MCP в Slack/Telegram).
Кейс: US Air Force использует Agile для разработки ПО боевого управления (Kessel Run). Результат: поставка каждые 2 недели вместо 1 раза в 18 месяцев .
5. Mission-Oriented Agile & Commander’s Intent
Откуда: Военная доктрина NATO и современные системы управления боем .
Суть: Вместо детальных приказов задаётся замысел командира (Commander’s Intent) — конечная цель и границы допустимого. Подразделения сами выбирают тактику.
Как применить к агентам:
Вместо промпта на 5000 токенов с детальным планом вы даёте:
Commander’s Intent:
- Цель: Создать REST API для управления пользователями
- Приоритеты: Безопасность (JWT) > Надёжность > Скорость
- Границы: Не использовать ORM, только raw SQL
- Deadline: 5 часов
Агенты сами декомпозируют и выбирают способы достижения цели в рамках границ.
6. Марковские игры и кооперативное multi-agent RL
Откуда: Исследования DARPA и NATO по управлению роями дронов и распределению ресурсов .
Суть: Формализация взаимодействия нескольких агентов как марковского процесса принятия решений (Markov game) с функцией вознаграждения.
Как применить к агентам:
Вы определяете:
- State space (S): Текущий код, тесты, статусы задач, MCP-данные
- Action space (A): Действия агентов (написать тест, изменить код, запросить MCP)
- Reward function (R): Зелёные тесты → +10, упавший прод → -100, успешный PR → +50
Затем агенты (через multi-agent RL) обучаются оптимальной политике распределения задач, а не следуют жёстким правилам .
7. Agent-Based Modeling (ABM) для нелинейных сценариев
Откуда: Моделирование партизанской войны, городских боевых действий, финансовых рынков .
Суть: Система моделируется как множество взаимодействующих агентов с простыми правилами, а глобальное поведение возникает из локальных взаимодействий (bottom-up).
Как применить к агентам:
Используйте ABM для исследования пространства возможных сценариев, прежде чем выбирать финальный план:
- Запустите 10 000 симуляций вашего роя агентов с разными параметрами (размер команд, timeout’ы, приоритеты)
- Посмотрите, какие конфигурации приводят к deadlock’ам, а какие — к оптимальному времени выполнения
- Это то, что делает SCEPTER и исследования на MANA
Как скомбинировать для вашей системы
- Архитектура агента → OODA Loop (Observe через MCP → Orient через world model → Decide через spec → Act через код)
- Декомпозиция задач → HTN Planning (иерархический spec с проверкой через символический планировщик)
- Управление сложностью → SCEPTER (агрегация, локальность, линеаризация взаимодействий)
- Процесс → Agile (спринты, WIP-лимиты, ежедневные отчёты)
- Целеполагание → Commander’s Intent (spec как замысел, а не инструкция)
- Оптимизация → Multi-agent RL (обучение распределению задач на основе reward)
- Валидация → Agent-Based Modeling (симуляция конфигураций до продакшена)