AI-агенты ломают онбординг джунов: 6 ошибок руководителя в 2026

Разбор новинки простыми словами: что это, кому нужно и брать ли.

Скорость закрытия задач с AI-агентом перестала быть сигналом роста инженера — бизнесу нужны новые критерии допуска к самостоятельной работе, иначе пробел вскроется на первом инциденте.

Связанные услуги: каталог, AI Boost Team, стать клиентом.

Что случилось

Джун приходит в команду. Через неделю первый коммит. Через месяц заметный PR. За квартал десяток закрытых задач, ревью чистое, тесты зелёные, на ретро хвалят за скорость. А потом падает брокер, сервис уведомлений начинает слать клиентам дубли, и на разборе выясняется: обработку событий в этом сервисе менял он. Точнее, агент. Джун проверил код и тесты. Показать код может. Объяснить, что будет, если уведомление уже ушло, а подтверждение брокеру не дошло, и каким механизмом сервис защищается от повторной отправки, — нет.

Это не гипотетическая страшилка. Это сценарий, который Сергей Прощаев, Tech Lead Java/Kotlin в FinTech & E-commerce и преподаватель OTUS, разбирает в блоге компании на Хабре. И разбор этот интересен не описанием боли, а тем, что он вскрывает: привычная связка «быстро закрывает задачи → значит, растёт» перестала работать. Агент разорвал её, а руководители этого не заметили.

Джун закрывает задачи быстрее, PR проходят ревью, метрики радуют руководителя. Но на первом серьёзном инциденте выясняется, что разработчик с трудом понимает устройство сервиса, над которым работал несколько месяцев.

Для собственника и руководителя SMB это не абстракция про «больших ребят из финтеха». Если у вас в команде есть хотя бы один новичок и хотя бы один AI-ассистент в IDE — вы уже внутри этой истории. Вопрос только в том, когда вскроется.

Что это меняет по сути

Раньше онбординг джуна работал почти без плана. Новичку давали простые задачи, и эти задачи сами по себе строили у него карту системы. Чтобы поправить эндпоинт, надо было пройти запрос насквозь: от входного API до базы, через все слои, со всеми зависимостями. Медленно, больно, но по дороге человек волей-неволей понимал, как сервис устроен. Понимание было побочным продуктом скорости.

Агент проходит этот маршрут сам. За час. Джун получает закрытый тикет и ноль понимания, куда именно он положил код. Через неделю у него пять тикетов в разных углах кодовой базы и пустая карта в голове. Метрики при этом растут.

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

Цифры, которые стоит держать в голове

Проблему видят, но процесс не трогают. В LeadDev Engineering Leadership Report 2026 84% опрошенных руководителей считают, что AI-инструменты в целом плохо скажутся на джунах. При этом только 4% назвали поддержку развития джунов главным изменением своей кадровой политики из-за AI. В опросе Augment из 219 руководителей онбординг поменяли 15. Это опросы, не перепись рынка, но картина одинаковая: тревога есть, действий нет.

Есть эксперимент, который помогает понять механизм. В январе 2026 года Anthropic опубликовал рандомизированное исследование: 52 разработчика, в основном джуны с опытом Python больше года, осваивали незнакомую асинхронную библиотеку Trio. Половина работала с AI-ассистентом, половина без. Группа с ассистентом закончила в среднем на две минуты быстрее, но разница статистически незначима. А вот тест на понимание сразу после задачи показал разрыв.

В тесте на понимание сразу после задачи группа с AI набрала в среднем 50%, группа без AI 67%. Самый большой разрыв был в вопросах на отладку.

Границы результата важные, и их надо назвать честно. Задача короткая, тест сразу после неё, выборка небольшая. Переносить это на полгода работы в команде напрямую нельзя. Авторы сами пишут, что ассистент в чате отличается от агентских инструментов, и ожидают, что у агентов влияние на навыки будет сильнее. То есть 50 против 67 — это, скорее, нижняя граница проблемы, а не верхняя.

Но самое интересное в исследовании — не средние цифры, а разбивка участников с AI по манере работы. В группах с сильной зависимостью от ассистента, где ему отдавали генерацию, отладку или постепенно всю работу, средний балл был ниже 40%. Те, кто задавал концептуальные вопросы или просил объяснить сгенерированный код, набрали 65% и больше. Группы маленькие, от двух до семи человек, причинную связь авторы не утверждают. Но различие важное: результат зависит не от наличия AI как такового, а от того, остаётся ли у разработчика своя интеллектуальная работа.

Шесть ошибок руководителя — коротко

Прощаев разбирает шесть ошибок онбординга в команде с агентами. Полный разбор — в исходной статье, здесь — суть каждой, чтобы вы могли сверить со своей командой.

Две практики в разборе подписаны именами: команда Гаримы Агарвал (пост на LeadDev 8 октября 2026) и доклад Джордано Скальцо (LeadDev, 29 сентября 2026). Критерии готовности, этапы допуска и карточку гипотезы Прощаев предлагает от себя — это его конструкция, не отраслевой стандарт. Относитесь к ней как к рабочей рамке, которую надо примерить к своей команде, а не как к готовому регламенту.

