Как меняются нормы работы команды

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

Узкие места сместились

Главная мысль умещается в одну фразу: то, что помогало вам раньше, может больше не помогать. Долгие годы самым дорогим ресурсом была работа инженеров — само написание кода, тестов, рефакторинг. Вокруг этой дороговизны и выстроены привычные процессы выпуска программ. Показателен пример из начала двухтысячных: Visual Studio 2005 отгружали на CD-ROM, а ещё раньше — на дискетах, и жёсткие сроки диктовала печать дисков. Программу нужно было успеть записать на диски, упаковать в коробки и развезти по магазинам. Переход к распространению через интернет изменил сам порядок выпуска. Сейчас происходит похожий сдвиг: писать код стало быстро, а объём кода резко вырос. Узкие места переместились в другие области — проверка, ревью, работа со смежными командами, безопасность. И главные вопросы теперь другие: верен ли код, кто его ревьюит и как его потом поддерживать.

Процессы, которые тихо перестают работать

Важно заметить: процессы редко отменяют сами себя — их обычно только накапливают, слой за слоем. Поэтому важно вовремя замечать те, что «тихо перестают работать». В их числе — предварительное планирование, владение кодом, ревью, состав команды, обмен знаниями и адаптация новичков. Все они когда-то появились не просто так, но были рассчитаны на мир, где код писать дорого.

Какие нормы пришлось переписать

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

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

Технические споры. Побеждает код. Вместо спора у доски проще сгенерировать несколько вариантов — три PR — и обсуждать не только реализацию, но и то, как изменение скажется на всех, кто вызывает этот код. Формула простая: когда строить дёшево, спорить дорого. При этом важна командная культура: недопустимо, чтобы прав оказывался тот, кто закоммитил последним.

Проверка. Сюда, наоборот, вкладываются сильнее. Это называют «сдвигом влево»: больше автоматизации, чтобы ловить ошибки раньше и ближе к источнику. Каждому, независимо от роли, нужна бо́льшая уверенность в том, что его изменение ничего не сломало.

Владение кодом. Оно размылось. Вопрос «кто это менял?» стал странным, ведь почти все PR идут с помощью Claude. Полезнее докопаться до настоящего вопроса — кто вызвал регрессию, кто эксперт для ответа клиенту, нужен ли контекст — и по возможности этот ответ автоматизировать.

Наём и состав команды. Ставка — на два профиля: креативные создатели с продуктовым чутьём и специалисты с глубокой системной экспертизой, например по распределённым системам. Пробелы между ролями закрывает Claude — продакт-менеджеры пишут код, а инженеры берутся за тексты. Организацию держат плоской, а менеджеры сначала работают как рядовые инженеры, чтобы пользоваться своим же продуктом и заслужить доверие команды.

Обмен знаниями. Источником истины становится сам код: на вопросы клиентов отвечают прямо из локальных репозиториев. Спецификации кладут в те же репозитории, чтобы Claude сверял с ними код.

Как это внедряли

Внедрение — это баланс между обязательными общими нормами и свободой отдельных подкоманд. Базовые принципы держат в актуальном состоянии и раз в несколько месяцев проверяют, служат ли они ещё цели. Все в команде, включая смежные роли, пользуются Claude Code. Отдельный принцип — явное разрешение убивать процессы. Пример: ежедневные стендапы сначала заменили общей таблицей, а потом — навыком-скриптом, который собирает статус за всех.

По каким признакам понятно, что работает

Об этом говорят три показателя. Время выхода новичка на продуктивность резко сокращается. Время цикла PR тоже сокращается — и заодно вскрывает узкие места, например когда сборка и CI не поспевают за объёмом коммитов. А доля коммитов, сделанных с помощью Claude, растёт: со временем ассистированный коммит становится нормой по умолчанию. При этом важна оговорка: важен конечный результат — качество и надёжность продукта, — а не сам по себе процент кода, написанного ИИ.

Открытые вопросы и задание на дом

Часть вопросов остаётся без ответа. Нужна ли раздельная организация под iOS и Android, когда инженеры свободно переключаются между платформами. Насколько доверять полностью автоматическому ревью — баланс «доверяй, но проверяй» смещается с каждой новой моделью. Как при размывании ролей сделать так, чтобы все чувствовали себя одинаково продуктивными. Задание на дом простое: возьмите самый шумный, дорогой или нелюбимый процесс в своей работе и спросите, служит ли он ещё своей цели. В одной команде так отменили еженедельное совещание на пятьдесят человек — после единственного вопроса «зачем оно нам?».

Связь с курсом

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