Привет, Хабр!

«Разработчики исчезнут, но не все» — когда я услышал эту фразу в дискуссии на канале Dev Q&A, она засела в голове надолго.

Вот факт: за 10 лет средняя зарплата разработчика в России выросла с миллиона до 2,8 миллиона рублей в год. Стоимость часа работы — с $30-50 до $80-100, у крупных агентств доходит до $300-400. И это происходит как раз тогда, когда появились ИИ-ассистенты, low-code платформы и масса других инструментов, которые вроде бы должны всё удешевлять.

Евгений Барсуков (SimbirSoft), Константин Тельной (Simple), Илья Сазонов (Axiom JDK), Алексей Любко (Pryaniky) и другие практики собрались, чтобы разобраться, что на самом деле происходит с разработкой в эпоху ИИ.

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

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

Универсального решения никто из экспертов не предложил. Зато стало понятно: ИИ не заменяет джуниоров — он убирает простые задачи, превращая их в сложные вызовы для сеньоров. Роли меняются, проблемы становятся другими, возможности тоже.

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

Дефицит специалистов как главный драйвер роста цен

Когда говорят о росте стоимости IT-разработки, первым делом вспоминают инфляцию и «зажравшихся программистов». И цифры правда впечатляют. Но реальность прозаичнее, чем кажется: рынок просто не справляется с объемом задач.

«Проблема в том, что на рынке недостаточно ресурсов. Рост стоимости происходит именно потому, что специалистов не хватает, а общая трудоемкость проектов далеко за пределами того, что рынок может предложить. Министр цифрового развития регулярно говорит о том, что дефицит IT-специалистов в России составляет около миллиона человек — это миллион дополнительных позиций, которые некем закрыть», — объясняет Александр Сахаров, директор по работе с партнерами компании «Диасофт».

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

«Стать сеньором сейчас гораздо сложнее. Порог входа в разработку снизился благодаря ИИ, но путь к экспертизе стал длиннее и круче. Разрыв между джунами и сеньорными специалистами сильно увеличивается, и поэтому последние начинают оцениваться дороже», — отмечает Иван Тимонов, DevOps/MLOps-инженер с опытом проектирования масштабируемой инфраструктуры.

Парадокс в том, что всё это происходит на фоне сжимающихся бюджетов заказчиков.

«Сейчас у крупных корпораций бюджеты серьезно подрезаны. РЖД публично заявила о сокращении на 50%, все инвестиционные программы перенесены на 2028 год. Идет серьезнейшая конкуренция за эффективность разработки. Еще два года назад можно было приходить с баснословными цифрами под флагом импортозамещения, сейчас люди начинают серьезно думать, прежде чем вкладываться», — отмечает эксперт.

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

ИИ не заменяет программистов, а меняет их роли

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

"Большинство рутинных задач, которые раньше поручались джуниорам и мидлам, быстрее и легче сделать сейчас с помощью LLM, дописав важные детали руками или проведя ревью. Скорость разработки вырастает, потому что те же самые CRUD-операции теперь можно писать в 3-4-5 раз быстрее", — делится опытом Константин Тельной, Senior Backend Developer в Simple.

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

Однако не все так однозначно с влиянием ИИ на разные уровни разработчиков. "У нас в компании в первую очередь включились в работу с LLM именно джуны. Оказалось, что нам нужно теперь не мучить джунов классическими задачами, а учить их работать с ИИ по определенным шаблонам. Это действительно повышает качество и скорость реализации проектов", — возражает Алексей Любко, CTO компании Pryaniky.com.

По его наблюдениям, меняется сама природа работы разработчика. "Теперь нужен программист-дирижер, программист-коммуникатор, который, с одной стороны, знает, какую 'таблетку' скормить LLM, как построить правильные промпты, чтобы получить нужный результат. А после этого может как хирург аккуратно доработать то, что сгенерировала модель, чтобы поднять качество на должный уровень", — добавляет эксперт.

Ситуация приводит к парадоксу: джуниорские позиции становятся менее востребованными, но при этом задач меньше не становится. "Работы, которую нужно сделат��, стало только больше, потому что появились новые инструменты, ускоряющие разработку. Мы видим расслоение: разница между сеньорами и джунами сильно увеличивается. Но в конечном итоге всё равно нужен кто-то, кто понимает, как работает система. Робот классный, но если что-то идет не так, нужно разбираться. И критические вещи требуют, чтобы ответственность была на человеке", — резюмирует Тельной.

Проблема качества: когда скорость не равна ценности

Способность быстро генерировать код звучит как решение всех проблем. Но появляется новый вызов: как контролировать качество того, что создаётся в разы быстрее?

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

Здесь возникает главная развилка отрасли.

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

Илья Сазонов, директор по продуктам Axiom JDK, видит эту проблему на практике каждый день.

