Джун после кода: как растить инженеров, когда исполнение уезжает агентам

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

Я разделяю работу на три слоя. Первый — производство артефакта. Второй — закрытие рабочего эпизода от намерения до наблюдаемого результата. Третий — эволюция системы: компромиссы во времени, границы, миграции, инциденты и решения, которые приходится пересматривать через год. Агенты сильнее всего удешевили первый слой. Чем дальше вправо, тем больше результат зависит от знания конкретной системы и качества инженерного контура вокруг модели.010101Разбирал в канале майский whitepaper Google про новый SDLC. Тот же сдвиг там сформулирован короче: десятилетиями интерфейсом разработчика с машиной был синтаксис, а теперь им стало намерение. Мне важно, что намерение по-прежнему формулирует человек.Книжный куб · The New SDLC: от vibe coding к agentic engineering01Разбирал в канале майский whitepaper Google про новый SDLC. Тот же сдвиг там сформулирован короче: десятилетиями интерфейсом разработчика с машиной был синтаксис, а теперь им стало намерение. Мне важно, что намерение по-прежнему формулирует человек.Книжный куб · The New SDLC: от vibe coding к agentic engineering

Рабочая публикация NBER 2026 года показывает это затухание на большой наблюдательной выборке. После последовательного внедрения поколений инструментов вплоть до автономных агентов накопленная оценка дошла до 180% для фиксаций кода, но до 50% для проектов и 30% для выпусков. Это не причинная оценка одного агента и не доказательство качества. Однако форма результата важна: производить изменения стало проще, а провести их через все слабые звенья системы — нет.

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

полезность для команды = принятый результат − проверка − переделка − эксплуатационный риск − стоимость помощи

Это не бухгалтерская формула. Она не предлагает назначать цену каждому вопросу джуна. Она напоминает, что большой выпуск кода может одновременно увеличить очередь у проверяющих. В наблюдательной выборке из 22 953 PR с использованием AI авторы, отнесённые к менее опытным по косвенным признакам, получали в 4,52 раза больше комментариев, имели на 31% более низкую долю принятия, а их изменения оставались открытыми в 5,16 раза дольше. Проекты и задачи различались, поэтому эти данные не доказывают, что AI вызвал такой налог на проверку. Они показывают, почему считать нужно весь рабочий эпизод. В разборе экономики AI-разработки я использовал ту же границу: управленческой единицей должна быть принятая работа, а не дешёвый локальный шаг.

Данные не складываются в удобный лозунг «AI сильнее помогает новичкам» или «опытные всегда извлекают больше». Они складываются в более полезный вывод: эффект зависит от задачи, поколения инструмента, проверяемости результата, знакомости с системой и выбранной метрики.

Самый сильный причинный источник по рабочему выпуску — три полевых эксперимента Cui и коллег 2026 года. Но это раннее автодополнение, а не агент, способный менять репозиторий. Более свежий квазиэксперимент 2026 года в Ant Group нашёл рост выпуска кода примерно на 55% в среднем и на 67% у сотрудников с опытом до года; у старших программистов прирост оказался статистически незначимым. Основной результат там измерен в строках кода; дополнительные метрики подтвердили рост числа завершённых задач, но не измеряли качество и продуктовую ценность. В то же время рецензируемое исследование 2026 года в Science охватило более 30 млн коммитов в открытых Python-проектах на GitHub и показало, что почти весь измеримый прирост выпуска и освоения новых библиотек достался более опытным, хотя менее опытные пользовались AI активнее; для них статистически значимого эффекта не нашли. Эти результаты не надо усреднять до красивой цифры: они показывают, что доступ к модели сам по себе не создаёт компетентность.

