Российские ИТ-шники доигрались. Крупный бизнес спешит заменить их искусственным интеллектом в ближайшие годы

«Ростелеком» намерен решить проблему нехватки ИТ-кадров внедрением искусственного интеллекта. Оператор запускает собственную ИИ-платформу по разработке программного обеспечения «Лукоморье», лицензию на использование которой в дальнейшем смогут приобрести сторонние компании, столкнувшиеся с дефицитом программистов.

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

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

В России действительно наблюдается нехватка ИТ-специалистов – они начали стремительно покидать Россию еще в ковидный 2020 г., и всего через несколько месяцев дефицит вплотную приблизился к отметке в 1 млн человек. Весной 2022 г. отток ИТ-шников за границу усилился, но многие, живя за рубежом, продолжали работать в России. Однако власти и крупный ИТ-бизнес дали понять, что таким удаленщикам они не рады.

Вакансии программистов закрыты
Идея «Ростелекома» по замещению ИТ-шников искусственным интеллектом – это часть проекта «Лукоморье», презентация которого состоялась в середине лета 2023 г. Это внутренняя платформа компании для разработки ПО полного цикла – с ее помощью будет создаваться софт в сферах бизнес-анализа, проектирования, тестирования и создания документации.

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

В скольких ИТ-шниках Россия нуждается на конец сентября 2023 г. – неизвестно. В середине июля 2023 г., по словам российского министра связи Максута Шадаева, их дефицит был на уровне 500-700 тыс. человек.

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

«Сначала "Лукоморье" будет применяться в собственных проектах оператора, затем платформу планируется продавать другим компаниям, которые столкнулись с кадровым дефицитом», – приводит издание слова представителей «Ростелекома».

Оператор не называет размеры вложений в развитие «Лукоморья», но примерные цифры все же известны. Глава ассоциации предприятий компьютерных и информационных технологий (АПКИТ) Николай Комлев, сообщил изданию, что на начальном этапе инвестиции в проект со стороны «Ростелекома» могут составить минимум 1,5 млрд руб.

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

Количество генеративных нейросетей, умеющих писать программный код, постоянно увеличивается – такие сервисы есть как минимум у Google и Microsoft, но и Россия в этом плане не отстает. Например, у Сбербанка с весны 2023 г. есть нейросеть GigaChat, на основе которой в конце сентября 2023 г. был создан сервис GigaCode – ИИ-помощник программиста, помогающий ему писать код. Над подобным проектом работает и «Яндекс».

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

Когда много – это еще хуже
В настоящее время «Ростелеком» и другие компании вынуждены замещать недостающих ИТ-специалистов алгоритмами и технологиями, но в обозримом будущем это может не потребоваться. Как сообщил изданию гендиректор разработчика заказного ПО Only Кирилл Владимиров, в ближайшие 10 лет Россия может перейти от дефицита ИТ-специалистов к их переизбытку ввиду того, что все больше вузов открывают соответствующие направления обучения. Также не стоит забывать и про онлайн-школы, в которых можно стать джуном в ИТ-сфере через пару-тройку недель виртуального обучения.

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

Но ИИ – это угроза не только работникам ИТ-сферы. Офисные клерки тоже могут лишиться работы – IBM намерена в кратчайшие сроки заменить нейросетями до 30% своего административного персонала, а это не десятки и не сотни, а тысячи человек.

Jackers писал(а):

Вы не обрабатываете случай выхода за границу значений типа в рантайме.

Так в моем коде и нет случая выхода за границу значений типа в рантайме. Он там просто не предусмотрен.

В с++ int и long это разные типы.

Переменной shift можно присваивать значения диапазона типа int это диапазон -2 147 483 648 до 2 147 483 647.
При попытке инициализировать shift числами за пределами этого диапазона это как в питоне числу присвоить строку.

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

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

В рамках языка с++ я сделал программу корректную на 100% в пределах его возможностей. И алгоритм в ней работает правильно.

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

Добавлено спустя 9 минут 31 секунду:

aiwalev писал(а):

Да и настраивать ничего не нужно: произойдет автоматическое обрезание до заявленного размера типа.

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

Но вряд ли найдется идиот который будет пилить модуль для перехвата
int n = 1000000000050000000000;
Проще не писать такой код, а если случайно кот на клавиатуру наступил, то компилятор сделает предупреждение и будет возможность исправить.

barmen писал(а):

Но вряд ли найдется идиот который будет пилить модуль для перехвата
int n = 1000000000050000000000;

Трудолюбивый компилятор обработает и такое, отбросив невпихиваемое и предупредив юзера.
Например, gcc x86-64 занесет в n значение -2099547136. Но большинство конечно же, как и люди, предпочтут не работать, выкинув ошибку компиляции.

Заметил еще один момент.
Например я говорю боту: хочу генератор случайной строки. Объявляем строку. В цикле в каждой итерации генерируем рандомное число. Дальше расписываем как количество итераций будет равно длине строки. Какие аргументы должна принимать функция. И еще различные пожелания.

