Джун закрывает задачи с агентом, но спотыкается на разборе инцидента

Знакомая картина. Новичок пришёл в команду полгода назад. Первый коммит через неделю, первый заметный PR через месяц, за квартал закрыт десяток задач. Ревью проходит чисто, тесты зелёные, на ретро его хвалят за скорость.

А потом после сбоя и восстановления брокера сервис уведомлений начинает слать клиентам дубли. На разборе выясняется, что обработку событий в этом сервисе недавно менял он, точнее, агент, а джун проверил код и тесты.

Показать код он может. Объяснить, что будет, если уведомление уже ушло, а подтверждение сообщения брокеру не дошло, и каким механизмом сервис должен защищаться от повторной отправки, нет.

Типичное объяснение звучит так: «джун попался слабый». Я не согласен с таким объяснением. Чаще всего человек нормальный, а сломался процесс, который раньше превращал джуна в мидла почти без плана.

Почему это стало заметно именно сейчас

Опасения широко распространены среди руководителей. В отчёте LeadDev Engineering Leadership Report 2026 84% опрошенных считают, что AI‑инструменты в целом плохо скажутся на джунах.

При этом только 4% назвали поддержку развития джунов главным изменением своей кадровой политики из‑за AI. В опросе Augment, поставщика AI‑инструментов, из 219 руководителей онбординг поменяли 15. Это опросы, а не перепись рынка, но картина одна: проблему видят, а процесс не трогают.

Есть эксперимент, который помогает понять один из возможных механизмов.

В январе 2026 года Anthropic опубликовал опытом ^[2] Python больше года, осваивали незнакомую асинхронную библиотеку Trio.

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

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

Для меня интереснее другое наблюдение. Участников с AI авторы разбили на группы по манере работы. В группах с сильной зависимостью от AI, где ассистенту отдавали генерацию, отладку или постепенно всю работу, средний балл был ниже 40%.

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

Это не доказательство, но различие важное: результат зависит не только от наличия AI, но и от того, остаётся ли у разработчика своя интеллектуальная работа.

Ниже шесть ошибок, которые чаще всего прячутся в онбординге команды с агентами.

Часть исправлений опирается на опыт команды Гаримы Агарвал, о котором она написала на LeadDev 8 октября 2026 года, её историю расскажу ниже. Каждая её практика подписана её именем. Критерии готовности, этапы допуска к дежурству и карточку гипотезы предлагаю я.

Ошибка 1. Мерить рост джуна скоростью

Симптом. В отчёте по новичку стоят закрытые задачи, время до первого PR, cycle time (здесь это время от взятия задачи в работу до выкладки). Все числа растут, руководитель доволен.

Причина. Эти метрики показывают скорость поставки, но сами по себе не измеряют понимание системы. Раньше быстро закрыть задачу без понимания было трудно, и метрики косвенно говорили и о росте. Агент эту связь ослабил.

Последствия. Пробел вскрывается в самый дорогой момент, на инциденте. Сеньоры замечают, что джуну нельзя отдать ничего, где нужно решение, и забирают сложное себе.

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

Я бы проверял пять:

1. Проследить один запрос от входного API до базы и до публикации события.

2. Назвать критические зависимости и основные сценарии их отказа.

3. Проверить гипотезу по логам, метрикам и трассировкам.

4. Обосновать своё изменение: какие гарантии оно сохраняет и какие допущения делает.

5. Понять, когда пора звать коллег, и знать, кого.

Проверку я бы разделил на два допуска.

• Допуск к дежурству под присмотром: базовая диагностика на учебном сценарии, знание runbook и границ своей ответственности.

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

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

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

Ошибка 2. Начинать онбординг с задач, а не с карты системы

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

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

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

Исправление. Начать с исследования системы по конкретному маршруту. Агарвал отводит на это первые две недели без AI‑инструментов.

