Эта статья была вдохновлена статьей https://addyosmani.com/blog/next-two-years/. Постить на Хабре просто очередной перевод выполненный LLM, на мой взгляд, не имеет смысла и ценности не несет. Плюс разработка в России ≠ разработка в США, у нас много своих нюансов и специфики. При этом я заимствовал вопросы, и части текста автора , потому что полностью разделяю его мнение в некоторых вопросах, а в некоторых вопросах наши мнения расходятся (да, да, можете считать, что это с одной стороны урезанный, а с другой дополненный перевод статьи).

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

Почему я считаю, что вообще могу высказываться на эту тему? Весь мой рабочий опыт так или иначе связан с разработкой ПО. Больше 10 лет я писал код своими руками, наблюдал появление и адаптацию новых технологий, которые используются для написания кода. Последние 10 лет я так или иначе руковожу командами разработки и участвую в их найме.

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

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

И хочу поговорить с вами скорее о том, какие варианты развития событий мы можем увидеть в ближайшие 2-3-5 лет и как к ним адапатироваться разработчикам.

DISLAIMER. Говорю разработчики, подразумеваю всех, кто участвует в цикле разработки ПО - аналитиков, программистов, тестировщиков, DevOps, тимлидов и тд.

Небольшая вводная

Индустрия разработки ПО проходит очередной этап в развитии, возможно переломный этап. Мы наблюдаем появление и бурную эволюцию AI-помощников для написания кода. В начале это было просто автодополнение, сейчас у нас появились агенты, MCP, и Skills с помощью которых можно целиком решать какие-то из задач разработки. Я специально пишу какие-то из задач, потому что сохраняю, как мне кажется, здоровый скепсис в части возможностей AI-помощников. С другой стороны, я считаю, что большая часть кода, которая разрабатывается в компаниях это несложные задачи, а скорее реализация автоматизации какой-то бизнес логики, которая очень часто состоит из перекладывания и трансформации условных JSON (я сознательно тут упрощаю, не воспринимайте буквально).

Оценить реальную эффективность новых инструментов мы сможем через 3-5 лет. Сейчас оценку выполнить крайне сложно по нескольким причинам:

  • Инструменты развиваются слишком активно. И большая часть разработчиков просто не успевают следить за трендами (и это нормально). Какие-то из этих инструментов (наиболее полезные) выживут и расцветут, а какие-то умрут.

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

  • Инструменты становятся сложнее и начинают требовать либо навыков, либо дополнительных артефактов (например, написания AGENTS.md, или создания другого описания архитектуры проекта, его логики и так далее). Развитие навыков или появление артефактов потребуют времени. А с учетом бурного развития (непонятно выживет инструмент или нет) и скепсиса части разработчиков, времени потребуется немало.

При этом развитие AI-инструментов наложилось на общий экономический спад, как в России, так и во всем мире. Если раньше мы видели непрерывный найм разработчиков (который и подтолкнул к появлению десятков инфоцыган обучавших ИТ), то в 2024-2025 произошел переход к сокращению найма, а местами и к увольнению людей. Скорее всего в 2026 мы не увидим смены тренда, скорее наоборот. При этом бизнес задачи, которые раньше решали разработчики никуда не делись. А значит нужно как-то повышать эффективность труда тех разработчиков, которые остаются работать в компаниях. Раньше у компаний был классический ответ - давайте уволим 2 Middle (или несколько Junior) и наймем одного Senior. По деньгам хороший Senior обычно стоит меньше, чем 2 Middle (обычно около 1.5 зарплатны Middle), при этом может делать x3-x5, а то и x10 результата. Эффективность также повышается за счет снижения количества коммуникаций в команде. Теперь менеджеры нашли еще один ответ - AI-инструменты. Мол давайте дадим людям новые инструменты, которые стоят дешевле, чем платить зарплату +1 специалисту, и за счет этого получим больше результата. Повторю - не будем пока учитывать реальную эффективность таких решений. Просто отметим этот факт.

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

