В JS наоборот надо по рукам бить, что бы слишком новые стандарты не использовал, все LLM очень любят grid, хотя полно ещё легаси устройств на руках у людей, где grid не поддерживается, на фронтенде для массового пользователя это принципиально.
"Вероятностную природу LLM" - смешное утверждение. Каким образом она вероятностная? Базовые принципы информатики - слышал? Что такое абстракция понимаем? Любой язык = усложненная таблица умножения, любая абстракция = просто ещё один уровень усложнения. Вероятностная она только потому, что запихиваете огромный контекст в узкое контекстное окно, по итогу LLM не справляется и начинает галлюционировать, а не потому что технология изначально "вероятностная". Изучите структуру LLM - она одинаковая плюс-минус у всех, и все LLM построены на плюс-минус одних и тех же библиотеках. Плюс ещё, если речь о Flutter - ну конечно, для вас она "вероятностная", потому что там под капотом мультипарадигменный движок, который требует кучу контекста в работе, по итогу кроме Claude ничего не справляется, и даже он еле-еле тащит всю эту кучу. Вы когда пишите: "мне эти принципы не подходят" - всегда язык уточняйте, потому что если речь о мультиплатформе, то это вы особенный, а не мы все особенные. На нативе и без фреймворков - всё что я написал на 100% работает. Плюс уровень абстракции - больше контекста - сложнее задача для LLM. У вас уровень абстракции максимальный, потому что фреймворк + мультиплатформа, то есть, простыми словами, вы исключение подтверждающее правило.
У меня изначально не очень хорошее отношение к Flutter, потому что несмотря на крутость самой технологии, так сложилось, что в девяти случаях из десяти Flutter применяют там где не надо. По идее Flutter - это про скорость развёртывания и прототипирования, в итоге все сводится к экономии, когда одним разработчиком целую команду заменяют, по итогу мы получаем ужасно тормознутые приложения, я уже не говорю про фронтенд. Дайте посмотреть на ваш уровень вложенности блоков, я уверен, там штук двадцать вложенностей, когда реально, без фреймворков - я не могу представить когда больше пяти может понадобится, если писать руками на чистом CSS. Плюс ещё дикая тормознутость, хуже чем у React/Vue/Angular, на которых у тебя в райнтайме огромное количество JS выполняется в реальном времени, по итогу если открыто куча вкладок и тут вкладка с Flutter прилетает - то браузер тупо падает, потому что привет 20% загрузки CPU, да-да, однопоток, мы всё ещё едем на нём. Я уже не говорю про тормознутость всего этого флаттеровского фронтедерского счастья на мобиле, где открыл на чуть не актуальном устройстве и ждёшь пока загрузится, "зато прогрессивный мультиплатформенный движок". Мы имеем дико тормознутый интернет в 2025-ом из-за как раз таки всей этой среды. У обычного пользователя на машине доступно не 16Gb RAM, а 50Mb, потому что уже сто вкладок открыто, но нам же надо проект делать, некогда на нативе пилить, да ещё и зная как у нас в стране обычно эксплуатируют Flutter и для чего, потом слышать пафос от разработчиков использующих Flutter это просто нелепо. Огромный мульти-парадигменный фреймворк, который сложен в работе и архитектуре, потом пишешь статьи с базовыми вещами, которые пригодны для 90% пользователей LLM, приходит флаттерщик (уже просто преследует из ветки комментариев в ветку комментариев) и начинается: "вот я только на клоде писать могу, всё остальное дрянь, контексту мало". Нет это вы особенный, это не мы все особенные. Для ванильного JS контекста надо на порядок меньше при работе с любой LLM. Переписывать что-то конкретно под Flutter я не буду, это нишевый фреймворк, для большинства, как концепт и инструмент - непригодный.
Вы читать умеете? Возьмите список топ-20 моделей по популярности, все будут в этом списке. Мы в 2025-ом, добро пожаловать, уже даже опенсорсные модели качественно генерируют код. Вы со своим Flutter носитесь, как будто весь мир вокруг Flutter вращается. Ну с Flutter своя специфика, его, по большому счёту, только модели с большим контекстным окном могут хорошо переварить. Кроме вас на сайте аудитории больше нет? 90% читателей используют более распространённые языки и поэтому для них сгодятся самые базовые модели, тут надо понимать, что это вы "уникум", а не "большинство не право". Flutter это довольно редкий фреймворк, пусть и локально популярный у определенной части аудитории Хабра, а глобально - с мизерной аудиторией. Адаптировать свои комментарии под "клуб любителей Flutter" ради вашего одобрения и ещё пяти пользователей, как-то неинтересно.
У вас какие-то странные вопросы. Я вам только что ответил, что использую все хоть сколько-нибудь популярные LLM одинаково, так как при правильном подходе, подавляющее большинство современных LLM выдаёт хороший результат. Из популярных LLM мне не довелось попробовать только Grok, потому что он требует премиум-аккаунта на Twitter. В 2025 уже особо разницы между хорошими LLM нет, если вы конечно умеете ими правильно пользоваться. Если вам лень разгребать контекст, ну делегируйте вопрос Claude, кто мешает-то? Подавляющее большинство читателей этого сайта использует базовые модели, а вы себя ведёте, как будто весь сайт только для вас существует.
Если ты хорошо язык знаешь (и умеешь с LLM работать), то вникать особо не нужно, просто смотришь как за тебя на экране проект генерируется, в редких случаях поправляешь.
Генерирует, но не редактирует, тут буквально недавно человек писал, что все LLM сыпятся на базовом редактировании SVG. Аналогично CSS - сгенерировать не так уж сложно, теперь попробуйте заставить LLM хотя бы из одного блока перенести меню с несколькими уровнями вложенностями в другой, так что бы верстка не посыпалась.
LLM в основной своей массе это про то что в первой десятке на этом графике и немного за его пределами. Есть такая вот LLM на два гигабайта [https://huggingface.co/bigcode/starcoder2-3b], которая по отзывам, при умелой работе, очень неплохо пишет код. Понятно, что речь не о стеке Dart/Flutter. Dart, с точки зрения машинного обучения - это язык с малым количеством общедоступной бигдаты. В отличие от JS, Python и прочих популярных языков. Flutter же, в свою очередь, фреймворк (да ещё и довольно молодой), т.е., это сужение специфики. У вас специфичный (с точки зрения общедоступной обучающей выборки) стек, а я говорю о среднестатистическом пользователе LLM, которому надо скрипт для фронтенда на JS написать или на Python алгоритм. Вот пара рейтингов популярности языков, для общей картины.
При использовании моделей с большим контекстным окном - они просто сами за тебя разгребают контекст, при использовании вышеназванных методов - в этом нет нужды, поэтому при подобном подходе можно практически любую модель использовать.
То что вы описали - это не излишняя логика. И разбиение на подзадачи и декомпозиция это не одно и тоже. Например, у вас есть JS который работает со списками и потом куда-нибудь отправляет результат. Вам надо сделать так, что бы выполнялись условия a, b, c, d, e, f. Сначала вы очищаете работу со списками от последующей отправки, так как это не имеет значения для задачи, то есть - декомпозиция, а потом сначала решаете задачу а, потом уже переходите к b и последующим. То есть декомпозируете вы свой код, а разбиваете на подзадачи промпт. Насколько я помню из диалогов с вами, вы работает с Rust, я с ним дело не имел, поэтому комментировать работу с Rust - не буду. Речь, скорее, об универсальных принципах, которые плюс-минус подходят для любой задачи.
простыми словами, код в запросе к LLM должен быть максимально очищен, промпт максимально продуман, точен и максимально наполнен необходимой информацией; простое правило: чем проще код и чем лучше промпт - тем качественнее генерация
Ну не скажите. На JS отлично с нуля пишет, если пропмт хороший. Очень сильно зависит от стека и задачи. JS в интернете жёван-пережёван > тонны бигдаты > огромная база знаний > качественная генерация. Редкий язык, специфическая задача, специфическое окружение - и всё - приплыли, гугли, пиши вручную.
LLM пока что не умеют в сложный вектор, и тем более, плохо работают с программным обращением к вектору. Вектор это пока что самая недоступная для LLM сфера информации. Даже на примере CSS, который по сути, текстовый векторный редактор - это хорошо видно, сложную архитектуру CSS даже самая продвинутая LLM не может написать. Мобильная адаптация - вообще сразу мимо, только самые базовые задачи.
минимизация контекста (из базы данных данных удаляем все значения, кроме нескольких, удаляем все лишние зависимости, и прочее)
как вы правильно сказали, кормим LLM полный стек, ещё желательно полностью скормить ей архитектуру проекта, насколько это возможно (если вы работаете с уже имеющейся кодовой базой)
кормить LLM надо ровно-ровно, байт-в-байт столько информации, сколько нужно, я бы сказал, это буквально спорт; при правильном подходе качество выдачи на несколько порядков улучшается
не стоит ожидать что LLM будет хорошо работать по задаче по которой у LLM малая база данных (редкая сборка linux, например) - будет чисто угадывание с галлюцинациями разного качества и разной степени пригодности
чем популярнее язык и чем больше по нему общедоступной биг-даты, тем лучше работает LLM; как пример - Javascript практически идеально (на любой сложности задачи, лишь бы контекстного окна и окна выдачи хватало) генерирует почти любая современная LLM; у JS всегда идентичное окружение (стандарт W3, то есть браузер), и у LLM нет возможности ошибиться, только в очень специфичных случаях (работа из JS с псевдоклассами, что по стандарту невозможно и реализуется только через хаки, это единственное, где LLM тупят)
на специфическом окружении, и редкой задаче - считайте, что LLM для работы непригодны, лучше сразу гуглите
никогда, ни при каких условиях, не кормите LLM излишнюю логику, только необходимый для понимаю моделью скелет; лишняя логика усложняет для LLM прохождение по лабиринту базы знаний, дольше генерации, меньше шансов на успешную генерацию, т.е., принципиально важный момент, абсолютно критический в практической работе
Который может без устали писать бойлерплейт 24/7/365 - немаловажное уточнение, надо заметить.
В JS наоборот надо по рукам бить, что бы слишком новые стандарты не использовал, все LLM очень любят grid, хотя полно ещё легаси устройств на руках у людей, где grid не поддерживается, на фронтенде для массового пользователя это принципиально.
"Вероятностную природу LLM" - смешное утверждение. Каким образом она вероятностная? Базовые принципы информатики - слышал? Что такое абстракция понимаем? Любой язык = усложненная таблица умножения, любая абстракция = просто ещё один уровень усложнения. Вероятностная она только потому, что запихиваете огромный контекст в узкое контекстное окно, по итогу LLM не справляется и начинает галлюционировать, а не потому что технология изначально "вероятностная". Изучите структуру LLM - она одинаковая плюс-минус у всех, и все LLM построены на плюс-минус одних и тех же библиотеках. Плюс ещё, если речь о Flutter - ну конечно, для вас она "вероятностная", потому что там под капотом мультипарадигменный движок, который требует кучу контекста в работе, по итогу кроме Claude ничего не справляется, и даже он еле-еле тащит всю эту кучу. Вы когда пишите: "мне эти принципы не подходят" - всегда язык уточняйте, потому что если речь о мультиплатформе, то это вы особенный, а не мы все особенные. На нативе и без фреймворков - всё что я написал на 100% работает. Плюс уровень абстракции - больше контекста - сложнее задача для LLM. У вас уровень абстракции максимальный, потому что фреймворк + мультиплатформа, то есть, простыми словами, вы исключение подтверждающее правило.
У меня изначально не очень хорошее отношение к Flutter, потому что несмотря на крутость самой технологии, так сложилось, что в девяти случаях из десяти Flutter применяют там где не надо. По идее Flutter - это про скорость развёртывания и прототипирования, в итоге все сводится к экономии, когда одним разработчиком целую команду заменяют, по итогу мы получаем ужасно тормознутые приложения, я уже не говорю про фронтенд. Дайте посмотреть на ваш уровень вложенности блоков, я уверен, там штук двадцать вложенностей, когда реально, без фреймворков - я не могу представить когда больше пяти может понадобится, если писать руками на чистом CSS. Плюс ещё дикая тормознутость, хуже чем у React/Vue/Angular, на которых у тебя в райнтайме огромное количество JS выполняется в реальном времени, по итогу если открыто куча вкладок и тут вкладка с Flutter прилетает - то браузер тупо падает, потому что привет 20% загрузки CPU, да-да, однопоток, мы всё ещё едем на нём. Я уже не говорю про тормознутость всего этого флаттеровского фронтедерского счастья на мобиле, где открыл на чуть не актуальном устройстве и ждёшь пока загрузится, "зато прогрессивный мультиплатформенный движок". Мы имеем дико тормознутый интернет в 2025-ом из-за как раз таки всей этой среды. У обычного пользователя на машине доступно не 16Gb RAM, а 50Mb, потому что уже сто вкладок открыто, но нам же надо проект делать, некогда на нативе пилить, да ещё и зная как у нас в стране обычно эксплуатируют Flutter и для чего, потом слышать пафос от разработчиков использующих Flutter это просто нелепо. Огромный мульти-парадигменный фреймворк, который сложен в работе и архитектуре, потом пишешь статьи с базовыми вещами, которые пригодны для 90% пользователей LLM, приходит флаттерщик (уже просто преследует из ветки комментариев в ветку комментариев) и начинается: "вот я только на клоде писать могу, всё остальное дрянь, контексту мало". Нет это вы особенный, это не мы все особенные. Для ванильного JS контекста надо на порядок меньше при работе с любой LLM. Переписывать что-то конкретно под Flutter я не буду, это нишевый фреймворк, для большинства, как концепт и инструмент - непригодный.
Вы читать умеете? Возьмите список топ-20 моделей по популярности, все будут в этом списке. Мы в 2025-ом, добро пожаловать, уже даже опенсорсные модели качественно генерируют код. Вы со своим Flutter носитесь, как будто весь мир вокруг Flutter вращается. Ну с Flutter своя специфика, его, по большому счёту, только модели с большим контекстным окном могут хорошо переварить. Кроме вас на сайте аудитории больше нет? 90% читателей используют более распространённые языки и поэтому для них сгодятся самые базовые модели, тут надо понимать, что это вы "уникум", а не "большинство не право". Flutter это довольно редкий фреймворк, пусть и локально популярный у определенной части аудитории Хабра, а глобально - с мизерной аудиторией. Адаптировать свои комментарии под "клуб любителей Flutter" ради вашего одобрения и ещё пяти пользователей, как-то неинтересно.
У вас какие-то странные вопросы. Я вам только что ответил, что использую все хоть сколько-нибудь популярные LLM одинаково, так как при правильном подходе, подавляющее большинство современных LLM выдаёт хороший результат. Из популярных LLM мне не довелось попробовать только Grok, потому что он требует премиум-аккаунта на Twitter. В 2025 уже особо разницы между хорошими LLM нет, если вы конечно умеете ими правильно пользоваться. Если вам лень разгребать контекст, ну делегируйте вопрос Claude, кто мешает-то? Подавляющее большинство читателей этого сайта использует базовые модели, а вы себя ведёте, как будто весь сайт только для вас существует.
Вам полный список привести? Все популярные периодически пробую в работе.
Если ты хорошо язык знаешь (и умеешь с LLM работать), то вникать особо не нужно, просто смотришь как за тебя на экране проект генерируется, в редких случаях поправляешь.
Генерирует, но не редактирует, тут буквально недавно человек писал, что все LLM сыпятся на базовом редактировании SVG. Аналогично CSS - сгенерировать не так уж сложно, теперь попробуйте заставить LLM хотя бы из одного блока перенести меню с несколькими уровнями вложенностями в другой, так что бы верстка не посыпалась.
Ах да, Dart/Flutter, точно.
LLM в основной своей массе это про то что в первой десятке на этом графике и немного за его пределами. Есть такая вот LLM на два гигабайта [https://huggingface.co/bigcode/starcoder2-3b], которая по отзывам, при умелой работе, очень неплохо пишет код. Понятно, что речь не о стеке Dart/Flutter. Dart, с точки зрения машинного обучения - это язык с малым количеством общедоступной бигдаты. В отличие от JS, Python и прочих популярных языков. Flutter же, в свою очередь, фреймворк (да ещё и довольно молодой), т.е., это сужение специфики. У вас специфичный (с точки зрения общедоступной обучающей выборки) стек, а я говорю о среднестатистическом пользователе LLM, которому надо скрипт для фронтенда на JS написать или на Python алгоритм. Вот пара рейтингов популярности языков, для общей картины.
https://survey.stackoverflow.co/2024/technology
https://www.tiobe.com/tiobe-index/
При использовании моделей с большим контекстным окном - они просто сами за тебя разгребают контекст, при использовании вышеназванных методов - в этом нет нужды, поэтому при подобном подходе можно практически любую модель использовать.
Если изначально работать с LLM по вышеописанным принципам - то нисколько времени не уходит. Просто пишется логика, потом раскрывается на зависимости.
То что вы описали - это не излишняя логика. И разбиение на подзадачи и декомпозиция это не одно и тоже. Например, у вас есть JS который работает со списками и потом куда-нибудь отправляет результат. Вам надо сделать так, что бы выполнялись условия a, b, c, d, e, f. Сначала вы очищаете работу со списками от последующей отправки, так как это не имеет значения для задачи, то есть - декомпозиция, а потом сначала решаете задачу а, потом уже переходите к b и последующим. То есть декомпозируете вы свой код, а разбиваете на подзадачи промпт. Насколько я помню из диалогов с вами, вы работает с Rust, я с ним дело не имел, поэтому комментировать работу с Rust - не буду. Речь, скорее, об универсальных принципах, которые плюс-минус подходят для любой задачи.
Ну вот, вы и поняли суть LLM. Это просто как продвинутые подсказки в IDE, ну или, попросту, следующее поколение поисковых систем.
простыми словами, код в запросе к LLM должен быть максимально очищен, промпт максимально продуман, точен и максимально наполнен необходимой информацией; простое правило: чем проще код и чем лучше промпт - тем качественнее генерация
Ну не скажите. На JS отлично с нуля пишет, если пропмт хороший. Очень сильно зависит от стека и задачи. JS в интернете жёван-пережёван > тонны бигдаты > огромная база знаний > качественная генерация. Редкий язык, специфическая задача, специфическое окружение - и всё - приплыли, гугли, пиши вручную.
LLM пока что не умеют в сложный вектор, и тем более, плохо работают с программным обращением к вектору. Вектор это пока что самая недоступная для LLM сфера информации. Даже на примере CSS, который по сути, текстовый векторный редактор - это хорошо видно, сложную архитектуру CSS даже самая продвинутая LLM не может написать. Мобильная адаптация - вообще сразу мимо, только самые базовые задачи.
Базовые правила при работе с LLM:
разбиение на подзадачи
декомпозиция
минимизация контекста (из базы данных данных удаляем все значения, кроме нескольких, удаляем все лишние зависимости, и прочее)
как вы правильно сказали, кормим LLM полный стек, ещё желательно полностью скормить ей архитектуру проекта, насколько это возможно (если вы работаете с уже имеющейся кодовой базой)
кормить LLM надо ровно-ровно, байт-в-байт столько информации, сколько нужно, я бы сказал, это буквально спорт; при правильном подходе качество выдачи на несколько порядков улучшается
не стоит ожидать что LLM будет хорошо работать по задаче по которой у LLM малая база данных (редкая сборка linux, например) - будет чисто угадывание с галлюцинациями разного качества и разной степени пригодности
чем популярнее язык и чем больше по нему общедоступной биг-даты, тем лучше работает LLM; как пример - Javascript практически идеально (на любой сложности задачи, лишь бы контекстного окна и окна выдачи хватало) генерирует почти любая современная LLM; у JS всегда идентичное окружение (стандарт W3, то есть браузер), и у LLM нет возможности ошибиться, только в очень специфичных случаях (работа из JS с псевдоклассами, что по стандарту невозможно и реализуется только через хаки, это единственное, где LLM тупят)
на специфическом окружении, и редкой задаче - считайте, что LLM для работы непригодны, лучше сразу гуглите
никогда, ни при каких условиях, не кормите LLM излишнюю логику, только необходимый для понимаю моделью скелет; лишняя логика усложняет для LLM прохождение по лабиринту базы знаний, дольше генерации, меньше шансов на успешную генерацию, т.е., принципиально важный момент, абсолютно критический в практической работе
CUDA на AMD уже давно работает. Там просто возни много с настройкой. Тут даже на Хабре несколько статей было на эту тему.
Можно, но сложно.