Тикет в Jira переходит в статус «в работе» — и его подхватывает не человек. Серверный агент читает
требования, задаёт уточняющие вопросы постановщику, дорабатывает кодовую базу по стандарту
организации, гонит сборку и тесты в песочнице и открывает Pull Request с отчётом. Разработчик
приходит не писать, а ревьюить готовый дифф.
Парадигма разработки смещается от генераторов кода к автономным агентным системам: агент сам
анализирует требования, планирует архитектуру, пишет код, запускает тесты и открывает PR. Разберём,
как спроектировать такого агента для автоматизации доработок Java-приложений, какие инструменты
взять для слоёв оркестрации и исполнения — и как защититься от быстрого устаревания LLM.
«Добавление людей на запаздывающий программный проект задерживает его ещё сильнее.»
— Фред Брукс, Мифический человеко-месяц
В прошлой статье мы разбирали витрину платформы — вход для потребителя concept-уровня. А сама платформа rationaldev собирается не одним агентом, а командой ролей: orchestrator планирует, implementer пишет, plan-reviewer принимает план, fixer чинит, release-health следит за релизом. Это субагенты. И интуитивно кажется: чем больше специализированных агентов, тем лучше.
Брукс сорок лет назад объяснил, почему это не так с людьми. Оказалось — и с агентами тоже. Добавить в проект ещё одного агента — это не только ещё одна пара рук, это ещё один канал координации и ещё один счёт за токены.
Поэтому я не стал угадывать, а провёл исследование: как индустрия строит субагентов и оркестрацию в 2025–2026, что из этого подтверждается первоисточниками, а что — маркетинг. Прогнал deep-research harness в два захода, ~200 агентов, каждый факт прошёл состязательную проверку в три голоса (чтобы отсеять — нужно два «опровергнуть» из трёх). В статье — только то, что выжило, с честными пометками там, где не выжило.
«Если у вас уже есть бутылочное горло, ИИ сделает поток перед ним толще. Само горло — не сделает шире.»
— переформулированный тезис 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% ускорения» и не академическая неопределённость про «требуется дальнейшее исследование».
«Технической информации присуще качество, когда ею легко пользоваться, её легко понять и легко найти.»
— Gretchen Hargis, Michelle Carey и др., Developing Quality Technical Information (IBM Press)
В статье «README — это продукт» мы сделали так, чтобы каждый файл в репозитории сервиса знал своего потребителя. У README — четыре потребителя, и каждый нанимает его на свою работу.
В статье «Композиция корректности» мы показали, что корректность системы из N сервисов выводится из корректности каждого сервиса и совместимости их контрактов. Один сервис никому не нужен — нужна система.
И вот тут вылезает дыра. Сервис описан хорошо. А продукт — платформа из десяти, двадцати, ста сервисов — не описан нигде. У системы нет входной двери. Менеджер не понимает, что это за зверь. Новый потребитель не понимает, из каких кусков он состоит. ИИ-агент, которого позвали делать фичу на три сервиса, не понимает, с чего начать и куда писать план.
В этой статье вводим лендинг продукта — витрину платформы. Разберём: кто его нанимает, что в него писать (и чего не писать), как это делают в индустрии, и как кросс-сервисная фича стартует именно здесь. Плюс скиллы для слабой модели и мат-часть.
Сквозной живой пример — concept-репозиторий codemonstersteam/pinout: экосистема инструментов для проверки совместимости сервисов по их OpenAPI/AsyncAPI-спецификациям. Платформа из четырёх модулей, у которой есть та самая входная дверь. Удобно, что pinout построен по той же методологии рациональной разработки, что мы разбираем в серии (его модули стоят на service-template и компонентных тестах) — так что лендинг тут не выдуман под статью, а живёт в проде.
В первой практике мы собрали сервис авторизации — OpenAPI-спека, README, devlog. Всё работает. Но документация получилась «для всех» — а значит ни для кого.
В этой сессии разбираем: у README четыре потребителя, и каждый нанимает его на свою работу. Проектируем структуру документации с Claude Opus, применяем через Claude Sonnet в терминале.