О чем поговорим

1. Экскурс в историю

2. AI as commodity

3. Что LLM умеют сейчас в сфере разработки ПО, с примерами кода

4. Ближайшие перспективы на 1-3 года

5. Прогноз на горизонт >3 лет

6. А что же менеджмент?

7. Краткие итоги

Если взглянуть на ИТ индустрию изнутри, хотя бы за последние 20 лет, то технологии и продукты сменяли друг друга довольно активно, вознося на пик спроса то одних специалистов, то совершенно других. Если брать рынок РФ, то в крупном корп секторе таких волн было несколько: была волна разработчиков OEBS (который, все еще работает в очень крупных компаниях, начиная с телекома, заканчивая известными интернет компаниями), был взлет и падение SAP/ABAP, был Siebel CRM, в части интеграции были монстры типа Oracle SOA или Tibco, в BI - Oracle BI и Sap Bobj, но сейчас все эти продукты, а вместе с ними тысячи их разработчиков перешли в разряд legacy с исчезающе малым числом вакансий и низкими зарплатами. Тем не менее многие из разработчиков почивших технологий и продуктов, выскочили из плена и зашли в новые направления, дав шанс своей карьере на развитие.

Наблюдая за этой картиной из казалось бы стабильного поезда [backend] разработки, где за 20 лет никто из mainstream продуктов-технологий не шел в закат, эта статья попытка взглянуть на эту ситуацию с т.з. "я не сидим ли мы в поезде, паровоз которого уже горит" и поделиться соображениями в части влияния больших языковых моделей (LLM) на труд разработчиков (и шире, ИТ специалистов некоторых профессий), рынок труда в этой сфере в кратко- и средне срочной перспективе.

Экскурс в историю

Любые аналогии, с одной стороны позволяют человеку при оперировании чем-то новым, “зацепиться” за знакомые шаблоны поведения и упростить прогнозирование, но, с другой, контекст каждой конкретной области знаний, периода времени и людей, важен, поэтому прогноз “по аналогии” лишь задает некий baseline, но как все повернется в реальности, часто остается только гадать. Тем не менее, посмотрим как в истории за последние пару веков технологический прогресс кардинально менял профессии и рынок труда. Начнем с того, какие очевидные профессии “пострадали” от технологического прогресса?

1. Конюхи и изготовители телег/повозок - с развитием автотранспорта спрос на эту профессию сильно упал.

2. Фонарщики - с появлением и распространением электрического освещения профессия лампочников, которые зажигали и тушили газовые уличные фонари, постепенно исчезла.

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

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

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

Промежуточный вывод: помимо варианта “LLM никак не повлияет на разработчиков”, есть еще два сценария: кардинальное снижение числа специалистов с одновременной трансформацией профессии и сценарий полного исчезновения профессии ввиду появления кардинально более эффективной замены.

AI as commodity

На заре появления электричества, профессия электрика была уважаема, вполне хорошо оплачиваема и во многом “близка к магии” (ничего не напоминает сейчас)? Тем не менее, благодаря эволюционному развитию в сфере энергетики, профессия, не то, чтобы исчезла, но стала максимально массовой и настолько базово необходимой, что помимо пожарных, скорой и полиции, существуют аварийные службы энергетиков, призванные в режиме 24 на 7 решать проблемы с этой базовой инфраструктурой. При этом относительный уровень зарплат, по отношению к другим профессиям в сравнении с уровнем зарплат электрика\энергетика на старте появления профессии, упал, как и базово необходимый уровень знаний и умений. Эта аналогия дает нам четвертый сценарий развития рынка труда разработчиков в связи с появлением и развитие LLM: постепенная коммодитизация AI и профессии разработчика, снижение базовых скилов для подавляющего числа участников профессии и, как следствие, уравновешивание зарплат на уровень тех же самых электриков.

Что LLM умеют сейчас в сфере разработки ПО

Теперь попробуем кратко описать, что же LLM дают уже сейчас в сфере разработки софта.