Пять навыков вместо даты в календаре

Вот что предлагается проверять у джуна вместо «прошло три месяца, пора давать самостоятельность»:

1. Проследить один запрос от входного API до базы и до публикации события.
2. Назвать критические зависимости и основные сценарии их отказа.
3. Проверить гипотезу по логам, метрикам и трассировкам.
4. Обосновать своё изменение: какие гарантии оно сохраняет и какие допущения делает.
5. Понять, когда пора звать коллег, и знать, кого именно.

Проверку предлагается разделить на два допуска. Допуск к дежурству под присмотром: базовая диагностика на учебном сценарии, знание runbook и границ своей ответственности. Допуск к самостоятельной работе: навыки показаны на нескольких сценариях и на дежурстве под присмотром, включая вовремя поднятую эскалацию. Боевой инцидент — тоже хороший сигнал, но ждать его как экзамена нельзя: в одной команде он случится через неделю, в другой через полгода.

Есть быстрая проверка из практики Агарвал, которую можно провести завтра. Попросите джуна без ноутбука рассказать, как устроен сервис, в котором он три месяца назад делал фичу. Если звучит описание одной функции, а не системы — у вас пробел, который метрики скорости не покажут. Никаких инструментов, никакого бюджета, десять минут разговора.

Как применить: онбординг начинается с карты, а не с задачи

Главное изменение — перевернуть порядок. Не «простая задачка, чтобы втянуться», а исследование системы по конкретному маршруту. Агарвал отводит на это первые две недели без AI-инструментов. Прощаев не делает запрет обязательным: важнее, чтобы новичок сначала построил свою схему и записал вопросы, а уже потом проверял гипотезы по документации и с агентом.

Маршрут для первого исследования выглядит так. Пройти один запрос от входного API до записи в базу и публикации события. Найти границы транзакций и понять, какие гарантии даёт каждый этап. Разобрать поведение при тайм-ауте зависимого API, повторной доставке сообщения и недоступности брокера. Понять, по каким логам и метрикам задержку отличить от потери сообщения. Найти runbook, владельцев компонентов и правила эскалации.

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

Где подвох

Соблазн простой: запретить агента на испытательный срок и жить как раньше. Это плохая идея по двум причинам. Первая — вы растите инженера, который не умеет работать с инструментом, а через год он будет нужен команде именно с ним. Вторая — запрет не решает задачу, а откладывает её: как только агент вернётся, карта снова начнёт не строиться, если процесс не изменён.

Второй подвох — принять исследование Anthropic за доказательство. Это не доказательство, а сигнал. Выборка маленькая, задача короткая, тест сразу после неё. Авторы сами оговаривают границы. Строить на этом кадровую политику целиком нельзя. Но игнорировать разрыв в 17 процентных пунктов и провал в вопросах на отладку — тоже.

Третий подвох — превратить пять навыков в ещё одну формальную анкету. Как только допуск становится галочкой в HR-системе, он перестаёт измерять понимание. Проверка работает, пока это разговор о системе, а не тест с вариантами ответов.

Вердикт за 30 секунд

• Скорость больше не равна росту. Cycle time и время до первого PR измеряют работу агента, а не понимание джуна. Перестаньте смотреть на них как на сигнал готовности.
• Онбординг начинайте с карты системы. Первые две недели — маршрут запроса насквозь, границы транзакций, поведение при сбоях. Задачи придут после, и они лягут на карту, а не в пустоту.
• Два допуска вместо одной даты. К дежурству под присмотром и к самостоятельной работе — по пяти наблюдаемым навыкам. Проверка — разговор, а не анкета.

Проблему видят 84% руководителей, а процесс поменяли единицы. Разрыв между тревогой и действием — это и есть место, где ваша команда потеряет джуна или получит инцидент. Выбор пока за вами.

FAQ

Это касается только больших команд?

Нет. Механизм тот же, что в команде из трёх человек, что в команде из тридцати: агент обходит маршрут, который раньше строил карту у новичка. В маленькой команде цена ошибки выше — сеньоров меньше, забирать сложное себе некому.

Значит, надо запретить AI-ассистенты джунам?

Нет. Исследование показывает другое: результат зависит от манеры работы. Группы, где ассистенту отдавали генерацию и отладку целиком, набрали ниже 40%. Группы, где задавали концептуальные вопросы и просили объяснить сгенерированный код, — 65% и выше. Дело не в наличии инструмента, а в том, остаётся ли у разработчика своя интеллектуальная работа.

Сколько ждать, прежде чем давать самостоятельность?

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

Что проверить прямо сейчас?

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

Что делать на этой неделе

Три шага, которые не требуют бюджета и согласований. Первое — проведите ту самую десятиминутную проверку с каждым джуном, у кого в работе есть агент. Второе — перепишите план онбординга следующего новичка: первые две недели на карту системы, а не на тикеты. Третье — уберите cycle time из отчёта о росте джуна и замените его на разговор по пяти навыкам.

Если после первой проверки окажется, что карта пустая у половины команды — вы уже знаете, где искать проблему. И знаете, что она вскроется не на ретро, а на инциденте. Успеть до него — ваша задача как руководителя.