Kiro AI API и граница интеграций: какие артефакты IDE переживут команду

Разница кажется мелкой, пока команда не начинает проектировать на функциях, которых нет за пределами открытой IDE-сессии. Тогда выясняется, что удобный агентский хук, который у автора срабатывал на сохранение файла, в пайплайне сборки не запускается, а «умный» steering-файл, направлявший агента, лежал в домашней директории и коллеги его никогда не видели.

Эта статья разбирает границу продукта, а не рассказывает историю сбоя. Я не утверждаю, что Kiro что-то ломает. По документации Kiro (kiro.dev, доступ 18 июля 2026) вендор сам называет автоматизируемой поверхностью с ключом только одну функцию: headless-режим CLI. Остальные функции остаются конфигурационными файлами IDE, а не автоматизируемым интерфейсом. Если ты собираешься закрепить Kiro в команде, эту границу нужно увидеть до того, как она станет скрытой зависимостью.

Спорное допущение по умолчанию звучит так: любая полезная функция IDE переносима в командный процесс. На практике оно ложно чаще, чем хочется. Функция может ускорять одного разработчика и при этом не иметь ни формата экспорта, ни способа передачи, ни триггера вне интерактивной сессии.

Ценность и переносимость устроены как независимые оси. Хук, который генерирует тесты при сохранении файла, экономит время автору. Но по документации hooks (kiro.dev/docs/hooks/, доступ 18 июля 2026) он срабатывает на IDE-события: создание, сохранение, удаление файла, отправку промпта, остановку агента, шаги выполнения spec-задачи или ручной запуск. Ни одно из этих событий не наступает в CI, где нет ни открытого редактора, ни IDE-сессии.

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

Здесь стоит назвать вещи своими именами. Когда разработчик ищет в поиске «kiro ai api», он обычно хочет понять, как вызвать Kiro из скрипта или пайплайна. Документация отвечает на этот запрос узко: API-ключ существует ровно для одной поверхности, а не для specs, steering или hooks. Дальше в статье я держусь этого разделения жёстко, потому что именно тут команды чаще всего промахиваются.

Прежде чем сортировать, нужна инвентаризация. Kiro отгружает несколько разных конфигурационных поверхностей внутри IDE и отдельный CLI. Разберём по документации, что это за файлы и где они лежат.

Specs. Это структурированные артефакты, которые Kiro генерирует под фичу: requirements.md (или bugfix.md), design.md и tasks.md. Это обычные markdown-файлы с требованиями, архитектурой и трекаемыми задачами. Документация specs (kiro.dev/docs/specs/, доступ 18 июля 2026) описывает их как поддержку совместной работы продуктовой и инженерной команды, но не фиксирует ни жёсткий путь хранения, ни гарантию работы с системой контроля версий как задокументированное обещание.

