CTO, девопс, стафф-инженер, дежурный?

Вот неполный список того, что я сделал “руками” за последние два месяца:

  • Допилил и поднял общий MCP-реджистри с read-only доступом к Kubernetes-кластерам, БД Postgres, Mattermost, ELK. Теперь все сотрудники добавляют ровно один MCP-сервер в настройки и получают безопасный доступ к логам, статистике, сообщениям в публичных каналах
  • Поднял и настроил OpenWebUI для “low-code personas” (новый угарный термин для не-технарей). Позволяет платить 20 баксов за токены по API на всех вместо 20-долларовой подписки на каждого
  • Поднял ИИ-дежурного на калибровку КТ ГМ по морфометрии, который следил ночью за нестабильной системой, которая могла залипнуть и больше не обрабатывать последующие исследования
  • Настроил сложную схему с общим облачным VPN с раздельным проксированием трафика в четыре точки. Кстати, пользуясь случаем, посылаю свою лютую ненависть всем, кто хоть на каплю причастен к блокировкам и к причинам их возникновения, а также ко всяческим максам и их принудительно-добровольному внедрению. Я вас искренне ненавижу, надеюсь, это взаимно
  • Добавил в LLM-алерт-менеджер большую часть локальных деплоев Цельса с дополнительными проверками
  • Создал шаблон для код-ревью с помощью Claude Code в Azure, который можно внедрить себе в проект
  • Провёл пен-тест нашей инфраструктуры

MCP-реджистри

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

(Не) делегируй это

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

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

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

  • “Так будет намного быстрее, а это сейчас горит”
  • “Не хочется терять тонус, иначе потеряю инженерные навыки”
  • “Хочется позаниматься чем-то кроме бесконечных встреч”

Но появление и развитие инструментов типа Claude Code снимает это ограничение. Сейчас не надо никому передавать свои идеи, сел, в зависимости от размера идеи выбрал фреймворк (от простого промптинга до тяжеловесного BMAD) и полетели, инструмент за тебя сделает всё, от технического рисёча до код-ревью, а тебе, утрируя, остаётся только проверять, что реализация соответствует изначальной идее.

Это только половина BMAD

И занимает это не спринт, не две недели, а чаще всего 2-3 часа (если лимитов хватит), в худшем случае несколько дней. К примеру, тот же MCP-реджистри я допилил под нас и поднял за один вечер, добавление каждого нового MCP со скиллом занимает от силы час (а моего времени там минут 10). Раньше пришлось бы искать кого-то, кто доработал бы сам реджистри (из коробки опен-сорс не завёлся), потом ставить девопсу задачу на поднятие и настройку его в нашем дата-инженерном кластере. В итоге с большой вероятностью, учитывая операционную нагрузку, это сделано бы просто не было, поскольку это не критически важная задача, а что-то разряда “nice-to-have”.

Что в этом хорошего?

Конечно же, плюсы в таком сжатии процесса разработки, когда CTO может завайбкодить что-то за вечерок, есть:

  • Снятие боттлнека. Как писал выше, если компания небольшая, а люди перегружены, то MCP-реджистри или удобная настройка VPN-прокси может навечно остаться в подвале бэклога. Я сделал сам - и все теперь пользуются
  • Разгрузка команд от нефокусных задач. ML-команды у нас целиком отвечают за работу своей системы. При этом у нас важнейшей задачей в последние месяцы было именно поднятие метрик и успешное прохождение калибровочного тестирования по КТ головного мозга. В итоге к калибровке мы подошли с парой непонятных багов. Мне удалось прям в день калибы подключиться и закодить одноразовое решение в виде ИИ-дежурного (по сути крон-джоба), которое избавило от необходимости сидеть ночью и следить за ходом калибровки
  • Углубляется понимание системы. Одна из проблем руководителя - слишком отрываешься от “земли”. А когда сам покопался в системе мониторинга, в организационных настройках Claude Code, в настройке VPN - понимаешь, где реально болит, а не на абстрактном уровне
  • Личное психологическое здоровье. Бизнес-результаты часто слишком отдалены во времени и пространстве от CTO. Скажем, прошли калибровку и подняли доход компании - успех команды. А я что сделал? Когда шатаешь что-то с Claude Code и получаешь результат - получаешь более прямой дофаминчик

Что в этом плохого?

