Кто платит за AI-продуктивность: почему выгорают middle-инженеры

В современной разработке AI-ассистенты для кодинга создали кризис, о котором никто не говорит. Junior-инженеры работают быстрее, чем когда-либо. Senior-инженеры проектируют архитектуру с меньшими усилиями. А что происходит с вашими middle-инженерами?

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

Я называю это проблемой «невидимого валидатора». Опираясь на опыт создания AI-платформ, которые обслуживали более 100 миллионов пользователей на enterprise-масштабе, в этой статье я разберу, как ваши лучшие инженеры субсидируют продуктивность всех остальных… и что сделать, пока они не ушли.

Exit-интервью, к которым я не был готов

В прошлом квартале цифры выглядели отлично. Мы выпускали релизы на 40% быстрее. Код-ревью, которые раньше занимали дни, теперь закрывались за часы. Руководство было в восторге. На нашу команду ссылались как на доказательство, что внедрение искусственного интеллекта работает.

А потом трое моих лучших middle-инженеров уволились. Все — с разницей в шесть–восемь недель.

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

«Я больше не могу выдерживать это давление: постоянно доводить всё до нормального состояния — и не получать за это никакого признания».

Эта фраза меня остановила и заставила очень серьезно задуматься.

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

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

Это не уникальная история моей команды. Исследование GitLab показало: хотя подавляющее большинство разработчиков сообщили, что AI-инструменты повысили продуктивность, заметная часть указала на проблемы с качеством кода и нагрузкой от ревью, которая пришла вместе с этим. Выигрыш в скорости был реальным. Скрытая цена — тоже.

Почему эта нагрузка ложится на middle-инженеров

Как мы все уже понимаем, AI-инструменты действительно помогают. Junior-инженеры чувствуют себя продуктивными с первого дня. Senior-инженеры успевают пройти путь от наброска на доске до рабочего прототипа еще до обеда. Но кто-то все равно должен ловить пробелы в безопасности, compliance-риски и архитектурные противоречия, спрятанные в годах неформального знания команды.

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

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

В моей команде одна инженер уровня L5 потратила почти три дня на то, чтобы остановить AI-сгенерированный сценарий аутентификации, который создал бы пробелы в журнале аудита в регулируемой системе. Она поймала compliance-риск, из-за которого мог запуститься формальный процесс проверки. Когда я потом посмотрел на ее спринт за ту неделю, у нее было ноль сторипоинтов, которыми можно было бы это показать.

Это не личная, а структурная проблема. AI-инструменты оптимизированы на создание результата. Они не оптимизированы под ваш compliance-профиль, ваш стареющий service mesh или недокументированную договоренность, которую ваша команда несколько лет назад заключила с зависимостью ниже по цепочке. Этот контекст держат middle-инженеры.

Когда AI генерирует код на скорости, кто-то должен закрывать разрыв между тем, что выдала модель, и тем, что реально нужно вашей системе. Сейчас эта работа невидима, и она снова и снова падает на людей, которым сложнее всего сказать «нет».

Тревожные признаки, которые у всех на виду

Сигналы можно заметить, если на них обращать внимание. Middle-инженеры замолкают на встречах. Не потому, что потеряли вовлеченность, а потому что вымотались. Архитектурные обсуждения становятся бинарными: junior-инженеры задают вопросы, senior-инженеры принимают решения, а люди между ними перестают участвовать. На это молчание стоит обратить внимание.

Очереди код-ревью движутся быстрее, но через несколько недель начинают понемногу расти инциденты в продакшене. Это отложенный эффект. Работа по валидации, которая раньше была явной — медленное ревью, живое обсуждение, — становится невидимой. По очереди ревью кажется, что все в порядке. Уровень дефектов говорит об обратном.

Вы начинаете терять инженеров уровней L4 и L5, а junior- и senior-инженеры остаются. Этот паттерн оттока говорит больше всего. Junior-инженеры получают от AI-инструментов больше рычагов. Senior-инженеров эти инструменты разблокируют. А middle-инженеры забирают на себя дополнительную нагрузку и за тех, и за других — без признания и без возможностей, как у senior-разработчиков, переложить хотя бы часть этой работы.

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

4 изменения, которые делают невидимую работу видимой

Решение не в том, чтобы замедлить внедрение AI. Решение — перестать делать вид, что контроль достается бесплатно.

1. Явно закладывайте валидацию AI в емкость спринта

Мы ввели в каждом спринте отдельную роль AI Quality Gate — явно назначенную ответственность, которую отслеживали как любую другую. Это была не побочная задача. Не что-то, что «и так кто-нибудь сделает», а нормально спланированная работа. Одно это изменение поменяло то, как команда говорила об этой нагрузке. Когда у валидации есть место в спринте, у нее появляется ценность.

2. Измеряйте не только то, что инженеры выпускают, но и то, что они предотвращают

Метрики velocity считают результат. Они не считают инцидент в продакшене, который не случился, или три дня, которые инженер потратил на то, чтобы AI-сгенерированный сервис не начал незаметно портить данные ниже по цепочке. Если добавить в отслеживаемые метрики показатель предотвращения дефектов и тегировать AI-сгенерированный код в репозиториях, вы получите более ясную картину того, где концентрируются трудозатраты на ревью.

3. Перестройте код-ревью как передачу знаний

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

4. Осознанно ротируйте работу по валидации

Если ошибки AI всегда ловят одни и те же инженеры, это проблема распределения нагрузки, а не таланта. Ротация роли Quality Gate делает эту работу видимой для senior-инженеров и руководства и не дает ей тихо накапливаться на одних людях, как это случилось в моей команде.

AI-продуктивность и выгорание инженеров

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

AI не устранил человеческое суждение, но перераспределил нагрузку. И большая часть этого веса легла на middle-инженеров, которым редко засчитывают сам факт, что они ее несут.

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

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

Возможно, вас удивит то, чего вы до сих пор не измеряли.

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

• 16 июля, 20:00. «Профессия тестировщика в эпоху ИИ — угроза потери работы или суперсила?». Записаться

• 21 июля, 20:00. «Разработка ИИ-приложений с Claude Code». Записаться

• 22 июля, 20:00. «Как CTO управляет неопределённостью: оценки, планы и ожидания бизнеса». Записаться