Паттерн агентов-мейнтейнеров: каждому модулю кодовой базы — свой агент-владелец. Чужие агенты не правят и не читают его код — только интерфейс и описание. Разбор идеи bilus.dev и как её внедрить.
Кодинг-агент силён ровно в том, что помещается в его контекст. Чем больше кодовой базы он держит в голове, тем хуже видит каждый отдельный модуль: детали тонут, решения противоречат друг другу, правки одного модуля ломают соседние. Пятое сентября 2026 года Марцин Кулик (блог bilus.dev) описал паттерн, который режет проблему иначе: не расширять контекст одного агента, а закрепить за каждым модулем своего агента-владельца, остальным агентам запретив даже смотреть внутрь чужого модуля. Статья заняла три минуты чтения и разошлась по обсуждениям — потому что в ней есть одна деталь, которой до этого никто не формулировал.
Идея одним абзацем
На каждый модуль, пакет или компонент кодовой базы заводится постоянный агент-мейнтейнер. Он владеет каждым изменением своего модуля. Любой другой агент, которому нужна правка, не редактирует модуль напрямую — он идёт через владельца.
Every module (or package, or namespace, whatever your particular language calls them, or perhaps class or component) in a codebase gets its own maintainer agent. The maintainer owns every change to its module. Another agent wants a change to that module? It goes through the maintainer.
Каждый модуль (или пакет, или namespace — как их называет ваш язык, а может, класс или компонент) получает своего агента-мейнтейнера. Мейнтейнер владеет каждым изменением своего модуля. Другой агент хочет изменить модуль? Он идёт через мейнтейнера.
Звучит как пересказ «один агент на модуль», который уже обсуждали. Автор сам признаёт: идея циркулировала раньше, в нескольких местах. Его вклад — следующий абзац, ради которого статью и цитируют.
Что нового: «не только не модифицировать, но и не заглядывать внутрь»
Привычная схема «раздели работу между агентами» ограничивает агентов в правках, но не в чтении. Все агенты читают весь код, просто каждый отвечает за свою часть. Кулик предлагает жёстче:
Other agents not only cannot modify the modules they don’t own, they cannot look inside them either. All they get is the exposed interface and a description of how the module works, good enough to predict how it will behave. If they need to know anything more, they can ask the maintainer.
Чужие агенты не только не могут изменять модули, которыми не владеют, — они не могут и заглядывать внутрь них. Всё, что они получают, — это открытый интерфейс и описание того, как модуль работает: достаточно, чтобы предсказать его поведение. Если им нужно знать больше — они спрашивают мейнтейнера.
Второй запрет — не читать внутренности — работает на контекст сильнее, чем запрет не писать. Пока агент умеет читать чужой код, его контекст растёт пропорционально размеру кодовой базы, которую он «на всякий случай» открывает. С запретом на чтение каждый чужой модуль превращается в интерфейс и один абзац описания:
This makes the context of each individual agent smaller, because it holds the details of only the module it owns. Every other module is an interface and a paragraph.
Это уменьшает контекст каждого агента: он держит детали только своего модуля. Каждый чужой модуль — это интерфейс и абзац.
Чем это отличается от мультиагентной координации
В статье про мультиагентные workflow разобраны оркестратор, иерархия и параллельные воркеры. Те паттерны отвечают на вопрос «как несколько агентов выполняют работу одновременно». Агенты-мейнтейнеры отвечают на другой: «как сделать так, чтобы агенты не мешали друг другу и человеку». Это слой поверх координации, а не её замена.
| Признак | Параллельные воркеры (классика) | Агенты-мейнтейнеры |
|---|---|---|
| Кто меняет код модуля | любой агент, которому назначили задачу | только агент-владелец модуля |
| Кто читает код модуля | все агенты (контекст = весь репозиторий) | только владелец; остальным — интерфейс и описание |
| Запрос на изменение | агент сам правит и коммитит | агент идёт к мейнтейнеру, тот вносит правку |
| Конфликты правок | возможны, лечатся worktree и файловыми блокировками | исключены по построению: у модуля один писатель |
| Контекст агента | пропорционален кодовой базе | пропорционален одному модулю |
| Человек на ревью | видит большие кросс-модульные диффы | видит локальные диффы + редкие, помеченные изменения интерфейса |
Ключевая разница видна в нижней строке. В кейсе про урезание контекста агента на 80% контекст резали приёмами: инструкции, файлы, лишние инструменты. Паттерн мейнтейнеров режет контекст структурно — границей владения, а не ухищрениями.
Откуда идея взялась и что добавил автор
Кулик честно перечисляет, что «идея циркулировала раньше, несколько раз», и даёт три источника, в которых к сентябрю 2026 уже были похожие конструкции:
- Addy Osmani, «The Code Agent Orchestra» (март 2026) — обзор паттернов координации агентов: сабэдженты, Agent Teams, оркестрация; финальный тезис про то, что качество кода агентов упирается в ревью человеком (пост);
- arXiv:2602.20478, «Codified Context» (февраль 2026) — инфраструктура для ИИ-агентов в кодовой базе на 108 000 строк C#: hot-memory конституция и 19 специализированных доменных агентов (статья);
- Claude Code Agent Teams — экспериментальный режим команд агентов с общим task list и обменом сообщениями между участниками (документация).
CLAUDE_EXPERIMENTAL_AGENT_TEAMS=1) — ближайшая готовая инфраструктура, на которой паттерн мейнтейнеров можно собрать уже сегодня. Реальный скриншот документации.Ни у одного из этих источников нет запрета «не заглядывать внутрь». Addy Osmani разделяет зоны ответственности по файлам, Codified Context — роли экспертов, Agent Teams — задачи. Кулик добавляет информационную изоляцию: чужой агент не просто не пишет в модуль — он не знает, как модуль устроен внутри, и общается с ним через контракт. Именно это делает контекст агентов малым, а не разделение файлов.
Как это устроить на практике
На момент публикации (09.09.2026) публичного кейса, где команда прогнала бы этот паттерн в продакшене, нет — автор поста сам пишет, что идею не пробовал. Ниже — каркас внедрения, который собирается из уже доступных механизмов Claude Code, Codex и AGENTS.md.
Шаг 1. Проведите границы модулей. Паттерн требует зрелой кодовой базы с внятными границами: пакеты, сервисы, компоненты. Если модуль тянет в себя половину проекта и связан с остальным каждой строкой — мейнтейнер не поможет, правки всё равно будут идти через интерфейс, который постоянно меняется. Начните с одного-двух по-настоящему изолированных пакетов.
Шаг 2. Опишите контракт каждого модуля. Что модуль делает, какие функции отдаёт наружу, какое поведение гарантирует, какие лимиты у него есть. Контракт — это и есть «интерфейс и абзац», который видят чужие агенты. Чем точнее контракт, тем меньше вопросов к мейнтейнеру — Кулик замечает, что «спроси мейнтейнера» само по себе диагностика: если документации не хватает, значит, плох интерфейс или описание.
Шаг 3. Заведите по одному агенту-владельцу на модуль. В Claude Code это отдельная сессия или кастомный сабэджент, в Codex — отдельная сессия с закреплённым контекстом. Владелец получает полный доступ только к своему модулю: код, тесты, история правок.
Шаг 4. Запишите правило владения в AGENTS.md. Как именно запретить агентам читать и писать — зависит от инструмента, но декларация должна быть в файле конвенций, который читают все агенты:
# payments
Владелец модуля: агент payments-maintainer.
Только владелец пишет и читает код внутри payments/.
Контракт для остальных агентов:
- create_subscription(user, plan) -> Subscription
- cancel_subscription(id)
- поведение: тарифы, лимиты, события — в docs/payments.md
Нужна правка внутри payments/ → отправь запрос агенту payments-maintainer.
Если ваш инструмент умеет ограничивать доступ к файлам (например, через пермишены сессии или skills), закрепите запрет на уровне инструмента, а не только в промпте: агенты, которые «всего лишь читают AGENTS.md», при автономной работе склонны нарушать декларативные правила.
Шаг 5. Настройте поток изменения. Запрос на изменение приходит мейнтейнеру, он оценивает его против контракта и тестов своего модуля, вносит правку и возвращает дифф заявителю. Изменение интерфейса — редкое событие, оно стоит переговоров и должно приходить к человеку помеченным: «меняется контракт payments».
Где паттерн ломается
Автор поста сам перечисляет, где конструкция разваливается:
Where it breaks down is when the agents become chatty. Or when the interfaces between packages require constant changes. If the packages are coupled rather than cohesive, you will end up with a lot of churn, chat and negotiations between the agents.
Паттерн ломается, когда агенты становятся болтливыми. Или когда интерфейсы между пакетами требуют постоянных изменений. Если пакеты связаны, а не сцеплены в цельное, вы получите много шума, переписки и переговоров между агентами.
Три сценария, в которых оверхед превышает выгоду:
- Связанные пакеты. Если модули дёргают интерфейсы друг друга каждый спринт, каждый запрос превращается в переговоры, а владелец — в узкое место. На связанном легаси паттерн не запустится, пока границы не приведут в порядок.
- Болтливость. Любая межагентная коммуникация стоит токенов. Если «спроси мейнтейнера» происходит по каждому пустяку, расход растёт быстрее, чем экономия на контексте.
- Многоуровневые изменения. Правка, которая пересекает границы трёх модулей, превращается в три последовательных запроса к трём владельцам. Кулик предполагает, что решение то же, что в человеческих командах: агент-архитектор, который координирует изменения интерфейсов.
Есть и структурное следствие: паттерн ведёт к более жёсткой архитектуре. Когда интерфейсы зафиксированы, менять их дорого, и иногда выгоднее накопить техдолг и использовать обходные пути, чем инициировать переговоры об изменении контракта. Автор считает это приемлемой платой: локальные изменения внутри модуля ревьюить проще, чем большие сквозные диффы.
Зачем это человеку: ревью, а не «больше кода»
Финальный тезис поста часто теряется в пересказах:
The whole idea isn’t really about making AI more efficient at filling hard disks with source code. It’s about making it easier for humans to review the code AI produces. A change inside a module is local, and a reviewer can check it against the module’s interface and its tests without holding the rest of the system in their head.
Вся идея не про то, чтобы ИИ эффективнее заполнял жёсткие диски исходным кодом. Она про то, чтобы человеку было проще ревьюить код, который производит ИИ. Изменение внутри модуля локально, и ревьюер может проверить его против интерфейса модуля и его тестов, не держа в голове всю остальную систему.
Это смещает акцент всего агентного кодинга. Узкое место уже не генерация кода, а проверка результата человеком — та же мысль звучит у Addy Osmani и в общем гайде про агентный кодинг. Мейнтейнеры дают ревьюеру две вещи: изменения приходят локальными, их можно сверить с интерфейсом и тестами модуля, не перечитывая систему; а изменения интерфейса редки и помечены, и именно им человек уделяет медленное внимание. Внутри модуля код может быть некрасивым — пока интерфейс держит обещания, а тесты подтверждают.
Российские реалии
Русскоязычных разборов именно паттерна агентов-мейнтейнеров на момент публикации нет — тема свежая даже в англоязычном мире (пост от 05.09.2026, автор признаётся, что не пробовал идею в деле). Ближайшее, что есть в рунете, — общие материалы по мультиагентным системам: «Мультиагентные системы: как команда ИИ берёт сложность штурмом» на Habr и «Оркестрация в мультиагентных системах» от Домклик. Ни тот ни другой не доходят до ownership-изоляции модулей — так что эта статья на русском, по сути, первая по теме.
Доступность инструментов, на которых паттерн собирается, — обычная история для РФ: Claude Code работает через Anthropic API и оплачивается зарубежными картами (подробнее — в статье про установку Claude Code), Codex требует подписки OpenAI или API-ключ с теми же ограничениями по оплате и региону. Никаких российских ограничений именно на паттерн нет: это архитектурный приём, он не зависит от конкретного провайдера.
Честные ограничения
- Паттерн никто не проверял в бою. Автор идеи не реализовал её: в посте он дважды повторяет «в теории» и «я ещё не пробовал». К сентябрю 2026 нет публичных кейсов команды, которая гоняла бы агентов-мейнтейнеров на реальной кодовой базе. Всё ниже — разбор предложения, а не проверенной методики.
- Оценка экономии контекста умозрительна. «Каждый чужой модуль — интерфейс и абзац» красиво звучит, но сколько токенов реально экономится и не всплывут ли новые расходы на переговоры — неизвестно. Автор сам хочет это измерить.
- Жёсткость архитектуры — осознанная плата. Границы модулей и интерфейсы становятся дорогими в изменении. На быстро меняющейся кодовой базе это может замедлить разработку сильнее, чем экономия на ревью.
- Запрет «не читать» технически нежёсткий. Агент, которому вы сказали не открывать чужой модуль, всё равно может прочитать файл, если инструмент не ограничивает доступ. Полноценная изоляция требует поддержки на уровне прав файловой системы, а не только деклараций в AGENTS.md.
- Оверхед на маленьких проектах. Один агент на модуль имеет смысл, когда модулей несколько и они крупные. На проекте из пары тысяч строк мейнтейнеры добавят переговоров без выгоды.
Вывод
Агенты-мейнтейнеры — паттерн, который отвечает не на вопрос «как заставить агентов писать больше кода», а на вопрос «как человеку проверять код, который пишут агенты». Каждому модулю — постоянный агент-владелец; чужие агенты не правят чужой код и не читают его, общаясь с модулем только через контракт. Так контекст каждого агента остаётся малым, конфликты правок исчезают по построению, а изменения приходят человеку локальными и проверяемыми.
Честная оговорка: на 09.09.2026 это хорошо сформулированная гипотеза, а не проверенная практика. Проверить её можно на своей кодовой базе: выбрать один изолированный пакет, назначить ему агента-владельца, записать контракт в AGENTS.md и посмотреть, сколько токенов и конфликтов это сэкономит на реальных задачах. Смежные кирпичи — контекст агента, AGENTS.md как файл-конвенций и мультиагентная координация — уже разобраны на сайте.
