Зачем руководителю возвращаться к коду

Интерес Никиты к инженерии вырос в семье инженеров: отец собирал компьютеры, дома появился Spectrum, а затем математическое образование и компьютерная графика показали прямую связь между собственными действиями и результатом на экране. Из графики он перешёл в мобильную разработку. Первое стремление руководить объясняет желанием автономии и уверенностью, что знает лучше других. Когда единственный программист получает второго коллегу, техническое лидерство возникает почти автоматически; сегодня Никита считает тот ранний заход неподготовленным. Позже в Берлине он прямо заявил новому менеджеру, что хочет занять его место. Вместо прекращения разговора тот указал на недостаточное понимание собственного поведения и предложил спросить коллег, хотят ли они такого руководителя. Честная обратная связь и помощь HR заставили пересмотреть представление о себе. В календаре появилось ежедневное напоминание BeKind: сначала остановиться и выдохнуть, затем разговаривать. Мотивацией стало помогать другим расти, включая людей, с которыми отношения складывались трудно.

Поначалу Никита доверял сотрудникам, объяснял направление и рассчитывал, что они сами придут за помощью. Слабым местом оказался контроль результата: одинаковая свобода подходила далеко не всем. Начинающему нужны ориентиры и поддержка, опытному самостоятельному специалисту — пространство для решений. Поломодов называет это ситуационным лидерством: руководитель меняет способ взаимодействия в зависимости от человека и обстоятельств. В Playrix различие стало особенно наглядным. Никита отвечал за техническую часть Gardenscapes и перестроил большую техническую группу вокруг отдельных задач. Сильные инженеры по низкоуровневой оптимизации сами искали полезную работу; им требовалась помощь с препятствиями и конфликтами. Команде качества, релизов и CI/CD, напротив, нужны были дежурства, процессы и быстрый отбор входящих ошибок. За одним названием должности скрывались разные способы работы. Масштаб руководителя Никита предлагает оценивать через ответственность, снятую с других: если переданные ему вопросы постоянно возвращаются к руководству, роль ещё не выполняется полностью.

Первый заметный сигнал от языковых моделей пришёл ещё в AutoScout24: ранний ChatGPT нашёл ошибку, которую инженер несколько часов не мог локализовать. Затем появились скрипты и внутренние инструменты. В Playrix внедрение стало отдельной управленческой задачей: команды переходили на Cursor, а в Asana отмечали результаты попыток, чтобы понять, где работа действительно ускоряется. Сильнейшие программисты подключались позднее других. Никита объясняет это высоким исходным уровнем: если специалист долго обдумывает сложную задачу, а код пишет быстро, простое ускорение набора кода мало меняет его работу. Более убедительным оказался проект автоматического разбора ошибок. Никита проектировал его вместе с инженером и столкнулся с выдуманными ответами, нестабильным качеством и медленной обработкой. Рабочую систему удалось получить, ограничив неопределённость: задать граф состояний, связать этапы с инструментами и запускать их в изолированной облачной среде. Опыт показал и возможности агентов, и цену управления ими; первоначальной идеи для надёжной работы оказалось недостаточно.

Личный перелом случился, когда Gemini в Firebase Studio начала собирать сайт для сборника рассказов Никиты. Вместо чтения обещаний он увидел, как продукт появляется без привычного объёма ручной работы. Возник вопрос: как руководить такими командами, если даже их новые проблемы остаются незнакомыми? Возвращение к практике стало способом обновить собственную картину производства. После завершения трансформации в Playrix Никита договорился об уходе, перестал искать управленческие позиции и попробовал самостоятельное консультирование. В Bluefish его привлекли новый предмет работы и возможность взять ответственность за внедрение разработки с ИИ. Управленческий опыт при этом остался полезен: найти владельца части системы, попросить помощь, быстро исправить ошибку и договориться о следующем изменении. Прогноз о сокращении управленческих слоёв Никита отделяет от факта: он допускает, что меньшим автономным командам понадобится меньше менеджеров, но не объявляет это неизбежным устройством любой компании. Приоритеты, концентрация и лидерство, по его мнению, сохраняют ценность.

Bluefish работает с крупными корпоративными клиентами, поэтому устройство разработки зависит от доверия, договоров и ответственности за данные. Клиенту нужен понятный процесс и конкретный человек, который решает проблемы. В основной системе инженер лично отвечает за внесённое изменение; ссылка на совет модели эту ответственность не снимает. Одновременно сотрудники, работающие с клиентами, создают собственные инструменты через Claude. Запретить эксперименты означало бы оставить их с прежней нагрузкой, а сократить самих сотрудников — поставить под угрозу отношения, за которые платят клиенты. Никита предложил общую инфраструктуру: репозиторий, критерии качества, проверки безопасности и соответствия требованиям. Для основной разработки обсуждаются единые критерии проектирования и проверки агентами собственной работы. Уже действующий автономный контур берёт небольшие задачи из Jira, проходит через очередь SQS, проверяет входные данные, строит план с постусловиями, реализует изменение и открывает запрос на включение кода. Его область — мелкие ошибки и технический долг; решение о необходимости задачи остаётся за инженерным менеджером.

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