Маленьких команд разработчиков больше не бывает: ИИ-агенты требуют модульности как у Uber

Автор блога проводит мысленный эксперимент: команда разработчиков в 5, 10 человек десятилетиями обходилась без сложной архитектуры, потому что физически не могла генерировать столько кода, чтобы модульность стала проблемой. В загруженный день такая команда могла выдать около 50 коммитов, 20 пушей и 10 PR (pull request, «запросов на слияние»). Автор использует программистскую метафору: один разработчик, редактирующий файлы по очереди, это «однопоточная» работа; несколько параллельно запущенных ИИ-агентов вместо него, это уже «многопоточная» работа, только поток обеспечивают агенты, а не человек. Если та же команда параллельно запускает 20, 100 ИИ-агентов для написания кода, объём работы вырастает на порядок: по прикидке автора, до 500 коммитов, 200 пушей и 100 PR в день. Это иллюстративная оценка автора, а не измеренные данные конкретной команды, но порядок величины важен: маленькая команда с агентами по объёму кода начинает работать как крупная организация.

Для сравнения автор берёт Uber, печально известный тысячами микросервисов: к этой архитектуре компанию привели сотни инженеров, которые хотели деплоить свой код по собственному графику и с чёткой зоной ответственности, а не стоять в одной общей очереди на слияние (merge queue). Раньше такой уровень дробления кода выглядел крайностью, характерной только для гигантских штатов. Тезис автора: с приходом параллельных ИИ-агентов подход Uber к модульности может стать нормой и для маленьких команд, просто потому, что число одновременно работающих «исполнителей» (агентов) сравнялось с тем, что раньше было только у компаний уровня Uber.

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

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

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

Ключевые факты

Раньше маленькая команда (5, 10 человек) на загруженный день выдавала около 50 коммитов, 20 пушей и 10 PR; та же команда, параллельно запуская 20, 100 ИИ-агентов, может выдавать около 500 коммитов, 200 пушей и 100 PR, это прикидка автора, а не измеренные данные.
Uber перешёл на тысячи микросервисов, потому что сотни инженеров хотели деплоить код по своему графику и с чёткой зоной ответственности, а не стоять в одной общей очереди на слияние; автор считает, что этот некогда «крайний» подход может стать нормой.
Чем модульнее код, тем больше агентов можно запускать одновременно: в монолите изменения сталкиваются и требуют разрешения конфликтов слияния, а при архитектуре из тысяч сервисов можно поставить по агенту на каждый сервис и почти наверняка получить улучшения сразу везде.
Автор предупреждает: 100+ агентов в параллели обязаны работать независимо друг от друга, если они тонут в конфликтах слияния, сломанных сборках и проблемах деплоя, суммарная продуктивность команды может уйти в минус.
Дробление кода на сервисы раньше стоило дорого (шаблонный код, инфраструктура, настройка CI), теперь агенты сами всё это пишут, поэтому издержки модульности перестают быть барьером; модуль, помещающийся в контекстное окно агента, к тому же заметно повышает качество его работы.

Почему это важно

Ключевая мысль автора, с приходом параллельных ИИ-агентов у команды разработки из 5, 10 человек фактически исчезает «маленький» масштаб. Раньше архитектурные решения вроде дробления монолита на сотни или тысячи сервисов (как у Uber) требовались только очень крупным организациям с сотнями инженеров. Теперь то же самое давление, десятки параллельных агентов вместо одного человека, возникает и в маленькой команде, а значит модульность кода перестаёт быть архитектурным перфекционизмом и становится практическим ограничением: от неё напрямую зависит, сколько агентов команда способна прогнать одновременно без потерь в продуктивности.

Кому это важно

В первую очередь, техническим лидам, архитекторам и CTO, которые уже решают, как делить кодовую базу на сервисы и модули, особенно в маленьких командах и стартапах, где раньше монолит «и так сходил с рук». Также, командам, которые уже запускают несколько ИИ-агентов параллельно (для рефакторинга, фиксов, мелких улучшений по всей базе) и на практике упираются в конфликты слияния и сломанные сборки. И тем, кто закладывает архитектурные решения на годы вперёд: автор прямо говорит, что модульность стоит закладывать с самого начала, а не по факту столкновения с проблемой.

Как это применить

Из аргументации автора вытекает несколько практических следствий. Проектировать границы сервисов и библиотек так, чтобы каждый модуль целиком помещался в контекстное окно агента, по автору, это резко улучшает качество его работы. Не экономить на дроблении кода из соображений «лишний сервис, лишняя обвязка (CI, деплой, шаблонный код)»: агенты теперь сами пишут эту обвязку, так что прежний аргумент против модульности слабеет. Закреплять за каждым сервисом или модулем чёткого «владельца», человека или конкретного агента, чтобы несколько параллельных агентов не правили один и тот же большой файл одновременно: именно так, по автору, Uber когда-то ушёл от общей очереди на слияние. И держать в уме порог: если агенты (по автору, от 100 и больше) начинают тратить время не на задачи, а на разрешение конфликтов, починку сборок и проблемы деплоя, продуктивность может уйти в минус, это сигнал, что архитектура недостаточно модульна для текущего числа агентов.

Можно ли доверять

Это личный блог-пост, а не новость и не исследование: издание автора не называет, а HN-ник «mooreslaw», под которым материал попал в обсуждение, просто ник того, кто разместил ссылку на Hacker News, а не автор текста. Пост уже собрал 44 балла и 81 комментарий на Hacker News примерно за 4 часа, сообщество активно спорит, но это подтверждает лишь резонанс темы, а не фактическую точность. Ключевые цифры (50/20/10 и 500/200/100 коммитов, пушей и PR), открыто названная автором прикидка «может выдавать», без измерений и без указания конкретной команды, которая реально прогнала 20, 100 или 100+ агентов параллельно. Сведения про Uber (тысячи микросервисов, сотни инженеров) поданы как общеизвестный факт без ссылки на источник. Материал стоит читать как аргументированное мнение практика, а не как отчёт с данными.

Риски и подводные камни

Текст, не эмпирическое исследование, а личное рассуждение: цифры про 50/20/10 и 500/200/100 коммитов, иллюстративная прикидка, а не данные реальной команды, и на них не стоит опираться как на норматив. Автор фокусируется на плюсах модульности (параллельность, подешевевшая инфраструктура для агентов), но почти не разбирает обратную сторону: чем больше независимых сервисов, тем дороже становится согласованность данных между ними, сквозная отладка и тестирование стыков, а именно эти издержки давно считаются главной платой за микросервисную архитектуру. Сам автор предупреждает лишь об одном риске: если 100+ агентов не умеют работать независимо, команда утонет в конфликтах слияния, сломанных сборках и проблемах деплоя, и продуктивность уйдёт в минус. Дробить код на сервисы раньше, чем в команде появятся практики владения кодом, мониторинга и тестирования на стыках, рискованный путь: сложность просто переезжает с уровня кода на уровень координации сервисов.

«Подход Uber к модульности когда-то мог выглядеть крайностью, но он способен стать новой нормой.»

— автор поста