Что будет дальше - неясно. Давайте попробуем поговорить о нескольких критический вопросах, которые могут определить или значительно повлиять на будущее разработки ПО. Это не предсказания - скорее рекомендации, как действовать.

Найм и рост Junior разработчиков

Есть 2 сценария по которому может пойти найм Junior.

Пессимистический сценарий: Найм начинающих разработчиков (джунов) может резко сократиться из-за автоматизации простых задач с помощью AI. В России период сокращения найма будет дополнительно зависеть от общей экономической ситуации.

Традиционный путь «научись программировать, устройся Junior, вырасти до Senior» почти не работает. Исследование Гарварда с участием 62 миллионов работников показало, что когда компании внедряют генеративный AI, количество занятых начинающих разработчиков падает примерно на 9–10% в течение шести кварталов, а занятость Senior-разработчиков почти не меняется. Гарвард для России не особо релевантен, но хороших собственных исследований у нас нет. Логику менеджмента я уже описывал выше - зачем нанимать +1 Junior, если можно повысить эффективность Middle/Senior разработчиков с помощью инструментов, которые стоят дешевле.

Долгосрочный риск пессимистичного сценария часто упускается из виду: сегодняшние Junior — это завтрашние Senior-инженеры и технологические эксперты. Полностью перекрыв канал притока талантов, создается вакуум лидерства через 5–10 лет. Ветераны отрасли называют это «медленным упадком»: экосистема, которая перестает готовить себе смену. Я не думаю, что джунов прям вообще не будут нанимать и растить, просто их будет значительно меньше. Скорее раньше рынок был перегрет и мы вернемся к доковидному найму.

Косвенная проблема, которая может быть следствием этого тренда - снижение bus factor. Один Senior, конечно, может принести больше ценности, чем 2 Middle, но что делать когда он пойдет в отпуск, на больничный или вообще уволится?

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

Оптимистический сценарий: AI открывает новый спрос на разработчиков во всех отраслях, а не только в технологиях. Здравоохранение, сельское хозяйство, производство и финансы уходят на новый виток внедрения ПО и автоматизации. Вместо того, чтобы заменять разработчиков на AI, мы получаем множитель мощности одного разработчика (если смотреть со стороны денег - это также снижение стоимости реализации автоматизации, а это может быть драйвером новой автоматизации, где раньше ее не рассматривали, так как было слишком дорого). Здесь может быть забавный эффект - когда компании хотят внедрить новые AI инструменты (не в разработке), им все равно нужно сколько-то разработчиков (использующих AI инструменты для разработки) для этого внедрения. В России этот сценарий сейчас выглядит куда менее вероятным - здравоохранению, например, сейчас точно не для AI автоматизации, но через 3-5 лет? Возможно, мы увидим даже новый виток импортзамещения с помощью AI (вряд ли с хорошим качеством, но там и без AI кодинга все было не без нюансов)

Что с этим делать:

  • Джунам: стать экспертом в новых AI технологиях и универсалом (так называемый T-shaped). Ваша задача показать, что вы + навыки AI можете соперничать с результатами маленькой команды (команды джунов конечно). Учитесь эффективно использовать AI-агентов, но с пониманием каждой строчки кода (а не просто доверяя LLM). Сосредоточьтесь на навыках, которые AI не может легко заменить: коммуникация, декомпозиция проблем, предметные знания. Рассмотрите смежные роли - прежде всего QA и аналитиков, как потенциальные точки входа в индустрию. Рассмотрите стажировки, подрядную работу или участие в open source. Не будьте «просто еще одним новым джуном, которого нужно учить и чуть»; будьте инженером, который сразу полезен и быстро учится. Создайте портфолио на github, особенно проекты, интегрирующие AI-API.

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

  • Senior-разработчикам: Меньшее джунов означает, что больше рутинной работы ляжет на вас. Вам точно стоит попробовать работу хотя бы с самыми популярными AI-инстурментами, понять их возможности и ограничения, а также показать работодателям, что вы готовы их использовать. Будьте неофициальным наставником через open source или обучение коллег из других отделов (чтобы не терять навыки обучения джунов). Будьте откровенны с руководством относительно рисков команд, состоящих только из Senior. Если спрос на джунов восстановится, будьте готовы к эффективному онбордингу и делегированию задач с использованием AI. Ваша ценность — в умножении результативности всей команды, а не только в вашем собственном коде.

