По мере развития искусственного интеллекта дискуссии о будущем многих профессий становятся все жарче. Мы попадаем в заколдованный круг: компании ищут людей с опытом, а задачи начального уровня автоматизируют с помощью ИИ. Но чтобы стать опытным, опыта нужно где-то набраться, а как это сделать, когда на работу берут только с опытом? Особенно остро кадровая проблема ощущается в сфере разработки.
Этой теме посвящена глубокая статья «Переосмысление профессии разработчика ПО в эпоху ИИ», которую написали корифеи ИТ-рынка: Марк Руссинович – технический директор Microsoft Azure, прославившийся созданием мощных системных утилит (набор Sysinternals) для белого хакинга Windows, и Скотт Хансельман – вице-президент и член технического совета Microsoft CoreAI и GitHub. Материал показался нам настолько интересным, что мы перевели его целиком, без купюр, чтобы вы могли сами ознакомиться с идеями авторов.
Спойлер: в статье есть о чем подискутировать.
Марк Руссинович и Скотт Хансельман
«Переосмысление профессии разработчика ПО в эпоху ИИ»
С появлением генеративного ИИ экономика программной инженерии дала трещину. ИИ-агенты для написания кода многократно повышают производительность труда опытных инженеров, но вместе с тем мешают начинающим разработчикам входить в профессию. Молодым сотрудникам не хватает экспертности и насмотренности, чтобы адекватно взаимодействовать с ИИ, а также проверять и внедрять результаты его работы. В итоге компании теперь стремятся нанимать опытных и автоматизировать работу, которую раньше отдавали младшим специалистам. Но без найма начинающих разработчиков кадровый резерв профессии иссякнет и следующего поколения опытных инженеров у бизнеса просто не будет.
Наш тезис прост: мы должны и дальше нанимать джунов, приняв как данность их сниженную производительность на старте, и сознательно проектировать системы с фокусом на профессиональный рост молодых кадров. Для этого нужно широко внедрять культуру наставничества, то есть сделать так, чтобы с помощью ИИ-систем опытные специалисты на ежедневных рутинных задачах учили начинающих разработчиков фиксировать ход рассуждения и выявлять ошибки. В этой статье мы рассмотрим, как такие системы могут помочь закрыть пробелы в учебном процессе и сохранить компетенции в разработке ПО даже в эпоху ИИ.
Ускорение через ИИ
В прошлом году разработка ПО вышла на совершенно новый уровень продуктивности. ИИ-агенты для написания кода теперь сами интерпретируют цели, ведут логические рассуждения на массивах данных из разных репозиториев и итеративно генерируют, тестируют и дорабатывают код, что меняет представление о возможностях даже небольших команд. Согласно данным самих компаний и новейшим независимым исследованиям, опытные разработчики, вооруженные такими инструментами, могут выполнять сложные задачи в разы, а иногда и на порядки быстрее.
В проекте Project Societas (так называется новый агент Microsoft для ее экосистемы Office) семь инженеров на неполной ставке всего за 10 недель выпустили предварительную потребительскую версию, создав больше 110 тыс. строк кода, который на 98% был сгенерирован через ИИ. Человек теперь не столько пишет код, сколько управляет процессом: ставит цели, проверяет корректность и внедряет результаты работы агента в единую систему.
Aspire — еще одна большая система, демонстрирующая, как эта трансформация реализуется на практике и меняет работу инженерных команд. Команды прошли через несколько этапов: сначала использовали локальных чат-ассистентов, затем разрешили агентам самим формировать запросы на включение изменений в код (Pull Request, PR-запрос) и в итоге перешли на ролевые модели, состоящие из людей и агентов, где каждый PR-запрос был готов к слиянию, а код проверялся через общий диалог людей и машин. Работа велась в длинных PR-запросах на GitHub, где старшие инженеры обсуждали архитектурные цели, а агент предлагал решения. В результате команды ускорили цикл обратной связи, повысили параллелизм и резко снизили издержки альтернативных возможностей при экспериментировании.
ИИ-агент ведет себя как стажер. Хотя ИИ ускоряет разработку ПО, известны примеры, когда агенты ведут себя как стажеры: выдают неоптимальные проектные решения или делают ошибочные выводы, которые разработчику без опыта может быть сложно распознать или поправить.

