Как удержать senior-разработчиков в эпоху AI: кейс на 42 РМ продуктовой компании

У клиента — продуктовой компании на 42 рабочих места — в начале 2024 года текучка senior-разработчиков составила 47% за год: ушли 8 человек из 17. CTO позвал нас на разбор «что мы делаем не так». Мы 3 месяца собирали данные MS-360 опросов с 12 оставшимися senior-ами, выявили три блокирующих фактора, выработали фреймворк из трёх шагов и за следующие 18 месяцев снизили текучку до 12% (2 из 17). Делюсь полным разбором: что senior-разработчиков на самом деле болит в эпоху AI, и что с этим можно сделать без удвоения зарплат.

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

Знаете, до 2023 года текучка senior-разработчиков у нашего клиента держалась в пределах 12-17%. Для российского ИТ-рынка это вполне себе нормальная история. Но в 2023 году что-то изменилось: команда начала активно внедрять AI-помощников – сначала Copilot, потом Claude, затем Cursor. И вот тут-то начались проблемы. Параллельно с этим, мы заметили, что уровень удовлетворённости senior-разработчиков стал падать, это было видно по анонимным опросам в MS-360. К декабрю 2023 года средний балл по вопросу «насколько вам интересна работа» рухнул с 7,8/10 до тревожных 4,1/10 именно в сегменте senior-ов.

В январе 2024-го ситуация обострилась до предела: за один месяц сразу 3 человека подали заявления об уходе. Тут уж CTO не выдержал и сказал: «Нам нужен свежий взгляд со стороны». Так меня и позвали – как стороннего консультанта. Мой опыт работы с командами разной численности у разных клиентов как раз был кстати. И знаете, первое, что я сделал, это убедил CTO: не стоит сразу кидаться с контрпредложениями по зарплате. Сначала надо понять, почему люди на самом деле уходят. Ведь деньги – это зачастую просто симптом, а не настоящая причина.

Что показал первичный анализ MS-360

Я погрузился в данные, обработав 18 месяцев анонимных опросов от 17 senior-разработчиков. Всего набралось 124 ответа! По применённой мною системе кодирования открытых ответов выделились 6 основных тем. Чаще всего (в 38% упоминаний) звучало: «AI забрал интересную часть моей работы». На втором месте (29%) – «middle-разработчики стали выдавать почти как я, и непонятно за что я получаю в 2,5 раза больше». Третья по значимости тема (18%) – «менторство вытесняется AI, и я больше не чувствую себя нужным как наставник». Остальные три темы – про офис, отдых и формальную карьерную лестницу – суммарно набрали 15% упоминаний.

Гипотеза: AI делает середину карьеры скучной

Исходя из всех этих данных, у меня сформировалась такая гипотеза. Раньше senior-разработчик тратил примерно 50% своего времени на по-настоящему интересные задачи: проектирование систем, написание сложных модулей, отладка каких-то нетривиальных багов. Но вот в чём загвоздка: эти самые 50% – это и есть самое лакомое для AI. Все эти типовые модули, рефакторинги, диагностика по stack-trace… Получается, AI забирает у senior-ов именно эти интересные 50%, оставляя им в нагрузку оставшиеся 50% управленческой рутины: встречи, ревью кода, найм, оценка ресурсов. А вот у middle-разработчика картина обратная: AI берёт на себя рутину, и middle, наоборот, получает больше интересных задач.

Вот и получается такая неприятная ситуация, словно ножницы: middle-разработчик становится продуктивнее, его работа кажется ему интереснее, а senior – наоборот. Именно это объясняет, почему сейчас уходит именно сегмент senior-ов, а не middle-разработчики. Деньги в этой схеме – вторичны. Senior уходит не за +30% к зарплате, а за надеждой «вернуться к интересной работе» в другой компании. Но проходит 6-8 месяцев, и он обнаруживает, что и на новом месте AI уже успел забрать интересную часть задач. И он снова уходит. Честно говоря, это уже не проблема одной конкретной компании, а системный вызов для всей индустрии.

Подтверждение от индустрии