По сути эту программу быстрее самому написать чем составить алгоритм на человеческом языке. Сам алгоритм получается больше чем текст исходного кода.

Получается пока ты у него что-то просишь, за это время можешь сам всё написать.

Так же тут выше один человек выложил историю общения с ботом где он просил написать шифр Цезаря. Там у него текста запросов и пожеланий на пару листов А4. А сама программка на 10 строк. При этом в начале бот выдавал не самый лучший код который надо было анализировать и снова корректировать запросы. Программу можно было написать самому намного быстрее чем попросить ее у бота.

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

barmen писал(а):

Так в моем коде и нет случая выхода за границу значений типа в рантайме. Он там просто не предусмотрен.

Конечно же может. Это понятно любому программисту. Это опять же следствие ваших же требований, что нужно предусматривать все случаи.

barmen писал(а):

Переменной shift можно присваивать значения диапазона типа int это диапазон -2 147 483 648 до 2 147 483 647.
При попытке инициализировать shift числами за пределами этого диапазона это как в питоне числу присвоить строку.

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

barmen писал(а):

Моя программа диапазоне int чисел работает корректно. В ней нет пользовательского ввода поэтому числа не из диапазона записать некому.

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

barmen писал(а):

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

Можете и свои многобайтовые смайлы рассмотреть, если хотите.

barmen писал(а):

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

Это вообще здесь не причем.

barmen писал(а):

В рамках языка с++ я сделал программу корректную на 100% в пределах его возможностей.

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

barmen писал(а):

И алгоритм в ней работает правильно.

А потом переделали код на питоне и стало неправильно.

barmen писал(а):

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

Хотите сказать, что нельзя в c++ обработать случай с выходом за границу значений? Если так, то вы похоже очень плохо разбираетесь в с++ и вам рано вообще что-то оценивать.

barmen писал(а):

Но вряд ли найдется идиот который будет пилить модуль для перехвата
int n = 1000000000050000000000;

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

barmen писал(а):

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

Проще было не выставлять требований, которые ваша программа не смогла выполнить.

Добавлено спустя 11 минут 58 секунд:

barmen писал(а):

В более сложных проектах будет еще хуже.

Вы не знакомы с программированием и таким понятием как декомпозиция.

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

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

barmen писал(а):

В новых стандартах есть возможность вычисления на этапе компиляции и там наверняка можно что-то сделать.

Вычисления на этапе компиляции можно условно считать встроенным пнемного продвинутым калькулятором и не более.
Роботизированная замена старого доброго #define.

barmen писал(а):

Но вряд ли найдется идиот который будет пилить модуль для перехвата
int n = 1000000000050000000000;
Проще не писать такой код, а если случайно кот на клавиатуру наступил, то компилятор сделает предупреждение и будет возможность исправить.

Та и особо модули не нужны, просто предусмотреть обычным сравнением.

Jackers писал(а):

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

Условие при котором она не работает возможно только при пользовательском вводе который в программе не реализован. Вы требуете реализовать обработку пользовательского ввода которого нет.

При реализации ввода пользователя придется реализовать ограничения не только на диапазон чисел, но и на ввод строк и прочих символов.

Вы почему в своем питоне не предусмотрели запрет строк во входных данных? Дайте догадаюсь. Наверно то той же причине почему я не предусмотрел выход за пределы диапазона.

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

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

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

Jackers писал(а):

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

Прежде всего нужно проверять, чтобы не было повторов и зацикливания. Что на общечеловеческом именуется "сказкой про белого бычка". Хорошо, чтобы не было возврата к упомянутой выше "проверки проверяющих", приведу простой исторический пример.
Самый копируемый фрагмент StackOverflow за всю историю ошибочен!
В 2010-м году на StackOverflow в качестве ответа программист привел кусочек кода с ошибкой.
И этот кусочек оказался по статистике самым копируемым: точно также как ИИ рыщет по интернету, программисты этот кусочек находили и копипастили вовсю в свое ПО, продолжая его распространение особенно через ГитХаб. Естественно предположить, что подавляющая часть его проверяла. И выставляла для следующей скачки и проверки.
И вот спустя 10 лет оказалось, что этот код некорректен.
The most copied StackOverflow snippet of all time is flawed!

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

barmen писал(а):

Условие при котором она не работает возможно только при пользовательском вводе который в программе не реализован.

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

barmen писал(а):

Вы требуете реализовать обработку пользовательского ввода которого нет.

Где я такое требую?

barmen писал(а):

При реализации ввода пользователя придется реализовать ограничения не только на диапазон чисел, но и на ввод строк и прочих символов.

Зачем реализация ввода пользователя?

barmen писал(а):

Вы почему в своем питоне не предусмотрели запрет строк во входных данных? Дайте догадаюсь наверно то пой же причине почему я не предусмотрел выход за пределы диапазона.