На Рис. 1 агент вставил команду sleep (задержку) в код, который падал из-за ошибки «состояние гонки» (race condition). Такое изменение лишь маскирует комплексную ошибку синхронизации, возникающую на более низком уровне, но начинающий разработчик может посчитать исправление эффективным, если ошибка больше не проявляется в тестах.

Агент даже не смог объяснить, зачем он вставил задержку, которая в данном случае никак не снижает риск возникновения гонок. Если сказать ему, что он не прав, агент признает ошибочность своих рассуждений (Рис. 2). Хуже того, машина может признать свою неправоту, даже когда ее рассуждения на самом деле корректны, а предположения пользователя наоборот неверны.
Только инженер, знакомый с используемыми протоколами синхронизации, примитивами синхронизации и архитектурой кода, может с уверенностью указать на ошибки агента и обладает знаниями, позволяющими направить его работу в правильное русло.

Во многих таких случаях прогресс зависит от пользователя, потому что именно он должен сказать агенту, как действовать дальше. Например, на Рис. 3 пользователь ставит задачу агенту вставить команды sleep (задержка), чтобы спровоцировать ошибку «состояние гонки» для проведения более надежной отладки.
Существуют десятки подобных примеров из различных проектов с ИИ-агентами, когда модель говорит, что все в порядке, а в коде остаются серьезные ошибки, реализуются неэффективные алгоритмы, и общий скрипт дублируется по всей кодовой базе. При этом модель игнорирует любые сбои и зависания как не имеющие отношения к текущей задаче, оставляет после себя отладочный код, использует «костыли», с которыми код работает не всегда, а лишь на некоторых тестах, и т.д.
Хотя ИИ-агенты быстро развиваются, компетенции человека при разработке ПО по-прежнему незаменимы. Разработка ПО не сводится к написанию кода. Даже самые надежные системы не могут полностью заменить такие сугубо человеческие качества как способность к оценочному суждению, креативность и адаптивность, которые необходимы для работы в условиях неопределенности, принятия сложных решений и обеспечения безопасности. Хотя агенты могут ускорить рабочие процессы и сократить ручной труд, им не хватает интуиции, чтобы предвидеть пограничные случаи и создать надежные решения. Если чрезмерно полагаться на ИИ, велик риск пропустить неочевидные ошибки, архитектурные изъяны и уязвимости, которые способен заметить только квалифицированный инженер. Контроль со стороны человека, его критическое мышление и знание предметной области незаменимы как при исправлении ошибок, так и при стимулировании дальнейших инноваций.
Гипотеза сужающейся пирамиды. Молодых специалистов обычно нанимают в отдел разработки ПО, чтобы повысить его пропускную способность, и дают им относительно простые задачи по исправлению ошибок и написанию кода. Выполняя эти задачи, они набираются опыта и знакомятся со стандартами программирования на проекте, а также с его архитектурой, реализацией, системами сборки и тестирования. При наличии желания и способностей некоторые из них могут вырасти в ведущих технических специалистов (техлидов), которые отвечают за более сложные задачи, охватывающие более крупные части системы, и делегируют задачи начинающим разработчикам. Как правило, на одного техлида приходится 10 начинающих специалистов.
В настоящее время генеративный ИИ меняет правила игры, создавая сильный перекос в сторону опытных разработчиков: он в разы усиливает тех, кто уже и так хорошо разбирается в системе, прочувствовал ее архитектуру, умеет проводить отладку в условиях неопределенности и интуитивно понимает, что нужно делать. А начинающим разработчикам, у которых нет выстраданных знаний о системе, очень сложно добавлять ценности в условиях активного использования ИИ. Согласно данным рынка труда, после выхода GPT-4 наем людей в возрасте 22–25 лет на начальные позиции в сегментах с высокой долей привлечения ИИ (таких как разработка ПО) упал примерно на 13%, в то время как число позиций для опытных специалистов наоборот выросло. В недавнем исследовании Гарвардского университета «Генеративный ИИ создает перекос в сторону опытных разработчиков: по данным опубликованных резюме и вакансий в США» отмечается, что ИИ, по всей видимости, уже создает ситуацию «с сильным перекосом в сторону опытных разработчиков».
ИИ усиливает опытных специалистов, но оставляет за бортом неопытных, тем самым создавая перекос в организации и уменьшая «основание пирамиды». Старый же подход – большая команда, где много разработчиков среднего и начального уровня, поступательно добавляющих функции в систему, – сейчас кажется нерентабельным.

