Из-за всех этих статей о том, насколько потрясающ прогресс ИИ, у многих возникло отчаяние в связи с возможностью скорой замены разработчиков ПО искусственным интеллектом. Люди представляют, что руководители и исследователи продуктов передадут всю работу по созданию ПО искусственному интеллекту. Так как я уже пятнадцать лет пишу ПО по спецификациям, созданным этими людьми, то не могу воспринимать серьёзно подобное беспокойство.
Кодинг может быть сложным, но мне никогда не требовалось больше двух недель, чтобы разобраться с проблемами в коде. Если освоить синтаксис, логику и методики, то процесс оказывается довольно прямолинейным. Настоящие проблемы обычно связаны с тем, что ПО должно делать. Самое сложное в создании ПО — не написание кода, а создание требований, а требования к ПО по-прежнему определяют люди.
В этой статье я расскажу о связи между требованиями и ПО, а также о том, что необходимо ИИ для создания хороших результатов.
▍ Это не баг, а фича… хотя постойте, всё-таки баг
В самом начале моей карьеры меня подключили к уже разрабатываемому проекту, чтобы повысить скорость команды. Основная задача ПО заключалась в конфигурировании произвольных продуктов на сайтах электронных продаж.
Мне поручили генерацию динамических условий договоров. Это было условное пустословие, зависящее от типа приобретаемого продукта, а также от того, в каком штате США находился покупатель.
В определённый момент я подумал, что нашёл потенциальный изъян. Пользователь мог выбрать один тип продукта, и при этом генерировались соответствующие условия договора, однако в дальнейшем он мог выбрать другой тип продукта с уже заданными условиями. Это нарушало одну фичу, которую чётко указали в бизнес-требованиях, и под которой стояла подпись клиента.
Я наивно спросил у клиента: «Нужно ли мне удалить входные данные, позволяющие пользователю переопределить правильные условия договора?» Его ответ запомнился мне навсегда. С полной уверенностью он сказал:
«Этого никогда не может случиться».
Это был руководитель высшего звена, работавший в компании много лет, он знал бизнес-процессы компании и его осознанно выбрали для контроля разработки ПО. Возможность переопределения стандартных условий договора в явной форме была запрошена тем же человеком. Да кто я такой, чтобы подвергать сомнению чьи-то слова, особенно важного руководителя из компании, которая платила нам за создание этого продукта? Поэтому я пожал плечами и вскоре забыл об этом.
Несколько месяцев спустя, всего за пару недель до релиза ПО, тестировщик на стороне клиента обнаружил проблему, решение которой поручили мне. Когда я прочитал описание этой проблемы, то громко рассмеялся.
Это была та самая проблема со стандартными условиями договора, про которую мне говорили, что она никогда не возникнет. Как думаете, что произошло? Как думаете, кого в этом обвинили и кому сказали всё исправить?
Устранить проблему было довольно просто, а последствия бага оказались незначительными, но этот опыт стал сквозной темой в моей карьере разработчика ПО. Я общался со многими коллегами-разработчиками, и знаю, что я такой не один. Проблемы стали больше, сложнее в решении и более затратными, но источник проблемы обычно был одинаков: нечёткие, несогласованные или ошибочные требования.
▍ Современное состояние ИИ: шахматы против беспилотных автомобилей
Концепция искусственного интеллекта существует достаточно давно, однако современный прогресс вызвал беспокойство в медиа и в конгрессе США. ИИ уже достиг большого успеха во многих областях. Первое, что приходит на ум — это шахматы.
ИИ начали использовать в шахматах ещё с 1980-х. Общепризнанно, что ИИ превзошёл человека в способности побеждать в шахматах. Это и неудивительно, ведь параметры в шахматах КОНЕЧНЫ (но игра пока ещё не решена).
Шахматы всегда начинаются с 32 фигур на 64 клетках, имеют хорошо задокументированные официальные правила, а самое важное — чётко определённую цель. На каждом ходу есть конечное количество возможных вариантов перемещения фигур. Играя в шахматы, мы просто выполняем движок правил. Системы ИИ могут вычислить последствия каждого хода, чтобы выбрать ход, который с наибольшей вероятностью приведёт к взятию фигуры противника, захвату позиции или окончательной победе.
Есть и ещё одна сфера, в которой ИИ развивается очень активно — беспилотные автомобили. Автомобилестроители уже довольно давно обещают нам их выпустить. Некоторые машины имеют определённые возможности беспилотного вождения, но есть и изъяны. Во многих ситуациях автомобиль требует активного контроля; водителю может понадобиться взять руль в свои руки — функция беспилотного вождения не полностью автономна.
Как и шахматные ИИ-программы, беспилотные автомобили активно используют для принятия решений движки на основе правил. В отличие от правил шахматных программ, правила поведения в каждой возможной ситуации определены нечётко. Есть тысячи крошечных факторов, которые водители принимают в расчёт при избегании пешеходов, объезде припаркованных автомобилей и поворотах на развязках. От правильной интерпретации этих факторов зависит, доберётесь ли вы в супермаркет безопасно или окажетесь в больнице.
В мире технологий стандартом является доступность уровня пяти или даже шести девяток, то есть когда веб-сайт или сервис доступен в течение 99,999% (или 99,9999%) от всего времени. Затраты для достижения первых 99% не так высоки. Это значит, что ваш веб-сайт или сервис может быть офлайн в течение более чем трёх дней (87,6 часа) в год. Однако при добавлении в конец каждой новой девятки затраты растут экспоненциально. Если вы достигнете 99,9999%, то даунтайм будет составлять всего 31,5 секунды в год. Это требует существенно больше планирования и усилий; и, разумеется, это гораздо дороже. Достичь первых 99% может быть непросто, но в соотношении это гораздо проще и дешевле, чем эта последняя крошечная дробная часть.
365 X 24 X 60 минут = 525 600 минут в год
Доступность 99% -> даунтайм 5256 минут, 87,6 часа
Доступность 99,9% availability -> даунтайм 526 минут, 8,76 часа
Доступность 99,99% -> 52 минуты, меньше одного часа
Доступность 99,999% -> 5,2 минуты
Доступность 99,9999% -> 0,52 минуты, приблизительно 31,5 секундыНеважно, насколько близок ИИ беспилотного вождения к достаточному качеству, всегда есть риск несчастных случаев и смертей. Эти риски и последствия ежедневно возникают у сидящих за рулём людей. Не знаю, какая частота несчастных случаев и смертей приемлема для государства, но стоит считать, что она должна быть хотя бы не хуже, чем у живых водителей.
Приемлемого уровня безопасности так сложно достичь, потому что при вождении автомобиля задействуется гораздо больше переменных, чем в шахматах, и эти переменные НЕ КОНЕЧНЫ. Первые 95% или 99% может быть легко предсказать и учесть. Однако после первых 99% есть так много пограничных случаев, каждый из которых может иметь некие общие признаки, но при этом быть уникальным; другой транспорт на дороге, управляемый другими людьми, перекрытые дороги, ремонт, ДТП, погодные условия. Как часто вы ездили по дорогам, которые асфальтированы, но разметка на которых отсутствовала? Существенно сложнее заставить модель ИИ учитывать и распознавать такие аномалии и пограничные случаи, и ещё более важно правильно реагировать на них, не попадая в аварии. У каждого пограничного случая могут быть некие общие черты, но они редко бывают одинаковыми, из-за чего ИИ сложнее определить правильную реакцию.
▍ ИИ не может создавать ПО, только код
Создание и поддержка ПО гораздо ближе к вождению, чем к игре в шахматы. В нём задействовано гораздо больше переменных, а правила основаны на субъективных решениях. Вы можете добиться желаемого результата при разработке ПО, но маловероятно, что он будет столь же простым, как в шахматах. ПО редко бывает завершённым; в нём добавляются фичи и устраняются баги; это постоянный процесс. В отличие от ПО, после победы или проигрыша в шахматах всё заканчивается.
В разработке ПО есть инструмент, приближающий архитектуру ПО к жёстко контролируемому движку правил шахмат: технические спецификации. В лучшем случае, спецификации описывают ожидаемое поведение пользователей и потоки исполнения программ. Вот как пользователь покупает сэндвич онлайн: нажимает на кнопку, создаёт эту структуру данных, запускает этот сервис. Однако мы редко такое получаем. Очень часто нам выдают списки с пожеланиями спецификаций фич, черновики и документы с нечёткими требованиями, а потом говорят полагаться на здравый смысл.
Ещё хуже то, что требования меняются или игнорируются. Недавно меня попросили помочь команде создать систему, помогающую людям получать информацию о проблемах со здоровьем, связанных с COVID 19. Приложение предназначалось для той части мира, в которой не было надёжного WIFI. Команда попросила помочь меня создать приложение, способное выполнять опросы через SMS. Поначалу я с восторгом взялся за проект.
Но как только услышал описание желаемой системы, я осознал, что это станет проблемой. Одно дело — спрашивать, какова по шкале от 1 до 10 вероятность того, вы снова посетите сетевой магазин. Это сильно отличается от многоэтапных анкет с вопросами, имеющими много вариантов выбора, о симптомах, испытываемых при вероятном заражении COVID. Я не отказывался от работы, но указал на все возможные точки отказа в этом процессе и попросил команду чётко определить, как мы будем обрабатывать поступающие ответы на все вопросы. Будут ли это разделённые точками с запятой числа, соответствующие каждому ответу? Что, если отправленный ответ не соответствует ни одному из вариантов?
После всех этих вопросов команда пришла к тому же выводу. Мы решили, что лучше за это не браться. Верьте или нет, но я считаю это удачным решением. Было бы хуже, если бы мы потратили время и ресурсы, двигаясь вперёд без чёткого решения всех потенциальных проблем с отправкой недопустимых пользовательских данных.
Заключается ли идея поручения искусственному интеллекту разработки ПО в том, чтобы позволить руководству напрямую попросить компьютер создать систему SMS-анкетирования? Будет ли ИИ задавать вопросы о том, как обрабатывать все возможные проблемы сбора данных опросов через SMS? Учтёт ли он всё, то люди могут сделать в процессе анкетирования, и сможет ли справиться с ошибками?
Чтобы создать функциональное ПО при помощи ИИ, вам нужно знать, чего вы хотите, и чётко описать это. Иногда бывает так, что я пишу ПО просто для себя и не осознаю некоторых сложностей и проблем до того, как не приступлю к написанию кода.
За предыдущее десятилетие отрасль разработки ПО перешла от каскадной модели к agile. В каскадной модели чётко задаётся желаемое до того, как написано код, а agile обеспечивает достаточную гибкость для внесения изменений по ходу движения.
Очень многие программные проекты провалились, потому что их руководители считали, что точно знают, чего хотят, и думали, что могут точно описать и задокументировать это, но очень разочаровывались, когда видели готовый продукт. Разработка ПО по модели Agile должна была стать противоядием для этого процесса.
Наверно, ИИ лучше всего подходит для переписывания уже имеющегося ПО для его применения на новом оборудовании или на более новых языках программирования. Всё ещё есть много организаций, в которых ПО написано на COBOL, но всё меньше программистов хочет его осваивать. Если вы точно знаете чего хотите, возможно, вам удастся заставить ИИ создавать ПО быстрее и дешевле, чем командой живых программистов. Я считаю, что ИИ может создавать уже созданное ПО быстрее, чем живые программисты, но причина этого в том, что в процессе первоначальной разработки люди уже поняли, что должно делать это ПО.
Наверно, ИИ может неплохо справляться с разработкой ПО по каскадному процессу, который имеет грозное название «марш смерти». А знаете, кто плохо совместим с каскадной моделью? Мы, человеческие существа. И не из-за той части, когда подписанные документы передаются команде разработчиков, чтобы они могли начать писать код. Причина во всём том, что происходит до этого. Искусственный интеллект способен на чудеса, но не может читать мысли или говорить вам, чего вам нужно хотеть.
Выиграй телескоп и другие призы в космическом квизе от RUVDS. Поехали? ????
Комментарии (34)
vilgeforce
17.07.2023 13:12+2Требование: софт, реализующий факторизацию в целых числах в два раза быстрее последней версии cado-nfs для любых случаев. Теперь вам должно быть очень просто накодить соответствующее решение (и прославиться, к слову!).
uvic
17.07.2023 13:12+6Не вопрос! Дайте мне не ограниченное количество памяти, и я тупо сложу туда таблицу результатов.
Может в Вашей постановке все-таки чего-то не хватает? ;)О чем собственно и статья...
youngmysteriouslight
17.07.2023 13:12-2Даже если не брать во внимание время на составление таблицы результатов, предложенное решение всё же сомнительное, потому что время на случайный доступ зависит от максимального размера накопителя: чем он больше, тем больше времени требуется на извлечение данных. Так что Вам осталось доказать, что физически возможно сконструировать носитель, чтение с которого будет быстрее разового вычисления cado-nfs.
P.S. Я тут быстро пробежался по документации cado-nfs и не увидел принципиальных ограничений на размер входного числа. Упоминается «маленький» режим (< 2^32) и есть режим больших чисел. Без ограничений таблицу результатов нельзя составить в принципе. Так что не зачёт.
uvic
17.07.2023 13:12+1Без ограничений и расчет не имеет смысла. Предположим число на столько большое, что результат будет только через год. Есть ли смысл вообще запускать этот расчет для такого большого числа?
vilgeforce
17.07.2023 13:12-1Честности не хватает у того, кто пытается змерять время выполнения на другом железе... Вилять можно сколько угодно, но задачу факторизации вы не решите
HlebyShek
17.07.2023 13:12+1Я не считаю, что ИИ сможет в полной мере заменить разработчиков ПО в ближайшее время, но -
Кодинг может быть сложным, но мне никогда не требовалось больше двух недель, чтобы разобраться с проблемами в коде. Если освоить синтаксис, логику и методики, то процесс оказывается довольно прямолинейным. Настоящие проблемы обычно связаны с тем, что ПО должно делать. Самое сложное в создании ПО — не написание кода, а создание требований, а требования к ПО по-прежнему определяют люди.
Если ИИ решит проблему быстрее вас, и его внедрение станет достаточно дешевым, а сам он будет надежным, тогда почему не заменить разработчика им. Далеко не все разработчики занимаются проектированием и составлением требований к системе. Разработка и проектирование это разные задачи.
uvic
17.07.2023 13:12+1Сложность как правило никуда не пропадает.
Написание ПО - итеративный процесс уточнения требований от смутных желаний заказчика, до строго формализованного текста. Сначала этим формализованным текстом были машинные коды. Потом - код на ассемблере, потом код на языках высокого уровня.
Ну будет следующий шаг развития - формализовать задачу только до постановки, с которой справится ИИ. Но убрать все логические не соответствия в постановке, спланировать взаимодействие разных частей программного комплекса, определиться с приемлемым временем отклика, со стратегий обработки ошибок и т.д. - ещё долго будет за человеком.
И именно этого человека ( человека который стоит на последнем этапе формализации и часто является последним бастионом здравого смысла ) - будут называть программистом. А чем именно будет заниматься программист - написанием кода или постановкой заданий ИИ, не суть важно...
offline268
17.07.2023 13:12+2И именно этого человека ( человека который стоит на последнем этапе формализации и часто является последним бастионом здравого смысла ) - будут называть программистом.
Тут прослеживается аналогия - когда-то писали на ассемблере, потом появились языки высокого уровня (которые магически образом компилируются в машинный код), теперь вот получается новый уровень абстракции - "написание запроса для ИИ" (который будет магическим образом сконвертирован в ЯП высокого уровня, а затем магическим образом скомпилирован в машинный код)
Причем за всё это время армия программистов только растет
Ohar
17.07.2023 13:12Причем за всё это время армия программистов только растет
Она просто поглощает остальные профессии, пока не поглотит их все
inkelyad
17.07.2023 13:12+1Но убрать все логические не соответствия в постановке, спланировать взаимодействие разных частей программного комплекса, определиться с приемлемым временем отклика, со стратегий обработки ошибок и т.д. - ещё долго будет за человеком.
Или наоборот. Это будет, скорее всего, не один ИИ, а целая пачка специализированных, каждый следящий за чем-то отдельным. Но есть некоторая вероятность, что в результате у этого коллектива из ИИ этот согласование будет получаться лучше, чем у человека. Потому что в электронные мозги влезет вся система целиком, а в человеческие - нет.
uvic
17.07.2023 13:12+1Сумеет ли ИИ объяснить заказчику что "пять красных линий" не реализуемы?
И что даже если бы и были реализуемы, то заказчику это не надо...
aamonster
17.07.2023 13:12+1Просто этот ИИ надо обучать не на программиста, а на психолога :-)
Возможно даже, это реально с нынешним уровнем развития ИИ.
solver
17.07.2023 13:12+1Но убрать все логические не соответствия в постановке
Фраза красивая, но за ней кроется бездна))
Очень часто логические несоответствия мы видим только в процессе реализации.
Polaris99
17.07.2023 13:12-2Кодинг может быть сложным, но мне никогда не требовалось больше двух недель, чтобы разобраться с проблемами в коде
Со всеми проблемами? Или с каждой отдельной проблемой? А со всем тогда сколько - год?
OlegZH
17.07.2023 13:12+1За предыдущее десятилетие отрасль разработки ПО перешла от каскадной модели к agile. В каскадной модели чётко задаётся желаемое до того, как написано код, а agile обеспечивает достаточную гибкость для внесения изменений по ходу движения.
Придётся немного "зацепиться"...
Предположим, нужно создать некую систему, решающую определённую задачу. Это новая задача? Её никто не решал до Вас? Это новая система? Такую систему уже делали до Вас? Если в прошлом уже что-то было, то где результаты этой работы? Где выводы? Где код? Где уже законченная спецификация системы? Ведь, если такая спецификация уже есть, то её надо брать готовенькую и автоматически строить код. (Вопросы авторского права я оставляю за скобками. Я говорю о возможностях.)
offline268
17.07.2023 13:12Всё ещё есть много организаций, в которых ПО написано на COBOL, но всё меньше программистов хочет его осваивать. Если вы точно знаете чего хотите, возможно, вам удастся заставить ИИ создавать ПО быстрее и дешевле, чем командой живых программистов. Я считаю, что ИИ может создавать уже созданное ПО быстрее, чем живые программисты, но причина этого в том, что в процессе первоначальной разработки люди уже поняли, что должно делать это ПО.
Сомнительное утверждение. Автор предлагает скормить нейронке старый код на коболе, чтобы она сгенерировала то же самое на современном языке? Я представлял себе избавление от легаси несколько иначе ))))
uvic
17.07.2023 13:12+2Ну а чем плохо? Если ИИ сможет корректно сконвертировать код с COBOL на современный популярный ЯП ( причем в однотипном современном ключе, избавившись от авторских стилей и не тривиальных штучек которые внесла давным-давно команда программистов создававших приложение )
А дальше - обычное избавление от легаси: пересмотр требований, перекройка архитектуры, использование современных библиотек и подходов, реализация новых фич, документирование. И т.д. и т.п.
Это шаг естественно основной и никто его отменять не собирается. И на этом шаге - по прежнему основная роль будет у людей.
iig
17.07.2023 13:12+1Если ИИ сможет корректно сконвертировать код с COBOL на современный популярный ЯП
Сможет, если его обучить на 100500 примерах перевода с COBOL на python. Только на чем обучать?
uvic
17.07.2023 13:12Есть надежда на то, что нейросети смогут переводить с одного языка на другой, зная близкие языки. Особенно учитывая, что языки программирования создавались людьми, которые вовсю воровали друг у друга полезные подходы, конструкции и фичи ( человек, даже не знающий кобол ведь в состоянии на процедурном уровне смутно понять, что код делает ).
Может ИИ будет достаточно примеров перевода с фортрана, бейсика, ады и т.д. Плюс текст учебников по коболу + текст стандарта кобола + код компилятора с кобола ( а лучше нескольких их реализаций ).
iig
17.07.2023 13:12+1Перевести то можно и без волшебных нейросетей. Дизассемблировать из машинных кодов например. И оно возможно даже заработает. Правда сопровождать это будет невозможно ни со знанием COBOL, ни С.
Alexey2005
17.07.2023 13:12Ну вот например Сбер при тренировке своей mGPT никаких примеров перевода не использовал — они просто забросили туда тексты на 61 языках, и этого оказалось достаточно, чтобы модель самостоятельно научилась переводить с одного на другой.
eton65
17.07.2023 13:12Автор предлагает скормить нейронке старый код на коболе, чтобы она сгенерировала то же самое на современном языке?
Зачем вообще переводить на новый язык? Пусть остается на Коболе! Ведь задавать условия для ПО можно и устно.
Так что программисты никуда не денутся — они просто перестанут писать код.
codecity
17.07.2023 13:12+2Самое сложное превратить код в деньги. Т.е. написать - ОК. А вот чтобы этот код хотя бы кому-то нужен был и как-то эту нужду превратить в деньги, хотя бы покрыть по среднерыночной цене наемного работника - вот тут таланты нужны.
И правильные требования как раз часть этого процесса - по превращению ненужного никому кода (которого тонны за бесплатно) - в живые деньги, которые на дороге не валяются.
andrey_gavrilov
17.07.2023 13:12-1Как и шахматные ИИ-программы, беспилотные автомобили активно используют для принятия решений движки на основе правил.
— и шахматные ИИ-программы уже давно, а точнее с выхода AlphaZero (2017) не является системой с "движком на основе правил" (мы конечно говорим о чемпионах мейнстрима, иначе можно показать на человека с палкой-копалкой и сказать, что прогресса не существует), и главные на рынке беспилотных автомобилей запятая в отрасли беспилотности автомобилей, Tesla, не желает от них отставать, и сейчас, в свете ошеломляющего успеха больших языковых моделей, и шире —трансформерной архитектуры, активно переводит свой модуль планирования так же на нейросеть.
В итоге у них будет полностью нейросетевой автопилот.
И то, как они продвинулись на этом пути, их прогресс в мультимодальных моделях на основе больших языковых моделей они показали менее недели назад, — продемонстрировав нейросетевой моделлер дорожных ситуаций, управляемый речью, — нейросетевую генерацию изображения камер машины для кейсов, задаваемых на естественном языке.
Это я к тому что ваша экспертиза в этой области не выдерживает критики.
Это так, разминка.
Главное то, что вы собственно не ответили на вопрос, а почему это программистам не надо бояться, что искусственный интеллект лишит их работы?
Пока все выглядит ровно наоборот.
(Строго говоря для меня все выглядит "ровно наоборот" вот уже 20 лет как, но сейчас это стало очевидно без малого всем (наконец-то!)).
Не видно препятствий тому, чтобы системы на основе больших языковых моделей (не обязательно LLM нынешнего поколения) научились работе с требованиями, и в итоге стали делать ее лучше людей. В чем проблема-то?
А вот со статьей я проблему вижу: в ней не дается ответа на этот вопрос, насколько я понимаю.
ArZr
17.07.2023 13:12+2Знаете, мнение, что "ИИ лишит работы программистов" тоже не выдерживает никакой критики. Просто мысли:
Сможете строго доказать, что какую-либо модель ИИ в принципе можно научить программировать на уровне "Может заменить программиста"? Нынешние успехи, увы, никак не доказывают это. А вот наличие у моделей фундаментальных ограничений (правда, в несколько других областях, но все же) заставляет задуматься над этим вопросом.
Если такая модель все-таки существует, то через сколько времени она будет хотя бы создана? Просто если соответствующая модель появится лет так через 200, то смысла бояться почти нет.
Пусть модель создана. Тогда ещё ряд вопросов:
3.1) Какие будут требования к оборудованию? Будет неудобно, если модели будут нужны парочка обычных и квантовых суперкомпьютеров, чтобы генерировать хотя бы по 1 строчке кода раз в год (никто же не гарантирует, что такого быть не может).
3.2) Как следствие предыдущего пункта - какова будет стоимость использования этой модели?
3.3) Если проблема 3.1 и/или 3.2 окажется слишком серьезной - можно ли будет хоть как-то оптимизировать модель без существенных потерь в качестве и до состояния, когда заказчику будет выгоднее оплачивать доступ к модели, а не живых людей?
Это как минимум. Обычно на данные вопросы ответов нет, все ограничивается "вот 2 года назад не умели, а сейчас умеют, а потому 2-3-5-10 лет - и всех программистов уволят". А ответы на них прямо определяют, стоит ли бояться или нет. И ведь это далеко не все вопросы.
Так что увы - если Вы не видите препятствий, то это не значит, что их нет.
andrey_gavrilov
17.07.2023 13:12А вот наличие у моделей фундаментальных ограничений
— это каких же, нейросеть?
ArZr
17.07.2023 13:12Например, вот статья. Отмечу, что конкретно данные ограничения решаются либо полностью (с помощью хитрой модификации), либо частично, до уровня "проблемы, связанные с ограничениями, не возникают при решении реальных задач" (без модификаций). Но это как раз заставляет задуматься над следующими вопросами: Какие ещё архитектурные ограничения есть у текущих моделей и будут у новых? Все ли их возможно как-то исправить (и да, путь решения проблемы должен и существовать, и быть реализуемым на практике)?
Всё ещё абсолютно уверены, что модели смогут получить абсолютно все способности, необходимые для замены программистов?andrey_gavrilov
17.07.2023 13:12Вы бы статьи, которые советуете, сперва бы a) читали, и b) понимали, чтобы не косплеить здесь сцену из столовой профессора Преображенского (— я ту, про "заявления космических масштабов и космической же глупости" ввиду имею, вдруг вам и это уточнить надо!)
Andrey_Epifantsev
17.07.2023 13:12-1Мне кажется, если будет создан ИИ способный заменить программиста (и экономически более выгодный), то можно будет быстро наделать миллиард таких виртуальных программистов и поручить им написать софт автоматизирующий вообще все профессии и делающий ненужными всех людей.
gluck59
17.07.2023 13:12Вы абсолютно правильно описали проблему с технарской точки зрения. Правила, мат. расчеты, предположения (на основе этих правил) — все верно и все работает так как вы пишете.
Но в процессе вы настолько увлеклись технарством, что только вскользь упомянули о том, что технарей нанимают манагеры и что манагеры живут по своим, "нечетким" правилам. Эти магнагерские правила позволяют им в частности предположить "за забором очередь" и это предположение не дает им покоя.
И скорее всего это их (ничем не обоснованное с технарской точки зрения) предположение приведет только лишь к следующему витку противостояния и к аргументу "за забором очередь" добавится еще один "и вообще вас всех скоро заменит ИИ". Также ничем не обоснованный, что не мешает манагерам свято в него верить.
Не хотел никого обидеть если что.
T968
Самое сложное - формализация реальности.
Правильно прикладывать математику ИИ не поможет от слова совсем.
KongEnGe
Объем копипасты после ИИ затмит тот, что мы уже имеем после того, как в нашу жизнь пришел stackoverflow. Возможно, наконец-то начнут по-настоящему ценить тех, кто реализует в продукте очередную фичу, сокращая при этом объем кодовой базы :)
SadOcean
Я вообще жду, когда умные головы в индустрии осознают преимущества "сокращений" ПО, вырезания фич (по разным причинам), уменьшения зависимостей и т.д. Наверняка книжки умные будут писать.
У меня даже есть термин: "Утилизация информационных систем". Вот мы пишем все эти системы, собираем данные, что то делаем. A что мы будем делать после?