Практическая работа: анализ направлений применения искусственного интеллекта выявил скрытую причину увольнений

Автор материала, инженерный руководитель с опытом создания ИИ-платформ для более чем 100 миллионов пользователей, описывает проблему, которую он называет «невидимый валидатор». Суть: ИИ-инструменты оптимизированы на создание кода, но не на учёт комплаенс-профиля (набора регуляторных требований, которым обязан соответствовать продукт), устаревшей архитектуры или устных договорённостей внутри команды. Этот контекст держат именно middle-инженеры, и именно они платят за ускорение остальных.

Как выглядит проблема на практике?

В команде автора за один квартал релизы стали выходить на 40% быстрее, код-ревью (проверка кода коллегами) закрывались за часы вместо дней. Руководство считало внедрение ИИ успехом.

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

Пока остальные радовались скорости, эти инженеры:

• Исправляли ошибки за ИИ-ассистентами
• Добавляли контекст, который модели упустили
• Проверяли, выдержит ли сгенерированный код продакшен в регулируемой среде

Ничего из этого не отражалось ни в спринт-досках (визуальных досках задач), ни в оценке эффективности, ни в обсуждениях повышения.

Почему нагрузка падает именно на middle-инженеров?

ИИ-инструменты помогают junior-инженерам чувствовать себя продуктивными с первого дня. Senior-инженеры проходят путь от наброска до прототипа ещё до обеда. Но кто-то должен ловить пробелы в безопасности, комплаенс-риски и архитектурные противоречия.

У middle-инженеров уже достаточно опыта, чтобы заметить проблему, но ещё нет позиции, чтобы переложить проверку на кого-то другого. Объём результата, за который им реально засчитывают работу, при этом уменьшается.

Конкретный случай из команды автора: инженер уровня L5 потратила почти три дня, чтобы остановить ИИ-сгенерированный сценарий аутентификации (процедуры подтверждения личности пользователя), который создал бы пробелы в журнале аудита регулируемой системы. Она поймала комплаенс-риск, из-за которого мог запуститься формальный процесс проверки. В её спринте за ту неделю было ноль сторипоинтов (единиц учёта работы в Agile).

Что понадобится

• Доступ к метрикам спринтов вашей команды за последние два-три месяца
• Список уволившихся или подавших заявления инженеров с разбивкой по уровню
• 30 минут на анализ очереди код-ревью и динамики инцидентов в продакшене
• Готовность провести честный разговор с middle-инженерами один на один

Пошаговая инструкция

1. Проверьте тревожные сигналы. Сопоставьте три показателя: скорость очереди код-ревью, число инцидентов в продакшене за последние 8 недель и активность middle-инженеров на архитектурных обсуждениях. Если ревью движутся быстрее, но инциденты растут, а middle-инженеры замолчали на встречах, проблема «невидимого валидатора» уже есть.

2. Введите роль AI Quality Gate в каждый спринт. Выделите явную роль проверяющего ИИ-сгенерированный код. Это не дополнительная обязанность, а отдельная задача с выделенными сторипоинтами. Автор рекомендует закладывать её в ёмкость спринта как обязательную строку.

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

4. Учитывайте эту работу при оценке эффективности. Перестройте перфоманс-ревью (оценку результатов работы) так, чтобы обнаружение и устранение комплаенс-рисков, архитектурных ошибок и пробелов безопасности засчитывалось наравне с написанием нового кода.

5. Проведите персональные разговоры с middle-инженерами. Спросите прямо: какую долю времени они тратят на исправление за ИИ? Что из этого не попадает в отчётность? Ответы дадут точную картину скрытой нагрузки.

Кому и что делать прямо сейчас?

Тимлидам и техническим руководителям. Проведите практическую работу: анализ направлений применения искусственного интеллекта в ваших процессах. Посмотрите, где ИИ реально ускоряет работу, а где создаёт скрытую нагрузку. Сопоставьте уход сотрудников с их уровнем: если теряете L4 и L5, а junior- и senior-инженеры остаются, паттерн уже сложился.

Предпринимателям и руководителям в РФ и СНГ. Проблема актуальна независимо от того, какие ИИ-ассистенты использует команда. В российских компаниях внедрение ИИ-помощников идёт активно, но метрики продуктивности почти всегда считают только скорость, не стоимость валидации. Попросите тимлидов посчитать, сколько часов в неделю middle-инженеры тратят на проверку ИИ-кода, и сравните с тем, что отражено в трекере задач.

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

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