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

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

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

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

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

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

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