Так я и не выдвигал таких требований к коду - это сделали вы. На практике вы в своем коде это не реализовали. Что тут непонятного?

barmen писал(а):

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

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

barmen писал(а):

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

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

barmen писал(а):

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

Возможности языка как раз позволяют обработать такой случай. В чем проблема?

barmen писал(а):

А это значит если моя программа корректно работает в рамках int32 диапазона.

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

barmen писал(а):

То претензий к ней быть не может.

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

barmen писал(а):

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

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

barmen писал(а):

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

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

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

barmen писал(а):

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

Неограниченного диапазона нет нигде. И даже в Питоне Васильевиче, какие бы былины о нем ни слагались.

Добавлено спустя 6 минут 15 секунд:

Jackers писал(а):

....сравнивали код на питоне с кодом на с++, что не корректно

не "не корректно", а бессмысленно.

aiwalev писал(а):

Самый копируемый фрагмент StackOverflow за всю историю ошибочен!
В 2010-м году на StackOverflow в качестве ответа программист привел кусочек кода с ошибкой.

Да, я отчасти помню эту статью на хабре. На SO такое встречается и поэтому ответы имеют свойство редактироваться своими авторами или сообществом по истечении времени.

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

aiwalev писал(а):

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

Это правда.

Jackers
Разговор насчет валидации данных начался с того, что программа выданная ботом не работала при ВАЛИДНЫХ входных данных. Я на это и обратил ваше внимание.

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

Ничего сверхъестественного я не требовал.

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

Jackers писал(а):

алгоритмическая сложность не зависит от кол-ва строк

Я говорил что много строк и выше сложность. А не о зависимости строк от сложности.

Jackers писал(а):

сравнивали код на питоне с кодом на с++, что не корректно

сравнивал алгоритмы которые и там и там одинаковые.

Jackers писал(а):

переделали код на питоне, но неправильно.

ну что поделаешь. не получилось с первого раза. Надеюсь мне больше никогда не придется этого делать. Но разговор был о том что бот выдал gounoкод с кривым неработающим алгоритмом.

barmen писал(а):

Разговор насчет валидации данных начался с того, что программа выданная ботом не работала при ВАЛИДНЫХ входных данных. Я на это и обратил ваше внимание.

Работала. Как и вы просили. Проход по char был. Результаты корректные. А то, что вы потом стали предъявлять в качестве требований не обсуждалось, но раз уж вы их обозначали, то вам был предоставлен другой код на питоне.

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

barmen писал(а):

Никакой проверки типов я не требовал.

Никакой проверки типов и нет.

barmen писал(а):

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

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

barmen писал(а):

Ничего сверхъестественного я не требовал.

Требования к устойчивости были.

barmen писал(а):

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

Это я не требовал, а вы требовали. Разница только в том, что требовали к чужому коду, а не к своему.

barmen писал(а):

Я говорил что много строк и выше сложность. А не о зависимости строк от сложности.

И снова неправильно. Вы не разбираетесь в алгоритмической сложности. Нет никакой зависимости от кол-ва строк.

barmen писал(а):

сравнивал алгоритмы которые и там и там одинаковые.

Тогда сравнивайте на псевдокоде, если реализации на ЯП не нужны.

barmen писал(а):

ну что поделаешь. не получилось с первого раза.

Если бы с первого. Пришлось несколько раз указывать в чем ошибка.

barmen писал(а):

Надеюсь мне больше никогда не придется этого делать.

Программирование это не ваше.

barmen писал(а):

Но разговор был о том что бот выдал gounoкод с кривым неработающим алгоритмом.

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

Jackers писал(а):

Нет никакой зависимости от кол-ва строк.

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

Добавлено спустя 1 минуту 48 секунд:

Jackers писал(а):

Никакой проверки типов и нет.

требование чтобы вместо int не приходил long это и называется проверка типа. Потому-что тот и другой оба типы и они разные.

barmen писал(а):

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

Вы не понимаете, что кол-во строк здесь не уместно - это не критерий оценки.

barmen писал(а):

требование чтобы вместо int не приходил long это и называется проверка типа. Потому-что тот и другой оба типы и они разные.

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

Добавлено спустя 5 минут 22 секунды:

barmen писал(а):

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

Дополню. Вот вы сказали про зависимость:

Цитата:

Я говорил что много строк и выше сложность

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

Jackers писал(а):

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

Числа лежащие выше диапазона int имеют тип long. Это два разных типа.

чтобы защитить программу в которой функция принимает аргументы с типом int досточно просто не передавать в эту функцию аргументы с другим типом.
Что я и сделал

Код: выделить все

int shift = 100500;
encrypt(shift)

Этого досточно чтобы данные с типом long не попали в функцию encrypt(int)

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

Вы же в питоне не передаете строки туда где ждут числа? Здесь почему должно быть не так?