Современные агенты дают обнадёживающие, но пока менее надёжные сигналы. В препринте Microsoft 2026 года раннее использование консольных агентов было связано примерно с 24% дополнительными слитыми PR за четыре месяца. Отдельная модель, где инженера сравнивают с его же неделями без агента, показывает у младших инженеров прирост выше среднего — но это уже другая оценка, а не разбивка первой. И картина входа обратная: младшие инженеры пробовали агентов реже старших, а самый крупный эффект — у сотрудников с опытом до года — авторы читают с осторожностью, потому что он смешан с онбордингом. Люди выбирали инструмент сами, а качество и ценность не измерялись. Небольшое контролируемое исследование PACIS 2026 года на 24 разработчиках сократило время задачи в существующей кодовой базе на 61,7% и субъективную нагрузку на 57,4%, но значимого роста корректности не обнаружило.

Доказательство риска для обучения тоже точечное, но прямое. В эксперименте Anthropic 2026 года 52 преимущественно младших инженера осваивали незнакомую библиотеку Trio. Группа с AI закончила лишь примерно на две минуты быстрее — различие незначимо, — зато набрала 50% против 67% в немедленном тесте. Самый большой разрыв пришёлся на отладку. Это не означает, что AI «снижает обучение на 17%» вообще. Это означает, что готовый артефакт и сформированный навык уже нельзя считать одной метрикой.

Наконец, опытные инженеры тоже неверно оценивают выигрыш. В эксперименте METR 16 сопровождающих решали 246 реальных задач в знакомых зрелых репозиториях и с инструментами начала 2025 года оказались на 19% медленнее. После эксперимента они всё равно считали, что ускорились. В обновлении 2026 года вернувшиеся участники с новыми агентами оказались быстрее примерно на 18%. Но авторы отказались считать это точной оценкой и прямо называют цифру нижней границей: отбор участников и задач смещает результат в одну сторону. Самооценка «сэкономленных часов» слаба и для расчёта отдачи, и для оценки джуна.020202Про этот эксперимент писал отдельно и сначала не хотел: выборка в 16 инженеров казалась маловатой для громких выводов. Передумал, когда пошли заголовки в жанре «учёный изнасиловал журналиста», — и прочитал все 50 страниц. Хорошая иллюстрация того, что границу вывода приходится восстанавливать самому.Книжный куб · разбор эксперимента METR02Про этот эксперимент писал отдельно и сначала не хотел: выборка в 16 инженеров казалась маловатой для громких выводов. Передумал, когда пошли заголовки в жанре «учёный изнасиловал журналиста», — и прочитал все 50 страниц. Хорошая иллюстрация того, что границу вывода приходится восстанавливать самому.Книжный куб · разбор эксперимента METR

Локальное ускорение доказано лучше, чем системная польза; системная польза — лучше, чем ускорение обучения; ускорение карьерного взросления почти не измерено.

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

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

В эксперименте Anthropic 2026 года участники, полностью делегировавшие генерацию или отладку, набрали меньше 40% в тесте; те, кто задавал концептуальные вопросы и самостоятельно строил решение, — не меньше 65%. Авторы честно называют это сравнение описательным, а не причинным. Но как проектная гипотеза оно полезно: в новом домене AI лучше сначала использовать как преподавателя и источник вариантов, а не как способ замкнуть весь цикл.030303Обсуждали это в эфире Research Insights Made Simple с Женей Сергеевым — как раз по работе Anthropic 2026 года про устойчивую отдачу от экспертизы. Главное, что я оттуда унёс: экспертиза там — знание конкретной задачи, а не грейд и не стаж.Книжный куб · почему coding agents не отменяют экспертизу03Обсуждали это в эфире Research Insights Made Simple с Женей Сергеевым — как раз по работе Anthropic 2026 года про устойчивую отдачу от экспертизы. Главное, что я оттуда унёс: экспертиза там — знание конкретной задачи, а не грейд и не стаж.Книжный куб · почему coding agents не отменяют экспертизу

