Джуна уже можно заменить LLM-кой? А откуда возьмутся сеньоры? Мнения айтишников

Число вакансий для новичков по-прежнему невелико, есть мнение, что джунов можно оптимизировать с помощью low-code/no-code инструментов.

«Раньше была популярна Agile-трансформация, сейчас — AI-трансформация»

Андрей, Product Manager с 15+ лет опыта

—  То, что менеджмент в ИТ решил: «Всё, мы снижаем найм джуниоров, их работу теперь будут выполнять мидлы и сеньоры с AI-инструментами» — это факт. Мы видим это по цифрам.

Да, джуны нужны для преемственности. Но компании хотят срезать косты, поэтому тема AI будет заходить моментально.

Думаю, ближайшие полгода-год станут пробными. Сейчас многие компании пытаются понять, как именно стоит использовать AI — потому что без умения это не даст нужного эффекта. Например, недавнее исследование MIT показало, что 95% компаний не видят ценности от внедрения ИИ — лишь около 5% пилотных AI-программ достигли быстрого роста выручки, остальные же практически не оказали измеримого влияния на прибыль и убытки (исследование основано на 150 интервью с руководителями, опросе 350 сотрудников и анализе 300 публичных внедрений ИИ — прим. Dzika).

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

Это огромная работа, которая занимала недели и месяцы. Теперь же этот цикл сократился до дней — благодаря AI-инструментам.

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

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

Я скажу, что это уже работает на 60%. Раньше я бы попросил выполнить эти задачи джуниора — а теперь справляюсь сам, лишь с помощью соответствующих инструментов. 

Бизнес-аналитикам внедрение генеративных инструментов также помогает сократить время работы на 20-30% — если они их правильно используют. Здесь всё зависит от людей, контекста, разрешенных на проекте AI-инструментов и того, какими данными можно делиться.

Вывод: да, джуна уже можно заменить на определённых задачах и в продакт менеджменте.

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

«Посоветовал бы нынешним QA джунам осваивать смежные с AI темы»

Александр, Senior QA Engineering Manager с 15+ лет опыта

— Не так давно наша компания приняла решение, что нам необходимо двигаться в сторону внедрения AI-инструментов во все процессы разработки и тестирования, закупила лицензии под различные AI-агенты, LLM, IDE, плагины и стартовала программу обучения сотрудников.

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

По итогу из всего набора AI инструментов мы оставили GitHub Copilot, который в энтерпрайз версии может работать и как плагин для чата с LLM, и как AI-агент для анализа исходного кода в репозитории и генерации кода или изменений в коде прямо в среде разработки. Среди прочего, в целях анализа результатов, воспроизводимых различными AI-инструментами и LLM моделями, используем Cursor и Claude Code в качестве дополнительных сред разработки. 

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

Но вот с другими видами автоматизации тестирования пока есть нюансы.

Так, полноценная автоматизация тестирования UI или мобильных приложений опробованным нами AI-агентам с различными LLM-моделями оказалась пока не под силу — как из-за сложности имеющегося кода, так и из-за невозможности AI-агентов достучаться до контента страниц/скринов приложений и сделать качественный поиск элементов на них. Готового решения данной проблемы пока не нашли, поэтому движемся в сторону разработки собственного MCP-сервера.

С использованием GitHub Copilot для написания UI тестов качество кода и точность результатов пока оставляют желать лучшего — менее 40-50%, что я считаю плохим результатом. Джун «пилит» такие тесты пусть и не быстрее, но лучше.

С мобильными приложениями всё ещё сложнее, там качество кода и точность результатов не превышают 20-25%.

Любой бизнес нацелен на оптимизацию расходов. Условно, зачем компании 50 джунов, если взамен можно оставить 5-10 мидлов, которые с помощью AI-инструментов сделают тот же объём работы?

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

Лично видел примеры, когда вместо 200-300 строк кода ожидаемых изменений QA джун с AI-инструментами получал на выходе 1200 строк кода посредством шаблонной кодогенерации. Причём предложенное решение было неоптимальным и с «поломанными» паттернами. Быстро, но не эффективно — в долгосрочной перспективе чревато большими проблемами.

Я считаю, что со временем возможности людей без опыта/QA джунов попасть в айти и в QA-тестирование и автоматизацию, в частности, будут только ухудшаться. Количество вакансий и количество людей, которые нужны в этой сфере, уже уменьшаются.

Думаю, совсем скоро с помощью AI инструментов закроется имеющийся спрос на API тестирование и автоматизацию, затем — UI тестирование и автоматизацию, а после уже доберутся до мобилок и каких-то более комплексных вещей. Прогресс рано или поздно возьмёт своё. 

AI Models Testing сейчас очень свежая и перспективная тема, которой пока занимается буквально пару человек в нескольких небольших стартапах. 

«Есть ещё пессимистичный сценарий»

Илья, Senior FullStack PHP & JS/T с 11 годами коммерческого опыта

— Отчасти заменить можно. Джуну всегда нужны чёткие инструкции по выполнению задачи, проверка и помощь в её выполнении.

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

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

Лично я использую LLM полтора года,в последнее время активнее. Сразу ChatGPT, потом Copilot, сейчас — Supermaven для «автокомплита» и Cursor.

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

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

