Да, ладно уже с правами на софт. Давайте решим хотя бы проблему кросс-компиляции.
Давайте заставим Apple, не запрещать собирать на windows/linux софт под их девайсы. Это уже будет прорыв. Ведь так странно, что swift-кросс-платформенный, но это не значит что он поддерживает кросс-компиляцию.
Следующий прорыв это сделать Windows SDK неприбытым гвоздями к msbuild.
То есть да, продавайте закрытый софт, зарабатываете на нем деньги, но в вставляйте палки в колеса, тем кто хочет сделать альтернативу, как например блокировка загрузкичов в android устройств, что б нельзя было поставить тот же LineageOS (Cyanogen mod).
Нужно работать над антимонопольным законодательством. Разделять где софт ключевая часть продукта, а где вспомогательная, телевизоры, смартфоны, компы, здесь софт вторичен, он должен быть открыт. Делаете супер программу по обработке фото в смартфоне, закрывайте этот компонет, запрещайте его запуск на устройствах от другого производителя законодательно, но форк андройда с нескучными обоями открывайте.
Bun, bun и ещё раз bun. Да конечно nodejs-runtime будет в electron, но все остальное, как юнит тесты, фронт или скрипты должно делаться через Bun. Bun просто работает, даже без tsconfig, но его все равно добавляют, что бы vs code все понимал.
По сути эти self-skills это подмножество soft-skills. Есть твердые скилы, которые применимы к конкретной профессии, а есть мягкий применимы везде. Но это уже к вопросам терминологии.
Дело не в вайбкодиге, а в качестве статей. Мне интерестно узнать что-то новое в этой теме, но проблема в том, что пишут либо чушь, либо воду, либо давно известные вещи.
Лично я неощущаю, что такое вайбкодинг. Я переодически задаю вопросы об ошибках, или прошу сгенерировать код у LLM. А вайбкодингом называют когда вообще в код не смотришь и оно самом как-то работу работает задачи делает и все круто, ну невижу я такого.
Кстати у Grok и у OpenAI есть голосовой помощник, но нет фичи которая бы позволиза созвместно писать код на canvas. Например я выделил кусок кода и сказал, вынеси метод и сделай его обобщенным что бы онподдерживал в аргументе массивы любого типа, и LLM мне это делает. Есть много тулов и расширейний для vscode может быть где-то есть такая функция и я бы с удовольствием почитал бы про то, как это настроить, сколько это стоит и насколько это эффективно. А текущая статья ни про что.
А в чем смысл статьи? Где опыт автора? Насколько это быстрее, дешевле, проще и менее требовательно к знаниям, чем написание кода самому или же используя llm как поисковик?
Ну и раз уж речь про LLM: я приведу обезвоженную версию статьи:
Вайб-кодинг позволяет создавать ПО, просто описывая идею ИИ (например, для прототипов игр), делая разработку доступнее и быстрее. Но метод непредсказуем (может создать яйцо вместо персонажа), требует точных инструкций и ручной проверки кода из-за ошибок, поэтому пока служит лишь помощником, а не заменой программисту.
Лично у меня teams хорошо работает, что на компьютере, что на телефоне. Качество голосовой связи определенно лучше тем у tg, что до блокировок, что после.
Когда grok 3 был был бесплатный в cline, я делал POC проекта для которого нужно был node-hid, electron и winapi. Там по итогу 300 строк кода. У меня ушло 10/2 млн токенов и целый рабочий день, на то что бы сделать что-то более вразумительное. Это примерно 60$.
Если умножить это на 20 рабочих дней то получается 1200$ в месяц тратить только на api. Это очень дорого и непонятно насколько это ускорит мою продуктивность, если использовать LLM только как поиск по документации.
При этом LLM плохо работает на больших реальных проектах. Я понимаю, что есть задачи написания чистых функций, верстки, тестов где LLM работает хорошо, но это от силы 5-10% рабочих задач.
Объясните мне, вайб-кодинг он с нами в одной комнате? Это вообще работает? Может быть кто-то может предложить как при помощи LLM изменить структуру проекта так, что бы он был готов к работе с LLM? Как сделать это дешевле?
Я использую LLM, но это не панацея. И я не понимаю как вайб-кодеры решают рабочие задачи?
Да и хрен с этими эмоциями, пусть лучше код без утечек памяти пишет, в это упор делать надо. И с ценой на API надо что-то делать, потому что агентный режим только через API и сделать простую фичу стоит очень дорого, сравнимо с ценой подписки. Приходиться копипастить код в браузер и обратно.
Вот они сделали открытые модели, пусть они их сделают, что простые вещи делаются у меня компе на упрощенных моделях, а сложные уже через API. Все работает относительно хорошо, но очень дорого для использования повседневно.
У меня другой опыт, все проблемы решаются либо оптимизацией бутылочного горлышка, либо изменением алгоритма. Например когда меняем поиск по массиву, на поиск в хэш-таблице. Или же вынос в веб-воркер, что бы не вешать основной поток, или виртуальный скролл, или кэш.
Экономия на спичках неактуальна для JS. Не устраивает время работы? Профилируем, находим бутылочное горлышко, переписываем на C++ (N-API/WebAssembly). 10 млн итераций заняли 200 мс, что приемлемо для запуска в Web Worker. Пользователь может и 5 секунд посмотреть на спиннер.
Да и как часто нужно обрабатывать такие объёмы данных? Показывать в UI более 100 (ну, пусть 1000) объектов бессмысленно. На бэкенде это скорее всего будет храниться в БД или обрабатываться джобой — проще масштабировать, чем заниматься микрооптимизациями. А если игра стоит свеч, то добро пожаловать в C++.
Ну так нужно работать в сторону развития MCP. Делать так, что бы инструменты давали более понятный выход для модели. Делать корпуса верифицированных знаний на которые модель может полагаться. Создавать механизмы верификации, например, для программирования запуск приложения в песочнице с отслеживанием побочных эффектов. Создание инструментов для кросс-валидации разными моделями. Текущие модели уже дают хороший результат, сейчас нужно как раз над обвесами работать.
Да, ладно уже с правами на софт. Давайте решим хотя бы проблему кросс-компиляции.
Давайте заставим Apple, не запрещать собирать на windows/linux софт под их девайсы. Это уже будет прорыв. Ведь так странно, что swift-кросс-платформенный, но это не значит что он поддерживает кросс-компиляцию.
Следующий прорыв это сделать Windows SDK неприбытым гвоздями к msbuild.
То есть да, продавайте закрытый софт, зарабатываете на нем деньги, но в вставляйте палки в колеса, тем кто хочет сделать альтернативу, как например блокировка загрузкичов в android устройств, что б нельзя было поставить тот же LineageOS (Cyanogen mod).
Нужно работать над антимонопольным законодательством. Разделять где софт ключевая часть продукта, а где вспомогательная, телевизоры, смартфоны, компы, здесь софт вторичен, он должен быть открыт. Делаете супер программу по обработке фото в смартфоне, закрывайте этот компонет, запрещайте его запуск на устройствах от другого производителя законодательно, но форк андройда с нескучными обоями открывайте.
"Журналжисты" более цензурный термин, пользуйтесь.
Правильно, на хабре мало мусора, давайте сюда привлекать авторов статей про сыр.
Bun, bun и ещё раз bun. Да конечно nodejs-runtime будет в electron, но все остальное, как юнит тесты, фронт или скрипты должно делаться через Bun. Bun просто работает, даже без tsconfig, но его все равно добавляют, что бы vs code все понимал.
m для objective-c, mm для objective-c++
Я бы ещё приводил сравнение с zig. Он имеет очень хорошую интеграцию с c/cpp/mm и тоже более безопасен.
По сути эти self-skills это подмножество soft-skills. Есть твердые скилы, которые применимы к конкретной профессии, а есть мягкий применимы везде. Но это уже к вопросам терминологии.
Bun shell, bun repl и проблема решена. Его как и curl нет в windows из коробки, но он поможет решить куда больше задач.
Ну так есть же тимс, и он прекрасно работает, креды те же
Дело не в вайбкодиге, а в качестве статей. Мне интерестно узнать что-то новое в этой теме, но проблема в том, что пишут либо чушь, либо воду, либо давно известные вещи.
Лично я неощущаю, что такое вайбкодинг. Я переодически задаю вопросы об ошибках, или прошу сгенерировать код у LLM. А вайбкодингом называют когда вообще в код не смотришь и оно самом как-то работу работает задачи делает и все круто, ну невижу я такого.
Кстати у Grok и у OpenAI есть голосовой помощник, но нет фичи которая бы позволиза созвместно писать код на canvas. Например я выделил кусок кода и сказал, вынеси метод и сделай его обобщенным что бы онподдерживал в аргументе массивы любого типа, и LLM мне это делает. Есть много тулов и расширейний для vscode может быть где-то есть такая функция и я бы с удовольствием почитал бы про то, как это настроить, сколько это стоит и насколько это эффективно. А текущая статья ни про что.
А в чем смысл статьи? Где опыт автора? Насколько это быстрее, дешевле, проще и менее требовательно к знаниям, чем написание кода самому или же используя llm как поисковик?
Ну и раз уж речь про LLM: я приведу обезвоженную версию статьи:
Лично у меня teams хорошо работает, что на компьютере, что на телефоне. Качество голосовой связи определенно лучше тем у tg, что до блокировок, что после.
Когда grok 3 был был бесплатный в cline, я делал POC проекта для которого нужно был node-hid, electron и winapi. Там по итогу 300 строк кода. У меня ушло 10/2 млн токенов и целый рабочий день, на то что бы сделать что-то более вразумительное. Это примерно 60$.
Если умножить это на 20 рабочих дней то получается 1200$ в месяц тратить только на api. Это очень дорого и непонятно насколько это ускорит мою продуктивность, если использовать LLM только как поиск по документации.
При этом LLM плохо работает на больших реальных проектах. Я понимаю, что есть задачи написания чистых функций, верстки, тестов где LLM работает хорошо, но это от силы 5-10% рабочих задач.
Объясните мне, вайб-кодинг он с нами в одной комнате? Это вообще работает? Может быть кто-то может предложить как при помощи LLM изменить структуру проекта так, что бы он был готов к работе с LLM? Как сделать это дешевле?
Я использую LLM, но это не панацея. И я не понимаю как вайб-кодеры решают рабочие задачи?
Да и хрен с этими эмоциями, пусть лучше код без утечек памяти пишет, в это упор делать надо. И с ценой на API надо что-то делать, потому что агентный режим только через API и сделать простую фичу стоит очень дорого, сравнимо с ценой подписки. Приходиться копипастить код в браузер и обратно.
Вот они сделали открытые модели, пусть они их сделают, что простые вещи делаются у меня компе на упрощенных моделях, а сложные уже через API. Все работает относительно хорошо, но очень дорого для использования повседневно.
У меня другой опыт, все проблемы решаются либо оптимизацией бутылочного горлышка, либо изменением алгоритма. Например когда меняем поиск по массиву, на поиск в хэш-таблице. Или же вынос в веб-воркер, что бы не вешать основной поток, или виртуальный скролл, или кэш.
Экономия на спичках неактуальна для JS. Не устраивает время работы? Профилируем, находим бутылочное горлышко, переписываем на C++ (N-API/WebAssembly). 10 млн итераций заняли 200 мс, что приемлемо для запуска в Web Worker. Пользователь может и 5 секунд посмотреть на спиннер.
Да и как часто нужно обрабатывать такие объёмы данных? Показывать в UI более 100 (ну, пусть 1000) объектов бессмысленно. На бэкенде это скорее всего будет храниться в БД или обрабатываться джобой — проще масштабировать, чем заниматься микрооптимизациями. А если игра стоит свеч, то добро пожаловать в C++.
Я бы советовал заменить shell на bun-shell и кайфовать.
https://bun.com/docs/runtime/shell
Ну так нужно работать в сторону развития MCP. Делать так, что бы инструменты давали более понятный выход для модели. Делать корпуса верифицированных знаний на которые модель может полагаться. Создавать механизмы верификации, например, для программирования запуск приложения в песочнице с отслеживанием побочных эффектов. Создание инструментов для кросс-валидации разными моделями. Текущие модели уже дают хороший результат, сейчас нужно как раз над обвесами работать.
Вот оно где-то рядом, но все никак не нащупать.
Скорее всего это должно быть похоже на CSV, line1, "line with quote "", "multi\nline"
В любом случае, должна быть возможность редактировать ручками как fodt, но не так монструюзно.