С начала 2014-го до конца 2020 года я работал в компаниях на стадии гиперроста. Это тяжёлая, но очень полезная среда. Главное преимущество гиперроста в том, что последствия своих ошибок вы видите уже через месяц, а не через год: когда всё движется быстро, проблемы проявляются сразу и очень заметно.

В последнее время я снова много думаю о гиперросте.

• Во‑первых, наш бизнес быстро растёт, и в прошлом году мы активно расширяли команду.

• Во‑вторых, переход к инструментам на базе ИИ изменил сам темп, в котором теперь можно работать.

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

Пересмотренные правила

1. Миграцию может провести один специалист, а не целая команда.

Даже крупные и сложные изменения теперь можно на 95% поручить одному основному исполнителю или одной ведущей команде и завершить за 10% прежнего времени.

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

Профессиональное мнение отдельного специалиста ещё никогда не влияло на компанию так сильно.

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

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

Насколько именно трудно, зависит от инфраструктуры разработки:

• тестов,

• CI/CD,

• сред проверки,

• возможности предварительно просматривать изменения

• и других подобных механизмов.

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

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

Хорошая новость в том, что самые эффективные способы ускорить разработку два года назад остаются самыми эффективными и сегодня.

3. Оптимизируйте типовой сценарий процесса под ИИ‑агентов. 

Большинство этапов большинства процессов в большинстве случаев можно полностью автоматизировать.

При наличии:

• подходящей инфраструктуры,

• механизмов контроля,

• знания предметной области

• и профессионального суждения у тех, кто проектирует процесс,

типовой сценарий почти любого процесса в современной технологической компании можно автоматизировать целиком.

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

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

Разумеется, есть и более рискованные зоны, где это правило не работает.

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

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

Совместное планирование по‑прежнему важно, но людям стоит заниматься им на более высоком уровне.

4. Устойчивые команды, которые глубоко знают свою предметную область и полностью отвечают за результат, стали ещё важнее.

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

Со временем они:

• накапливают знание предметной области,

• формируют чувство товарищества

• и всё сильнее воспринимают свою область как собственную зону ответственности.

Даже сейчас, когда реализовать что‑либо конкретное стало намного дешевле, всё равно нужно делать правильные вещи.

Выбирать их стало немного проще, но лишь немного, и здесь помогают системные изменения.

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

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

Картина очень привлекательная, но я не вижу, чтобы всё двигалось в эту сторону.

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

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

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

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

А это зависит:

• и от того, насколько продуманно спроектирована автоматизация,

• и от готовности команд сотрудничать.

Реализовать новую функцию имеет смысл только тогда, когда вы способны принять решение о её запуске.

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

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

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

Это не значит, что руководители принимают решения лучше остальных.

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

Что мы сделали на практике

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

Миграции

• Год назад мы выкатывали изменения вручную и делали около шести развёртываний в неделю. Сейчас мы деплоим 200–400 раз в неделю. Численность инженерной команды за это время удвоилась, но даже если просто удвоить прежнее количество развёртываний, рост всё равно составляет 20–30 раз год к году. Этого удалось добиться благодаря полной переработке процессов развёртывания и проведения миграций. Сама миграция заняла два месяца, и на 90% её выполнили два специалиста из инфраструктурной команды.

• В начале января около 25% сотрудников инженерной команды использовали Claude Code или Cursor ежедневно. К концу февраля ими пользовались уже все. Мы добились этого без распоряжений сверху: просто сделали инструменты удобными и поговорили с теми, кто ещё на них не перешёл, чтобы убрать мешавшие им проблемы. Теперь почти каждый пул‑реквест, по крайней мере в первой версии, пишется с помощью нашей инфраструктуры разработки.

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

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

• Примерно за месяц мы объединили фронтенд‑архитектуру из нескольких репозиториев в один монорепозиторий. На 95% эту работу вёл один фронтенд‑инженер. Теперь у нас общая инфраструктура фронтенд‑разработки, библиотеки стало проще сопровождать, а от npm как хостинга пакетов мы полностью отказались — раньше он постоянно создавал нам неудобства.

• Мы полностью перевели фронтенд‑код на статическую типизацию, хотя прежде большая его часть вообще не была типизирована. Эту работу за несколько недель выполнил один инженер при весьма значительных затратах токенов.

