Последнее время я много думаю о том, как должна выглядеть агентная разработка внутри большой компании.
Самый очевидный сценарий уже сейчас довольно понятен: появляется задача в Jira или YouTrack, оркестратор агентов её забирает, поднимает среду, передаёт задачу агенту, тот вносит изменения, прогоняет тесты и создаёт Merge Request.
То есть в упрощённом виде всё выглядит примерно так:
Трекер → Оркестратор агентов → Репозиторий → CI/CD → MR
Технически такой сценарий уже вполне реализуем.
Но чем больше я смотрю на эту схему, тем сильнее кажется, что самая сложная часть находится вовсе не в написании кода.
Она находится между:
«получить задачу» → «понять, что вообще нужно делать»
Код — не главная проблема
Представим, что агент получил задачу:
Добавить новую проверку при создании заказа.
Для человека внутри команды за этой одной фразой скрывается огромное количество контекста.
Агенту нужно каким-то образом понять:
- какой сервис необходимо изменить;
- где находится его репозиторий;
- частью какой системы является этот сервис;
- какие у него зависимости;
- кто является владельцем компонента;
- как сервис собирается;
- как его правильно запускать локально;
- как он деплоится;
- какие внутренние библиотеки можно использовать;
- какие архитектурные ограничения существуют;
- какие security-политики необходимо соблюдать;
- где находится актуальная документация;
- какие тесты обязательны;
- что вообще разрешено делать автоматически.
У разработчика значительная часть этого знания уже находится в голове.
Остальное размазано по нескольким системам:
GitLab / GitHub
Jira / YouTrack
Confluence / Wiki
Kubernetes
Terraform
CI/CD
Service Mesh
мониторинг
внутренние инструкции
чат команды
И, конечно:
голова Васи
Человек умеет довольно эффективно собирать этот контекст из разных источников.
Для автономного агента это становится отдельной инженерной задачей.
И здесь появляется IDP
Именно поэтому мне кажется очень естественной связка агентной разработки с IDP — Internal Developer Portal.
Тогда архитектура начинает выглядеть уже немного иначе:
Трекер → Оркестратор агентов → IDP → Агент → CI/CD → MR
В такой модели IDP становится не просто красивым порталом, где разработчик может посмотреть список сервисов.
Он превращается в единый слой инженерного контекста.
Через него агент может определить:
задача
↓
система
↓
компонент
↓
репозиторий
↓
владелец
↓
зависимости
↓
документация
↓
политики
↓
доступные действия
И только после этого переходить непосредственно к изменению кода.
Backstage как фундамент
Поэтому мне особенно интересен Backstage.
В нём уже существует значительная часть фундамента, который нужен для подобной модели:
- каталог сервисов и компонентов;
- связи между сущностями;
- ownership;
- техническая документация;
- шаблоны создания новых компонентов;
- интеграции с CI/CD;
- подключение внутренних систем через плагины;
- единая модель инженерных сущностей.
Конечно, сам по себе Backstage не является агентной платформой.
Он не будет автоматически брать задачу из Jira, писать код и создавать Merge Request.
Но для меня Backstage выглядит как очень хорошая база, поверх которой можно постепенно собрать полноценный Agentic IDP.
┌──────────────────────┐
│ Jira / YouTrack │
└──────────┬───────────┘
│
▼
┌──────────────────────┐
│ Agent Orchestrator │
└──────────┬───────────┘
│
▼
┌────────────────────────────┐
│ IDP │
│ │
│ Service Catalog │
│ Ownership │
│ Dependencies │
│ Documentation │
│ Policies │
│ Templates │
│ Available Actions │
└─────────────┬──────────────┘
│
▼
┌──────────────────────┐
│ Coding Agent │
└──────────┬───────────┘
│
┌───────────┴───────────┐
▼ ▼
Repository CI/CD
│ │
└───────────┬───────────┘
▼
Merge Request
Не нужно сначала строить идеальную платформу
При этом я не думаю, что перед запуском первого агента компания должна несколько лет строить идеальную Internal Developer Platform.
Начинать можно гораздо проще.
Например:
задача
↓
один заранее известный repository
↓
агент
↓
тесты
↓
Merge Request
Для первых сценариев этого вполне достаточно.
Но дальше начинается интересная зависимость.
Чем больше самостоятельности получает агент, тем больше вещей вокруг него приходится формализовывать.
Сначала:
репозиторий
Потом:
репозиторий
+ правила сборки
+ тесты
Дальше:
+ зависимости
+ документация
+ ownership
Потом:
+ архитектурные правила
+ security policies
+ инфраструктура
+ deployment
+ observability
И постепенно компания обнаруживает, что строит уже не просто инфраструктуру для coding agent.
Она строит формализованную модель своей инженерной организации.
Возможно, IDP изначально строили не для того пользователя
Сегодня Internal Developer Portal обычно рассматривается как интерфейс для разработчика.
Разработчик заходит туда, находит сервис, читает документацию, смотрит ownership, запускает какой-то workflow.
Но если посмотреть немного дальше, появляется другой пользователь этой системы:
агент.
Причём для агента такой интерфейс может оказаться даже важнее, чем для человека.
Человек способен:
- спросить коллегу;
- найти информацию в Slack;
- догадаться по названию репозитория;
- посмотреть соседний сервис;
- открыть Kubernetes и разобраться;
- сделать что-то «потому что у нас всегда так делали».
Агенту гораздо лучше дать формальный ответ:
component: order-service
owner: team-commerce
repository:
url: gitlab.company.local/commerce/order-service
depends_on:
- payment-service
- user-service
documentation:
- architecture
- api
- runbook
deployment:
type: kubernetes
namespace: commerce
policies:
- java-platform-policy
- pci-security-policy
actions:
- build
- test
- deploy-dev
- run-integration-tests
И вот такой IDP становится уже не столько порталом, сколько API инженерной организации.
Люди и агенты будут использовать один слой
Отсюда для меня возникает самая интересная мысль.
Агентная разработка и платформенная инженерия, похоже, будут не просто развиваться параллельно — они постепенно начнут сходиться в одну систему.
Потому что чем больше инженерной работы компания хочет отдавать агентам, тем больше ей нужен:
- единый каталог компонентов;
- формализованный ownership;
- граф зависимостей;
- машиночитаемая документация;
- стандартизированные процессы;
- политики;
- API для инженерных операций;
- управляемый доступ к инфраструктуре.
То есть практически всё то, чем последние годы занимается Platform Engineering.
И в таком мире качество внутренней платформы напрямую определяет, насколько автономными вообще могут быть ваши агенты.