Внешнее техническое лидерство для одного репозитория и множества ассистентов

Почему один репозиторий быстро становится хаотичным

Сначала один репозиторий кажется простым. Потом команда добавляет двух или трёх AI-ассистентов, каждый разработчик держит свои промпты, и код начинает расползаться по маленьким островкам. Один ассистент создаёт services/, другой предпочитает lib/, а третий кладёт ту же логику в utils/. Никто не планирует беспорядок, но репозиторий всё равно его получает.

Проблема здесь не только в стиле. Проблема в координации. Промпты расходятся, ожидания меняются, и код перестаёт ощущаться как работа одной команды. Один разработчик просит строгий TypeScript и маленькие функции. Другой делает ставку на скорость и получает большие файлы со смешанными зонами ответственности. Через неделю оба варианта работают, но они не сочетаются друг с другом. Команда тратит время на переименование папок, перенос файлов и исправление шаблонов, которые должны были совпасть с самого начала.

Тесты делают проблему ещё заметнее. В общем репозитории небольшое изменение в одном файле может сломать что-то далеко от него. Меняется вспомогательная функция, становится менее строгим общий тип, или ассистент переписывает запрос, который выглядел безобидно. Человек, который внёс правку, может так и не увидеть слабое место, потому что ошибка проявляется в другой части продукта.

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

Небольшая продуктовая команда чувствует это особенно быстро. Представьте четыре разработчика в одном репозитории и трёх ассистентов. К пятнице логика входа всё ещё работает, но тесты нестабильны, в API-слое уже три разных подхода, и никто не уверен, нужна ли была миграции ещё одна пара глаз.

Именно здесь помогает внешнее техническое лидерство. Опытный фракционный CTO или advisor обычно замечает закономерность раньше других. У репозитория сначала не проблема с кодом. У него проблема с координацией. Пока кто-то не задаст общие правила для структуры, промптов и каналов ревью, команда продолжает чинить избежимые ошибки вместо того, чтобы делать продуктовую работу.

Что должно входить в контекст-пак

Хороший контекст-пак отвечает на вопросы, которые каждый разработчик и AI-ассистент задаёт в первые десять минут. Если ответы собраны в одном коротком документе, люди перестают угадывать. Они перестают складывать код в случайные места, а ревью перестаёт возвращать изменения на базовую уборку.

Часто внешнему CTO или advisor проще написать такой документ. Человек, который не живёт в ежедневных привычках команды, может объяснить правила простыми словами и быстрее заметить пропущенные детали, особенно когда один и тот же репозиторий трогают несколько людей и несколько ассистентов.

Полезный пакет обычно включает пять вещей. Начните с короткого описания продукта: что он делает, кому помогает и что команда пытается улучшить прямо сейчас. Затем добавьте карту папок, чтобы было видно, куда должен попадать новый код. Если UI-код лежит в одном месте, фоновые задачи — в другом, а общие типы — в третьем, скажите об этом прямо.

Потом задайте правила именования файлов, функций, компонентов и веток. На первый взгляд это мелочи, но они экономят много времени на ревью, потому что люди перестают придумывать свои схемы. После этого добавьте список проверок перед ревью. Объясните, что нужно запускать перед тем, как просить ревью: unit-тесты, linting, type checks или одну ручную проверку в продукте.

Последняя часть — это правила команд. Перечислите, что людям можно запускать, а что нельзя. Разрешите безопасные команды только для просмотра и обычных тестов. Заблокируйте рискованные действия вроде удаления базы данных, force push в защищённые ветки и широких скриптов поиска и замены.

Держите пакет коротким. Если его чтение занимает 20 минут, люди будут его пропускать. Обычно две или три страницы работают лучше, чем руководство, которое никто не открывает. Пишите правила как инструкции, а не как официальный документ.

Правила команд помогают держать результат стабильным

Хороший лидер превращает привычки команды в короткий лист команд. Это особенно важно, когда один репозиторий трогают несколько ассистентов. Если каждый ассистент сам придумывает, как запускать тесты, форматировать код, собирать проект или поднимать сервисы, код быстро расползается, а люди перестают доверять результату.

Решение простое: для каждой регулярной задачи дайте одну утверждённую команду. Один способ запускать тесты. Один способ форматировать код. Один способ поднять приложение и локальные сервисы. Чёткие правила оставляют меньше места для догадок.