Я не стал ограничиваться одним клиентом. За полгода я обзвонил CTO ещё 7 компаний из моего круга – это были команды разработки от 30 до 200 человек. И везде, представляете, картина повторялась! Текучка senior-сегмента в 2024 году выросла на 30-60% по сравнению с 2022-м, а анонимные опросы стабильно выводили на первый план ту же самую тему: «AI забрал интересное». Это стало для меня окончательным подтверждением: моя гипотеза не просто локальная проблема одного клиента, а отражает настоящий индустриальный сдвиг.

Три блокирующих фактора, которые мы видим в опросах

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

Вот эти факторы. Фактор 1 – это «потеря интересной части работы». Senior тратит 50% своего времени на то, что AI уже делает ничуть не хуже. Тут же включается неприятное чувство: «Я уже не нужен». Фактор 2 – «размытие границы между уровнями». Представьте, middle-разработчик с помощью AI в пятницу вечером за 4 часа пишет фичу, на которую senior закладывал целых 2 дня! И это видит вся команда, даже CTO. Senior начинает чувствовать себя обязанным оправдывать свою зарплату, а это, согласитесь, унижает. И, наконец, Фактор 3 – «снижение веса менторства». Раньше junior-ы постоянно бегали к senior-у с вопросами – по 5-10 раз в день. Теперь они идут к Claude, и senior теряет ту роль наставника, которая для многих была главным мотиватором в работе.

Что НЕ помогает

Прежде чем я расскажу о фреймворке, которым мы воспользовались, мне кажется важным перечислить, что мы пробовали – и что, увы, не сработало. Не помогают: повышение зарплаты на 20-30% (даёт лишь временное удержание на 4-6 месяцев, а потом тот же отток), новые тайтлы вроде «Staff Engineer» без изменения содержания работы (через 3 месяца они превращаются в пустые ярлыки), офсайты и тимбилдинги (да, улучшают настроение, но лишь на неделю, не решая сути проблемы), «домашний офис» (он отлично помогает junior-ам и middle-ам, но senior-ы и так работали удалённо ещё до пандемии). Всё это, конечно, не вредит, но и не лечит. Поэтому мы решили сосредоточиться на корне проблемы.

Шаг 1 фреймворка: проекты, которые AI не выучил

Первый и самый важный шаг – это найти для senior-ов такие проекты, где AI либо бесполезен, либо вообще вредит. На таких проектах senior снова чувствует себя незаменимым, и, что важно, интерес к работе возвращается. У нашего клиента мы выделили три такие категории проектов и, соответственно, распределили по ним senior-разработчиков.

Категория А – это интеграции с устаревшими российскими системами. Представьте, у клиента в роадмапе на 2024-2025 годы было 6 таких интеграций: 1С 7.7 (один из подрядчиков до сих пор на ней сидит!), СМЭВ-3 для двух госуслуг, ФССП-API, старые версии ЕГАИС для торгового подразделения, СБИС-Электронные документы и, конечно, обмен с одним конкретным банком через HTTPS с их самописным протоколом. AI-помощники просто не имеют тренировочных данных по большинству этих систем и поэтому начинают, извините, галлюцинировать. На таких проектах senior-разработчик просто незаменим: он сам читает .NET-документацию, разбирается в XML-схемах, пишет адаптеры вручную.

Категория Б и В

Категория Б — производственные системы с уникальной бизнес-логикой. У клиента есть собственный биллинг с системой партнёрских скидок (4-уровневая иерархия), который написан на Python+SQLAlchemy на 18 000 строк кода. AI не понимает специфики этой системы и предлагает обобщённые решения, которые ломают работу скидок. Senior с историей в этой системе — единственный, кто может вносить изменения безопасно. Категория В — production-инциденты на конкретном legacy-стеке. На любой инцидент в legacy-коде идёт senior — AI здесь только мешает (см. предыдущую нашу статью про правила code-review с AI).

# Распределение проектов по senior-ам у клиента, фрагмент из roadmap
# /docs/senior-projects-2024.yaml

senior_projects:
  - assignee: a.smirnov
    role: ведущий разработчик 1C-интеграций
    projects:
      - name: 1С 8.2 → новый биллинг (обмен через RabbitMQ)
        ai_helpful: false
        why_no_ai: специфика самописной конфигурации, AI галлюцинирует
        time_budget_q1: 240h
      - name: ЕГАИС 4.x migration
        ai_helpful: false
        time_budget_q1: 80h

  - assignee: e.petrov
    role: архитектор данных
    projects:
      - name: data lakehouse на Iceberg (миграция из PG)
        ai_helpful: partial
        why_partial: AI помогает с инфрой, но не с миграционным планом
        time_budget_q1: 320h

  - assignee: k.ivanova
    role: performance engineering lead
    projects:
      - name: bottleneck analysis в order-service (Go)
        ai_helpful: false
        why_no_ai: low-level pprof + работа с CPU profiler
        time_budget_q1: 160h