Для простых алгоритмов стараюсь всегда использовать LLM. Да, я сам могу написать за 15-30 минут, но с LLM это занимает секунды и ещё минуту — проверить глазами.

У ИИ не сильно хорошо с фронтом, так как он не может протестировать сгенерированную вёрстку (или же я не нашел такого сервиса как минимум). Поэтому доведение верстки до идеала и последующие правки — только человеку. На данном этапе это вполне можно поручать джуну. 

С фиксом багов у LLM также плохо. Можно всё объяснить, и всё равно модель исправляет не то, пытается искать баг там, где его нет… Пару раз пробовал, опыта мало, даже не пытаюсь поручать исправление багов машине, так как предыдущий опыт отрицательный. 

PHP к тому же дебажить не умеет. А может, и JS не умеет, по крайней мере, Cursor мне такое не предлагал. А значит, дебаг — это снова пока задача для человека. 

Но, к моему удивлению, оказалось, что мелкие правки в какой-то рандомной точке проекта LLM делает быстрее человека.

У меня проект средней величины. Так как я работаю с ним только 2 года, а всего у меня проектов 4-5, то я не знаю все детали. Дал сделать правку LLM — и она за минуту её внесла. Хотя я бы минут 10 только разбирался, где вообще этот код находится. Для себя решил, что LLM надо поручать поиск кода, ей это проще. 

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

По обучению джунов и перспективе — слишком сложный вопрос и для меня неактуальный. С одной стороны, думаю, что джунам или школьниками надо запрещать использование LLM, чтобы они сами учились кодить. С другой, через 20 лет, возможно, никто вручную код писать не будет. 

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

Программирование не стоит на месте: появятся новые языки, новые фреймворки, программисты в том или ином виде будут востребованы.

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

«Оператор со знанием специфики в любом случае нужен»

Виктор, Senior PHP Developer с 8 годами опыта в ИТ

— Думаю, кто-то должен запускать и объяснять AI суть задачи и затем проверять корректность и правильность работы. То есть в любом случае нужен оператор.

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

Я на постоянной основе ежедневно использую Github Copilot для улучшения производительности работы. Например, для написания технической документации для API приложений. Однако в любом случае приходится глазами пробегать по каждой строке и проверять качество, а для этого нужен уже наработанный опыт. Поэтому оператору для ИИ в любом случае нужно проверять качество и работоспособность кода.

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

Пробовал писать сложные задачи (большой и сложный SQL запрос), используя Grok — он не осилил. Дошло до циклических ошибок — исправляя одну, он делал другую и так по кругу. Пришлось самому по кусочкам собирать.

Это как высшее образование двух студентов: один просто ходил на пары ради диплома, а другой вникал в каждую лекцию — кто из них останется по специальности на должности условного сеньора. Я думаю, с LLM будет так же.

Если студент нацелен на ИТ, LLM — это крутейший учебник для разжёвывания материала. Использовать в работе только там, где сам руками уже делал. В таком случае опыт будет нарабатываться, и LLM будет хорошим помощником.

Как новичкам сейчас повысить свою ценность на рынке кадров? Хороший вопрос, наверное, его рекрутингу задавать нужно. Я полгода пробивался в IT, но это было уже лет 6-8 назад.

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

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

Для студента или джуна это будет дремучим лесом, но пройдя хоть немного такого леса и показав его нанимающему — сразу плюс 100 очков.

«Может ли в будущем быть нехватка сеньоров? Могу только на это надеяться. Мне лично в целом будет выгоднее»

Влад, Senior Software Engineer, Fullstack (Python, Go, JS и т. д.) с 15 годами опыта

— Джун вырастет в мидла и уйдет в другую компанию, так как смена работы почти всегда выгоднее новой должности в той же компании. А вот LLM никуда не денется.

Я использую LLM-ки по максимуму — для написания кода, тестов; переводов на другой язык; корректировки UI. Обсуждаю с Claude и ChatGPT архитектуру новых фич. Применяю для создания интерактивных демок своих идей. Всё чаще использую ChatGPT вместо гугла для поиска информации. 

Быстро набросать MVP какой-то новой фичи — вообще отлично. Но нужен контроль, и надо иметь достаточно опыта, чтобы понимать, когда LLM выдала приемлемый результат, а когда его лучше выбросить и писать самому.

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

Лично у меня насчёт джунов довольно пессимистический взгляд. Отвечу с поправкой на то, что у нас в компании нет джунов уже около 10 лет.

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

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

У меня 15 лет опыта, и первые 11-12 лет, мне кажется, были на фоне повсеместной нехватки сеньоров, и с ИТ-индустрией всё было в порядке.

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

«И в 2035 ещё порулю». Почему таксист, дальнобойщик и логист не боятся AI (и вам не советуют)

По теме

«И в 2035 ещё порулю». Почему таксист, дальнобойщик и логист не боятся AI (и вам не советуют)

Как AI (не) вредит школьникам — рассказывает учитель и родители

По теме

Как AI (не) вредит школьникам — рассказывает учитель и родители

Живешь в Польше?

Подпишись на полезный канал о финансах Złoty Dzik