• Мы также мигрировали с npm на pnpm ради более безопасных настроек по умолчанию и более быстрых развёртываний. Один инженер тратил на это по несколько часов в день в течение нескольких дней.

Стоимость работающего кода зависит от инфраструктуры разработки

Когда мы пытались просто передать дизайн‑документы и пул‑реквесты инженерам из других команд и считать свою работу законченной, из этого ничего не выходило.

Низкокачественные пул‑реквесты и дизайн‑документы дёшевы, но при этом откровенно вредны.

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

Мы увидели отличные результаты, когда менеджеры сами вносят изменения в код, но только при условии, что они:

• напрямую проверяют свою работу,

• следят за дашбордами после выкладки изменений

• и устраняют все возникшие из‑за них проблемы.

Попытки вносить изменения без этого не дали никакого положительного эффекта.

Оптимизируйте типовой сценарий процесса под ИИ‑агентов

• Все обращения от команды клиентских операций проходят первичную сортировку и оценку с помощью нашей инфраструктуры разработки. Она знает состав команды, видит открытые тикеты и имеет ограниченный доступ к хранилищу данных, чтобы оценивать масштаб последствий каждой проблемы. Это сложная работа, требующая высокой квалификации, но сама по себе не особенно интересная. Теперь ИИ‑агенты выполняют её быстрее и качественнее. Да, нестандартные случаи по‑прежнему разбирает человек. Важно и то, что мы не меняли привычный рабочий процесс: он остался прежним, просто отдельные этапы теперь автоматизированы.

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

• В прошлом квартале мы развернули Claude Code и Cowork для всех сотрудников компании. С тех пор они тоже автоматизируют всё большую часть своей работы. Особенно далеко продвинулась команда по борьбе с мошенничеством: она заменяет ручные процессы первичной автоматической проверкой потенциальных атак с указанием данных, на которых основаны выводы.

• Мы перешли с Jira на Linear, чтобы лучше поддерживать такой подход: у Linear более функциональный MCP и лучше интеграция со Slack. Благодаря этому у всех сотрудников появилась более подходящая инфраструктура для создания процессов, изначально рассчитанных на ИИ‑агентов. Подробнее об этом расскажу позже, но сейчас мы почти завершили альфа‑тестирование внутренней системы, которая автоматически забирает задачи из Linear и пытается их решить. Это наш следующий большой шаг в этом направлении.

Устойчивые команды, которые глубоко знают свою предметную область и полностью отвечают за результат, стали ещё важнее

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

Такой подход работал, но из‑за него мы в основном реагировали на уже возникшие проблемы.

Теперь за каждой важной областью компании закреплена хотя бы небольшая команда, которая может постоянно в неё вкладываться.

Эти команды сами используют все новые возможности, которые даёт ИИ.

Без них некому было бы находить и реализовывать такие улучшения: вокруг происходит слишком много всего.

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

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

Здесь сразу несколько характерных примеров:

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

• Переработка CI/CD‑конвейера тоже оказалась спорной, поскольку изменила привычное для многих представление о развёртывании и выпуске. Например, нам пришлось явно разделить развёртывание кода и выпуск функции с помощью feature flags. Решение вызвало немало разногласий, а при движении снизу вверх принималось бы медленно и тяжело.

• Объединение веб‑проектов в один монорепозиторий тоже было спорным решением, по которому существовали разные мнения. Здесь очень помогло то, что в итоге было принято единое решение.

• Переход на SierraAI потребовал сложного обсуждения: мы сравнивали его и с несколькими конкурентами, и с вариантом вообще ничего не менять. Чтобы завершить межфункциональную дискуссию, понадобилось окончательное одобрение руководства.

---

Это лишь несколько характерных примеров, на деле мы сделали гораздо больше.

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

Удивительное время для работы в технологиях.

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

Разобраться с этими задачами на практике можно на открытых уроках — и заодно увидеть, что главный эффект ИИ начинается там, где меняется не отдельный инструмент, а сам способ организации работы.

• 17 августа, 20:00. «Создаем первого ИИ‑агента за 90 минут: автоматизируем реальную рабочую задачу с Claude Code». Записаться

• 3 сентября, 20:00. «Как руководителю внедрить ИИ в работу команды: от выбора процесса до рабочего сценария». Записаться

• 8 сентября, 20:00. «От технического лидера к CTO: как начать принимать решения на уровне бизнеса». Записаться

Расписание бесплатных уроков августа смотрите в дайджесте.