Документирование кода. Вы просто подаете на вход функцию или метод и LLM может описать не только входящие данные и возвращаемый результат, но суть выполняемых функцией действий и дать комментарии к существенным местам в коде. Качество документирования ожидаемо выше на изолированных участках кода на популярных языках программирования. В случае если бизнес логика “размазана”, комментарии сваливаются в простой пересказ кода человеческим языком. Ниже приведен один из примеров, где LLM не только откомментировала код, но и дала вполне валидные замечания по качеству кода, его corner cases и привела советы, как код исправить. Ниже и далее ответ сгенерирован GPT4, изначальный код найден в интернете по поисковой строке: python поиск второго минимального значения

promt:

Напиши комментарий к python функции get_second_min что она делает, что принимает на вход

a = [1, 2, 3, 4, 5, 6]
def get_second_min(a):
	k = min(a)
	for i in range(len(a)):
		if a[i] == k:
			a.pop(i)
			return a.pop(i)
			break

print(get_second_min(a))

Ответ GPT4 (текст, код и снова текст):

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

a = [1, 2, 3, 4, 5, 6]  # Исходный список чисел. 
def get_second_min(a):
  k = min(a)  # Находим минимальный элемент в списке. 
  for i in range(len(a)):  # Проходим по индексам списка.
    if a[i] == k:  # Если текущий элемент списка равен найденному минимальному элементу.
        a.pop(i)  # Удаляем этот минимальный элемент из списка.
        return a.pop(i)  # Пытаемся вернуть следующий за удаленным элементом и выходим из функции.
        break  # Break после return в этом случае излишен, так как return уже прекратит выполнение функции.
print(get_second_min(a))

Ключевые комментарии и замечания к функции:

• Функция предназначена для поиска второго по величине минимального элемента в списке a.

• Функция сначала находит минимальный элемент в списке (k) и затем ищет его индекс, чтобы удалить.

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

• В текущей логике функции есть серьезная проблема: после вызова pop(i), список a изменяется, и попытка выполнить return a.pop(i) может привести к ошибке "index out of range" (индекс вне диапазона), особенно если минимальный элемент был последним в списке. Это происходит потому, что после удаления элемента все последующие элементы сдвигаются на одну позицию влево, и индекс i может указывать за пределы обновленного списка.

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

Более надежный способ реализации функции поиска второго минимального элемента - это сначала отфильтровать минимальный элемент из списка, а затем вновь применить функцию min() к оставшимся элементам. Alternately, you could sort the list and select the second element; however, this approach may not be efficient for large lists.

Вся длинная портянка текста, от строки "Ответ GPT4" и до данной строки написана не автором, а именно GPT4. И, признаюсь, такой ответ меня приятно поразил, особенно в сравнении с обычными подсказками IDE, даже таких продвинутых как intellidj или pycharm.

Исправление ошибок и отладка: исправление ошибок, не только синтаксических, но и более кардинальных, включая ошибки в дизайне решения

promt: исправь код функции get_second_min по твоим же комментариям

Ответ GPT4

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

def get_second_min(a):
    # Проверяем, что в списке как минимум два элемента.
    if len(a) < 2:
        return None  # Невозможно найти второй минимальный элемент в списке из менее чем двух элементов.

    # Находим первый минимальный элемент.
    first_min = min(a)

    # Создаем новый список без этого первого минимального элемента.
    filtered_list = [elem for elem in a if elem != first_min]

    # Если после фильтрации список оказался пустым, это означает, что все элементы в исходном списке были одинаковы.
    if not filtered_list:
        return None

    # Находим и возвращаем минимальный элемент среди оставшихся, то есть второй минимальный в исходном списке.
    second_min = min(filtered_list)

    return second_min

# Пример использования функции:
a = [1, 2, 3, 4, 5, 6]
print(get_second_min(a))  # Выведет 2, что является правильным ответом.

Написание тестов. Эта рутинная, казалось бы не приносящая впрямую бизнес эффект, работа, тем не менее важна с тз надежности и поддерживаемости ПО, и здесь LLM уже демонстрируют вполне достойные результаты, снимая с разработчика эту не слишком интересную обязанность.

promt: напиши тесты к этой функции

Ответ GPT4

import unittest

