Всем привет, это команда SimpleOne SDLC. Вокруг ИИ в разработке уже сформировались два шумных лагеря: одни уверены, что джуны теперь не нужны, другие считают, что ничего принципиально не изменилось. На практике неверны обе крайности.
Junior-разработчики не исчезли, но способ, которым они входят в профессию, решают первые задачи и демонстрируют результат на собеседованиях действительно изменился. А значит, командам нужно пересматривать не только отношение к ИИ, но и сами процессы найма, онбординга и оценки инженерной зрелости.
Что на самом деле изменилось
По данным hh.ru, в IT количество резюме выросло на 12%, а вакансий стало меньше на 29%. На одну junior-вакансию сейчас приходится до 16 резюме — работодатели стали значительно избирательнее. На собеседованиях это проявляется в конкретном паттерне: кандидат присылает аккуратное тестовое с читаемыми именами переменных, нормальной структурой и базовой обработкой ошибок — но на созвоне не может объяснить, почему выбрал именно такой подход, какие альтернативы рассматривал и какие ограничения видел.
Это не обязательно вопрос нечестности, чаще это признак новой модели обучения: раньше начинающий разработчик дольше продирался через ошибки, документацию, форумы и отладку, и за счёт этого медленно собирал причинно-следственные связи. Сейчас часть пути схлопывается до промпта и ответа модели. Результат появляется быстрее, а понимание — далеко не всегда.
Здесь важно не скатиться в упрощение. Проблема «принёс рабочий код, но не понимает, как он устроен» существовала и до ИИ: были copy-paste из Stack Overflow, заимствования из GitHub и чужие тестовые. Но у ИИ есть важное отличие: он научился генерировать правдоподобно хороший код, который проходит поверхностную проверку и выглядит как самостоятельная работа.
Почему это проблема не только для найма
Говорят: «код-ревью превратилось в допрос». Может быть, но это лишь видимый симптом — реальная проблема глубже, и проявляется уже в эксплуатации.
Если инженер не понимает собственное решение, он не может качественно поддерживать его через месяц, безопасно менять его через три месяца и уверенно диагностировать его поведение в инциденте. Такой код быстро превращается в участок системы без автора, без объяснимости и без надёжного владения. Для команды это означает рост скрытого техдолга, снижение bus factor и увеличение стоимости любых изменений.
Особенно заметно это в production-среде. Когда сервис деградирует под нагрузкой, ломается интеграция или начинает сыпаться цепочка ретраев, команде нужен не человек, который «видел похожий ответ у модели», а инженер, который умеет строить гипотезы, читать логи, понимать побочные эффекты и принимать осторожные решения под риском. Этот навык не возникает автоматически от того, что код однажды сгенерировался и прошёл тесты.
Где компании ошибаются
Когда в командах начинают замечать проблему, первая реакция почти всегда одинакова: искать виноватого — инструмент, кандидата или систему образования. На практике же большинство проблем с качеством джунов — это не внешние факторы, а следствие процессов, которые команда выстроила сама. Вот три ошибки, которые встречаются чаще всего.
Главная ошибка — считать, что проблема в самом инструменте
Запретить ИИ проще всего, но это не рабочая стратегия. Инструменты уже встроились в повседневную разработку, и рынок не собирается от них отказываться, что, в общем-то, справедливо. Вопрос не в том, использовать ли ИИ, а в том, при каких процессах его использование усиливает мышление, а не подменяет его.
Вторая ошибка — оценивать только результат
Если тестовое оценивается по критерию «работает / не работает», кандидат закономерно оптимизируется под этот критерий. Если первый рубеж качества в команде — только зелёный пайплайн, а обсуждение причинно-следственных решений начинается лишь на ревью, то команда сама себе создаёт условия, в которых понимание перестаёт быть обязательным.
Третья ошибка — пытаться решить всё код-ревью
Ревью не должно быть первым местом, где автор начинает думать о собственном решении. К моменту открытия PR базовые ответы на вопросы «почему так», «какие были альтернативы» и «что может пойти не так» уже должны существовать.
Как менять найм
Большинство процессов найма разработчиков строилось в эпоху, когда джун учился через боль: медленно, с ошибками, через Stack Overflow и отладчик. Под эту модель и затачивалось тестовое, технические вопросы и критерии оценки. Сейчас модель изменилась — а процессы остались прежними. Вот, что стоит пересмотреть в первую очередь.
Снижать ценность тестового «написать с нуля»
В 2026 году классическое тестовое всё хуже проверяет именно инженерное мышление. Оно по-прежнему может быть полезным как фильтр на минимальную способность доводить задачу до конца, но плохо показывает глубину понимания.
Поэтому вместо или поверх тестового лучше вводить формат разбора чужого кода. Дайте кандидату 150–200 строк анонимизированного, намеренно неидеального кода и попросите вслух ответить на несколько вопросов:
-
Что здесь сделано хорошо?
-
Что вызывает сомнения?
-
Что бы он поменял в первую очередь?
-
Какие edge cases здесь не учтены?
-
Где могут быть проблемы с эксплуатацией, поддержкой или тестированием?
Этот формат заметно лучше проверяет реальный рабочий навык. Большинство разработчиков в компании не пишут всё с нуля — они читают, меняют, ревьюят и поддерживают уже существующий код.
Добавлять operational thinking в интервью
Если команда работает с production, интеграциями и реальными пользователями, на собеседовании нужен не только разговор про алгоритмы и синтаксис. Нужны сценарии из жизни:
-
Этот код упал в проде, вот логи — что делать дальше?
-
Как бы ты тестировал участок, который зависит от внешнего API?
-
Что в этом коде станет проблемой при росте нагрузки в 10 раз?
-
Где здесь риск для release или rollback?
Junior не обязан идеально отвечать на все такие вопросы. Но по этим ответам хорошо видно, понимает ли кандидат систему как живой объект или мыслит только рамкой «функция отработала — задача решена».
Как менять онбординг
Найм — это только вход. Даже если кандидат прошёл собеседование с разбором чужого кода и ответил на операционные вопросы, это не гарантирует, что через месяц он будет понимать систему, в которой работает.
Онбординг — это место, где инженерное мышление либо начинает формироваться, либо атрофируется окончательно. Здесь у большинства команд есть несколько типичных ошибок.
Требовать объяснения решений, а не построчных комментариев
Популярная реакция на проблему — обязать джуна «объяснять каждую строку». На практике это быстро превращается в бессмысленный ритуал, который не масштабируется ни для автора, ни для ревьюера.
Гораздо полезнее требовать объяснения нетривиальных решений. Любой PR джуна в первые недели должен сопровождаться коротким описанием:
-
какую проблему решает изменение;
-
почему выбран именно этот подход;
-
какие альтернативы рассматривались;
-
какие ограничения и компромиссы есть у решения;
-
что может сломаться при дальнейшем развитии.
Это можно оформить как мини-ADR, шаблон в описании pull request или обязательный чеклист. Смысл не в бюрократии, а в том, чтобы заставить мышление происходить до ревью, а не во время защиты.
Делать защиту решений регулярной практикой
Хорошо работает формат, при котором джун раз в одну-две недели берёт свой PR или завершённую задачу и устно защищает решение перед сеньором или тимлидом. Объясняет, как устроена логика, какие были альтернативы, почему был принят именно такой компромисс.
Если решение делалось с помощью ИИ — это не проблема. Проблема возникает только тогда, когда инженер не может объяснить, что именно он принял на себя как ответственность. В этом смысле код, предложенный моделью, должен защищаться так же, как и написанный вручную.
Учить не только писать, но и отлаживать
Во многих командах начинающих учат в основном «делать фичи». Но эксплуатационная зрелость формируется не на happy path, а на разборе сбоев.
Поэтому в онбординг полезно включать управляемую практику отладки: воспроизведение багов, чтение логов, поиск причин деградации, анализ некорректных ретраев, таймаутов и неконсистентного состояния. Именно здесь лучше всего видно, понимает ли человек систему или лишь умеет быстро собирать видимо работающий код.
Что это значит для SDLC
На первый взгляд тема кажется локальной — будто речь только о джунах, но на деле это влияет на весь жизненный цикл разработки.
Если в команде растёт доля кода без понятного авторского замысла, то ухудшается качество code review, повышается стоимость изменений, слабеет устойчивость релизов и растёт нагрузка на старших инженеров как на единственных носителей реального контекста. Это уже не проблема отдельного собеседования, а проблема SDLC-процесса: от входа человека в команду до сопровождения изменений в продакшене.
Поэтому зрелый ответ на влияние ИИ — это не лозунг «разрешить» или «запретить». Это настройка quality gates на уровне процессов:
-
в найме — проверять понимание, а не только результат;
-
в онбординге — требовать объяснимости решений;
-
в code review — проверять не только стиль и корректность, но и причинность выбора;
-
в инженерной культуре — формировать привычку защищать архитектурные и кодовые компромиссы;
-
в эксплуатации — развивать способность читать поведение системы, а не только производить код.
Где здесь роль инструмента
В SimpleOne SDLC часть этой задачи решается на уровне среды разработки процессов: команде проще работать, когда задачи, изменения, обсуждения и контекст решений находятся в одном пространстве, а не размазаны между разными системами и устными договорённостями. Это не заменяет инженерное мышление и не отменяет необходимости сильного ревью, но снижает порог входа в контекст системы.
Для джуна это особенно важно. Если он видит не только тикет и diff, но и историю задачи, связанные изменения, обсуждавшиеся ограничения и зависимости между компонентами, у него выше шанс понять, зачем решение вообще устроено именно так. Инструмент сам по себе не делает инженера зрелым, но может убрать часть организационной слепоты, которая мешает учиться.
Какие anti-patterns стоит признать прямо сейчас
Есть несколько вредных крайностей, которые уже начинают закрепляться в командах:
-
«Главное — чтобы код работал, остальное придёт потом». Обычно не приходит.
-
«Запретим ИИ, и проблема исчезнет». Не исчезнет, просто уйдёт в серую зону.
-
«Раз джун быстро генерирует, значит он быстрее растёт». Скорость генерации и скорость формирования инженерного мышления — не одно и то же.
-
«Сеньор на ревью всё поймёт и поправит». Это путь к перегрузке старших инженеров и бутылочному горлышку в delivery.
-
«Контекст сам наработается со временем». В сложных enterprise-системах без целенаправленной передачи контекста это работает всё хуже.
Что стоит пересмотреть командам уже сейчас
Если коротко, то не джунов нужно переизобретать, а процессы вокруг них. Минимальный практический набор изменений выглядит так:
-
Перестать считать тестовое основным источником сигнала.
-
Ввести разбор чужого кода и сценарные вопросы на эксплуатацию.
-
Требовать объяснения нетривиальных решений в каждом раннем PR.
-
Встроить регулярную защиту решений в онбординг.
-
Учить отладке и чтению поведения системы так же целенаправленно, как учат писать код.
-
Передавать системный контекст через процессы и инструменты, а не надеяться, что он «как-нибудь впитается».
ИИ не отменил junior-разработчиков. Но он резко повысил цену поверхностной оценки и слабого онбординга. Команды, которые это поймут раньше, получат не только более сильных джунов, но и более устойчивый SDLC в целом.
***
Сталкивались с ситуацией, когда джун приносит рабочий код, но не может объяснить ни одного решения? Как вы это решаете на уровне процессов — или пока не решаете?
ссылка на оригинал статьи https://habr.com/ru/articles/1036918/