AI-агенты в платформе разработки быстро перестают быть игрушкой для отдельных команд и превращаются в часть инженерной инфраструктуры. The New Stack 29 августа 2026 года описал три роли, в которых такие агенты уже работают внутри developer platform, и для русскоязычных команд это полезная рамка: она помогает понять, где заканчивается удобный Copilot и начинается новая операционная модель.
Материал написал Matar Peles, solutions engineer в Port, и в нем есть одна важная цифра: 47% организаций, с которыми компания общалась в первой половине 2026 года, поднимали тему реестра агентов и skills. Сам текст, правда, не про модели и промпты, а про скучную, но критичную вещь: как встроить агентный ИИ в платформу разработки так, чтобы он не жил на случайных скриптах, локальных конфигах и чужих токенах доступа. Иначе AI-агенты в платформе будут ускорять ровно до первого инцидента.
Первая роль самая понятная: агент как пользователь платформы. В этой схеме он действует почти как инженер, только без сна и с куда более слабым чувством стыда перед production. The New Stack приводит пример с Claude Code: инженер просит добавить endpoint в платежный сервис, а агент до генерации кода подтягивает из платформы владельца сервиса, зависимости и стандарты, затем поднимает preview-окружение и запускает тесты. Смысл тут не в самом агенте, а в том, что ему нужен доступ к актуальному контексту: каталогу сервисов, ownership, зависимостям, текущему состоянию систем. Если контекст устарел или разбросан по десяти источникам, агент не «немного ошибется», а уверенно сделает неправильную вещь. Поэтому для такого сценария нужны API- и MCP-first-интерфейсы, единый управляемый слой контекста и self-service-действия, которые агент может вызывать без ручного шаманства.
Вторая роль уже интереснее для platform engineering: агент как внутренний компонент платформы, встроенный в workflow. Здесь его запускает не человек, а событие или расписание, а рядом с ним живут обычные детерминированные шаги оркестрации. Пример из статьи: ночная проверка находит уязвимые зависимости сразу в 40 сервисах, после чего платформа поднимает remediation-агента для каждого сервиса, и утром команды получают готовые pull request на ревью. Это уже не «ассистент разработчика», а полноценный кусок процесса. Из этого следуют довольно приземленные требования: нужен реестр агентов, нужна оркестрация, нужна отдельная identity на каждого агента, чтобы действия логировались не под «одолженным» человеческим аккаунтом, и нужен human-in-the-loop там, где риск не декоративный. Для крупных компаний это, пожалуй, ключевой момент: если агент сам открывает PR, трогает зависимости, меняет конфиг или инициирует релизный шаг, вопрос аудита перестает быть бюрократией и становится базовой гигиеной.
Третья роль автор называет фактически AgenticOps: агент рассматривается как самостоятельный ресурс со своим жизненным циклом. Не только сам агент, но и LLM, MCP-серверы, skills, окружение и права доступа должны выдаваться, настраиваться и управляться платформой так же, как сегодня выдаются сервис, база или временная среда. В статье есть пример с on-call triage agent: инженер выбирает модель, инструменты и среду выполнения через форму или текстовое описание, а платформа сама провижинит все необходимое и возвращает уже зарегистрированный, управляемый объект. Это хороший маркер зрелости: AI-агенты в платформе перестают быть самоделкой конкретного энтузиаста и становятся стандартным внутренним сервисом. В логике Port это продолжение идеи golden path: если команда заказывает нового агента, она должна по умолчанию получить не «как получилось», а версию с корректной identity, ограниченными credentials, одобренным контекстом и регистрацией в общем каталоге.
Почему этот текст вообще заслуживает внимания, хотя он опубликован как спонсорский материал Port? Потому что он довольно точно попадает в реальный сдвиг 2026 года. Еще недавно рынок обсуждал в основном персональных кодовых ассистентов, которые помогают одному разработчику. Теперь разговор смещается на уровень команд и платформ: кто выдает агентам доступ, где они берут контекст, как проходят approvals, кто отвечает за опубликованные skills, где хранится аудит, и можно ли масштабировать все это за пределы одной сильной команды с SRE-романтизмом. The New Stack не приводит независимых комментариев рынка и не спорит с подходом Port, но даже в таком виде статья полезна как диагностическая карта. Если у компании агент умеет только помогать в IDE, это первая стадия. Если он уже встроен в CI/CD, remediation и инцидентные процессы, это вторая. Если его можно запросить, собрать и зарегистрировать как управляемый внутренний ресурс, это третья.
Для российских и русскоязычных команд здесь практический вывод довольно простой. Главный вопрос уже не в том, «разрешать ли разработчикам пользоваться агентами», а в том, на каком уровне платформа готова их переварить. Если сервисный каталог дырявый, ownership не поддерживается, права доступа выдаются вручную, а self-service существует только в презентации для CTO, агентный слой лишь ускорит организационный бардак. Если же платформа действительно умеет быть источником контекста, слоем автоматизации и точкой управления жизненным циклом, AI-агенты в платформе дают не только скорость, но и более предсказуемую инженерную систему. В ближайшие кварталы выиграют, похоже, не те компании, у кого больше агентов, а те, кто раньше остальных научится относиться к ним как к штатным, пусть и очень буквальным, участникам SDLC.