Если пустить процесс на самотек, то все меньше начинающих разработчиков смогут выработать системное мышление, развить архитектурную интуицию и отточить то самое мастерство, которое у профессионалов оседает «на кончиках пальцев», в результате чего качество кода начнет падать, а внедрение инноваций замедлится. В своем посте «О работе с ИИ-ассистентами» Итан Моллик отмечает:
... Нам нужно научиться адекватно оценивать не процесс, а результат. Мы должны быть в состоянии проверить то, что выдал ИИ, и выбрать из этого то, что нам подходит. Более того, нам нужно наработать опыт использования ИИ, чтобы мы могли интуитивно определять, когда ИИ прав, а когда нет. Мы должны научиться понимать, в чем ИИ прав, в чем нет, а что мы проверить не можем, но в принципе готовы рискнуть и оставить «как есть». В результате возникает серьезная проблема: как научить молодых специалистов проверять работу ИИ в тех областях, которыми они еще не овладели, при том что сам ИИ мешает им набраться соответствующих знаний и опыта? И c этим надо что-то делать как можно скорее.2
Нужно целенаправленно нанимать новичков и вкладываться в их развитие и при этом не ждать, что благодаря ИИ молодые специалисты вслед за опытными разработчиками смогут так же кардинально повысить свою производительность труда. Иными словами, нужно дать новичкам погрузиться с головой в отладку, столкнуться с неизбежными при проектировании компромиссами, изучить, как это все реализуется на практике и собирается в конечный продукт. Только так они получат фундаментальные знания, которые позволят критически оценивать результаты работы ИИ. Специалисты должны расти, сталкиваясь с ИИ на практике, иначе все будет напрасно. Итан Моллик продолжает:
... каждый раз, отдавая задачу ИИ-ассистенту, мы упускаем возможность прокачать собственную экспертизу и критическое мышление, которые нам нужны, чтобы оценить работу такого ассистента. Да, на выходе мы можем получить нечто похожее на волшебство, но сами при этом становимся зрителем, а не волшебником и даже не его помощником.2
В новой модели и старшие, и младшие специалисты, работая бок о бок, должны иметь возможность не только выдавать результат, но еще и учиться в процессе работы. Опытные наставники должны оценивать слабые места и курировать ключевые области, используя ИИ как ускоритель, а не как костыль.
Программа наставничества. Чтобы решить проблему развития начинающих разработчиков в условиях активного использования ИИ, мы предлагаем программу наставничества, когда в реальных продуктовых командах молодые специалисты будут работать вместе с опытными наставниками. Наставники направляют и прокачивают своих подопечных, обучая их тому, как управлять агентными ИИ-инструментами, развивать критическое мышление и осваивать задачи, которые выполняют старшие инженеры. Такой подход гарантирует, что в эпоху ИИ инженер будет не только повышать производительность труда, но и постоянно постигать новое.