Небольшой лист правил часто лучше длинного документа с политиками. Для повседневной работы хватает пяти или шести команд. Разместите их там, куда люди уже смотрят: в основном README и в корне репозитория, и напишите так, чтобы их можно было просто скопировать и вставить без правок.

# local setup
docker compose up -d

# start app
make dev

# format code
make fmt

# run checks
make test
make lint

Безопасные локальные команды должны покрывать только обычную работу. Людям нужны команды, чтобы ставить зависимости, запускать сервисы, прогонять тесты, смотреть логи и подготавливать локальные данные. Им не нужны команды, которые могут повредить общую работу или стереть данные. Запрещённые действия лучше прописать простыми словами.

Обычно достаточно короткого списка:

• Не используйте git push --force в общих ветках
• Не запускайте git reset --hard, если вы не в своей ветке и не понимаете зачем
• Не запускайте команды удаления против общих баз данных
• Не останавливайте и не удаляйте общие контейнеры в удалённых средах
• Не меняйте историю миграций вручную

Последний пункт важнее, чем ожидают команды. Многие ошибки ассистентов появляются из-за правильных команд, применённых не там. Хорошие правила ясно показывают границу: что безопасно на ноутбуке и что никогда не безопасно вне его.

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

Каналы ревью помогают ловить проблемы раньше

Большинство команд застревают, когда каждое изменение идёт в одну и ту же очередь. Правка документации, чистка CSS и изменение логики биллинга несут разный риск. Если относиться к ним одинаково, люди либо слишком долго ждут, либо торопятся не там, где надо.

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

Практичное разделение

Низкорисковые изменения могут проходить с лёгкой проверкой. Если ассистент исправляет опечатки в документации по настройке или приводит в порядок отступы в компоненте, не меняя поведение, команда может быстро одобрить такую работу. Очередь остаётся короткой, а люди продолжают двигаться.

Production-коду нужен более строгий канал. Любое изменение, которое затрагивает auth, billing, сохранённые данные или правила структуры данных, должно останавливаться на человеческое ревью. То же касается логики прав доступа, migrations и всего, что может сломать доступ пользователя или денежный поток. Ассистенты здесь полезны, но они не должны быть последним ревьюером.

Короткий чек-лист помогает сохранить разделение:

• Меняет ли это поведение или только текст и стиль?
• Затрагивает ли это auth, billing или сохранённые данные?
• Можно ли откатить это за несколько минут?
• Тесты прошли, и дифф достаточно маленький, чтобы быстро его проверить?

Это решает сразу две задачи. Во-первых, оно раньше ловит рискованные изменения. Во-вторых, оно прекращает бесконечные споры о том, в какую очередь должен попасть pull request.

За исключения должен отвечать один человек. Выберите founder, engineering lead или fractional CTO и дайте этому человеку право решать, когда изменение попадает в серую зону. Если за исключения никто не отвечает, каждый необычный pull request превращается в общий спор.

Логика простая. Неправильная запятая в документации раздражает. Неправильное условие в коде биллинга может создать возвраты, обращения в поддержку и часы уборки. Каналы ревью должны отражать эту разницу до того, как вред распространится.

Как внедрить это за одну неделю

Одной недели достаточно, если не раздувать масштаб. Начинайте с уборки, а не с горы новых правил.

В первый день составьте карту того, что уже работает с репозиторием. Запишите всех ассистентов, плагинов, скрипты, шаблоны промптов и локальные помощники, которые использует команда. Укажите, кто чем пользуется, что он меняет и где лежат его инструкции. Большинство команд быстро находят дублирование, а именно там и появляются смешанные привычки.

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

Третий день — это место, где ломается много внедрений. Добавьте правила команд, а затем уберите старые заметки, разбросанные по чатам, документам и сохранённым промптам. Один источник правды лучше пяти почти правильных версий. Лучше всего работают простые правила: меняйте только перечисленные файлы, спрашивайте перед троганием schema или auth, запускайте согласованные проверки и объясняйте любую догадку вместо того, чтобы её скрывать.

На четвёртый день задайте каналы ревью по риску. Не делите их по seniority или статусу. Текстовая правка или небольшое изменение стиля может идти по лёгкому каналу. Бизнес-логика, billing, права доступа, инфраструктура и изменения данных должны идти по более строгому каналу с человеческим ревью. Люди следуют правилам ревью, когда усилия соответствуют риску.

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