class TestGetSecondMin(unittest.TestCase):
    def test_regular_list(self):
        self.assertEqual(get_second_min([1, 2, 3, 4, 5, 6]), 2, "Должно быть 2")

    def test_list_with_negative_numbers(self):
        self.assertEqual(get_second_min([-10, -5, 0, 5, 10]), -5, "Должно быть -5")

    def test_list_with_duplicates(self):
        self.assertEqual(get_second_min([5, 2, 3, 2, 1, 4]), 2, "Должно быть 2")

    def test_list_all_same_elements(self):
        self.assertIsNone(get_second_min([1, 1, 1, 1]), "Должно вернуть None")

    def test_list_two_elements(self):
        self.assertEqual(get_second_min([2, 1]), 2, "Должно быть 2")

    def test_list_single_element(self):
        self.assertIsNone(get_second_min([1]), "Должно вернуть None")

    def test_list_empty(self):
        self.assertIsNone(get_second_min([]), "Должно вернуть None")

    def test_list_with_floats(self):
        self.assertEqual(get_second_min([1.1, 2.2, 3.3, 4.4]), 2.2, "Должно быть 2.2")

if name == 'main':
    unittest.main()

Несмотря на ошибки, в целом как некоторый baseline данные тесты можно брать за основу.

Отладка, Поддержка кода и рефакторинг: Здесь LLM могут :

• найти и исправить и синтаксические ошибки или помочь с правкой deprecated кода на свежую реализацию

• найти логические ошибки

• дать рекомендации по улучшению кода

• дать ревью по коду

Написание SQL кода. Я выделил этот пункт специально по двум причинам, во-первых для ряда ролей типа аналитика данных, владение SQL является одним из ключевых навыков. С другой, иногда для backend разработчиков, “измученных” ORM, необходимость писать SQL вызывает затруднения и тут LLM могут помочь.

Запрос:

Дана схема данных

CREATE TABLE orders (
  "id" INTEGER,
  "date" TIMESTAMP,
  "shop_id" INTEGER,
  "customer_id" INTEGER,
  "amount" INTEGER,
  "product_id" INTEGER
);

INSERT INTO orders
  ("id", "date", "shop_id", "customer_id", "amount", "product_id")
VALUES
  ('1', '01/01/2024', '1', '1', '10', '15'),
  ('2', '01/01/2024', '1', '2', '10', '15'),
  ('3', '03/01/2024', '3', '2', '10', '15'),
  ('4', '03/01/2024', '1', '2', '10', '15'),
  ('5', '02/01/2024', '1', '1', '20', '25');

напиши sql запрос который выведет id покупателей, которые совершили две покупки подряд в одном и том же магазине

Ответ GPT4

Важно обратить внимание на фактическое определение "две покупки подряд в одном и том же магазине". Для интерпретации этого условия как "две покупки в последовательные дни без других покупок между ними в этом магазине", запрос может быть более сложным, чем предполагалось. Также важно учесть, что даты в вашем примере вставки данных указаны в формате, который может не соответствовать стандарту ISO для TIMESTAMP в PostgreSQL, например, и требуют преобразования. Однако, исходя из предоставленных данных, предположим, что дата в формате 'DD/MM/YYYY'.

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

shop_id

и

date

для каждого

customer_id

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

WITH ranked_orders AS (
    SELECT
        customer_id,
        shop_id,
        date,
        LAG(shop_id) OVER(PARTITION BY customer_id ORDER BY date) AS prev_shop_id,
        LEAD(shop_id) OVER(PARTITION BY customer_id ORDER BY date) AS next_shop_id,
        LAG(date) OVER(PARTITION BY customer_id ORDER BY date) AS prev_date,
        LEAD(date) OVER(PARTITION BY customer_id ORDER BY date) AS next_date
    FROM orders
)
SELECT DISTINCT
    customer_id
FROM ranked_orders
WHERE 
    (shop_id = prev_shop_id OR shop_id = next_shop_id) AND
    (
      -- Для проверки последовательных дат необходимо преобразовать строки в даты,
      -- пример для PostgreSQL:
      -- (date::timestamp - prev_date::timestamp = '1 day'::interval OR
      -- next_date::timestamp - date::timestamp = '1 day'::interval)
      
      -- Но если приемлем любой интервал:
      shop_id = prev_shop_id OR
      shop_id = next_shop_id
    );

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

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