Уже через 3 месяца после переключения senior-ов на такие проекты средняя оценка «насколько мне интересна работа» в анонимных опросах выросла с 4,1/10 до 6,7/10. Двое senior-разработчиков, которые писали заявление об уходе, отозвали его — буквально потому что им стало интересно.

Шаг 2: ROIC-учёт менторства, чтобы оно стало видимым

Что касается третьего блокирующего фактора – «менторство потеряло вес» – то мы решили его через внедрение показателя ROIC (Return On Invested Capital). Теперь у клиента в OKR каждого senior-разработчика появился конкретный показатель: «ROIC от менторства». Он рассчитывается так: (рост скорости подопечных в часах × ставка часа подопечного) / (часы senior на менторство × ставка часа senior). Цель – всегда больше 2,5. Это даёт senior-у ощутимое, измеримое влияние, которое, что важно, выражается в деньгах.

А вот как мы это мерим. Подопечный, обычно это middle-разработчик, в начале квартала фиксирует свою скорость по определённым типам задач. Например, говорит: «Фича среднего размера у меня занимает 18 часов». Senior проводит с ним регулярные 1-on-1 сессии (45 минут раз в две недели), активно помогает в code-review, организует «парные» дизайн-сессии по сложным фичам. В конце квартала подопечный снова замеряет свою скорость: «Теперь та же фича занимает 11 часов». Разница – это 7 часов экономии. Если таких фич 12 за квартал, то это 84 часа экономии. При ставке middle-разработчика 3 000 ₽/час это выливается в 252 000 ₽. Senior же потратил на менторство 36 часов, и при его ставке 6 000 ₽/час это составило 216 000 ₽. Считаем ROIC: 252 000 / 216 000 = 1,17. В этом примере цель (больше 2,5) не достигнута, значит, нужно усиливать работу.

Что это даёт senior-разработчику

Самое главное – senior теперь видит свой реальный вклад в цифрах. Когда HR на годовом ревью спрашивает: «За что мы повышаем тебе зарплату?», senior может спокойно показать: «Вот мой ROIC от менторства – 3,2 в среднем за год. Я сэкономил компании 8,2 миллиона рублей за счёт роста моих подопечных». Это невероятно сильный аргумент, который раньше был абсолютно невидим. У клиента сейчас 4 из 5 senior-разработчиков показывают ROIC в диапазоне 3-4,5, и трое из них получили повышение зарплаты на 18-25% на годовом ревью, основываясь именно на этом обосновании.

Шаг 3: ротация в нетривиальные домены

Третий шаг мы предлагаем тем senior-ам, у которых даже после первых двух шагов всё ещё остаётся это неприятное ощущение: «Я как-то медленно расту, моя экспертиза становится просто товаром». Им нужен переход в совершенно новый домен, где AI пока помогает очень мало, а само погружение требует серьёзных усилий, месяцев 6-12. У клиента мы выделили четыре таких перспективных направления и предложили senior-ам выбрать то, что им больше по душе.

Направление 1 – это архитектура данных. У клиента это был переход от классической PG-схемы к data lakehouse на Apache Iceberg, S3, Trino и dbt-моделях. AI здесь, конечно, помогает с инфраструктурным кодом, но совершенно бесполезен для дизайна моделей и миграционных планов. И вот senior, имеющий, скажем, три года опыта в Postgres, за полгода становится настоящим full-stack data engineer и решает такие задачи, которыми в компании до него никто не занимался!

Направление 2 – performance engineering. Это глубокий анализ конкретных узких мест в Go/Rust-сервисах с помощью таких инструментов, как perf, pprof, eBPF. У клиента, например, есть order-service на Go, который держит 1 200 RPS на пике, и senior-ы с огромным интересом погружаются в low-level оптимизации – будь то выделение памяти, GC pauses или locks. AI здесь выручает только в самых типовых сценариях, а основная работа – это построение гипотез и проведение экспериментов.

