Comments 30
Проблема LLM заключается в том, что ее "понимание" ситуации совершенно ситуативно, и не имеет целостной модели мира/явления/предмета о котором оно рассуждает. Типичный пример того, как обваливается стильная-модная система оркестрации с агентами на реальной задаче:
Агент пишет код, потом другой агент запускает тесты
Тест падает с ошибкой. Агент: "Ой, тест упал - сейчас мы это поправим..."
Тест опять падает. Агент: "Ой, а может быть у нас тест некорректный? Я сейчас запущу экземпляр сервиса и проверю через API"
Запускает сервис, тест через API тоже предсказуемо падает
НЕ УБИВ СЕРВИС, агент пытается внести изменения в код и пересобрать проект
Сборка падает, потому что исполняемый файл занят другим процессом
Агент: "Ой, извините, я сломал сборку своими изменениями - сейчас я их откачу"
... и дальше агент начинает планомерно разносить до основания проект ("Ой, наверное это база данных падает, давайте ВРЕМЕННО заменим вызовы БД на заглушки", "ой, наверное это из-за аутентификации, давайте ВРЕМЕННО удалим этот код".
В конце-концов, он разносит в хлам билд-файлы, и выдает шедевральное "Ой, наверное тут SDK неправильно сконфигурирован, я ничего больше не могу сделать" - и останавливается.
При этом, агента в его выводе НИКАК не смущает что вот только что - система и собиралась, и запускалась, и SDK был нормально сконфигурирован, а теперь вот на тебе! У него нет целостного понимания окружающего мира, и он даже не может понять что происходит что-то выше его понимания, и хотя бы остановиться!
А вы хотите чтобы это чудо самостоятельно что-то разрабатывало!...
Поводом для написания этой статьи послужила очередная психологическая война (не найду более подходящего определения) с LLM в попытке решить относительно простую задачу, а именно написать систему сборки проекта на CMake вместо пользовательского Makefile.
есть две категории людей. Одни говорят, что ИИ полностью заменяет рабочих, другие - что ИИ вообще ничего не умеет. И те, и другие неправы. Вы относитесь ко второй категории.
Ну вы то точно относитесь к первой, тогда как вижу реальный потенциал при использовани LLM, но в текущей реализации есть серьезные проблемы при их использовании в разработке ПО, о чем я и написал.
Ну вы то точно относитесь к первой
где конкретно я написал "считаю, что ии полностью заменит рабочих"?
У меня одна модель не смогла написать слово по буквам в обратном порядке - есть задачи, с которыми ИИ не справляются, например, из-за особенностей реализации, а другая (claude opus 4.5 с режимом high) за один промт в пару предложений создала MVP продукт на node.js с минимальными ошибками - и то из-за того, что я не уточнял детали.
Вы же даже не указали какую именно модель использовали. Может там какой-нибудь qwen 0.5B, который почти ничего не умеет.
Дело не только в модели, но и в технологиях, даже самая посредственная модель будет прекрасно справляться с перекладыванием json-ов на каком-н node.js, и при этом даже самая лучшая модель довольно быстро сядет в лужу с kernel-mode драйвером. Потому что количество данных для обучения отличается на несколько порядков. В итоге кто делает первое везде кричат что ИИ полностью заменяет рабочих, а кто второе - что ИИ вообще ничего не умеет.
Вы правы и не правы. Я делю вполне тривиальную вещь, но так как огромный текстовый вывод компилятора тоже попадает в контекст для анализа, то фокус внимания нейросети по любому будет размываться из-за обилия дополнительной информации.
Мне очень понравилось использовать LLM для генерации начальных прототипов ПО, но с рефакторингом и дальнейшим развитием у них полный швах.
где конкретно я написал "считаю, что ии полностью заменит рабочих"?
Где конкретно я написал, что LLM "вообще ничего не умеет"?
Я написал о конкретной проблеме, которая осложняет процесс использования LLM в разработке ПО и предложил вариант решения обозначенной проблемы. Без этого потенциал ИИ можно использоватаь преимущественно в простых задачах, что серьезно сужает область их применения.
Вы вроде написали о конкретной проблеме, но опустили важные обстоятельства, из-за чего не видно общей картины.
Я тут еще подумал - вы же и промт конкретный не указали. Если я напишу даже умной модели просто "сделай рефакторинг", то и она может внести "вредные" правки.
Про важные обстоятельства я как раз написал и они не зависят от модели или конкретной промпта.
Я понимаю, что уточнениями в теории можно вытянуть то или иное решение, чтобы привести его в качестве аргумента в споре, но мне бы хотелось иметь инструмент, который хорошо работает всегда, а не раз от раза в зависимости от фазы луны.
Конкретно в моем случае я понимаю в чем там дело
Все программисты в мире делятся на две категории:
— Те, кто считает, что ChatGPT кодит на порядок лучше их;
— Те, кто считает, что ChatGPT кодит на порядок хуже их.
И первые, и вторые абсолютно правы.
Воспроизводимость - дорогая фича. Она мешает разработке и поддержке, а пользователь, завязавшийся на неё, скорее всего прикуёт себя к конкретной сборке конкретной LLM. Это более сильная и болезненная привязка, чем версия другого софта, например компилятора или OS
Полностью согласен, что это дорогая фича и нужна не каждому, но иногда без нее не обойтись. К тому же многое зависит от способа реализации, можно сделать её платной и подключаемой только по запросу, либо при её активации отключать рассуждающие надстройки и т.д.
Давайте пофантазируем. Я хочу использовать "воспроизводимость" в продовом процессе. Это значит, нужно фиксировать архитектуру и веса моделей, эффективно фиксировать даже не минорную версию, а именно билд и системные промпты. То есть сервера, которые обрабатывают мой запрос должны обязательно содержать именно тот конкретный билд LLM.
В пределе поставщик должен держать все билды всех LLM для которых просили воспроизводимость. Зачастую это будет ради 1-го пользователя. Это должно стоить безумных денег, которые никто не согласится платить.
С точки зрения пользователя всё ещё хуже. Я строю продовый процесс, который прибил гвоздями условную версию 5.1.23.2314rc3. Обязательно придёт время, когда захочется использовать новую версию (новые фичи, исправление багов, моральное устаревание и т.п.). Однако переезд будет золотым, потому что сломается всё, где были завязки на воспроизводимость. Даже задача переезда с одной версии компилятора на следующую в больших кодовых базах сложная, хотя там контракты очень стабильные, специфицированные, и в теории ничего ломаться не должно. Здесь же переезд будет просто невозможен, ну или вам не нужна была воспроизводимость.
Может вспомним Сократа? «Кто хочет, тот ищет возможности, кто не хочет — ищет причины»
Можно делать не для всех билдов, а для специальных LTS с определенным сроком поддержки. Системные промпты идентифицируются элементарно через хеш и даже если они меняются часто, то их размер значительно меньше самой модели.
Но мне кажется, мы по разному пониманием назначение подобного функционала. Мне важна не только сама воспроизводимость, но и информация о том, что воспроизводимость конкретного запроса не реализована, что дополнительно поможет идентифицировать источник проблем.
И мотом, раз уж говорить об использовании LLM, то при наличии воспроизводимости запросов, реализовать автоматический или полуавтоматический апгрейд промптов на более свежую версию LLM с помощью её же самой, становится обычной инженерной задачей.
Я конечно похож на моську, которая тявкает на опытного сеньора (судя по профилю автора), но позвольте вставить свои 5 копеек.
1) "LLM — это вероятностная система, а значит, не интеллект". А человек — не вероятностная система? Да, LLM — это не мозг с синапсами и нейротрансмиттерами, где "интеллект" возникает из хаотичной, но адаптивной сети (стохастика в нейронных спайках или пластичность в гиппокампе). Это всего лишь вероятностный автокомплит текста, обученный на петабайтах данных, без настоящей саморефлексии, префронтальной коры и других причуд, свойственным кожаным.
2) Temperature=0 + фиксированный seed + фиксированная версия модели + фиксированные параметры дают детерминизм. Это тривиальная вещь, которую нормальные провайдеры уже умеют (или могут сделать, и многие сделали на уровне API).
3) И мое любимое — ложные ожидания. С новичками, которые вайбкодят. Так это только начало. Сейчас они научатся писать промпты, вырастет контекстное окно у моделей, адаптируются инструменты (привет Antigravity); и они уже начнут вытеснять мидлов по эффективности. А менеджмент компаний? Напоминает ситуацию, когда было 20 токарей, но купили ЧПУ станок, и теперь он один делает работу за 20 токарей. Проблема тут в том, что уволили 20 сотрудников, наняли эникейщика, а надо было нанимать опытного оператора, который сможет работать со станком.
Лично я считаю, что сейчас хайп по ИИ, как и с любыми технологиями, которые начали сильно изменять нашу жизнь. НО вот этот текст звучит как ворчание луддита, который требует, чтобы квантовая механика работала по законам Ньютона, потому что так надежнее. Индустрия уйдет вперед, также, как это было с изобретениями разных машин и методов.
зы: я осознанно использую em dash
Проблема LLM заключается в том, что ее "понимание" ситуации совершенно ситуативно, и не имеет целостной модели мира/явления/предмета о котором оно рассуждает. Типичный пример того, как обваливается стильная-модная система оркестрации с агентами на реальной задаче:
Агент пишет код, потом другой агент запускает тесты
Тест падает с ошибкой. Агент: "Ой, тест упал - сейчас мы это поправим..."
Тест опять падает. Агент: "Ой, а может быть у нас тест некорректный? Я сейчас запущу экземпляр сервиса и проверю через API"
Запускает сервис, тест через API тоже предсказуемо падает
НЕ УБИВ СЕРВИС, агент пытается внести изменения в код и пересобрать проект
Сборка падает, потому что исполняемый файл занят другим процессом
Агент: "Ой, извините, я сломал сборку своими изменениями - сейчас я их откачу"
... и дальше агент начинает планомерно разносить до основания проект ("Ой, наверное это база данных падает, давайте ВРЕМЕННО заменим вызовы БД на заглушки", "ой, наверное это из-за аутентификации, давайте ВРЕМЕННО удалим этот код".
В конце-концов, он разносит в хлам билд-файлы, и выдает шедевральное "Ой, наверное тут SDK неправильно сконфигурирован, я ничего больше не могу сделать" - и останавливается.
При этом, агента в его выводе НИКАК не смущает что вот только что - система и собиралась, и запускалась, и SDK был нормально сконфигурирован, а теперь вот на тебе! У него нет целостного понимания окружающего мира, и он даже не может понять что происходит что-то выше его понимания, и хотя бы остановиться!
А вы хотите чтобы это чудо самостоятельно что-то разрабатывало!...
Вы говорите как любой человек который не делал с помощью llm большой проект. Когда у нее забиваемся окно токенов чатом с вашими правками, она начинает галюционировать. Когда вы создаёте каждый раз новый чат для маленькой задачи, она пишет случайным образом и не ориентируется в проекте. На большом проекте это игра в лотерею и перегенерацию, где крутить барабан рандома придётся тем чаще, чем больше ваш проект.
Особенно выгодно это создателям llm чтобы вы уже создали что-то и дальше без llm не могли поддерживать эту махину, а на большом коде это лотерея.
А самое грустное что пока вы вайбкодили, вы как специалист не выросли вообще. Вы всё ещё в отправной точке по вашим знаниям и опыту по написанию кода. Поэтому даже джун в этой ситуации лучше, т.к. рано или поздно он придёт к правильному решению, сам разработает подход для решения своих задач, научится на своих же ошибках, и будет выдавать ожидаемый результат.
Тут я полностью согласен. При помощи ллм вкатывался в незнакомую мне технологию и понял, что без ллм я все вообще не ориентируюсь. И за это мне не нравится вайбкодинг. Но так или иначе это уже неизбежно и через какое-то время мы к этому придем. Это будет похоже на переход с низкоуровневых на высокоуровневые ЯП.
Напоминает ситуацию, когда было 20 токарей, но купили ЧПУ станок, и теперь он один делает работу за 20 токарей.
Уж не намекаете ли Вы, что в Вашей команде 20 программистов каждый день пишут одну и ту же программу?
Мы в компании столкнулись сейчас с тем, что джуны, часто использующие LLM в работе, не развиваются в мидлов, а наоборот - деградируют. Нагенерил код, сдал таску и начисто забыл о том, что и как делал. А может и не знал вообще.
Как код работает в проекте, как сам проект работает, как работают смежные с ним проекты - они разбираться не хотят, а зачем? Это не говоря уже о качестве "нагенеренного" кода - повторяемости там нет даже близко. Одному LLM так сгенерила, другому - по-другому, третьему - третий вариант и т.д.
Я сейчас как раз переделываю за вайбкодерами внутренний проект - в коде просто цирк с конями... Антидепрессанты приходится пить к концу года...
Ну в защиту LLM могу сказать, что прототипы она генерит достаточно хорошо и после доработки напильником получается вполне рабочий. Главное не забывать делать побольше тестов
Скоро будет актуален фреймворк, который проверяет уровень LLMшности кода, который выдаёт программист, и если он часто делает коммиты с 90% ллмошным кодом, на него будут косо смотреть.
Честно говоря я уже даже не уверена, что дело в LLM. Первый раз я встретила такого джуна с год назад, все как вы описали - сдал работу, забыл что делал. Доходило до смешного, буквально неделя разницы между однотипными задачами, а он уже не помнит, что делал и как решал, ошибки буквально идентичные. Но писал без нейронки. Гуглил правда бездумно, буквально копировать-вставить без понимания, что делает. Сработало - хорошо, не сработало - гуглил снова. Закрыл задачу - забыл.
Сейчас второй похожий, как в дне сурка, одни и те же ошибки снова и снова по кругу, обучения ноль.
Автору респект. Недавно смотрел на канале Егора Бугаенко мысли взрослого мидла по этому вопросу, и люди сходятся со мнением что это хайп. LLM это шуруповёрт, которым удобно можно вспоминить или узнать код, или устроить брейншторм, что будет бустить вас как специалиста, но вайбкодинг это опиум для ленивых - он собирает вам проект, в котором вы без LLM ничего не можете, и чем шире проект тем чаще вам нужно перезапускать LLM чтобы дальше масштабировать его. При этом вы как были человеком без опыта и знаний, так и остались тем же человеком без опыта и знаний.
В человеке слишком много механизмов чтобы нас заменила LLM. Мы учимся, нам скучно, мы ищем новые подходы, мы делаем импульсивные решения, а потом анализируем свои ошибки и учимся делать лучше, и главное у нас есть встроенное желание улучшать и делится. Потом мы суммируем свои знания, оформляем их, и передаём другим поколениям в виде библиотек и фреймворков, новых подходов и языков. Мы являемся источником новы паттернов. А LLM всеголишь плохо повторяет наши же заученные патерны но разных людей.
Через неё удобно познавать и получать опыт других людей, как суммарайзер. Функция которую она чаще всего пишет, скорее всего исторически уже системный подход целого поколения программистов, но новый паттерн или улучшение она придумать не может.
LLM хорошо подходит на роль резинового утёнка — этого у него не отнимешь.
Использую нейросети в качестве "гугла на максималках" и радуюсь. Это позволяет соблюдать баланс, где, с одной стороны, легко отупеть, т. к. всё делается за тебя, а с другой - очевидно, глупо отрицать новые появившиеся профиты.
А еще мне искренне жаль менее опытных коллег, которые не способны понять, что при текущем уровне развития нейросетей их бездумное и бесконтрольное использование - это в перспективе билет в один конец.
Согласен. Причем даже не просто Гугл на максималках, а Гугл + GitHub с примерами кода.
А еще мне искренне жаль менее опытных коллег, которые не способны понять, что при текущем уровне развития нейросетей их бездумное и бесконтрольное использование - это в перспективе билет в один конец.
Не переживайте, эйфория от ИИ быстро походит после первых затрещин от коллег или при попытке поддержать одноразовый ИИ код (так и напрашивается ассоциация с изделием номер 2)
LLM станет (идеальным программистом и работнико) не тогда, когда у него будет ещё больше параметров, а когда сложатся три вещи: длинная и управляемая память, дешёвые вычисления (вплоть до in-memory), контроль внимания, и контроль ошибок/галлюцинаций. Технически это уже в разработке
Главная проблема использования ИИ (Иллюзии Интеллекта) при разработке ПО