Comments 29
Фактически создан агент "Go-coder". Может быть, если выделить отдельно "Go-tester", то будет еще лучше.
разрешите поинтересоваться, а в чем в (общем и) целом смысл?
если вы устали от рутины шлепать однотипные сервисы - может быть проблема в архитектуре?
если цель это экономия времени - вы действительно выпускаете в прод то что llm написало, само “протестировало” и сказало “я сделаль” без детального ревью и сотен “u did a bulshit, coz … and … should be …”
если llm пишет код лучше чем тот, кто её использует, то (токсичный текст тут был замечен НЛО и удален)
нет, вы не подумайте, ваш покорный не из лагеря “llm-на-вилы”, сам пользуюсь каждый день, но с оговоркой - только для ревью написанного кода (руками), перевода текста с ну-понятно-но-коряво на православно-английский и изредка траблшутинга (понять какого хрена контекст отменился где-то где не надо в реально сложной цепочке, или пошукать в тернистой SDK или объемной доке подсказки).
я правда пытаюсь понять - зачем?
На мой взгляд для 80% задач продуктовой разработки писать код руками не имеет смысла из-за низкой эффективности. LLM пишет быстрее и качественнее если достаточный контекст и описание задачи.
Отвечая на ваш вопрос - конечно код сгенерированный LLM уже давно работает в продакшене.
Потому что логично все делать единообразно. А аргументы "мужики едят шашлык руками" не логичны.
Я пробовал как хобби в формате:
1. Спроектируй такую фичу -> маленькая модель
2. Напиши замечания -> ChatGPT
3. Исправь замечания -> маленькая модель
4. 2-3 итерации
5. Реализуй -> маленькая модель
По факту какие я сделал выводы:
Как агенты модели могут допускать серьёзные огрехи, например у меня в режиме Ask редактировал код без предупреждения, модифицировал системный питон с флагом --break-system(без него в питоне стояла защита от этого) и т. д.
Маленькая модель может игнорировать инструкции. Например, по плану мы сошлись на то, что нужно добавить haptic feedback, у модели с ходу не получилось, она не добавила, а по фактуотписала, что всё сделала
Своеволие. Например, попросил внести изменения, модель внесла, попросил поправить варнинги(в том числе, которые висят давно) - модель сделала git stash, проверила варнинги и отказалась делать, мол это было до меня.
Или такой кейс. И часто это "я не буду этого делать" лечится только перезапуском сессии.
Пытался сделать 2 приложения, которые должны были интегрироваться. Интеграция не заработала. Запустил 2-х агентов. Одного для одного проекта, другого - для другого. Так они друг на друга гнали, мол у меня всё ок, смотри что в другом проекте.Ну и не получилось до сих пор у меня приучить ни локальные, ни платные модели к хорошему коду. Если модель сделает большой кусок проекта, а потом что-то не сможет пофиксить, то нужно лезть самому. А там, как правило, что-то трудное для понимания. И поэтому когда в приложении баг, из-за которого им невозможно пользоваться, приходится сначала делать рефакторинг практически в ручном режиме и потом уже искать ошибку.
И главное, что хороший план в этой ситуации не помогал мне избежать этого всего. План был достаточно подробный, со структурой проекта, примерами кода и т. д.
План можно и самому наклепать и задачи поставить. Кстати кто-то кодил с 27B последней версией? Которая 3.6
На такое железо можно qwen 3.6-35b-a3b поставить Q5.
По мне правильная бесплатная разработка, это обсуждаешь проект, архитектуру, включая содержание модулей go, на облачной модели, крайне желательно того же семейства что и локальная. А локальной потом куски допиливаешь, тесты, отладки, когда в облачную надоест копировать логи, ошибки и и.т.д.
А вот не нашел такую, которая бы помещалась в GPU полностью и место хватала для нормального контекста + тулы. Если подскажите где такую скачать для LM Studio будут благодарен.
https://habr.com/ru/articles/1026482/
Спасибо, но 42 токена/сек и контекст 65 536 не подходят для реальной агентной работы. Контекст нужен минимум 150 тыс иначе ничего хорошего не выйдет, будет постоянно в него упираться.
С Qwen 3.5 получается скорость генерации 120 токенов в секунду и контекст 200K.
У меня больше t/c получалось, там на 12Г у меня 16Г , а насчет контекст 200K.
Модель Qwen 3.5 9B поддерживает нативный контекст в 262 144 токена (с возможностью расширения до 1 млн). При этом, как и большинство современных LLM на архитектуре Transformer, она сталкивается с эффектом «потерянного в середине» (Lost in the Middle) — наибольшую точность показывают начало и конец промпта, а середина длинного контекста может игнорироваться. [1]
Для наглядности, вот главные особенности работы 9-миллиардной модели Qwen с длинным контекстом:
⚡ Ключевые аспекты
Окно памяти: До 262 144 токенов «из коробки». [1]
Архитектурная особенность: Модель имеет тенденцию пересчитывать промпт при каждом новом повороте диалога. Без оптимизаций это может приводить к долгим ожиданиям при загрузке больших текстов. [1]
Потери в середине (Lost in the Middle): Как и другие LLM, модель склонна забывать факты, спрятанные в середине длинного документа. Ключевые инструкции или термины лучше дублировать в начале и конце большого текста.
Я запускаю qwen3.6-35 q4 на стареньком ноуте асус с амд процом и мобильной ненавидиа на 6гб vram. 25-30 т/с и контекст 120к. Секрет - выгрузка мое в оперативку
Поддерживаю. Сделал на таком подходе недавно проект с использованием дипсика веб интерфейс и его апи для агента.
Одно не пойму, почему при наличии новых моделей люди упорно лезут что-то делать на старье и не самом лучшем? Специально для того чтобы сказать фу локальный модели ничего не могут и агетировать за платные модели?
Qwen 3.5 довольно старая по меркам моделей и к тому же очень плохо работает с тулзами.
Даже Gemma 4 будет лучше, молчу уже про Qwen 3.6.
Qwen 3.6 35/27b вообще отличная модель получилась, она очень хорошо делает все, от планирования до конечного проекта с тестами и сборкой.
Подскажите:
Как сам процесс проходил, есть какие-то циклические этапы, как, например, plan -> implements -> test -> review?
Сколько по времени от старта до конечного результата прошло времени и есть ли понятие, за какое время вы бы сами вручную реализовали этот функционал.
Какая трудоемкость подготовить среду для процесса, который вы описали.
Была ли попытка использовать методологии SDD
1) Создана подробная спецификация сервиса и разбито на задачи
скелет проекта, домен, password и JWT
сервисный слой и fake repository tests
HTTP API, middleware и handler tests
PostgreSQL repository, config и миграции
Dockerfile, Docker Compose и запуск всех зависимостей
Каждая задача это отдельная сессия, все сессии идут последовательно. После каждой задачи смотрел что он сделал все верно.
2) Сервисы реализован в течении дня между делом, чистого времени работы агента около 1-1,5 часа Руками писать 1-2 дня
3) У меня уже все было установлено, поэтому сложно оценить.
4) По сути так и было в простом варианте - Бизнес описание сервиса, план реализации и описание каждой задачи все в .md файлах в проекте.
А почему эта модель? На ваших спеках можно новую Qwen3.6 35B A3B запустить и она будет значительно лучше
Upd: прочитал ваши ответы, понял что глупый вопрос, игнорируйте пожалуйста.
Как то пришел к тому что всегда сложные задачи разделяю на этап "напиши план" и "реализуй план". Даже если план будет писать не более дорогая модель а та же самая что будет делать, все равно результат лучше (ну и план можно/нужно проверить и исправить). Ну и даже большие дорогие модели вроде опуса лажают если им просто скормить проект и сказать "делай". Всегда лучше делать план, имхо
Как развернуть модель локально?
Установить программу https://lmstudio.ai/ скачать модель qwen/qwen3.5-9b установив GPU Offload на максимум и Context Length на 200K.
Далее подключить в opencode так https://opencode.ai/docs/ru/providers/#lm-studio
Эксперимент с локальной Qwen на Go-сервисе