Второе фундаментальное правило работы с ИИ-агентами: разбиение большого запроса на более мелкую гранулярность с проверкой после каждого шага даёт лучшие результаты, чем один гигантский prompt.
Если вы берётесь за крупную новую функциональность, лучше разбить её на более мелкие Task, и тому есть несколько причин.
Одна из важнейших вещей, о которых нужно сказать, — то, как стоимость разработки программного обеспечения ведёт себя во времени. В книге «Code Complete» есть известная диаграмма, показывающая, насколько дороже обходится исправление бага в зависимости от того, на какой фазе разработки он обнаружен: на этапе анализа стоимость почти нулевая, но когда ПО уже в эксплуатации у заказчика, стоимость на порядок выше или больше. При той скорости, с которой ИИ сегодня генерирует код, к проектированию архитектуры заранее нужно относиться ещё внимательнее — потому что рефакторинг как раз то, с чем ИИ справляется не особенно хорошо. Лучший подход — придерживаться стандартов, описанных в книгах о чистом коде, и использовать устоявшиеся шаблоны для структуры и бизнес-логики: книги — один из самых качественных источников, из которых ИИ-модель усвоила правильные практики во время обучения, поэтому она понимает их лучше всего. Для ИИ также важно держать код разделённым на чёткие слои, даже в монолите, — тогда агент гораздо проще ориентируется в коде.
Вернёмся к тому, как правильно разбивать Task. Допустим, задача — создать новую форму оценки удовлетворённости клиентов. Какие фазы потребуются?
- UI — форма, её поля и событие отправки.
- Бизнес-логика — валидация формы, привязка запроса к учётной записи клиента, приоритет запроса.
- Структура данных — как данные передаются на BE и обратно на FE.
- BE — снова валидация и бизнес-логика, теперь на стороне бэкенда.
- Слой данных — отображение структуры данных на базу данных.
- Сохранение данных плюс соответствующая структура, возвращаемая с BE на FE.
Для ИИ на самом деле не важно, откуда начинать, — важно правильно описать каждый шаг. Для вас как пользователя удобнее всего начинать либо с базы данных, либо с фронтенда.
Так охватываются все Task. Теперь вопрос: в чём разница между одной большой Task и несколькими меньшими?
У одной Task преимущество — общий контекст (кэш) между шагами: агенту никогда не нужно ничего искать заново. Но на большем числе ходов это преимущество оборачивается: чем дольше вы остаётесь в одном контексте, тем больше токенов повторно отправляется и повторно обрабатывается на каждом последующем ходу, так что стоимость хода продолжает расти вместе с размером контекста — в длинной многоходовой Task это может складываться в заметную сумму.
Если же разделить Task, ИИ выполняет только свою конкретную часть, которую в конце можно независимо протестировать — выявляя ошибки ещё до начала работы над следующей частью. В сумме мы расходуем меньше токенов, а возможность независимо проверять каждый шаг позволяет обнаруживать галлюцинации или отклонения от требования гораздо раньше, чем после завершения одной гигантской Task. Более мелкие Task также не требуют от модели удерживать внимание на всех деталях сразу.
Почему это так важно для ИИ-моделей? У них ограниченная способность сохранять приоритет среди большого числа инструкций одновременно. Если написать в одном prompt «добавь новую функциональность, переработай старую логику и исправь три связанных бага», модель выстраивает собственный порядок приоритетов — и он может не совпасть с вашим. Результат: одна часть Task выполнена блестяще, другая — спустя рукава, и никто этого не замечает, пока не сломается в эксплуатации.
Именно поэтому AITM разбивает крупные запросы на связанные в цепочку Task, а не позволяет им выполняться одним непрерывным проходом.
Как это выглядит на практике: обычный ИИ-чат и AITM
Обычный ИИ-агент (чат/копилот в IDE): вы даёте один длинный prompt, и агент работает в одном непрерывном контексте. Если он ошибся в какой-то детали на 80 % пути, вы не узнаете об этом, пока не просмотрите весь diff, — а тем временем работа над последующими пунктами продолжалась поверх сломанного фундамента.
AITM: тот же запрос разбивается в Chat/Brainstorm на отдельные связанные в цепочку вызовы Task с зависимостями — Task B может стартовать только после того, как Task A прошла весь Pipeline и была слита. Если Task A терпит неудачу на ревью или тесте, Task B не запускается поверх сломанного фундамента — она ждёт. Тем временем Watchdog сам оценивает сбой Task A: если он может проанализировать ошибку и предложить исправление, Task автоматически перезапускается с prompt, описывающим именно эту ошибку и предложенное исправление; если ошибка неясна или неразрешима без решения человека, Task останавливается и ждёт, пока пользователь решит, как действовать дальше. Кроме того, после слияния последней Task цепочки выполняется шаг chain-audit — детерминированная (не ИИ) финальная проверка, повторно подтверждающая контракты, затронутые всей цепочкой.
Разница, которую видит пользователь: с обычным агентом в конце вы получаете один большой непрозрачный diff. С AITM вы получаете несколько более мелких, именованных, независимо проверенных Task с собственной историей — и точно знаете, где что-то пошло не по плану, если так случилось.