Организация AI-разработки, в которой каждый разработчик работает в своей зоне, а следующая задача может использовать решения, принятые на другой стороне.
Бэкенд-разработчики закончили несколько задач и влили их в develop. Фронтендер берётся за связанную часть функциональности и открывает новую сессию агента.
Знакомый запрос: «Для синхронизации посмотри вот эти коммиты, потом вот это дополнение и ещё этот фикс». До начала реализации кто-то должен собрать историю и объяснить, какие решения из неё всё ещё актуальны.
Я хотел встроить эту координацию в процесс проекта. Для этого организовал OpenSpec как две узко сфокусированные системы: одну для фронтенда, другую для бэкенда. У каждой — свои спецификации поведения, локальные инструкции, записи изменений и проверки. Между ними — общие контракты.
Разработчики могут независимо выполнять свои части общей командной задачи, оставляя следующему участнику актуальное описание того, на что он может опереться.
То же устройство помогает разработчику выполнить небольшую, чётко ограниченную доработку на другой стороне. В целевой зоне уже есть контекст для её проектирования, реализации и проверки.
Структура и примеры ниже обобщены. Под develop понимается общая интеграционная ветка команды.
Что здесь даёт OpenSpec
OpenSpec организует работу вокруг действующих спецификаций и отдельных изменений — change. Изменение может содержать предложение, требования, техническое решение и задачи реализации. После реализации принятое поведение включается в действующие спецификации, а change архивируется.
Эти артефакты отвечают на разные вопросы:
Specs: какое поведение сейчас должна обеспечивать система?
Активные changes: что предлагается или реализуется?
Архив changes: что изменилось и почему?
В своей организации проекта я применил этот цикл отдельно к фронтенду и бэкенду и связал его с локальными правилами, знаниями о домене и проверками. Это устройство процесса вокруг OpenSpec; сама установка инструмента команду не синхронизирует.
Две микросистемы разработки внутри одного проекта
Я выделил отдельные области спецификаций и изменений для фронтенда и бэкенда. У каждой — свои соглашения, задачи реализации и команды проверки.
project/ shared-domain-reference frontend/ local-guidance openspec/ specs/ changes/ backend/ local-guidance openspec/ specs/ changes/
Под микросистемами я имею в виду два самостоятельных набора знаний и рабочих правил, а не два сервиса. Спецификации фронтенда подробно описывают взаимодействие, клиентское состояние и использование API. Спецификации бэкенда — поведение сервисов, валидацию и правила работы с данными.
Разработчику не нужна одна универсальная спецификация обо всём приложении. Он начинает с подходящих спецификаций своей зоны, а при наличии зависимости читает контракт другой стороны. Агент получает более точную отправную точку, разработчику приходится восстанавливать меньше контекста.
Локальные процессы решали разные вопросы. Бэкенд-разработчик работал с поведением сервисов и его проверками. Фронтенд-разработчик — со взаимодействием, клиентским состоянием и своими проверками. Локальная задача на реализацию сама по себе не давала агенту разрешения менять другую зону.
Общий справочник задавал единые смыслы. Действующие спецификации зоны описывали её поведение. Записи изменений показывали, что предлагается или реализуется.
При этом зоны не были информационно изолированы. Агент мог прочитать нужную спецификацию другой стороны, сохранив правки в границах своей задачи. Инструкции маршрутизации выбирали рабочую зону; сквозные изменения требовали согласованной работы в обеих.
Так фронтендом и бэкендом могли заниматься разные разработчики, в разных сессиях и по собственному графику. Одному агенту не требовалось поручать всю функциональность целиком.
Что означает «другая зона будет знать об изменении»
Переписка одного агента не переносится автоматически в память другого. Информация передаётся через обновлённые и доступные документы проекта.
Бэкенд-разработчик + агент → согласовать затронутый контракт → реализовать и проверить изменение бэкенда → обновить действующую спецификацию → сделать изменение доступным в общем репозитории Фронтенд-разработчик + новая сессия агента → прочитать нужную спецификацию и статус изменения → при необходимости проверить реализацию → спланировать и выполнить задачу фронтенда
Вторая задача получает доступное для проверки описание решения. Не нужно сохранять открытой первую переписку или использовать того же агента.
Для такой передачи важны три условия: документы описывают нужное поведение, читающая сторона получила версию с обновлением, а задача направляет агента к соответствующей зависимости. Устаревшая рабочая копия не узнает о последующем изменении.
Предложенный контракт, реализованный контракт и поведение, доступное в нужном окружении, — разные состояния. Разработчику потребляющей стороны нужно различать их до использования новой возможности. Влитая в репозиторий спецификация не является уведомлением о релизе.
Параллельная разработка возможна после согласования общего контракта. Интеграция при этом зависит от доступности соответствующей реализации.
Несколько задач бэкенда влиты. Как фронтенду догнать изменения?
Возьмём обобщённую командную задачу: для новой функциональности интерфейса требуется несколько связанных доработок бэкенда. Разные разработчики заканчивают их в разное время и вливают в develop.
При синхронизации через коммиты фронтендер собирает для агента список на чтение. В нём могут оказаться первая реализация, её исправление и последующее изменение контракта. Агенту приходится восстанавливать итоговое поведение по этой последовательности.
В процессе с OpenSpec каждое завершённое изменение бэкенда также обновляет затронутые действующие спецификации. Когда фронтендер подтягивает develop в свою рабочую ветку, вместе становятся доступны код и соответствующие описания.
Задача бэкенда A → код + обновление спецификации ─┐ Задача бэкенда B → код + обновление спецификации ─┼→ develop Задача бэкенда C → код + обновление спецификации ─┘ │ Фронтендер обновляет свою ветку ←──────────────────┘ → агент читает нужные актуальные спецификации бэкенда → проверяет зависимости и при необходимости реализацию → предлагает change в OpenSpec фронтенд-зоны → реализует и проверяет локальные задачи → обновляет спецификации фронтенда
Поэтому постановка агенту может выглядеть так:
Для этой функциональности прочитай нужные спецификации бэкенда из обновлённой ветки. Определи доступный контракт и необходимые изменения фронтенда. Проверь незакрытые зависимости и предложи change во фронтенд-зоне. Обращайся к реализации и истории изменений там, где спецификация оставляет вопрос открытым.
Разработчик по-прежнему ставит задачу. Но ему больше не нужно вручную подобранным списком коммитов объяснять агенту текущее поведение бэкенда.
История Git остаётся полезной для расследования. Действующие specs дают описание текущего поведения, активные changes показывают незавершённую работу, архив объясняет предыдущие решения.
Если две бэкенд-задачи затрагивают один контракт, их итоговые изменения спецификации нужно согласовать при ревью и интеграции. Удобство возникает благодаря поддержанию итогового состояния вместе с кодом: OpenSpec не вычисляет его автоматически из произвольных коммитов.
Для команды это упрощает передачу связанных задач между разработчиками и сессиями: каждая завершённая часть оставляет пригодные входные данные для следующей.
Фронтендер может сделать и небольшую доработку бэкенда
Иногда для завершения фронтенд-задачи нужна узкая доработка бэкенда. Если у неё понятный контракт и ограниченная область влияния, разработчик может вместе с агентом пройти процесс OpenSpec в бэкенд-зоне, опираясь на её инструкции.
Он читает подходящие спецификации бэкенда и локальные правила, исследует затронутую реализацию, предлагает небольшое изменение, выполняет проверки зоны и передаёт результат на соответствующее ревью. Фронтенд-часть остаётся отдельным локальным изменением относительно согласованного поведения.
В обратную сторону это работает так же: бэкендер может выполнить небольшую клиентскую адаптацию, используя спецификации и проверки фронтенд-зоны.
Полезная граница здесь — объём изменения и способность разработчика проверить решение. Узкая адаптация контракта отличается от перепроектирования хранения данных, авторизации или конкурентного выполнения. Крупные архитектурные изменения требуют профильных специалистов.
Подробный локальный контекст облегчает ограниченную работу за пределами основной специализации. Техническое суждение и ревью владельца зоны остаются необходимыми. Две микросистемы позволяют переходить границу, используя правила той стороны, где выполняется правка.
Что передавать другой зоне вместе с изменением
Для изменения, затрагивающего другую сторону, я бы использовал такую короткую запись. Это переносимый шаблон, а не встроенная схема OpenSpec.
Зона — владелец поведения: Зона — потребитель: Поведение до изменения: Поведение после изменения: Смысл ответов, состояний и ошибок: Совместимость / необходимые действия потребителя: Статус контракта: предложен / согласован Ссылка на реализацию и её статус: Доступность в целевом окружении: Ссылка на действующую спецификацию: Связанная задача потребителя: Результаты проверок:
Эти поля отвечают на вопросы, которые иначе расходятся по сообщениям: что изменилось, что мне нужно поменять и можно ли этим уже пользоваться?
У каждого контракта должно быть одно основное описание, на которое ссылаются зависимые задачи. Несколько копий одной договорённости создают несколько мест для расхождения. Другой зоне нужны надёжная ссылка и возможность прочитать нужную версию.
Если изменение полностью локально и сохраняет контракт, в записи достаточно явно указать, что действия потребителя не требуются.
Что я добавил вокруг работы со спецификациями
Разделение папок само по себе не обеспечивает координацию. Я связал процесс со знаниями о проекте:
Исследование перед предложением. Изучить текущее поведение и зависимости до описания изменения. Для сложной задачи исследование без правок можно распределить по отдельным вопросам.
Общий справочник домена. Сохранить единые смыслы бизнес-понятий в разных представлениях и зонах реализации.
Локальные ограничения. Разместить повторяющиеся риски рядом с областями, к которым они относятся, чтобы следующая задача могла их найти.
Согласование предложения человеком. Решить вопросы границ и контракта до реализации.
Проверки и актуализация знаний в одном изменении. Выполнить нужные проверки и обновить затронутые спецификации и справочники вместе с кодом.
Важна зависимость между этими шагами: спецификация опирается на существующую систему, а реализация возвращает принятые знания в спецификацию.
Поэтому завершённая локальная задача оставляет после себя и изменения кода, и исходные данные для разработчика, чья работа от неё зависит.
Как начать без документирования всего репозитория
Выберите одно взаимодействие двух зон, которое сейчас приходится регулярно объяснять заново.
Определите владельца и потребителя. Кто отвечает за контракт и кто на него опирается?
Опишите текущее поведение. Включите значения и ошибочные исходы, существенные для потребителя.
Создайте локальное изменение для каждой стороны. Свяжите оба с согласованным контрактом. Задачи и проверки оставьте специфичными для своей зоны.
Явно оформите передачу работы. Что изменилось, что требуется потребителю и какая реализация доступна?
Проверьте передачу на следующей задаче. Может ли другой разработчик с новой сессией агента продолжить работу по этим материалам, не восстанавливая предыдущую переписку?
Последний вопрос — практическая проверка такого устройства. Полезная спецификация позволяет продолжать работу между людьми и сессиями.
В итоге получаются две узко сфокусированные микросистемы разработки, работающие на общий командный процесс. Разработчики могут выполнять свои части общей функциональности, подхватывать уже влитые изменения коллег и делать небольшие адаптации в соседней зоне. OpenSpec даёт каждой стороне актуальное описание её поведения и повторяемый процесс его изменения.
Когда одна сторона вашего приложения меняет контракт, где другая находит его смысл, статус реализации и необходимые дальнейшие действия?
