Skip to content

Блог

Субагенты и оркестрация. Когда команда агентов лучше одного — и чем это оплачено

«Добавление людей на запаздывающий программный проект задерживает его ещё сильнее.»

— Фред Брукс, Мифический человеко-месяц

В прошлой статье мы разбирали витрину платформы — вход для потребителя concept-уровня. А сама платформа rationaldev собирается не одним агентом, а командой ролей: orchestrator планирует, implementer пишет, plan-reviewer принимает план, fixer чинит, release-health следит за релизом. Это субагенты. И интуитивно кажется: чем больше специализированных агентов, тем лучше.

Брукс сорок лет назад объяснил, почему это не так с людьми. Оказалось — и с агентами тоже. Добавить в проект ещё одного агента — это не только ещё одна пара рук, это ещё один канал координации и ещё один счёт за токены.

Поэтому я не стал угадывать, а провёл исследование: как индустрия строит субагентов и оркестрацию в 2025–2026, что из этого подтверждается первоисточниками, а что — маркетинг. Прогнал deep-research harness в два захода, ~200 агентов, каждый факт прошёл состязательную проверку в три голоса (чтобы отсеять — нужно два «опровергнуть» из трёх). В статье — только то, что выжило, с честными пометками там, где не выжило.

GL HF DD!

ROI ИИ в разработке. Почему без зрелой платформы и стандарта вы покупаете ускоритель хаоса

«Если у вас уже есть бутылочное горло, ИИ сделает поток перед ним толще. Само горло — не сделает шире.»

— переформулированный тезис DORA 2026

В апреле 2026 команда DORA опубликовала отчёт «The ROI of AI-assisted Software Development». Это не очередная вендорская методичка про «внедрили Copilot — стали быстрее на 35%». Это финансовая рамка для разговора про ИИ, где ИИ описан буквально одним словом: amplifier, усилитель. Усилитель сильных сторон высокопроизводительных организаций. И усилитель дисфункций — у всех остальных.

Эта статья — синтез трёх отчётов DORA (2024, 2025, ROI 2026), сверенный с независимыми исследованиями: METR, Faros, Veracode, Apiiro, GitClear, MIT NANDA, MIT/Microsoft/Accenture, Stack Overflow Developer Survey. Она для тех, кому интересно управляемое ИТ-производство с ИИ. Не вендорская сказка про «35% ускорения» и не академическая неопределённость про «требуется дальнейшее исследование».

В этой главе рассмотрим:

Лендинг продукта. Как описать платформу из N сервисов по JTBD

«Технической информации присуще качество, когда ею легко пользоваться, её легко понять и легко найти.»

— Gretchen Hargis, Michelle Carey и др., Developing Quality Technical Information (IBM Press)

В статье «README — это продукт» мы сделали так, чтобы каждый файл в репозитории сервиса знал своего потребителя. У README — четыре потребителя, и каждый нанимает его на свою работу.

В статье «Композиция корректности» мы показали, что корректность системы из N сервисов выводится из корректности каждого сервиса и совместимости их контрактов. Один сервис никому не нужен — нужна система.

И вот тут вылезает дыра. Сервис описан хорошо. А продукт — платформа из десяти, двадцати, ста сервисов — не описан нигде. У системы нет входной двери. Менеджер не понимает, что это за зверь. Новый потребитель не понимает, из каких кусков он состоит. ИИ-агент, которого позвали делать фичу на три сервиса, не понимает, с чего начать и куда писать план.

В этой статье вводим лендинг продукта — витрину платформы. Разберём: кто его нанимает, что в него писать (и чего не писать), как это делают в индустрии, и как кросс-сервисная фича стартует именно здесь. Плюс скиллы для слабой модели и мат-часть.

Сквозной живой пример — concept-репозиторий codemonstersteam/pinout: экосистема инструментов для проверки совместимости сервисов по их OpenAPI/AsyncAPI-спецификациям. Платформа из четырёх модулей, у которой есть та самая входная дверь. Удобно, что pinout построен по той же методологии рациональной разработки, что мы разбираем в серии (его модули стоят на service-template и компонентных тестах) — так что лендинг тут не выдуман под статью, а живёт в проде.

GL HF DD!

Композиция корректности. Как собрать рабочую систему из сервисов с подтверждённой спецификацией

«Программы должны быть написаны так, чтобы их корректность можно было доказать, а не угадать тестированием.»

— Niklaus Wirth, Systematic Programming

Это финальная статья серии про корректность программ. В предыдущих мы по кирпичу собирали модуль, сервис и спецификацию:

Сервис в результате этой дисциплины имеет спецификацию, подтверждённую тестами в изоляции. Юнит-тесты по формуле «1 + ветки антецедента» подтверждают, что каждый модуль ведёт себя по своему контракту. Компонентные сценарии в Gherkin через Docker Compose подтверждают, что сервис как чёрный ящик ведёт себя по OpenAPI/AsyncAPI и по карте режимов отказа в README.

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

