Материал о том, почему джуны в IT застревают на стартовом уровне, собрал на Habr около 60 тысяч охвата и попал ровно в боль найма 2026 года: курсы обещают быстрый вход, команды ждут самостоятельности, а между ними сидит начинающий разработчик с нейросетью и тревогой. Habr / Карьера сообщает о сатирической колонке с шестью «вредными» правилами для junior-специалистов, за которыми прячется вполне серьезный тезис: проблема не в отсутствии опыта, а в отказе отвечать за результат.
Автор Grami строит текст как антиинструкцию. Не учись, не задавай вопросы, отдавай код без проверки, спорь с процессами, используй ИИ как прокладку между ТЗ и репозиторием, а при первом конфликте уходи. Формально это шутка, но шутка из тех, после которых тимлиды нервно открывают список незакрытых ревью. В центре заметки не «ленивый джун» как карикатура, а привычный набор защитных реакций: боязнь признать пробелы, желание выглядеть опытнее, чем есть, и надежда, что команда как-нибудь подхватит все, что не было додумано, проверено или понято.
Самый острый фрагмент касается самообразования. Автор высмеивает позицию «все уже есть в интернете», где документация, статьи, примеры и ответы нейросетей заменяют понимание. Для разработчика это особенно опасная иллюзия: доступ к информации не равен навыку применять ее в чужом коде, под реальные ограничения и с последствиями для продукта. Transactions, data race, бизнес-логика, пограничные сценарии и архитектурные причины решений не становятся понятными от того, что рядом открыт чат с ИИ.
Вторая мишень - молчание. Начинающий специалист часто боится задавать вопросы, потому что вопрос выглядит как признание слабости. На практике команда обычно страдает не от вопроса, а от недели тихой разработки в неверном направлении. Если junior не понял задачу, нашел противоречие в требованиях или застрял в коде на несколько часов, нормальная рабочая реакция - уточнить. Это не просьба «сделайте за меня», а способ не превращать маленький пробел в дорогую переделку.
Отдельный слой текста - нейросети в разработке. В 2026 году спор уже не в том, можно ли пользоваться ИИ: можно, и многие команды будут только рады ускорению рутинных операций. Вопрос в другом: кто отвечает за результат, если код сгенерирован агентом, но попал в репозиторий под именем разработчика. Автор формулирует это жестко: не становиться мостиком между ТЗ и нейронкой. ИИ может подсказать реализацию, набросать тест, объяснить незнакомый API, но он не снимает обязанность прочитать, запустить, проверить и понять, почему решение подходит именно этому проекту.
Еще один конфликт знаком почти любой команде с наймом начинающих: новичок приходит со свежими идеями и быстро обнаруживает легаси, странные процессы, непопулярные библиотеки и архитектурные решения, которые выглядят как повод все переписать. Иногда критика справедлива. Но в колонке высмеивается другой сценарий: когда непонимание контекста автоматически объявляется «устаревшим подходом», а просьба соблюдать стиль кода или предупреждать о задержках трактуется как подавление личности. Для бизнеса это не философский спор, а вопрос предсказуемости: можно ли доверить человеку задачу и понимать, что риски всплывут раньше релиза.
В источнике нет комментариев работодателей или статистики по рынку, но контекст считывается без дополнительных графиков. Российский IT-рынок несколько лет переваривает массовый вход новичков после курсов, буткемпов и стажировок. Одновременно команды стали чаще использовать ИИ-инструменты, а требования к даже младшим разработчикам сместились от «напиши кусок кода» к «разберись, проверь, объясни, где сомневаешься». Поэтому джуны в IT конкурируют уже не только знаниями языка или фреймворка, но и рабочим поведением: умеют ли они уточнять задачу, принимать ревью, тестировать базовые сценарии и не перекладывать ответственность на процесс.
Сильная часть колонки - раздел без инверсии, где автор снимает комедийную маску. Junior не обязан приходить с десятилетним опытом, знать все паттерны и сразу спорить с архитектором на равных. От него разумно ждать другого: попытался разобраться, обозначил спорные места, спросил вовремя, проверил основной сценарий, понял ошибку после ревью и изменил поведение. Это звучит скучнее, чем «быстро войти в IT за три месяца», зато больше похоже на реальную профессию.
Есть и спорный момент: автор советует начинающим смотреть в сторону аутсорса, стажировок и «галер», потому что там сильнее заинтересованы в росте грейда сотрудника. Тезис узнаваемый, но не универсальный. Аутсорс действительно может дать много практики, разные проекты и быструю обратную связь. Он же может дать хаос, перегруз и выгорание, особенно если наставничество существует только в описании вакансии. Для новичка важнее не тип компании, а наличие понятных ожиданий на испытательный срок, доступного ментора и культуры, где вопросы не наказываются.
Главный вывод для разработчиков и руководителей одинаковый: джуны в IT растут быстрее не там, где им прощают все, и не там, где от них требуют невозможного, а там, где ответственность дозируют, но не отменяют. Новичку полезно перестать изображать сеньора, а команде - явно проговаривать, что считается прогрессом. Следующий большой спор, похоже, будет не о том, заменит ли ИИ junior-разработчиков, а о том, кто быстрее научится работать с ИИ как с инструментом, не отдавая ему собственную профессиональную голову.