В современной разработке 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‑инженеров, как на самом деле выглядит их рабочая неделя.

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

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

Продолжить тему можно на бесплатных открытых уроках:

  • 9 сентября, 20:00. «Как тимлиду распределять ответственность и не становиться узким местом команды». Записаться

  • 22 сентября, 20:00. «Можно ли доверять ИИ‑коду: как находить галлюцинации, уязвимости и устаревшие решения». Записаться

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

Больше открытых уроков сентября смотрите в дайджесте.