Но в индустрии один такой сервис никому не нужен. Нужна система — десять, двадцать, сто сервисов, которые ходят друг к другу через сеть, и эта система должна работать.

И вот здесь индустрия ставит поверх всей пирамиды ещё один этаж: интеграционные тесты, e2e на Playwright, системные стенды, регрессионные прогоны на стейджинге. Тысячи сценариев. Часы прогонов. Десятки человеко-месяцев на поддержку.

В этой статье покажу, что весь этот этаж — компенсация отсутствия двух простых вещей: машиночитаемого контракта и канареечного деплоя. При наличии обоих корректность системы выводится из корректности сервисов и совместимости их контрактов. Без e2e, без стейджинга, без бесконечной регрессии.

Два скилла дисциплины. Скилл проектирования для opus и скилл реализации для sonnet

«Дисциплина — это мост между целями и достижениями.»

— Jim Rohn

В предыдущей статье мы вывели дисциплину: программа = дерево модулей с контролем диапазонов, юнит-тесты по формуле «1 + ветки антецедента», корректность доказывается по построению. Там была теория, оформленная как практическая методичка.

Этой статьёй закрываем разрыв между «понятно как» и «понятно что положить в Claude Code». На выходе — два самостоятельных артефакта:

  • program-design.skill — скилл для opus. Принимает функциональное требование, отдаёт пакет проектной документации.
  • program-implementation.skill — скилл для sonnet. Принимает пакет, отдаёт код по тикетам через Trunk Based Development.

Связующая нить — vertical slice architecture: каждый вход API режется в отдельный поток сверху вниз, со своим адаптером, своей бизнес-логикой, своим модулем I/O. Это резко упрощает и проектирование, и сборку бэклога, и параллельную работу нескольких агентов.

В следующей статье оба скилла прикручиваются к ubik-life/passkey-demo-api. Здесь — только сами скиллы и обоснование, почему они выглядят именно так.

Дисциплина проектирования программ. Скилл для opus и бэклог для sonnet

«Тестирование программ может служить для доказательства наличия ошибок, но никогда не докажет их отсутствия.»

— Edsger W. Dijkstra

Это практическая статья для вайб-кодера и джуна. Без академической мути. Цель — дать одну дисциплину проектирования, по которой opus проектирует программу, а sonnet получает готовый бэклог и реализует его в Claude Code.

Статья — концентрат четырёх разборов на codemonsters.team: структурное программирование, модульность, правильность программы, компонентные тесты.

Если ты дисциплинированно выполнишь то, что описано ниже, у тебя будет программа, которая работает правильно по построению. Не потому что её тщательно тестировали — а потому что её правильно спроектировали.

Применение и доработка скилла компонентных тестов. Сессия с opus и хендофф sonnet'у

«Если карта не сходится с местностью — права местность.»

— старая военная пословица

В предыдущей статье мы зафиксировали скилл компонентных тестов как артефакт: положили SKILL.md рядом с проектом, написали процедуру, посчитали для passkey-demo-api по формуле семь сценариев. Всё красиво.

Реальность вмешалась на первой же минуте применения. Эта статья — журнал двух смежных сессий: opus прошёл от теории до зелёного smoke, потом sonnet за один день написал восемь сценариев по готовому шаблону. Карта (скилл) встретилась с местностью (реальный репозиторий), оба после этого изменились.

Компонентные тесты на практике. Скилл для агента и разбор passkey-demo-api

В предыдущей статье мы вывели формулу:

N_тестов = 1 + Σ (число различимых веток в адаптере i)

Теория готова. Время превратить её в инструмент, который работает каждый день — на любом сервисе, в руках любого вайб-инженера, в связке с ИИ-агентом.

Сколько компонентных тестов нужно сервису. Логический вывод

«Тестирование программ может служить для доказательства наличия ошибок, но никогда не докажет их отсутствия!»

— Edsger W. Dijkstra

В предыдущих статьях мы прошли путь:

Складываем три кирпича — и приходим к вопросу, на который индустрия не даёт внятного ответа: сколько компонентных тестов нужно сервису?

Ответ выводится логически. И он мал.

README — это продукт. Документация по JTBD с ИИ-агентом

В первой практике мы собрали сервис авторизации — OpenAPI-спека, README, devlog. Всё работает. Но документация получилась «для всех» — а значит ни для кого.

В этой сессии разбираем: у README четыре потребителя, и каждый нанимает его на свою работу. Проектируем структуру документации с Claude Opus, применяем через Claude Sonnet в терминале.

Репозиторий с результатом: service-template

GL HF DD!