Что происходит: джун закрывает задачи, но не понимает сервис
Джун полгода закрывает задачи с AI-агентом. Первый коммит через неделю, первый заметный PR через месяц, за квартал десяток задач, ревью проходит чисто, тесты зелёные, на ретро его хвалят за скорость. Потом брокер падает и восстанавливается, сервис уведомлений начинает слать клиентам дубли, и на разборе выясняется: показать код джун может, а объяснить, что будет, если уведомление уже ушло, а подтверждение сообщения брокеру не дошло, и каким механизмом сервис должен защищаться от повторной отправки, нет. Этот сценарий разобрал Сергей Прощаев, Tech Lead и руководитель направления Java | Kotlin разработки в FinTech & E-commerce, преподаватель OTUS, в статье на Habr (разбор на Habr).
Короткий ответ на главный вопрос: AI-агенты действительно ускоряют закрытие задач, но заодно забирают у новичка ту работу, через которую он строит модель системы. Гипотезы, чтение чужого кода, отладка, восстановление связей между компонентами: всё это агент делает быстрее, и джун просто не проходит этот путь. Метрики поставки при этом выглядят отлично, поэтому деградация навыков всплывает не в спринт-отчёте, а на первом серьёзном инциденте.
Типичное объяснение звучит как «джун попался слабый». Прощаев с ним не согласен: чаще человек нормальный, а сломался процесс, который раньше превращал джуна в мидла почти без плана. Разница принципиальная. Если виноват человек, руководителю остаётся искать другого человека. Если виноват процесс, у руководителя есть шесть конкретных мест, которые можно починить.
Почему метрики поставки не показывают проблему
Скорость закрытия задач, число PR, время до мержа, доля ревью без замечаний: эти метрики удобны, потому что считаются автоматически. Они измеряют выход, а не понимание. Джун с агентом выдаёт нормальный на вид результат, иногда быстрее остальных, и дашборд показывает здоровье процесса.
Провал проявляется в других точках: на разборе инцидента, в отладке незнакомого сбоя, в вопросах «почему сделано именно так» и «что сломается, если это убрать». Скрытые дефекты агентных систем устроены похожим образом: внешние сигналы зелёные, качество результата падает (поведенческие сбои AI-агентов). В случае с джуном такой «тихий сбой» длится месяцами и выглядит как успешный онбординг.
Что именно забирает агент у новичка
Новичок учится на действиях. Сформулировать, что именно сломалось. Придумать гипотезу. Прикинуть, как её проверить и что должно быть в логах. Прочитать код вокруг, восстановить поток сообщений, понять, где проходит граница ответственности сервиса. Агент закрывает каждый из этих шагов одним запросом, и джун получает готовый ответ, минуя когнитивную работу.
Дело не в самом инструменте. В исследовании Anthropic авторы выделили шесть разных паттернов взаимодействия с AI, и три из них предполагают когнитивную вовлечённость: при них результаты обучения сохраняются, даже когда участник пользуется ассистентом (arXiv 2601.20245). Разница между «вырос» и «не вырос» проходит по способу работы, а не по факту наличия агента.
Что говорят данные: исследование Anthropic и отраслевой контекст
В январе 2026 года Anthropic опубликовал рандомизированное исследование. 52 разработчика, в основном джуны с опытом Python больше года, осваивали незнакомую асинхронную библиотеку Trio. Половина работала с AI-ассистентом, половина без него. Скорость и понимание замеряли отдельно (обзор исследования и кейса).
По скорости: группа с ассистентом закончила задачу в среднем на две минуты быстрее, но разница статистически незначима. По пониманию: в тесте сразу после задачи группа с AI набрала 50%, группа без AI 67%. Сильная зависимость от ассистента коррелировала с результатом ниже 40%. Авторы формулируют вывод жёстко: использование AI ухудшает концептуальное понимание, чтение кода и способности к отладке, не давая значительного выигрыша в эффективности в среднем (полный текст исследования). Участники, которые полностью делегировали задачу агенту, показали некоторый рост продуктивности, но заплатили за него обучением библиотеке.
Почему разрыв особенно велик в отладке
Самый большой разрыв между группами был в вопросах на отладку. Логично: отладка требует модели системы и цепочки гипотез. Когда агент выдаёт готовое исправление, джун не тренирует ни то, ни другое. Он тренирует вставку исправления.
Вопрос на разборе инцидента с дублями уведомлений, по сути, тоже вопрос на отладку: что случится, если сообщение уже ушло клиенту, а подтверждение брокеру не дошло, и какой механизм должен остановить повторную отправку. Ответить на него можно только из модели системы: где хранится состояние, кто отвечает за идемпотентность, что будет при повторной доставке.
Что это значит для руководителя
Рост продуктивности с AI не равен росту компетентности. Авторы исследования предупреждают: AI-enhanced productivity is not a shortcut to competence, и ассистента стоит осторожно встраивать в рабочие процессы, особенно в критичных для безопасности областях (arXiv 2601.20245).
Отраслевой контекст показывает разрыв между признанием проблемы и действиями. В LeadDev Engineering Leadership Report 2026 84% опрошенных считают, что AI-инструменты в целом плохо скажутся на джунах. При этом только 4% назвали поддержку развития джунов главным изменением кадровой политики из-за AI. В опросе Augment из 219 руководителей онбординг поменяли 15. Это опросы, а не перепись рынка, но картина понятная: проблему видят, а системно её почти никто не решает. Значит, решение остаётся на уровне тимлида, у которого есть конкретная команда и конкретные джуны.
Ограничения данных стоит держать в голове. Задача в исследовании короткая, тест проводили сразу после неё, выборка небольшая, и переносить результаты на полгода работы в команде напрямую нельзя. Авторы отдельно пишут, что ассистент в чате отличается от агентских инструментов, и ожидают, что у агентов влияние на навыки будет сильнее. Сигнал всё равно достаточно сильный, чтобы перестроить онбординг до первого инцидента, а не после.
Ошибка 1. Измерение роста скоростью
Симптом: джун быстро закрывает задачи, руководитель считает онбординг успешным и закрывает тему. Причина: скорость единственная метрика, которая считается сама и не требует ручной работы. Последствие: деградация навыков не видна до инцидента, а на инциденте выясняется, что разбирать его некому.
Исправление: заменить единственную метрику набором наблюдаемых навыков и добавить понятные пороги допуска к дежурству.
Пять наблюдаемых навыков вместо скорости
Принцип один: навык должен наблюдаться в реальной работе, а не в самооценке и не в чек-листе, который джун заполняет сам себе. Ниже пример набора, который можно адаптировать под свою команду.
- Объясняет устройство сервиса. Рассказывает, из каких компонентов состоит сервис, как ходят сообщения, где точки отказа. Проверяется вопросом на разборе, без подглядывания в код.
- Строит гипотезу о причине сбоя. До обращения к агенту формулирует версию и способ проверки, потом сверяет результат.
- Читает и объясняет чужой код. Проходит по чужому PR и говорит, что тот делает и что сломается при изменении.
- Выбирает механизм защиты от повторной отправки. Понимает, зачем нужна идемпотентность, где хранится ключ, что делать с повторной доставкой.
- Проводит разбор инцидента. Ведёт хронологию, отделяет симптом от причины, формулирует, что поменять в процессе.
Формулировки стоит привязать к своему стеку: в сервисе с очередями один набор, в сервисе без асинхронности другой. Важно, чтобы каждый пункт проверялся в задаче или на разборе, а не в разговоре «как дела».
Два допуска к дежурству как пороги
Пороги удобнее навыков тем, что у них есть последствие. Два допуска выглядят так.
- Первый допуск. Джун дежурит вместе с сеньором: объясняет типовые сбои, строит гипотезу до эскалации, знает, где смотреть логи и метрики. Ошибки допустимы, решения подтверждает наставник.
- Второй допуск. Самостоятельное дежурство, включая инциденты с дублями и повторной отправкой. Условие: джун уже разбирал похожий случай и отвечал на вопросы по механизму защиты, а не только по коду исправления.
Условия допуска должны проверяться в деле. Рабочий формат: имитация инцидента, где сеньор играет роль «сломанного» брокера и задаёт вопросы по ходу. Похожую логику используют при допуске к работе с AIOps-агентом на дежурстве: последнее слово остаётся за инженером, и он должен понимать, какое действие безопасно (разбор дежурства с AIOps-агентом).
Ошибка 2. Старт с задач вместо карты системы
Симптом: джун с первого дня закрывает тикеты, но на вопрос «как устроен сервис» отвечает фрагментами. Причина: онбординг начинается с задач, а модель системы предполагается сама собой, по мере работы. С агентом она не появляется: агент выдаёт правку в файле, а не карту связей между компонентами.
Последствие видно на инциденте: джун не может объяснить, что будет, если уведомление уже ушло, а подтверждение брокеру не дошло. Исправление: карта системы для нового разработчика, которую джун строит сам и защищает перед сеньором.
Что должно быть в карте системы
Карта не обязана быть красивой. Она обязана отвечать на вопросы, которые задают на разборе.
- Компоненты сервиса и их зоны ответственности.
- Потоки сообщений: от постановки в очередь до подтверждения брокеру, с указанием, где сообщение может продублироваться или потеряться.
- Точки отказа и что происходит при каждой.
- Механизмы идемпотентности и защиты от повторной отправки: где хранится ключ, как долго живёт, что будет при повторной доставке.
- Где смотреть состояние: логи, метрики, очереди, таблицы.
Ключевое слово здесь «сам». Если джун получает готовую документацию, он читает её как чужой текст. Когда он восстанавливает карту по коду, логам и вопросам к сеньору, он строит модель системы, а это и есть навык, которого не хватает на инциденте.
Как проверить, что карта усвоена
Проверка идёт вопросами, а не пересказом документа. Что будет, если подтверждение брокеру не дошло? Каким механизмом сервис защищается от повторной отправки? Где узнать, что сообщение уже ушло клиенту? Что сломается, если убрать проверку ключа идемпотентности?
Это те же вопросы, что задают на разборе инцидента с дублями. Если джун отвечает своими словами и показывает на схеме, карта усвоена. Если повторяет формулировки из документа и путается в направлении потока, защита не пройдена и возвращаться к задачам на выпуск рано.
Ошибка 3. Передача отладки агенту
Симптом: при сбое джун сразу отправляет ошибку и контекст агенту и вставляет предложенное исправление. Причина простая: так быстрее, агент под рукой, результат проходит тесты. Последствие тяжелее, чем кажется: в исследовании Anthropic самый большой разрыв между группами был именно в вопросах на отладку.
Запрещать агента бессмысленно, и разбор предлагает другое. Задача в том, чтобы вернуть джуну первый шаг, на котором рождается понимание. Этот шаг делается до запроса к агенту.
Карточка гипотезы: что в ней должно быть
Карточка гипотезы это короткая форма, которую джун заполняет перед обращением к агенту. Пример набора полей.
- Симптом. Что наблюдается: дубли уведомлений после восстановления брокера, ошибка в логах, рост задержки.
- Предполагаемая причина. Одна-две версии своими словами.
- Как проверить. Какие логи, метрики или состояние очереди посмотреть.
- Что ожидаю увидеть. Признак, который подтвердит или опровергнет версию.
- Что показала проверка. Факт, а не пересказ ответа агента.
- Совпало ли с ответом агента. Где гипотеза разошлась и почему.
Пример по кейсу с дублями. Гипотеза: подтверждение брокеру не дошло, сообщение вернулось в очередь и было обработано повторно. Проверка: состояние очереди, счётчик повторов, логи обработчика, наличие ключа идемпотентности. Ожидание: повторная доставка того же сообщения с тем же ключом. Если факт совпал, джун сам дошёл до механизма защиты. Если нет, он всё равно получил модель, в которую агентское исправление можно вписать осмысленно.
Как встроить карточку в процесс
Карточка работает в двух местах: в задачах на обучение и на разборе инцидентов. Бюрократии она не требует, пяти-шести строк достаточно, форма живёт в тикете или в заметке.
Смысл появляется, когда карточки видит наставник. На еженедельном разборе решений по PR видно, была ли гипотеза до агента или джун сначала получил ответ и потом подогнал объяснение. Разница между этими сценариями и есть разница между обучением и имитацией обучения. Паттерн с когнитивной вовлечённостью сохраняет результат, полное делегирование даёт продуктивность за счёт навыка.
Ошибка 4. Нет разделения задач на выпуск и обучение
Симптом: все задачи в спринте одинаковые, джун учится только на выпуске. Причина: отдельного типа задач на обучение нет, значит обучение не планируется и не измеряется. Последствие: под давлением сроков учебные задачи исчезают первыми, потому что их никто не считает работой.
Исправление: два типа задач и разные критерии успеха. Задача на выпуск оценивается по скорости и качеству, агент в ней разрешён. Задача на обучение оценивается по навыку, и её результат не обязан ехать в прод.
Шаблон задачи на обучение
Четырёх полей достаточно, чтобы задача не превратилась в обычный тикет.
- Какой навык тренируется. Один из пяти наблюдаемых, своими словами.
- Что джун делает сам. Например, восстанавливает карту модуля уведомлений или разбирает инцидент с карточкой гипотезы и без обращения к агенту.
- Критерий готовности. Наблюдаемое действие: защита карты перед сеньором, ответы на вопросы по механизму повторной отправки, разбор инцидента с хронологией.
- Кто проверяет. Конкретный сеньор и конкретный формат проверки.
Пример: восстановить карту системы для модуля уведомлений и защитить её перед сеньором, включая ответ на вопрос, что будет при потере подтверждения брокеру. В прод эта задача не идёт, но она напрямую снижает время разбора следующего инцидента.
Как делить поток задач
Пропорция зависит от команды, правило простое: задачи на обучение планируются заранее и не растворяются в выпуске. Практика, которая работает: после крупной задачи на выпуск ставится задача на обучение, чтобы навык не деградировал. Учебная задача не должна занимать весь спринт, иначе джун выпадает из продукта и теряет контекст.
Когда агент числится в трекере полноправным исполнителем, граница стирается ещё быстрее: учебная задача выглядит как обычный тикет и уходит агенту по привычке. В разборе про виртуальных исполнителей в Jira видно, как задачи распределяются между людьми и агентами и почему ревью остаётся за человеком. Там же честное ограничение: стоимость принятой задачи пока не измерена.
Ошибка 5. Код-ревью как единственное наставничество
Симптом: единственный контакт сеньора с джуном это комментарии в PR. Причина: код-ревью кажется достаточным, оно встроено в процесс и не требует отдельного времени. Последствие: в PR виден результат, но не виден ход мысли. Когда код написан агентом, сеньор ревьюит текст, который джун сам не до конца понимает, и оба делают вид, что это нормально.
Исправление: еженедельный разбор решений по PR, отдельный от ревью.
Еженедельный разбор решений по PR
Формат: раз в неделю, 45-60 минут, несколько PR за встречу. Разбираются решения: почему сделано так, какие были альтернативы, где была гипотеза, что показала проверка, что случится при отказе зависимости.
Стиль и оформление на этой встрече не обсуждаются. Разбор стиля остаётся в PR, где для него есть место и контекст. На встрече видно, обращался ли джун к агенту до гипотезы или после, и это главный сигнал.
Что разбирать, а что оставить в PR
В PR: корректность, граничные случаи, тесты, читаемость. На разборе: решения, гипотезы, альтернативы, понимание системы. Это разные задачи, и смешивать их значит терять обе: в потоке комментариев разговор о модели системы не живёт.
Побочный эффект, который стоит учитывать: на разборе регулярно всплывают вопросы, которых нет в PR. Например, почему ключ идемпотентности строится именно так и что будет при смене формата сообщения. Для джуна это дешёвый способ увидеть границы своего понимания до инцидента.
Ошибка 6. Наставничество на свободном времени сеньоров
Симптом: наставничество происходит, если у сеньора осталось время. Причина: время на наставничество не планируется, оно берётся из остатка. Последствие предсказуемо: под давлением выпуска наставничество исчезает первым, а вместе с ним исчезают и остальные исправления, потому что карту системы нужно кому-то защищать, карточки гипотез нужно кому-то читать, разбор PR нужно кому-то вести.
Как заложить час в неделю
Час фиксируется в календаре сеньора и в его плане, как любая другая работа. Не «найдём время», а конкретный слот, который не двигается из-за релиза. На этот час опираются еженедельный разбор решений по PR и защита карты системы.
Час в неделю это минимум, ниже которого конструкция не держится. Прощаев отмечает это прямо: нужен хотя бы один сеньор с часом в неделю на наставничество (разбор на Habr). Если такого часа нет, сначала решается вопрос с временем, потом всё остальное, иначе исправления останутся на бумаге.
Границы применимости: когда подход не окупается
Подход не универсальный, и это стоит сказать до внедрения.
Кому подход подходит
Командам с джунами и долгим горизонтом: человек остаётся в команде год и больше, значит вложения в навыки успевают вернуться. Продуктовым командам, где инциденты с дублями, повторной отправкой и потерей сообщений реальны и дороги: там понимание системы окупается на первом же разборе. Командам, где есть хотя бы один сеньор, готовый выделить час в неделю.
Кому подход не нужен
Для мидлов вложения обычно не окупаются: модель системы у них уже есть, и карта вместе с карточкой гипотезы превращается в лишний ритуал. Для коротких проектов тоже: онбординг не успевает вернуть вложенное время. Если сеньора с выделенным часом нет, начинать с карточек и шаблонов бессмысленно, они быстро станут формальностью.
Как внедрить исправления: порядок действий
Порядок не случайный. Без выделенного времени сеньора остальные исправления не удержатся, поэтому начинать стоит с него.
- Заложить час сеньора в неделю и провести первый разбор решений по PR.
- Заменить метрику скорости на пять наблюдаемых навыков и два допуска к дежурству.
- Ввести карту системы для нового разработчика с защитой перед сеньором.
- Ввести карточку гипотезы до обращения к агенту.
- Добавить шаблон задачи на обучение и разделить поток на задачи на обучение и задачи на выпуск.
- Сделать еженедельный разбор решений по PR регулярным.
С чего начать на этой неделе
Минимальный шаг: заложить час сеньора в неделю и провести первый разбор решений по PR по двум-трём уже смерженным PR. Дальше ввести карточку гипотезы в одной задаче на обучение, не во всём спринте. Пытаться запустить все шесть исправлений сразу значит получить шесть формальностей.
Как понять, что стало лучше
Критерий не в скорости закрытия задач, а в наблюдаемых действиях. Джун объясняет устройство сервиса своими словами. Строит гипотезу до обращения к агенту и потом сверяет её с ответом. Отвечает на вопросы разбора инцидента про повторную отправку и подтверждение брокеру. Защищает карту системы без подглядывания в документ.
Числовых порогов сверх того, что даёт исследование, здесь нет и быть не может: каждая команда задаёт свои. Важно другое: метрика скорости перестаёт быть единственным сигналом, а первый серьёзный инцидент перестаёт быть первой проверкой компетенции джуна.