Такой запуск хорошо работает с fractional CTO, потому что ему не нужно защищать старые привычки. Oleg Sotnikov занимается именно такой практической настройкой AI coding workflows и дизайна процесса ревью, а затем оставляет команде правила, которыми можно пользоваться и после первой недели.

Простой пример из небольшой продуктовой команды

У продуктовой команды из четырёх человек один общий репозиторий, а три разработчика используют разных ассистентов. Один опирается на Claude для бэкенда, другой использует GPT, чтобы привести в порядок тесты, а третий работает в editor agent, который с удовольствием переименовывает файлы, если считает, что код будет читаться лучше.

В понедельник все они трогают одну и ту же фичу. Первый разработчик добавляет новый endpoint для выгрузки данных клиентов. Второй просит GPT переписать тесты вокруг этой области, потому что старые тесты выглядят неряшливо. Третий замечает несогласованные названия и позволяет editor agent переименовать файлы и обновить импорты.

Ко вторнику ветка становится больше самой фичи. Endpoint работает, но он оказался не в той папке. Тесты проходят, но стиль у них отличается от остального репозитория. Переименования технически корректны, но из-за них дифф сложнее проверять и возрастает риск merge conflicts.

Короткий контекст-пак предотвращает большую часть этого ещё до того, как ветка разрастётся. В нём каждому ассистенту говорят, где должны лежать API endpoints, как называются handlers, когда тесты можно переписывать и когда переименование файлов под запретом, если только это не требуется задачей. Туда же можно добавить простые правила вроде «сохраняйте существующий стиль тестов» и «не перемещайте файлы во время работы над фичей».

Именно здесь внешнее техническое лидерство окупается. Человек со стороны может написать правила, которыми команда действительно будет пользоваться, потому что они подходят конкретному репозиторию, а не какому-то общему шаблону.

Команда также задаёт каналы ревью. Любое изменение, которое затрагивает поля базы данных, migrations или форму payload, сначала идёт к senior reviewer. Правки только для тестов проходят по обычному каналу. В этом примере endpoint для выгрузки включает изменение данных, поэтому эта часть проверяется раньше, чем ветка успевает разрастись вокруг неё.

Итог лучший в самом хорошем смысле этого слова: скучный. Команда выпускает один аккуратный набор изменений вместо фичи и двух раундов исправлений. Обычно это экономит больше времени, чем добавление ещё одного ассистента.

Почему команды игнорируют правила

Большинство команд отвергают правила не потому, что им не нравятся стандарты. Они отвергают правила, когда те отнимают время, мешают повседневной работе или меняются так часто, что им больше не доверяют.

Первая ошибка — писать настолько длинное руководство, что им невозможно пользоваться под давлением. Если в репозитории лежит 40-страничный handbook, разработчики пробегут глазами первый раздел, скопируют старый промпт и пойдут дальше. Короткий контекст-пак работает лучше: цели проекта, карта репозитория, ограничения по коду, частые команды и несколько реальных примеров.

Ещё одна распространённая ошибка — менять правила каждую неделю. Людям нужна хотя бы небольшая стабильность, прежде чем сформируется привычка. Если названия команд, шаги ревью или шаблоны промптов постоянно меняются, разработчики сохраняют свои версии, а ассистенты расходятся в разные стороны. Лучше зафиксировать основные правила на время, а потом менять их только тогда, когда ревью снова и снова находит одну и ту же ошибку или появляется реальный риск.

Команды также теряют терпение, когда смешивают правила стиля с продуктовыми решениями. «Используйте такую структуру папок» — это правило для репозитория. «Не делайте эту фичу сейчас, потому что pricing может измениться» — это уже продуктовое решение. Когда оба типа правил живут в одном документе, никто не понимает, что является постоянным, а что временным.

Общим репозиторием также труднее управлять, когда каждый инструмент придумывает свой список команд. Если один ассистент использует /plan, другой — /spec, а третий пишет свой формат, разработчики перестают вообще что-либо запоминать. Выберите один общий набор команд и заставьте все ассистенты следовать ему. Внешний лидер здесь часто особенно полезен, потому что может убрать дублирующиеся правила, не защищая старые привычки.

