Вот интересно, и почему я за 15 лет ни разу не попал в ситуацию, описанную в статье? При том что живу на Дальнем Востоке, где именно такие дорожные условия встречаются часто. Может потому что нужно во врем вождения проявлять бдительность, опираться на знания и опыт (свой и чужой)?
По вашему, наличие автоматизированных систем должно искоренить такие и подобные проблемы? Нет. Такого не будет. И тут всё очень просто. Управление транспортным средством, на момент дня сегодняшнего, это не расслабленное прослушивание подкаста, это слежение за дорожной ситуацией. Видя за 500 метров лесополосу, я например, на автоматизме начинаю притормаживать если время года отличное от лета. А что если бы ситуация закончилась бы более трагично? А что если бы пострадали например дети? Вы бы тоже винили в этом отсутствие ИИ в вашем авто?
Ну а АБС вообще не призвано автоматизировать какие-либо процессы управления ТС, а помогать водителю в ситуациях аналогичных описанным в статье когда он уже в неё попал (ушёл в занос например). Но при этом, АБС и подобные системы, зачастую даже мешают принятию наиболее верных решений, поэтому опытные водители часто недолюбливают все эти автоматизации.
И ещё раз, ситуация в которую попал водитель, абсолютно тривиальная.
А подвальные "таксопарки" на рациях вернутся? Помню в нашем мухосранске было такси 5 звёзд", у меня даже VIP-карта была. Были же времена. Прям 2007 пахнуло.
Лично мне не известны рабочие способы решения этой проблемы: невозможно заранее предсказать сколько токенов потребуется модели для обработки запроса, и не превысит ли это количество оставшееся количество токенов в текущей сессии.
Лично мне известно несколько таких способов. Самый простой из них, когда ты просишь создать задачи на основе ресёрча бизнес-задачи, указать, что каждая задача не должна превышать например 2 или 3 или сколько ты хочешь (вычисляется эмпирическим путём) дней по оценки трудозатрат. Таким образом, задачи будут созданы с учётом этого и будут предсказуемы. Если вы не используете разделение задач контроль их размера - вы получаете проблему о которой сами же и сказали.
Расскажите подробнее, о чём речь. Потому что, насколько я понимаю, консенсус на сегодня заключается в том, что работа с кодом требует чтобы модель видела код полностью, причём в его текущей версии
Не следует в RAG хранить код. В RAG есть документация проекта. При этом, для корректной работы, документация должна быть соответствующе подготовлена. Таким образом, задавая контекст, какие то вещи будут взяты моделью из базы знаний. База знаний пополняется по мере работы над проектом и это должно входить в флоу работы с LLM. Например, предоставив модели тул с описанием, что тул предоставляет оглавления документации, позволит модели посмотреть оглавления и вызвать нужное если это потребуется.
Это чушь и передёргивание. Вайбкодингом оно станет только если сгенерированный код принимать без тщательного ревью. А с ревью это очень близко к обычному процессу парного программирования.
Ревью обязателен в любом случае. Однако ревью целого проекта или всей бизнес-задачи созданного одним промптом и ревью небольших итераций (в том числе по средствам самой LLM) это не одно и тоже.
Зачастую люди применяют второе, отсюда и разговоры, что LLM может гененировать только нейрослом.
Речь не о замене промпта на что-то принципиально другое6 а добалении инструкций говорящих модели об итерации. И это не я придумал.
Субагенты сегодня - довольно сомнительная фича. Мне вообще кажется, что её придумали ради кратного увеличения затрат на токены.
Использование субагентов позволяет атомизировать подзадачи, и как следствие - повышать их качество выполнения за счёт маленьких, но гарантированно решаемых задач. Вопрос токенов тут не стоит. Как показывает практика, затраты токенов на применение субагентов, примерно равносильны затратам при их неиспользовании. Это происходит из-за увеличения итераций доработок при линейном подходе.
Оставим за кадром вопрос пруфов на тему для кого был придуман этот механизм, давайте обсудим определение "более качественный подход".
В чём необходимость пруфов не ясно. Однако ясно, появление механизма сжатия - это решения проблемы переплонения контекстного окна в угоду процесса (именно процесса, который для многих кажется правильным, когда готовият огромную задачу и тупо ждут результата). С момента появления механизма сжатия контекста, мне ни разу он не понадобился, с учётом большого количества решаемых задач с помощью LLM.
А когда сессия оборвалась в процессе работы над задачей нам в любом случае нужно какое-то саммари для продолжения работы в новой сессии.
Повторю, при атомарности задач и контроля их размера это не нужно. Ты просто повторяешь задачу и если надо, с чекаутом предыдущих изменений либо указанием предварительно проанализировать прогресс. Проблемы нет от слова совсем. И это так же может быть автоматизировано в выбранном флоу.
Не понял вашего сарказма по поводу токенов. Но да ладно. Всё это я написал только для того, что бы у читателя не возникло ощущения, что вы своим пет проектом раскрыли всем глаза. Только и всего. Но я желаю вам успехов в ваших исследованиях. И да, за Rust респект.
К сожалению, ваш агент не далеко ушёл от этого самого простого цикла.
Вот простой минимум контрольных вопросов.
Меняет ли ваш агент системный промпт после первого сообщения пользователя? Например: вы работаете с моделью делая предварительный ресёрч перед запуском основного флоу. Вы задали изначальный промпт (не важно, будет это текст или файл с промптом), после чего получили ответ и продолжаете итеративно менеджить процесс. В первом сообщении, у вас должен быть один системный промпт, в последующих - другой. И так не только для ресёрчей.
Использует ли ваш агент кеш?
Есть ли инструмент позволяющий автоматически запускать субагентов? А не автоматически?
Допустим есть. А как он это делает? Как будет обработан агентом результат работы субагента? Какие инструкции будут даны основному агенту вместе с результатом работы субагента?
Использует ли агент LSP? А как использует? Какие инструкции получает модель вместе с результатом работы LSP?
Использует ли ваш агент правила? Какие инструкции получает модель от агента вместе с правилами?
Про MCP я вообще промолчу.
И повторю, это лишь несколько примеров из того что ваш агент должен уметь для того что бы не быть очередным мусором.
Ну и не могу не упомянуть про суммаризацию. По своей сути, этот механизм был придуман для вайбкодеров, которые не особо то думают головой когда используют LLM для разработки. При более качественном подходе в работе с LLM, этот механизм не нужен вообще. Если в вашей работе с LLM вам необходима суммаризация - вы вероятно не умеете планировать и ставить задачи.
Большинство существующих агентов для коддинга - мусор. И судя по написанному в статье, ваш не исключение, без обид. Создание качественного агента это не промпт за бутылкой пива, а серьёзная исследовательская работа. То, как агент взаимодействует с моделью, операционной системой и пользователем напрямую влияет на инференс. Поэтому когда на просторах интернета вайбкоддеры начинают сравнивать модели, используя, при этом разные агенты, не вызывает у меня ничего кроме желания сделать facepalm.
RAG? Спасибо, нет
Что же, жаль что вы не смогли осознать как его применять в коддинге. Это весьма полезная вещь если уметь её готовить. Проблема состоит лишь в том, что для конкретного проекта нужен свой подход в применении RAG. Если для вас работа с кодом с помощью LLM это только написание промпта и ожидание результата - то это тот самый вайбкоддинг, от которого ожидать что-то кроме нейрослопа не следует.
Вот честное слово, ничего личного. Хотел поддержать отечественную разработку. Поставил в Idea ваш плагин. Он повесил мой Macbook Pro с M4 что пришлось убивать процесс Intelij Idea. Индексация просто зависала. Пробовал несколько раз - результат одинаковый. Проект не самого большого размера, но индексация вашим плагином не давала сделать абсолютно ничего. Удалил. Но я желаю вам успехов, может через годик попробую снова.
Из прочитанного понял что речь в статье вовсе не про микросервисы, а про распределённый монолит. Микросервисы безусловно не панацея, однако если для вас микросервисы == распределённый монолит - то у меня для вас плохие новости, так как все ваши доводы в этом случае несостоятельны.
Заголовок кликбейт. Ни о каком заработке в 1,7 млн в статье речи не идёт. Ну а в остальном, речь об типичном печатном салоне, у меня за углом аналогичный, заказывал там брендированные кепки месяц назад. Ну, впрочем, курица тоже кудахтает так, как будто снесла планету.
С годами я понял одну вещь. Чем больше я смотрю на ООП, на все эти потуги с DDD, отловом исключений и т.п, тем больше понимаю, что через ООП нужно пройти. Сначала осознать, потом обуздать, потом стать евангелистом ООП, потом начать сомневаться что бы потом в итоге осознать - что тебе это не нужно.
Без исходников, мог бы даже не утруждаться писать эту портянку.
Вот интересно, и почему я за 15 лет ни разу не попал в ситуацию, описанную в статье? При том что живу на Дальнем Востоке, где именно такие дорожные условия встречаются часто. Может потому что нужно во врем вождения проявлять бдительность, опираться на знания и опыт (свой и чужой)?
По вашему, наличие автоматизированных систем должно искоренить такие и подобные проблемы? Нет. Такого не будет. И тут всё очень просто. Управление транспортным средством, на момент дня сегодняшнего, это не расслабленное прослушивание подкаста, это слежение за дорожной ситуацией. Видя за 500 метров лесополосу, я например, на автоматизме начинаю притормаживать если время года отличное от лета. А что если бы ситуация закончилась бы более трагично? А что если бы пострадали например дети? Вы бы тоже винили в этом отсутствие ИИ в вашем авто?
Ну а АБС вообще не призвано автоматизировать какие-либо процессы управления ТС, а помогать водителю в ситуациях аналогичных описанным в статье когда он уже в неё попал (ушёл в занос например). Но при этом, АБС и подобные системы, зачастую даже мешают принятию наиболее верных решений, поэтому опытные водители часто недолюбливают все эти автоматизации.
И ещё раз, ситуация в которую попал водитель, абсолютно тривиальная.
Статья по своей сути, является нытьём, которое прикрывает стремление кухонных экспертов оправдать собственное нубство как водителей.
Так и сделают. Но надо же что-то в карман положить, не за свой же счёт эти самые шильдики менять.
Приватизация прибили и обобществление издержек. Какие молодцы!
Зачем к дороге, он и на парковке ловит прекрасно.
А подвальные "таксопарки" на рациях вернутся? Помню в нашем мухосранске было такси 5 звёзд", у меня даже VIP-карта была. Были же времена. Прям 2007 пахнуло.
Лично мне известно несколько таких способов. Самый простой из них, когда ты просишь создать задачи на основе ресёрча бизнес-задачи, указать, что каждая задача не должна превышать например 2 или 3 или сколько ты хочешь (вычисляется эмпирическим путём) дней по оценки трудозатрат. Таким образом, задачи будут созданы с учётом этого и будут предсказуемы. Если вы не используете разделение задач контроль их размера - вы получаете проблему о которой сами же и сказали.
Не следует в RAG хранить код. В RAG есть документация проекта. При этом, для корректной работы, документация должна быть соответствующе подготовлена. Таким образом, задавая контекст, какие то вещи будут взяты моделью из базы знаний. База знаний пополняется по мере работы над проектом и это должно входить в флоу работы с LLM. Например, предоставив модели тул с описанием, что тул предоставляет оглавления документации, позволит модели посмотреть оглавления и вызвать нужное если это потребуется.
Ревью обязателен в любом случае. Однако ревью целого проекта или всей бизнес-задачи созданного одним промптом и ревью небольших итераций (в том числе по средствам самой LLM) это не одно и тоже.
Зачастую люди применяют второе, отсюда и разговоры, что LLM может гененировать только нейрослом.
Чтобы что?
Речь не о замене промпта на что-то принципиально другое6 а добалении инструкций говорящих модели об итерации. И это не я придумал.
Использование субагентов позволяет атомизировать подзадачи, и как следствие - повышать их качество выполнения за счёт маленьких, но гарантированно решаемых задач. Вопрос токенов тут не стоит. Как показывает практика, затраты токенов на применение субагентов, примерно равносильны затратам при их неиспользовании. Это происходит из-за увеличения итераций доработок при линейном подходе.
В чём необходимость пруфов не ясно. Однако ясно, появление механизма сжатия - это решения проблемы переплонения контекстного окна в угоду процесса (именно процесса, который для многих кажется правильным, когда готовият огромную задачу и тупо ждут результата). С момента появления механизма сжатия контекста, мне ни разу он не понадобился, с учётом большого количества решаемых задач с помощью LLM.
Повторю, при атомарности задач и контроля их размера это не нужно. Ты просто повторяешь задачу и если надо, с чекаутом предыдущих изменений либо указанием предварительно проанализировать прогресс. Проблемы нет от слова совсем. И это так же может быть автоматизировано в выбранном флоу.
Не понял вашего сарказма по поводу токенов. Но да ладно. Всё это я написал только для того, что бы у читателя не возникло ощущения, что вы своим пет проектом раскрыли всем глаза. Только и всего. Но я желаю вам успехов в ваших исследованиях. И да, за Rust респект.
К сожалению, ваш агент не далеко ушёл от этого самого простого цикла.
Вот простой минимум контрольных вопросов.
Меняет ли ваш агент системный промпт после первого сообщения пользователя? Например: вы работаете с моделью делая предварительный ресёрч перед запуском основного флоу. Вы задали изначальный промпт (не важно, будет это текст или файл с промптом), после чего получили ответ и продолжаете итеративно менеджить процесс. В первом сообщении, у вас должен быть один системный промпт, в последующих - другой. И так не только для ресёрчей.
Использует ли ваш агент кеш?
Есть ли инструмент позволяющий автоматически запускать субагентов? А не автоматически?
Допустим есть. А как он это делает? Как будет обработан агентом результат работы субагента? Какие инструкции будут даны основному агенту вместе с результатом работы субагента?
Использует ли агент LSP? А как использует? Какие инструкции получает модель вместе с результатом работы LSP?
Использует ли ваш агент правила? Какие инструкции получает модель от агента вместе с правилами?
Про MCP я вообще промолчу.
И повторю, это лишь несколько примеров из того что ваш агент должен уметь для того что бы не быть очередным мусором.
Ну и не могу не упомянуть про суммаризацию. По своей сути, этот механизм был придуман для вайбкодеров, которые не особо то думают головой когда используют LLM для разработки. При более качественном подходе в работе с LLM, этот механизм не нужен вообще. Если в вашей работе с LLM вам необходима суммаризация - вы вероятно не умеете планировать и ставить задачи.
Большинство существующих агентов для коддинга - мусор. И судя по написанному в статье, ваш не исключение, без обид. Создание качественного агента это не промпт за бутылкой пива, а серьёзная исследовательская работа. То, как агент взаимодействует с моделью, операционной системой и пользователем напрямую влияет на инференс. Поэтому когда на просторах интернета вайбкоддеры начинают сравнивать модели, используя, при этом разные агенты, не вызывает у меня ничего кроме желания сделать facepalm.
Что же, жаль что вы не смогли осознать как его применять в коддинге. Это весьма полезная вещь если уметь её готовить. Проблема состоит лишь в том, что для конкретного проекта нужен свой подход в применении RAG. Если для вас работа с кодом с помощью LLM это только написание промпта и ожидание результата - то это тот самый вайбкоддинг, от которого ожидать что-то кроме нейрослопа не следует.
Вот честное слово, ничего личного. Хотел поддержать отечественную разработку. Поставил в Idea ваш плагин. Он повесил мой Macbook Pro с M4 что пришлось убивать процесс Intelij Idea. Индексация просто зависала. Пробовал несколько раз - результат одинаковый. Проект не самого большого размера, но индексация вашим плагином не давала сделать абсолютно ничего. Удалил. Но я желаю вам успехов, может через годик попробую снова.
Из прочитанного понял что речь в статье вовсе не про микросервисы, а про распределённый монолит. Микросервисы безусловно не панацея, однако если для вас микросервисы == распределённый монолит - то у меня для вас плохие новости, так как все ваши доводы в этом случае несостоятельны.
А вот тут респект за прямоту и честность
Заголовок кликбейт. Ни о каком заработке в 1,7 млн в статье речи не идёт. Ну а в остальном, речь об типичном печатном салоне, у меня за углом аналогичный, заказывал там брендированные кепки месяц назад. Ну, впрочем, курица тоже кудахтает так, как будто снесла планету.
С годами я понял одну вещь. Чем больше я смотрю на ООП, на все эти потуги с DDD, отловом исключений и т.п, тем больше понимаю, что через ООП нужно пройти. Сначала осознать, потом обуздать, потом стать евангелистом ООП, потом начать сомневаться что бы потом в итоге осознать - что тебе это не нужно.
Эх, ничему Ералаш их не учит...
То OpenAI в гос органы ходит жаловаться, теперь эти. Интересные они ребята, хотят что бы конкурировали честно, но не они.