Я инженер-программист с общим опытом больше 15 лет в разных областях. Сейчас специализируюсь на веб разработке, это моя профессия и основное хобби. Есть большой опыт применения ChatGPT, включая o1 и Claude AI на практике в своей работе. Я рассуждаю здесь с позиции этого опыта и логики. Сразу хочу сказать, что я не боюсь, что ИИ меня заменит, а наоборот мечтаю об этом, потому что у меня есть много нереализованных идей, требующих много времени на реализацию. И на этих же идеях, кстати, можно и заработать. Когда инженер получает инструмент заменяющий его, он не теряет работу, а становится инженером следующего уровня.
Прошло два года с момента взлета ChatGPT, а ни одна LLM так и не научилась писать приложения и сайты самостоятельно, программисты все еще нужны. Новички не заменили профессионалов. LLM не сделали из новичков даже джуниоров. Давайте разберемся почему это происходит и чего стоит ожидать в ближайшем будущем.
Текущее состояние и перспективы развития
На данный момент LLM модели могут писать фрагменты кода приемлемого качества на основе уже написанного. Это направление сейчас активно развивается. Но каждый такой фрагмент кода должен быть проверен программистом. LLM не способны мыслить архитектурно и моделировать будущее, даже если их об этом настойчиво попросить. Когда только начинаешь писать приложение, нужно продумать его структуру, типы данных, как это все будет взаимодействовать. Даже Claude AI не может это сделать минимально адекватно. Он руководствуется какими-то общими принципами, но нужно ведь еще думать, проигрывать в уме как это все будет работать и какие могут быть проблемы. Современные модели ИИ думать не умеют, даже рассуждающий o1 не думает.
В ближайшие пару лет мы, вероятно, увидим:
Появление инструментов разработки приложений с активным участием ИИ в качестве помощника (GitHub Copilot - это пока что мелочь). ИИ уже научился писать небольшие прототипы приложений в пару сотен строк очень плохого кода, но работающие. Сделать из этого что-то стоящее вряд ли получится, но для экспериментов подходит.
Развитие инструментов проверки кода на ошибки. Программирование - это по большей части поиск и исправление ошибок и других проблем. Чем раньше выявлена проблема, тем меньше времени в итоге будет потрачено на ее исправление. ИИ здесь сильно помогает выявлять множество проблем еще на ранних стадиях разработки. Человек не в состоянии быстро проанализировать тысячи строк кода и найти едва заметные проблемы, а с LLM можно находить такие ошибки за пару минут.
Увеличение размера контекста, чтобы LLM могла охватить весь проект целиком, состоящий из сотен тысяч строк кода, видеть структуру файлов и папок.
Для новичков все эти инструменты будут очень полезны, потому что очень эффективно учиться на примерах реального кода с подробными объяснениями. ИИ может это объяснить простыми словами и дать ссылку на документацию.
Инженерное мышление в программировании
Одним из важных и очень сложных процессов в разработке программ является создание эффективных инструментов. И это, пожалуй, касается инженерии в целом, где требуется изобретать что-то новое. Мне в программировании изобретать приходится постоянно - даже найдя себе специализацию, я никак не могу создать рутину по написанию приложений, все время появляется что-то новое. Конечно, я сталкивался с разработчиками, занимающимися чистой рутиной, например, разработчик WordPress, который годами делал одно и то же, не создавая ничего нового. Но это уже не инженерия в полном смысле этого слова.
Что разработчики понимают под эффективностью инструмента
Эффективность инструмента каждый разработчик определяет по-своему, но чаще всего рассматриваются такие критерии:
решение поставленных задач и возможных задач в будущем
скорость разработки и поддержки (включая тестирование)
производительность
гибкость, т.е. возможность максимально просто подстраиваться под меняющиеся требования
совместимость с другими инструментами
стоимость, масштабируемость, надежность, безопасность
Почему создание эффективных инструментов - это сложно
Сложнее даже не создать инструмент, а придумать каким он должен быть снаружи, какие у него должны быть функции, а не то как он реализован изнутри. Это кардинально отличается от обычных алгоритмических задач по программированию, которые можно встретить на сайтах типа CodeWars, где очень четко описываются требования к решению.
Составлять алгоритмы сложно, но многие важные в программировании алгоритмические задачи давно уже решены и вылизаны так, что их уже вряд ли получится сделать эффективнее. И обычно программисты не занимаются такими задачами. А вот задачи касающиеся инженерии кажутся неисчерпаемыми. В таких задачах заранее неизвестны даже требования.
Две фундаментальные проблемы инженерного проектирования
Первая проблема в том, что чтобы создать эффективный инструмент нужно проверить его эффективность, а чтобы проверить эффективность его нужно создать. Замкнутый круг. Из этого следует, что единственный способ создавать эффективные инструменты - эволюционный, когда пробуешь разные варианты и отметаешь неудачные. Первый этап эволюции происходит в голове разработчика, когда он моделирует различные ситуации, второй - практика, т.к. каким бы опытным не был разработчик он не в состоянии учесть все мелкие нюансы, которые вскрываются на практике.
Вторая проблема связана с выбором подходящего решения. Для каждой задачи обычно существует огромное множество разновидностей инструментов. Но каждый вариант несет свой набор ограничений и потенциальных проблем, как сейчас, так и в будущем. Разработчику нужно выбрать решение, которое не только решает текущие задачи, но и принесет минимум проблем в будущем. Не будет же разработчик пробовать все варианты, на это целой жизни не хватит.
Один из эффективных способов упростить эту задачу - это поиск доказательств, обоснований того, что какие-то функции в инструменте точно должны быть, а каких не должно быть, какие у него могут быть реальные ограничения не зависящие от разработчика. Это похоже на разгадывание судоку, постепенно сужая количество возможных вариантов. Но это работает не бесконечно, этот судоку не разрешим полностью, в итоге все равно остается много разных вариантов инструментов. Не редко бывает так, что разные варианты могут направлять разработку разными путями, а проблемы одного из путей вскроются на практике еще не скоро. Тут нужно либо думать больше, либо наступать на грабли и думать уже с новой информацией. Хуже когда хороших вариантов не видно вообще, и тогда приходится искать компромиссы или придумывать новые гениальные решения.
Почему ИИ не справляется с инженерными задачами
Все что умеют сейчас языковые модели - это программировать основываясь на шаблонах кода. В интернете полно всякого говнокода. Основываясь на нем можно сделать что-то простое и рабочее. Для этого как раз и не требуется заниматься инженерией. Но если захочешь создать что-то посложнее шаблонного сайта, LLM с этим не справится, и не потому что ей ресурсов не хватает или промпты плохие, а потому что она просто не занимается инженерией в том смысле как описано выше.
Для настоящей инженерии нужен процесс разработки, подразумевающий множество итераций сначала мысленного моделирования (требующий большого хорошо проанализированного опыта), а потом практических экспериментов. А миллион примеров кода в интернете - это даже не опыт и не анализ опыта, это просто результаты чьей-то работы, за которыми не видно успехов и неудач.
Мои попытки научить LLM инженерному мышлению терпели неудачу, потому что она все время забывала важные детали, а их очень много, искажала задачу на каждом шаге, перефразировала выкидывая важный смысл, так что через 10 итераций она просто не следовала уже никаким инструкциям, сочиняла какой-то мусор и получалась полная каша. Можно конечно на каждом шаге её учить и поправлять, тратя огромное количество времени, но в итоге она становится только тупее и тупее, и начинает тупо ждать правильного ответа. И это лучшая на сегодняшний день LLM - Claude AI 3.5 Sonnet.
Мифы о скором появлении AGI
В развитие ИИ вкладывается огромная куча денег, недавно была новость, что OpenAI потратили миллион долларов на тест модели потенциального AGI. Футурологи предполагают создание AGI в ближайшие годы или, как максимум, пару десятилетй. Но значит ли это, что AGI точно будет создан в этим сроки? Я считаю что нет, не значит.
Почему нельзя верить оптимистичным прогнозам
В науку тоже вкладывались большие деньги и были большие ожидания типа термоядерного синтеза, управления погодой, колонизации планет, персональных атомных реакторов, личных космомобилей, а многие сложности разработки вскрылись только в процессе.
Никто не знает, что будет необходимо для создания AGI, какие подводные камни всплывут в процессе попыток реализации этой задачи, просто потому что чтобы это узнать AGI сначала нужно создать. А значит никто не может сказать будет ли AGI создан в ближайшие годы, десятилетия или даже столетия. Какие угодно трудноразрешимые проблемы могут выявиться.
На чем основаны прогнозы футурологов?
Так на чем же основываются футурологи? Просто на прогрессе в области языковых моделей? Но ведь сколько гоночный автомобиль не развивай по воздуху он не полетит. Здесь нельзя полагаться просто на графики. Да здесь вообще, как мне кажется, не на что полагаться.
Единственное что можно с уверенностью ожидать, это то, что ученые выжмут максимум из имеющихся сейчас возможностей. А чем именно окажется этот максимум никто не знает.
Что мы вообще понимаем под AGI?
Важно отметить, что современные тесты AGI вызывают серьезные вопросы. С одной стороны, они проверяют способность пройти PhD тесты и решать сложные академические задачи. Но при этом те же самые модели проваливаются на простых детских задачах на абстрактное мышление.
Это поднимает интересный вопрос: если какая-то модель пройдет текущие тесты AGI, действительно ли это будет означать создание искусственного общего интеллекта? Ученые, возможно, откроют шампанское и объявят о прорыве, но будет ли это настоящим прорывом, если модель все еще не способна к базовому абстрактному мышлению?
Языковые модели имеют принципиальные ограничения
Современные языковые модели, из которых сейчас пытаются создать AGI, включая самые продвинутые как Claude AI, o1, o3, могут, основываясь на миллионе примеров, написать рабочий код. И на этом их возможности в программировании заканчиваются. Для написания продаваемого приложения с длительной поддержкой, нужно принимать множество эффективных решений, касающихся как кода, так и архитектуры, а этого нельзя сделать без исследования. С одним только ассоциативным мышлением невозможно заниматься исследованием, т.к. одна маленькая деталь может полностью опровергнуть одно решение, но ассоциативное мышление не придаст этой детали значения, потому что у этого решения есть сотня плюсов.
О возможных прорывах и "черных лебедях"
Конечно, нельзя исключать появление принципиально новых подходов к искусственному интеллекту. Языковые модели - это лишь один из возможных путей, и вполне вероятно, что настоящий AGI будет основан на совершенно других принципах. Возможно, это будут модели, способные к настоящему абстрактному мышлению и накоплению реального опыта - когда ИИ сможет сам программировать и проверять свой код на практике, учась на собственных ошибках.
Однако важно понимать, что таких потенциальных прорывов пока не видно даже на горизонте. Более того, текущие языковые модели имеют принципиальное ограничение - их мышление основано на словах, значения которых размыты, и на ассоциациях. С таким подходом крайне сложно построить строгое логическое рассуждение.
Человек ведь думает совсем иначе - в основном образами, а не словами. Словами мы формулируем уже готовые идеи, и даже это бывает непросто - как часто мы сталкиваемся с ситуацией, когда сложно подобрать нужные слова для выражения мысли! Что уж говорить об ИИ, который постоянно рискует неверно интерпретировать свои же слова и немного исказить смысл, а потом еще немного, и в итоге задачу вроде решит, но создаст еще 10 будущих проблем.
Заключение
В этой области невозможны точные прогнозы просто потому что AGI еще никто не создавал, ни у кого нет опыта, и никто не знает какие сложности возникнут на этом пути. А эти сложности могут отодвинуть разработку AGI на десятилетия.
Что же касается программирования, то в ближайшие годы мы увидим все более совершенные инструменты, помогающие в разработке. Но они останутся именно инструментами, помощниками программиста, а не его заменой. Потому что настоящая инженерия требует того, чего пока нет ни у одной языковой модели - способности исследовать проблему и находить действительно эффективные решения.
Комментарии (78)
Ilya_JOATMON
31.12.2024 14:50Мне кажется в ближайшие годы в прогграмирование столкнется с тем, что доступная вычислительная мощь перестанет расти и все доступные ниши уже заняты. К чему это приведет? Скорее всего к кризису в индустрии, а LLM будет всего лишь вишенкой на этом "торте". Уже сейчас народ увольняют, а это еще цветочки.
voidinvader
31.12.2024 14:50Народ увольняют из-за перенабора во время коронавируса. Конечно никто не знает какой внеплановый кризис ждёт мир в ближайшие пару лет, но это не значит, что вечно строить исключительно пессимистические прогнозы это оправдано.
Ilya_JOATMON
31.12.2024 14:50Как говорится - пессимист, это информированный оптимист. Перенабрали на оптимистичных прогнозах, а теперь пожинают. Сейчас спускают на ИИ образно говоря 100р получая выхлопа на 1р, и это тоже не бесконечно.
Newcss
31.12.2024 14:50Давайте попробую вставить свои 5 копеек. Опыт использования ИИ не столь большой как у Вас, но простые задачи, хорошо сформулированные ИИ (ChatGPT) выполняет на ура. Из примеров - есть CSV таблица, из данных в таблице сформируй SQL запрос вставки данных, или более частый пример использования - вот массив ключ значение, значение переведи с английского на русский и верни итоговый массив, про задачи - переименуй, замени я вообще молчу. Получается так, что сложную задачу если разбить на маленькие простые подзадачи и подать на вход ИИ - с большой долей вероятности получаем готовое решение. Все упирается в качество поставленной задачи.
NikolayMakhonin Автор
31.12.2024 14:50сложную задачу если разбить на маленькие простые подзадачи и подать на вход ИИ
== этот подход бы работал, если бы это было так просто - просто разбить проект на мелкие задачи. А это как раз и требует всего то, что я описал в статье про инженерное мышление. Потому что непродуманная и казалось бы мелочь может вылиться в большие проблемы в будущем. Большой опыт разработки многие такие проблемы быстро выявляет. Над какими-то приходится долго думать. Какие-то выявляются только на практике. Чтобы понять как вообще реализовывать проект из каких частей он должен состоять, нужно заниматься непрерывным исследованием, т.к. проблемы и неожиданности могут быть на каждом шагу, а лучше даже саму разработку превратить в одно большое исследование, побочным результатом которого будет готовый продукт.
jsirex
31.12.2024 14:50Почему-то вспомнился анекдот. В нашем сельхозе мы изобрели новый комбайн ГрибочекГПТ4000. Теперь комбайнёру осталось найти гриб и .. чик - остальное дело техники.
N-Cube
31.12.2024 14:50Если вы так считаете, то спроектируйте звездолет с варп двигателем - с помощью чатгпт разработайте теорию, чертежи и софт для реализации, сделайте смету. Или машину времени «в гараже» постройте- раз чатгпт всемогущ, по вашему мнению, что вам мешает? А переименовать переменные можно и регулярным выражением, тут никакого интеллекта не требуется.
evgeniy_kudinov
31.12.2024 14:50Поскольку текущее текстовое представление кода нужно людям, предположу, что системы на основе AI будут описание(техзадание) сразу воплощать в машинный код под нужную архитектуру. А другой AI будет проводить верификацию(доказательство) и соответствие машинного кода описанию в техзадании.Ну и, конечно, нужны будут люди, чтобы следили за такими системами. Вот почему, я думаю, не надо текущим и будущим разработчикам бояться AI, они будут делать немного другое, что делают сейчас.
RieSet
31.12.2024 14:50Точно. Если раньше инженеры жаловались на отсутствие ТЗ в проекте, то вот сейчас начнут его сами писать для ИИ
olku
31.12.2024 14:50Научил продактов формировать из потока мыслей типовые User Story. Вклад GPT достигает 50-80 процентов в зависимости от уникальности проблемы, остальное это модерация и уточнения.
Wesha
31.12.2024 14:50сейчас начнут его сами писать для ИИ
Я об этом уже столько раз писал:
...давным-давно, когда компьютеры были большими, разработчик набирал переключателями на пульте двоичный код, который потом исполнялся процессором. Потом программист стал писать человекочитаемыми буковками код низкого уровня (на ассемблере), который транслировался в машинный код, который исполнялся процессором. Потом разработчик стал писать код на языке высокого уровня (скажем, C — кстати, у сишных ++ и -- ноги растут из DEC-овских операций с авто{ин|де}крементом), который транслировался в код низкого уровня, который транслировался в машинный код, который исполнялся процессором. Теперь разработчик нового уровня будет писать очень-очень подробное и детальное техническое задание, не допускающее двояких толкований, которое транслируется в код на языке высокого уровня, который транслируется в код низкого уровня, который транслируется в машинный код, который исполняется процессором...
NikolayMakhonin Автор
31.12.2024 14:50не допускающее двояких толкований
== это сложно сделать на человеческом языке, где есть много многозначных или размытых слов
Wesha
31.12.2024 14:50это сложно сделать на человеческом языке, где есть много многозначных или размытых слов
(Восхищённо:) Мужики, а этот соображает!
flancer
31.12.2024 14:50:))) (y) Кстати, если развивать мысль дальше, то и у LLM в "мозгах" тоже много многозначного и размытого. И кодировать посредством LLM примерно то же самое, что "кодировать на человеческом языке". В зависимости от -настроения- температуры LLM может на один и тот же промпт выдать годноту, а может и "ай, всё!"
orenty7
31.12.2024 14:50А другой AI будет проводить верификацию(доказательство) и соответствие машинного кода описанию в техзадании.Ну и, конечно, нужны будут люди, чтобы следили за такими системами.
они будут делать немного другое, что делают сейчас.
Даже просто проверить, что тех.задание формализовано правильно -- уже достаточно неподъёмная задача, кратно сложнее средних задач программиста. По сути это даже не программирование, а скорее переквалификация в математика. В качестве подтверждения своих слов, я предлагаю вам посмотреть Iris Tutorial, в частности, формальную спецификацию ticket lock и попытаться понять что там написано (всё что между
ProofиQedэто доказательства, их можно пропустить). Отдельно отмечу, что на данный момент Iris это самый продвинутый фреймворк для верификации программ, то есть описывать спецификации проще пока никто не умеет
C-TV
31.12.2024 14:50Примечательность ИИ заключается в том, что он всесилен только в определённых областях, т.е. он не может знать того, чего в его обучении не заложено. Также он может только создавать из чего-то созданного, т.е. из чего-то существующего.
Ard33
31.12.2024 14:50А что у обучении не заложено? Там почти весь интернет и все библиотеки. Другое дело что пока он знает как все точно использовать. Та и человек создаёт на основании существующего. Ничего придумать полностью нового нельзя не опираясь на старые знания. А потом уже на основании нового ещё что-то и т.д.
acc0unt
31.12.2024 14:50"Почему автомобили не заменят кареты: взгляд лошади"
Именно вещам вроде декомпозиции сложных задач и пресловутого "инженерного мышления" сейчас и учат самые "злые" из передовых моделей. Те же o1 и o3 - развитие именно в этом направлении.
Претензия про то, что "ИИ совершают ошибки" очень по своей сути тупая. Потому что мы сравниваем ИИ не с какой-то божественной волей, абсолютно непогрешимой и к ошибкам неспособной, а с людьми. Которые ошибаются много и часто. И возникает вопрос - кто ошибок больше делать будет? Средний человек-разработчик, или лучшие ИИ текущего поколения? Средний человек-разработчик, или лучшие ИИ 2030 года?
А в "микро", в том, что касается базового "написать простой кусок кода, об который не спотыкается компилятор", доступные ИИ уже сейчас лучше людей. Потому что робот отлично выдрессирован, и выплёвывает синтаксически верный код без всяких там IDE с подсветкой несовпадений скобок.
Wesha
31.12.2024 14:50кто ошибок больше делать будет? Средний человек-разработчик
Простите покорно, мне просто жутко интересно: а
нафейхоазачем Вы нанимаете средних?acc0unt
31.12.2024 14:50Так большинство разработчиков на рынке труда - это разработчики средние, плюс минус.
Нанимать лучших? Это не только крайне дорого - это ещё и сложно. Потому что лучших разработчиков банально мало, и у них есть свои требования, и не факт что твои вакансии будут им соответствовать. Вряд ли лучшие из лучших пойдут на формошлёпство - даже если платят за это лучше чем в этих ваших Гуглах.
С ИИ такой проблемы нет, потому что ИИ - это софт. Если работает одна копия ИИ, то могут работать 10.
Wesha
31.12.2024 14:50Это не только крайне дорого
Ну то есть как всегда проблема свелась не к том, что «не хватает хороших разработчиков», а что «не хватает хороших разработчиков, готовых работать за миску риса».
А об этом ещё в 2011 году писали.
JBFW
31.12.2024 14:50Чисто для примера, замечательный чатГпт оптимизировал некий скрипт, и выполнил задачу просто отлично, синтаксически верно и без ошибок.
Но он не учел сторонние условия: отсутствие файлового пространства и потенциально бесконечный поток данных. Программист это предусмотрел, решая задачу, а в коде этого никак не было видно.
Результат - облом. Хорошо что проверили
А так да, синтаксически верно
randomsimplenumber
31.12.2024 14:50Программист это предусмотрел, решая задачу, а в коде этого никак не было видно.
Ох уж эти программисты, пишущие между строк.. ;)
JBFW
31.12.2024 14:50Просто из вариантов A, B, C, ... был выбран вариант P, в то время как чатГпт в лучших традициях школьника-отличника без опыта работы выбрал вариант A
Wesha
31.12.2024 14:50Ох уж эти программисты, пишущие между строк.. ;)
Вот вы тут ржОте, а тем временем настоящие программисты пишут между слов!
Sly_tom_cat
31.12.2024 14:50В интернете полно всякого говнокода.
А мне кажется вот этот фактор очень многие недооценивают. Посмотрев на некоторые проекты на github хочется "рассмотреть их назад". И вот на таком учатся все эти недопрограммисты. А теперь еще количество говнокода увеличивают сами LLM (руками тех кто на них полагается).
Объемы то огромные разметкой таких обемов (где говнокод, где так себе, а где можно приводить как пример) - просто не реальна. Любая автоматизация разметки (туже нейронку обучить на небольшом, размеченном датасете) - тоже не решает проблему полностью.
Причем любой опытный разработчик найдет нужный код/методики в интернете и без LLM.
Serge1001
31.12.2024 14:50Да раньше и без LLM копировали прямо со стековерфлоу.
И хорошо если из ответа, а не из вопроса :)
JBFW
31.12.2024 14:50Когда-то говорили "чтобы задать правильный вопрос надо знать половину ответа"
И иногда в чужом вопросе уже может находиться недостающая половина )
Видишь, человек мучается, решая то что у тебя есть, зато у него уже есть то чего нет у тебя...
ИИ это упрощает, он даёт уверенный ответ на любой вопрос, вместо "rtfm" даёт подробную, пошаговую инструкцию, решающую совсем другую задачу.
Wesha
31.12.2024 14:50Все что умеют сейчас языковые модели - это
...предсказывать следющий токен в потоке.
Если аффтар даже не разобрался, как работает (что именно делает) LLM — это уже весьма нелестно говорит о его инженерных компетенциях.
acc0unt
31.12.2024 14:50Говорить "всё, что делает LLM - это предсказывает следующий токен" - это примерно как говорить "всё, что делает компьютер - это читает данные с устройств ввода и выдаёт данные на устройства вывода".
Технически верно, но не очень полезно. Потому что упускает всё, что происходит внутри такой чудовищно сложной системы.
В LLM интересное нам поведение - это не то, что она выводит "следующий токен", а то, как она этот токен выбирает. И эта сложная неформальная логика, которая и определяет поведение LLM, похоронена в огромных массивах матричной математики. Разуму человека такие вещи сходу не поддаются.
Wesha
31.12.2024 14:50чудовищно сложной системы.
Система-то как раз сама по себе достаточно простая. Что зарубает на корню любые попытки в ней разобраться — так это её размер (как в хрестоматийном анекдоте).
AppCrafter
31.12.2024 14:50Отличный текст! Спасибо автору! Согласен полностью по поводу инженерного мышления.
Dataist
31.12.2024 14:50Генеральный директор Amazon Энди Джесси рассказал, что ИИ-помощник Q значительно сократил время обновления программного обеспечения компании, сэкономив сотрудникам тысячи рабочих часов.
По словам Джесси, Amazon Q интегрировали во внутренние системы компании для оптимизации обновления базового программного обеспечения. Он отметил, что среднее время обновления приложения до Java 17 сократилось с 50 дней разработки до нескольких часов. В итоге разработчики перенесли 30 тысяч приложений продуктов с Java 8 или 11 на более новую версию.
Джесси подчеркнул, что это сэкономило Amazon «4500 лет разработки». Он также упомянул, что 79% сгенерированных ИИ обзоров кода были отправлены без дополнительных изменений, подчеркнув точность инструмента.
NikolayMakhonin Автор
31.12.2024 14:50перенесли 30 тысяч приложений продуктов с Java 8 или 11 на более новую версию
== с конвертацией LLM справляется очень хорошо, с этим по-моему никто и не спорит, и такие задачи не требуют инженерного мышления.
Landgraph
31.12.2024 14:50Я б скорее предположил экономию за счёт отсутствия у ИИ необходимости создавать тикеты, апдейтить таски, ходить на синки, отвечать на запросы, искать баги , ждать когда другой ИИ вернется из отпуска, искать способы подставить соседнюю ИИ ноду и обвинить во всех проблемах и тд
В каждой шутке есть доля..,
Azerotos
31.12.2024 14:50вообще валидный аргумент и реальный кейс, что ИИ все таки заменяет разработчиков. пока в таких задачах, но дальше больше. "инженерство" будет за счет мультиагентных систем, где один агент будет кодером, а другой инженером или архитектором
Proscrito
31.12.2024 14:50Прошло уже 2 года. Действительно. Аж целых два. Или уже 3?
«Вес компьютеров в будущем не будет превышать 1,5 тонны». Журнал «Популярная механика», 1949 год. До появления первого персонального компьютера около 30 лет. И немало технических пророчеств смешат нас сегодня, хотя были сделаны серьезными технарями своего времени. Радио, телефон, компьютер. "Вряд ли кому-то придет в голову установить компьютер дома", говорил Кен Олсен в 1977 году. Основатель компании, производящей мейнфреймы, инженер и ученый. Звучит забавно по сей день.
Все предсказания о возможностях и перспективах ии будут выглядеть намного смешнее в гораздо более короткие сроки.
NikolayMakhonin Автор
31.12.2024 14:50Многое из того, что было предсказано без наличия реального опыта не сбылось, и многое превзошло ожидания. Из этого мы можем только сделать вывод, что такие события невозможно предсказать без реального опыта. Никто не знает. что необходимо для создания AGI, и сколько времени на это потребуется, т.к. еще нет опыта создания AGI.
Bedal
31.12.2024 14:50Традиции линейной экстраполяции сильны... Не будет нейросеть заменять программиста, она просто выполнит эту работу без того, что привыкли называть программированием. Пара примеров такого мне уже известна.
karmael
31.12.2024 14:50люди мечтающие свести свою интеллектуальную деятельность полностью на нет, с оптимизмом смотрят в будущее! так держать!
тем не менее, люди которым необходим протез, называются инвалиды.
Per_Ardua
31.12.2024 14:50Если кто-то пользуется калькулятором, это ещё не значит что он совсем не умеет считать
karmael
31.12.2024 14:50буквально вчера вы меня развлекали калькулятором с АИ. спасибо что не с АГИ
Per_Ardua
31.12.2024 14:50Не думаю, что я действительно в этом участвовал. В любом случае, я не говорил про то, что ai молоток - это хороший молоток. Видимо не смог своей аналогией донести мысль о том, что использование инструмента (протеза) не означает того, что пользователь не может работать без него (инвалид).
karmael
31.12.2024 14:50да, попробуйте лучше мне рассказать, зачем же в калькуляторе как это, а! ии агенты?
я вот совершенно искренне думаю, что вот если чат-боты заменят в индустрии людей которые вместо print(a+b), подключают LLM что бы спросить у неё, как вот, в её выборке обучения a+b это сколько? ничего страшного не произойдет.
fakedup
31.12.2024 14:50В интернете полно всякого говнокода
Следующие поколения моделей будут обучаться не на коде из интернета. Какой-нибудь Copilot выданный команде разработчиков позволит Майкрософту через довольно короткое время воссоздать кодовую базу проекта, со всей структурой, данными об окружении, документацией, etc. Ну и это будет не пет-проект Васи с курса, а рабочий продакшн энтерпрайз код.
Wesha
31.12.2024 14:50Следующие поколения моделей будут обучаться не на коде из интернета.
А на чём тогда? На коде, присланном инопланетянами?
fakedup
31.12.2024 14:50Ну вы хотя бы комментарий до конца осильте прочесть.
Wesha
31.12.2024 14:50Хотя бы головой осильте подумать. Не на том уровне, что «вот заведём ИИ — и оно всё завертится», а хотя бы представьте объёмы (точнее — мизерность таковых), на которых Вы сейчас предполагаете ИИ дотренировывать.
fakedup
31.12.2024 14:50Обьем закрытого кода сильно больше открытого.
Большая часть открытого кода - мусор.
Поэтому я оцениваю объём приватного полезного кода, к которому в течение нескольких лет будут иметь доступ вендоры llm (если ещё нет), сопоставимым с объёмом такового в открытом доступе.
Что там у вас по части аргументов? Или все мысленные усилия уходят на курсив?
Wesha
31.12.2024 14:50Большая часть открытого кода - мусор.
(Глядит жалостливо:) Мало Вы видели закрытого кода, челодой моловек, ой мало...
Landgraph
31.12.2024 14:50Мне вот интересно другое. С помощью ИИ пытаются избавиться/заменить/низвести рабочие специальности (при чем те, которые связаны с долгими инвестициями в обучение и совершенствование навыков). «Обычные» рабочие профессии давно уже под прессом автоматизации и всяких станков с чпу.
При этом крайне мало активности по замене «эффективных», которые, скажем так, имеют отдаленное отношение к производству чего бы то ни было.
Громогласно звучит «Давайте заменим ИИ всех ученых/писателей/актеров/художников/инженеров/итд» и крайне слабо слышно про избавление от «менеджеров» (особенно среднего звена), чиновников и тп, которые , бывает, занимаются исключительно решением своих личных амбициозных задач, не гнушаясь и откровенного вредительства.
Лично по мне ИИ должен быть своеобразным костылём-помощником для созидателей (накидать основу, подсветить проблемы, упростить доступ к информации), и средством избавления от «эффективных» переводом их в созидательное русло.
Так, условный ИИ может даже «взрослеть» вместе с «носителем»: сначала помогая обучаться и обучаясь совместно в зависимости от предпочтений «носителя». Помогать решать задачи: мне нужна легковесная ос реального времени с поддержкой аудио/видео - вуаля, дистриб линукса нарезан, выкинуто всё лишнее, работает на ардуинке… или нужны иллюстрации - на, вот, доработал напильником - сэкономил время, продолжил исследование. Написали закон? Автоматически проверен на непротиворечивость с имеющимися (еси чо - копирайты мои :)). Нужно заявление на что бы то ни было - сгенерирован текст запроса со всеми ссылками и тп. Обработка обращений - текст проанализирован, выдан базовый ответ для редактуры и последующего ответа. Судебные дела - тоже хелп. Короче так могу философствовать до бесконечности…
Goradiz
31.12.2024 14:50Цифровая фотография никогда не сможет заменить пленочную. Есть смысл просто найти замену процессу на серебре. В противном случае серебра может не хватить на дальнейшее развитие фотографии.... . (надо поискать эту статью в старых журналах фото и видео, там тоже много аргументов приводилось)
karmael
31.12.2024 14:50в Вашем случае, передёргивать было бы верным, если бы сравнивалась фотография и колоноскопия
proxy3d
31.12.2024 14:50Напишите кто то статью, где с помощью LLM мигрируете запросы SQL с mssql в postgres со всеми триггерами, процедурами и тд. Я постоянно использую chstgpt, сбер и другие llm, чтобы облегчить себе задачи в разработке.
Простые вещи решает отлично. Но что то сложнее и там полная ж... Будь это конвертация функций с одного фреймворка на другой, или где требуется подумать как можно сделать. И самое ужасное, что они пишут правдоподобно и если не перепроверить то проблема вылезет потом. Сделать функцию по формуле, по описанной блок схеме - да, ок. Прописать настройки, сохранить , загрузить данные из файла, сделать примитивные запросы, выдать инфу из доков.
Люди, которые довольны LLM и считают что они заменят. Напишите статью, я реально хочу понять, какие вы задачи решаете что llm отлично справляется и экономит время.
LLM отличный инструмент для облегчения ряда задач. Но даже при написании игры чуть сложнее арканоида, она уже начинает тупить.
Wesha
31.12.2024 14:50И самое ужасное, что они пишут правдоподобно и если не перепроверить то проблема вылезет потом.
Так это ж отлично — я работой (по расчистке завалов) до самой смерти обеспечен буду!
NikolayMakhonin Автор
31.12.2024 14:50если кто-то захочет за это платить
если бизнес не загнется раньше, из-за очень медленной разработки
Wesha
31.12.2024 14:50если бизнес не загнется раньше, из-за очень медленной разработки
Правильно! Пусть бизнес загнётся сразу, продавая 76000-долларовые машины за доллар! Зато какие будут обороты!
undersunich
Если Вы столь оптимистичны то для проверки Ваших "гипотез" реализуйте свои проекты, уйдите с головой в свой проект с AI а потом через год напишите что получилось.Вот это будет интересно. Вы после года такой работы почувствуете разницу в понимание происходящих процессов. Инженеры и те люди которые им платят думают и действуют по разному
NikolayMakhonin Автор
Я пытался и пытаюсь до сих пор, год пишу свой пэт-проект лично для себя, чтобы самому этим пользоваться. Я здесь и инженер, и пользователь, и менеджер, я сам себе плачу своим же временем. Использую GitHub copilot активно, даю Claude AI какие-то простые шаблонные задачи, и потом проверяю и исправляю его, на что тоже может уходить час - два, но это все же быстрее чем писать самому. В итоге, по истечению почти года, у меня получилось хорошее и удобное веб приложение, которым я доволен, но его делал в основном я, я принимал все тысячи решений, которые сделали это приложение удобным и которым приятно пользоваться. LLM модели предлагали шаблонные и плохие решения, потому что они не обладают моим опытом, они не могут продумывать будущие проблемы, вместо исследования они лопатой загребают мусор и вываливают в чат, подавая как хорошие решения, или делают вид что что-то исследуют, а в итоге получается тот же мусор. Я даже не знаю возможно ли сделать удобное приложение из мусора, я даже пробовать не хочу, у меня хватает опыта поддержки плохого кода, чтобы в это не вляпываться.
undersunich
Похвально я тоже так работаю, но мы с Вами видим мир как инженеры.И к сожалению инженеры не управляют нашим миром.И у них другой взгляд.Я как раз не очень то оптимистично смотрю в будущее. AI не принесет в ближайшее время счастья высококвалифицированным специалистам, он их "сьест".И что делать пока не очень понятно
flancer
Не съест, не волнуйтесь. Просто позволит высококвалифицированным специалистам быть более эффективными. Специалист с ИИ будет круче специалиста без ИИ или просто ИИ без специалиста. Ну или ИИ со специалистом будет круче - если кому-то удобнее другая центровка.
Landgraph
Мне кажется тут вообще подмена понятий идёт «кодер» и «погроммист».
Сферические программисты в вакууме так и продолжат программировать, только не через кодинг и IDE, а несколько иными инструментами, в числе которых генерация кода ИИ-кодерами. Как бы сферический язык высокого уровня это уже сильно не то, что ассемблер.
Wesha
В программировании самое главное — это предсказуемость (
[ 1, 15 ] + [ 2, 28 ] = [ 1, 15, 2, 28]) и повторяемость результатов (2 + 2 = 4вне зависимости от фазы Луны) — в то время как в основу LLM изначально заложена случайность, см. температура. А недетерминированным молотком сами гвозди забивайте (только дайте мне сначала удалиться на безопасное расстояние).akod67
всё так, но самих рабочих мест из-за возросшей эффективности пар специалист+ИИ может стать сильно меньше
diakin
В комментарии выше имеется в виду, что решение "делать ли приложение из мусора" принимают не инженеры, а менеджеры. И если у менеджера появится возможность сократить должность инженера, сэкономить на ФОТ и получить за это бонус, то он ей воспользуется обязательно. А то, что "приложение из мусора" никого не будет волновать - "работает же".
NikolayMakhonin Автор
= но советуются то они с инженерами или нет? нельзя же принимать важные решения без экспертных знаний, которыми менеджеры здесь не обладают
= а потом выявится неприятный баг или понадобится новая фича, а в этом говнокоде уже мало кто разберется, включая GPT. Можно нанять опытного программиста, но кто из опытных за это возьмется, за обычную зарплату? Я не возьмусь, я не работаю с ужасным кодом, я уже наступал на эти грабли. Или попрошу зарплату в 2-3 раза выше за такую работу.
Инженер об этом знает, а менеджеры - нет. Хороший менеджер скорее обратится к инженеру за советом в такого рода решениях, потому что инженер - эксперт в написании и поддержке приложений, а менеджер - нет.
Wesha
Это до первого серьёзного взлома.
flancer
Что-то на ум пришёл чувак из Гугла - Прабхакар Рагхаван. Он успешно, без взломов, похерил поиск в Yahoo, и так же успешно закапывает поиск Гугл. Когда у эффективного менеджера перед носом маячит морковка в виде бонуса, он способен на очень многое. И за взломы, кстати, будут отвечать инженеры, а не эффективные менеджеры.
Gorthauer87
Ну так такие люди разрушают конкретные компании, высвобождая место под солнцем для других, но они не разрушают всю индустрию сразу же.
Вот когда он окончательно похерит поиск Гугла, то на рынке поисковиков появится конкуренция. История с IE6 это все наглядно демонстрировала.
geornit25
Думаю, что такие попытки - заменить разработчиков ИИ-агентами, мы точно увидим в недалеком будущем. Это прямо идеально ложится в парадигму zero-code.
Можно и менеджеров тоже на ИИ поменять и сразу продавать ИИ-компанию "под ключ" собственникам или же выводить её на IPO.
А вот насколько это будет успешным - вопрос открытый.