Я бы не делал запрет обязательным: важнее, чтобы новичок сначала построил свою схему и записал вопросы, а уже потом проверял гипотезы по документации и с агентом.

Маршрут такой:

1. Пройти один запрос от входного API до записи в базу и публикации события.

2. Найти границы транзакций и понять, какие гарантии даёт каждый этап.

3. Разобрать поведение ^[3] при тайм‑ауте зависимого API, повторной доставке сообщения и недоступности брокера.

4. Понять, по каким логам и метрикам задержку отличить от потери сообщения.

5. Найти runbook, владельцев компонентов и правила эскалации.

Ответы наставник обсуждает в разговоре, а не проверяет как контрольную.

Схема ниже показывает, как части онбординга раскладываются по первым месяцам (рис. 2).

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

Ошибка 3. Отдать отладку агенту

Симптом. Упал тест, джун копирует ошибку ^[5] в чат агента, получает исправление, тест зелёный. Повторяется по несколько раз за задачу.

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

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

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

Джордано Скальцо в анонсе доклада на LeadDev от 29.09.2026 предлагает похожие упражнения: сессии без AI, «объясни, что сделала машина» и задания «сломай это».

Мой вариант для начала: в задаче на обучение джун заполняет короткую карточку до того, как отдать ошибку агенту.

<!-- Карточка гипотезы до обращения к агенту (markdown) -->
Что наблюдаю: тест падает на втором вызове обработчика
Предполагаемая причина: событие обрабатывается повторно
Что за это говорит: в логе два одинаковых id сообщения
Как проверю: тест с повторной доставкой и трассировка

После этого ответ агента сравнивается с карточкой, и расхождение обсуждается на разборе решений (о нём в ошибке 5).

Ошибка 4. Не разделять задачи на выпуск и задачи на обучение

Симптом. Все задачи новичка устроены одинаково: взять тикет, закрыть быстро, агент разрешён. Или наоборот: агенты запрещены первые месяцы целиком.

Причина. У задачи в онбординге две цели, а критерий успеха один. Когда цель «выпустить», агент правильно ускоряет работу. Когда цель «разобраться», он забирает ту часть работы, на которой человек учится.

Последствия. Запрет отрезает новичка от инструмента, с которым он будет работать всю карьеру, и выглядит как наказание. Разрешение без правил даёт быстрого джуна без модели системы.

Исправление. Назвать два вида задач честно и с первого дня. Агарвал делит их на задачи на выпуск и задачи на обучение: во втором случае джун сначала пробует сам, потом решает с агентом и пишет короткий абзац о том, чем подход агента отличился и почему. По её словам, команда начинает с соотношения 50 на 50 и к третьему месяцу выходит на 80% задач на выпуск.

От себя добавлю: тип задачи не определяет, насколько агенту можно доверять. В задаче на выпуск агент работает в тех же рамках безопасности, тестов и ревью, что и любой код. В задаче на обучение фиксируется, какому навыку учимся и как поймём, что научились:

# Шаблон задачи на обучение (yaml), значения иллюстративные
type: learning
learning_goal: "Разобраться в обработке повторной доставки события"
practice:
  - "Описать текущий путь события"
  - "Сформулировать гипотезу для повторной доставки"
  - "Проверить гипотезу тестом или трассировкой"
ai_usage: "сначала своя попытка, ответ агента проверяется"
acceptance:
  - "Объяснено, где и почему возможна повторная обработка"
  - "Описаны гарантии и ограничения выбранного механизма идемпотентности"
review: "разбор решений с наставником, 15 минут"

Мне нравится в этом подходе одно: ограничение объяснено. Джуны сопротивляются не правилам, а правилам без объяснения.

Ошибка 5. Оставить код‑ревью единственным местом наставничества

Симптом. Наставник честно ревьюит каждый PR новичка, комментариев почти нет, всё одобряется.