Небольшая работа CHI 2026 добавляет механизм. Опытные инженеры сохраняли управление через подробное, ограниченное и проверяемое делегирование. Начинающие колебались между полной зависимостью и осторожным отказом от AI. Авторы предлагают проверять не только код, но и ключевые решения о делегировании. А препринт Yu и Moon от 19 июля 2026 года на 14 интервью описывает поглощение простой работы связкой «старший инженер + AI». Именно на такой работе раньше безопасно рос новичок. Обе выборки слишком малы, чтобы говорить о потерянном поколении, но организационный риск они формулируют точно.

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

Я бы не делил новичков на «хороших» и «плохих» по объёму исходных знаний. Полезнее различать сильную и хрупкую рабочую петлю. Хрупкую нередко создаёт сама команда: требует скорость, выдаёт слишком широкую задачу, награждает большой PR и оставляет проверку старшему инженеру.040404Честный контраргумент к этому разделу тоже разбирал в канале: Kitze предлагает вообще не чинить руками код, написанный моделью, а заставлять её переделывать — иначе ломается скорость. Для скорости это работает. Для формирования инженера это ровно та петля, которую я называю хрупкой.Книжный куб · From Vibe Coding To Vibe Engineering04Честный контраргумент к этому разделу тоже разбирал в канале: Kitze предлагает вообще не чинить руками код, написанный моделью, а заставлять её переделывать — иначе ломается скорость. Для скорости это работает. Для формирования инженера это ровно та петля, которую я называю хрупкой.Книжный куб · From Vibe Coding To Vibe Engineering

Одинаковое изменение, разный уровень инженера

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

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

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

Это и есть калиброванное управление. Сильный новичок не обязан знать всё. Наоборот, точная граница знания — хороший сигнал. Фраза «я не понимаю, почему эта операция безопасна при повторной доставке; до выяснения не предлагаю слияние» ценнее уверенного объяснения из общих слов.

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

1. Сформулировать задачу и первую модель системы

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

2. Выбрать критерий правильности

Модель хорошо генерирует тесты. Человек решает, что они доказывают: положительный и отрицательный сценарии, инвариант, режим отказа, совместимость, безопасность и нагрузку. Генератор не должен единолично менять и реализацию, и способ её приёмки. Зелёная проверка без независимого оракула доказывает только согласованность двух артефактов.050505Разбирал SWE-PRBench: там меряют не умение написать патч, а умение оценить чужой PR, и за эталон берут реальные комментарии людей. Сам факт, что для этого понадобился отдельный оценочный стенд, хорошо показывает, почему генератор не должен единолично решать, что считается правильным.Книжный куб · SWE-PRBench и качество AI-ревью05Разбирал SWE-PRBench: там меряют не умение написать патч, а умение оценить чужой PR, и за эталон берут реальные комментарии людей. Сам факт, что для этого понадобился отдельный оценочный стенд, хорошо показывает, почему генератор не должен единолично решать, что считается правильным.Книжный куб · SWE-PRBench и качество AI-ревью

3. Воспроизвести и локализовать дефект

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

4. Выпустить, увидеть последствия и объяснить

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

Не делегируй целиком тот шаг, результат которого пока не умеешь независимо опровергнуть.

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

Календарная лестница плохо работала и до AI. Теперь два человека за одинаковые полгода могут произвести сходный объём кода и накопить совершенно разный опыт. Поэтому я предлагаю строить трек по единице ответственности, а не по сроку, числу задач или размеру проекта.

Открытые рамки Monzo и Dropbox уже движутся в эту сторону. Monzo называет рамку «компасом, а не GPS»: масштаб ответственности задаётся отдельно для каждого уровня — от задачи к проекту или функции и дальше, — а оценка строится вокруг влияния, технических навыков и поведения. Dropbox добавляет самостоятельный выбор решения, устойчивый выпуск и эксплуатационную ответственность. Это нормативные модели двух компаний, не универсальный стандарт. Но с агентами их логика становится ещё полезнее.060606Из книг про эту лестницу ближе всего «The Software Engineer's Guidebook» Гергели Ороша — разбирал её в канале. Блоки middle → senior → tech lead → staff идут там по нарастающей, и переход описан через объём ответственности, а не через срок.Книжный куб · The Software Engineer's Guidebook06Из книг про эту лестницу ближе всего «The Software Engineer's Guidebook» Гергели Ороша — разбирал её в канале. Блоки middle → senior → tech lead → staff идут там по нарастающей, и переход описан через объём ответственности, а не через срок.Книжный куб · The Software Engineer's Guidebook