В начале 2025 года Массачусетский технологический институт выпустил исследование, согласно которому у взрослых, использовавших ChatGPT для написания эссе по методике SAT (Scholastic Assessment Test), накапливался «когнитивный долг»: их мозговая активность была ниже, чем у тех, кто писал сам, и спустя несколько минут таким «должникам» было сложнее вспомнить написанное.1 Непосредственная вовлеченность в процесс обучения дает более высокий результат. Обучая молодых специалистов работе именно в условиях активного использования ИИ, мы обеспечиваем долгосрочное развитие и сохранение инженерных компетенций, потому что новички изучают основы, учатся понимать сильные и слабые стороны ИИ, а также развивают критическое мышление, чтобы адекватно оценивать, когда ИИ доверять можно, а когда нельзя. Такие целенаправленные инвестиции обеспечивают устойчивость и прочность пирамиды на всех уровнях: от основания до вершины, причем в основании фокус идет не на рост производительности труда, а на приток свежей крови, то есть на развитие молодых специалистов, которые затем пополнят кадровый резерв.
Командам, использующим ИИ, важно выработать принципы, по которым они будут оценивать код и искать в нем проблемные места, то есть выработать то самое «чувство кода». Молодых специалистов следует не ограждать от процесса решения проблем, но наоборот вовлекать во все его аспекты. Они должны помогать своим наставникам с составлением промптов, отладкой и проверкой кода, и должны видеть, как человек-эксперт взаимодействует с ИИ. В данном случае самое ценное — это не повышение продуктивности, а обучение в контексте: начинающие разработчики выявляют заблуждения ИИ, спрашивают, почему агент выдал некорректный результат, и постепенно перенимают логику рассуждений, в которой давно работают их наставники. В свою очередь, старшие инженеры, взявшие на себя роль наставников, должны облечь свои экспертные суждения в конкретную форму, чтобы на них молодые специалисты могли учиться и чтобы ИИ из якоря, который тянет новичков вниз, превратился в фактор роста.
Наставничество - важный катализатор профессионального развития. Оно сочетает в себе и оценку результата, и ответственность за него. Благодаря этим усилиям программная инженерия как человеческий навык не исчезает в эпоху ИИ. Наоборот, старшие инженеры берут на себя дополнительную ответственность за то, чтобы помочь своим подопечным освоиться в профессии. Наставники – это специально обученные люди из числа старших инженеров, каждый из которых способен взять под крыло от 3 до 5 молодых специалистов. Имея фактически неограниченное количество токенов, наставник и ученик могут свободно экспериментировать: начать с малого и быстро двигаться от итерации к итерации с непрерывным обучением и масштабированием по мере развития программы.
Наставники и подопечные могут общаться с ИИ-ассистентами в «режиме новичка», когда по умолчанию все взаимодействие сводится к сократовскому коучингу перед генерацией кода. Андрей Карпатый в недавнем интервью упомянул: «[Как педагог] я не собираюсь сразу показывать вам решение, сначала попробуйте догадаться сами. Чтобы обучение не было пустой тратой времени, перед тем как озвучить правильный ответ, я должен дать вам шанс попытаться найти решение самостоятельно». Подобно тому, как виртуальный помощник Khanmigo от Khan Academy взаимодействует с пользователем в ходе изучения математики и естественных наук, ИИ-ассистент по программированию должен задавать молодому специалисту каверзные вопросы, объяснять ему свой процесс генерации кода, проверять усвоение им ключевых концепций и решений, а также активно отслеживать его сильные и слабые стороны на протяжении всего взаимодействия.
Наставники должны иметь возможность просматривать журналы чатов подопечных, чтобы отслеживать прогресс, точечно направлять процесс обучения и устранять пробелы в знаниях. Так можно гарантировать, что ИИ-ассистенты не только помогают писать код, но и повышают эффективность обучения и наставничества.
В идеале на одного наставника должно приходиться от 3 до 5 подопечных в зависимости от сложности ПО, их опыта и степени вовлеченности ментора. Ожидается, что программы наставничества будут длиться минимум год, а возможно, и дольше, в зависимости от необходимых навыков и сложности продукта.
Заключение
Генеративный ИИ спровоцировал фундаментальный сдвиг в парадигме разработки ПО, повысив производительность труда опытных инженеров и одновременно обнажив хрупкость кузницы кадров в ее традиционном виде. Если организации сосредоточатся только на краткосрочной эффективности и будут нанимать лишь тех, кто уже умеет управлять ИИ, то велик риск, что следующего поколения опытных разработчиков у бизнеса просто не будет. Во избежание этого следует взять целенаправленный курс на рост и развитие: последовательно встраивать наставничество и менторство в ежедневную работу, а также превращать ИИ-системы в инструменты обучения по методам сократовского диалога и управляемых рассуждений.
Будущее программной инженерии будет определяться не объемом кода, который может сгенерировать ИИ, а тем, насколько эффективно люди будут учиться, рассуждать и развиваться во взаимодействии с этими системами. Вкладываясь в начинающих разработчиков через наставничество, можно гарантированно сохранить компетенции и даже прокачать их до уровня профессиональной интуиции. Сохраняя баланс между автоматизацией процессов и обучением стажеров, мы обеспечим надежное будущее для профессии разработчика ПО на много лет вперед.
Сноски:
1.Kosmyna, N. et al. Your brain on ChatGPT: Accumulation of cognitive debt when using an AI assistant for essay writing task. arXiv (2025).
2.Mollick, E. On working with wizards. One Useful Thing (Sept. 10, 2025); https://www.oneusefulthing.org/p/on-working-with-wizards
3.Massoum, S.M.H. and Lichtinger, G. Generative AI as seniority-biased technological change: Evidence from U.S. résumé and job posting data. SSRN; https://ssrn. com/abstract=5425555 or http://dx.doi.org/10.2139/ssrn.5425555
Комментарии (45)