• текущие LLM не знают контекст, включая существующие стили и паттерны проектирования принятые в компании, как следствие, чтобы получить решение в заданной стилистике необходимо давать подробное описание в тексте запроса

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

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

• написание конфигурационных файлов: docker файлы, конфиги k8s, nginx etc со всеми подобными задачам LLM уже вполне справляется, значительно экономя время для разработчиков, для которых данные технологии и задачи скорее саттелиты, нежели ежедневная обязанность, знания о которой есть на кончиках пальцев

• написание базового кода с небольшим отличием от обычно используемого. Хороший пример: как подключить второй (или более одного) источник данных для Hibernate? Или как решить проблему “N+1 Selects Problem” опять же в Hibernate?

Ближайшие перспективы на 1-3 года

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

Прогноз на горизонт >3 лет

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

1. Требования к профессии разработчика начнут трансформироваться, смещая внимание со знания конкретных фреймворков и библиотек в сторону system design, базового computer science, бизнес доменов и soft skills

2. Повышение производительности разработчиков и DevOps, возможно деградация некоторых проектных ролей в небольших командах, например на небольшом проекте вместо выделенного devops или тестировщика, их функции могут взять на себя разработчики под контролем выделенных DevOps и Тестировщиков, которые будут шариться на несколько команд и выполнять функции тех лидов. Как следствие - уменьшение среднего размера команд и, возможно, снижение спроса на devops и тестировщиков junior/middle уровня за счет перераспределения части их задач на разработчиков и повышения производительности оставшихся специалистов.

3. Снижение потребности на рынке в джуниор разработчиках и на то есть несколько причин: если раньше запрос на ускорении разработки закрывался через увеличение штата, в тч через найм и обучение джунов, то теперь, с тз инвестиций в ускорение разработки и увеличение ее объемов, у джунов появился конкурент - инвестиции в повышение производительности мидлов\сеньоров через LLM. И даже оставшимся джунам LLM могут принести пользу - с применением LLM джун может заменить трех джунов ранее.

4. Рост требований к senior и архитектор позициям, на плечи которых будут взвалены задачи по проектированию решений, code review того, что напишут LLM (джуны и middle разработчики с помощью LLM) и предотвращению превращения кодовой базы решений в “лапшу и ад”, вызванные легкостью генерации простых и неправильных решений.

5. Появление платформенных LLM команд в крупных компаниях. LLM станут важным и необходимым элементом инфраструктуры разработки крупных ИТ игроков, в которых будут сформированы команды по разработке\адаптации\интеграции LLM во внутреннюю инфраструктуру. Есть вероятность фрагментации как интернета, так и AI решений, так что многие крупные компании будут вынуждены создавать свои LLM, нанимая под эти задачи соответствующих специалистов. Как определить, кто эти “крупные ИТ игроки”? На мой взгляд это могут быть те же компании, у которых есть свое приватное облако, здесь наличие облака внутри компании и развитие LLM внутри не имеет причинно следственной связи а, скорее, является корреляцией, позволяющей определить нужных игроков рынка.

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

7. Повышение доли фрилансеров full/max stack на рынке, способных (с помощью LLM) выполнять полный цикл работ (не только back и фронт, но и mobile+devops) по разработке простых базовых приложений для небольших компаний.

8. Влияние на Low и No Code платформы, здесь возможны два сценария:

   • Синергия LLM с Low\No Code платформами, поддерживающая их развитие и рост.

   • Замедление темпов роста а в перспективе медленное угасание low code /no code платформ.

   Главное преимущество Low\No Code в сокращении сроков разработки, снижении затрат на разработку за счет привлечения менее квалифицированной (чем обычные back\front end разработчики) рабочей силы и демократизации разработки ввиду снижения требований к квалификации в обмен на ограниченность в функционале и закрытую экосистему в сравнении с обычными подходами и языками программирования.

   Здесь LLM приносят такие же выгоды, сокращая time to market, косты на разработку и порог входа, без ограничений, накладываемых Low Code платформами, поэтому мой прогноз - рынок таких платформ не будет показывать значимых темпов роста, выйдет на плато интереса и займет свою ограниченную долю на рынке.
   

