Мы с партнёром @skazkin развиваем компанию, в которой код пишут ИИ-агенты. Для этой работы мы разработали и внедрили производственный процесс: от подготовки требований до приёмки системы и сопровождения поставленных версий. Хотим поделиться тем, как он устроен и какими средствами реализован.

Мой участок в этой работе — архитектура процесса. Кто определяет правильное поведение системы, откуда агент получает задание, чем подтверждается результат, что происходит при расхождении. Ниже разберём маршрут целиком: агенты и используемые ими скиллы, агент-оркестратор, эталон системы, выполнение задач, независимые проверки, приёмка, обратная связь и эксплуатация.

Оркестратор ведёт маршрут и сохраняет историю и текущий статус работ. Эти записи задают точку продолжения после перезапуска; решения и ответственность остаются у людей.

1. Агенты выполняют производственные работы, используя скиллы

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

Например, агент, используя скилл постановки, получает источник изменения и эталон компонента, создаёт в tasks/NNNN/task.md постановку задачи: цель, границы работы, ссылки на требования и критерии приёмки. Исполняемые тесты задачи агент подготавливает до реализации и сохраняет отдельно, в tasks/NNNN/test-code/. Другой агент использует скилл реализации: читает постановку, изменяет код и оставляет отчёт. Проверяющий агент использует скилл проверки: получает зафиксированные критерии, выполняет проверки и сохраняет отчёт в tasks/NNNN/test-report/. Агент, использующий скилл закрытия, проверяет наличие оснований приёмки и обновляет индекс задач. Разделение работ агентов закреплено в читаемых входах и сохраняемых выходах каждой работы.

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

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

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

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

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

Оркестратор постоянно поддерживает два связанных представления о разработке:

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

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

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

2. До кода фиксируется эталон системы

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

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

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

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

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

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

Мы фиксируем норму поведения раньше реализации. Эталон включает бизнес-требования BR с целью и критериями успеха, системные требования SR, спецификации SPEC и контрольные примеры TC — описания проверок этих требований. Спецификации раскрывают архитектуру, интерфейсы, данные, безопасность, эксплуатацию и условия тестирования.

Среди спецификаций есть отдельная Use Case (UC): в ней описываются пользовательские сценарии. Каждый сценарий связывает отдельные требования в последовательность действий пользователя и ожидаемых реакций системы. Его проверка выполняется через пользовательский интерфейс UI, с эмуляцией действий пользователя: открыть экран, ввести данные, нажать кнопку, проверить полученный результат. Так подтверждается проходимость пользовательского пути целиком.

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

Контрольный пример задаёт конкретную проверку требования: исходные условия и данные, действия, ожидаемый результат и признаки провала. Например, для требования об округлении стоимости: передать в расчёт итоговую сумму 100,50 рубля и убедиться, что результат равен 101 рублю. Такое описание входит в эталон и определяет, какой результат считать правильным.

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

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

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

Эталон также создают агенты; человек утверждает решения. Это заметная часть работы, а не оформление после разработки. Цена выбора — необходимость разбирать неоднозначность до кода. Выигрыш — возможность указать, относительно какого поведения результат вообще проверяется. Полнота этого описания остаётся ограничением: тест не обнаружит нарушение правила, которое нигде не сформулировано.

3. Изменения эталона превращаются в пул задач

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

В описанной здесь реализации эти возможности обеспечивает хранение артефактов файлами в Git.

Принципиальная единица фиксации — комплект эталона целиком. Нельзя получить задачу по одному набору требований, тестировать по другому и назвать это соответствием системе. Версия связывает требования, спецификации и нормативные TC в один определённый срез с однозначным идентификатором. В файловой реализации для этого используются тег вида renar-<модуль>-vN.M и индекс VERSIONS.md.

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

Сравнение версий даёт исходный материал для планирования. Взять изменение в работу — отдельное решение; появление нового минора не переключает начатые задачи автоматически.

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

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

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

4. Задача проходит разделённые сессии и проверки

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

Маршрут задачи построен на пяти контрольных точках. На QG-0 проверяется достаточность контекста: цель, критерии, границы, негативные сценарии и риски. На QG-1 подтверждается нормативное основание и готовность тестов задачи. Затем агент выполняет работу. На QG-2 предъявляются результаты тестов задачи, регрессионного прогона модульных тестов, сборки и применимых автоматических проверок. QG-3 отведён независимому ревью. На QG-4 человек персонально фиксирует приёмку результата.

Постановка, реализация и контроль выполняются в разных сессиях. QG-4 фиксирует ответственность за принятие уже проверенного результата.

Для задачи создаются собственные тесты, TT. Их критерии фиксируются до реализации; автор постановки и тестов отделён от исполнителя. Начальный прогон позволяет увидеть, что проверка действительно обнаруживает отсутствие нового поведения. Зелёный результат до начала работы требует объяснения: возможно, функциональность уже существует или тест ничего не проверяет. Для работ без изменения поведения применяется иной контекст доказательства; искусственно ломать систему ради красного индикатора не требуется.

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

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

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

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