«Я много лет наблюдаю один и тот же процесс при разработке на бэкенде. Делается проект, стартует, всё нормально, потом нагрузка немного вырастает — и всё, проект ложится. После этого нужен опытный специалист, который придет и объяснит, почему проект упал. У тех, кто его делал, такой экспертизы обычно нет. Что будет, если эти же люди сделают что-то с помощью LLM — не ляжет ли это решение, когда немножко вырастет нагрузка? У меня большие сомнения. Наверняка ляжет, и наверняка понадобится человек, который сам этот код не писал, но может с помощью систем диагностики понять, что не так, и поправить нужные строчки. Сейчас таких людей мало», — делится наблюдениями эксперт.

Евгений Барсуков, руководитель направления SDET в SimbirSoft, добавляет важный нюанс о том, кто останется востребованным.

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

Low-code платформы и микросервисная архитектура: контроль качества на уровне системы

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

«Возникает задача контроля качества. Мы говорим о комбинированном подходе: одной LLM и одними джунами жить не получится. Нужны политики — информационной безопасности, работы с CRUD-операциями, микросервисной архитектуры, архитектурных правил для создания и компоновки микросервисов, горизонтального масштабирования. Таких вещей около 15, которые нужно контролировать», — объясняет Александр Сахаров, эксперт из Диасофт.

Речь не о написанных на бумаге гайдлайнах, которые все игнорируют. Речь о low-code платформе, где эти правила зашиты в код.

«Сеньоры и solution-архитекторы — те, кто получает самые большие зарплаты в IT — решают эти вопросы так, чтобы все остальные, кто работает с LLM и собирает компоненты, не нарушали определенные правила. Мы используем кодогенерацию на базе LLM и наших собственных правил. Такая комбинация low-code нового поколения и LLM дает максимальный результат», — продолжает специалист.

Результаты измеримы.

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

Важный момент: речь именно о системном контроле, а не о договорённостях.

«Когда мы говорим про качество, все эти правила зашиты в экосистему как строгие блоки, где код контролируется со всех сторон. У нас, например, фронтенд полностью автоматически генери��уется. Все CRUD-операции полностью автоматически создаются. Вся стандартная обвязка автоматически генерится. Фронтенд-разработчики добавляют только очень сложные вещи — например, какую-то анимацию, которой нет в шаблонах LLM», — рассказывает специалист.

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

«Если говорить про B2B, наша компания обслуживает больше 300 клиентов, причем среди них крупнейшие банки России. В одном только ВТБ 25 миллионов клиентов и порядка 400 внутренних систем. Альфа-банк — тоже около 400 систем. Такой же уровень сложности в других индустриях. У Альфа-банка, например, порядка 10 тысяч IT-специалистов только для поддержки мобильного банка и связанных систем. Без специализированной микросервисной платформы управлять такой сложностью просто невозможно», — объясняет эксперт масштаб задачи.

Кризис джуниоров: откуда возьмутся сеньоры завтра?

Low-code платформы и ИИ решают проблему производительности и качества для опытных разработчиков. Но возникает новый, стратегический вопрос: если джуниорам больше не нужно решать рутинные задачи, как они будут расти до уровня сеньоров?

Проблема проявилась неожиданно быстро.

«Впервые год-полтора назад ко мне на собеседование на позицию мидла пришли люди, которые не умеют программировать. Натурально, просто не могут. Говорю: нужно код написать, простой, который любой может написать во сне, — а люди просто не способны кодить. Вот такое состояние индустрии», — делится шокирующим наблюдением Илья Сазонов из Axiom JDK.

По его мнению, проблема не только в инструментах.

«Кризис продиктован не только появлением новых инструментов, но и тем, что люди поняли: можно прийти в профессию программиста, потому что на собеседованиях очень добрые люди возьмут вас, если скажете "я хочу программировать". Раньше всегда было: если человек хочет — значит, научится. А сейчас человек проходит собеседование со словами "я хочу программировать", а потом считает, что всего уже добился и может просто получать зарплату. Таких с каждым годом становится всё больше», — констатирует эксперт.

Александр Сахаров из Диасофт признаёт фундаментальную проблему отрасли, на которую пока нет ответа.

«Откуда тогда будут браться сеньоры, если мидлы и джуны не нужны? Честно сказать, не знаю, что на это ответить. Мы находимся в переходном периоде», — констатирует эксперт.

Есть ли выход из этой ситуации? Илья Сазонов делится опытом, который работал до недавнего времени.

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

Евгений Барсуков из SimbirSoft предлагает переосмыслить саму градацию специалистов.

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

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

«Я высокого мнения о том, как провожу собеседования. Считаю, что смогу задать такой вопрос, на который ChatGPT не поможет ответить. Но нужно быть реалистом — рано или поздно ИИ доберется и сюда. Думаю, в ближайшее время собеседования будут проходить офлайн, в клетке Фарадея, чтобы никакие устройства не работали. Будет два человека: один проводит собеседование, другой стоит за спиной и смотрит, что кандидат никуда не подглядывает», — с иронией заключает специалист.