Навыки

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

84% разработчиков в США регулярно используют AI-помощников. В России это скорее 30-50%. Это исключительно мое мнение-наблюдение. При появлении новой ошибки или необходимости написать новую функциональность, разработчики рефлекторно начинают писать промпты и собирать вместе AI-сгенерированные фрагменты, а не пишут код с нуля. Меня больше всего смущают баги - так как именно на багах мы обучаемся "отладке", то есть погружению вглубь проблемы. И именно на таких задачах происходит обучение (на мой взгляд). Отсутствие этих навыков приведет к тому, что багу, которую не смог решить AI не сможет решить никто (из сотрудников компании). С другой стороны именно на багах AI сейчас ошибается чаще всего, и в них все равно приходится разбираться самому. Что будет через 3-5 лет - посмотрим.

Некоторые Senior-инженеры опасаются, что это порождает поколение, которое не может хорошо программировать самостоятельно, — своего рода деградацию навыков. Я бы не был так пессимистичен. Даже сейчас у нас есть разработчики с крайне глубокими знаниями с одной стороны и подавляющее большинство, которые, например, ничего не знаю про устройство ОС - им это не нужно. Скорее всего тут будет также - будут эксперты, которые могут написать код лучше\быстрее\безопаснее, чем средний разработчик, использующий AI-инструменты (но именно таких будет большинство).

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

Если у всех есть доступ к AI-агенту для кодинга, то опытных разработчиков отличает умение понять, когда AI ошибается или работает не оптимально. Как сказал один Senior-инженер: «Лучшими инженерами-программистами будут не самые быстрые кодеры, а те, кто знает, когда не доверять AI».

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

Мнения разработчиков в 2025 году разделились. Некоторые признались, что почти никогда не пишут код «вручную» и считают, что технические собеседования должны эволюционировать. Другие утверждали, что пропуск основ приводит к большему количеству «тушения пожаров», когда вывод AI не работает. Отрасль начинает ожидать от инженеров и того, и другого: скорости работы с AI и фундаментальных знаний для обеспечения качества.

Отмечу кстати еще один забавный момент. Когда AI начинает писать много кода - одна из важнейших задач это code review. И наверное, каждый из нас знает на сколько сложнее отсмотреть несколько патчей на тысячу строк кода в день. Это очень высокая когнитивная нагрузка, которая крайне выматывает. С другой стороны - это именно то, что делает, например, Линус Торвальдс на протяжении десятков лет. Он уже очень редко пишет сам, скорее изредка редактирует присылаемые патчи. И большая часть его работы именно глубинное понимания того, как работает ядро, и десятки code review в день.

Я не разделяю мнения, что код превращается в "Черный ящик". Любое современное приложение это использование десятка, а то и пары тысяч библиотек (привет JavaScript). И никто не понимает как это все работает внутри. Я видел немало разработчиков, которые с трудом могут диагностировать проблему внутри библиотеки и еще меньше тех, кто может ее поправить, а не просто поставить костыли в своем коде или просто переключиться на другую библиотеку, где такой ошибки нет. Я скорее вижу, что есть разработчики которые могут копать глубоко, таких меньшинство, а есть те, которые не могут или не хотят это делать. Это скорее отдельный навык или личная предрасположенность, так было и раньше. И так может быть и дальше - кто-то будет копаться внутри AI кода, а кто-то будет просто 10 раз просить разные модели переписать ошибочный кусок кода или подставить костыли.