Новые сотрудники и подрядчики нуждаются в онбординге, даже если правила кажутся очевидными тем, кто их писал. 30-минутный walkthrough экономит дни уборки позже. Покажите им контекст-пак, вместе выполните один поток команд и объясните, как работают каналы ревью на практике.

Обычно признаки усталости от правил заметны рано. Люди задают одни и те же вопросы по настройке, pull requests выглядят по-разному, а ревьюеры повторяют одни и те же замечания. Это редко проблема дисциплины. Обычно проблема в том, что систему сложнее соблюдать, чем саму работу.

Небольшие стартапы выигрывают от меньшего числа правил, которые не меняются, одного языка команд для всех ассистентов и короткого процесса онбординга, который получает каждый новый человек в первый день.

Что проверить перед тем, как добавить ещё одного ассистента

Новый ассистент может сэкономить время, а может добавить в репозиторий второй набор привычек. Проблемы начинаются тогда, когда один инструмент пишет код по общим правилам команды, а другой работает на основе собственного скрытого промпта. Разделение быстро видно в названиях, тестах, структуре папок и шуме на ревью.

Начните с общего контекста. Если ассистент не может прочитать тот же контекст-пак, что и команда, он будет угадывать. Эти догадки порождают пачку мелких проблем: handler не на том слое, стиль тестов, который никто не просил, migrations, игнорирующая локальные правила.

Потом проверьте, как инструмент следует командам. Некоторые ассистенты ведут себя нормально только после набора частных хаков в промпте, browser extensions или локальных wrappers. Обычно это ломается сразу, как только кто-то из разработчиков обновляет свою настройку. Если утверждённые команды работают для команды, они должны работать и для ассистента. Если нет, инструмент — особый случай, а особые случаи редко остаются аккуратными.

Каждому изменению тоже нужен понятный след. Вы должны знать, кто начал задачу, что именно затронул ассистент и кто проверил результат перед merge. Если этот след живёт в трёх окнах чата и одном локальном терминале, у вас нет accountability. У вас есть folklore. Через две недели, когда в репозиторий попадёт что-то странное, никто не сможет это объяснить.

Первый запуск держите узким. Новый ассистент не должен в первый же день редактировать production-пути, трогать live data или переписывать customer-facing content. Дайте сначала низкорисковую работу: исправления тестов, рефакторинг одного модуля или документацию, которая остаётся внутри репозитория. Доверие растёт из скучного, повторяемого результата, а не из широкого доступа.

Есть ещё одна проверка, которую постоянно пропускают: кто может быстро отключить инструмент? Назначьте одного владельца. Дайте этому человеку право заблокировать ассистента, отозвать токены или убрать его из workflow в тот же день. Маленьким командам это нужно даже больше, чем большим. Если во вторник утром инструмент начинает создавать плохие pull requests, ждать до следующего спринта слишком долго.

Хорошо работает простое правило: новый ассистент не входит в репозиторий, если он не разделяет контекст, не подчиняется тем же командам, не оставляет чистый журнал действий, не стартует с ограниченным доступом и не имеет назначенного владельца отключения. Звучит жёстко, но это всё ещё дешевле, чем разгребать шесть недель уверенной ерунды.

Что делать дальше

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

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

Например, если ассистент постоянно лезет в billing-код во время простой UI-задачи, сформулируйте правило прямо: оставайтесь внутри указанных папок, если только в запросе не названы изменения зависимости. Одно такое предложение может сэкономить часы на уборке.

Лёгкий стартовый набор уже достаточен:

• контекст-пак с целями продукта, стеком, картой папок и запретными зонами
• файл с правилами команд: именование, тестирование и ограничения по scope
• один быстрый канал ревью для стиля и правил репозитория
• один более глубокий канал ревью для архитектуры, безопасности и изменений базы данных

Запустите эту схему на две недели и смотрите на поведение, а не на мнения. Какие правила действительно убирают ошибки? Какие люди пропускают или забывают? Вычеркивайте то, чем никто не пользуется. Оставляйте то, что уменьшает переделки, сокращает ревью или предотвращает рискованные правки.

Если вам нужна помощь в настройке, Oleg Sotnikov занимается таким AI-first engineering на oleg.is и работает со стартапами и небольшими командами как fractional CTO. Цель простая: репозиторий, где ассистенты не выходят за рамки, ревью проходят быстрее, а меньше ошибок доходит до production.