Направления 3 и 4

Направление 3 – security engineering. Здесь речь идёт о поиске уязвимостей с помощью codeql, fuzz-тестов, threat modeling и периодических pentest-сессий. У нашего клиента это направление отлично подошло senior-у, которому безопасность была близка по складу мышления. AI здесь, конечно, помогает с описанием уже найденных уязвимостей, но совершенно бесполезен в поиске новых паттернов атак. И Направление 4 – платформенная разработка. Это создание Kubernetes-операторов, собственных controllers, internal developer platform. Такая работа требует глубокого системного дизайна и понимания распределённых систем – вот тут AI как раз пасует.

# Шаблон 1-on-1 ротационной сессии CTO + senior, раз в квартал
# /docs/senior-rotation-template.md

## Состояние сейчас
- Какие 3 проекта были самыми интересными за квартал?
- Какие 3 — самыми скучными?
- Где AI забрал у тебя интересную часть, и что осталось?

## Ротационные варианты
1. Архитектура данных (Iceberg, dbt, Trino)
2. Performance engineering (Go pprof, eBPF, CPU profiling)
3. Security engineering (codeql, fuzz, threat modeling)
4. Платформенная разработка (k8s operators, IDP)

## Решение на квартал
- Выбранное направление: ____
- Поддержка от компании:
  - [ ] оплата книг/курсов до 80 000 ₽
  - [ ] участие в конференции (РИТ++, HighLoad)
  - [ ] выделенные часы в неделю на изучение (8-12 ч)
  - [ ] mentor-контакт извне (engaged consultant)
- Целевой проект на квартал: ____
- Метрика прогресса: ____

Из 12 senior-разработчиков, которые остались в компании, 5 за 18 месяцев перешли в новые домены: 2 в архитектуру данных, 1 в performance engineering, 1 в security, 1 в платформенную разработку. Все пятеро в текущих опросах MS-360 ставят 8+/10 в «удовлетворённость работой» — это выше, чем было до прихода AI вообще.

Сроки и ROI: как окупилось за 4 месяца

Вся эта работа заняла у нас 18 календарных месяцев. Первые 3 месяца ушли на сбор и анализ данных MS-360, а также на интервью с уходящими senior-ами. Затем 2 месяца мы потратили на разработку фреймворка и его согласование с CEO и CTO. И, наконец, 13 месяцев заняло постепенное внедрение фреймворка, работая параллельно с 5 senior-ами. Моё прямое участие составило 12 рабочих дней в первые 5 месяцев, плюс я выделял 8 часов в месяц на квартальные ретроспективы в оставшиеся 13 месяцев. И, конечно, дополнительно было 24 часа консультаций с HR-партнёром компании.

Стоимость всей этой работы составила 480 000 ₽. А теперь о результатах: текучка senior-ов упала с 47% (это 8 уходов из 17 senior-ов за год до начала проекта) до 12% (всего 2 ухода из 17 за последние 12 месяцев). Давайте посчитаем: один уход senior-разработчика обходится компании в 1,5-2,5 миллиона рублей – это и поиск, и рекрутер, и испытательный срок, и, конечно, потеря экспертизы, да и команда замедляется. Мы предотвратили 6 уходов за 18 месяцев! Если грубо посчитать, ROI проекта составил около 12-15× по чистым деньгам, и это мы ещё не учитываем косвенные выгоды, такие как стабильность экспертизы, мораль команды и скорость доставки фич.

Что осталось как риск

Я не буду утверждать, что мы «решили» проблему раз и навсегда. AI продолжает семимильными шагами развиваться, и я уверен, что через 12-18 месяцев Claude 5 или Opus 5 заберут у senior-ов ещё какую-то часть их интересной работы. Это значит, что наш фреймворк нужно будет повторять каждые 12-18 месяцев: переопределять, что же такое «проект, который AI пока не выучил», искать новые нетривиальные домены, перебалансировать ROIC-цели. У нашего клиента это уже вошло в годовой OKR-цикл CTO. По моему опыту, компании, которые этого не делают, рискуют терять 30-50% senior-ов каждые 18-24 месяца, а это, поверьте, очень тяжёлый налог на бизнес.

FAQ: что чаще всего спрашивают клиенты