Что с этим делать:

  • Джунам: Используйте AI как инструмент обучения, а не костыль. Когда AI-агенты для кодинга пишут за вас код, анализируйте, почему он работает, выявляйте слабые места. Время от времени отключайте помощника AI и пишите ключевые алгоритмы с нуля. Изучайте основы информатики: структуры данных, алгоритмы, сложность, управление памятью. Реализуйте проекты дважды: один раз с AI, один раз без, и сравнивайте результаты. Изучите промпт-инжиниринг и мастерство владения инструментами. Углубляйте дополнительные навыки, которые AI не может воспроизвести: проектирование систем, интуиция в пользовательском опыте, понимание параллелизма. Покажите, что вы можете и быстро создавать решения с помощью AI, и решать сложные проблемы, когда он не справляется. Разбирайтесь в тестировании и отладке: пишите модульные тесты, читайте stack trace, не обращаясь сразу к AI, привыкайте к отладчикам. Стоит также начать работать над своими soft skills, учиться выстраивать эффективные коммуникации с коллегами и постановщиками задач. Чаще задавать себе вопросы - зачем и почему я делаю то или иное изменение. Если суммировать - вам надо учиться code review без хорошей базы написания кода. Будет непросто, и базу все равно придется набирать.

  • Senior-разработчикам: Позиционируйте себя как гаранта качества и сложных решений. Оттачивайте свою основную экспертизу: архитектура, безопасность, масштабирование, предметные знания. Практикуйтесь в моделировании систем с AI-компонентами и продумывании режимов отказа. Следите за новыми уязвимостями в коде, сгенерированном AI. Примите свою роль наставника и рецензента: определяйте, где использование AI приемлемо, а где обязательно писать руками (код, связанный с платежами или безопасностью). Погружайтесь в творческую и стратегическую работу; пусть комбинация Junior+AI занимается реализаций рутинных API, пока вы решаете, какие API нужны, проектируете хорошие контракты для этих API. Инвестируйте в soft skills и междисциплинарные знания. Следите за новыми инструментами и лучших практик. Удваивайте ставку на то, что делает разработчика-человека незаменимым: здравый смысл, системное мышление и наставничество. Защищайте свою творческую страсть через прототипы, хакатоны или исследование новых технологий

Специалисты vs универсалы

Пессимистический сценарий: Узкие специалисты рискуют столкнуться с автоматизацией или исчезновением своей ниши.

Учитывая скорость, с которой модели, инструменты и фреймворки появляются и устаревают, делать ставку в карьере на один стек технологий рискованно. Гуру в устаревшем фреймворке может внезапно обнаружить, что его знания менее востребованы, когда новый ИИ-инструмент справляется с этой технологией при минимальном вмешательстве человека. Разработчики, узко специализирующиеся на «одном стеке, фреймворке или продуктовой области», могут проснуться и обнаружить, что эта область пришла в упадок или стала избыточной.

Вспомните разработчиков COBOL, Flash или специалистов по движкам для мобильных игр, которые не сменили направление, когда отрасль ушла вперед. Разница сейчас — в темпе изменений. Автоматизация с помощью ИИ может сделать определенные задачи программирования тривиальными, подрывая значимость ролей, которые были сосредоточены на этих задачах. В целом - ничего нового - в ИТ нужно постоянно обучаться.

Российская специфика - в гос структурах все будет меняться на порядок быстрее. И AI ассистенты там будут появлятся не скоро, особенно если появится новая регуляторка и принуждение к использованию только российских инструментов.

Оптимистичный сценарий: специализация в новой форме: «универсальный специалист» или T-shaped разработчик. Глубокие знания в одной-двух областях (вертикальная черта), широкое знакомство со многими другими (горизонтальная черта). Такие инженеры становятся «связующим звеном» в междисциплинарных командах; они общаются со специалистами другого профиля и при необходимости заполняют пробелы.

