Enterprise-разработка - это конвейер из людей. Аналитик пишет постановку неделю. Разработчик кодит еще две. Ревьюер находит баги, возвращает. Тестировщик покрывает сценарии. Безопасник сканирует. Ops катит в прод. Между каждым этапом - ожидание, переключение контекста, больничные, отпуска, митинги. Типичная задача в банке добирается до прода за 2-3 месяца.
Я это видел изнутри на банковских проектах. И сейчас вижу, что в 2026 году тот же путь - от постановки до деплоя - можно пройти за часы. Не одним волшебным агентом, а конвейером из троек агентов, где каждый этап защищен тройной валидацией, а человек контролирует процесс в четырех стратегических точках.
Я назвал это Pipeline Triad Pattern.
В предыдущей статье я описал Jarvis Pattern - манифест персонального агентного минимализма. Формула: LLM (мозг) + OS (руки) + файловая память (карта знаний) = полноценный специалист. Мой агент umax закрывает 100% DevSecOps-задач на mid-tier модели. Один агент заменяет одного специалиста.
Pipeline Triad - следующий шаг. Если Jarvis - это Джарвис конкретного Тони Старка, то Pipeline Triad - это конвейер таких джарвисов. Каждый специализирован, каждый знает свою роль, и вместе они закрывают весь SDLC - от аналитики до деплоя.
Рынок предлагает разные подходы к этой задаче. Devin и SWE-agent идут по пути единого агента-разработчика. Cursor и Copilot Workspace усиливают человека в IDE. CrewAI и LangGraph дают фреймворки для оркестрации мультиагентных систем. Pipeline Triad - не инструмент и не фреймворк, а паттерн организации процесса. Разница принципиальная: фреймворк устареет через год, паттерн останется. Его можно реализовать поверх любого из перечисленных инструментов.
Фундамент: на чем стоим
В конце 2025-го Antonio Gulli, Distinguished Engineer из офиса CTO Google, выпустил книгу "Agentic Design Patterns" (Springer, 424 стр.) - первую серьезную систематизацию паттернов проектирования AI-агентов. 21 паттерн, каждый с кодом и кейсами. Ключевой контрибьютор - Marco Fago (код, диаграммы, ревью всего текста).
Параллельно свой взгляд дали Anthropic ("Building Effective Agents"), Lilian Weng из OpenAI ("LLM Powered Autonomous Agents"), и сам OpenAI выпустил "A Practical Guide to Building Agents". Все работы приходят к одному выводу: базовые паттерны кристаллизовались. Фреймворки - разные "холсты", а паттерны - одни и те же. Полный список источников - в конце статьи.
Не буду пересказывать 424 страницы. Для Pipeline Triad критичны шесть паттернов: Prompt Chaining (разбиение на мелкие шаги - LLM на маленькой задаче работает на порядок лучше), Routing (условная логика - агент сам решает куда двигать задачу), Parallelization (параллельное выполнение - Google Research показали +80.8% эффективности в 180 экспериментах), Tool Use (вызов реальных инструментов - curl, git, сканеры безопасности), Memory Management (краткосрочная и долгосрочная память - те же markdown-файлы из Jarvis Pattern) и Reflection - самокритика.
На Reflection остановимся подробнее.
Почему тройка, а не один агент
LLM плохо находит ошибки в собственном ответе. Доказанный факт (Huang et al., ICLR 2024): модель не способна исправить собственное рассуждение без внешней обратной связи. Anthropic прямо пишут в "Building Effective Agents": один генерирует, другой оценивает, и процесс повторяется, пока результат не достигнет нужного качества.
Gulli формализует это как Producer-Critic. Один агент генерирует, второй критикует. Работает, но недостаточно. Критик тоже может ошибиться: быть слишком строгим, пропустить критическую проблему, зациклиться на мелочах.
Поэтому я добавляю третью роль - Арбитр. Независимый судья, который проверяет и Создателя, и Критика.
Принцип maker-checker-approver известен давно - в банковских процессах это стандарт. Новизна Pipeline Triad - в системном применении этого принципа ко всему циклу разработки, где каждая тройка специализирована под свой этап и работает с общей памятью.
Аналогия: разработчик пишет код, ревьюер находит проблемы, техлид принимает решение. Три роли, три точки зрения, минимизация ошибок. Только вместо трех людей, которые неделю согласовывают - три агента за минуты.
"Это же просто CI/CD?" - нет.
Важное различие.
Jenkins, GitLab CI, TeamCity - это автоматизация. Скрипт гоняет линтер, запускает тесты, собирает билд. Если тест упал - pipeline красный. Все детерминировано: одинаковый вход = одинаковый выход.
Pipeline Triad - это не автоматизация. Это делегирование.
Критик не запускает линтер. Он анализирует логику: "Здесь нет проверки прав доступа, а по регламенту эту операцию может вызывать только роль ACCOUNT_MANAGER." Арбитр не проверяет чеклист. Он принимает решение: "Замечание Критика обосновано, возвращаю на доработку" или "Критик придирается к стилю, а код корректен, пропускаю."
CI/CD выполняет инструкции. Тройка думает. Скрипт не может найти пропущенный бизнес-сценарий или заметить, что архитектурное решение противоречит стандартам компании. Агент - может.
При этом Pipeline Triad не заменяет CI/CD, а включает его: на шагах 11 и 13 (деплой) работает обычный автоматический pipeline. Агенты готовят, CI/CD катит.
Human-in-the-Loop: контроль без иллюзий
Gulli выделяет два режима. Human-in-the-Loop - человек проверяет, одобряет, корректирует. Human-on-the-Loop - человек задает стратегию, агент исполняет автономно в заданных рамках.
Pipeline Triad использует оба. Шаг 0 (постановка задачи) и Human Gates - это in-the-loop. Агентные этапы между gates - это on-the-loop: человек задал правила (скиллы агентов, критерии качества), тройка работает сама.
Gulli честно пишет про ограничения: люди не масштабируются (не могут проверять миллионы задач), эффективность зависит от квалификации проверяющего, чувствительные данные нужно анонимизировать. Именно поэтому в Pipeline Triad четыре Human Gate, а не четырнадцать - человек стоит только там, где цена ошибки максимальна.
Доска: 14 шагов от идеи до прода
Зачем спринты, если есть поток
Спринты оптимизируют работу людей. Двухнедельные итерации, ретроспективы, velocity - все потому, что люди устают, болеют, переключают контекст. Agile - великая методология. Для людей.
Агенты не устают. Не болеют. Не переключают контекст, потому что у каждого свой контекст в памяти. Когда исполнители - агенты, координация упрощается.
Kanban - это про поток задач, а не про итерации. Задача поставлена - задача поехала. Следующая не ждет конца "спринта". Для агентного конвейера это естественная модель. Agile не умирает - он упрощается до непрерывного потока.
Полная модель
0. Создание задачи - Human. Формулируешь задачу и ставишь на доску. Качество постановки определяет качество всего конвейера. Garbage in - garbage out никто не отменял.
1. Аналитика - Тройка. Создатель читает требования, базу знаний, стандарты компании. Пишет техническую постановку. Критик ищет дыры: пропущенные сценарии, конфликты с архитектурой, неоднозначности. Арбитр решает - постановка готова или нет.
2. Валидация требований - Human Gate #1. Самый дешевый gate. Поймать ошибку в требованиях - часы. Поймать в коде - дни. Поймать в проде - месяцы и деньги. Каждый enterprise-архитектор знает: баг в проде, который можно было увидеть еще на постановке, если бы кто-то внимательно прочитал. Этот gate - именно для этого.
3. Разработка - Тройка. Создатель пишет код. Критик с промптом "ты строгий Senior Developer" - ищет баги, уязвимости, нарушения стиля. Арбитр принимает.
4. Code Review - Тройка. Ревью кода: архитектура, производительность, поддерживаемость. Если FAIL - возврат на шаг 3.
5. Тестирование - Тройка. Создатель генерирует и запускает тесты. Критик анализирует покрытие, ищет пропущенные сценарии. Агент знает десятки подходов к тестированию, которые один тестировщик физически не успеет применить: boundary testing, mutation testing, property-based, fuzz testing. Живой тестировщик выберет 2-3 подхода из привычных. Тройка применит все, параллельно, за минуты.
6. Регрессия - Тройка. Полный набор тестов всей системы - проверка, что новые изменения не сломали существующее. Создатель запускает, Критик анализирует падения, Арбитр принимает решение.
7. Безопасность - Тройка. Сканирование кода и зависимостей на уязвимости: статический анализ (SAST), динамический анализ (DAST), проверка сторонних библиотек на известные уязвимости. Критические уязвимости - блокер, возврат на разработку.
8. Одобрение готовности - Human Gate #2. Ответственный смотрит на результат всех этапов: код, тесты, безопасность. Дает добро.
9. Подготовка артефактов - Тройка. Релизная документация: план испытаний, протоколы приемки, пользовательская документация, release notes, нотификация заинтересованных. Критик проверяет комплектность. Арбитр подтверждает.
10. Одобрение деплоя - Human Gate #3. Команда эксплуатации подтверждает готовность инфраструктуры и наличие плана отката.
11. Деплой на staging - Авто. CI/CD разворачивает на тестовую среду.
12. Подтверждение прода - Human Gate #4. Проверка на staging: базовые сценарии работают, метрики в норме. В финтехе - обязательно. Цена ошибки в проде измеряется в деньгах и репутации.
13. Деплой в production - Авто. Раскатка в боевую среду.
Пример: задача проходит через конвейер
Для тех, кто работает с банковским бэкендом, - конкретный прогон. Задача: "Добавить REST endpoint /api/v2/accounts/{id}/freeze для заморозки счета клиента." Типичная enterprise-задача средней сложности: нужно учесть бизнес-правила, безопасность, интеграцию с существующей системой.
Шаг 0. Архитектор ставит на доску: endpoint, бизнес-правила, ссылка на регламент заморозки.
Шаг 1 (Аналитика). Создатель читает регламент заморозки (подключается к базе знаний), смотрит документацию существующих endpoints, пишет постановку: HTTP метод, формат запроса/ответа, бизнес-валидации (нельзя заморозить уже замороженный счет, нельзя заморозить счет с активными платежами в очереди), коды ошибок, требования к логированию. Критик: "Не описано поведение при частичной заморозке - что если на счету запланированные автоплатежи?" Арбитр подтверждает замечание, возврат. Второй проход - Создатель добавляет сценарий. Критик доволен. Арбитр пропускает.
Шаг 2 (Human Gate). Архитектор: сценарий с автоплатежами учтен, все на месте, пропускаю. 15 минут.
Шаг 3 (Разработка). Создатель пишет контроллер, сервис, слой работы с базой, миграцию. Критик: "Нет проверки прав доступа - кто может вызывать freeze? Нужна авторизация по роли." Цикл. Создатель добавляет. Критик: ОК. Арбитр пропускает.
Шаг 4 (Code Review). Тройка проверяет: именование, обработка ошибок, потокобезопасность, идемпотентность (повторный вызов freeze не должен падать - должен возвращать "уже заморожен").
Шаг 5 (Тестирование). Создатель: модульные тесты, интеграционные, негативные сценарии (замороженный счет, несуществующий id, нет прав). Критик: "Нет теста на гонку - два параллельных вызова freeze на один счет." Цикл.
Шаги 6-7. Регрессия проходит. Сканер безопасности чисто.
Шаг 8 (Human Gate). Архитектор проверяет итог: код, тесты, отчет безопасности. Все чисто. 20 минут.
Шаги 9-13. Документация, одобрение эксплуатации, staging, проверка, прод.
Итого, время человека: постановка (10 мин) + проверка требований (15 мин) + одобрение (20 мин) + одобрение деплоя и проверка staging (15 мин) = примерно 1 час.
В классическом enterprise та же задача: 3-5 дней аналитика + 3-5 дней разработка + 1-2 дня ожидание ревью + 2-3 дня тестирование + 1 день безопасность + 1-2 дня документация = 2-3 недели. Зарплатный фонд команды за эти две-три недели - совсем другой порядок цифр. А здесь - час человеческого времени.
Оговорка: эти цифры - для задачи, где бизнес-логика описана в регламенте и не требует длинных согласований. Если нужно получить одобрение юриста, compliance-офицера и трех аналитиков из разных подразделений - Pipeline Triad не телепортирует организационные процессы. Он ускоряет техническую работу.
Экономика: сколько стоит конвейер
Считать нужно в двух моделях - через API и через подписку.
Расчет через API (Claude Sonnet 4.6, апрель 2026)
Текущие цены: $3 за 1M input-токенов, $15 за 1M output-токенов.
Один проход тройки - это три вызова LLM (Создатель + Критик + Арбитр). Каждый вызов: примерно 10-20K input (промпт + контекст + файлы из памяти) и примерно 2-5K output. При 2-4 проходах тройки на этап и 7 агентных этапах получаем 42-84 вызова на задачу.
Грубый расчет: примерно 1-2M input-токенов ($3-6) + примерно 200-400K output-токенов ($3-6) = $6-12 за полный прогон одной задачи.
Это оценка. Реальное потребление зависит от сложности задачи, размера контекста и количества возвратов на доработку. Для простых задач может быть $3-5, для задач с большим контекстом и множеством итераций - $15-20.
Расчет через подписку (Claude Max $200/мес)
Max 20x дает примерно 900 сообщений за 5-часовое окно, окна обновляются непрерывно. Тяжелая задача (примерно 80 вызовов) укладывается в одно окно с запасом. За рабочий день - 4-5 задач. За месяц при плотной работе - порядка 80-100 задач. $200 / 100 = примерно $2 за задачу.
Подписка субсидируется и значительно дешевле API. Ограничение - нельзя гнать конвейер 24/7: лимиты общие для всех сессий.
Сравнение
Для сравнения: типичная enterprise-команда на один продукт - 2-3 аналитика, 4-6 разработчиков, 1-2 тестировщика, 1 DevOps, 1 безопасник, 1 техлид, 1 PM. Это 11-15 человек. Зарплатный фонд такой команды - другой порядок цифр, даже за одну неделю. Задача, которая занимала полкоманды две недели, проходит через конвейер за обеденный перерыв.
Где это ломается
LLM галлюцинирует бизнес-логику. Агент может выдумать правило, которого нет в регламенте. Тройка снижает риск - Критик и Арбитр ловят. Но не устраняет полностью. Именно поэтому Human Gate после аналитики - необходимость, а не опция. Если тройка выдала красивую, но неправильную постановку, а человек ее пропустил - дальше поедет идеально реализованная ерунда.
Стоимость ошибки на ранних этапах. Если тройка на аналитике приняла неверное архитектурное решение и Human Gate его пропустил - все последующие этапы будут делать идеально, но не то. Агенты работают в рамках контекста и могут не увидеть картину целиком.
Зависимость от качества промптов. Скилл каждого агента - что он делает, на что смотрит, какие критерии - это тонкая работа. Плохо описанный Критик будет либо пропускать все, либо заворачивать все. Это не "настроил и забыл" - итеративный процесс, как настройка памяти в Jarvis Pattern.
Организационные процессы никуда не деваются. Конвейер ускоряет техническую работу. Совещания, согласования, политика - те же дни. Pipeline Triad решает инженерные проблемы, не организационные.
Стоимость при масштабе. $6-12 на задачу по API - недорого. 20 досок по 50 задач в неделю - это $6-12к в неделю на токены. Но зарплатный фонд отдела разработки за ту же неделю - на порядок больше.
"А покажи работающую доску"
Справедливый вопрос. Pipeline Triad на момент публикации - это паттерн, проверенный на отдельных этапах на моем стенде. Агент umax (Jarvis Pattern) закрывает DevSecOps-этапы конвейера: безопасность, CI/CD, инфраструктура. Тройка Создатель-Критик-Арбитр обкатана на аналитике и code review.
Полный конвейер из 14 шагов с работающей доской - следующий шаг.
Публикую это как паттерн, а не как готовый продукт - потому что архитектура процесса важнее конкретной реализации. Jarvis Pattern тоже начинался как манифест, а через неделю umax уже закрывал 100% задач. Паттерн первичен, реализация следует.
Масштабирование: от одной доски до предприятия
Одна тройка на этапе - минимум. Для крупного enterprise:
- 10 Создателей параллельно работают над 10 задачами
- 10 Критиков параллельно проверяют
- 10 Арбитров параллельно решают
Одна доска = один продукт или сервис. 20 продуктов = 20 досок. 24/7. Без перерывов. Утром на доске готовые артефакты, ждущие одобрения на Human Gate.
Параллелизация работает для независимых задач. Задачи с зависимостями требуют оркестрации: SLA между задачами, приоритизация через человека, merge-стратегии. Это отдельная тема, выходящая за рамки статьи.
Основная работа при масштабировании - не код, а описание скиллов: что делает каждый агент, куда смотрит, куда пишет, куда коммитит. Те же markdown-файлы из Jarvis Pattern, только для каждой роли в тройке.
Минимальная команда
Вот во что превращается штат при Pipeline Triad:
Архитектор/техлид (1 человек). Ставит задачи (шаг 0). Валидирует требования (шаг 2). Одобряет готовность (шаг 8). Это человек, который видит картину целиком, понимает бизнес-контекст и может оценить, правильно ли тройка поняла задачу. Не менеджер, а инженер - в том же смысле, что я описывал в Jarvis Pattern: "Ценится тот, кто понимает зачем."
Ops/эксплуатация (1 человек). Одобряет деплой (шаг 10). Проверяет staging (шаг 12). Отвечает за инфраструктуру, rollback, мониторинг в проде.
Бизнес-аналитик (опционально, для сложных доменов). Если продукт работает в области с тяжелым регулированием (финтех, медицина, страхование) - нужен человек, который проверяет бизнес-логику на шагах 2 и 8. Для простых продуктов архитектор закрывает эту роль.
Итого: 2-3 человека.
Не потому что остальные "не нужны". Их работу выполняет конвейер. Непрерывно, без больничных и отпусков, без переключения контекста.
Но эти 2-3 человека должны быть сильными. Джуниор не потянет роль единственного архитектора на конвейере из 7 агентных этапов. Здесь нужен Senior+, который видит систему целиком и может за 15 минут оценить, правильно ли агенты отработали. Pipeline Triad не снижает требования к людям - он радикально снижает их количество.
Заключение
В Jarvis Pattern я писал: "Человек остается в центре. Не как оператор при машине, а как инженер, которому машина подчиняется." Pipeline Triad не меняет эту позицию - он масштабирует ее.
Эволюция: один агент (Jarvis) заменяет одного специалиста. Тройка агентов закрывает один этап с тройной валидацией. Конвейер троек (Pipeline Triad) закрывает весь цикл разработки - от аналитики до деплоя.
Через полгода выйдут новые модели. Через год - новое железо. Уже сейчас mid-tier модель достаточна для одного специалиста. Что будет, когда тройки заработают на Opus или на том, что выйдет после, - можно только предполагать.
Фреймворки приходят и уходят. Паттерны остаются. Pipeline Triad можно реализовать на чем угодно: Nanoclaw, LangGraph, CrewAI, или на скриптах и API. Важна архитектура процесса, а не конкретный инструмент.
Jarvis Pattern начинался как манифест - и через неделю umax уже работал в проде. Pipeline Triad начинается как паттерн. Что будет через неделю - увидим.
Источники
-
Antonio Gulli (Google, Office of CTO) - "Agentic Design Patterns: A Hands-On Guide to Building Intelligent Systems", Springer, 2025. Marco Fago - ключевой контрибьютор. -> https://link.springer.com/book/10.1007/978-3-032-01402-3
-
Erik Schluntz, Barry Zhang (Anthropic) - "Building Effective Agents", декабрь 2024. -> https://www.anthropic.com/research/building-effective-agents
-
Lilian Weng (VP of Research, OpenAI) - "LLM Powered Autonomous Agents", июнь 2023. -> https://lilianweng.github.io/posts/2023-06-23-agent/
-
OpenAI - "A Practical Guide to Building Agents", апрель 2025. -> https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf
-
Google Research + DeepMind + MIT - "Towards a Science of Scaling Agent Systems", 2024.
-
Jie Huang et al. - "Large Language Models Cannot Self-Correct Reasoning Yet", ICLR 2024.
-
Егор Зиновьев - "Jarvis Pattern: почему AI-агенту не нужен фреймворк, а нужна операционная система", zinovev.org, 2026. -> https://zinovev.org/post/jarvis-pattern
Егор Зиновьев - IT-архитектор, аудитор, AI-инженер. NL / Remote.
zinovev.org