flaviy75
20.08.2026 12:17Я бы за джунов так не переживал, да, в срочной перспективе им не сладко, но мировая практика показывает, что передовые технологии проходятся по всей цепочке уровня квалификации и в конечном итоге догоняют и верхнеуровневых. Только в любом случае молодые всегда выкорабковываются, т.к. у них меньше обременения на старте.

mist56
20.08.2026 12:17Нужно нужно, только не сказано за чей счёт кормить неэффективных джунов.

Cordekk
20.08.2026 12:17Так с нейросетью любой джун станет эффективнее.

Serge1001
20.08.2026 12:17Каким образом?
Если он не может провалидировать/оценить результат
Тупо скопипастить? Просто доверять всему что выдаёт нейросеть?
Так для этого джун не нужен, можем одну нейросеть оставить

Cordekk
20.08.2026 12:17если честно, то и синьор-разработчик не может провалидировать всё, что пишет нейросеть, а вот джун с двумя нейросетями уже может.

Serge1001
20.08.2026 12:17Опять получается что джун не нужен.
Две нейросети справятся и без него))

Cordekk
20.08.2026 12:17Нужен, ему же можно платить меньше чем синьору.

Serge1001
20.08.2026 12:17Нужен, ему же можно платить меньше чем синьору.
Так а смысл платить джуну если нейросеть умнее чем он?
Он тупо копипастит даже не понимая что и спрашивает ту же самую нейросеть норм ли
Синьор хотя бы контролирует процесс, потому что есть опыт, понимание, и в своё время он это всё ручками делал

AleVaKa
20.08.2026 12:17Он тупо копипастит даже не понимая что и спрашивает ту же самую нейросеть норм ли
А как у вас такие джуны все эти нынешние этапы собеседования проходят?

Vicollel
20.08.2026 12:17Вы когда такое говорите - сколько синьор кода на хайлоде вы видели за жизнь? Нейронку надо прям ручками водить чтобы она адекватно вывозила контекст из 20 микросервисов и не наложила там кучу. Уж синьор то точно провалидирует код нейронки, и еще ответственность за этот код возьмет на себя, потому что больше просто некому а джун перепоручит ревью нейрокода нейронке и скажет "я сделяль", синьору или другому коллеге ревьюить потом этот нейрослоп

Cordekk
20.08.2026 12:17Не видел ни одного синьора который держал контекст 20 микросервисов. Да и к монолиту тоже относится. Всегда идут, проверяют всё заново, потом аппрувят правки, либо аппрувят правки, смотря только на соблюдение неких принятых правил разработки, типа наименования переменных, отступов и комментариев.

LinkToOS
20.08.2026 12:17если честно, то и синьор-разработчик не может провалидировать всё, что пишет нейросеть, а вот джун с двумя нейросетями уже может.
У авторов противоположное мнение. Они считают что опытный разработчик легко нейтрализует ошибки ИИ. А если разработчик без опыта, то ошибки ИИ добавляются к его собственным. Новичок свои ошибки с трудом исправляет, а тут еще ИИ подбрасывает.
И это стереотип - что нейросеть пишет код, а человек только проверяет.
Cordekk
20.08.2026 12:17Ну понятно же, что не нейтрализует. И до нейросетей опытные разработчики плодили баги и аппрувили баги при ревью кода от джунов.

mist56
20.08.2026 12:17Нейросеть - усилитель. Усилитель ошибок в том числе. Джун ни черта не поймёт, когда агента понесло не туда, не прервёт процесс, накинув коррекций в контекст, не задаст наводящий вопрос. А делать это надо ПОСТОЯННО. Не потому, что нейросеть/агент тупой, а потому, что так уж он работает по определению.

Cordekk
20.08.2026 12:17В случае с опытным разработчиком будет тоже самое, также придется откатываться и искать где свернули не туда. Просто опытный потратит на это меньше времени, что логично.