Компаниям больше не нужны разработчики, которые либо слишком поверхностны, либо слишком узко сфокусированы; им нужна сильная ключевая компетенция плюс способность работать со всем стеком. Частично причина в эффективности: T-shaped инженер может решать проблемы от начала до конца, не дожидаясь передачи задачи. Частично — в инновациях: перекрестное опыление знаний приводит к лучшим решениям.

Инструменты ИИ на самом деле больше усиливают возможности универсалов, позволяя одному человеку легче работать с несколькими компонентами. Бэкенд-инженер может полагаться на помощь ИИ для создания приемлемого пользовательского интерфейса; фронтенд-специалист может поручить ИИ сгенерировать серверный шаблонный код. Среда, богатая ИИ, позволяет людям действовать шире. В то же время узкие специалисты могут обнаружить, что их ниша частично автоматизирована, и у них нет простого способа расширить кругозор.

Что с этим делать:

  • Начинающим разработчикам: Заложите широкий фундамент рано. Даже если вас наняли на конкретную роль, заглядывайте за пределы своей «башни». Если занимаетесь мобильной разработкой, изучите основы бэкенда; если фронтендом — попробуйте написать простой сервер. Изучите процесс развертывания и такие инструменты, как Docker или GitHub Actions. Определите одну-две области, которые вас искренне увлекают, и углубитесь в них: это станет вашей вертикальной экспертизой. Позиционируйте себя как гибридного специалиста: «full- stack разработчик со специализацией на облачной безопасности» или «фронтенд-разработчик с экспертизой в UX». Используйте ИИ-инструменты для быстрого изучения новых областей; когда вы новичок в бэкенде, попросите ChatGPT сгенерировать стартовый код API и изучите его. Выработайте привычку к постоянному переобучению. Участвуйте в хакатонах или кросс-функциональных проектах, чтобы заставить себя работать в режиме универсала. Скажите своему менеджеру, что хотите получить опыт в разных частях проекта. Адаптивность — это суперсила в начале карьеры.

  • Опытным разработчикам: Составьте карту своих навыков: в чем вы эксперт, с какими смежными областями вы знакомы лишь поверхностно? Выберите одну-две смежные области и начните в них разбираться. Если вы специалист по базам данных на бэкенде, освойте современный фронтенд-фреймворк или изучите основы ML-пайплайнов. Выполните небольшой проект в своей слабой области с помощью ИИ. Интегрируйте свою глубокую экспертизу в новые контексты; если вы специализируетесь на производительности веб-приложений, исследуйте, как эти навыки применимы к оптимизации ML-инференса. Выступайте за то, чтобы ваша роль стала более кросс-функциональной, или сами спроектируйте ее такой. Вызовитесь быть «чемпионом по интеграции» для проектов, затрагивающих несколько областей. Будьте наставником, чтобы распространять навыки, и сами учитесь у своих подопечных. Обновите резюме, чтобы отразить универсальность. Используйте свой опыт, чтобы выявлять шаблоны и передаваемые знания. Станьте образцом T-образного специалиста: глубокая экспертиза в своей области (дает авторитет и уверенность), но активное горизонтальное развитие.

В целом это универсальные советы, которые даже без развития AI имеют смысл.

Образование

Один из сценариев: университеты остаются важными, но с трудом поддерживают актуальность в части инструментов. При этом образование остается фундаментом и еще больше фокусируется на общих принципах построения ПО, архитектуре, а также заложат базу для тех самых T-shaped разработчиков. Университеты также могли бы начать обучать code review или общим принципам оценки кода, а также новым стандартам в части безопасного написания кода. Общая идея в том, чтобы хороший университет будет закладывать фундамент и развивать мышление в принципе.

В общем - ничего нового, большая часть университетов не даст вам знаний по облачным технологиям, современному DevOps и так далее.

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

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