От выполненной задачи к проверенному изменению

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

От слияния к наблюдаемому результату

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

От эпизода к системе во времени

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

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

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

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

Строки кода, число запросов, доля сгенерированного кода, количество агентов и субъективно сэкономленные часы могут описывать использование инструмента. Они почти ничего не говорят о формировании самостоятельного инженера. Даже число PR полезно только рядом с их размером, приёмкой, переделкой, дефектами и временем проверяющих.070707В августе записывал выпуск Code of Leadership про «цифрового тимлида» — систему, которая обещает оценивать эффективность разработчика прямо по коду. Разговор как раз про эту границу: код — важный результат работы инженера, но архитектурные решения, помощь команде, ревью и предотвращённые ошибки в него не попадают.Книжный куб · можно ли измерить инженера по коду07В августе записывал выпуск Code of Leadership про «цифрового тимлида» — систему, которая обещает оценивать эффективность разработчика прямо по коду. Разговор как раз про эту границу: код — важный результат работы инженера, но архитектурные решения, помощь команде, ревью и предотвращённые ошибки в него не попадают.Книжный куб · можно ли измерить инженера по коду

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

• —Дать неполное или слегка противоречивое требование и небольшой существующий модуль.
• —Разрешить привычный агент и сохранить историю взаимодействия.
• —До генерации попросить назвать предположения, критерий правильности и план.
• —Добавить скрытый инвариант, падающую проверку или журнал с правдоподобной ложной гипотезой.
• —После решения изменить одно условие и попросить объяснить, расширить или исправить результат.
• —На коротком фрагменте без AI проверить чтение кода, первичную локализацию дефекта и перенос понимания.
• —Дать конкретную обратную связь и посмотреть вторую итерацию.

Оценивать стоит постановку и декомпозицию, понимание системы и продукта, проверку и отладку, качество и эксплуатацию, обучаемость и ответственность. Не умение помнить синтаксис и не «секретные запросы». Сильный кандидат может пользоваться простыми инструкциями, потому что сначала сам сузил задачу и дал правильный контекст. Слабый может показать сложную оркестрацию и не заметить, что решает не ту проблему.080808Про устройство многоэтапного найма писал в канале отдельно: в большой компании нанимают не в команду, а в компанию, и каждый этап проверяет свою компетенцию. Рабочий эпизод с видимым процессом хорошо встаёт именно в такую схему — как отдельный этап, а не вместо всех остальных.Книжный куб · процессы найма и типы интервью08Про устройство многоэтапного найма писал в канале отдельно: в большой компании нанимают не в команду, а в компанию, и каждый этап проверяет свою компетенцию. Рабочий эпизод с видимым процессом хорошо встаёт именно в такую схему — как отдельный этап, а не вместо всех остальных.Книжный куб · процессы найма и типы интервью

Устройство LinkedIn REACH даёт полезный ориентир: реальные проекты, наставник, защищённое время развития, а после домашнего задания — объяснение и расширение решения. Страница программы к августу 2026 года не подтверждает открытый набор прямо сейчас, поэтому это пример механики, а не заявление о доступной вакансии.

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

Вход на рынок действительно сжимается. Рабочая публикация IZA на почти полной базе американских интернет-вакансий оценивает относительное снижение вакансий младших разработчиков против старших на 14–15% после выхода ChatGPT. Требования к опыту росли даже внутри тех же названий ролей, а в оставшихся вакансиях для начинающих чаще требовались решение проблем, коммуникация и внимание к деталям, а не специальные AI-навыки. Обновлённый 12 августа материал Stanford DEL описывает 19-процентный разрыв относительно прежней траектории занятости 22–25-летних в наиболее затронутых AI профессиях — в основном через найм. Это не потеря 19% всех мест и не причинная оценка AI; разрыв относится ко многим профессиям, наблюдаемые различия ослабевают при контроле образования, а часть расхождения траекторий появилась ещё до генеративного AI.