Причина. Ревью проверяет предложенное изменение, но не измеряет, понимает ли автор систему и сможет ли разобрать её отказ. В PR, собранном с агентом, эти две вещи особенно легко спутать: изменение соответствует требованиям, а автор не знает, на какие допущения оно опирается и что будет при отказе соседнего компонента.

Последствия. Наставник уверен, что учит, а джун уверен, что научился. Оба узнают правду одновременно, на первом сложном баге.

Исправление. Добавить к ревью разбор решений отдельно от проверки диффа. У Агарвал это раз в неделю: джун берёт свой влитый PR и проводит по нему наставника, но разбирает не код, а решения. Вопросы удобно держать под рукой:

<!-- Разбор решений по PR, 15 минут (markdown) -->
1. Почему этот метод здесь, а не в сервисном слое?
2. Какое допущение код делает о вышестоящем API?
3. Что сломается, если поменять время жизни кэша?
4. Какой вариант предлагал агент и почему ты его принял или отверг?
5. Как ты поймёшь в проде, что эта часть работает неправильно?

Побочный эффект важнее основного: когда решения придётся объяснять вслух, джун начинает спрашивать у агента компромиссы между вариантами, а не только готовый код.

Ошибка 6. Строить онбординг на свободном времени сеньоров

Симптом. Наставник назначен, но наставничество в его задачах не стоит. Разборы переносятся, потому что горит релиз.

Причина. Раньше значительную часть пути джун проходил сам, на собственных попытках и ошибках, и наставник был нужен эпизодически. Теперь эту часть забирает агент, и учебную практику надо создавать специально. Это работа, и у неё есть цена.

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

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

История: 14 фич и ни одной модели системы

Команда Агарвал полгода работала с обязательными AI‑инструментами. Скорость выросла, cycle time упал, новички делали первые значимые коммиты за недели. Через четыре месяца джуна позвали на инцидент с гонкой в сервисе обработки заказов.

Двумя месяцами раньше он писал фичу в этом сервисе и не знал, с чего начать. Тогда она и задала джунам вопрос про устройство сервиса без ноутбука. Её итог: 14 фич выпущено, ни одной модели системы не построено.

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

Но заметьте: AI‑инструменты никто не отменял. Поменяли процесс вокруг них.

Схема ниже сравнивает три цикла роста джуна: прежний, с агентом без изменений в онбординге и с агентом в новом онбординге (рис. 3).

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

Где это не сработает

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

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

Сводная таблица

Чек‑лист на ближайший месяц

1. На встрече один на один задать каждому джуну вопрос про устройство его сервиса без ноутбука.

2. Добавить в шаблон задачи тип «на обучение» с целью и критериями приёмки.

3. Поставить в календарь наставникам еженедельный разбор решений, 15 минут на джуна.

4. Новым людям начинать с маршрута по системе с письменными ответами.

5. Назначить первый ежемесячный разбор прошлого инцидента.

6. Поменять критерий окончания онбординга на пять подтверждённых навыков.

7. Вписать часы наставничества в план спринта.

Вывод

Эта группа ошибок проверяет не джунов, а руководителя: умеет ли он проектировать среду, в которой человек учится.

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

Запрещать агентов я бы не стал. Я бы встроил в работу два места, где без понимания не пройти: собственную попытку и разговор о решениях.

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

AI-агенты ускоряют разработку, но вместе с этим меняют подходы к обучению и развитию инженеров. Как грамотно распределять задачи между человеком и искусственным интеллектом ^[12] и выстраивать работу команды так, чтобы скорость не достигалась за счёт потери экспертизы?

Эти и смежные вопросы разбираем на бесплатных уроках:

• 19 октября в 20:00 — «ИИ-агенты в реальной разработке: что умеют делать вместо вас». Записаться ^[13]

• 20 октября в 19:00 — «Стабильность команды и взаимозаменяемость людей». Записаться ^[14]

Больше вебинаров по разработке, AI и управлению IT-командами собрали в дайджесте ^[15].