Comments 54
Зачем делигировать LLM то, что вы можете сделать лучше неё сами, вручную?
Да, зачем вообще брать LLM если я могу это сделать лучше её сам, вручную?
Ручная работа всегда была лучше. Но дольше и дороже.
Тогда как отличить какую часть -- автоматизировать, а какую -- самопалить? Почему "тут" а не "здесь"? Где грань?
Например вопрос "вкатывания" в язык. Раньше на изучения языка тратились годы, сейчас, при помощи LLM - месяцы, а то и недели. Я бы даже сказал, что если ты уже знаком с каким-либо языком схожего назначения на хорошем уровне, то при помощи LLM вкатиться в новый язык можно... за неделю смело. Пишешь прототип, просишь LLM тебе всё объяснить, прогоняешь раз десять все мелочи, и считай уже освоил практику. Я до появления LLM года три учил документацию по JS, в свободное время, что бы в него "вкатиться", с появлением LLM процесс, можно сказать, на порядок упростился. Сразу пишешь - ничего не понимаешь - потом разбираешь. Всё равно, что с сеньором работать рядом, сами понимаете разницу по скорости изучения языка. Мой личный прогноз - через пять-десять лет все фулстеками будут, потому что, например, зная JS, я ноду освоил за несколько дней, ну и так далее. Написать мобильное приложение, если ты знаешь только веб? Не проблема. Написать веб, если ты знаешь только десктоп - не проблема. LLM подвинули это всё на принципиально новый уровень. Этакий супер-гугл. А гугл уже давно "мёртв". Почти всё забито инфоцыганством до невозможности. Найти что-то толковое, как 20 лет назад - стало в разы сложнее. Гугл из инструмента превратился в развлекательный ресурс. Я считаю, что это и стало основой для зарождения среды появления LLM.
"при помощи LLM вкатиться в новый язык можно... за неделю смело."
Ей бы кто объяснил язык, при переводе функции составления regexp с python на pascal Deepseek r1 мне вмандюрила переменную I как итератор по вектору найденных строк и сразу ниже i как счётчик в цикле по этой строке, функция всего 6 строк, у нас любой школьник знает, что Паскаль регистронезависим
Паскаль не используется в индустрии - нет кодовой базы - нет обучающей выборки.
Python2, Python3 -- вагоны их -- но py2to3 лучше делать скриптами, разницу и миграцию сеточки делают отвратно.
PyGTK -- есть кодобазы и выборки всех размеров и форм -- но миграцию с одного на другую сеточка сделать не может.
На счёт python не скажу, но на фронте при миграции фреймворков vue и react на новые мажорные версии справляется достаточно хорошо (с react вообще за одну итерацию с 18-ой на 19ую, с vue за три-четыре, но там и посложнее миграция). Но тут ещё и от агента зависит и от того как он настроен. Да и от размера проекта: какие-то небольшие можно целиком перенести, какие-то только частями.
Если он у тебя в деревне не используется, это не значит что он не используется в индустрии, кодовой базы полно на github
https://madnight.github.io/githut/#/pull_requests/2024/1
Q1 2024
Python: 16.925% (-0.284%)
Java: 11.708% (+0.393%)
Go: 10.262% (-0.162%)
JavaScript: 9.859% (+0.306%)
C++: 9.459% (-0.624%)
TypeScript: 7.345% (-0.554%)
PHP: 5.665% (+0.357%)
Ruby: 4.706% (-0.307%)
C: 4.616% (+0.208%)
C#: 3.442% (+0.300%)
...
50. Pascal: 0.026%
В масштабах big data это примерно нисколько. Фортран на сороковом. Есть хоть один пример чего-то хоть сколько-нибудь серьёзного написанного на Паскале? Для индустрии это мертвый язык. Уже как лет тридцать. Два с половиной НИИ пишущих по традиции - не в счёт. Исключение подтверждает правило, как известно.
зачем ходить так далеко? в коде на 10 строчек использовать i и I одновременно может только изверг. вне зависимости от языка. даже если переменные допустимы только однобуквенные.
Я специально потратил полчаса на то, что бы найти хоть один реальный пример применения Паскаля, и не нашёл. Есть отрывистые комментарии на тему "на нём микроконтроллеры пишут", но ни одного реально примера применения за полчаса гугления найти не удалось. Могу в свою очередь рассказать про COBOL, на нём, понятное дело уже не пишут, но так как на нём огромные кодовые базы, исправно работающие, то оптимизируют и переписывают будь здоров. Паскаль-то - он реально применяется, или это уже из разряда "просто по фану писать пет проекты"?
Сразу пишешь - ничего не понимаешь - потом разбираешь
Написать мобильное приложение, если ты знаешь только веб? Не проблема. Написать веб, если ты знаешь только десктоп - не проблема
Не совсем так. Такой результат можно получить в 7-8 случаев из 10, в зависимости от сложности проекта и его объема. Из за (все ещё существующих) галлюцинаций, отлаживать ошибку ничего не зная о ней не так легко, а LLM иногда имеет свойство ходить по кругу, и мы попадаем в бесконечный процесс фиксов.
Поэтому что бы писать код быстро и качественно с LLM, знание программирования все ещё нужно.
Изначальный смысл статьи как раз заключался в описании методов получения безгаллюционной генерации. Разбиение на подзадачи обычно помогает, плюс если LLM "затупила", то это обычно какой-то действительно специфичный момент, например проблема отсутствия возможности обращения к псевдоклассам из JS. Эта задача ставит в ступор даже опытных разработчиков (решается либо аттрибутными селекторами, либо прямой записью в таблицу стилей). Но тут достаточно немножко погуглить, и всё сразу находится, да и сама LLM обычно понимает в чём может быть проблема, просто по специфичным задачам мало базы знаний и она "боится" выдавать выдачу с малым количеством примеров в базе (так настроены практически все LLM). Тут надо заставить её дать все возможные варианты и самому прогонять их, включая самые неочевидные, либо же с самой LLM их поочерёдно разбирать. По той же проблеме с псевдоклассам - LLM предполагает что это может быть проблемой, но в её приоритетах возможных проблем она занимает третье-четвертое место, т.е., надо сначала отсеять два-три неверных варианта и тогда натыкаешься на правильное решение. Это единственный серьёзный затуп в работе с JS, который мне встретился за очень долгое время, как сейчас говорят, "вайбкодинга", или простыми словами - использования LLM для генерации кода.
Разбиение на подзадачи обычно помогает, плюс если LLM "затупила", то это обычно какой-то действительно специфичный момент
В целом да, но сильно зависит от версии LLM. Не могу сказать за все, использую только GPT. Заметил у 04-mini-high и 04-mini свойство возвращаться к прошлым вопросам и отвечать на них, даже при наличии четкой инструкции и конкретики кода, как раз таки с разбиением. 4о при этом таких шагов не делает.
Но тут достаточно немножко погуглить, и всё сразу находится
Вот тут и кроется кирпич, погуглить в целом можно, но понять что действительно поможет, а что отведет на ложный путь можно если есть насмотренность, что приходит с опытом.
Тут надо заставить её дать все возможные варианты и самому прогонять их, включая самые неочевидные, либо же с самой LLM их поочерёдно разбирать
Это хорошая практика при работе с LLM, однако сама LLM может увести в ложное русло в процессе объяснения, особенно часто это случается когда окно контекста заполняется и начальная стадия проекта забывается. Это особенно актуально, когда кодовая база проекта исчисляется сотнями строк. LLM может попросту забыть часть функционала, исправляя что-то другое.
Если максимально концентрировать контекст - то хватает даже мизерного контекстного окна. Например, если у вас фронтенд, то тупо убираете все стили кроме необходимых, это как спорт, счёт идёт на байты буквально. Все лишние зависимости, абсолютно всё. Оставляете только чистую логику. Потом уже на готовую логику вешаете обратно всё. При таком подходе даже базовая LLM с минимальным контекстным окном "тащит" будь здоров, выдавая на 99.99% верный код. Даже верстку можно перелопатить ради упрощения логики, удалив все лишние блоки. Потом её обратно "раскрыть" на написанной логике - не проблема.
Если максимально концентрировать контекст - то хватает даже мизерного контекстного окна.
Тут опять же зависит от обьема проекта, если связка зависимых функций и блоков будет большой и без этой цепочки не разобрать функционал корректно, то мы упремся в контекстное окно. Такой подход очень хорошо работает на небольших блоках данных, где проблема видна явно либо находится в этом узком радиусе.
Даже верстку можно перелопатить ради упрощения логики, удалив все лишние блоки. Потом её обратно "раскрыть" на написанной логике - не проблема.
Опять же, это работает если мы понимаем что и как нужно убрать, не сломав ничего при этом и потом вернуть обратно. А если смотреть на случай который указывался выше:
Написать мобильное приложение, если ты знаешь только веб? Не проблема. Написать веб, если ты знаешь только десктоп - не проблема
То тут и начнутся сложности. Придется потратить некоторое время на изучение вопроса, с той же LLM, и в последствии мы уже будем убирать/возвращать не нужные блоки имея знания/опыт/понимание, а значит изначально без понимания и знаний (базовых по тематике) будет довольно сложно/время-затратно добиться качественного результата.
Но тут опять же, если мы делаем калькулятор, то с такой задачей справится почти любая LLM и будет не сложно производить декомпозицию, а вот на проектах по сложнее...
…как сейчас говорят, "вайбкодинга", или простыми словами - использования LLM для генерации кода.
Использование LLM ≠ Вайбкодинг.
«Вайбкодинг» ассоциируется с бездумным, поверхностным использованием LLM и слепым принятием результата «по наитию». Все описанные вами техники (тщательная подготовка контекста, декомпозиция задач) — это как раз антиподы вайбкодинга, примеры осознанного, дисциплинированного подхода к работе с LLM. Вы фактически описываете не‑вайбкодинг под заголовком о вайбкодинге.
Ну уж как называют, не я придумал. Я наблюдаю тенденцию просто, что это слово ушло в народ. По крайней мере в англоязычной среде это уже абсолютно устойчивое понятие, я бы даже сказал, зарождающаяся научная дисциплина, как уже устоявшийся, в качестве научной дисциплины, промпт-инжиниринг. Мне в целом нравится название, вайб (vibe) просто благозвучное слово, оттуда и популярность его использования в сленге и терминах.
Ни «вайбкодинг» (как анти‑практика), ни «промптинг» (как практический навык) не являются «научными дисциплинами». Не стоит путать хайп и ремесло с наукой.
«Вайбкодинг» — это анти‑дисциплина, отсутствие инженерного подхода.
Вам правильно выше сказали. Посмотрите хотя бы шуточные видосы на ютубе по запросу вайбкодинг
Попробуйте "вкатиться" в русский. В тексте поражающее количество грамматических ошибок.
язык по документации учить надо а не в ллм смотреть, а потом думать ой а что это такой функции не существует
Качественный контекст и декомпозиция — это база работы с LLM, а не откровение. Без этого ничего не работает в принципе, и это знают все, кто использовал LLM дольше пяти минут.
Фактически, сегментируя задачи и повышая концентрацию контекста, можно заставить даже самые базовые модели работать на уровне мощнейших и лучших.
Нет, нельзя. Хоть опляшысь ты с бубном — если работаешь с 7B моделью, которая двух слов связать не может, ты получишь шлак.
Выбор качественной модели — это первое правило хорошей генерации. Часто это означает: взять лучшую из доступных топовых, а не пытаться выжать что-то осмысленное из модели, которая обучалась на "трёх рецептах борща".
Ещё один, немного необычный совет для работы с LLM — купите хорошую игровую мышку.
И коврик не забудьте.
Пост родился из диалогов на хабре, я в нём просто изложил, можно сказать, то что, на мой взгляд упущено многими, а именно - возможность устойчивой безошибочной генерации практически на любом языке на любой современной модели. Касательно возможностей "базовых моделей" - это уже вопрос личного понимания этого термина. Фактически всё что я написал было верно ещё несколько лет назад, т.е., любая актуальная качественная модель соответствует всему вышесказанному. Понятно, что под базовой тут понимается "любая модель из актуальных". Ну не усложняйте, это как с дистрибутивами линукс, понятно, что под базовой имеется ввиду "что угодно нормальное".
Касательно 7B моделей, ну вот, вроде, неплохо справляющаяся с генерацией кода 7B модель [ https://www.promptingguide.ai/ru/models/mistral-7b ]. Опять-таки, это очень широкий вопрос, и тут нельзя прямо вот так сказать: "годится или не годится". Вопрос базы знаний и много чего ещё. Опять-таки, если вы понимаете базу информатики, то думаю, для вас очевидно - что код это попросту точная текстовая абстракция. Соответственно что? Соответственно работа с кодом - это минимальная нагрузка на LLM. Поэтому, если, например, при работе с "логическим мышлением" справляются только лучшие LLM - то с генерацией кода запросто справляются даже самые "базовые" (опять-таки, не стоит абсолютировать этот термин, давайте воспринимать его адекватно).
Моя мысль и тут заключалась в простом посыле, который, опять-таки, у меня родился после многочисленных диалогов на Хабре на данную тематику. Немногие понимают, что работа с кодом, в силу базовых принципов информатики - является самой простой задачей для LLM, а значит и самой сильной их стороной. Код это не просто текстовая абстракция, код это точная текстовая абстракция с наборов устойчивых правил, а значит при наличие данных правил в базе знаний и самых базовых библиотек в составе модели - модель не может ошибаться чисто "информатически". Это всё равно что прогонять её по усложнённой таблице умножения. В отличие от работы с текстом, логикой и прочим - это абсолютно элементарная задача для LLM, на уровне базовой математики. Вы понимаете о чём я говорю? Это для LLM просто, как прогонять математическую формулу по базовым принципам, то есть это сверх-простая задача даже для простейших LLM. Там уже дальше качество генерации - вопрос базы знаний и прочих условий, коих великое множество, то есть даже обсуждать это в одном комментарии не имеет смысла, тут на две статьи тема и это только вступление будет.
Про коврик классная идея, надо бы подумать. Без стёба. Когда мне нужно что-то сгенерировать - я просто ищу в своём проекте все необходимые для генерации зависимости, копирую их в текстовый файл и подготавливаю запрос (этакий супер-промпт), который содержит все необходимые для LLM данные, сами понимаете сколько текста, хороший коврик тут действительно может помочь. При качественной подготовке "запроса" ещё ни разу ни одна LLM не выдавала мне неверный ответ. В этом и была основная мысль статьи. Просто хотелось поделиться с хабровчанами, потому что я накопал с этого ресурса немало полезной информации, полезно, знаете ли, когда выбираешь фреймворк - знать мнение людей, которые не одну декаду в индустрии.
Судя по всему, вы ни разу не встречали сложных проблем. Оттуда и такие заблуждения...
Я готов поспорить, что мои выводы подтвердятся через несколько лет. Это просто наблюдения сделанные за годы использования LLM для генерации кода (или "вайбкодинга", как сейчас говорят). Любая сложная проблема - разбивается на части и успешно решается. Если решение не находится - дело может быть исключительно в нехватке базы знаний, это значит что речь идёт либо об очень специфичной проблеме, либо об очень специфичном языке/фреймворке/библиотеке.
Да не нужно даже и сложных. Достаточно простых и сразу видны различия в работе. Клод если и косячит, то его можно заставить "думать" и исправлять, крог зануда, каких мало, в каждой итерации половина ответа повторение предыдущего или промта, чатгпт как недоучившийся программер, что то слышал, но сам пробует сделать первый раз.
Техники (контекст, декомпозиция) важны, не спорю. Но для реальных задач все упирается именно в выбор достаточно мощной модели. Никакая условная 7B не заменит 100B+ на сложных задачах, как ты с промптом не пляши.
Я ни вижу причины, почему если в базе знаний есть библиотеки с языком и библиотеки генерации кода и LLM способна понять запрос, то, чисто с точки зрения базовых принципов информатики - как она может ошибиться? Это невозможно просто "информатически". По моим наблюдениям, LLM модели за последние несколько лет стали лучше понимать сложные запросы и композировать сложные задачи, но в целом, как они писали безошибочный код при качественном промпте, так и пишут, ничего не поменялось, обычно в языке есть два-три способа решить задачу и не более, максимум четыре-пять. LLM все эти способы известны и они их выдают, этот функционал не меняется из года в год.
Как может ошибиться? Очень просто. Наличие в корпусе обучения НЕ РАВНО зннаию. Ллм вероятностные, и могут и по факту врут на ровном месте!
Именно!
Наличие данных ≠ Знание/Понимание
Вероятностная природа → Галлюцинации/Ошибки ("врут")
Так о чём я и говорю! Что LLM перешагнули этот порог! LLM сфера это как Linux-сфера, то есть есть постоянно растущий общий уровень, так как все копируют друг друга, простыми словами - всё это форк, даже само ядро форкают у форков. Как в JS добавляют функционал из фреймворков, сначала jQurey (почти полностью добавили в спецификацию), сейчас TypeScript подъехал, уже процесс идёт, скоро будет в JS опциональная строгая типизация, скоро React подвезут (htmx и ему подобные фреймворки, уже идут официальные обсуждения о включении в спецификацию). Потом ещё pug приплывёт - крутейшая штука. Так, я немного отвлёкся, суть в том, что общий уровень сферы - растёт синхронно. Все LLM за год примерно на один уровень подтягиваются, а что там подтягиваться, скопировал c Hugging Face последние библиотеки и здрасьте-пожалуйста (почему я и настаиваю, что отечественные LLM вполне себе пригодные к работе, они обычные форки, на обычном для индустрии уровне, точно не хуже). Так вот, LLM перешагнули уровень "непонимания" кода ещё ~лет пять назад (очень примерно). То есть сейчас все, абсолютно все LLM на 100% понимают работу с кодом на любом актуальном языке/фреймворке/библиотеке (при наличие достаточной базы знаний). Я уже неделю пытаюсь донести эту мысль до хабровчан, а мне не верят, "потому что DeepSeek не конвертирует в Паскаль". Откуда по Паскалю бигдате взяться? Глобально язык уже тридцать лет не применяется в крупномасштабной коммерческой разработке. Не хочется на Паскаль наговаривать, хороший язык, но надеяться на работу с Паскалем через LLM попросту наивно.
Я уже неделю пытаюсь донести эту мысль до хабровчан, а мне не верят
напомнило:
Жена звонит мужу на мобильный: - Алло, ты где? - Я в машине, на садовом. - Ты там осторожнее, по телевизору показывают - там какой-то придурок по встречной полосе едет!!! - Ты не поверишь, их здесь сотни!!!
Индустрия перешагнула все проблемы LLM обсуждаемые на Хабре уже лет как пять назад. Тут у большинства мнение, как будто мы в 2020-ом.
А каким образом вы получаете информацию о том, что "индустрия перешагнула", или о том, каким образом "народные массы" понимают термин вайб-кодинг?
У меня складывается ощущение, что вы полагаете, что ваше собственное мнение является верным. Оно может таковым быть, но обобщение его на всех - это величайшая ошибка.
Пример. Мне нравится кофе американо с утра, и эспрессо после обеда. Но я не могу утверждать, что "в индустрии все пьют кофе по утрам, и эспрессо после обеда" на основе только того, что я считаю американо и эспрессо вкусным.
Если бы они "100% понимали", они бы не делали тонких логических ошибок, не зависели бы так сильно от качества промпта и контекста, и не галлюцинировали бы. Это прямое следствие их вероятностной природы и отсутствия истинного "понимания". Они имитируют понимание через статистическое предсказание, и эта имитация несовершенна.
Уровень топовых коммерческих моделей (OpenAI, Anthropic, Google) и средних open-source моделей не одинаков. Невозможно заменить топовую модель слабой за счет "плясок с промптом".
Пытаться решить сложную задачу слабой моделью, даже с идеальным промптом — это как пытаться перевезти рояль на велосипеде.
Вы сводите LLM к системе, которая (при наличии данных в «базе знаний» и «понимании» запроса) детерминированно применяет правила. Ваша вера в «информатическую безошибочность» при правильном промпте игнорирует вероятностную природу моделей.
У LLM нет «базы знаний» в виде структурированных фактов и правил. У нее есть миллиарды параметров (весов), отражающих статистические закономерности в обучающих данных. LLM не «понимает» запрос, а статистически предсказывает наиболее вероятное продолжение на основе входных данных и своего внутреннего состояния.
Генерация (по своей природе) вероятностна. Даже при одинаковом запросе (с ненулевой температурой) результат может варьироваться. Ошибки — это не сбой «информатической» логики. Они возникают из‑за неточностей в статистике, пробелов в обучающих данных, неверного применения выученных шаблонов или просто из‑за сложности самой задачи.
Именно это я и пытаюсь развеять, потому что все LLM модели - это по большому счёту форки друг друга (всё собрано из общедоступных опесорсных баз на Hugging Face, т.е., примерно та же ситуация, что и с Linux). Ещё несколько лет назад LLM вышли на уровень когда они, в силу хорошо обученных базовых библиотек 100% точно генерируют код. Безошибочно. Соответственно, добавляем качественную базу знаний (есть теневой рынок с "известными" ценами, да и опенсорс тут поспевает за индустрией, буквально ~~~через полгода догоняя коммерческие разработки) - и получаем безошибочную генерацию (согласно базовым принципам информатики). Т.е., LLM уже вышли на "стадию безошибочной генерации" кода. О чём и речь. И уже давно, сейчас просто их все опробовали в работе и, можно сказать, ревью пишут.
Ваше упорное утверждение о "100% точности" и "безошибочной генерации", якобы достигнутой LLM несколько лет назад, оторвано от реальности. Ни одна LLM, даже самая мощная сегодня, не является безошибочной. Это не вопрос "добавления базы знаний" — это следствие их вероятностной природы. Они предсказывают наиболее вероятный код, а не доказывают его корректность. Они блестяще имитируют понимание через статистику, но их вероятностная природа гарантирует, что ошибки всегда возможны и реальны. Никакие "форки" и "базы знаний" не отменяют этого факта.
Не я один ежедневно сталкиваюсь с ошибками, галлюцинациями и необходимостью тщательной проверки сгенерированного кода.
Мы с вами уже неделю спорим общаемся, причём это происходит в формате: я пытаюсь объяснить базовые вещи, вы в ответ упорно аргументируете. Ладно попробуем упростить аргументацию:
LLM это попросту набор алгоритмов и база знаний (с этим спорить вы не можете, так как это технические факты)
если у LLM библиотеки позволят работать с кодом безошибочно, то при наличие достаточной базы знаний - LLM не может ошибаться (сейчас у всех популярных LLM библиотеки на хорошем уровне и база знаний по популярным языкам отличная)
возникает вопрос только контекстного окна, это огромная тема для дискуссии, поэтому скажем так - если вам хватает контекстного окна, то при условии соблюдения других условий - LLM не может ошибаться, потому что в её основе точные алгоритмы и точная база знаний, а рандомность выдачи это настраиваемая опция
при нехватке контекстного окна действует краткая инструкция изложенная мной здесь [ https://habr.com/ru/articles/903618/comments/#comment_28215552 ] (фронтенд, но применимо ко всему), при применении данной инструкции, вы получаете 99.99% точную генерацию, например, за несколько лет экспериментирования с генерацией JS - я получил всего один случай, когда LLM с трудом справилась, и этот случай - недостаток архитектуры самого JS, описал эту ситуацию тут [ https://habr.com/ru/articles/903618/comments/#comment_28214944 ]
Вы, по неизвестной мне причине, полностью игнорируете, что LLM вероятностные. Они ошибаются — это технический факт, подтверждаемый практикой. Следовательно, и код, который они пишут, — вероятностный, а не 'информатически безошибочный'.
LLM — мощный, но ошибающийся, вероятностный инструмент, требующий контроля.
Почему автор бесконечно пытается всех убедить, что LLM не предсказывают наиболее вероятный ответ, а действуют по какому-то алгоритму? Да ещё и все ллмки это "форки друг друга"... Чозабред.
Сам текст говорит о вполне хороших техниках для работы с языковыми моделями, но заголовок противоречит этому. Это не вайбкодинг (который буквально означает копипасту того, что даёт нейросетка, а не разумный подход), а наоборот анти-вайбкодинг.
Автору нужно разобраться что же такое вайбкодинг, как работают нейросети.
Потому что увлекаюсь генерацией кода при помощи LLM ("вайбкодингом") уже много лет, задолго до появления Курсора и прочих и попросту высказываю свои наблюдения. "Предсказывания" это тоже алгоритм, причем, если его разобрать - очень простой. Попробуйте напишите простенький бэкенд на node.js/sqlite. Там нет вариативности решений, всегда есть только одно, соответственно, LLM выдает только один вариант всегда. Символ в символ. Это и показывает явно суть работы LLM с кодом. Простые алгоритмы, угадывание только в том что и как лучше делать. Но если мы скормим LLM запрос содержащий точные инструкции, не дающие возможность отклониться от способа выполнения задачи, то LLM генерирует 100% точный ответ, при наличии нужной информации в базе знаний. Т.е. угадывание мы, при помощи простейших лайфхаков, таких как "сложный запрос" (скармливание LLM всего необходимого контекста и инструкций) заменяем исполнением инструкций. В целом - если мы можем заставить LLM вместо "предсказаний" исполнять инструкцию, а вместо галлюцинаций выдавать генерацию, прибавьте сюда лайфхаки описанные мной в статье и комментариях - и мы получаем стопроцентную точность генерации кода на любом популярном языке/фреймворке/библиотеке. А то что "все LLM - форки друг друга", я не писал, это вы невнимательно читаете, я написал, что они "плюс-минус форки друг друга", так как созданы из одних и тех же опенсорсных библиотек, даже лучшие коммерческие модели.
А все ещё есть Битрикс. Его почти не обсуждают на стаковерфлоу. Код с новыми фишками подсматриваешь на Ютубе. И конечно нейросети выдают фигню, ведь никто не запостил решение такое проблемы.
Порой даже простые вещи приходится корректировать.
Но технология прикольная. Жду когда такую можно будет запускать локально.
Будни вайбкодинга: лайфхаки при работе с LLM