Archspec investigate: как LLM ловит межсервисные конфликты до написания кода

Разработчик проверил, может ли LLM обнаруживать межсервисные конфликты на этапе планирования — до первой строчки кода. Инструмент — archspec с машиночитаемыми контрактами `SERVICE_MAP.yaml`, фича — автоматическое переназначение задачи после отказа фрилансера.

Где LLM теряет межсервисный контекст В первой части цикла автор

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

Контракты вместо свободного

Markdown Вторая часть цикла представила archspec — инструмент, который генерирует на каждый сервис файл `SERVICE_MAP.yaml`. Это не текстовая документация для людей с описаниями в свободной форме, а машиночитаемый контракт: явные ограничения, допустимые переходы между состояниями, зависимости между сервисами и требования к данным на каждом переходе.

Разница принципиальная. Свободный Markdown — текст, который LLM интерпретирует с домыслами. `SERVICE_MAP.

yaml` — структурированные данные, которые модель разбирает детерминированно. Нет места для «галлюцинаций» о неявных соглашениях. Ключевые элементы контракта: Явные входные и выходные форматы для каждого сервиса Допустимые переходы между статусами бизнес-объектов Обязательные поля при межсервисных вызовах Ограничения по бизнес-логике на границах сервисов ## Что показал /archspec:investigate Условия теста строгие: тот же промпт, та же модель (Claude Sonnet 4.

6), та же фича. Единственная разница — поверх `SERVICE_MAP.yaml` вместо свободного текста.

«Тот же промпт, та же модель.

Вопрос один: поймает ли план те межсервисные ошибки ещё до написания кода», — формулирует автор суть эксперимента. С контрактами модель обнаружила межсервисные конфликты уже на этапе планирования — те самые, которые в первый раз всплыли только после написания кода. Формализация границ дала LLM структурированный контекст, достаточный для корректного выстраивания переходов между сервисами до того, как написана первая строчка реализации. Но у инструмента нашлись ограничения. Archspec investigate работает ровно настолько хорошо, насколько точны сами контракты. Если `SERVICE_MAP.yaml` отстал от реального кода — модель планирует по устаревшей карте и снова промахнётся. Отдельно проверялась и сама реализация по итоговому плану: там тоже обнаружились точки, где код «отъехал» от задуманного — и это честная часть исследования.

Что это значит

Spec-driven development с LLM в микросервисах работает — но требует явных машиночитаемых контрактов. Без них модель теряет межсервисный контекст структурно: это не вопрос качества промпта или мощности модели. Archspec — практический способ зафиксировать этот контекст, инструмент доступен на GitHub. Главное ограничение: поддерживать `SERVICE_MAP.yaml` актуальными нужно вручную — это отдельный этап, который требует встраивания в процесс разработки. Без актуальных контрактов инструмент создаёт ложную уверенность вместо реальной помощи.