Merge со скоростью света — командная работа и разрешение конфликтов
У каждого менеджера свой сервер, свой домен, свои задачи. Раз в сутки — merge в master и подтягивание изменений в ветки менеджеров.
Однако: скорость работы менеджеров такова, что за сутки накапливаются несовместимые изменения. Не только конфликты в git (их много, но ИИ хорошо их разрешает), но и конфликты по сути, которые невозможно объединить (один человек правил длинную форму, а другой вообще её удалил).
Пока мы думали о ежедневных аналогах sprint meetings (обсудить и распределить задачи), контринтуитивное решение пришло само — как обычно, случайно. Но одновременно от двух разных команд.
Люди (их агенты) работали одновременно на одном сервере — просто потому, что в моменте так оказалось удобно, чтобы не ждать готовности серверов, копирования БД, обновления ключей и AGENTS.md.
И выяснилось, что в этих командах конфликтов не было — они либо не успевали возникать, либо авторы сразу видели проблемы и решали их в личке.
Казалось бы, глупо. Но с другой стороны, это по канонам Дженсена Хуанга и Thinking at the Speed of Light. Думаем не про итерации, а про физический предел. Делать синхронизацию раз в сутки лучше, чем раз в неделю. А какой физический предел? Раз в минуту, раз в секунду, в момент редактирования файла. Вот оно!
Бонус: конфликт вылезает сразу, сами менеджеры его решают. Развиваем коллаборацию! А лишняя ответственность не переносится на технарей, который должны в конце дня осознать чужие интенции и принять решение «Кто победил?» в конфликтах.
Эта схема хорошо работает из коробки. Агенты сами замечают изменения без особых инструкций.
Но мы попробовали ещё два улучшения:
- Физический уровень — git. Не трогать незакоммиченные файлы. Если нужный агенту файл уже был изменен, нужно остановиться и сказать об этом менеджеру. (Естественно, подразумевается работа с частыми коммитами и законченными изменениями.)
- Логический уровень — агент пишет intent перед началом работы. Все остальные агенты читают все intents и понимаю, если намерения разработчиков пересекаются. В таком случае — остановиться и сказать менеджеру.
В обоих случаях отправляет уведомление в телеграм-чат со всеми разработчиками, имеющими доступ к серверу.
В итоге merge как отдельное событие исчез. Нет дня стабилизации, нет «кто разрулит конфликты», нет веток-долгожителей. Есть один сервер, где код всегда в согласованном состоянии, и прод, куда все изменения выкладываются раз в сутки.
Это не исключает работу на отдельных серверах, локальную разработку, длительную разработку — это default mode — всех разработчиков направить на один сервер и всячески способствовать коммуникации между ними.