А как вы контролируете качество в своей работе — ревью глазами, тесты, вторая модель?
Ни то, ни другое ни третье. Я бы это назвал “парный вайб инжиниринг”. т.е. когда ты ждешь заврешения задачи и смотришь на код, но не как при ревью кода, а а как при ревью архитектуры без глубокого погружения в детали реализации и задаешь в диалоге вопросы по сомнительным местам. А модель либо переделывает, либо доказывает тебе, что именно так и должно быть, и ты соглашается с итоговым решением.
То есть получается сразу и постановка задачи и ревью кода и обсуждением архитектуры итогового решения (пока пользователь сам “в контексте”).
К сожалению, я не представляю можно ли автоматизировать такой процесс, потому что часто бывает, что верное и работающее решение (тесты проходят), на проверку оказывается очень кривим с точки зрения архитектуры, но проблема от него возникнет не сейчас, а в будущем. Т.е. на текущем этапе решение может быть и пойдет, но в будущем это архитектурный долг,.
У меня примерно такая же лабуда (24VRAM, 2x32 Core CPU, 256RAM и 1TB RAID0 на 4 ssd). Собрал пару-тройку лет назад, но так и продолжаю пользоваться провайдерами, т.к. работает быстрее, по суммарным затратам выходит дешевле (ненужно тратить время на поддержку хозяйства, его оптимизацию и ремонт) и постоянно ловить проблемы из-за нехватки размера контекста и долгого ожидания ответов при неспешной генерации на локальных моделях.
Тогда как основная проблема при работе с LLM, это не генерация и даже не оркестрация парка агентов, а контроль качества выдаваемого ими результата. Для обычного вайбкодинга пойдет любое решение, а вот для реальной работы нужно смотреть итоговый код.
И этого говорит человек, который пытался зарегистрировать термин Open Source в качестве торговой марки, а его OSI (Open Source Initiative) внесла в движение свободного ПО больше смуты, чем все остальные проприерасты вместе взятые.
Причем тут контракт, когда лицензия, это юридический документ не зависимо от ожидания или договоренностей?
А принимать патч или не принимать, с лицензией, да по большому счету и с открытостью, слабо связаны. Можно предложить патч или доработки и для проекта, у которого нет исходников в открытом доступе, так и полностью свободный проект может не принять патчи.
Другими словами, лицензия на проект, открытость его исходников и прием патчей / доработок, это вообще разные вопросы.
Вы путаете требования лицензии к обязательному открытию исходников и просто факт открытия исходников (под любой лицензией). И форкать можно, только если это позволяет лицензия, а не любой открытый исходный код.
В этом есть смысл для государства (тотальный контроль за движением). Это примерный аналог безналичной долларовой системы США, но на более современных принципах.
У всех есть отдельная тарификация кэшированных токенов
У провайдеров может быть и есть, но информация о кешированных токенах не отдается csv в отчете статистики запросов. Поэтому она есть как бы “виртуально”. То есть есть и можно получить при запросе по API, она есть в информации по конкретному запросу, но её НЕТ в итоговой статистике обработанных запросов.
Я отвечал про решение с WSL, а самим Mojo не пользуюсь и не собираюсь, поэтому про него ничего сказать не могу. Как по мне, то синтаксис моча это вообще полный шлак.
Ну как бы само использование термина “язык программирования” уже предполагает, что человек не обычный пользователь. Ладно бы это была бы игруха, тут да, я с вами соглашусь, заставлять пользователя ставить еще и Linux, это немного перебор.
Но для средств разработки отличное решение. Ну а если программист не может настроить себе WSL то может быть ему это не тук уж и нужно? :-)
И использование WSL никак не отменяет сборку нативных приложений. Для этого давно придумана кросс компиляция.
Они сломали хуки (у меня на них было делано хранение истории работы), но сейчас (в 4.11) пишут что и хуки починили. Сейчас я уже испопьзую 4.х версию без особых затруднений и без пересборки из исходников.
Ни то, ни другое ни третье. Я бы это назвал “парный вайб инжиниринг”. т.е. когда ты ждешь заврешения задачи и смотришь на код, но не как при ревью кода, а а как при ревью архитектуры без глубокого погружения в детали реализации и задаешь в диалоге вопросы по сомнительным местам. А модель либо переделывает, либо доказывает тебе, что именно так и должно быть, и ты соглашается с итоговым решением.
То есть получается сразу и постановка задачи и ревью кода и обсуждением архитектуры итогового решения (пока пользователь сам “в контексте”).
К сожалению, я не представляю можно ли автоматизировать такой процесс, потому что часто бывает, что верное и работающее решение (тесты проходят), на проверку оказывается очень кривим с точки зрения архитектуры, но проблема от него возникнет не сейчас, а в будущем. Т.е. на текущем этапе решение может быть и пойдет, но в будущем это архитектурный долг,.
У меня примерно такая же лабуда (24VRAM, 2x32 Core CPU, 256RAM и 1TB RAID0 на 4 ssd). Собрал пару-тройку лет назад, но так и продолжаю пользоваться провайдерами, т.к. работает быстрее, по суммарным затратам выходит дешевле (ненужно тратить время на поддержку хозяйства, его оптимизацию и ремонт) и постоянно ловить проблемы из-за нехватки размера контекста и долгого ожидания ответов при неспешной генерации на локальных моделях.
Тогда как основная проблема при работе с LLM, это не генерация и даже не оркестрация парка агентов, а контроль качества выдаваемого ими результата. Для обычного вайбкодинга пойдет любое решение, а вот для реальной работы нужно смотреть итоговый код.
Делать не то, что хочется или лучше всего получатся, а то, что реально нужно :-)
И какой размер контекста
У вас что, нет LLM ?
И этого говорит человек, который пытался зарегистрировать термин Open Source в качестве торговой марки, а его OSI (Open Source Initiative) внесла в движение свободного ПО больше смуты, чем все остальные проприерасты вместе взятые.
Увы нет. С вашими буквами это вообще никак не связано.
Причем тут контракт, когда лицензия, это юридический документ не зависимо от ожидания или договоренностей?
А принимать патч или не принимать, с лицензией, да по большому счету и с открытостью, слабо связаны. Можно предложить патч или доработки и для проекта, у которого нет исходников в открытом доступе, так и полностью свободный проект может не принять патчи.
Другими словами, лицензия на проект, открытость его исходников и прием патчей / доработок, это вообще разные вопросы.
Вы путаете требования лицензии к обязательному открытию исходников и просто факт открытия исходников (под любой лицензией). И форкать можно, только если это позволяет лицензия, а не любой открытый исходный код.
А без мобильного приложения банка?
В этом есть смысл для государства (тотальный контроль за движением). Это примерный аналог безналичной долларовой системы США, но на более современных принципах.
У провайдеров может быть и есть, но информация о кешированных токенах не отдается csv в отчете статистики запросов. Поэтому она есть как бы “виртуально”. То есть есть и можно получить при запросе по API, она есть в информации по конкретному запросу, но её НЕТ в итоговой статистике обработанных запросов.
Вы какой язык пытаетесь улучшить C, C++? И улучшить в чем? Синтаксис, скорость, безопасность, совместимость или что-то еще?
А можно еще круче.
Сделать новый язык программирования и запускать его под второй ос под wsl :-)
Я отвечал про решение с WSL, а самим Mojo не пользуюсь и не собираюсь, поэтому про него ничего сказать не могу. Как по мне, то синтаксис моча это вообще полный шлак.
Ну как бы само использование термина “язык программирования” уже предполагает, что человек не обычный пользователь. Ладно бы это была бы игруха, тут да, я с вами соглашусь, заставлять пользователя ставить еще и Linux, это немного перебор.
Но для средств разработки отличное решение. Ну а если программист не может настроить себе WSL то может быть ему это не тук уж и нужно? :-)
И использование WSL никак не отменяет сборку нативных приложений. Для этого давно придумана кросс компиляция.
Выглядит идеально! Под виндой запускается и работает, а за совместимость WSL с масдаем отвечает сам MIcrosoft.
А в 4.11 эту проблему уже поправили. Теперь уже можно не собирать :-)
Они сломали хуки (у меня на них было делано хранение истории работы), но сейчас (в 4.11) пишут что и хуки починили. Сейчас я уже испопьзую 4.х версию без особых затруднений и без пересборки из исходников.
В текущая версии (начиная где то с 4.5) этот баг был поправлен и теперь контекст не режется и работает по полной.