Подключите эту же модель через LM Studio к Claude Code, обозвав ее Claude Sonnet, и вы увидите, что она прекрасно работает, используя абсолютно все возможности самого Claude Code.
Полный игнор релевантного скила
Даже после прямого вопроса продолжает про React Router + выдумала несуществующий
Не смогла правильно вызвать то ли скил, то ли саб-агента + спутала таски с todo list
Не знаю, кто эти ребята что плюсуют ваши комментарии, видимо ваши друзья. Других объяснений этому поведению нет. Теперь по существу:
Ваши выводы про Qwen3 Coder Next не подтверждаются моей практикой
Не интересуют меня ваши субъективные ощущения. Приведите пруфы и цифры, а не ссылку на ютюб.
В вашем случае проблема кроется не в самих моделях, а в Qwen Code и его настройках
Вы прочитали статью, но не заметили, что добрая ее половина как раз об этом? Вы даже TL;DR пропустили, давайте напомню:
TL;DR:CLI-агенты галлюцинируют даже с мощными моделями, потому что системные промпты раздуты лишними примерами, повторами и нерелевантными терминами. Это математически бьёт по вниманию модели и не даёт того эффекта, который обещают best-practices. Я форкнул Qwen Code, вычистил системные промпты, и на 4 моделях получил стабильный вызов нужных скиллов, меньше галлюцинаций и на 35-53% сократил расход токенов. Без потери качества.
Дальше вы пишите:
Насколько я помню, у Qwen Code он завернут в специфические xml теги
Давайте приведу еще один отрывок из статьи, которую вы читали: Интересно, что доступные скилы в Qwen Code пакуются в некие специальные XML директивы (назначение которых мне неизвестно), и отправляются как сообщение пользователя а не системы (что похоже на баг).
Как же вы статью то читали? Точнее какую? Эту точно нет.
Вам определенно стоит покопать именно в эту сторону.
В какую? Не в сторону ли инструмента, то есть CLI, о чем как раз вторая половина статьи? О том куда я копал, зачем, что изменил и какие результаты получил?
Вы просто не умеете его готовить. Я специально написал это так категорично, чтобы дать вам заряд энергии выйти из отрицания и разобраться почему же он не работает у вас.
А пруфы будут, или мы просто должны поверить вашей «практике»?
То, что у вас она наотрез отказывается работать
Отказывается работать, и игнорирует инструкции системного промпта – это совершенно разные вещи. Для агентских систем reasoning обязателен, и проведенный мной эксперимент это подтверждает. Имея описания минимум двух релевантных скилов, Qwen3 Coder Next неспособен прийти к выводу, что надо бы их использовать. То есть ему не хватает умений даже инструменты свои использовать, не говоря уже о выполнении комплексных, многоступенчатых задач.
Я принимаю код от агента, не потому что он мне нравится, а из-за кривизны инструментов, так как агенты печатают в консоль только часть изменений. Из-за этого приходится нажимать yes, а потом смотреть что он там нашкодил. Так что статистика эта бесполезная
В production это даёт задержку 8-12 секунд от момента "позвонить" до первого аудио. Причина: современные мобильные устройства собирают ICE-кандидаты медленно — особенно в мобильных сетях, особенно если STUN/TURN серверы далеко. ICE gathering может занимать 3-5 секунд на стороне caller, потом ещё 3-5 секунд на стороне receiver.
Звучит как вечность. Есть какие-то примеры реальных измерений с дампами?
Автор REST в своей диссертации , в которой он собственно представил REST, очень явно обосновывает свое решение ссылаясь на другую работу, ссылку на которую я также привел в статье. Суть архитектуры в том, что она явно обозначает ограничения которые должны быть соблюдены для достижения результата, при этом архитектура не диктует «как» реализовывать. Он пишет:
We next add a constraint to the client-server interaction: communication must be stateless in nature, as in the client-stateless-server (CSS) style of Section 3.4.3 (Figure 5-3), such that each request from client to server must contain all of the information necessary to understand the request
То есть stateless – не REST, а «коммуникация» между клиентом и сервером. Это в том числе вытекает из ограничений остальных компонентов системы, например транспорта. Каждый TCP пакет в последовательности должен содержать идентификатор соединения, каждый Request должен содержать идентификатор пользователя и т.д.
Тоже остается справедливым и для фронтенда, где каждый Request (Event), содержит всю необходимую информацию. Когда мы пишем el.addEventListener('input', cb), браузер передает не просто строку с новым текстом, полагая что мы понимаем от какого именно <input /> оно пришло, а Event со всей необходимой информацией, делая нашу «шину» stateless по природе.
Имеется ввиду что map, filter и т.д. возвращают промисы? Это же принесет больше проблем, нет? Что если там девять элементов, и на обработке шестого произошла ошибка? Или например map отработал, а на reduce в третьем элементе произошла ошибка?
А причем тут вообще роутер? Я про кнопку в браузере. Она уже есть, работает как надо, и ею пользуются. Вы же не делаете в интерфейсе адресную строку, чтобы пользователь вводит туда ссылки на ваш же сайт, а кнопку назад для чего делаете? Я этого не понимаю. Еще я ожидаю, что если она вдруг зачем-то есть, то работает также как в браузере, а в описанным вами сценарии это не так. Если я перешел на страницу товара сразу, например из результатов выдачи Гугла, то при нажатии назад, я хочу вернуться назад, то есть в результаты выдачи Гугла, а не на страницу с вашим каталогом которую я вовсе не посещал.
Ограничения c H.265 в веб-браузерах больше лицензионные
Это больше миф. Не все видеокарты умеют декодировать этот кодек, и если у вас ни одно видео не работает, значит или вообще нет видеокарты, или она старая, или в браузере выключена настройка hardware acceleration.
Все современные браузеры этот кодек поддерживают (если железо его поддерживает), а прошлым летом его занесли даже в WebRTC.
Автор явно не работал с этим серьезно. Тогда бы он упомянул то, о чем я написал в комментариях выше, а главное про то, что некоторые вендоры, особенно Китайцы, спецом ломают профиль, что бы видео нормально работало только в их клиентах. Я двух таких нашел, поток разбирал, смотрел каждый пакет, и искал в чем же косяк. Берут какой-то байт подменяют другим значением, из-за чего некорректно формируется профиль, условно говоря вместо hev1.2.3.e получается hev1.2.3.f — и вуаля, любой клиент говорит «я не знаю что это за кодек, воспроизвести не могу».
А в главном автор как раз ошибается. При одинаковых пресетах, и в одинаковых условиях (освещение, сцена и пр), две камеры разных производителей на одном и том же кодеке ведут себя вполне одинаково.
Не знаю, кто эти ребята что плюсуют ваши комментарии, видимо ваши друзья. Других объяснений этому поведению нет. Теперь по существу:
Не интересуют меня ваши субъективные ощущения. Приведите пруфы и цифры, а не ссылку на ютюб.
Вы прочитали статью, но не заметили, что добрая ее половина как раз об этом? Вы даже TL;DR пропустили, давайте напомню:
Дальше вы пишите:
Давайте приведу еще один отрывок из статьи, которую вы читали:
Интересно, что доступные скилы в Qwen Code пакуются в некие специальные XML директивы (назначение которых мне неизвестно), и отправляются как сообщение пользователя а не системы (что похоже на баг).
Как же вы статью то читали? Точнее какую? Эту точно нет.
В какую? Не в сторону ли инструмента, то есть CLI, о чем как раз вторая половина статьи? О том куда я копал, зачем, что изменил и какие результаты получил?
Пафос и демагогия.
Из ваших комментариев я могу сделать только один вывод: статью вы не читали.
А пруфы будут, или мы просто должны поверить вашей «практике»?
Отказывается работать, и игнорирует инструкции системного промпта – это совершенно разные вещи. Для агентских систем reasoning обязателен, и проведенный мной эксперимент это подтверждает. Имея описания минимум двух релевантных скилов, Qwen3 Coder Next неспособен прийти к выводу, что надо бы их использовать. То есть ему не хватает умений даже инструменты свои использовать, не говоря уже о выполнении комплексных, многоступенчатых задач.
Я принимаю код от агента, не потому что он мне нравится, а из-за кривизны инструментов, так как агенты печатают в консоль только часть изменений. Из-за этого приходится нажимать yes, а потом смотреть что он там нашкодил. Так что статистика эта бесполезная
Ухх… хорошо, что дело не в блокировках и отключении интернета.
Звучит как вечность. Есть какие-то примеры реальных измерений с дампами?
Факт))
Автор REST в своей диссертации , в которой он собственно представил REST, очень явно обосновывает свое решение ссылаясь на другую работу, ссылку на которую я также привел в статье. Суть архитектуры в том, что она явно обозначает ограничения которые должны быть соблюдены для достижения результата, при этом архитектура не диктует «как» реализовывать. Он пишет:
То есть stateless – не REST, а «коммуникация» между клиентом и сервером. Это в том числе вытекает из ограничений остальных компонентов системы, например транспорта. Каждый TCP пакет в последовательности должен содержать идентификатор соединения, каждый Request должен содержать идентификатор пользователя и т.д.
Тоже остается справедливым и для фронтенда, где каждый Request (Event), содержит всю необходимую информацию. Когда мы пишем
el.addEventListener('input', cb), браузер передает не просто строку с новым текстом, полагая что мы понимаем от какого именно<input />оно пришло, а Event со всей необходимой информацией, делая нашу «шину» stateless по природе.Что вы имеете ввиду, есть пример из других яп?
Имеется ввиду что map, filter и т.д. возвращают промисы? Это же принесет больше проблем, нет? Что если там девять элементов, и на обработке шестого произошла ошибка? Или например map отработал, а на reduce в третьем элементе произошла ошибка?
А для чего это может быть нужно? Что с ними делать?
Вы из какого года пишете?
Завезли почти десят лет назад
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/AsyncIterator
Никогда бы в голову не пришло, накручивать. Даже больше скажу, для меня, как автора, мне важно не количество, а от кого эти звезды.
Я как раз про нативную браузерную кнопку назад и писал, и да, она всегда делает ровно то, что должна.
В действительности как раз все так. Браузерная кнопка назад имеет предсказуемое и стабильно поведение.
А причем тут вообще роутер? Я про кнопку в браузере. Она уже есть, работает как надо, и ею пользуются. Вы же не делаете в интерфейсе адресную строку, чтобы пользователь вводит туда ссылки на ваш же сайт, а кнопку назад для чего делаете? Я этого не понимаю. Еще я ожидаю, что если она вдруг зачем-то есть, то работает также как в браузере, а в описанным вами сценарии это не так. Если я перешел на страницу товара сразу, например из результатов выдачи Гугла, то при нажатии назад, я хочу вернуться назад, то есть в результаты выдачи Гугла, а не на страницу с вашим каталогом которую я вовсе не посещал.
Еще ни одному ПО или дезигнеру не удалось меня заставить добавить в интерфейс кнопку «назад». Она уже есть в браузере. В любом. Битва продолжается)
Это больше миф. Не все видеокарты умеют декодировать этот кодек, и если у вас ни одно видео не работает, значит или вообще нет видеокарты, или она старая, или в браузере выключена настройка hardware acceleration.
Все современные браузеры этот кодек поддерживают (если железо его поддерживает), а прошлым летом его занесли даже в WebRTC.
Пы сы — сайт не мой.
Какая дичь. Что только не придумывают, лишь бы не признавать свое помешательство на иммутабельности.
Автор явно не работал с этим серьезно. Тогда бы он упомянул то, о чем я написал в комментариях выше, а главное про то, что некоторые вендоры, особенно Китайцы, спецом ломают профиль, что бы видео нормально работало только в их клиентах. Я двух таких нашел, поток разбирал, смотрел каждый пакет, и искал в чем же косяк. Берут какой-то байт подменяют другим значением, из-за чего некорректно формируется профиль, условно говоря вместо hev1.2.3.e получается hev1.2.3.f — и вуаля, любой клиент говорит «я не знаю что это за кодек, воспроизвести не могу».
А в главном автор как раз ошибается. При одинаковых пресетах, и в одинаковых условиях (освещение, сцена и пр), две камеры разных производителей на одном и том же кодеке ведут себя вполне одинаково.