Понятное дело, что у всего есть обратная сторона медали:

  • Приучаешь команду к тому, что ты всегда рядом. Если ты всегда и во всех тредах и готов подорваться, во всём разобраться и починить - это приучает людей надеяться в таких вещах на тебя. А тебя может завтра не стать (ушёл в отпуск, уволился, эмигрировал, похмелье). Важное примечание - если всё-таки взялся что-то сделать, обязательно надо задокументировать и куда-то положить
  • Отнимаешь возможность к росту. Каждая взятая задача - это задача, на которой мог бы вырасти кто-то другой. С ИИ эффект усиливается, раньше условный мидл знал контекст проекта лучше тебя, сейчас этой проблемы фактически нет, и можно брать почти любую задачу. Важно при этом, чтоб у людей в принципе была возможность брать какие-то новые для себя задачи, а не только тухнуть в операционке. Если такого механизма нет, то чинить надо в первую очередь это
  • Парадокс ценности. Раньше я брался только за какие-то очень важные или ценные для себя и компании штуки, а сейчас можно параллельно вести 5 задач и 3 пет-проекта, лишь бы лимитов и фокуса внимания хватало. В итоге общее количество ценности может и не вырасти. Так что перед реализацией всё ещё важно думать, а оно вообще того стоит?
  • Ноша поддержки. Подняв 10 инструментов, ты подписываешься их поддерживать, передать их потом кому-то будет почти невозможно. Например, я пытался передать ЛЛМ-алерт-менеджер дата-инженерной команде, но пока безуспешно, там своих задач навалом. Благо поддержка обычно не отнимает много времени, но кумулятивный эффект не очень приятный

Что делать?

Очевидно, нужен какой-то мини-чек-лист, чтоб принимать осознанное решение врываться в проект или задачу (ну ещё я люблю чек-листы и списки). Например, такой:

  • Это одноразовая штука или нужно будет постоянно поддерживать? Чем ближе ко второму, тем сомнительнее это брать на себя. Надежда передать это кому-то на поддержку потом может быть тщетной
  • Что произойдёт, если эта штука не будет сделана за час, день, неделю? Критические для компании вещи надо брать и делать, особенно если по времени и скиллам сейчас некому. Если же не очень серьёзный инцидент висит без ответа час, пусть лучше команда сама разбирается с ним и со своими процессами. Всегда можно нажать “Follow” и следить за происходящим в треде из тени…
  • Какая вероятность, что кто-то сможет это сделать в ближайший месяц? Если это штука из вечного подвала бэклога, то вряд ли кому-то станет хуже, если ты повайбкодишь вечерком за чашечкой габы. Особенно если это в итоге облегчит всем жизнь и принесёт реальную ценность
  • Есть ли у задачи скрытая косвенная ценность? Например, если среди твоих задач - осознанное внедрение ИИ в работу техотдела, то очень неплохо понимать, как, собственно, работают ИИ-агенты, какие практики хорошие, какие плохие. Этого понимания не достичь, просто читая твиттер и реддит, надо реально поделать что-то самому, тем более, что всё ещё и постоянно меняется, а у твоих инженеров может не быть времени следить за всем этим
  • Какая реакция у команды? Если они рады помощи и новым фишкам - круто! Если бесятся, что забираешь их зону ответственности или наоборот скидываешь фигни на поддержку - стоит задуматься, нужно ли брать задачи из этой области
  • Зачем я сюда лезу? Если просто из-за скуки, то часто лучше пойти почитать книжку

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

  • Emergency mode - всё горит, клиенты завтра разорвут контракт, никто не понимает, что делать
  • Value mode - инфраструктурное улучшение, которое разгрузит или поможет сразу многим, но которое некому сделать (по времени, скиллам, желанию)
  • Learning mode - когда нужно самому погрузиться в новую технологию или инструмент

В общем, старое правило “CTO/стафф не должен писать код”, на мой взгляд, устарело. Ну как, код писать как раз теперь не надо, но реализовать что-то самому - вполне окей, если это принесёт компании ценность и не создаст техдолга и других проблем для коллег. Думаю, что в нетехнических областях и ролях может быть аналогичная ситуация.

И не забываем, конечно, что использование ИИ само по себе не лечит структурные проблемы. Если девопс перегружен, а команда утопает в алертах - то CTO с Claude Code под рукой тут явно не главное решение.