Возможно, будущие студенты еще больше разочаруются в знаниях, которые дают университеты, а работодатели перестанут совсем ценить дипломы (так как непонятно, кто его получил - студент или AI-модель). В этом случае мы увидим очередной виток развития онлайн-курсов, стажировок, буккемпов, хакатонов и прочих активностей, которые организуются совместно с компаниями.

Сам ИИ предлагает новые способы обучения: ИИ-тьюторы, интерактивные песочницы для кода, персонализированное обучение вне стен университетов.

Что с этим делать:

  • Джунам и учащимся: Если вы учитесь в вузе, не полагайтесь исключительно на свою программу. Дополняйте учебный план реальными проектами: создайте веб-приложение, внесите вклад в open source. Ищите стажировки или программы co-op. Если в вашей программе не хватает горячих тем, изучайте их через онлайн-платформы. Если учитесь сами, сосредоточьтесь на убедительном портфолио: как минимум один существенный проект с хорошей документацией. Будьте активны в сообществе разработчиков: вносите вклад в open source, пишите технические посты. Создавайте сеть контактов через LinkedIn, митапы, dev-мероприятия. Найдите опытного наставника, который поможет с обучением и сможет поручится за вас. Учитесь непрерывно; период полураспада технических навыков короток. Используйте ИИ как своего личного репетитора.

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

  • Руководителям: Пересмотрите требования к вакансиям: действительно ли новому сотруднику нужен диплом, или вам нужны определенные навыки и способность учиться? Выступайте за найм, основанный на навыках (skills-first hiring), чтобы расширить пул талантов. Поддерживайте внутренние учебные программы внутри компании. Отстаивайте круги наставничества для джуниоров без формального образования. Взаимодействуйте с вузами и альтернативными системами обучения: выступайте консультантом, гостевым лектором, давай обратную связь по пробелам в учебных планах.

В этих советах вы тоже наверняка не увидели ничего нового. Я специально это выделяю, чтобы показать, что влияние новых инструментов на индустрию не будет на столько глобальным. В обучении хватает своих собственных накопившихся проблем, которые надо решать, но появление очередного Claude Code никак их не решает (и не должно).

Вместо итогов

Эти сценарии не исключают друг друга. В реальности скорее всего будет какой-то гибрид или мы увидим разное поведение в разных индустриях, разных компаниях, разных университетах.

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

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

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

Лучший способ предсказать будущее — активно строить его.

