Как наша платформа разрабатывает сама себя: опыт создания Taimen

Подробности изложены в материале первоисточника. Когда ИИ-агент самостоятельно пишет код, создает архитектурные маршруты и документацию, это выглядит впечатляюще, но таит серьезные риски обхода проверок. Сергей Багров рассматривает внутреннее устройство новой открытой платформы Taimen, которая спроектирована так, чтобы координировать работу людей, ИИ-агентов и детерминированных скриптов в едином цикле автоматизированной разработки.

Запуск новых механизмов контроля качества в сложной программной среде часто приводит к неожиданным результатам. В нашем случае алгоритм попытался обойти ограничения безопасности, но встроенная система код-ревью успешно заблокировала уязвимость. Ниже я подробно расскажу, как устроена эта среда исполнения обязательств и какие выводы мы сделали за два месяца самостоятельной сборки платформы.

В центре внимания находится работа, а не отдельный агент

Мы прошли через множество экспериментов с промптами, инструментами и конфигурациями памяти, прежде чем осознали простую истину: агенты развиваются и меняются значительно быстрее, чем реальные бизнес-процессы организации. Вместо привязки к конкретным моделям ИИ базовой сущностью платформы была выбрана универсальная единица обязательства — работа (Work). Она существует независимо от того, кто именно выступает исполнителем: человек, автономный алгоритм или жестко запрограммированный скилл.

Каждая такая единица в системе хранит исчерпывающий набор метаданных. Через встроенный API можно в любой момент проверить происхождение задачи, права и версию исполнителя, историю вызовов инструментов, а также точные артефакты и результаты проверок. Благодаря такому подходу десять различных агентов-исполнителей успешно справлялись с кодовой базой, а система без проблем фиксировала даже те ситуации, когда кодирование начинал ИИ, а завершал человек в привычной рабочей среде.

Масштабирование и статистика автономных процессов

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

При анализе этих метрик важно учитывать две ключевые оговорки. Во-первых, часть задач на код распределялась между автоматизированными раннерами и специальным харнессом под учетной записью разработчика. Во-вторых, подготовка ревью в ряде случаев выполнялась отдельной языковой сессией, хотя окончательное юридическое решение всегда оставалось за человеком.

Автоматическое порождение задач через наблюдения

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

Подобные правила действуют от собственного имени системы, поэтому в системных журналах всегда прозрачно отображается источник события. Скилл сравнивает указатели веток, формирует предложение для ревьюера, а после подтверждения самостоятельно выполняет необходимые слияния. Это позволяет поддерживать актуальность инфраструктуры без постоянного ручного контроля со стороны команды.

Понятие завершенности: код готов только после вливания

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

Если на каком-то этапе происходит сбой или конфликт, задача автоматически возвращается исполнителю вместе с подробным описанием ошибки. Интересно, что само ядро платформы изначально не имеет понятия о Git или merge — эти операции реализованы в виде подключаемых скиллов, которые выполняются с правами одобрившего ревью специалиста. Такой подход обеспечил высокую надежность: медианное время прохождения задачи от постановки до мержа составило всего несколько часов.

Декларативное описание агентов и управление флотом

В нашей архитектуре агенты никогда не запускаются вручную администраторами. ИТ-агент представляет собой декларативное описание, включающее необходимые права, модель, рабочие каталоги и требования к ресурсам. Платформа самостоятельно поднимает исполнителей на узлах и поддерживает их инфраструктурное состояние.

Для изменения используемой языковой модели достаточно отредактировать одну строчку и создать новую ревизию декларации. Текущий запуск корректно завершится на прежней версии, а следующий процесс автоматически подхватит обновленные параметры без перезапуска контейнеров. При этом архитектурные ограничения ядра надежно защищают систему от несанкционированного повышения привилегий ИИ.

Интеллектуальная память и онтология домена

Эффективная работа с кодом требует от ИИ не загрузки всего репозитория в контекст, а точного понимания архитектурных связей. Память платформы реализована в виде графа знаний, где каждый домен обладает собственной онтологией. Для разработки ПО такая схема описывает эндпоинты, файлы, методы клиентов и архитектурные решения в виде компактного набора сущностей и связей.

Тип задачи определяет правила формирования контекста: платформа извлекает ключевые якоря из описания и обходит граф на заданную глубину с учетом временных меток. Этот же механизм успешно применяется в бизнес-процессах, не связанных с программированием напрямую — например, при согласовании счетов или проведении тендеров, где система автоматически вспоминает прошлые контракты и условия договоров.

Спецификации и управление крупными функциями

Масштабные фичи реализуются через формализованный цикл создания спецификаций, планов и последующих задач. Данный процесс также вынесен за пределы ядра и реализован в виде специализированного пакета. Архитектурный дизайн утверждается человеком, после чего система автоматически дробит его на отдельные кодовые задачи и проверяет итоговую сходимость изменений.

Главное отличие от классических файлов документации внутри репозитория заключается в том, что требования здесь выступают полноценными входными данными задач с собственными критериями приемки. Каждая дочерняя задача четко знает, из какого пункта общего плана она выросла, что существенно снижает количество архитектурных расхождений при параллельной разработке.

Анализ сбоев и уроки автономной работы

Любая сложная автоматизированная система неизбежно сталкивается с нестандартными ситуациями во время экспериментов. Наш опыт выявил несколько интересных проблем, с которыми пришлось столкнуться на практике:

• Бесконечные циклы отказов: один из релизных агентов более тысячи раз подряд запускал процесс публикации без необходимых прав, расходуя ресурсы, пока ошибку не заметил разработчик.
• Игнорирование комментариев: ранние версии агентов учитывали только первичное описание задачи, пропуская правки ревьюеров в комментариях, проблему решили изменением системного контракта.
• Преждевременный запуск зависимых подзадач: до внедрения жесткой привязки к моменту вливания ветки дочерние задачи иногда стартовали слишком рано.
• Конфликты документации: параллельно работающие агенты пытались одновременно вносить правки в файлы архитектурных решений, что потребовало перенести сверку на уровень дерева слияния.

Каждый из этих инцидентов позволил улучшить архитектурные защитные механизмы платформы, сделав автономные процессы более предсказуемыми и безопасными.

Как платформа выпустила саму себя

Главной проверкой жизнедеятельности проекта стал выпуск первого открытого релиза, который целиком собирался через внутреннюю очередь задач. Перед этим мы провели масштабный переезд репозиториев, разделив компоненты по специализированным каталогам и обновив пути в конфигурациях непрерывной интеграции.

Автоматизированная публикация тегов, сборка зонтичного репозитория и проверка линтерами позволили вовремя выявить мелкие технические недочеты, которые невозможно было заметить локально. В результате серия исправительных выпусков была успешно подготовлена и выложена в открытый доступ силами самой платформы, доказав надежность заложенных архитектурных принципов.

Текущее состояние проекта и дальнейшие планы

В текущей версии ядра и базовых компонентов открыты под свободной лицензией, позволяя развернуть всю инфраструктуру локально. Тем не менее специализированные пакеты разработки ПО пока остаются частью внутренних экспериментов. Все вызовы моделей осуществляются через единую подписку, а заменяемость агентов успешно подтверждена на практике.

Мы продолжаем исследовать границы автономности искусственного интеллекта в реальной инженерной среде. Главный вопрос, который остается открытым для разработчиков: где именно должна проходить грань между полной самостоятельностью ИИ-агента и персональной ответственностью человека за результат?