mist56
20.08.2026 12:17Вы не поняли. Поправки нужны в ПРОЦЕССЕ работы агента. Вот сидишь и смотришь в терминал, что он сейчас делает. И когда понимаешь, что начинает нести не туда - прямо в терминал накидываешь steer'ов. Вот опытный, знающий что должно получится - это сделает, а джун будет тупо результат смотреть и потом возмущаться тупостью модели. С сеньёрами многими такая же проблема на практике. То ли банальная лень, то ли нежелание работать с инструментом, то ли желание саботировать работу. В результате одни люди реально 10x, а другие хорошо, есил 2х, а некоторые индивиды даже меньше перформить умудряются. От таких в основном и идут разобрачающие тупость агентов статьи.

cdriper
20.08.2026 12:17Статья не отвечает на главный вопрос -- за чей счет будет этот банкет. Бизнес не будет заниматься благотворительностью.
опытные разработчики, вооруженные такими инструментами, могут выполнять сложные задачи в разы, а иногда и на порядки быстрее
На порядки быстрее выполнять задачи как раз могут лишь те, кто находится на начальном уровне карьеры -- ибо сами пишут код плохо и медленно, не могут оценить качество того, что выдают агенты.
А опытный разработчик как раз и нужен, чтобы на порядки замедлять скорость генерации нового кода для проекта, ибо слоп код ведет проект к точке, как в нем невозможно будет ничего изменить, ни агентами, ни руками.

