Будущее разработки программного обеспечения — разработчики программного обеспечения

Я был программистом, который много говорил в течение 43 лет. Это больше половины всей истории электронных программируемых компьютеров.

За это время я видел, как многое изменилось. Но я также видел, что некоторые вещи остаются примерно такими же.

Я пережил несколько циклов технологий, которые в то время были восприняты как «конец компьютерных программистов».

WYSIWYG, такие редакторы, как Visual Basic и Delphi, собирались положить конец потребности в программистах.

Волшебники и макросы в Microsoft Office собирались положить конец потребности в программистах.

Executible UML собирался покончить с потребностью в программистах.

Платформы No-Code и Low-Code собирались положить конец потребности в программистах.

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

В этих циклах нет ничего нового. В семидесятые и восьмидесятые годы 4GL и 5GL рекламировались как конец программистов.

А до них 3GL вроде Fortran и COBOL.

И до них компиляторы, такие как А-0, собирались покончить с необходимостью в программистах, которые инструктировали компьютеры в двоичном, буквально пробивая дыры в картах.

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

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

В каждом цикле прогнозы оказывались очень, очень неверными. Конечным результатом было не меньше программистов, а больше программ и больше программистов. Это пример парадокса Jevons за $1,5 трлн в год.

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

Но на этот раз все по-другому, Джейсон!»

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

И есть еще одно важное различие: в предыдущих циклах технология работала надежно. Мы действительно могли бы быстрее создавать рабочее программное обеспечение с VB или с Microsoft Access. Это не так с LLM, которые для большинства команд фактически замедляют их, делая программное обеспечение менее надежным и менее поддерживаемым. Это своего рода ПРОИГРЫШ В большинстве случаев. (Если только эти команды не устранили реальные узкие места в процессе разработки.)

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

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

Это была самая трудная часть, когда программисты пробивали дыры в картах. Это была самая сложная часть, когда они печатали код COBOL. Это была трудная часть, когда они оживляли графические устройства Visual Basic (предположительно, для отслеживания IP-адреса убийцы). И это самая сложная часть, когда они побуждают языковые модели предсказывать правдоподобный Python.

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

Эдгар Дейкстра назвал это почти 50 лет назад: мы никогда не будем программировать на английском, французском или испанском. Естественные языки не эволюционировали, чтобы быть достаточно точными и недвусмысленными. Семантическая двусмысленность и языковая энтропия всегда будут побеждать эти амбиции.

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

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

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

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

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

Когда я пишу код, я выполняю его в своей голове. Моя внутренняя модель программы не просто синтаксическая, как у LLM. Я не просто сопоставляю шаблоны и предсказываю токены для получения статистически правдоподобного кода. Я действительно понимаю код.

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

Глупость многих людей, утверждающих, что «подсказки — это новый исходный код», и даже то, что целые рабочие системы могут быть регенерированы из исходных входных данных модели, будет раскрыта как бессмыслица, как это. Проблема с тем, чтобы вступить в дебаты с реальностью, заключается в том, что реальность всегда побеждает. (И даже не понимает, что это в дебатах.)

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

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

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

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

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

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

И тогда, возможно, напишите мне, если вы заинтересованы в том, чтобы освоить их в технических методах, которые могут значительно сократить сроки доставки, одновременно повышая надежность и снижая стоимость изменений, с «ИИ» или без него. Это WIN-WIN-WIN-WIN.

Источник: codemanship.wordpress.com

Комментарии: