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

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

Позже я предложил попробовать C# и backend. Это мой основной стек, поэтому здесь я могу не только посоветовать материал, но и проверить решение, объяснить контекст из реальной разработки или заметить, когда нейронка ведёт не туда.

Мы поправили резюме, подготовили рассказ об опыте и сделали тестовый task tracker. В нём есть задачи и подзадачи, которые можно завершать. Проект разворачивали в Azure примерно на месяц, чтобы пройти весь путь до работающего сервиса, а затем выключили. Я помогал с частью реализации и деплоем. С метриками жена разбиралась в основном сама.

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

Что именно AI упрощает в обучении

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

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

AI сильно сокращает этот цикл.

Можно попросить объяснить concurrency другими словами. Затем привести пример на знакомом коде, задать уточняющий вопрос и попросить небольшое упражнение. При разборе алгоритма можно отдельно запретить выдавать готовое решение: пусть агент даст направление или укажет на ошибку в рассуждении.

Такой формат не привязан к расписанию преподавателя. Он позволяет за единицу времени разобрать больше вопросов, а затем сразу применить ответ в проекте.

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

Но скорость получения материала нельзя путать со скоростью формирования навыка.

Где заканчивается понятное объяснение

Во время работы над task tracker возникла проблема с EF Core миграциями. Codex пошёл по сложному пути и начал создавать дополнительные классы, чтобы запустить миграции. Реальная причина могла быть гораздо проще: способ запуска скрипта, окружение или недостающие права.

Эта ситуация хорошо показывает две проблемы обучения с AI:

1. Новичок может неполно описать ситуацию

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

На интервью этот разрыв проявляется ещё быстрее.

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

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

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

Работодателю нужен второй вариант.

Простые задачи тоже меняются

Есть ещё одна причина, по которой вход в профессию становится сложнее.

Начинающий разработчик традиционно получал задачи с ограниченным риском. Подключить Redis к сервису. Поменять строку подключения на staging. Найти в коде, почему система работает именно так. Для опытного коллеги это не самая ценная работа, а для junior-разработчика это способ изучить репозиторий и сделать первое полезное изменение.

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

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

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

Я не могу по этому наблюдению доказать, что количество junior-вакансий сократилось именно из-за AI. На рынок одновременно влияют найм после периода быстрого роста, состояние экономики и число кандидатов. Без отдельных данных причины не разделить.

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

Pet-проект больше не говорит сам за себя

Ещё несколько лет назад развёрнутый сервис с базой данных, логами и метриками требовал много самостоятельного исследования. Теперь начинающий разработчик может попросить AI создать структуру проекта, Docker-конфигурацию и deployment pipeline.

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

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

Для task tracker я бы спрашивал не только о списке технологий. Почему задачи и подзадачи представлены именно так? Что произойдёт при одновременном изменении? Какие метрики были добавлены и зачем? Как поменять модель, если у задачи появится несколько исполнителей?

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

Как я бы проверял новичка

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

Я бы разделил проверку на две части.

Сначала небольшая задача без AI. Она не должна требовать трюка или знания редкого API. Цель: увидеть, умеет ли человек разложить условие, выбрать базовую структуру данных, написать код и объяснить решение.

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

Такой формат проверяет и базу, и реальный способ работы с инструментом.

Что делать начинающему разработчику

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

Но после каждого заметного куска работы стоит убирать подсказку и проверять себя:

• объяснить решение своими словами

• изменить одно из условий

• найти и исправить поломку

• показать весь путь от кода до запущенного сервиса

Для pet-проекта это означает не просто сгенерировать API. Нужно поднять базу, развернуть сервис, добавить наблюдаемость и несколько раз самостоятельно изменить модель после первой рабочей версии.

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

Если вам близки такие темы, я пишу о них в Telegram-канале «Разработчик без хайпа»