mist56
20.08.2026 12:17Порядки это конечно сильное заявление, но в несколько раз - это совсем не сложно. Достаточно уметь параллелить работу, либо заниматься разноплановой работой. Условно - один терминал фигачит IaaC всякий, второй пилит один проект, второй другой.
У меня много мелких проектов / клиентов / своего и вот за счёт параллелизации перфомлю во многие разы продуктивней, чем ранее и берусь за такое, за что бы раньше никогда бы не взялся.
Понимаю, что не во всех проектах такое возможно, но в очень многих. Так, за счёт многотерминальности иксы и достигаются.
kenomimi
В статье придираются к единичным багам, когда как кожаный в погоне за KPI плодит сотни таких же багов, и всем всё норм, бизнес в массе своей заявил, что "пили быстрей фичи - качество вторично". Нейросети идеально подходят под эту парадигму, уже сейчас количество багов у какой-нибудь sonnet и среднего кожаного мидла "на потоке" отличаются на порядок в пользу ИИ...
А то что нет джунов, это нормально. Рыночек в стагнации, причем не только в РФ, но и в мире - остывает от безумного хайпа прошлых лет, когда хватали любую криворукую макаку с рынка труда чисто чтобы не успел конкурент. Ситуация устаканится, и снова возобновятся проекты поднятия джунов/стажеров.
Serge1001
Ну по факту с развитием ИИ - джуны больше не нужны. Теперь от них одни только расходы.
Какой смысл платить им за то что они без всякого понимания просто копипастят из нейросетки?!
И потом тем более будут не нужны, даже не факт что найдется место для сегодняшних мидлов
Нужно становится сверхпрофессионалом закрывающим все технические задачи бизнеса, чтобы просто оставаться в индустрии
EvilFox
А где ты профессионалов новых возьмёшь?
Serge1001
А они точно будут нужны?
Кажется нам уже нынешних профессионалов некуда девать, только самые опытные могут работу найти
EvilFox
Думаешь модели полностью заменят квалификацию? Сейчас они идут по пути специализации (никакой серьёзной генерализации не случилось и в ближайшее время не предвидется, это фундаментальная проблема), вне выученной специализации у моделей серьёзное непонимание, но чем дальше тем меньше таких пустот, тем не менее это не исключает их в принципе. Текущие модели отличный инструмент для квалифицированных людей, ну для неквалифицированных тоже, но если дать одну и ту же модель этим людям то между их продуктами будет пропасть, хотя часть формальных типичных требований будет соблюдено.
Кто отвечает за код? В норме это разного рода отвественные, они берут на себя риски, модель на себя риски не возьмёт. Если сокращаем штат то когнитивная нагрузка на сотрудников серьёзно растёт (и с моделями она другого характера), они будут выгорать, командный опыт будет теряться.
Пока что люди не бессмертны, текущие умрут, образуется дыра в индустрии (это явление не новое, обычно в такие моменты бегут за старичками которые давно списаны на пенсию и пытаются срочно родить новых спецов).
На тему опытных это пока ещё не утрясся рынок, да и кризисы сейчас (местами искусственные), денег мало у государств и компаний.
Serge1001
Индустрия у нас молодая, средний возраст опытного айтишника 30-40 лет, вы про какую пенсию говорите? Куда мы денемся?
И я уже сейчас вижу что многие люди с опытом работу найти не могут
Так и куда нам ещё этих стажёров/джунов пристраивать? Горшочек не вари...
EvilFox
Не могут найти потому что денег нет, индустрия кукожится.
К тому же рынок найма пока что мёртв:
HR в массе неквалифицированы (и это уже начинают понимать и увольнять их, т.к. современные модельки и то лучше разбираются) насколько что их найм даёт отрицательный эффект, фильтровать кандидатов они не умеют и выбирают по совсем не тем критериям что нужны компании.
Площадки и компании заспамлены как ботами так и людьми, не в последнюю очередь через очередную попытку галер/корпоратов/итп скинуть ЗП программистов, они наплодили кучу низкоквалифицированных людей через обещания 500к/наносек и советами врать в резюме и на собеседовании (сами собеседования тоже отдельная спец олимимпида на которую отдельно натаскиваются). Сейчас в массе рулит только нетворкинг.
rPman
каким вы видите этот процесс? кто будет это финансировать?
до ИИ стажеров нанимали компании, потому что их труд имел смысл, но после появления ИИ (не сейчас так скоро) этот труд будет обесценен.
что бы появились джуны и они развивались, нужно что бы компании начали за это платить, даже если им это не выгодно... не представляю что бы это произошло сейчас с крупными компаниями (да и с мелкими), без к примеру регуляторного пинка (а его сделать некому по иным причинам).
Caracupa
в чём вы видите "смысл" работы стажёров? Это всегда убыточно. Стажёров берут в надежде, что кто-то толковый останется в компании.
Serge1001
Толковые уходят в другие компании на зп x2 сразу после стажировки (у них теперь есть официальный опыт работы)
Получается подготовка стажёров это всегда убыточно для самой компании
Cordekk
Это неправильная организация работы, и проблема тут не в нейросетях, точно также было и раньше.
rPman
а как бы вы организовали работу?
вот вы нанимаете джуна, с маленькой зарплатой джуна, он набирается опыта, и в какой то момент, начинает хотеть большего, считая себя лучше... ваше же мнение о том что лучше может не совпадать, т.е. не угадали - воспитанник ушел, или наоборот, повысили зарплату раньше времени и держите недорослика на высокой зарплате, которую он не окупает.
Как будете момент ловить, когда зарплату поднимать? Проводить ежемесячные экзамены?
Cordekk
Не ежемесячные, но раз в квартал можно
Dhwtj
Очень нерациональное использование кожаных. Программисты показывают хорошие результаты если долго живут в проекте и не спешат. А в таком режиме у них отнимают возможности оптимальной работы.
LinkToOS
Это не придирка к багам ИИ. Авторы объясняют, почему ИИ усиливает разрыв между опытными разработчиками и начинающими.
Речь в статье идет не о сравнении джунов с ИИ, а о том как в новых условиях правильно развивать способности начинающих специалистов. ИИ ломает привычную схему профессионального роста разработчиков. Об этом речь.
Michio-sempaiq
Пока *опытный разработчик ревьют коммит в 100 строчек кода со сложным еле воспроизводим на пограничных случаях багом
Нормальный llm-щик покроет код линтерами, тестами, анализаторами и т.д. которые если не найдут эту багу сейчас, найдут ее после какой-то из итераций ретроспективы.
Перед тем как llm напишет хоть одну строчку кода нужно понимать как эта строчка может быть протестированна, какой импакт она несет в проект какие модули затронет.
И я не удивлюсь если завтрашний джун не сможет на собеседовании написать сортировку пузырьком, зато в его портфолио будут полноценные работающие проекты где им не написанно ни одной строчки кода и этот проект оттестирован и работает. Потому что пока мы сидели и набирались в компетенциях по использованию конкретного ЯП, он учился строить своих агентов, инструментов валидации, верификации и тестирования.
Dhwtj