А в чем смысл статьи? Где опыт автора? Насколько это быстрее, дешевле, проще и менее требовательно к знаниям, чем написание кода самому или же используя 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. Делать так, что бы инструменты давали более понятный выход для модели. Делать корпуса верифицированных знаний на которые модель может полагаться. Создавать механизмы верификации, например, для программирования запуск приложения в песочнице с отслеживанием побочных эффектов. Создание инструментов для кросс-валидации разными моделями. Текущие модели уже дают хороший результат, сейчас нужно как раз над обвесами работать.
Мне кажется, что 95% юзеров достаточно markdown. А остальным 5% как будто следует использовать html+css, Latex или что-то подобное. А ещё есть typecell (Mark Down + Typescript + jsx).
Лично мне кажется, что так больше контроля на потоком данных и соблюдается принципы low coupling и high cohesion. Ну вот как-то по субъективным ощущениям это работает луше.
Я использую RxJS и Inversify в связке с react и это работает. А Redux, это просто очень много размазанного по системе бойлерплейта. Может быть я чего-то не понимаю, но для меня дебажить и писать новые фичи с Redux сложнее и дольше.
RxJS + Inversify позволяет хранить структуру данных вместе с методами их обработки. Соблюдается принцип high cohesion. Я вижу в одном месте связанные логически вещи и инкапсулирую состояние. Появляется иерархия сервисов. От простых для работы с localstorage, до сложных бизнес сценариев (например многошаговые формы, я могу создать сервис для всех этапов, и сервисы для конкретного шага, что позволяет выстроить нормальные и слабозависимые друг от друга шаги и отдать их разным разработчикам).
Вы хотели решить проблему, того что текущие сотрудники увидят эту вакансию и удивяться, что могут взять с улицы за большую сумму. Большая викла решает эту проблему, большой диапазон дает кандидату понять финасовые возможности компании, но так же показывает текущим сотрудникам, что они в этой вилке.
Моя проблема как кандидата, что мне прилетают приглашения на собес где самое максимальное предложения сильно меньше, чем я ожидаю. А для того, что бы это фильтрануть, мне надо пройти тех. собес и по сути дойти до оффера, что бы узнать уровень оплаты труда.
А теперь вопрос: почему на Python? Вакансии вообще существуют? Мне кажется, что даже на PHP проще работу найти чем на python. А ведь есть ещё прекрасный Typescript, С#, Ыыынтырпрайз Java.
Почему нельзя в заголовок вакансии писать титульную технологию? Не Backend developer, а .NET Backend Developer? Разве, это сложно?
Почему нельзя писать зарплатную вилку? Вы хотите торговаться по з/п? Так торгуйтесь. Вы потратите больше денег, если кандидат пройдет все этапы, а потом вы не сойдетесь по з/п? Это особенно классно, когда сами HR-пишут в linkedin и пытаются переманить человека с текущего места. Кандидат спокойно сходит на собеседование, что бы быть в тонусе.
Зачем супер подробно рассказывать, про историю компании, а особенно про географию клиентов? Лучше расскажите, про процессы, да банально в какое время стоят миты. Читайте дальше по методичке, только включите в неё нужную информацию.
Если вам интересен фидбек по описанию вакансии, можете написать мне в telegram: @swatoplus
А в чем смысл статьи? Где опыт автора? Насколько это быстрее, дешевле, проще и менее требовательно к знаниям, чем написание кода самому или же используя 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, но не так монструюзно.
Значит нужен markdown-для табличек, что бы можно было интегрировать в markdown для текста.
Мне кажется, что 95% юзеров достаточно markdown. А остальным 5% как будто следует использовать html+css, Latex или что-то подобное. А ещё есть typecell (Mark Down + Typescript + jsx).
Лично мне кажется, что так больше контроля на потоком данных и соблюдается принципы low coupling и high cohesion. Ну вот как-то по субъективным ощущениям это работает луше.
Я использую RxJS и Inversify в связке с react и это работает. А Redux, это просто очень много размазанного по системе бойлерплейта. Может быть я чего-то не понимаю, но для меня дебажить и писать новые фичи с Redux сложнее и дольше.
RxJS + Inversify позволяет хранить структуру данных вместе с методами их обработки. Соблюдается принцип high cohesion. Я вижу в одном месте связанные логически вещи и инкапсулирую состояние. Появляется иерархия сервисов. От простых для работы с localstorage, до сложных бизнес сценариев (например многошаговые формы, я могу создать сервис для всех этапов, и сервисы для конкретного шага, что позволяет выстроить нормальные и слабозависимые друг от друга шаги и отдать их разным разработчикам).
Розетки в откосах по земстандарту!
Вы хотели решить проблему, того что текущие сотрудники увидят эту вакансию и удивяться, что могут взять с улицы за большую сумму. Большая викла решает эту проблему, большой диапазон дает кандидату понять финасовые возможности компании, но так же показывает текущим сотрудникам, что они в этой вилке.
Моя проблема как кандидата, что мне прилетают приглашения на собес где самое максимальное предложения сильно меньше, чем я ожидаю. А для того, что бы это фильтрануть, мне надо пройти тех. собес и по сути дойти до оффера, что бы узнать уровень оплаты труда.
Звучит, как будто надо делать свою компанию, где всем будут править разрабы. Вот есть только одна проблема: где искать сбыт.
Пишите 500 - 5000 USD и проблем не будет. Компания покажет, что к нее есть бюджеты, но их надо заслужить.
А теперь вопрос: почему на Python? Вакансии
вообще существуют? Мне кажется, что даже на PHP проще работу найти чем на python. А ведь есть ещё прекрасный Typescript, С#, Ыыынтырпрайз Java.
Почему нельзя в заголовок вакансии писать титульную технологию? Не Backend developer, а .NET Backend Developer? Разве, это сложно?
Почему нельзя писать зарплатную вилку? Вы хотите торговаться по з/п? Так торгуйтесь. Вы потратите больше денег, если кандидат пройдет все этапы, а потом вы не сойдетесь по з/п? Это особенно классно, когда сами HR-пишут в linkedin и пытаются переманить человека с текущего места. Кандидат спокойно сходит на собеседование, что бы быть в тонусе.
Зачем супер подробно рассказывать, про историю компании, а особенно про географию клиентов? Лучше расскажите, про процессы, да банально в какое время стоят миты. Читайте дальше по методичке, только включите в неё нужную информацию.
Если вам интересен фидбек по описанию вакансии, можете написать мне в telegram: @swatoplus