Comments 30
Простой вопрос.
В язык программирования X добавлена фича Y (например, в Go 1.18 добавлены generics). Откуда ИИ (Copilot, ChatGPT, ...) узнает что это такое и как с ним работать? Сейчас все, что предлагает ИИ, основано на уже имеющемся коде и примерах его использования. А если фича новая, и примеров кода еще нет? По крайней мере в количестве, достаточном для обучения модели ИИ.
Видится два варианта: ждать или сгенерировать корпус текстов с новой фичей самостоятельно.
сгенерировать корпус текстов с новой фичей самостоятельно
Совершенно верно. И для этого нам понадобятся разработчики (много) применяющие фичу в реальных задачах. А мы 99% этих разработчиков сократили уже за ненадобностью.
Что в таком случае мешает нанять лучших разработчиков по каждому языку, чтобы они "объясняли", как пользоваться новой фичей?
Условно, была задача, которую можно было решить с помощью Х, теперь при помощи У она решается быстрее, пример переписывается под новый стандарт и скармливается
Например, по запросу "stackoverflow.com golang CRUD" гугл возвращает 219.000 результатов.
Дальше нетрудно оценить, сколько понадобится человеко-часов "лучших разработчиков" для того, чтобы переписать хотя бы каждый десятый фрагмент кода с использованием дженериков. Хорошо, пусть нам не требуется для обучения переписать 20.000 примеров, пусть будет только две тысячи.
А ведь на CRUD история не заканчивается. Например, запрос "stackoverflow.com golang k8s API" возвращает два миллиона результатов с копейками. Ну и так далее.
За скобками остается вопрос о том, сколько времени понадобится "лучшим разработчикам" на то, чтобы вкурить новые фичи, и не подъедут ли к этому времени фичи новые.
Наверное, считается, что генеративное машинное обучение способно само извлекать наилучшее, даже если в обучающей выборке нет наилучшего, или оно исчезающе непредставительно.
К тому же, не стоит недооценивать роль той просто лавинообразной обратной связи, которую получили в последние месяцы разработчики генеративного ИИ и которую можно считать эдаким подкреплением изначальных модельных построений.
Думается дело будет не в фичах.
Через несколько итераций совокуплений программистов с ИИ исчезнут фреймворки, еще через пару лет исчезнут высокоуровневые ЯП — одним словом все, призванное облегчить работу людей с кодом, останется за бортом.
Это будет продолжаться до тех пор, пока не останется один ассемблер или какая-то его реинкарнация.
И на уровне ассемблера вопрос "новых фич" даже не встанет...
Простой ответ (и вполне серьезный): ИИ не нужно знать про эту новую фичу, т.к. он может сгенерировать вполне качественный код без ее использования.
Новые фичи в ЯП нужны для людей, а не для компьютеров и компиляторов. Фичи, т.е. новые абстракции - для того, чтобы было легче и удобнее мыслить. Если же человек исключается из процесса, то высокоуровневые ЯП становятся не нужны, и кодогенерацию можно делать сразу непосредственно в ассемблер (ну или в веб-ассемблер, или в коды Java-машины и т.п.)
Но даже если в процессе "компиляции русского языка в машинный код" и используются промежуточные языки, то степень их высоко- или низко-уровневости уже не будет иметь значения в большинстве случаев. Разве что для формальной верификации или дебага.
Если же человек исключается из процесса
Человек из процесса исключен не может быть в принципе, для обучения ChatGPT (и предшествующих ему GPT-3.5, GPT-3 и т.д.) привлекались "разметчики" (labelers), то есть вполне живые разработчики (если говорить об обучении в части языков программирования).
Ну только если ИИ научится сам себя обучать программированию без размеченных данных, но это точно не про GPT.
для обучения ChatGPT <...> привлекались "разметчики" (labelers)
ОК, это уже сделано. Зачем этим заниматься еще раз? Только из-за того, что мы придумали еще один ЯП (который ничем не лучше старых, и будущая его востребованность под большим вопросом)?
научится сам себя обучать программированию
Еще раз, ему не будет нужно обучаться "программированию" в том смысле, какой вкладывают в это слово современные разработчики ПО. Более вероятно, что он будет создавать работающее ПО не путем подражания мыслительным процессам человека, а иными способами. И сама эта идея не нова, эксперименты на этот счет (напр. genetic programming) были и раньше. И если все тесты будут успешно проходить, то какая разница?
Зачем этим заниматься еще раз?
Хотя бы затем что на ChatGPT 4 история не завершилась. Как не завершилась до этого на GPT-3, к примеру. Будут новые модели, их надо будет обучать, а как обучить бота писать код без этапа supervised learning - пока не придумали.
Более вероятно, что он будет создавать работающее ПО не путем подражания мыслительным процессам человека, а иными способами
Да, возможно. Но таких моделей ИИ (дающих результаты, хотя бы сопоставимые с ChatGPT) еще не существует. И неизвестно - появятся ли, и если появятся, то когда? Давать прогнозы "через 5 лет потеряют работу 75% разработчиков, через 10 лет 99%" на основании того, что в марте 2023 появился ChatGPT 4 - довольно странная идея.
На самом деле, сомнительные утверждения. Некоторые мысли:
Отказ от абстракций => увеличение размера программы (не всегда, но все же) => увеличение количества токенов, которых нужно сгенерировать. Последнее, в частности, ведет к увеличению затрат на 1 генерацию, увеличению кол-ва ошибок в коде и вероятным проблемам с размером контекста модели. Ну, а уж если окажется, что в сгенерированном коде найдется критическая ошибка, которую модель в упор не может исправить даже после внушительного числа запросов... не позавидуешь программистам, которым придется разгребать это чудо. Нет, можно, конечно, нафантазировать, что вот совсем скоро все эти проблемы возьмут да как-то решатся, но я в этом сомневаюсь. А до тех пор новые фичи ЯП потенциально будут способны смягчать недостатки модели, следовательно, ИИ вполне будут нужны эти фичи.
Обобщая рассматриваемую ситуацию с "обучением модели новой фиче" - положим, что каким-то образом был открыт принципиально новый алгоритм (или структура данных - неважно), который позволяет в разы эффективнее решать какие-то акутальные задачи; дополнительно положим, что в силу новизны существующие на момент открытия модели если и способны сгенерировать этот алгоритм, то делают это исключительно редко. Как заставить ИИ использовать это открытие? Или это тоже будет гарантированно не нужно?
Так что, если не вдаваться в необоснованные фантазии уровня "ИИ будет способен писать эффективный код без всего этого", то данные вопросы оказываются куда сложнее.
Отказ от абстракций => увеличение размера программы
Не сразу понял, о чем вы. ОК, согласен, что иногда отказ от высокоуровневых абстракций эквивалентен copy-paste approach, который мы справедливо осуждаем. Но к увеличению числа багов это само по себе не ведет. И когда это увеличение размера в эпоху Big Data имело значение?
Согласен, что код, сгенерированный ИИ, может быть нечитабельным для человека. Но надо ли человеку его читать и изменять? Вы дизассемлируете скомпилированный код, чтобы убедиться в правильности работы компилятора? Вряд ли. Хотя это не значит, что в компиляторах не бывает багов.
Давайте различать повседневную работу и исключительные случаи. ОК, исключительные случаи с помощью одного лишь ИИ решены быть не могут. Но они на то и исключительные, что встречаются не слишком часто.
Как заставить ИИ использовать это открытие?
Видимо, сообщить ему, что способ решения данной подзадачи следует считать известным, и что интерфейс вызова для этого нового алгоритма <такой-то>.
Сравните, сколько токенов нужно будет сгенерировать модели на создание одной и той же программы с использованием фич высокоуровневого ЯП, на том же ЯП, но без фич, и на ассемблере. А затем посмотрите скорость генерации токенов у больших языковых моделей. Да и модели любят начинать пороть бред, если надо сгенерировать больше, чем пару десятков строк кода (с оговорками, но все же), причем чем больше надо сгенерировать, тем больше будет вероятность бреда; это я и имел в виду, когда говорил про «баги». Так что размер выходных данных на данный момент все же имеет значение. В будущем, возможно, это решат, и тогда на размер будет действительно все равно, но когда решат (и решат ли вообще) - неизвестно.
Сравнение с компилятором не считаю корректным - компилятор с вероятностью, крайне близкой к единице, верно и качественно выполнит поставленную перед ним задачу. А вот когда модели научатся с такой же вероятностью генерировать качественный код, который к тому же будет удовлетворять не только запросу, но и почти всем тараканам в голове запрашивающего - неизвестно. Когда научатся - ваши замечания будут верны, а до тех пор программистам все равно придется лезть и что-то править в коде, либо же они будут изменять код под чьих-то тараканов, которых модель никак понять не может и посему генерирует не то.
Тем более, код моделей можно изучать на наличие новых алгоритмов или же наличие нежелательных паттернов, которые неплохо бы убрать в моделях новых версий (аргумент не очень, конечно, но все же).
Ну, насчет исключительных случаев - как вы и сказали, что они редко, но все же бывают. А теперь представьте, что у вас есть модель с высокой точностью, но крайне медленная (учитывая, что возможности моделей растут быстрее, чем их оптимизируют - такое вполне реально); представьте также, что сгенерированный и абсолютно нечитабельный код будет успешно работать месяц-два-полгода, после чего резко упадет, а затем выяснится, что поднять надо его быстро, а модель будет все исправлять пару дней. Будет очень грустно.
А насчет последнего - каким образом вы хотите сообщить это модели без дообучения? Ладно, в случае небольших задач это сделать вполне реально, а если задача будет огромной, почти не поддаваться разбиению на более мелкие подзадачи и притом будет неизвестно, нужен ли там будет этот алгоритм (вдруг там случай, в котором "классические" алгоритмы будут лучше нового? Или наоборот, он там ни в каком виде не нужен, а потому ваше уведомление модели об новом алгоритме будет мешать генерации).
Машине не нужен синтаксический сахар - для нее написать для каждого типа одинаковый код не стоит ничего. Так что Дженерики в го или наследование в c++ это все для нас. Машина может держать все детали в памяти и ког генерируемый ей будет мне кажется не пригодным для людей. Да сейчас ChatGPT генерирует код привычный нам, с логичными названиями переменных и даже комментариями. Но это потому что он обучен на коде написанном людьми и к тому же цель его разработчиков пока в том чтобы код был "для людей". Дальше критерии для обучения будут меняться - так что в конечном итоге языки программирования в привычном нам виде развиваться больше не будут. Но это я думаю не так скоро все будет. А пока кодить будем сами - и думаю долго.
Дальше критерии для обучения будут меняться
Первые два шага (из трех) в обучении GPT включают работу "разметчиков", на первом шаге они вручную завершают предложенные им фразы (ну или фрагменты кода), на втором - выбирают наиболее предпочтительные варианты продолжения из предложенных моделью ИИ, обученной на данных шага 1. Чтобы эта работа могла быть выполнена и успешно завершена ограниченной группой людей в разумные сроки, код должен быть написан на ЯП высокого уровня. Ну не машинный же код они будут сочинять и ранжировать.
Теоретически (наверное) можно результаты обучения на ЯП высокого уровня транслировать в язык ассемблера / машинный код / байткод, и шаг 3 "обучение с подкреплением" (reinforcement learning) выполнять уже для этого кода. В этом случае да, код в формате, понятном человеку, тут особо уже и не нужен. Проблема заключается в том, что даже если 99% такого кода будет работать как надо, ошибки, вызываемые оставшимся 1% надо будут как-то кому-то анализировать и исправлять. А человечество уже лет 70 как ушло от программирования в машинных кодах, и вряд ли станет к этому возвращаться.
Автор публикации (https://levelup.gitconnected.com/chatgpt-will-replace-programmers-within-10-years-91e5b3bd3676), с которой, собственно, весь это разговор и начался, на вопрос про исправление ошибок отвечает "ну живые разработчики ведь тоже ошибки допускают, и что?" А то, что в 9999 случаях из 10000 (условно) для исправления найденной ошибки не нужно лезть в машинный код или байткод, все делается средствами разработки и отладки ЯП высокого уровня.
Поэтому возможно что
в конечном итоге языки программирования в привычном нам виде развиваться больше не будут
но
не так скоро все будет. А пока кодить будем сами
Искин будет писать напрямую на ассемблере. С goto и без классов. Но это временно. Потом он станет процессором и будет напрямую показывать людям на экране то, что они хотят видеть
Что в таком случае мешает нанять лучших разработчиков по каждому языку
Очевидно, мешать будет их отсутствие. Если мы 99% сократили, остались только 1% "кодеров-любителей" - откуда возьмутся "лучшие разработчики"? Из "кодеров-любителей"?
Страшно не само сокращение. Всё-равно, потом придётся нанимать тех же для того. чтобы разгрести образованные ИИ завалы. Страшно то, то имеется безоглядная вера в ИИ, который сделает жизнь красивой. А тут нужна корректная постановка практически значимой задачи. А ИИ нужен для того, чтобы упорядочить накопленный опыт. Другими словами, результатом работы ИИ должна быть большая глобальная компонентная библиотека ПО. Вот такая библиотека и способна оставить без работы кучу программистов. Ведь, тогда, при разработке любой системы будет достаточно определить её класс и автоматически получить готовый код.
Игра в ассемблер для ИИ будет не на шутку, а всерьёз. Он будет терпеть неудачу снова, снова и снова, пока наконец не найдёт выигрышную стратегию.
Интересно, что и достаточно формализованный язык Форт (Forth), к тому же имеющий принятые стандарты и по модели его построения и использования близкий к естественным языкам за счёт использования в коде концепции конкатенации кода, тоже ещё не особо
по "зубам" AI ввиду того, что, вероятно, методология создания на нём кода не типовая задача. и ПО для обучения AI на нём, возможно, специально не размечалось для алгоритмов обучения.
P.S. Мой любимый вопрос к AI по Форт (Forth):
Показать код на Форт (Forth) примеров метапрограммирования. :)
Forth в скобках к слову Форт желательно использовать т.к. AI, может путать его с Фортраном.
Правда, не все согласны с таким пессимистическим сценарием.
Но они не получат просмотры и цитирование за своё несогласие. А автор апокалиптических прогнозов получит.
Авторы не учитывают социальные факторы, уменьшение зарплат программистов приведет к падению качества программистов. Зачем учиться чему-то сложному, когда за более простую работу (физическую, сервисную, менеджерскую, научную) платят больше. Можно иметь среднее образование, средние навыки, а код AI как-нибудь сгененерируют за тебя.
"Нам не нужно много программистов, нам нужна кучка самых умных", а откуда возьмутся самые умные если они всем сразу будут нужны? Как итог еще большая конкуренция за топовых специалистов и рост зарплат. С учетом уменьшения новых кадров, спрос на старые будет только расти, а значит будет расти и разрыв в зарплате между junior и top senior.
При этом AI будет отбирать все больше простой работы и создавать потребность в решении более сложных задач (рост сложности технологий никто не отменял). Единственный вариант преодоления пропасти между желающими стать программистами и тем уровнем который будет реально востребован, это обучение с помощью AI. Пока я даже близко не вижу прогресса в этом направлении, EdTech очень запаздывает.
Может есть какой-нибудь плагин для хрома чтобы таких вот авторов не видеть на главной никогда в жизни?
Был Habrosanitizer. Не знаю, как (и если) он сейчас работает.
Помнится когда появился AutoCAD тоже был вопль что конструкторам конец, однако да, исчезли чертежники, копировщики и другие профессии однако конструктора как были так и остались, их даже больше стало
мне очень интересно посмотреть на клиента который будет писать ч0ткое ТЗ для искусственного интеллекта для проекта который он хочет получить. а потом когда какая-нибудь маленькая штука будет работать немного не так как он хочет, как он будет объяснять что вот это не совсем так работает как я хочу, измените это пожалуйста... интересно было бы посмотреть на это. похожие истории были с PHP и 1С - все думали что на вот щас бизнес будет программировать сам, так легко же! в итоге всё только усложнилось и программистов стало только на порядок больше
SQL вообще для бухгалтеров и экономистов сделали, думали, им так проще будет :))))))
Програмисты превратятся в аналитиков переводящих человеческие хотелки в формальные ТЗ, а главным навыком будет знание предметной области и понимание логики универсального генератора готовых программ. 1C и SQL такими генераторами не смогли стать, слишком много в них низкоуровневой логики для работы с которой по прежнему нужно слишком много специальных знаний
Будущее программирования с помощью ИИ — первые примеры