SignalFire показывает, что вход продолжал сжиматься и после прихода генеративных моделей: в Big Tech на выпускников пришлось лишь 7% наймов 2024 года, а число нанятых выпускников снизилось на 25% к 2023-му; в стартапах доля была ниже 6%, а найм выпускников сократился на 11% к 2023-му. Но сама компания ставит AI в один ряд с дорогим капиталом, сокращениями и избыточным наймом 2020–2022 годов. Опросы тоже расходятся. Среди более чем 880 инженерных руководителей в LeadDev 54% ожидали в долгую меньше найма джунов, а 38% согласились с утверждением, что AI-инструменты сократили объём прямого наставничества для джунов. В опросе Strada Education Foundation участвовали почти 1 500 американских руководителей компаний и старших руководителей по найму и развитию сотрудников из разных отраслей и компаний разного размера; среди старших руководителей по работе с людьми тех, кто ждал от AI роста найма на начальные позиции в 2026 году, оказалось в 2,7 раза больше, чем тех, кто ждал спада. Это ожидания разных выборок, а у Strada — ещё и намерения, не фактический найм.090909Разбирал панель Lightcone от Y Combinator про карьеру в эпоху AI. Там та же развилка с другой стороны: безработица среди выпускников computer science в США оказалась выше, чем у выпускников истории искусств, а ставку предлагают делать на самостоятельность, а не на диплом.Книжный куб · How to Spend Your 20s in the AI Era09Разбирал панель Lightcone от Y Combinator про карьеру в эпоху AI. Там та же развилка с другой стороны: безработица среди выпускников computer science в США оказалась выше, чем у выпускников истории искусств, а ставку предлагают делать на самостоятельность, а не на диплом.Книжный куб · How to Spend Your 20s in the AI Era

Компании делают обе ставки. Salesforce в мае 2026 года объявила, что программа Builder набирает 1 000 выпускников и стажёров в инженерные, продуктовые, коммерческие и другие подразделения. В том же материале Emerging Talent Playbook рекомендовал работодателям оценивать владение AI и когнитивную адаптивность, использовать структурированный ввод в работу и обратное наставничество. Cognizant 15 июля 2026 года заявила план нанять 1 500 выпускников в США до конца года через университетские программы и ученичество. Это заявления самих компаний, не независимые оценки и не только инженерные роли. Но они опровергают идею, что организация с AI в центре работы обязана отказаться от новичков.

Нанимать имеет смысл, если

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

Лучше отложить, если

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

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

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

Роль наставника

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

Роль руководителя

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

Роль инженерной платформы

Маленькие изменения, быстрый CI, автоматические проверки, наблюдаемость, обратимые выпуски, понятные границы и доступный контекст делают ошибку дешёвой и информативной. DORA называет AI усилителем существующей системы. Для программы новичков это особенно буквально: зрелая среда превращает скорость агента в обратную связь, слабая — в быстрый выпуск неопределённости.101010Онбординг как измеримый процесс разбирал в серии Developer Productivity for Humans. Там же названы обычные причины медленного разгона: слабая документация, отсутствие наставничества и неясные ожидания от инженера. Ни одну из них агент сам по себе не закрывает.Книжный куб · онбординг и разгон новичка10Онбординг как измеримый процесс разбирал в серии Developer Productivity for Humans. Там же названы обычные причины медленного разгона: слабая документация, отсутствие наставничества и неясные ожидания от инженера. Ни одну из них агент сам по себе не закрывает.Книжный куб · онбординг и разгон новичка

Две линии результата

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

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

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

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

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

Код стал дешевле. Воспроизводство инженерного суждения — нет.