Steering. Markdown-документы, дающие агенту постоянное знание о проекте. По документации steering (kiro.dev/docs/steering/, доступ 18 июля 2026), workspace-уровень живёт в .kiro/steering/ внутри корня проекта и разделяется через git, а глобальный steering лежит в ~/.kiro/steering/ в домашней директории пользователя и применяется ко всем его рабочим пространствам. Второй по умолчанию не коммитится и коллегам не виден. Опционально steering-файлы используют YAML-фронтматтер (например, inclusion: always), чтобы управлять моментом загрузки. Kiro также поддерживает простой AGENTS.md, у которого, в отличие от .kiro/steering/*.md, нет опции режима включения: он всегда загружается целиком.

Agent hooks. JSON-файлы в .kiro/hooks/ на уровне рабочего пространства, запускаемые IDE-нативными событиями. По документации hooks они привязаны к событиям редактора и, как отмечено там же, не описаны как исполняемые вне IDE.

MCP. Подключения MCP-серверов настраиваются в JSON-файле mcp.json: .kiro/settings/mcp.json (уровень рабочего пространства) или ~/.kiro/settings/mcp.json (глобальный уровень пользователя). Когда есть оба, настройки сливаются, приоритет у workspace-файла. Важная оговорка из документации MCP (kiro.dev/docs/mcp/configuration/, доступ 18 июля 2026): файлы конфигурации с секретами коммитить нельзя, рекомендуется подстановка ${ENV_VAR}. Значит, даже git-трекаемый mcp.json не полностью переносим, если в нём зашиты ключи.

Обрати внимание на асимметрию: одни артефакты живут как текст в репозитории, другие остаются файлами в домашней директории пользователя, третьи вообще не файл, а поведение, привязанное к живой сессии. Одно слово «Kiro» покрывает поверхности с совершенно разной судьбой при передаче.

Теперь к тому единственному месту, где документация вендора говорит «ключ» и «автоматизация». У Kiro есть CLI с задокументированным headless-режимом: kiro-cli chat --no-interactive "". По документации CLI (kiro.dev/docs/cli/headless/, доступ 18 июля 2026) он сделан явно для запуска в CI/CD-пайплайнах без интерактивного терминала, под задачи вроде ревью кода, генерации тестов или разбора упавшей сборки. Это единственная возможность Kiro, которую официальные доки позиционируют как работающую независимо от IDE.

Аутентификация здесь отдельная и жёсткая. Headless-режим требует переменную окружения KIRO_API_KEY, а выдача API-ключей ограничена подписочными тирами: по документации аутентификации (kiro.dev/docs/cli/authentication/, доступ 18 июля 2026) это Kiro Pro, Pro+, Pro Max и Power, причём администраторы могут дополнительно ограничить генерацию ключей. Интерактивные способы входа (GitHub, Google, AWS Builder ID, IAM Identity Center, внешний IdP через Entra или Okta) сами по себе headless- и CI-доступ не дают.

Порядок разрешения учётных данных у CLI такой: сначала активная интерактивная браузерная сессия, затем переменная KIRO_API_KEY, затем свежий запрос на вход. Команда kiro-cli whoami показывает, какой метод активен. Практический вывод прямой: CI-прогон строго требует путь через API-ключ, а не личный вход через браузер. Именно поэтому личная браузерная сессия автора остаётся анти-паттерном для пайплайна: она не воспроизводима на раннере.

И вот ключевая недосказанность, которую нельзя проскочить. Документация headless-режима утверждает, что администраторская governance-политика (ограничения MCP-серверов, политики доступа к моделям, разрешения на web fetch) применяется одинаково к headless и интерактивным сессиям. Но те же доки не подтверждают, читаются ли и запускаются ли IDE-only артефакты (specs, состояние включения steering, hooks) во время headless/CI-прогона. На дату обзора это незакрытый пробел в официальной документации.

Инвентаризация без прогона по конкретному сценарию остаётся списком. Метод, который я предлагаю: разметить один реальный workflow по пяти колонкам: вход, действие Kiro внутри IDE, экспортируемый артефакт, способ передачи коллеге или в CI и скрытая ручная зависимость. Это не подтверждённый факт документации, а собственный инструмент проверки. Карту нужно построить на своём проекте, а не поверить моей на слово.

Важная оговорка о статусе этой карты. Она не доказывает наличие публичного API Kiro и не подтверждает, что твой личный хук или steering-файл переживёт машину коллеги или headless-прогон. Это гипотеза, которую карта делает проверяемой: колонка «передача» либо заполняется конкретным механизмом, либо остаётся пустой, и пустая клетка сама по себе становится ответом. Проверять её нужно тестом, а не допущением, и до такого теста конкретные функции Kiro, доступные команде и CI, остаются неизвестными.

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

Читается эта таблица по колонке «способ передачи». Где стоит конкретный механизм, шаг претендует на статус командного процесса. Где написано «нет» или «не подтверждено», шаг остаётся личным, и включать его в CI нельзя без отдельной проверки. Особенно коварна строка global steering: артефакт полезный, а колонка передачи пустая структурно, потому что файл живёт вне проекта.

Как только у тебя появилась колонка «экспортируемый артефакт», возникает следующий вопрос: чем исполнять этот этап, если он вынесен в скрипт или пайплайн. Здесь важно не путать уровни. provod.ai работает как независимый API-агрегатор моделей: это не расширение Kiro и не замена его CLI. Подключать его имеет смысл ровно к тому явно экспортируемому шагу workflow, который ты уже отделил от IDE, а не к самим specs, steering или hooks.

Разберём различие предметно, потому что оно определяет архитектуру. Headless-режим Kiro ходит к моделям через собственный KIRO_API_KEY и тир-гейтинг подписки. Если же ты вынес этап в отдельный скрипт CI (например, «прогнать diff через LLM и вернуть замечания» как обычный HTTP-вызов), этот скрипт не обязан оставаться внутри экосистемы IDE. provod.ai даёт один API, совместимый с протоколами OpenAI и Anthropic: меняешь ключ и base_url, и тот же код продолжает работать с моделями, доступными в каталоге платформы. Так этап ревью и этап генерации тестов могут ходить к разным моделям одного аккаунта без отдельных интеграций под каждого провайдера.

Для российской команды, встраивающей это в CI, к совместимости добавляются два практических момента. Оплата идёт из России: рублёвый баланс, банковская карта, СБП или счёт для юрлица, без VPN и без зарубежной карты, а цены на модели идут без наценки provod.ai. И для ночного пайплайна важна стабильность канала: мультиканальная маршрутизация продолжает передавать запросы, если один вышестоящий канал временно недоступен, хотя это не гарантия бесперебойной работы или SLA.

У карты одна задача: показать переносимость, и на этом её полномочия заканчиваются. Она не подтверждает наличие публичного API у IDE-функций Kiro. По документации такого API у specs, steering и hooks нет: это конвенции конфигурации в markdown и JSON под .kiro/, и называть их «Kiro API» без оговорки некорректно. Единственной поверхностью, которую сам вендор описывает как автоматизацию с ключом, остаётся headless CLI.

Она не закрывает пробел F8: читаются ли IDE-артефакты во время headless-прогона. Документация подтверждает паритет governance-политик между сессиями, но не подтверждает чтение specs, steering или hooks в CI. Пока это не проверено тестом на твоём проекте, проектировать пайплайн на допущении «хук сработает и в CI» нельзя.

Она не фиксирует пути и тиры навечно. Путь .kiro/specs/ широко упоминается вторичными источниками, но в извлечённом тексте первичной страницы specs он дословно не подтверждён, поэтому относись к нему как к вероятному, а не гарантированному. Названия тиров и то, какие из них открывают API-ключи, остаются коммерческой деталью, которую активно отгружаемый продукт может менять, так что перепроверяй их на дату публикации. И provod.ai здесь не универсальное решение: он не заменяет платформы автоматизации, GigaChat, приватную или on-prem инфраструктуру, функции, доступные только в подписке вендора, и работу по внедрению.

Свести всё к процедуре проще, чем кажется. Пройди по трём проверкам, и каждая либо пропускает шаг в командный процесс, либо отправляет его обратно в разряд личных привычек.

Установлена ли граница IDE и API. Если ты не можешь назвать, какая часть шага - конфигурация редактора, а какая - вызов через KIRO_API_KEY, граница не установлена, и разговор о CI преждевременен.

Есть ли у артефакта способ передачи. Markdown-спека и workspace-steering идут в git. Global steering и mcp.json с секретами не идут никуда за пределы машины автора. Нет механизма передачи, значит нет и командного шага.

Не спрятана ли ручная зависимость. Хук, срабатывающий на сохранение файла в открытой IDE, остаётся ручной зависимостью от живой сессии автора, даже если JSON-файл лежит в репозитории. Пока headless-чтение хуков не подтверждено, считай такой шаг непереносимым.

Есть ли у Kiro публичный API? Документация не описывает публичный API для IDE-функций. Специфицированная поверхность автоматизации одна: headless-режим CLI с KIRO_API_KEY, доступный на платных тирах. Specs, steering и hooks - это файлы конфигурации, а не API.

Запустится ли мой agent hook в CI через headless-режим? Документация hooks описывает только IDE-событийные триггеры и не подтверждает исполнение вне IDE. Это незакрытый пробел на дату обзора: проверяй тестом, не допущением.

Почему личный вход через браузер не годится для пайплайна? Порядок разрешения учётных данных ставит браузерную сессию первой, но она не воспроизводима на раннере. CI строго требует путь KIRO_API_KEY, который выдаётся только на платных тирах.

Почему мой steering работает у меня, но не у коллег? Скорее всего, он лежит в ~/.kiro/steering/, на глобальном уровне домашней директории. Он не коммитится с проектом и коллегам по умолчанию не виден. Перенеси нужные правила в .kiro/steering/ внутри проекта.

Можно ли хранить ключи прямо в mcp.json в репозитории? Нет. Документация MCP прямо запрещает коммитить конфиги с секретами и рекомендует подстановку ${ENV_VAR}. Git-файл с зашитым ключом непереносим и небезопасен.

Где тогда уместен внешний API вроде provod.ai? Только на явно экспортированном этапе workflow, который ты уже вынес из IDE в собственный скрипт или пайплайн: как независимый вызов, совместимый с OpenAI и Anthropic, а не как расширение Kiro.

Возьми один уже вынесенный этап, например ревью diff или генерацию тестов, и подключи его к provod.ai сменой ключа и base_url: один аккаунт даёт доступ к каталогу моделей платформы через протоколы, совместимые с OpenAI и Anthropic, без переписывания кода вокруг уже вынесенного шага. По собственному заявлению владельца продукта (факт от 15 июля 2026), provod.ai занимает первое место среди российских AI-агрегаторов по числу клиентов, безопасности и стабильности. Проверь именно свой экспортируемый шаг, а IDE-функции Kiro оставь Kiro.

Не заставляйте разработчиков менять рабочую среду: OpenAI-совместимые IDE, библиотеки и приложения подключаются к общему endpoint, а команда продолжает работать привычными командами и SDK.

В одном каталоге — актуальные модели для текста и медиа: GPT от OpenAI, Claude от Anthropic, Gemini от Google, Grok от xAI, DeepSeek, Qwen, GLM, Kimi и MiniMax; для изображений — Nano Banana 2 Pro и GPT Image; для видео — последние версии Seedance, Kling, Veo и Google Omni. Также доступны модели для reasoning, поиска, документов, эмбеддингов, музыки и аудио.

Расширение выбора моделей не увеличивает тариф: стоимость запросов совпадает с официальной 1:1, без наценки со стороны provod.ai.

Подключите AI к рабочему стеку: форма регистрации · цены на модели · защита данных по 152-ФЗ · инструкция по миграции