Почему автору поставили минусы? Возможно, «я пиарюсь» было бы более подходящим тегом статьи.
Думаю, автору стоило бы рассказать о «300 секретах»: как он их создавал с помощью LLM. Мне и другим читателям было бы интересно об этом узнать.
Бегло глянул проект https://github.com/comerc/budva43. На мой взгляд и субъективный, впечатление, что нет понятной принятой в Go структуры проектов, как, например, https://github.com/golang-standards/project-layout, и на первый взгляд выглядит как беспорядочные папки и с проблемными неймингами. И типичные проблемы с repo, с функционалом который не должен быть по определению в патерне Repository.
Спасибо, что напомнили о Kitty. Прочитав статью, вспомнил, что хотел его себе установить. Поставил, настроил, и всё, что надо для меня, в нем есть. Жалко, что переход в режим выделения клавишами нативно не работает и надо ставить хелпер.
Если кто не знал, но на го тоже есть много утилит. Вот, например, я вместо МС использую после "допиливания" под себя https://github.com/gokcehan/lf. А в общем TUI интерфейсы мне нравятся.
На практике важно правильно разбить задачу на более мелкие части (декомпозировать) и сформулировать требования. В большинстве случаев (но не всегда) это приводит к нужному результату или с небольшими проблемами. Это похоже на то, что происходит в реальной жизни, но здесь есть проблема с формулировками и уровнем дробления. Думаю, с опытом у людей появятся методики для такой техники. И да чтобы проверять результат ЛЛМ уже надо иметь определенный уровень подготовки.
Да, становится очень удобно рутину скидывать на «болванчика» и остается правильно формулировать задачи и проверять результат. Я таким образом свой пет проект делаю и пока результатом доволен.
Спасибо за статью. Не указано, какие тесты используем? Unit или какие-то другие? Mockery позволяет использовать тип Anything и это реально помогает некоторые параметры не принимать в тесте, если они не нужны для конкретного кейса, например context. Кстати, если бы в методах был бы сквозной ctx (context.Context) как аргумент, вызов асинхронного метода был бы простой в тесте с отменой.
Почему автору поставили минусы? Возможно, «я пиарюсь» было бы более подходящим тегом статьи.
Думаю, автору стоило бы рассказать о «300 секретах»: как он их создавал с помощью LLM. Мне и другим читателям было бы интересно об этом узнать.
Бегло глянул проект https://github.com/comerc/budva43. На мой взгляд и субъективный, впечатление, что нет понятной принятой в Go структуры проектов, как, например, https://github.com/golang-standards/project-layout, и на первый взгляд выглядит как беспорядочные папки и с проблемными неймингами. И типичные проблемы с repo, с функционалом который не должен быть по определению в патерне Repository.
Интересная история.
А ide какую использовали vscode + plugin, Сursor IDE или еще какой то способ?
Спасибо, отличный проект. Экспериментировали ли с локальными моделями для генерации музыки или речи?
почему не писать команды уровня проекта сразу на го?
https://magefile.org/
История не из этой серии?
спасибо, а то этих opencode развелось)
Внезапно
Но как понимаю просто переехал https://github.com/charmbracelet/crush
Спасибо, что напомнили о Kitty. Прочитав статью, вспомнил, что хотел его себе установить. Поставил, настроил, и всё, что надо для меня, в нем есть. Жалко, что переход в режим выделения клавишами нативно не работает и надо ставить хелпер.
Я пока себе такую присмотрел https://ru.ergohaven.xyz/shop/tproduct/767494027-849612784162-velvet-v3-ui-edition и, возможно, потом попробую собрать такую же, как у автора, с уже пониманием, что мне нужно.
Спасибо, давно искал, чтобы было что-то типа awesome-llm.
Спасибо за доклад, полезно и все в одном месте.
Если кто не знал, но на го тоже есть много утилит. Вот, например, я вместо МС использую после "допиливания" под себя https://github.com/gokcehan/lf. А в общем TUI интерфейсы мне нравятся.
По верхам пробежался, впечатление, что репозиторий школьника, но, возможно, я ошибаюсь.
Да, задумка и реализация интересная. Нет ли риска, что что-то зловредное сделает, например, с личного кабинета банка переведет деньги куда-нибудь?
На практике важно правильно разбить задачу на более мелкие части (декомпозировать) и сформулировать требования. В большинстве случаев (но не всегда) это приводит к нужному результату или с небольшими проблемами. Это похоже на то, что происходит в реальной жизни, но здесь есть проблема с формулировками и уровнем дробления. Думаю, с опытом у людей появятся методики для такой техники. И да чтобы проверять результат ЛЛМ уже надо иметь определенный уровень подготовки.
Да, становится очень удобно рутину скидывать на «болванчика» и остается правильно формулировать задачи и проверять результат.
Я таким образом свой пет проект делаю и пока результатом доволен.
Возможно ли поставить эту ОС на свое железо или купить домой девайс с ней?
Спасибо за статью. Интересно было бы подобное на Zig под RISC-V почитать.
Спасибо за статью.
Не указано, какие тесты используем? Unit или какие-то другие?
Mockery позволяет использовать тип Anything и это реально помогает некоторые параметры не принимать в тесте, если они не нужны для конкретного кейса, например context.
Кстати, если бы в методах был бы сквозной ctx (context.Context) как аргумент, вызов асинхронного метода был бы простой в тесте с отменой.
Думаю, что когда LLM сможет ясно сообщить, что она не знает ответа на поставленный вопрос, это должен быть следующий этап в их развитии.