5. Готовность задач проверяется на уровне системы

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

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

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

При этом результаты проверок и версия тестов, на основании которых была принята задача, сохраняются как историческое доказательство. Модульные тесты в постоянном наборе могут развиваться вместе с кодом; это не переписывает основание прежней приёмки. Исполняемые тесты, созданные по TC, образуют отдельный набор для проверки собранной системы на соответствие эталону. Поэтому модульный регресс после задач и интегральный прогон TC на уровне этапа имеют разные назначения. В файловой реализации материалы приёмки задачи находятся в tasks/NNNN/, инструментальные реализации TC — в tc-tests/<scope>/<TC-ID>/impl/.

Для интегральной проверки агент использует скилл tc-runner: находит нормативные TC, создаёт недостающие исполняемые тесты, запускает проверки и организует ограниченный цикл исправлений. Нормальный выход его работы — подтверждённое соответствие либо зарегистрированная проблема, по которой понятно, почему продолжение невозможно. Количество удачно завершившихся процессов агента эту картину не заменяет.

Для ориентира, рабочие артефакты компонента разнесены по таким путям:

<компонент>/renar/                        # эталон и история его версий
<компонент>/tasks/NNNN/task.md            # постановка и критерии задачи
<компонент>/tasks/NNNN/test-code/         # исполняемые тесты задачи
<компонент>/tasks/NNNN/test-report/       # результаты сценарной проверки
<компонент>/tc-tests/<scope>/<TC-ID>/impl/ # исполняемая реализация TC
<компонент>/issues/ISSUE-NN.md            # симптом, разбор, решение

Агент-диагност определяет объект исправления. Агент, выполняющий исправление в отдельной сессии, получает этот диагноз; закрыть проблему позволяет подтверждающий прогон.

При падении теста сначала запускается агент в отдельной диагностической сессии. Используя скилл диагностики, он читает требование, тест и наблюдаемый результат, определяет предполагаемую причину и фиксирует находку. Затем другой агент в отдельной сессии использует скилл исправления и выполняет работу строго по диагнозу. Для ошибки кода он меняет код, для ошибки инструментальной проверки — тест. Сомнение в норме передаётся человеку. Автоматическая починка ограничена тремя попытками; затем остаётся проблема для разбора, а не бесконечная генерация вариантов.

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

Параллелизм также ограничен ресурсами. Два сценария, меняющие данные, нельзя безусловно запускать на одном стенде: они будут влиять друг на друга. Поэтому ёмкость пула изолированных стендов ограничивает параллельные проверки, а отдельный лимит — одновременные вызовы агентов. Стенд подготавливается по SPEC-TEST; результат прогона связан с определённой конфигурацией среды и тестовыми данными.

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

6. Поставку принимают по итоговому ТЗ

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

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

Альтернатива — принять систему на основании внутренних TC и успешной демонстрации. Это проще, но внутренняя цепочка могла изначально неверно понять ТЗ. Если эталон и реализация согласованно воспроизводят одну ошибку интерпретации, дополнительный прогон того же набора её не обнаружит.

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

Для собственного продукта без внешнего ТЗ такой контрактный маршрут отсутствует. Есть внутреннее подтверждение результата относительно принятого замысла и эталона. Добавлять к нему вывеску «независимая контрактная приёмка» было бы неверно: отдельного источника обязательств здесь нет.

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

7. Проблема проходит разбор до исправления

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

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

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

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

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

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

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

8. После поставки сохраняются версии и знания

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

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

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

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

Пример, ограничения и развитие реализации

Сквозной пример

Рассмотрим условный пример, он не описывает конкретный клиентский проект. По согласованному ТЗ итоговая стоимость сохраняется с копейками. Заказчик просит округлять её до целого рубля: дробную часть меньше 50 копеек отбрасывать, от 50 копеек — округлять вверх. Замечание регистрируется как проблема.

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

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

Другой агент, используя скилл реализации, изменяет код. Проверяющий агент подтверждает выполнение задачи по TT и результатам модульного регресса. На уровне этапа агент со скиллом tc-runner проверяет собранную систему по TC. Перед поставкой отдельный агент создаёт AT из уточнённого ТЗ; их прогон проверяет новое обещание заказчику. В истории остаётся цепочка от замечания до принятой версии. Агент в следующей сессии может восстановить причину изменения без пересказа участников.

Границы и открытые вопросы

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

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

Дальнейшей проработки требуют несколько вопросов устройства самого процесса:

• Приёмка эталона. Каких проверок полноты, согласованности и проверяемости требований достаточно для утверждения версии? Как обнаруживать пропущенное поведение, если оно ещё не отражено ни в требованиях, ни в TC?

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

• Параллельные изменения. Как согласовывать изменения общего эталона, подготовленные разными агентами? По каким признакам обнаруживать конфликт до объединения и решать, какие уже начатые работы нужно пересмотреть?

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

От Git к сервису для командной работы

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

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

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

Мы планируем выпустить эту реализацию как продукт «Киберза», в котором описанный производственный процесс будет объединён с общей средой командной работы, инструментами утверждения и фиксации и поддержкой ролей участников.