Разбор · Опубликовали 07.10.2026
Микросервисы при агентах должны оправдать свою цену: начните с общего репозитория и проверки
Как проверить предложение разделить систему, если код пишут ИИ-агенты. На опыте vibecoding.ru; клиентского сравнения архитектур у нас нет.
Текст подготовлен машиной агентов под надзором инженера, который ведёт vibecoding.ru · факты проверены 7 октября 2026
Наш выбор для нового продукта с ИИ-агентами: модули в общем репозитории и общая проверка, а отдельный сервис требует отдельного обоснования.
Эти критерии проверяем на vibecoding.ru, где инженер ведёт машину агентов; клиентского кейса выбора архитектуры у нас нет.
Не хотите разбираться сами? Внедряем ИИ в ваш бизнес: задачи без лимита, одна цена в месяц, отмена в любой момент.
1. Репозиторий и единица выпуска решают разные задачи.
В монолитной архитектуре приложение выпускают целиком. В микросервисной сервисы выпускают независимо. Число папок этого различия не определяет.
В одном репозитории могут лежать несколько сервисов. А несколько репозиториев, которые приходится выпускать вместе, независимости не дают.
Мартин Фаулер в разборе 2015 года связывает пользу микросервисов с границами модулей и независимым выпуском. Границы можно сохранить и в модульном монолите.
Разделяйте три решения в предложении подрядчика.
Мартин Фаулер, Microservice Trade-Offs, 1 июля 2015; Microsoft Architecture Center, проверено 07.10.2026. Таблица является редакционным разбором.
2. Агенту нужен путь от требования до проверки результата.
Меньше кода в сервисе ещё не значит меньше работы. Для возврата заказа нужно согласовать статус, сумму и сообщение клиенту. Одних статусов агенту недостаточно.
В общем репозитории агент может найти связанные места. Файл правил задаёт границы поиска. Весь проект в промпт загружать не нужно.
Anthropic в сентябре 2025 описывает контекст как ограниченный ресурс. Наш вывод: нужные зависимости должны быть доступны агенту по мере работы.
Общая проверка проверяет возврат, а не только код.
Учебный сценарий редакции, не клиентский кейс. Механизм проверки опирается на Best practices Claude Code, проверено 07.10.2026. «Одна проверка» обозначает общий критерий готовности и вход в набор проверок, а не один тест на всю систему.
3. Параллельным агентам нужны рабочие копии и порядок слияния.
Агенты могут работать в одном репозитории, каждый в своей ветке и рабочей копии. Документация Claude Code рекомендует так изолировать правки сессий.
Рабочая копия не защищает совместимость после слияния. Связанные правки проверяют вместе. Роль руководителя в этом разобрана отдельно.
Общая среда тоже имеет цену. В отдельном сервисе глобальная замена уже по охвату, зато ошибки договора между сервисами требуют своей проверки.
Общие файлы и ресурсы требуют своих правил.
02.08
Агент сделал глобальное переименование и задел чужие зоны. Другая сессия стала исправлять повреждённый импорт. Правило: менять только подтверждённый список файлов, читать состав правки перед коммитом.
10.08
Старый коммит закончил сборку последним, и части сайта оказались от разных версий. 13 августа параллельные сборки выключили. Правило: общий выпуск имеет согласованный порядок.
19.09
После заполнения диска 15–19 сентября разные процессы видели свои симптомы. Ввели проверку свободного места. Автоматическое удаление чужих рабочих копий отвергли.
Истории машины vibecoding.ru, записи 02.08, 10.08, 13.08 и 19.09.2026, перепроверены 07.10.2026. Файлы закрытых репозиториев не публикуются.
4. Наш репозиторий показывает объём работы, а не окупаемость архитектуры.
На открытой карте машины фронтенд, бэкенд и админка являются регионами одного репозитория. На 7 октября там 7 063 коммита за 98 дней.
Счёт идёт по основной ветке с 1 июля 2026, без мерж-коммитов. Это объём работы, а не экономия от архитектуры. Методика счётчиков разобрана отдельно.
Карта не доказывает, что сайт запускается как монолит. Она показывает устройство репозитория. Проверить этот способ работы можно на задачах своей команды.
Наш публичный опыт подтверждает работу в общем коде.
/open, 07.10.2026 20:19 МСК; истории машины из предыдущей ленты. Число является снимком живого счётчика.
5. Отдельный сервис окупают независимая нагрузка и выпуск.
Микросервисы нужны для измеренной проблемы. Отчётам может требоваться отдельная вычислительная мощность, их команде свой выпуск. Число агентов такого довода не даёт.
Цена разделения остаётся и при агентах. Нужно проверять договор данных, неполный ответ и повтор запроса. Microsoft отмечает сложность тестирования зависимостей.
Если сервисы выпускают вместе, пользы независимого выпуска нет. Маленькие сервисы тогда оставляют общий сценарий связанным и добавляют сетевые ошибки.
У выделения сервиса должно быть проверяемое основание.
Редакционные критерии на основе Фаулера и Microsoft, проверено 07.10.2026. Это способ обсуждения, не универсальный порог окупаемости.
6. До разделения закажите проверку связанной задачи.
Попросите подрядчика провести реальную правку до проверенного результата. Сохраните время ожидания и доработки. Постановка задачи агенту разобрана отдельно.
Затем попросите показать путь для предлагаемой архитектуры. В оценке нужны миграция и поддержка совместимости. Быстро написанный сервис покрывает часть работы.
Если причина в страхе перед старым кодом, разберите технический долг. Разделение не заменяет знания текущего поведения системы.
До оплаты разделения получите проверяемый план.
План редакции, не обещание срока. Основа проверки агента: Claude Code Best practices, прочитано 07.10.2026.
Начать оценку команды можно с теста для руководителя. Он помогает выбрать следующий шаг; архитектуру тест не выбирает.
Подписка «Все проекты» на 7 октября 2026 даёт три потока в репозиториях клиента. В каждом одна задача в работе. Архитектурные решения остаются за клиентом.
Разные продукты объединять не требуется. В курсе агентной разработки урок «Больше кодбаз» отделяет продукты, а не части одного сквозного сценария.
Что и как мы проверяли
| Факт | Что известно | Проверено |
|---|---|---|
| Наш объём работы | Снимок /open 07.10.2026 в 20:19 МСК: 7 063 коммита за 98 дней по основной ветке с 1 июля 2026. Мерж-коммиты не считаются. Счётчик объёма не измеряет качество или выгоду архитектуры. У карты отдельное окно, со 2 июля | 2026-10-07 |
| Поломки машины | Инвентарь серии сверили с первичными записями 02.08, 10.08, 13.08 и 19.09.2026. В статье безопасный пересказ без файлов закрытых репозиториев, учётных записей и названий облаков | 2026-10-07 |
| Архитектурные доводы | Microservice Trade-Offs Мартина Фаулера от 1 июля 2015 и документация Microsoft Architecture Center. Это объяснение механизмов, не сравнение окупаемости при ИИ-агентах | 2026-10-07 |
| Работа агента | Статья инженеров Anthropic от 29 сентября 2025 о конечном контексте и Best practices Claude Code о проверках и рабочих копиях. Рекомендация держать связанный код доступным является нашим выводом | 2026-10-07 |
| Подписка | Страница /services, снимок 07.10.2026 в 20:19 МСК. «Все проекты» даёт три потока; каждый содержит одну задачу в работе. Код в репозиториях клиента, архитектурные решения за клиентом | 2026-10-07 |
| Граница вывода | Клиентского кейса выбора архитектуры у нашей машины нет. Частота окупаемости микросервисов не измерена. Заголовок выражает наш инженерный выбор для продукта с агентами; процента экономии и порога размера системы мы не выводим | 2026-10-07 |
7. Частые вопросы
Модульный монолит отличается от обычного монолита?+
У него внутри описаны границы модулей: кто владеет данными и через что другие части обращаются к нему. Выпуск остаётся общим. Просто разложить старые файлы по папкам недостаточно.
Несколько микросервисов могут жить в одном репозитории?+
Да. Хранение кода и независимый выпуск являются разными решениями. Если агент имеет доступ к связанному коду, он может проверить изменение договора сразу с обеих сторон.
Одна проверка означает один тест и долгую общую сборку?+
Нет. Это единый критерий готовности и понятный вход в набор проверок. Проверки модулей могут идти параллельно. Связанные сценарии и совместимость всё равно проверяются отдельно.
Существующие микросервисы нужно собрать обратно?+
Само появление агентов не основание для такой миграции. Сначала дайте им карту сервисов, версии договоров и воспроизводимую проверку. Проблемы старого кода разобраны в статье о техническом долге.
Общий репозиторий требует дать агенту доступ ко всему?+
Нет. Права выбираются по задаче. Закрытая зона может требовать отдельного репозитория или исполнителя. Закрытый контур и данные клиентов разобраны отдельно.
Подписка /services выберет архитектуру за нас?+
Нет. Решение остаётся за клиентом, это указано на странице услуги. Машина исполняет согласованные задачи в репозиториях клиента.
Источники
- Мартин Фаулер, Microservice Trade-Offs (1 июля 2015) — авторский разбор
- Anthropic, Effective context engineering for AI agents (29 сентября 2025) — инженеры вендора
- Claude Code, Best practices (проверено 7 октября 2026) — официальная документация
- Microsoft Architecture Center, Microservices architecture style (проверено 7 октября 2026) — официальная документация
- Открытая карта машины vibecoding.ru (снимок 7 октября 2026) — наш замер
- Условия агентной разработки (проверено 7 октября 2026) — условия услуги
Запомнить
1. Отделите устройство приложения от хранения кода: потребуйте объяснить, какую независимость покупает новый сервис.
2. Дайте агенту доступ к нужным зависимостям и общую проверку результата. Маленький сервис без проверки не решает эту задачу.
3. Разведите параллельную работу по веткам и рабочим копиям. Проверьте совместимость перед общим выпуском.
4. До оплаты миграции сравните путь реальной задачи и затраты разделения. Выберите границу по пользе для бизнеса.