9. Влияние на профессию аналитика данных. Здесь влияние и уровни трансформации могут быть выше, чем для классических разработчиков. LLM уже не плохо справляются с написанием SQL кода а размер контекста существующих моделей достаточен для включения в запрос схемы CDM слоев DWH. Это приведет к усилению смещения акцентов в профессии аналитика данных: понижение роли хардов (SQL и Python) и повышение роли продуктовых знаний, знаний в области математики и бизнес домена. Появление диалоговых систем, когда бизнес заказчики смогут сформировав текстовый запрос получить нужные ответы, снизит требования к количеству аналитиков, выполняющих ad hoc запросы, что снизит число начинающих/middle специалистов в профессии, повысив спрос на специалистов, способных извлекать новые знания и предлагать продуктовые гипотезы.

10. Влияние на профессию DevOps/SRE. Базовые требования к специалистам данных профессий сейчас высоки и требуют часто, глубокий знаний особенностей тех или иных систем, протоколов, не говоря уже о базовых знаниях в CS. LLM понижают порог оперирования базовой инфраструктурой, например в части написания конфигураций, анализе логов и траблшутинге. Это породит трансформацию профессии, в сторону больших акцентов на system design и понимание принципов построения распределенных систем, нежели на, утрировано, заучивание linux\k8s команд.

А что же менеджмент?

Это отдельный комплексный сложный вопрос, который сейчас активно исследуется на примере пилотных команд применяющих в разработке решения a-la copilot. Здесь возможны изменения роли линейных руководителей (лидов и engineering managers): уменьшение числа разработчиков в команде (не в штате в целом), увеличение среднего уровня разработчиков ввиду снижения доли джунов перемещает фокус внимания линейных руководителей в небольших и средних компаниях с администрирования команд и их развития (из джунов в мидлы) на управление звездами и принятие технологических решений в т.ч. в части LLM. LLM становятся одним из факторов производительности (не важно, реальной или мнимой) и вопросы их выбора, применения и развития становятся ключевыми.

Итоги

1. Инвестиции в LLM с тз замещения разработки являются венчуром. Успех не гарантирован, но тот (имеется ввиду корпорат), кто не попробует, рискует остаться за бортом, если технология взлетит. А значит все более или менее крупные компании будут пробовать в меру своих бюджетных возможностей и склонности их СТО к риску.

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

3. Более того, успех применения LLM в автоматизации служб поддержки, сопровождения юристов, в финансовых департаментах, продажах и далее (см отчет Goldman Sachs) вызовет рост спроса на прикладных разработчиков, применяющих LLM в этих областях. По сути, это новые вакансии для выполнения новых задач, чья реализация сократит людей в других профессиях.

4. Широкое внедрение LLM снизит спрос на джунов ввиду повышения производительности мидлов, автоматизации задач, которые ранее делегировались джунам и, повышения производительности оставшихся джунов. Т.е здесь "снизит спрос" не равно "полностью уничтожит".

5. Внедрение LLM может привести к росту производительности разработчиков, аналитиков данных и DevOps/SRE, как минимум за счет помощи в рутинных и смежных операциях. Что касается самой разработки - сейчас во многих компаниях идут весьма активные эксперименты, результаты которых пока попадают в публичное поле весьма дозированно.

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

7. Хорошим маркером угрозы для работы в классической разработке (backend, frontend, mobile), может стать успех или не успех LLM в разработке для ERP, в первую очередь для популярных за пределами РФ SAP, OEBS, Salesforce etc. В этой области есть отлаженные процессы формальной постановки задач, есть хорошая наработанная база исходников с бизнес описанием (на чем можно учить LLM) и, как кажется, путь к высокоэффективным в разработке LLM здесь короче и ближе, чем в Java/C++/C# etc. Если консалтеры и заказчики прочувствую реальную отдачу от LLM в такой прикладной разработке, следующие, кому стоит напрячься это уже разработчики на классических языках вне ERP\CRM коробок. А значит, надо будет искать следующий поезд, куда пересесть, чтож, таков путь.