Где искать экономию: парадокс аналитики

Когда встаёт вопрос об удешевлении разработки, первым делом думают о сокращении программистов или замене их ИИ. Но эксперты предлагают посмотреть на проблему с неожиданной стороны.

«Давайте увеличим стоимость аналитики — будет дешевле стоимость разработки. На самом деле, если во главу угла поставить экономию и заложить это в аналитику, можно на нужное число процентов всё уменьшить, вписаться в бюджет. Качественная аналитика — дешевле разработка», — формулирует парадоксальный принцип Алексей Любко.

Александр Сахаров из Диасофт развивает эту мысль конкретным опытом.

«Мы 10 лет вкладывались в аналитику, чтобы создать инструментарий, который позволяет разработчикам получать удовольствие от работы, делая то, за что им платят деньги, а не заниматься рутиной — написанием CRUD-операций, размышлениями о правильном доступе к базе без нарушения ГОСТ. Инструмент генерирует код в результате, радикально снижает трудоемкость и повышает эффективность в разы», — объясняет эксперт.

Евгений Барсуков из SimbirSoft подтверждает важность начальной фазы проекта.

«Ответить точно, на сколько можно удешевить, невозможно. Нормальное решение — сместить решение многих проблем на самое начало проекта. Тогда действительно чем дальше в разработку, тем будет проще, а в итоге и дешевле. Чем больше мы предусмотрим в начале, включая риски, тем проще и дешевле будет в итоге. Серебряной пули пока нет», — резюмирует эксперт.

Илья Сазонов приводит конкретный пример, где небольшие инвестиции дают заметный эффект.

«Например, есть закрытый банковский контур без доступа в интернет. Разработчику приходится гуглить на отдельном компьютере, к которому нужно обеспечить доступ — много мероприятий. Поставишь в этот контур LLM, которая отвечает на вопросы разработчика, — и скорость разработки магическим образом вырастает, хотя особо ничего не сделал. Таких приемов достаточно много. Сколько можно сэкономить? Большой вопрос, но считаю, что достаточно много», — делится опытом специалист из Axiom JDK.

В итоге общий принцип прост: небольшие инвестиции в начале — в аналитику, в правильную инфраструктуру, в продуманную архитектуру — дают кратную экономию на всех последующих этапах. Это работает эффективнее, чем попытки сэкономить на зарплатах разработчиков.

Что дальше: между оптимизмом и реализмом

Казалось бы, решения найдены, инструменты работают, произв��дительность растёт. Но остаётся главный вопрос: куда движется индустрия и какой она будет через 5-10 лет?

Александр Сахаров из Диасофт видит чёткий тренд.

«На одного программиста будет существенно больше и функционала, и качества, которое он должен выпускать. Джуны в какой-т момент будут не нужны, потому что их заменят дата-аналитики, которые могут написать скрипт. Зачем фронтенд-разработчик, когда аналитик может вставить все нужные скрипты на форму без обращения к фронтенду? У нас, например, фронтенд полностью автоматически генерируется, все CRUD-операции создаются автоматически. Фронтенд-разработчики добавляют только очень сложные вещи — какую-то анимацию, которой нет в библиотеках», — описывает один из сценариев эксперт.

Но Константин Тельной из Simple не исключает и более радикальный вариант.

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

Пока все обсуждают разработчиков, Евгений Барсуков из SimbirSoft замечает кое-что важное.

«Мы говорим о применении ИИ и роли разработчика, основываясь на одном звене в процессе разработки. Но изменения происходят во всех ролях — у аналитиков, тестировщиков, DevOps-инженеров, менеджеров команд. Видя рост зарплат у разработчиков кода, мы не замечаем, как растут зарплаты у других специалистов, которые тоже применяют ИИ для увеличения производительности. Проблема в том, что внедрение этих инструментов происходит несогласованно. В результате процесс вместо сокращения и ускорения удлиняется и усложняется», — анализирует эксперт.

А вот что интересно: меняется не только сама профессия, но и путь в неё.

«Появляется тренд — если раньше на разработку учились целенаправленно, тратили много времени, то сейчас много людей переключаются из других профессий. Например, были врачом — переключились на разработку и могут принести свою экспертизу как врача. Это делает их уникальными специалистами в своей области. Порог создания продуктов с помощью программирования сильно снизился, и каждый желающий может с помощью LLM что-то своё сделать. Чтобы не затеряться в море подобных проектов, нужно делать что-то выше среднего», — говорит Иван Тимонов.

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

«Сейчас разработчик говорит: "У меня идея", созванивается с аналитиком, на коленке что-то делают, и к вечеру это уже идет на A/B-тест. Это большой плюс», — по словам Алексея Любко.

А Илья Сазонов из Axiom JDK честно признаётся: «Непонятно, что будет. Мы действительно в переходном процессе. До этого года всё работало отлично. Сейчас многое под вопросом».

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