Comments 182
Я хочу полноценный экспириенс от А до Я — хочу создать приложение только промптами.
Сами же написали, что это не правильно, но решили продолжить кушать кактус. Хотя иначе бы не получилось такой подробной статьи))
все косяки, что были в приложении, — из-за плохо прописанных требований.
Тут бинго. Да. Чтобы написать все как хочется надо 1) очень хорошо понимать что хотим получить, 2) очень хорошо это описать словами, 3) ещё очень желательно предварительно разделить это на реально небольшие задачи - буквально как бы вы делали это для джуна который первый день у вас работает.
Я, по факту, прораб LLM-модели.
Скорее вы теперь архитектор и аналитик. И у вас есть поддержка десятка джунов которые только и ждут вашего приказа. Ну собственно вы к этому и пришли.
Мне очень помогло:
Заранее описывать стэк, вплоть до версий и желательных библиотек. Чтобы потом, например, не любиться с ssr на ровном месте.
Описывать правила, по которым пишется код. То, что обычно с коллегами обсуждается только голосом, пришлось написать текстом. Заняло прилично времени. Этакий конфиг литера на человеческом получился. Даже правила как мы называем переменные и некоторые устоявшиеся подходы - все пришлось прописать. Кстати часть конфига линтера я туда тоже добавил.
Делать кусочками. Сделали скелет - ок. Теперь в нем работаем над небольшим компонентом или над отдельной страницей. На мне - больше аналитики и архитектуры. Но в итоге вышло именно то, о чем вы и написали - это не "вайбкодинг" где все за меня делает ИИ, а просто использование более быстро печатающего инструмента для набора кода.
За статью респект. Я бы сдох раньше, чем получили бы такое решение))
вот мне модель показала скрипт как сейвить из <div></div> в картинку и его код либо с ошибкой либо кладёт браузер. я писал движок, чтобы открывать формат ttf и из таблицы SVG закидывать в растр глифы, чтобы их сопаставлять и рисовать запрашиваемый глиф, так ИИ не очень то и помог, потомучто ясен пень движок этот можно и не делать в системе же все настроено, но суть ведь открыть файл и распарсить по его принципам, в итоге ИИ подсказал только как стилями пользоваться и это при том, что всё равно пришлось стили изучать и по итогу пришлось читать документацию на сайте Майкрософт по таблице SVG, а потом всё это тестировать
LLM пока что не умеют в сложный вектор, и тем более, плохо работают с программным обращением к вектору. Вектор это пока что самая недоступная для LLM сфера информации. Даже на примере CSS, который по сути, текстовый векторный редактор - это хорошо видно, сложную архитектуру CSS даже самая продвинутая LLM не может написать. Мобильная адаптация - вообще сразу мимо, только самые базовые задачи.
Claude 3.7 с удовольствием генерирует шикарные svg-графики и карточки.
так то что про ИИ извините тот файл весит, 20 мегабайт он не помещается в промпт, поэтому и пришлось изучать стили подыскивать как считать, так то он подскажет просто данные могут весить не 1 кб, по уточнению например + в наивном подходе там группы глифов в отдельных файлах от 2 до не знаю количества, при этом я на сайте глянул они работают как маски впринципе об этом в стандарте вроде и говорится на сайте Майкрософт
Генерирует, но не редактирует, тут буквально недавно человек писал, что все LLM сыпятся на базовом редактировании SVG. Аналогично CSS - сгенерировать не так уж сложно, теперь попробуйте заставить LLM хотя бы из одного блока перенести меню с несколькими уровнями вложенностями в другой, так что бы верстка не посыпалась.
Для своего игрового движка решаю похожую задачу, рендеринг текста *sdf шейдером при помощи квадов с текстурами из атласа.
Основная задача давно решена, сейчас занимаюсь автоматизацией добавления собственных пиктограмм в атлас. Общая идея: собственный файл шрифта в inkscape/svg → конвертация в ttf FontForge → генерация в общий атлас со шрифтами, используемыми в игре.
pecheny/fontgen – генератор текстурных атласов и описание шрифта в формате BMFont
pecheny/htext – рантайм для рендеринга (ну не самого рендеринга, а генерации меша с UV).
Вдруг, найдете для себя что-то полезным.
вот вы назвали основные моменты, я просто с нуля написал или правильнее сказать собрал текстовый шрифт по канону ttf, и чутка растрового шика аля аутлайн типо под sdf, ну кароче вытащил наверх и проверил на 5 шрифтх (китайский, индийский, корейский, русский, английский) теперь вот добавилось емодзи(тут пока с артефактами так как некоторые path смешиваются хотя по отдельности емодзики рисуются как надо)(на самой верхушке мне видится это какой-то скрипт должен определять локализацию чтобы в одном месте указывать шрифт и чтобы 1 запуском генерировать нужный атлас), кароче шрифт как оказалось интересно (видео обзор возможностей (https://www.youtube.com/watch?v=SO83KQuuZvg) )
спасибо я с этого начинал аналог бмфонта у меня на фряхе и линуксе, и с имейджмежиком баловался
на будущее поиграйтесь с гимпом там можно понять некоторые процессинги
edge, normal-map(может генерить), блюр по гаусу (что-то ближайшее к сдф), мозайка, собель да там почти всё что надо есть
суть шрифта не далеко ушла от шейдеров просто всё это содержится в файле ттф, может вас это заинтересует, всё таки прикольно когда шрифт без зависимостей рисуется
поидее вы можете кинуть шрифт в SVG таблицу на каждый язык по своей таблице, ну и там просто читать из таблицы, а отступы правда надо будет посмотреть в доке на ттф где они храняться
Скрытый текст
./a.out
1
65536 16 256 4 0
COLR 461536
CPAL 11048
GSUB 34748
OS/2 460
SVG 4817344
cmap 1976
glyf 1546632
head 404
hhea 332
hmtx 143240
loca 302360
maxp 268
name 556
post 300
vhea 368
vmtx 63652
SVGv 0
SVGDocListOffset 10
SVGvReserved 0
NumEntries 684
так выглядит чтение на свг, ну или растром обойтись 12 и 4 формат вон работает с китайским, правда не все шрифты, но пока найти можно
соотв атлас конфигурируется стилем css ну и там надо просто подумать как правильно кинуть с отступами атлас в растр, потомучто css классно комплектует квадратики, кернингом я пока не пользуюсь, но после изучения ttf понял как справится без кернинга просто отступами по иксу и игрику
Базовые правила при работе с LLM:
разбиение на подзадачи
декомпозиция
минимизация контекста (из базы данных данных удаляем все значения, кроме нескольких, удаляем все лишние зависимости, и прочее)
как вы правильно сказали, кормим LLM полный стек, ещё желательно полностью скормить ей архитектуру проекта, насколько это возможно (если вы работаете с уже имеющейся кодовой базой)
кормить LLM надо ровно-ровно, байт-в-байт столько информации, сколько нужно, я бы сказал, это буквально спорт; при правильном подходе качество выдачи на несколько порядков улучшается
не стоит ожидать что LLM будет хорошо работать по задаче по которой у LLM малая база данных (редкая сборка linux, например) - будет чисто угадывание с галлюцинациями разного качества и разной степени пригодности
чем популярнее язык и чем больше по нему общедоступной биг-даты, тем лучше работает LLM; как пример - Javascript практически идеально (на любой сложности задачи, лишь бы контекстного окна и окна выдачи хватало) генерирует почти любая современная LLM; у JS всегда идентичное окружение (стандарт W3, то есть браузер), и у LLM нет возможности ошибиться, только в очень специфичных случаях (работа из JS с псевдоклассами, что по стандарту невозможно и реализуется только через хаки, это единственное, где LLM тупят)
на специфическом окружении, и редкой задаче - считайте, что LLM для работы непригодны, лучше сразу гуглите
никогда, ни при каких условиях, не кормите LLM излишнюю логику, только необходимый для понимаю моделью скелет; лишняя логика усложняет для LLM прохождение по лабиринту базы знаний, дольше генерации, меньше шансов на успешную генерацию, т.е., принципиально важный момент, абсолютно критический в практической работе
простыми словами, код в запросе к LLM должен быть максимально очищен, промпт максимально продуман, точен и максимально наполнен необходимой информацией; простое правило: чем проще код и чем лучше промпт - тем качественнее генерация
Базовые правила при работе с LLM:
То есть в сухом остатке приходится делать всё то же самое, как будто вы лид и режете таск для толпы практикантов. А потом ещё после этих практикантов проверяете, подчищаете, переписываете и отдаёте на тестирование, которое выполняется опять же силами другого лида с практикантами.
разбиение на подзадачи
декомпозиция
Это одно и тоже.
никогда, ни при каких условиях, не кормите LLM излишнюю логику, только необходимый для понимаю моделью скелет; лишняя логика усложняет для LLM прохождение по лабиринту базы знаний, дольше генерации, меньше шансов на успешную генерацию, т. е., принципиально важный момент, абсолютно критический в практической работе
Больше похоже на устаревшую догму времен моделей с малыми окнами, чем на универсально применимый принцип для современных LLM типа Claude. Это отличный способ гарантированно получить код, который никогда, ни при каких условиях не впишется в остальной проект.
Предоставление файлов проекта, даже не напрямую связанных с текущей задачей, дает LLM информацию о стиле, паттернах, архитектуре, соглашениях. Это позволяет генерировать код, который лучше интегрируется в проект и требует меньше доработки. Для сложных задач или рефакторинга больший релевантный контекст часто дает лучший результат.
Главное тут — практика. Через месяц‑два реальной работы любой адекватный человек уже имеет свой, проверенный на своих задачах и стеке, список того, что реально работает.
То что вы описали - это не излишняя логика. И разбиение на подзадачи и декомпозиция это не одно и тоже. Например, у вас есть JS который работает со списками и потом куда-нибудь отправляет результат. Вам надо сделать так, что бы выполнялись условия a, b, c, d, e, f. Сначала вы очищаете работу со списками от последующей отправки, так как это не имеет значения для задачи, то есть - декомпозиция, а потом сначала решаете задачу а, потом уже переходите к b и последующим. То есть декомпозируете вы свой код, а разбиваете на подзадачи промпт. Насколько я помню из диалогов с вами, вы работает с Rust, я с ним дело не имел, поэтому комментировать работу с Rust - не буду. Речь, скорее, об универсальных принципах, которые плюс-минус подходят для любой задачи.
Стало гораздо... запутаннее. Если я правильно вас понял:
Декомпозиция = Упрощаешь то, что даешь LLM (код).
Разбиение на подзадачи = Упрощаешь то, что просишь LLM сделать (промпт).
Вы называет старую добрую декомпозицию задач «разбиением на подзадачи». А понятие «декомпозиция» (разбиение сложного на простое) применяете к коду в смысле очистки/упрощения/изоляции (ручная предобработка входных данных).
То есть, я сначала должен вручную «декомпозировать» (читай: почистить и упростить) код, чтобы потом скормить его LLM и попросить решить «разбитую на подзадачи» проблему?
Интересно, сколько часов/дней обычно уходит на эту увлекательную «декомпозицию кода»? Кажется, это отличный способ потратить время, которое LLM должна была сэкономить.
Если изначально работать с LLM по вышеописанным принципам - то нисколько времени не уходит. Просто пишется логика, потом раскрывается на зависимости.
Интересно узнать какие модели вы используете?
При использовании моделей с большим контекстным окном - они просто сами за тебя разгребают контекст, при использовании вышеназванных методов - в этом нет нужды, поэтому при подобном подходе можно практически любую модель использовать.
Какие конкретные модели вы используете на практике?
Вам полный список привести? Все популярные периодически пробую в работе.
Так и не понял, какая из «всех популярных» — ваша любимая. Или любите всех одинаково?
У вас какие-то странные вопросы. Я вам только что ответил, что использую все хоть сколько-нибудь популярные LLM одинаково, так как при правильном подходе, подавляющее большинство современных LLM выдаёт хороший результат. Из популярных LLM мне не довелось попробовать только Grok, потому что он требует премиум-аккаунта на Twitter. В 2025 уже особо разницы между хорошими LLM нет, если вы конечно умеете ими правильно пользоваться. Если вам лень разгребать контекст, ну делегируйте вопрос Claude, кто мешает-то? Подавляющее большинство читателей этого сайта использует базовые модели, а вы себя ведёте, как будто весь сайт только для вас существует.
Сначала вы даете «универсальные принципы», потом оказывается, что все модели «одинаковы», потом — что мой опыт с Claude — это «лень», а мои вопросы — «странные», и в конце — бездоказательное утверждение про «большинство читателей».
Вы так и не назвали ни одной модели, на которой строятся ваши «универсальные принципы». Если подход так хорош, что работает «практически с любой моделью», то назвать те, с которыми вы реально работаете, не должно быть проблемой.
Вы читать умеете? Возьмите список топ-20 моделей по популярности, все будут в этом списке. Мы в 2025-ом, добро пожаловать, уже даже опенсорсные модели качественно генерируют код. Вы со своим Flutter носитесь, как будто весь мир вокруг Flutter вращается. Ну с Flutter своя специфика, его, по большому счёту, только модели с большим контекстным окном могут хорошо переварить. Кроме вас на сайте аудитории больше нет? 90% читателей используют более распространённые языки и поэтому для них сгодятся самые базовые модели, тут надо понимать, что это вы "уникум", а не "большинство не право". Flutter это довольно редкий фреймворк, пусть и локально популярный у определенной части аудитории Хабра, а глобально - с мизерной аудиторией. Адаптировать свои комментарии под "клуб любителей Flutter" ради вашего одобрения и ещё пяти пользователей, как-то неинтересно.
Спасибо, что объяснили мне, «уникуму» с «редким Flutter», как всё устроено для «90% читателей» с «базовыми моделями» (откуда, кстати, дровишки про эти «90%» и «базовые»?).
Ваши «универсальные принципы» так легко ломаются, столкнувшись с практической реальностью (например, моей): внезапно оказалось, что Flutter «специфичный», мой опыт можно игнорировать, а назвать хоть один инструмент, на котором строятся ваши догмы, вы так и не смогли.
Ваш подход, похоже, существует только в теории.
У меня изначально не очень хорошее отношение к Flutter, потому что несмотря на крутость самой технологии, так сложилось, что в девяти случаях из десяти Flutter применяют там где не надо. По идее Flutter - это про скорость развёртывания и прототипирования, в итоге все сводится к экономии, когда одним разработчиком целую команду заменяют, по итогу мы получаем ужасно тормознутые приложения, я уже не говорю про фронтенд. Дайте посмотреть на ваш уровень вложенности блоков, я уверен, там штук двадцать вложенностей, когда реально, без фреймворков - я не могу представить когда больше пяти может понадобится, если писать руками на чистом CSS. Плюс ещё дикая тормознутость, хуже чем у React/Vue/Angular, на которых у тебя в райнтайме огромное количество JS выполняется в реальном времени, по итогу если открыто куча вкладок и тут вкладка с Flutter прилетает - то браузер тупо падает, потому что привет 20% загрузки CPU, да-да, однопоток, мы всё ещё едем на нём. Я уже не говорю про тормознутость всего этого флаттеровского фронтедерского счастья на мобиле, где открыл на чуть не актуальном устройстве и ждёшь пока загрузится, "зато прогрессивный мультиплатформенный движок". Мы имеем дико тормознутый интернет в 2025-ом из-за как раз таки всей этой среды. У обычного пользователя на машине доступно не 16Gb RAM, а 50Mb, потому что уже сто вкладок открыто, но нам же надо проект делать, некогда на нативе пилить, да ещё и зная как у нас в стране обычно эксплуатируют Flutter и для чего, потом слышать пафос от разработчиков использующих Flutter это просто нелепо. Огромный мульти-парадигменный фреймворк, который сложен в работе и архитектуре, потом пишешь статьи с базовыми вещами, которые пригодны для 90% пользователей LLM, приходит флаттерщик (уже просто преследует из ветки комментариев в ветку комментариев) и начинается: "вот я только на клоде писать могу, всё остальное дрянь, контексту мало". Нет это вы особенный, это не мы все особенные. Для ванильного JS контекста надо на порядок меньше при работе с любой LLM. Переписывать что-то конкретно под Flutter я не буду, это нишевый фреймворк, для большинства, как концепт и инструмент - непригодный.
Нет плохих технологий — есть неправильное их применение и узкое мышление. Ваш поток сознания про Flutter — яркий пример второго.
Реальное применение Flutter — это кросс‑платформа для mobile (iOS, Android) и desktop (Windows, macOS, Linux). Flutter в web редко используется.
Похоже, вы оторваны не только от реальных сценариев использования Flutter, но и от реальности бизнеса с его нуждами и болями, которая и определяет ценность таких инструментов, а не ваши теоретические рассуждения.
И нет, я не «преследую» вас (это ваши фантазии). Я указываю на ваши повторяющиеся заблуждения и догмы, которые вы упорно тиражируете из ветки в ветку. Когда видишь повторяющуюся потерю связи с реальностью, сложно пройти мимо.
Поток сознания это ваши мысли касательно состояния сферы LLM. Вы опираясь на использование специфического инструмента на пяти LLM (исходя из ваших комментариев), делаете выводы о состоянии всей сферы и ещё пытаетесь на меня своё мнение экстраполировать (в чём ваша ошибка). Реальные сценарии использования Flutter? Нужен "Вася", который будет тащить на себе работу, которую по идее должен целый отдел делать, то что оно всё лагает и тормозит (а то, что приложения и фронтенд на Flutter лагают и тормозят известно всем, ну если есть желание - можно поискать замеры, но в целом то, что любая кроссплатформа лагает на любом функционале отличном от базового, это аксиома, тем более Flutter, у которого мультиплатформенность в абсолют возведена) - всем плевать. Очень ещё смешно, как вы к толпе на Хабре апеллируете, тут людей понимающих состояние сферы LLM на 2025-ый - два с половиной человека, включая меня, просто лишний раз доказываете свою абсолютную некомпетентность в вопросе ещё и прибегаете почти в любую ветку где я отписался касательно LLM, доказывать своё мнение. Смешно наблюдать.
всё что я написал на 100% работает
любая кроссплатформа лагает на любом функционале отличном от базового, это аксиома
тут людей понимающих состояние сферы LLM на 2025-ый - два с половиной человека, включая меня
Эх, мне бы такую непоколебимую уверенность в собственной правоте. Эффект Даннинга-Крюгера во всей красе.
У вас эффект отсутствия английского (уже лет сто как международный и "технологический" язык) и полное отсутствие понимания того, что происходит в глобальной индустрии. А то, что мультиплатформа вся ужасно лагучая - известно любому за пределами Хабра, тут просто из-за системы инвайтов, по классике echo chamber сформировалось, где все друг друга хвалят и "попробуй плохо про мультиплатформу скажи". Зайдите на любой форум и спросите мнение людей насчёт производительности мультиплатформенных решений. Flutter, причём, обладает самой худшей репутацией в плане производительности из всей мультиплатформы. Он годится для MVP и прототипирования, для быстрого запуска и валидации рынка, но лагает даже на самом простом функционале при разрастании логики. Топить за Flutter, как за мультиплатформу - окей, можно крайне быстро продукт разработать и запустить. Топить за Flutter, как за производительное техническое решение - не смешите. Оставайтесь в своём echo chamber, пожалуй, у вас от моих попыток вытащить вас из вашей зоны комфорта - нервы шалят.
Спасибо, что пытаетесь «вытащить нас» из нашего «echo chamber» в вашу светлую альтернативную реальность, где только вы и еще полтора человека «понимают» LLM, а все остальные «не знают английского», задают «странные вопросы» и сидят с «шалящими нервами» или «преследуют» вас.
Жаль только, что эта ваша альтернативная реальность не имеет ничего общего с действительностью, где вы так и не смогли ни назвать свои инструменты, ни понять основы LLM.
Удачи вам в вашем мире.
Мания величия («два с половиной человека, включая меня») цветет пышным цветом. Возможно, ваш дедовский метод работы с LLM как раз и подходит только для этих «двух с половиной человек», включая вас.
Вы назвали себя одним из немногих «понимающих LLM»? Серьезно? Ваше тупое упорство в отрицании вероятностной сути LLM — за гранью технической безграмотности. Либо вы неспособны понять элементарные вещи, либо сознательно несёте бред.
Прежде чем строить «универсальные принципы», разберитесь хотя бы с азбукой того, как работает инструмент.
Так не мог молчать, что аж два комментария написал... Ну пиши-пиши, Достоевский, если думаешь, что их читать кто-то будет.
Если вдруг решишь ответить по делу, начни с Vaswani et al. (2017) — там про softmax и вероятности, которые ты так упорно игнорируешь.
А пока — удачи в мире, где LLM «не ошибаются» и Flutter «тормозит интернет».
Поменьше пафоса, Достоевский, у вас флаттер пердит в продакшене.
https://blog.theodo.com/2023/09/ios-rendering-performance/
The bigger concern is around the large deviation of times that Flutter has. While SwiftUI & React Native have relatively similar standard deviation (24ms and 30ms on average respectively), Flutter has an average standard deviation 530ms across the different tests, which is significantly higher. This effectively means that our tests have found that Flutter apps can exhibit more inconsistency when it comes to rendering a large number of items.
530 миллисекунд задержка против 30 у реакт нэйтив и 24 у свифта, (реакт, кстати, я думал хуже, не зря на флаттер наговаривают).
Дальше будем прятать голову в песок и отрицать реальность?
Своих индусов читай сам.
На всякий случай приложу картинку, для тех, у кого когнитивные проблемы с восприятием реальности.
Ну или вот ещё пример, прямо с сабреддита по флаттеру (заранее извиняюсь за ссылку на помойку называемую реддит, открывайте осторожнее, что бы не запачкаться, но IT сообщества там лучшие в интернете). Типичнейший пример флаттера in real life, а не на рекламных памфлетах. Давеча тут популярное у эппловодов приложение перевели со свифта на флаттер, и все (заметь-те! разработчики, которые пишут на флаттер! не кто-то там!) обсуждают, как оно сразу лагать стало дико. Nuff Said. Enjoy your multiplatform.
https://www.reddit.com/r/FlutterDev/comments/186mbxy/9to5mac_has_rebuilt_their_app_using_flutter/
Вот видос с лагами, что бы далеко не ходить. А всё плавно-идеально работало. Привет флаттер на большом количестве элементов.
Ещё будут вопросы почему чистый фронтенд лучше любого фреймворка? Или нет? Я могу подобных сравнений по производительности сотни на любой стек принести, устанете минусовать.
Ну и контрольный, давайте у свифтеров мнение спросим касательно флаттера, ну так, чисто посмеяться.
https://www.reddit.com/r/swift/comments/1i8os04/title_swift_vs_flutter_which_should_i_choose_for/
Ты прям как LLM с окном в 512 токенов, которую забыли дообучить: теряешь контекст, уходишь в сторону, бредишь.
Flutter — просто инструмент, у него есть плюсы и минусы. И коню понятно, что любой натив быстрее. Не понятно, как это связано с твоими «безошибочными LLM» и «универсальными принципами»? Flutter — не тема этого треда, и ты это знаешь. Набег на Flutter — это твой белый флаг.
Прежде чем писать свой «свод правил», разберись в основах. Ты ошибается в базовом понимании архитектуры LLM.
«Attention Is All You Need» (Vaswani et al., 2017) — это работа, которая представила архитектуру трансформеров, ставшую основой для всех современных LLM (GPT, BERT, Claude, LLaMA и других). Она четко показывает, что трансформеры (основа всех LLM) генерируют токены на основе вероятностного распределения через softmax (раздел 3.2). Даже при «идеальном» контексте вероятность «неправильного» токена ненулевая, что делает ошибки неизбежными.
Вот тебе реальность: LLM — это трансформеры, которые выбирают токены по вероятностям. Ошибки — не «плохой промпт», а их природа. «Безошибочные LLM» — это твоя галлюцинация, и она будет посильнее, чем любой лаг во Flutter.
В рамках стандарта W3 (HTML/CSS/JS) LLM имеют настолько хорошую базу, так как бигдаты очень много, а окружение статично (стандарт W3 - это браузер), что в рамках стандарта W3 даже самые базовые модели не ошибаются при наличие достаточного контекстного окна. Похожая ситуация для всех популярных языков и более-менее "типичного" окружения. Т.е., когда у тебя шанс на ошибку менее 
на вероятностной природе, природа перестаёт быть вероятностной. Деление на ноль возможно или нет? Если значение стремится к нулю - является ли оно нулевым или нет? Ну ты понял, короче.
Диагноз: Хроническая псевдоматематическая галлюцинация, осложнённая острой уклончивостью.
Лечение: читай Vaswani, и сложи 2+2.
Прогноз: будешь таскать телегу навоза по тредам, пока не научишься вникать, делать выводы и отвечать по делу.
Я уже все сказал, что хотел, на твои минуса вообще плевать. Иди собери ещё триста миллионов лагающих приложений на флаттер и получи премию от начальства за то, что выполняешь работу целого отдела разработки и плюёшь на головы пользователям. Индусов не читаю принципиально. Понимаешь, ты думаешь, что диалог идёт с тобой, потому что у тебя ЧСВ. Хабр - это сайт, который читают сотни тысяч людей. Мои комменты прочтут, контекст уже разжёван донельзя, на остальное вообще плевать. Я изначально на Хабре не сидел и не собираюсь, просто когда всплыла тема LLM и появилось с несколько десятков не очень умных людей, которые постят не разбираясь в тематике - это потребовало некоей расстановки точек. Соответственно, что? Пост резонансный, в библиотеке Хабра остался, а я его именно как библиотеку и воспринимаю, захожу почитать какие базы данных использовать (ну то есть гуглю по хабру и иду в комментарии), какие фреймворки на бэкенде использовать (фреймворки на фронтенде это зло и пятое колесо изначально), то есть люди просто зайдут, им алгоритмы Хабра предложат резонансный пост и они прочтут всю требующуюся информацию, твои минуса тут даже в тему, потому что это рофл как ты и ещё с десяток подобных слюной брызжете на опенсорсные LLM. Ты типичный фреймворщик-плодитель-bloatware. С тобой разговор считаю бесполезным изначально. Flutter индустрия - паразит на теле IT комьюнити.
ещё триста миллионов лагающих приложений на флаттер
...наличие (или отсутствие) которых никак не коррелирует с вашей точкой зрения об LLM.
Индусов не читаю принципиально.
Документацию от Microsoft тоже? Там, технически, мог лично Наделла руку приложить.
Коррелирует крайне точно. Если ты отстаиваешь позицию, что Flutter годится для чего-то кроме прототипирования и быстрого запуска в корпоративной среде, а у Flutter, на секундочку - средняя задержка рендера элементов от полусекунды до полутра секунд, то уровень твоей компетенции - околонулевой. Как и понимание природы LLM генерации.
Насколько я помню из диалогов с вами, вы работает с Rust
Нет, не Rust. Я работаю с Dart/Flutter (фронтенд/мобильная разработка).
Ах да, Dart/Flutter, точно.
LLM в основной своей массе это про то что в первой десятке на этом графике и немного за его пределами. Есть такая вот LLM на два гигабайта [https://huggingface.co/bigcode/starcoder2-3b], которая по отзывам, при умелой работе, очень неплохо пишет код. Понятно, что речь не о стеке Dart/Flutter. Dart, с точки зрения машинного обучения - это язык с малым количеством общедоступной бигдаты. В отличие от JS, Python и прочих популярных языков. Flutter же, в свою очередь, фреймворк (да ещё и довольно молодой), т.е., это сужение специфики. У вас специфичный (с точки зрения общедоступной обучающей выборки) стек, а я говорю о среднестатистическом пользователе LLM, которому надо скрипт для фронтенда на JS написать или на Python алгоритм. Вот пара рейтингов популярности языков, для общей картины.
Только вот есть проблема - легаси. Я уже много кода сгенерировал на питоне и ни разу llm не использовала моржовый оператор (:=) хотя он еще в 3.8 появился.
Вангую, что в будущем это станет проблемой - llm будут игнорировать любые новые фичи при генерации кода, а т.к. большая часть кода для обучения будет сгенерирована теми же llm это будет очень сложно исправить, проще будет создать новый язык или его версию :)
Только вот есть проблема — легаси.
Модель (в моем случае Claude) адаптируется к новому синтаксису из контекста, даже если ее обучение отстает.
Пробовали давать ей «моржовый» контекст (примеры кода с :=)?
Про := она знает, 6 лет фиче, понятно что если прямо попросить то найдет куда вставить, но кто же будет так делать? Прописывать в промпт синтаксис?
Речь о том, чтобы закинуть в контекстное окно файлы проекта или примеры кода, где этот «моржовый» оператор УЖЕ используется. Генерация ведь обычно идет не в вакууме, а в контексте конкретного проекта. Модель видит существующий стиль/синтаксис и адаптируется, начинает его применять сама, без явных указаний в промпте.
Подождите, 6 лет фиче. И LLM «не в курсе»? Это странно.
если прямо попросить то найдет куда вставить
Господа гусары, МОЛЧАТЬ!!!
За всё время ни разу не использовал моржовый оператор. Оно и при анонсе фича была спорной и вызвала заметные дискуссии, так сказать. Есть ощущение, что в массе своей этот оператор не приняли.
Оно и лучше, что ИИ его не использует.
В JS наоборот надо по рукам бить, что бы слишком новые стандарты не использовал, все LLM очень любят grid, хотя полно ещё легаси устройств на руках у людей, где grid не поддерживается, на фронтенде для массового пользователя это принципиально.
Javascript практически идеально (на любой сложности задачи, лишь бы контекстного окна и окна выдачи хватало) генерирует почти любая современная LLM; у JS всегда идентичное окружение (стандарт W3, то есть браузер), и у LLM нет возможности ошибиться, только в очень специфичных случаях
Зачем вы повторяете это враньё из комментария в комментарий? Я ранее приводила опровергающий пример.
Ботовод, "дообучи" свою сетку "LLM-евангелиста".
То есть то, что человек может просто обобщать собственный опыт (т.е. это не враньё и не ботоводство, а просто заблуждение, которых у каждого из нас сотни в день происходит) - не вариант?
В том‑то и проблема, что этот комментатор продолжает озвучивать свой опыт как абсолютную истину, несмотря на приведенные контрпримеры. «Практически идеально», «у LLM [вероятностного инструмента] нет возможности ошибиться» — wat?
Вы абсолютно правы, это уже за гранью простого заблуждения. Он упорно игнорирует вероятностную природу LLM, выдавая желаемое («нет возможности ошибиться») за действительное. Похоже на полный отрыв от реальности разработки, где ошибки LLM — норма, а не исключение. А теперь еще этот догматичный свод «универсальных правил» от человека, который так упорно игнорирует реальность...
"Вероятностную природу LLM" - смешное утверждение. Каким образом она вероятностная? Базовые принципы информатики - слышал? Что такое абстракция понимаем? Любой язык = усложненная таблица умножения, любая абстракция = просто ещё один уровень усложнения. Вероятностная она только потому, что запихиваете огромный контекст в узкое контекстное окно, по итогу LLM не справляется и начинает галлюционировать, а не потому что технология изначально "вероятностная". Изучите структуру LLM - она одинаковая плюс-минус у всех, и все LLM построены на плюс-минус одних и тех же библиотеках. Плюс ещё, если речь о Flutter - ну конечно, для вас она "вероятностная", потому что там под капотом мультипарадигменный движок, который требует кучу контекста в работе, по итогу кроме Claude ничего не справляется, и даже он еле-еле тащит всю эту кучу. Вы когда пишите: "мне эти принципы не подходят" - всегда язык уточняйте, потому что если речь о мультиплатформе, то это вы особенный, а не мы все особенные. На нативе и без фреймворков - всё что я написал на 100% работает. Плюс уровень абстракции - больше контекста - сложнее задача для LLM. У вас уровень абстракции максимальный, потому что фреймворк + мультиплатформа, то есть, простыми словами, вы исключение подтверждающее правило.
Вероятностная она только потому, что
...чисто математически выбирает каждый следующий токен с некоторой вероятностью (а эти вероятности, да, зависят от имеющегося контекста). И чисто статистически в некоторых задачах почти всегда выдаёт правильный ответ, но из-за первого "чисто математически" от этого "почти" избавиться в принципе невозможно, даже на этих "некоторых" задачах.
Если вероятность околонулевая, на уровне ниже единицы на гугол, то термин "вероятностная", по факту, не уместен.
А вот это "околонулевая" нужно отдельно обосновывать. И ещё отдельно обосновывать, почему конкретные встреченные примеры срабатывания этой "околонулевой" вероятности на самом деле не примеры.
Давайте пример неверного срабатывания любой топ-20 LLM старше 2024 года выпуска на чистом стандарте W3 (HTML/CSS/JS), при условии достаточного контекстного окна. Спойлер: их нет. Точнее есть один, обоснованный спецификой стандарта W3, но по стандарту LLM как раз таки правильно все делают, просто это недостаток архитектуры и все используют хаки в работе, это работа из JS с псевдоклассами CSS. Больше их нет. Можете сколько угодно тестировать, ни одна LLM не даст ошибку при наличие достаточного контекста. Причём можно уже в уверенной степени сказать примерно тоже самое о локальных опенсурсных LLM. Т.е., на Хабре пользователи всё ещё прибывают в информационном состоянии пятилетней давности.
Что значит "достаточного контекста"? Точнее, как определить его достаточность, кроме как "скормить этот контекст LLM, задать вопрос и проверить, что ответ имеет смысл"?
Это уже ваши проблемы как вы будете это доказывать. Вам нужно знать параметры контекстного окна модели, и количество текущего используемого контекста. Есть масса способов это сделать. Вы так упорно выдвигаете постулат о "вероятностной природе" LLM, что бремя доказательства тут на вас лежит. Любому, кто хоть более-менее разбирается в вопросе текущего состояния сферы LLM - абсолютно всё и так понятно, я объясняю "прописные истины", если вы с ними не согласны - извольте доказать. Технически это элементарно делается, вопрос желания и усилий.
Я сейчас не выдвигаю никакой постулат. Я сейчас задаю конкретный практический вопрос. Вы утверждаете, что, если современной LLM задать достаточный контекст - она не будет совершать ошибок. Вопрос - какой именно контекст здесь будет достаточным?
Вы утверждаете, что, если современной LLM задать достаточный контекст - она не будет совершать ошибок.
Это вы сами придумали, я такого не утверждал. Значение имеют: база знаний, контекстное окно и ни один другой параметр. Я утверждаю, что в рамках стандарта W3 (так как он изучен вдоль и поперёк, и по нему масса общедоступной высококачественной бигдаты), при достаточной свежести (для гарантии современности библиотек) - ни одна модель из топ-20 коммерческих не может ошибиться, плюс-минус тоже самое можно сказать про опенсурсные модели.
Каким образом она вероятностная?
Javascript практически идеально (на любой сложности задачи, лишь бы контекстного окна и окна выдачи хватало) генерирует почти любая современная LLM
Слишком громкое заявление конечно ))
storage.#client.do(request)Мой любимый пример «помощи» LLM. Так она мне тест на класс с приватными свойствами накидала ))
Скрытый текст
просто использование более быстро печатающего инструмента для набора кода.
А вы задачи для этого инструмента печатаете быстрее, чем итоговый код?
Буквально час назад ставил задачу джуну.
В общем то потратил времени на объяснение ровно столько же, за сколько сделал бы задачу сам минус время на отладку. Время которое ушло бы на отладку будет потрачено на ревью и решение потенциальных косяков реализации.
С джуном я успокаиваю себя тем, что научу его и через 2-3 месяца получу человека который сможет решать подобные задачи самостоятельно. LLM модели в этом аспекте проигрывают.
С другой стороны LLM сделает эту задачу за минуты, а джун потратить часы и дни. Тут LLM явно впереди.
LLM действительно хорошо работают, когда ты точно знаешь что хочешь получить либо совсем не знаешь что тебе нужно и хочешь получить отправную точку в коде от которой можно проводить ресерч, что то вроде «реализуй такую то задачу и опиши с помощью каких инструментов ты ее реализовал и почему», далее спросить «какие еще библиотеки и подходы можно использовать для решения этой задачи.
Не совсем. Я бы сказал так (условно, конечно же):
Самому: 3 часа на всю задачу
Джун: 1 час объяснить, 1 час на ответы на вопросы и решение его проблем, 1 час на ревью. То же самое, но через несколько месяцев у вас будет сильно более самостоятельный юнит, и та же задача займет 15 минут на постановку и 15 на ревью. А ещё через год нужно будет потратить 5 минут на то чтобы прочитать сообщение где он сам говорит что и как собирается сделать и ответить "ок".
БЯМ: 1 час объяснить нормально, 1 минута на результат, 1 час поправить (ака ревью). Вроде экономия, но ни через месяц, ни через три, ни через год оно не станет самостоятельным юнитом. Ну как минимум пока к этому предпосылок не очень видно, хотя тут все меняется каждую неделю.
Цифры все, разумеется, очень условные. И джун не всегда за несколько месяцев становится самостоятельным, и БЯМ иногда надо объяснять так подробно, что часа не хватит - сидишь третий час втолковываешь, сам бы уже сделал, а она тупит и все ломает по кругу.
БЯМ: 1 час объяснить нормально
С матами и проклятиями, потому что оно тупое до ужаса и сильно бесит, что не понимает то, что джун поймет гарантированно.
Что за чушь? Как и большинство программЕРов, впадаете в ошибку: "Я попробовал, ИИ лажает на примере1, примере2. Вывод: через год... лет 10... никогда ИИ не станет самостоятельным разработчиком". На самом деле ента штука весьма быстро совершенствуется. Нет, психологическую причину неприятия я понимаю: сложно признать, что скоро твой профессионализм обесценится и профессия "программист" уйдет в прошлое...
LLM сделает эту задачу за минуты
Но есть нюанс
Скоро надо будет делать спец. ретриты для угоревших в ИИ вайбе. Чем могучее ИИ тем выше требования к нам (парадокс, да) и тем гуще угар.
а я сделал 10к атлас (можно и больше сделать они же в SVG ) всех емодзи "from scratch" они там хранятся в таблице SVG и получился атлас )
для этого я написал еще одну утилу которая считает файл css около 3к строк стиля ) движок емодзи готов без скиа ) теперь емодзями можно рисовать ) в растр я их кинул выделением браузерным потомучто всё остальное либо кладёт DOM либо не тянет расширение ) атлас весит от 8 мегабайт )
В - ВайбВелосипед )
Скрытый текст
ИИ не очень-то уж помог, так подсказал пару моментов как с ним серьезно что-то делать не понимаю
Технология, безусловно, полезная. Но пока только как помощник: автокомплит, поиск ошибок, рефакторинг и решение проблем без stackoverflow конкретно к твоему проекту. А вот что с нуля пишет ИИ - это вообще кошмар.
Ну не скажите. На JS отлично с нуля пишет, если пропмт хороший. Очень сильно зависит от стека и задачи. JS в интернете жёван-пережёван > тонны бигдаты > огромная база знаний > качественная генерация. Редкий язык, специфическая задача, специфическое окружение - и всё - приплыли, гугли, пиши вручную.
С правильной архитектурой? Нужно же понимать, что код нужен не отдельным методом, а в рамках проекта.
Я думаю, что общее правило такое -- если вы можете сами и понять и решить задачу и объяснить ее стажеру со всей внутренней кухней -- вы сможете эту задачу (любую) решить и с помощью ИИ с эффективностью 90-95%...
Есть еще несколько приемчиков, как довести эти 90% до 98-99% (путем нескольких генераций и их кросс-валидации)..
Просто надо отказаться от иллюзии, что хороший и правильный ответ вы получите сразу -- так практически никогда не происходит... или еще иллюзия, что вы сможете решить задачу с помощью ИИ, которую не понимаете...
В итоге сейчас фокус резко смещается на опыт, насмотренность и понимание задачи, а не "механическую работу"... дальше уже идут общие хорошие практики программирования, такие как чистый код и понимание домена, разделение ответственности и прочее...
Вы должны не просто попросить ИИ решить задачу, в заставить ИИ решить задачу корректно и по высоким стандартам и по всем требованиям, без лишнего и четко по инструкции -- т.е. нужно постоянно направлять ИИ в нужном русле, т.е. понимать, ага, нам нужно придти в эту точку, он сейчас движется не в том направлении -- нужно ему сказать, чтобы взял чуть левее или правее... чем-то напоминает управление парусным судном... мы корректируем паруса, а ветер за нас делает все необходимое и мы плывем куда нам требуется...
Еще что лично мне помогает и я за этим строго слежу, чтобы внутри кода был не только код, но и тщательно оформленные комментарии, где ИИ описывает что и зачем он делает, а в начале файла роли и обязанности и связи с другими компонентами системы... кроме того все файлы должны быть чистыми, чтобы не было никаких ошибок и противоречий... т.е. иногда я полностью перегенерирую файлы по 10-20 раз, прежде чем они станут такими, как мне надо.. это довольно монго ручной работы...
Тут еще другой вопрос понимается. Все проекты под NDA и интеллектуальная собственность конторы. ИИ же по сути код отправляет на свои сервера. Вопрос - на сколько это нарушает договор NDA?
Все это напоминает мне ситуацию с математическим доказательством правильности программ.
Теоретически, правильность любой программы можно доказать математически, но сложность такой задачи - не меньше, чем написание самой программы. Собственно, поэтому математические доказательства правильности используются очень редко.
Здесь - то же самое: теоретически, можно описать программу достаточно подробно, чтобы ее по этому описанию написала любая LLM. Только это будет сравнимо по сложности с написанием самой программы.
На родном языке обычно проще писать чем на языке программирования.
С появлением LLM, фактически, отпадает потребность в фреймворках (пока ещё нет, но это вопрос времени), потому что либо ты берёшь React со сложной архитектурой, когда твой код, простейшая, базовая функциональность, идёт через сложную структуру фреймворка, который вращается в рантайме на машине пользователя. При работе с бэкендом, хорошо, это сервер на себе вытягивает. А стандартная ситуация на фронтенде? Пользователь, у которого открыто двести вкладок, и тут прилетает вкладка на очередном навороченном, тяжёловесном фреймворке - и браузер благополучно падает, потому что однопоток и привет 100% CPU load. Я прогнозирую, что фреймворки уйдут в прошлое уже очень скоро, потому что сейчас ты просто делегируешь написание бойлерплейта LLM вместо делегирования функционала фреймворку - и получаешь, по сути, свой фреймворк, только с логикой в сто раз проще и скоростью работы на два-три порядка выше. Заметили возврат на Rust с Go? Вот это одна из первых ласточек. Когда качество архитектуры ценится выше качества бойлерплейта - это уже и есть тенденция созданная LLM. Если ты хорошо разбираешься в тематике LLM, то написание дикого количества бойлерплейта на нативе превращается в элементарную задачу, а что быстрее работает, натив или фреймворк/мультиплатформа? Вот и вся суть.
Фреймворк хорош тем, что вы используете хорошо протестированный код. Там позаботились о безопасности и все проблемы хорошо известны.
Пользователю, у которого всё лагает - от этого не легче. Вообще, фреймворки в основной своей массе появились, потому что крупным корпорациям нужна дешевая рабочая сила, а обучать нативным языкам долго, а потом, когда разработчик их выучит - становится ценным специалистом, и требует много денег. А обучить работе на React на порядок проще, чем работе на JS. Тот же принцип со всеми остальными фронтенд-фреймворками. Они абсолютно ничего не улучшают, и не дают новых возможностей, только лагают, единственный смысл фреймворков это более удобный синтаксис, читай, проще обучать сотрудников. Что даёт нового React (кроме лагов) инфраструктуре HTML/CSS/JS? Ровным счётом ничего, ещё и возможности урезает на корню, особенно в плане построения интерфейсов. Но можно, да, за пять минут собрать шаблонный корпоративный интерфейс на MUI. По факту, просто новое поколение CMS, сменившее Wordpress и ему подобных.
Как русскоязычного специалиста по использованию языковых моделей, прошу ответить. А именно: оценить перспективы следующей модели разработки. Человек ("Заказчик") обращается к команде ИИ-агентов, возглавляемой "ИИ-менеджером проекта", и сообщает о своей потребности в создании ИТ-решения. Агент "ИИ-менеджер проекта" инициирует старт "ИИ-системного аналитика", коий путем пошагового уточнения задачи в ходе диалога с Заказчиком формирует документ требований - с учетом специфики ИИ!. Далее агент "ИИ-менеджер проекта" просит "ИИ-архитектора" исходя из установленных требований, сформировать пригодную архитектуру с выбором языков, фреймворков, и пр. Далее, получив архитектуру - возможно, с привлечением еще "ИИ-агента-критика" для пошагового улучшения, "ИИ-менеджер проекта" запускает стадо "ИИ-программистов" для генерации программных модулей. Получив набор исходных текстов, подключает "ИИ-специалистов по качеству", кои делают инспекции и тестирование модулей и взаимодействуют в ходе отладки с "ИИ-программистами". Затем полученный прототип "ИИ-менеджер проекта" демонстрирует Заказчику. Заказчик ругает одно, просит дополнить другим. Цикл повторяется, вносятся уточнения в требования, затем в архитектуру, затем в программные модули. Наконец, когда Заказчик удовлетворен, "ИИ-менеджер проекта" запускает "ИИ-техписателя", коий пишет качественную, написанную грамотно по-русски и с учетом уровня подготовки Заказчика, документацию. Может даже еще быть "ИИ-девопс", коий сможет развернуть и настроить приложение. Ваше мнение?
Языки программирования - это один из видов формальных языков, которые создаются под задачу и хорошо её решают. Ноты ясно и лаконично описывают инструментальную музыку, математические формулы так же хорошо представляют взаимосвязи между величинами. ЯП же созданы для удобного представления алгоритмов в виде программ и достаточно хорошо, как мне кажется, с этим справляются.
В естественных языках очень много избыточности, неоднозначности, выражения на них несут эмоциональную окраску, а смысл некоторых из выражений сильно зависит от культурного контекста. Из-за этого такие языки очень универсальны и удобны в повседневном общении с их носителями, но проигрывают в выразительности формальным языкам. Там, где нужно тщательно подбирать слова и писать абзацы текста на естественных языках, чтобы тебя правильно поняли, в формальных обходятся одним символом.
Грубо говоря, то, что на родном языке проще писать вообще, не означает, что на нём проще писать программы
На родном языке обычно проще писать чем на языке программирования.
Присвой переменной S значение произведения переменных V и T
S = V * T
Прямо даже и не знаю, что проще?
Вайбкодить нужно по водопаду, сначала тщательно описать все рамки, архитектуру, раскидать и структурировать все функции, отфильтровать, потом запускать следующий уровень. Так быстрее, чем сразу кодить. Это похоже на накатывание снежного комка в снеговика, начинаем с основы, архитектуры, требований... в общем полезно не просто уметь кодить, а сначала выучить весь стек целиком... плюс АИ подстраивается под уровень программиста. Если писать правильным языком с правильными терминами- его уровень выше. Он повторяет за вами и основывается на вашем мышление. Это продолжение вас.
Ещё нужно нарабатывать опыт кодинга постоянно, с утра до вечера и на многих разных задачах - ваш мозг тоже учится в процессе, вы становитесь умнее и опытнее. Не нужно ничего бросать и думать, что это плохо работает. Я пишу код с ИИ уже 3 года и сейчас это супер полезный инструмент.
Но я раньше руководил командами, имею опыт разработки 18 лет и написал до этого миллион строчек кода буквально. Сейчас с вайб кодингом я пишу порядка 10 тысяч строк очень хорошего кода в неделю стабильно, причём как правило всё работает почти с первого раза без отладки... бывает, что очень сложные решения, бывает простые... главное решить задачу в голове, а потом научить ИИ чтению мыслей, тогда всё получится.
ИИ не предлагает идей лучше, чем то, что содержится в их обучающих данных
вот это прозрение! что обучающий корпус это открытые источники навроде гитхаба. если на входе трижды переваренный кал, то что вы ждете на выходе? бриллианты и жемчужины? нет - четырежды переваренный кал.
всё жду когда гитхабы заполнят ботнетами, майнерами, локерами, рутшеллами, а нейронки громко чавкая схавают их и начнут срать этим на каждый второй промпт, а вайбкодеры не утруждаясь эту гниль потащат в продакшен
Уже начали добавлять трояны, создавая несуществующие библиотеки которые предлагают llm'ки
Мне кажется можно с помощью доп системного аромата это отлавливать
Что-то вроде "проверь отзывы в интернете на библиотеку и перед тем как ее добавить"
обучающий корпус это открытые источники навроде гитхаба
Хе-хе... Если бы гитхаб...
Я бы добавил
Сделали что-то, попробуйте тем же курсором поговоииь ... спрашивайте, какие у него есть вопросы, и не ленитесьна них отвечать. Вы удивитесь, но багов будет меньше.
Мне кажется, сделать приложение с помощью ИИ и отправить код в репозиторий — это ещё не совсем вайб-кодинг. Настоящий суровый вайб-кодинг — это когда ты пишешь промпты, сохраняешь их, и отправляешь их же в репозиторий. А само приложение будет генериться на этапе сборки.
Мсье знает толк в извращениях.
Это что, техническое задание не на салфетке написанно, а в репозитории?
Надеюсь к такому мы не перейдем. Каждое обновление будет рандомом, особенно "прикольно" в жизнеобеспечивающих отраслях, наверное, и в финансовых :)
Развитие идеи: генерить код и собирать приложение из промпта при каждом запуске!
Потом: рефакторинг промптов, "так уже никто не пишет", "Ой, модель обновилась, теперь эти промты не нужны", "Не знаю зачем эта строка, но без неё модель генерирует красный фон"
только в репо сохранять не промпты, а требования
и это неплохой способ
только не надо ждать решения за 1 раз
Звучит страшно и фантистически. Но чем это отличается от текущей ситуации? В репозитории лежат текстовые файлы с содержимым, написанном на почти естественном языке (например Java) и каждый раз при сборке на их основе генерируется абсолютно новый бинарник, который может почти полностью отличаться от прошлого при побайтовом сравнении, если, например, обновилась версия компилятора
Только к компилятору есть четкие требования по переводу в машинный код, а вот для LLM таких требований нет.
Требования к компиляторам, интерпретаторам, версиям ОС, под которыми нужно проводить сборку могут быть зафиксированы в коде. Как, например package-lock.json в js, composer.lock в php. В других языках это очевидно тоже есть. В docker-compose.yml, к примеру можно тоже зафиксировать все необходимые версии. И на выходе получается полностью детерминированный результат.
В то же время, в основе нейросетей лежит рандомизация. Не имея генератора случайных чисел, невозможно обучить модель. Поэтому и результат, выдаваемый ИИ, не может быть заранее детерминированным и всегда будет случайным.
Точно, и для большей суровости не давать задавать рандом сид, пусть приложение при каждой сборке получается новым!
VCaaC - Vibe Coding as a Code.
Как вам такой вариант вашего примера с прибавляющимся счетчиком:
const ClickCounter = ({count = 0}) => (
<button click_e_update={() => count++}>Clicked {() => count} times</button>
);Работает без ИИ, только на чисто-функциональном эфире :)
Тут немного путаница с терминами вышла. Вайбкодинг - это для домохозяек, которые не понимают сути процесса и действуют по "вайбу", т.е. настроению, эмоциям. Они не понимают код, не понимают действий нейросети. Для них нейросеть - это такая волшебная шкатулка, сверхразум. Отсуда же идёт название обычных запросов "промптами", т.к. они не понимают сути и просто повторяют кем-то сказанное.
Программисты же используют ai-assisted coding, т.е. разработку с помощью нейросети. Они отправляют запрос и проверяют результат генерации. Действуют не по настроению и эмоциям, а по результату работы кода, тестов.
Программисты тоже используют вайб кодинг. Это когда ты даже не вникаешь, что там написал ИИ. Только иногда можно че-нить руками поправить, когда ИИ ни как совсем не может. Это неплохо работает для небольших проектов, прототипы, mvp, хобби-проекты.
Если ты хорошо язык знаешь (и умеешь с LLM работать), то вникать особо не нужно, просто смотришь как за тебя на экране проект генерируется, в редких случаях поправляешь.
Это когда ты даже не вникаешь, что там написал ИИ.
эт погодите. Пока еще человечество только разворачивается в сторону специального спама для засирания llm. Думаю, в следующем десятилетии оно проявится во всей красе и проблемой будет не то, что оно визуально работает, а то, что ж там внутри еще лишнего дописано и насколько это опасно.
у вайбкодинга есть 2 очень очень неприятных момента
1) ты нифига не можешь оценить срок - разброс в 10 раз запросто, в худшем случае вдвое дольше чем вручную, потому что все выкинул и сделал сам
а писать в тикетах срок 2х, т.е. показывать снижение своей производительности вдвое это очень плохо
в результате 4 дня в неделю на вайбе, 1 день в мыле до ночи - мне такой режим не нравится
2) нечасто, но бывают очень плохие решения, что выясняется уже на проде
впрочем, это общеизвестный момент
Под конец дня я уже думал, как пояснить СТО без обид, что идея — очень не очень.
Получилось?
Если заказчик совсем не-технарь, предполагаю что имеет смысл продолжить писать дедовским способом (путем нажимания кнопок на клаве), а заказчику говорить что использую LLM на 80...90...95%.
Иначе в войне "менеджеры-инженеры" проигрывают всегда инженеры — они не умеют писать восхваляющие ИИ статьи, которым верят менеждеры...
В данный момент кодинг чуть ли не единственное реальное применение LLM. Я не отрицаю остальные приложения, но они в большей степени отстают от реального продукта.
Причина в том, что в кодинге есть чётко правильные и неправильные лейблы для RL. Это жутко бустит качество обучения.
Для таких задач, как перевод, суммаризация и т.д. ранжирование примеров для датасета остаётся и, скорее всего, будет субъективным. Что, наоборот, тормозит обучение.
Остается только посочувствовать вашему руководству и пожелать ему здоровья. Ибо с энтузиазмом и настойчивостью заставлять использовать индусский код от нейронок в бизнесе - это признак плохого самочувствия. Лично мне нейронки помогают решить проблемы, которые даже в официальных мануалах не описаны, либо описаны, но максимально криво. Однако поигравшись с ними неделю как с генератор кода, я понял, что мне проще самому все написать, чем постоянно жать копировать/вставить из-за тупейших ошибок. Я тупо устал делать копировать/вставить. Это похоже на какое то казино «выпадет работающий код или нет». Сочувствие, только сочувствие вашему руководству.
Общераспространенное заблуждение. Все LLM, включая коммерческие, растут из опенсурса, все они построены на опенсурсных библиотеках. Сфера LLM, подобно сфере Linux, жестко отсеивает любые "негативные тенденции" в общей архитектуре (а она всегда одна, потому что все библиотеки это форки друг друга). Конечно же LLM обучаются не на "индусах", а на лучших проектах с гитахаба, и других отсеянных высококачественных обучающих выборках. Вы же доверяете ядру Linux, хотя это чистой воды опенсорс? Так здесь в чём вопрос?
Важно указывать 'по состоянию на май 2025 года', поскольку каждый месяц появляются новинки, и нельзя утверждать, что текущий уровень вайб кодинга останется неизменным или что это его предел.
Это называется: суп из топора...
В статье прослеживается мысль которую я неоднократно описывал тут.
Любая программа это алгоритм. Алгоритм работы даже одного инпута на форме может быть очень большим. Это всяческие ограничения на ввод, описание автоматических действий при вводе текста, по типу автокоррекции, запрету определённых символов и прочего.
И тут мы приходим к сути проблемы. За многие десятилетия истории алгоритмов, человечество пришло к самому эффективному способу их точного описания - это код.
В вайбкодинге - мы пытаемся описать алгоритм человеческим языком. И этот способ проигрывает по качеству наглядности и минимализму обычному коду.
Отсюда в вышеописанной статье есть предостережения по типу - ни в коем случае не кидайте LLM не полный промт. Иначе она сама на-галлюцинирует такого, что потом это просто нереально отладить. Но! Максимально полный промт (описывающий все алгоритмы поведения) - это чистый код. Только написанный на языке (человеческом) - который не особо подходит для кодинга.
И есть ещё одна глобальная проблема. Писать максимально подробный промт сразу - практически невыполнимая задача даже для сеньора. Так уж устроена наша мясная нейросеть - где нейроны связаны графом. И если выборка не попадает в граф - то и информация не будет подгружена.
Когда мы пишем код сами - многие особенности поведения алгоритмов всплывают на автомате в голове. И мы их реализуем не задумываясь.
Но если всю туже работу нам нужно будет описать в промте человеческим языком - пласт знаний алгоритмов у нас в голове не всплывёт. Потому что описание алгоритма в человеческом коде - не пересекаются с алгоритмами в коде на котором вы всю жизнь писали. И собственно на котором тренировали свою мясную нейросеть.
Вайбкодинг - это симулятор поручения задач стажеру-джуну)
Просто приведу дословный репост моего вчерашнего поста в нашу внутреннюю рабочую группу:
"А ChatGPT - опасная штука, за ним глаз да глаз. Он может предложить рабочую (на первый взгляд) идею, но если попросить у него доработок/уточнений - он будет подставлять костыли и цепляться за свою идею как слепой за стену. И лепить костыли поверх нее. Пока ты сам не найдешь лучшее решение и не предложишь пересмотреть концепцию "с нуля", закинув свою идею. Вот тогда - он начинает думать уже над ней. Короче, нам, программистам (не кодерам!) он не угроза а помощник. Только уметь с ним надо.
Ключевая часть определения вайб-кодинга заключается в том, что пользователь принимает код, не полностью понимая его. ...
То есть для меня вайбкодинг, это когда я целиком и полностью сделал приложение за счёт ИИ, ну, может, с какими-то минимальными правками в коде ...
Исключительный уровень доверия или доверчивости.
Вы же можете неверно сформулировать задачу или пропустить какие-то требования.
Если вы не профессионал в постановках задач на разработку софта, это вполне допустимо.
А как часто вы пишете приложение целиком и полностью?
Может я ошибаюсь, но вы жалуетесь на инструмент из-за неправильного его использования.
Эту «заразу» вкинул в массы не кто иной, как Андрей Карпати, мать его. Просто почитайте его оригинальный твит. Вот этот цирк с конями:
Пользователь стремится «forget that the code even exists» (забыть, что код вообще существует).
Практикуется принцип «I 'Accept All' always, I don't read the diffs anymore» (Я всегда жму 'Принять все', я больше не читаю диффы).
В результате «The code grows beyond my usual comprehension» (Код разрастается за пределы моего обычного понимания).
Если возникает проблема, «Sometimes the LLMs can't fix a bug so I just work around it or ask for random changes until it goes away» (Иногда LLM не могут исправить баг, так что я просто обхожу его или прошу случайных изменений, пока он не исчезнет).
Сам Карпати заключает, что «It's not too bad for throwaway weekend projects» (Это не так уж плохо для одноразовых проектов на выходные) и что «it's not really coding» (это на самом деле не кодинг).
Именно этот подход и подразумевает тот «исключительный уровень доверия», о котором вы пишете.
Проблема в том, что сейчас этот почти ругательный термин («вайб‑кодинг») начали применять к любому процессу программирования с использованием LLM. Это вносит дикую путаницу.
От не поверите, но я изначально с ИИ начал общаться как с ребенком, последовательно ему указывая границы поведения и тд. Правда делал это только пару раз и не про кодинг)
Вот что мне не понравилось, точнее удивило, когда я дочитал до середины статьи: мне показалось странным, что вы с ним говорите на языке геометрии, ведь это не вертикали, а столбцы, а еще точнее, выпадающее меню. Может поэтому он не сразу понял, что подсосал тот сторонний API для вертикалей, а для выпадающих меню. То есть, первый промт в общей форме он понял правильно, но когда Вы начали разгонять про какие-то Vertical, от тут у него и потекло, видимо: Шеф путает вертикали со столбцами недоговаривая про выпадающие меню)
Прикольный текст, благодарю 😇
Я не хотел. Меня заставили. #вайбкодинг
Для того чтобы код был более читаемым и удобным для дальнейшего использования, можно попробовать скормить LLM хорошо формализованный style guide.
Помимо упрощения работы нейронки, получится ещё и отличный документ для остальной команды.
https://www.humblebundle.com/software/complete-vibe-coding-automation-and-profit-super-bundle-software без бутылочки смузи не заходить.
я разработчик с почти уже 25 лет стажем, и ИИ , а особенно агенты в cursor и vscode + copilot, наконец-то вывели разработку действительно на новый уровень. MVP на Flutter с полным MVVP как обёртка для backend - легко за 10 часов. Wordpress Plugin с UI клиента для экспорта данный - 5 часов. Chrome Extension с привязкой к тому же ИИ и валидацией промтов от того же ИИ - 10 часов. Плагин для Shopify - пять часов. Я бы месяцами это раньше делал это. И я в половине технического стека этого ничего не понимаю. Ну как... 25 лет не сотрёшь...;-)
Первый коммент в треде по делу.
И я в половине технического стека этого ничего не понимаю.
IMHO, это потенциально большая проблема. Время разработки уменьшается кардинально, но поиск и исправление ошибок могут слопать экономию и попросить ещё.
LLM в качестве подсказчика по знакомому стеку, всё-таки, безопаснее.
У меня тоже 25+ лет разработки кода и системной архитектуры, с десяток языков в более-менее активном использовании.
А есть уже смысл начинать вайб кодить на плюсах? У меня там базовый бэкенд. Курсор такое хавает, я просто что-то кейсов пока не нашёл кроме одного видос на ютубе.
Дорогой Хабр, сделайте интеграцию с какой-нибудь LLM и добавьте кнопочку "no bullshit", которая бы приводила речь автора в порядок.
Когда синьоры работают с инструментами вроде Cursor или Copilot, это выглядит как магия. Они могут создать целую функциональность за минуты, включая тесты и документацию. Но если присмотреться, заметно ключевое: они не просто позволяют ИИ генерировать код. Они постоянно рефакторят сгенерированный код. Они добавляют обработку ошибок, ловят edge кейсы, которые ИИ пропустил, усиливают типизацию и интерфейсы, а также ставят под сомнение архитектурные решения ИИ.Иными словами, они применяют годы опыта, чтобы формировать и ограничивать вывод ИИ.ИИ ускоряет реализацию, но их экспертиза обеспечивает поддержку проекта.
Спустя год или два на этом алгоритме модели дообучаются и ...
бутстраперы и итераторы
Пока вижу реальную пользу именно от итеративного подхода, еще и начиная работу с подробной архитектуры сразу после подробной формализации требований. Пробовал "бутстрап" - он реально буксует после роста проекта выше уровня 5-7+ тысяч строк. То есть для прототипа - норм, но потом все заново писать. Разбираться и развивать дальше команда не готова...
А вот итеративный подход - весьма ускоряет работу и позволяет сохранить понимание кода, если не злоупотреблять согласиями, а контролировать то, что именно пишет сетка. Получается и средние по размеру проекты тащить. Правда, приходиться постоянно удерживать себя от "да и так сойдет" )).
Кстати, нюанс Firebase - там Gemini, она упертая и нагло глючит иногда. Выгладит все гладко и все довольны, а потом прошу ее написать полную подробную документацию на каждый файл проекта - и получаю глюки и фантазии местами, типа "здесь вызов модели OpenAI", хотя ее в проекте нет и не было никогда.. Еще и и упирается, показывает мне несуществующий код и убеждая, что права...
Но если присмотреться, заметно ключевое: они не просто позволяют ИИ генерировать код. Они постоянно рефакторят сгенерированный код.
Строго говоря, сейчас это единственно работающий подход к использованию LLM в программиировании. Я в последние два года много экспериментировал с автогенерацией кода под локальные задачи в С, С++, Python и Kotlin, и пришёл у выводу, что описание задач в виде подробных промптов по сложности не особенно отличается от кодинга на вышеупомянутых языках с той разницей, что естественный язык хуже приспособлен для программирования :)
Практически во всех случаях сгенерированный код требовал верификации с помощью ревью и тестов, и часто содержал ошибки, далеко не всегда легко выявляемые младшими членами команды.
Посмотрим, конечно, что будет лет через пять.
Попробуйте вместо cursor https://github.com/hotovo/aider-desk, IMHO идеально для итеративного подхода
По факту, языком написания этого приложения стал английский.
Вайб-кодинг - новая парадигма программирования, в которой сухой язык промптов заменяет ЯП)
Посмотрим, во что выльется это дело. Будет грустно, если работодатели, в погоне за сиюминутной выгодой, совсем перестанут нанимать начинающих программистов.
По беглому взгляду на описание задач такое CTO должен был отправить вайбкодить как раз не программистов.
Мне недавно поручили завайбкодить сервис, который до этого хотели на лоукоде запилить - вот тут по опыту знакомых без бекграунда в разработке реально не обойтись.
А по опыту windsurf больше всего их продуктом внутри компании пользуется продажник, который пишет проги и скрипты помогающие ему в его задачах
del
Меня заставили повайбкодить