Ксаверий, Терминус и языковые модели против кодировщиков

Генеральный директор NVIDIA Дженсен Хуанг высказал мнение, что каждый сможет стать программистом с помощью ИИ

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

Прогнозам о вымирании профессии программиста чуть меньше лет, чем самой профессии. Первые смелые предположения появились еще в конце 1950-х, вместе с распространением Кобола и Фортрана. Программисты в машинных кодах постепенно стали программистами на языках высокого уровня. Новый стандарт Фортран-2023 (ISO/IEC 1539-1:2023) был принят сообществом в прошлом году.

25 лет назад Михаил Донской, автор программы "Каисса", первого чемпиона мира по шахматам среди программ, в статье "Жизненный цикл программиста" утверждал, что цикл связанной с технологией профессии -- 60 лет, и он походит к концу, как это произошло для шоферов автомобилей.

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

С другой стороны, чтобы писать простые программы для своих нужд, не прибегая к услугам профессиональных софтостроителей, специалистам других областей, от инженеров и учёных до счетоводов и клерков, тоже достаточно взять короткий курс Питона, как 40 лет назад -- Бейсика. На фото -- книга 1983 года "Бейсик бухгалтера для Apple II" (Accountant's BASIC for the Apple II).

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

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

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

А что значит "правильно"?

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

Языки типа упомянутых Кобола, Фортрана или Питона -- формальные. Это значит, что написав в тексте ЕСЛИ яблоко В моя_корзина ТО печатать("Уже куплено") можно быть уверенным в однозначности "понимания" смысла написанного транслятором, и, соответственно, ожидаемых результатов выполнения программы.

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

Не зря программирование называют еще и "детальным проектированием".

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

Методы автоматизированной спецификации программ проникали в отрасли под видом CASE-инструментов, MDA-подхода и DSL -- специализированных языков полупрограммирования-полуописания. Интерес к таким подходам также подогревался ажиотажем в СМИ, но потом сходил "на нет". То есть, данные подходы не исчезли, они продолжают применяться, но весьма ограниченно.

В чем проблемы?

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

Оно вам нужно?

Большинству оказалось не нужно.

CASE -- выбор небольшой части проектировщиков для отдельных частей и этапов разработки. Лучше всего, видимо, прижился подход в области баз данных. DSL оказались полезны прежде всего как инструментарий настройки и персонализации в сложных прикладных системах. Про "1С: Бухгалтерия" слышали, наверное, многие. Можно ли использовать DSL из 1С для решения научных или инженерных задач? Почему на рынке много вакансий для программистов на 1С, хотя по замыслу написанием скриптов должны заниматься сами бухгалтеры? Вопросы риторические.

Следующая проблема еще круче.

Единожды написанный код нужно сопровождать. Весь смысл софта в том, что его легко менять, в отличие от "железа". Представим себе запрос на генерацию куска программы в большой системе, чтобы проверять не только, куплено ли яблоко, но куплено ли оно по цене ниже средней по рынку региона за последний месяц. Представили? И чтобы никакой регрессии!

Что меняется при переходе к большим языковым моделям?

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

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

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

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

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

Иначе может возникнуть казус. Алесандр Степанович Грин в своем романе "Золотая цепь" прекрасно описывает диалог людей с большой языковой моделью за сто лет до их появления.

...Ганувер посмотрел на куклу и спросил: — Ксаверий, чувствуешь ли ты что-нибудь?

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

— Я — Ксаверий, ничего не чувствую, потому что ты говоришь сам с собой.

— Вот ответ, достойный живого человека! — заметил Галуэй. — Что, что в этом болване? Как он устроен?

— Не знаю, — сказал Ганувер, — мне объясняли, так как я купил и патент, но я мало что понял. Принцип стенографии, радий, логическая система, разработанная с помощью чувствительных цифр, — вот, кажется, все, что сохранилось в моем уме. Чтобы вызвать слова, необходимо при обращении произносить «Ксаверий», иначе он молчит.

— Самолюбив, — сказал Томсон.

— И самодоволен, — прибавил Галуэй.

— И самовлюблен, — определила Дигэ. — Скажите ему что-нибудь, Ганувер, я боюсь!

— Хорошо. Ксаверий! Что ожидает нас сегодня и вообще?

— Вот это называется спросить основательно! — расхохотался Галуэй. Автомат качнул головой, открыл рот, захлопал губами, и я услышал резкий, как скрип ставни, ответ:

— Разве я прорицатель? Все вы умрете; а ты, спрашивающий меня, умрешь первый.

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

— Довольно, довольно! — вскричала Дигэ. — Он неуч, этот Ксаверий, и я на вас сердита, Ганувер! Это непростительное изобретение.

Я выходил последним, унося на затылке ответ куклы: «Сердись на саму себя!»

— Правда, — сказал Ганувер, пришедший в заметно нервное состояние, — иногда его речи огорошивают, бывает также, что ответ невпопад, хотя редко. Так, однажды, я произнес: «Сегодня теплый день», — и мне выскочили слова: «Давай выпьем!»

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

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

— П-о-ч-е-м-у — М-о-м-с-с-е-н — н-е — о-т-в-е-ч-а-е-т — п-р-и-е-м…

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

— У — н-е-г-о — к-о-н-ч-а…

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

— С-и-м-о-н — э-т-о — т-ы…

— Г-о-в-о-р-и-т — С-и-м-о-н — н-е — я — к-т-о — г-о-в-о-р-и-л — к-т-о — г-о-в-о-р-и-л…

Пиркс втянул голову в плечи. Удары сыпались, как град:

— К-т-о — г-о-в-о-р-и-л — о-т-з-о-в-и-с-ь — к-т-о — г-о-в-о-р-и-л — к-т-о — г-о-в-о-р-и-л — я — С-и-м-о-н — я — В-а-й-н — к-т-о — г-о-в-о-р-и-л — о-т-з-о-в-и-с-ь…

— Терминус! — крикнул Пиркс. — Перестань! Перестань!

Давать прогнозы -- дело неблагодарное.

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

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

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

Перспектива нанять вместо десятка разработчиков десяток жрецов промпт-инженеров и платить за доступ к Ксаверию тоже не очень радостная.

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