Почему ИИ не заменит программистов: взгляд инженера

в 14:29, , рубрики: AGI, ai-агенты, gpt, llm, ИИ, инженерия, инженерный подход

Я инженер-программист с общим опытом больше 15 лет в разных областях. Сейчас специализируюсь на веб разработке, это моя профессия и основное хобби. Есть большой опыт применения ChatGPT, включая o1 и Claude AI на практике в своей работе. Я рассуждаю здесь с позиции этого опыта и логики. Сразу хочу сказать, что я не боюсь, что ИИ меня заменит, а наоборот мечтаю об этом, потому что у меня есть много нереализованных идей, требующих много времени на реализацию. И на этих же идеях, кстати, можно и заработать. Когда инженер получает инструмент заменяющий его, он не теряет работу, а становится инженером следующего уровня.


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

Текущее состояние и перспективы развития

На данный момент LLM модели могут писать фрагменты кода приемлемого качества на основе уже написанного. Это направление сейчас активно развивается. Но каждый такой фрагмент кода должен быть проверен программистом. LLM не способны мыслить архитектурно и моделировать будущее, даже если их об этом настойчиво попросить. Когда только начинаешь писать приложение, нужно продумать его структуру, типы данных, как это все будет взаимодействовать. Даже Claude AI не может это сделать минимально адекватно. Он руководствуется какими-то общими принципами, но нужно ведь еще думать, проигрывать в уме как это все будет работать и какие могут быть проблемы. Современные модели ИИ думать не умеют, даже рассуждающий o1 не думает.

В ближайшие пару лет мы, вероятно, увидим:

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

  2. Развитие инструментов проверки кода на ошибки. Программирование - это по большей части поиск и исправление ошибок и других проблем. Чем раньше выявлена проблема, тем меньше времени в итоге будет потрачено на ее исправление. ИИ здесь сильно помогает выявлять множество проблем еще на ранних стадиях разработки. Человек не в состоянии быстро проанализировать тысячи строк кода и найти едва заметные проблемы, а с LLM можно находить такие ошибки за пару минут.

  3. Увеличение размера контекста, чтобы LLM могла охватить весь проект целиком, состоящий из сотен тысяч строк кода, видеть структуру файлов и папок.

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

Инженерное мышление в программировании

Одним из важных и очень сложных процессов в разработке программ является создание эффективных инструментов. И это, пожалуй, касается инженерии в целом, где требуется изобретать что-то новое. Мне в программировании изобретать приходится постоянно - даже найдя себе специализацию, я никак не могу создать рутину по написанию приложений, все время появляется что-то новое. Конечно, я сталкивался с разработчиками, занимающимися чистой рутиной, например, разработчик WordPress, который годами делал одно и то же, не создавая ничего нового. Но это уже не инженерия в полном смысле этого слова.

Что разработчики понимают под эффективностью инструмента

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

  • решение поставленных задач и возможных задач в будущем

  • скорость разработки и поддержки (включая тестирование)

  • производительность

  • гибкость, т.е. возможность максимально просто подстраиваться под меняющиеся требования

  • совместимость с другими инструментами

  • стоимость, масштабируемость, надежность, безопасность

Почему создание эффективных инструментов - это сложно

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

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

Две фундаментальные проблемы инженерного проектирования

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

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

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

Почему ИИ не справляется с инженерными задачами

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

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

Мои попытки научить LLM инженерному мышлению терпели неудачу, потому что она все время забывала важные детали, а их очень много, искажала задачу на каждом шаге, перефразировала выкидывая важный смысл, так что через 10 итераций она просто не следовала уже никаким инструкциям, сочиняла какой-то мусор и получалась полная каша. Можно конечно на каждом шаге её учить и поправлять, тратя огромное количество времени, но в итоге она становится только тупее и тупее, и начинает тупо ждать правильного ответа. И это лучшая на сегодняшний день LLM - Claude AI 3.5 Sonnet.

Мифы о скором появлении AGI

В развитие ИИ вкладывается огромная куча денег, недавно была новость, что OpenAI потратили миллион долларов на тест модели потенциального AGI. Футурологи предполагают создание AGI в ближайшие годы или, как максимум, пару десятилетй. Но значит ли это, что AGI точно будет создан? Я считаю что нет, не значит.

Почему нельзя верить оптимистичным прогнозам

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

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

На чем основаны прогнозы футурологов?

Так на чем же основываются футурологи? Просто на прогрессе в области языковых моделей? Но ведь сколько гоночный автомобиль не развивай по воздуху он не полетит. Здесь нельзя полагаться просто на графики. Да здесь вообще, как мне кажется, не на что полагаться.

Единственное что можно с уверенностью ожидать, это то, что ученые выжмут максимум из имеющихся сейчас возможностей. А чем именно окажется этот максимум никто не знает.

Что мы вообще понимаем под AGI?

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

Это поднимает интересный вопрос: если какая-то модель пройдет текущие тесты AGI, действительно ли это будет означать создание искусственного общего интеллекта? Ученые, возможно, откроют шампанское и объявят о прорыве, но будет ли это настоящим прорывом, если модель все еще не способна к базовому абстрактному мышлению?

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

О возможных прорывах и "черных лебедях"

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

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

Человек ведь думает совсем иначе - в основном образами, а не словами. Словами мы формулируем уже готовые идеи, и даже это бывает непросто - как часто мы сталкиваемся с ситуацией, когда сложно подобрать нужные слова для выражения мысли! Что уж говорить об ИИ, который постоянно рискует неверно интерпретировать свои же слова и немного исказить смысл, а потом еще немного, и в итоге задачу вроде решит, но создаст еще 10 будущих проблем.

Заключение

В этой области невозможны точные прогнозы просто потому что AGI еще никто не создавал, ни у кого нет опыта, и никто не знает какие сложности возникнут на этом пути. А эти сложности могут отодвинуть разработку AGI на десятилетия.

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

Автор: NikolayMakhonin

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js