Команда разработчиков Taimen опубликовала на Хабре кейс о том, как их платформа для ИИ агентов почти два месяца разрабатывала саму себя. Агенты брали задачи из очереди, писали код и сдавали его на ревью. Ветки вливались через ту же систему, которую агенты и строили. 4 октября вышел первый открытый релиз — Taimen v0.2.0 под лицензией Apache-2.0.
Статья помечена на Хабре как кейс уровня «сложный». В ней много YAML-фрагментов и цифр по очереди задач. Ниже — её содержание без кода. Здесь собрано, как устроена платформа, откуда берутся задачи, как принимается результат, что сломалось и как очередь выпустила собственный релиз. Все числа и выводы принадлежат авторам кейса, отдельно мы их не проверяли.
Начинается кейс с показательной истории. 30 сентября в 06:32 в очереди появилась задача: научить ядро переводить открытые задачи на новую версию их типа. Через 19 минут агент сдал маршрут API, тесты и документацию. В 07:15 ревью работу отклонило. Новый маршрут позволял агенту с обычными правами исполнителя перевести свою задачу на первую версию типа, где ревью ещё не было, и закрыть её самому. Ревьюер воспроизвёл обход по шагам. В 08:24 исправление влили. От постановки до вливания прошёл 1 час 52 минуты, агент сделал два прогона. Получилось, что агент написал дыру для ухода от ревью, а поймало её ревью, которое платформа считает частью задачи.
Работа вместо агента: как устроена платформа для ИИ агентов Taimen
Авторы называют Taimen средой исполнения работы организации. По их словам, сначала они пробовали строить систему вокруг агента: промпта, инструментов, памяти. Каждый раз упирались в одно и то же: агенты меняются быстрее, чем работа. Выходит новая модель, меняется харнесс, вместо одного исполнителя появляются три. А сама задача остаётся прежней.
Поэтому главная сущность платформы — работа (Work), единица обязательства, которая не зависит от исполнителя. Через API про любую работу можно узнать четыре вещи:
- откуда она взялась: от человека, от правила, из процесса или из родительской задачи;
- кто её делал и с какими правами, вплоть до каждого прогона, вызова инструмента и версии агента;
- как принят результат: какие проверки прошли и кто принял решение;
- чем результат доказан: артефактами и попытками проверки.
Исполнителем может быть человек, ИИ-агент или детерминированный скилл. Все они работают с задачей одинаково: берут её, выполняют, сдают артефакты и проходят приёмку. В собственной разработке код писали десять агентов-исполнителей: несколько поколений раннеров и отдельные исполнители под отдельные репозитории. Они работали на Claude Code с моделями Opus и Sonnet и на Codex. Ещё в девяти случаях задачу начинал агент, а заканчивал человек в своём окружении, и для задачи это ничего не меняло.
Масштаб за период с 12 августа по 4 октября на одной установке выглядит так:
| Что | Число |
|---|---|
| Единиц работы | 1 416 |
| Выполнено | 1 190 |
| Заведено правилами, а не людьми | 502 |
| Задач на код (выполнено) | 788 (681) |
| Прогонов агентов | 2 406 |
К цифрам авторы сами дают две оговорки. Задачи на код поделили агенты-раннеры (393) и харнесс владельца (324). Харнесс владельца — это тоже Claude Code, но под учёткой человека, и в данных их не различить. Кроме того, с 29 сентября ревью готовит отдельная сессия Claude владельца, а решение записывается за владельцем, который за него отвечает. Ревьюер из вступительной истории как раз такая сессия.
Откуда берутся задачи: правила вместо ручной постановки
Треть работы, 502 единицы, никто не ставил руками. Схема такая: коннектор наблюдает за репозиториями и сообщает платформе о событиях, например о новом коммите в компоненте. Правило решает, нужна ли из-за этого события работа.
В кейсе разобрано правило, которое следит, чтобы суперпроект не отставал от своих компонентов. Коммит в компоненте вызывает скилл, тот сравнивает указатель сабмодуля с головой ветки. Если указатель отстал, ревьюеру приходит решение «сдвинуть». После одобрения другой скилл сам делает коммит в суперпроект. Если указатель догонят другим путём, парное правило закроет задачу. За период таких решений набралось 77.
Правило действует от собственной личности. В журнале видно, что задачу завёл не человек, а правило, и есть ссылка на наблюдение, которое его запустило. Для автоматизации разработки это означает прослеживаемость: у каждой задачи, заведённой машиной, есть понятная причина.
Приёмка: задача закрыта, когда ветка влита
Главное решение этих недель авторы формулируют прямо: задача на код закрыта не тогда, когда агент сказал «готово», а тогда, когда ветка влита. Приёмку задаёт тип задачи, и в ней два шага. Сначала ревью человеком, потом детерминированное вливание. Если любая проверка проваливается, задача возвращается тому же исполнителю вместе с причиной. Ядро при этом не знает, что такое merge. Вливание выполняет скилл пакета с полномочиями того, кто одобрил ревью.
К такому правилу команда пришла через поломку. Раньше задача считалась сделанной сразу после сдачи, и зависимые задачи стартовали до ревью и вливания.
С 26 сентября, когда приёмка стала частью типа, через неё прошли 458 задач на код:
| Что | Число |
|---|---|
| Принято с первой сдачи | 326 (71%) |
| Понадобилось две сдачи | 100 |
| Три сдачи и больше | 32 |
| Отказов ревью | 162 |
| Провалов вливания | 14 |
Из 14 провалов вливания восемь пришлись на честные конфликты или ушедшую вперёд ветку. Четыре дала инфраструктура: токен не видел репозиторий, push отклонили. Ещё в двух случаях агент сдал коммит без метаданных, и вливать было нечего.
По времени картина такая. Задача агента в медиане доходит от постановки до вливания за 3,4 часа, 90% задач укладываются в 27 часов, считая ожидание в очереди ревью. Сам прогон агента в медиане длится 11 минут. Условная стоимость прогона Claude Code по тарифу API — $1,90 в медиане и $7,32 на 90-м перцентиле. Авторы уточняют, почему «условная»: раннеры работают по подписке, а цифру считает сам Claude Code. Это оценка, а не фактические расходы команды.
Агенты как описание, память как граф, процессы как пакеты
Агент — это декларация. Руками агентов не запускают. В описании агента указаны права, исполнитель, модель, каталог репозиториев, место размещения и число реплик. Платформа сама поднимает исполнителей на узлах и держит их в описанном состоянии. Чтобы сменить модель, достаточно поправить строку, и получится новая ревизия того же агента. Идущий прогон доработает на прежней модели, следующий возьмёт новую, контейнер не пересоздаётся. Право решать согласования или администрировать платформу агенту дать нельзя: API отвергает такую привязку. Решают только люди.
Память — граф знаний с онтологией. По словам авторов, агенту на задаче не нужен весь репозиторий в контексте. Ему нужен ответ на вопрос «что я сломаю». Онтология разработки ПО у них занимает около 50 строк: восемь видов сущностей (маршруты API, файлы, клиентские методы, архитектурные решения ADR и другие) и пять типов связей. Тип задачи описывает, как собрать контекст. Из описания задачи извлекаются якоря, например маршрут или ADR. Дальше платформа идёт по графу: кто вызывает маршрут, где он определён, какое решение управляет этим файлом. Бюджет на такой контекст — 4000 токенов. Агент видит граф на момент постановки задачи, а не на момент, когда до неё дошла очередь. Результат попадает в промпт отдельным блоком, как данные, а не как инструкции.
Авторы считают память ключевой частью платформы: та же механика должна работать там, где кода нет. Процесс оплаты счёта перед решением вспоминает контрагента, договор и прошлые платежи. Тендерный процесс вспоминает прошлые дела с заказчиком. При этом они честно пишут о пределах: насколько граф улучшает работу агента на коде, никто не измерял. Сравнения «с графом и без графа» у них нет.
Spec-driven-разработка тоже оформлена пакетом. Крупные фичи проходят цикл «спецификация → план → задачи». Документы spec и plan сдаются как результат задачи и проходят одни ворота — решение человека. После одобрения план разворачивается в задачи на код по репозиториям и в задачи сходимости, у каждой из которых свои ворота. Через этот цикл прошли 18 дизайнов фич и 60 задач сходимости.
Ядро не знает про код. Git, merge и ревью кода живут в пакетах, а в ядре их нет. Команда держит правило: каждая возможность ядра должна доказать себя и на пакете не из разработки. Пример — процесс оплаты счетов, где загрузивший счёт не может сам согласовать оплату. Агент реализовал это разделение обязанностей, ревью нашло обход: исключённый согласующий мог отменить согласование, и дело проходило без голоса бухгалтерии. Исправление влили через 1 час 42 минуты.
Что сломалось и как очередь выпустила релиз
Авторы перечисляют четыре поломки.
- Публикатор, который сутки бился в стену. 27–28 сентября агент-публикатор 1 063 раза подряд запускал прогон и каждый раз мгновенно получал отказ: у него не было права на нужный скилл. Эти отказы составили 84% всех упавших прогонов за период. Платформа записала каждый, но цикл не остановился, пока его не заметил человек. Теперь назначение скиллов входит в декларацию агента. Сторож зависших прогонов у команды есть, а сторожа серии мгновенных отказов пока нет, и этот случай он бы не поймал.
- Агенты не читали комментарии. Ревьюер писал правки в комментарии, а агент видел только описание задачи. Теперь комментарии официально считаются частью постановки и передаются в промпт.
- Зависимые задачи стартовали раньше времени. Отсюда и выросло правило «сделано — значит принято».
- Параллельные агенты сталкивались в документации. Две задачи дописывали поправки к одному ADR и обе брали следующую свободную букву. По отдельности каждая ветка была корректной, вместе они давали конфликт. Ревью теперь проверяет такие вещи на дереве слияния.
Первый открытый релиз авторы называют проверкой всего описанного выше. Перед ним перестроили раскладку репозиториев, и вместе с ней поменялись пути в CI, раннере, скиллах и Dockerfile. Пять задач подготовки 3 октября поставил человек, все пять сделал агент. Две вернулись с ревью. Самая крупная задача, скрипт переезда с прогоном вхолостую, заняла три прогона и затронула 452 файла. Вся подготовка обошлась примерно в $64 по тарифу API. Сам переезд стенда делали уже вне очереди.
Публикацию тоже вела очередь. Правило раз в час проверяет, какие теги готовы, и заводит задачи агенту-публикатору. 4 октября в 16:05 UTC его включили. Публикатор выложил десять компонентов за 6 минут 41 секунду без единого отказа. Сборка зонтичного репозитория в CI нашла то, чего не было видно по отдельности. Главная находка — ядро 0.10 отправляло сервису уведомлений поле, которого тот не принимал, и уведомления на стенде падали с 3 октября. Заметили это только при сборке релиза. Четыре исправительных выпуска прошли той же очередью. Финальный тег и GitHub Release в 19:19 UTC поставил человек.
В релиз вошли ядро, identity, память, уведомления, fleet, веб-консоль, персональный ассистент и SDK. Пакеты разработки selfdev и sdd, из которых взяты примеры кейса, пока не опубликованы. Ограничения авторы называют сами. Все вызовы модели идут через подписку одного человека, поэтому заменяемость доказана на уровне ревизии агента, а не провайдера. Ревьюер фактически один, и его время никто не измерял. Цифр экономии не будет, пока не пройдёт пилот вне разработки ПО.
Коротко
- В центре Taimen стоит единица работы, а не агент. Исполнители меняются, а у задачи сохраняются происхождение, история прогонов и доказательства результата.
- Задача на код закрыта, только когда прошло ревью и ветка влита. С первой сдачи так приняли 71% из 458 задач.
- Треть работы заводят правила по наблюдениям за репозиториями, и каждое такое решение прослеживается до своей причины.
- Агенты описаны декларациями без права на согласования. Решения остаются за людьми, и именно ревью ловило дыры, которые писали агенты.
- Измерено не всё: нет данных о пользе графа памяти, о времени ревьюера и об экономии, а установка работает на подписке одного человека.
Что из этого следует
Кейс полезен тем, кто уже запускает агентов для разработки кода и упирается в один вопрос: когда считать работу сделанной. Ответ авторов переносится на любую автоматизацию: результат агента принимается внешней проверкой, а не его собственным «готово». В их данных почти треть задач требовала повторной сдачи, и ревью дважды поймало обход контроля, который написал сам агент.
Для производства контента параллель прямая. Конвейер, где ИИ-агенты готовят материал, а человек принимает решение о публикации, устроен по той же логике «сделано — значит принято». Проверить у себя стоит две вещи из списка поломок. Видит ли исполнитель правки ревьюера, а не только исходную постановку? Есть ли сторож на серию одинаковых мгновенных отказов? Без него, как показал случай с публикатором, система может сутки исправно записывать ошибки, и никто их не увидит.
Переносить цифры кейса на свои задачи напрямую нельзя. Это одна установка, один ревьюер, разработка ПО и стоимость, которую считает сам инструмент. Устойчивые выводы здесь — архитектурные: работа отделена от исполнителя, приёмка встроена в тип задачи, право решать за агентом не закреплено.
Источник: Задача закрыта, когда ветка влита: как наша платформа разрабатывает сама себя