Джун без простых задач. Как войти в IT в эпоху AI?

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

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

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

Собственный проект даёт место, где обе линии обучения можно соединить. Евгений предлагает пройти весь цикл: разобраться в проблеме, собрать работающий продукт, запустить его и поддерживать. Особенно важны этапы до генерации кода и после неё. После первого запуска появляются ошибки, изменения требований и необходимость сохранить систему пригодной для дальнейшей разработки. Именно этот опыт отличает учебную демонстрацию от знакомства с реальной инженерной работой. При этом продукт не гарантирует заработка. Александр разделяет два смысла входа в IT: начать что-то делать и начать получать за это деньги. Инструменты упрощают первое, но не обеспечивают второе. Новичок конкурирует не только с опытным разработчиком: специалист предметной области тоже может автоматизировать собственную работу с AI и уже понимает, какой результат ему нужен. Поэтому проект должен учить не только сборке приложения, но и пониманию пользователя. Вопрос «зачем это кому-то нужно?» становится частью подготовки инженера раньше, чем в привычной модели найма.

Проверять готовность начинающего Алексей предлагает через историю собственного проекта. Важны организация работы агентов, инструкции в AGENTS.md, автоматические проверки и CI/CD, а также способность рассказать, что происходило при сбоях. Сам по себе язык реализации или стаж дают меньше информации, чем объяснение решений: как проверялась новая модель, чем подтверждалось завершение задачи, что менялось после ошибки. Александр предлагает и более узкую модель стажировки: новичку не обязательно знать все методологии работы с AI, достаточно освоить принятый в компании процесс. Но он должен объяснить постановку задачи и критерии приёмки, защитить реализованное агентом решение перед наставником, понимать выпуск изменений и план отката. Проверять нужно не только конечный артефакт, но и обучение внутри процесса. Готовый код перестал быть надёжным свидетельством того, что автор понял задачу. Поэтому наставничество требует специально спроектированного цикла обратной связи, в котором растёт ответственность человека, даже если реализацию выполняет агент.

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