Комментарии (15)


  1. ncix
    14.01.2026 09:37

    Традиционный путь «научись программировать, устройся Junior, вырасти до Senior» почти не работает. Исследование Гарварда с участием 62 миллионов работников показало, что когда компании внедряют генеративный AI, количество занятых начинающих разработчиков падает примерно на 9–10% в течение шести кварталов

    "почти не работает" - это падение на 9-10% ?


    1. Neraverin Автор
      14.01.2026 09:37

      Так, тут похоже 2 мысли смешалось. Мысль первая - переход от научись программировать до устройства на работу джуном сейчас почти не работает. Точных цифр у меня нет - возможно они есть в постах по найму. Но сейчас шансы попасть куда-то джуном - это скорее 1%. Вторая мысль скорее показывает, что после внедрения AI джунов стали нанимать еще меньше, чем делали раньше.


      1. ncix
        14.01.2026 09:37

         Мысль первая - переход от научись программировать до устройства на работу джуном сейчас почти не работает.

        Вторая мысль скорее показывает, что после внедрения AI джунов стали нанимать еще меньше, чем делали раньше.


        В том смысле, что он и не работал до внедрения AI а теперь стал еще хуже?

        А "раньше" это когда? я свою первую работу в ИТ искал где-то полгода, имея некоторый любительский опыт, вакансий было очень-очень мало, деньги платили смешные, работать надо было много и стараться. Было это 22 года назад.

        Может времена, когда джуном брали с улицы всех подряд, - это просто некий короткий период истории развития ИТ, а не какое-то само-собой разумеющееся нормальное состояние "раньше" ?


        1. Neraverin Автор
          14.01.2026 09:37

          Да, не работал раньше, а теперь еще хуже.

          Вы правы, 20 лет назад было также. Я примерно тогда же искал работу джуном и мой опыт похожий.

          Но после 2015 (опять же мои ощущения) людей нанимали очень активно, а в ковид еще активнее. Попробую поправить текст, спасибо за комментарии.


          1. ncix
            14.01.2026 09:37

            Вы написали в статье, что пишите код "более 10 лет". А что было в промежутке между поиском работы джуна 20 лет назад и началом программирования "10 лет назад"? Так и не нашли и отложили на почти 10 лет? Просто интересно


            1. Neraverin Автор
              14.01.2026 09:37

              Было так - 20 лет назад начал писать код и был разработчиком 10 лет, врос до лида, потом ушел в менеджмент, и следующие 10 лет уже не писал production код, только для себя, в pet-проектах


  1. Plesser
    14.01.2026 09:37

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


    1. Neraverin Автор
      14.01.2026 09:37

      Моя основная идея - нет абсолютных ответов и решений. Даже если AI пузырь лопнет сам AI уже никуда не денется. Да, будет не 100 компаний, а всего 2-3-5. Это в целом нормально для любой хайповой технологии. Джуны тоже не одинаковые. Кто-то просто все пихает в AI и не включает мозг, а кто-то с пониманием, и заглядывает глубже. Вот таких и будут брать компании. Я это так вижу. Даже до AI я проводил десятки интервью с разработчиками, которые не понимают основ или не могут без гугла и/или stackoverflow написать FuzzBuzz. Теперь просто stackoverflow заменился на Cursor или другой инструмент. Но всегда были и те, кто разбирался, понимал глубже и так далее.


      1. Plesser
        14.01.2026 09:37

        Моя основная идея - нет абсолютных ответов и решений. Даже если AI пузырь лопнет сам AI уже никуда не денется.

        Он то останется, вопрос в каком виде он останется.

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

        Не будут, к сожалению. Впрочем таких джунов реально мало.


        1. Neraverin Автор
          14.01.2026 09:37

          Я не вижу почему нет. Более того, у меня прямо сейчас есть открытые позиции. И если бы пришел такой перспективный джун, с опытом AI, но при этом с пониманием - я бы выставил оффер.


          1. Plesser
            14.01.2026 09:37

            Ну у вас значит есть бюджет :). Я себе с трудом выбил бюджет на одного джуна.


  1. ncix
    14.01.2026 09:37

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

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


    1. Neraverin Автор
      14.01.2026 09:37

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


      1. ncix
        14.01.2026 09:37

        джунов берут в том числе для решения рутинных задач

        Рутина - это что-то повторяющееся. Таких задач как раз должно быть мало. Если много - похоже что в системе недостает абстракций или иным образом нарушается принцип DRY

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


  1. Sosnin
    14.01.2026 09:37

    Вброс: по мнению Алисы

    Почему senior developer может зарабатывать больше, чем senior system administrator:

    • Сложность задач — разработка требует решения сложных задач, управления проектами, обучения новичков, в то время как системное администрирование — управление серверами, настройка сетей, обеспечение безопасности данных.

    А ведь вроде русская... у нас же как:
    если сисадмин:
    - установи БД... и пофиг что ты CCIE и занят оптимизацией инфраструктуры 100к сетей прямо сейчас, быстро же надо.
    - настрой WiFi директору срочно, пофиг что ты прямо сейчас закрываешь инфр-ру от атаки
    если разраб:
    - "Господин Сеньор, рассмотрите Пожалуйста вопрос о возможности в этом году добавить отображение Даты рождения коллег в staff-портале"
    хотя... конечно многое от CIO и TeamLead зависит, но за 30 лет работы не видел контор, где не вытирали бы ноги о "senior sysadmin"
    P.S. я не принижаю знАчимость девелоперов, просто доходы реально сильно выше - как следствие отношение юзеров - другое