Comments 39
Самое сложное - формализация реальности.
Правильно прикладывать математику ИИ не поможет от слова совсем.
Объем копипасты после ИИ затмит тот, что мы уже имеем после того, как в нашу жизнь пришел stackoverflow. Возможно, наконец-то начнут по-настоящему ценить тех, кто реализует в продукте очередную фичу, сокращая при этом объем кодовой базы :)
Я вообще жду, когда умные головы в индустрии осознают преимущества "сокращений" ПО, вырезания фич (по разным причинам), уменьшения зависимостей и т.д. Наверняка книжки умные будут писать.
У меня даже есть термин: "Утилизация информационных систем". Вот мы пишем все эти системы, собираем данные, что то делаем. A что мы будем делать после?
Требование: софт, реализующий факторизацию в целых числах в два раза быстрее последней версии cado-nfs для любых случаев. Теперь вам должно быть очень просто накодить соответствующее решение (и прославиться, к слову!).
Не вопрос! Дайте мне не ограниченное количество памяти, и я тупо сложу туда таблицу результатов.
Может в Вашей постановке все-таки чего-то не хватает? ;)
О чем собственно и статья...
Даже если не брать во внимание время на составление таблицы результатов, предложенное решение всё же сомнительное, потому что время на случайный доступ зависит от максимального размера накопителя: чем он больше, тем больше времени требуется на извлечение данных. Так что Вам осталось доказать, что физически возможно сконструировать носитель, чтение с которого будет быстрее разового вычисления cado-nfs.
P.S. Я тут быстро пробежался по документации cado-nfs и не увидел принципиальных ограничений на размер входного числа. Упоминается «маленький» режим (< 2^32) и есть режим больших чисел. Без ограничений таблицу результатов нельзя составить в принципе. Так что не зачёт.
Честности не хватает у того, кто пытается змерять время выполнения на другом железе... Вилять можно сколько угодно, но задачу факторизации вы не решите
Я не считаю, что ИИ сможет в полной мере заменить разработчиков ПО в ближайшее время, но -
Кодинг может быть сложным, но мне никогда не требовалось больше двух недель, чтобы разобраться с проблемами в коде. Если освоить синтаксис, логику и методики, то процесс оказывается довольно прямолинейным. Настоящие проблемы обычно связаны с тем, что ПО должно делать. Самое сложное в создании ПО — не написание кода, а создание требований, а требования к ПО по-прежнему определяют люди.
Если ИИ решит проблему быстрее вас, и его внедрение станет достаточно дешевым, а сам он будет надежным, тогда почему не заменить разработчика им. Далеко не все разработчики занимаются проектированием и составлением требований к системе. Разработка и проектирование это разные задачи.
Сложность как правило никуда не пропадает.
Написание ПО - итеративный процесс уточнения требований от смутных желаний заказчика, до строго формализованного текста. Сначала этим формализованным текстом были машинные коды. Потом - код на ассемблере, потом код на языках высокого уровня.
Ну будет следующий шаг развития - формализовать задачу только до постановки, с которой справится ИИ. Но убрать все логические не соответствия в постановке, спланировать взаимодействие разных частей программного комплекса, определиться с приемлемым временем отклика, со стратегий обработки ошибок и т.д. - ещё долго будет за человеком.
И именно этого человека ( человека который стоит на последнем этапе формализации и часто является последним бастионом здравого смысла ) - будут называть программистом. А чем именно будет заниматься программист - написанием кода или постановкой заданий ИИ, не суть важно...
Но убрать все логические не соответствия в постановке, спланировать взаимодействие разных частей программного комплекса, определиться с приемлемым временем отклика, со стратегий обработки ошибок и т.д. - ещё долго будет за человеком.
Или наоборот. Это будет, скорее всего, не один ИИ, а целая пачка специализированных, каждый следящий за чем-то отдельным. Но есть некоторая вероятность, что в результате у этого коллектива из ИИ этот согласование будет получаться лучше, чем у человека. Потому что в электронные мозги влезет вся система целиком, а в человеческие - нет.
Но убрать все логические не соответствия в постановке
Фраза красивая, но за ней кроется бездна))
Очень часто логические несоответствия мы видим только в процессе реализации.
За предыдущее десятилетие отрасль разработки ПО перешла от каскадной модели к agile. В каскадной модели чётко задаётся желаемое до того, как написано код, а agile обеспечивает достаточную гибкость для внесения изменений по ходу движения.
Придётся немного "зацепиться"...
Предположим, нужно создать некую систему, решающую определённую задачу. Это новая задача? Её никто не решал до Вас? Это новая система? Такую систему уже делали до Вас? Если в прошлом уже что-то было, то где результаты этой работы? Где выводы? Где код? Где уже законченная спецификация системы? Ведь, если такая спецификация уже есть, то её надо брать готовенькую и автоматически строить код. (Вопросы авторского права я оставляю за скобками. Я говорю о возможностях.)
Ну а чем плохо? Если ИИ сможет корректно сконвертировать код с COBOL на современный популярный ЯП ( причем в однотипном современном ключе, избавившись от авторских стилей и не тривиальных штучек которые внесла давным-давно команда программистов создававших приложение )
А дальше - обычное избавление от легаси: пересмотр требований, перекройка архитектуры, использование современных библиотек и подходов, реализация новых фич, документирование. И т.д. и т.п.
Это шаг естественно основной и никто его отменять не собирается. И на этом шаге - по прежнему основная роль будет у людей.
Если ИИ сможет корректно сконвертировать код с COBOL на современный популярный ЯП
Сможет, если его обучить на 100500 примерах перевода с COBOL на python. Только на чем обучать?
Есть надежда на то, что нейросети смогут переводить с одного языка на другой, зная близкие языки. Особенно учитывая, что языки программирования создавались людьми, которые вовсю воровали друг у друга полезные подходы, конструкции и фичи ( человек, даже не знающий кобол ведь в состоянии на процедурном уровне смутно понять, что код делает ).
Может ИИ будет достаточно примеров перевода с фортрана, бейсика, ады и т.д. Плюс текст учебников по коболу + текст стандарта кобола + код компилятора с кобола ( а лучше нескольких их реализаций ).
Ну вот например Сбер при тренировке своей mGPT никаких примеров перевода не использовал — они просто забросили туда тексты на 61 языках, и этого оказалось достаточно, чтобы модель самостоятельно научилась переводить с одного на другой.
Автор предлагает скормить нейронке старый код на коболе, чтобы она сгенерировала то же самое на современном языке?
Зачем вообще переводить на новый язык? Пусть остается на Коболе! Ведь задавать условия для ПО можно и устно.
Так что программисты никуда не денутся — они просто перестанут писать код.
Самое сложное превратить код в деньги. Т.е. написать - ОК. А вот чтобы этот код хотя бы кому-то нужен был и как-то эту нужду превратить в деньги, хотя бы покрыть по среднерыночной цене наемного работника - вот тут таланты нужны.
И правильные требования как раз часть этого процесса - по превращению ненужного никому кода (которого тонны за бесплатно) - в живые деньги, которые на дороге не валяются.
Как и шахматные ИИ-программы, беспилотные автомобили активно используют для принятия решений движки на основе правил.
— и шахматные ИИ-программы уже давно, а точнее с выхода AlphaZero (2017) не является системой с "движком на основе правил" (мы конечно говорим о чемпионах мейнстрима, иначе можно показать на человека с палкой-копалкой и сказать, что прогресса не существует), и главные на рынке беспилотных автомобилей запятая в отрасли беспилотности автомобилей, Tesla, не желает от них отставать, и сейчас, в свете ошеломляющего успеха больших языковых моделей, и шире —трансформерной архитектуры, активно переводит свой модуль планирования так же на нейросеть.
В итоге у них будет полностью нейросетевой автопилот.
И то, как они продвинулись на этом пути, их прогресс в мультимодальных моделях на основе больших языковых моделей они показали менее недели назад, — продемонстрировав нейросетевой моделлер дорожных ситуаций, управляемый речью, — нейросетевую генерацию изображения камер машины для кейсов, задаваемых на естественном языке.
Это я к тому что ваша экспертиза в этой области не выдерживает критики.
Это так, разминка.
Главное то, что вы собственно не ответили на вопрос, а почему это программистам не надо бояться, что искусственный интеллект лишит их работы?
Пока все выглядит ровно наоборот.
(Строго говоря для меня все выглядит "ровно наоборот" вот уже 20 лет как, но сейчас это стало очевидно без малого всем (наконец-то!)).
Не видно препятствий тому, чтобы системы на основе больших языковых моделей (не обязательно LLM нынешнего поколения) научились работе с требованиями, и в итоге стали делать ее лучше людей. В чем проблема-то?
А вот со статьей я проблему вижу: в ней не дается ответа на этот вопрос, насколько я понимаю.
Знаете, мнение, что "ИИ лишит работы программистов" тоже не выдерживает никакой критики. Просто мысли:
Сможете строго доказать, что какую-либо модель ИИ в принципе можно научить программировать на уровне "Может заменить программиста"? Нынешние успехи, увы, никак не доказывают это. А вот наличие у моделей фундаментальных ограничений (правда, в несколько других областях, но все же) заставляет задуматься над этим вопросом.
Если такая модель все-таки существует, то через сколько времени она будет хотя бы создана? Просто если соответствующая модель появится лет так через 200, то смысла бояться почти нет.
Пусть модель создана. Тогда ещё ряд вопросов:
3.1) Какие будут требования к оборудованию? Будет неудобно, если модели будут нужны парочка обычных и квантовых суперкомпьютеров, чтобы генерировать хотя бы по 1 строчке кода раз в год (никто же не гарантирует, что такого быть не может).
3.2) Как следствие предыдущего пункта - какова будет стоимость использования этой модели?
3.3) Если проблема 3.1 и/или 3.2 окажется слишком серьезной - можно ли будет хоть как-то оптимизировать модель без существенных потерь в качестве и до состояния, когда заказчику будет выгоднее оплачивать доступ к модели, а не живых людей?
Это как минимум. Обычно на данные вопросы ответов нет, все ограничивается "вот 2 года назад не умели, а сейчас умеют, а потому 2-3-5-10 лет - и всех программистов уволят". А ответы на них прямо определяют, стоит ли бояться или нет. И ведь это далеко не все вопросы.
Так что увы - если Вы не видите препятствий, то это не значит, что их нет.
А вот наличие у моделей фундаментальных ограничений
— это каких же, нейросеть?
Например, вот статья. Отмечу, что конкретно данные ограничения решаются либо полностью (с помощью хитрой модификации), либо частично, до уровня "проблемы, связанные с ограничениями, не возникают при решении реальных задач" (без модификаций). Но это как раз заставляет задуматься над следующими вопросами: Какие ещё архитектурные ограничения есть у текущих моделей и будут у новых? Все ли их возможно как-то исправить (и да, путь решения проблемы должен и существовать, и быть реализуемым на практике)?
Всё ещё абсолютно уверены, что модели смогут получить абсолютно все способности, необходимые для замены программистов?
Вы бы статьи, которые советуете, сперва бы a) читали, и b) понимали, чтобы не косплеить здесь сцену из столовой профессора Преображенского (— я ту, про "заявления космических масштабов и космической же глупости" ввиду имею, вдруг вам и это уточнить надо!)
Можете, пожалуйста, объяснить, почему Вы решили, что я не читал и/или не понял данную статью? По Вашему мнению, в ней не рассматриваются ограничения определенного класса моделей (пусть эти ограничения и касаются задач, очень слабо связанных с программированием - но я это отмечал выше)?
И все-таки попрошу Вас более конструктивно обосновывать свои утверждения, а не только делать громкие высказывания.
Мне кажется, если будет создан ИИ способный заменить программиста (и экономически более выгодный), то можно будет быстро наделать миллиард таких виртуальных программистов и поручить им написать софт автоматизирующий вообще все профессии и делающий ненужными всех людей.
Вы абсолютно правильно описали проблему с технарской точки зрения. Правила, мат. расчеты, предположения (на основе этих правил) — все верно и все работает так как вы пишете.
Но в процессе вы настолько увлеклись технарством, что только вскользь упомянули о том, что технарей нанимают манагеры и что манагеры живут по своим, "нечетким" правилам. Эти магнагерские правила позволяют им в частности предположить "за забором очередь" и это предположение не дает им покоя.
И скорее всего это их (ничем не обоснованное с технарской точки зрения) предположение приведет только лишь к следующему витку противостояния и к аргументу "за забором очередь" добавится еще один "и вообще вас всех скоро заменит ИИ". Также ничем не обоснованный, что не мешает манагерам свято в него верить.
Не хотел никого обидеть если что.
Допустим ИИ смог выкатить 1ю версию. Допустим на ней каким-то магическим образом пофиксили баги.
Теперь нужно выкатить следующую версию, сохранив все накопленные данные.
Сможет ли ИИ итеративно по водопадному или agile методу улучшить свою 1ю версию? Ведь для этого он должен как минимум разобраться: а чего же он нагородил. Или ему не нужно разбираться в своем коде?
Проблема в том, что пожелания пользователей постоянно поступают. И часто противоречат исходным пожеланиям.
и ещё более важно правильно реагировать на них, не попадая в аварии.
Это пол беды.
Вторая половина надо задать уровень риска, на который автопилот может пойти.
Ну вот пример.
ДАНО:
1)ЖД переезд с дальностью видимости 100м
2)автомобилю на переезд ЖД нужно 3 секунды.
Можно посчитать что в случае если поезд едет медленнее 120км/ч, то можно гарантированно успеть проехать перед ним.
Но автопилот нет знает скорость поезда пока его не увидит. А когда увидит будет поздно.
Допустим автопилот каким-либо образов оценивает вероятность того, что поезд едет быстрее 120км/ч в k.
Вопрос: при каких значениях k автопилот проедет переезд, а в каких встанет намертво?
Если строго считать к=0, для проезда, то автопилот встанет в на реальной дороге очень быстро. К примеру потому, что он будет считать что любой человек на тротуаре может внезапно потерять сознание и упасть на проезжую часть.
А если k>0 то кто определит это k?
Самое сложное в ПО — не кодинг, а требования, или Почему разработчикам не стоит бояться ИИ