Habr AI: Como Pipeline Triad Monta um Pipeline de Agentes IA em Vez de uma Equipe de Desenvolvimento

Идея одного универсального ИИ-разработчика постепенно уступает более практичной схеме: вместо «суперагента» предлагается конвейер из специализированных троек, где один агент создает результат, второй ищет ошибки, а третий выносит решение. Именно так устроен Pipeline Triad Pattern — модель разработки, рассчитанная не на демонстрации, а на типовые enterprise-задачи, где требования, стандарты и правила уже описаны, а человеку остается контроль в нескольких самых дорогих точках процесса. В основе схемы три роли: Создатель, Критик и Арбитр.

Первая генерирует артефакт, вторая проверяет логику, качество и риски, третья решает, пропускать результат дальше или отправлять на доработку. Такой подход опирается на простую идею: языковые модели плохо исправляют собственные ошибки без внешней проверки, поэтому надежнее не усиливать одного агента до бесконечности, а строить независимую тройку с разными функциями. Автор паттерна переносит на агентную разработку знакомый enterprise-принцип maker-checker-approver и растягивает его на весь SDLC.

При этом Pipeline Triad не предлагается как замена CI/CD. Автоматические пайплайны по-прежнему собирают, тестируют и выкатывают код, но над ними появляется еще один слой — слой агентного делегирования, где решения принимаются не по жесткому скрипту, а с учетом контекста, регламентов и бизнес-правил. Полная схема состоит из 14 шагов от постановки задачи до продакшена.

Из них семь выполняют агентные этапы: аналитика, разработка, code review, тестирование, регрессия, безопасность и подготовка релизных артефактов. Еще четыре точки остаются за человеком: валидация требований, одобрение готовности, подтверждение деплоя и финальная проверка перед продом. На каждом этапе тройка должна выдать не просто текстовый ответ, а формализованный пакет: сам артефакт, критерии PASS или FAIL, журнал замечаний Критика, а также решение Арбитра — пропустить, вернуть или провести частично.

За счет этого конвейер превращается из набора промптов в воспроизводимый процесс с трассировкой решений. Следующий этап не стартует, пока не получит валидный вход, а значит можно строить аудит, измерять качество и разбирать ошибки постфактум. Практическая ценность паттерна лучше всего видна на типовой задаче.

Для примера автор берет банковский эндпоинт для заморозки счета: сначала тройка уточняет требования и крайние сценарии, потом отдельные тройки пишут код, проверяют права доступа, добавляют тесты на гонки, прогоняют регрессию и безопасность, после чего человек лишь подтверждает несколько ключевых решений. В таком сценарии человеческое участие оценивается примерно в час суммарного времени против двух-трех недель в классическом enterprise-процессе. По стоимости автор считает полный прогон через API примерно в 42–84 вызова модели, 1–2 миллиона входных токенов и 200–400 тысяч выходных, что дает ориентир порядка 6–12 долларов на задачу.

Для пилотов и личных стендов подписка может быть дешевле, но для стабильного production-потока все равно придется считать лимиты, бюджет и реальное потребление токенов. При этом у модели есть жесткие границы. Она хорошо подходит для change requests, bugfixes, CRUD- и API-задач, интеграций и инфраструктурных изменений, где домен формализован и результат можно проверить тестами и артефактами.

Хуже всего Pipeline Triad работает там, где много неопределенности: в discovery, greenfield-архитектуре без зрелых стандартов, R&D и больших межкомандных рефакторингах. Риски тоже вполне земные: агент может придумать несуществующее бизнес-правило, плохо настроенный Критик начнет либо пропускать ошибки, либо заворачивать все подряд, а параллельная работа нескольких задач быстро упрется в конфликты контекста, миграций и веток. Отдельный блок — безопасность самого конвейера.

Если агентам открыть доступ к репозиторию, секретам и деплою без жестких ограничений, новый процесс превращается в дополнительную поверхность атаки. Поэтому автор настаивает на принципе least privilege, раздельных правах ролей, полном audit log, policy engine для tool use и фильтрации чувствительных данных до попадания их в контекст модели. Что это значит на практике: идея «команды из агентов» становится не фантазией про универсального ИИ-сотрудника, а более приземленной инженерной моделью, где ускорение достигается за счет специализации, формализованных входов и контроля на дорогих шагах.

Но материал честно показывает и пределы подхода: он не отменяет организационные согласования, не решает проблему слабой постановки и не снимает ответственность с сильных людей, которые должны валидировать результат. Если такие конвейеры и станут рабочим стандартом, то сначала в предсказуемых enterprise-доменах, где цена ошибки высока, а правила уже можно превратить в проверяемый процесс.