Почему senior-разработчики уходят именно сейчас, в 2025-2026?

По нашим данным, собранным из MS-360 на 12 senior-разработчиках за 18 месяцев, выделились три основные причины. Во-первых, AI просто забрал у них самую интересную часть работы: написание нового кода, типовые модули, оптимизации. В итоге им осталась только рутина управления командой и работа с legacy-кодом. Во-вторых, middle-разработчики с AI на борту стали выдавать 60-70% от объёма senior-а, что, конечно, обостряет вопрос: «За что же мне платят в 2,5 раза больше?» И в-третьих, это было просто чувство усталости от бесконечных объяснений junior-ам очевидных вещей, которые теперь Claude объясняет им совершенно бесплатно.

Что значит «проект, не выученный AI»?

Мы говорим о задачах, для которых AI-помощники либо бесполезны, либо откровенно вредны. Таких категорий три. Первая: это интеграции с устаревшими российскими системами, например, 1С 7.7, 1С 8.2 с их самописными конфигурациями, СМЭВ, ФССП-API, старые версии ЕГАИС. У AI по ним просто нет тренировочных данных, и он начинает галлюцинировать. Вторая: это производственные системы с уникальной бизнес-логикой – скажем, расчёт себестоимости по какой-то уникальной методологии или биллинг с целой сетью партнёрских скидок. Третья: это production-инциденты на специфическом legacy-стеке. Именно на таких проектах senior-разработчик снова чувствует себя по-настоящему нужным.

Как ROIC учитывается на менторстве?

У нашего клиента я ввёл чёткое правило: каждый senior-разработчик в своём OKR на квартал теперь имеет показатель «ROIC от менторства». Рассчитывается он так: (рост скорости подопечных × ставка часа подопечного) / (часы senior на менторство × ставка часа senior). Цель – всегда больше 2,5. Это даёт senior-у конкретное, измеримое влияние, которое выражается в деньгах. Раньше менторство воспринималось как «нагрузка сверху», и senior-ы чувствовали себя так, будто их наказывают. Сейчас же 4 из 5 наших senior-ов показывают ROIC в диапазоне 3-4,5, и это становится реальным, весомым аргументом на годовом ревью зарплат.

Какие нетривиальные домены вы рекомендуете для ротации senior-ов?

По нашему опыту, отлично работают четыре направления. Первое – архитектура данных. У клиента, например, это был переход на data lakehouse с Iceberg-таблицами, и senior-ы с большим интересом погрузились в эту новую модель. Второе – performance engineering, то есть низкоуровневая оптимизация конкретных bottleneck в Go/Rust. Тут AI помогает очень мало, а сам анализ через perf и pprof безумно увлекателен. Третье – security engineering: поиск уязвимостей через codeql, fuzz-тесты и различные pentest-методики. И четвёртое – платформенная разработка: создание Kubernetes-операторов и собственных controllers, где требуется глубокое понимание системного дизайна, намного выше прикладной разработки.

Сколько занимает разворот текучки и сколько это стоит?

В продуктовой компании клиента, где было 42 РМ, вся работа заняла 18 месяцев. Из них 3 месяца ушло на сбор данных и анализ MS-360, ещё 2 месяца – на разработку фреймворка и его согласование с CEO и CTO. Остальные 13 месяцев мы постепенно внедряли его, работая с 5 senior-ами параллельно. В итоге текучка senior-ов упала с 47% (это 8 уходов из 17 за предыдущий год) до 12% (всего 2 ухода из 17). Стоимость моей работы составила 480 000 ₽ за весь проект, включая 12 моих рабочих дней и 24 часа консультаций с HR-партнёром. И самое приятное: проект окупился всего за 4 месяца! Ведь один уход senior-а с поиском замены стоит компании от 1,5 до 2,5 миллиона рублей, а мы предотвратили целых 6 уходов.

Итог

AI не делает senior-разработчиков ненужными — он перераспределяет интересные задачи в пользу middle и оставляет senior с ощущением «я больше не нужен». Лечится это не деньгами, а тремя вещами: проектами, которые AI не выучил; ROIC-учётом менторства; ротацией в нетривиальные домены. По нашему опыту, текучка senior-сегмента падает с 47% до 12% за 18 месяцев — и это окупает работу за 4 месяца.