Вот только если вы посмотрите на скриншот в комментарии выше (на которой и был дан ответ), то увидите, что там как раз-таки сервис gemini. И именно модель gemini-2.0-flash, которая не способна генерировать и редактировать изображения. О чём я и сообщил комментатору.
Пруфы того, что в сервисе gemini используется Imagen3 я предоставил. Если есть обратные пруфы - предоставьте пожалуйста (предлагаю не пропускать конструктивную часть диалога, как это сделал предыдущий комментатор).
Вас забанили в поисковике? Или может вы не видели на какой комментарий я отвечал изначально? Ещё раз повторю: на скриншоте - сервис gemini, и он использует imagen3. Если вам сложно разобраться в теме самому - то дарю вам пруф:
Не сложно, не так ли?
Знаю, в это сложно поверить, но сколько бы минусов вы не поставили под комментами, более правым вы от этого не станете.
На вашем скриншоте видно, что вы используете gemini. Gemini предоставляет не чистую модель, а модель + сервис, и использует под капотом Imagen3 чаще всего (но может использовать и другие модели, в зависимости от контекста (и, возможно, ещё какой скрытой логики)). aistudio в свою очередь предоставляет чистые модели, которые не генерирует картинки вовсе.
Как определил? Работаю с моделями gemini, как через api, так и напрямую в aistudio и gemini. Но и без этого никакой сложности в определении не вижу, если есть умения по использованию веб-поиска.
Нода с mcp клиентом неофициальная и никак не рекламится. Я тоже наткнулся только после того, как специально задался вопросом подключения парочки своих серверов к ассистенту на n8n.
Tequila Framework использует современный JavaScript (ES6+) без понижения версии и без строгой типизации TypeScript. Код остаётся в исходном виде, что делает его прозрачным, доступным и удобным в сопровождении
Может что не так понял, но впервые вижу, как отсутствие строгой типизации приводит к прозрачному, доступному и удобному в сопровождении коду)
Но вообще, подход выглядит довольно интересно и, думаю, будет иметь своё место для проектов на полтора разработчика (LLM + js'ер, и тут сами решайте, кто в таком подходе идёт за половину разработчика).
Есть n8n, и кастомная нода на работу с mcp для него. Инструмент довольно сильный, но со своими проблемами. Ну и, грубо говоря, это no-code платформа (не кидайтесь тапками). Гибкости меньше, чем хотелось бы, но агентов создавать получается очень быстро. Развернуть можно без проблем локально.
Там не так уж и давно стало можно и папки засовывать в контекст. Ну и в общем, в курсор самая гибкая система обогащения контекста (серьезно, там чего только нет). Плюс поиск и автоматическое обогащение контекста в последние месяцы стали лучше и работают достаточно хорошо сами по себе.
Там, у github copilot, вроде буквально сегодня должна была выйти версия 0.25, где обещали улучшить поиск по файлам и обогащение контекста (одна из двух основных причин превосходства курсора над ним). Но вообще, у него есть всякие интеграции из-под экосистемы гитхаб для интерпрайзов. Именно этим он привлекателен для команд. Но если нет большой команды, то, на мой взгляд, курсор в однозначных фаваритах.
Ключевых примера таких систем сейчас 3: Cursor Agent, Windsurf, Claude Code.
Всё же их больше. Github copilot, OpenHands, AIDE с sidecar'ом (который много где юзаетсся, кстати). И Claude code хоть и хайповый, но ключевым бы его не назвал.
Агенты развиваются быстро, очень быстро. Но всё равно в такие сроки я не верю. Скорее только через 3-5 лет агенты смогут решать задачи полостью самостоятельно. И то, скорее только в новых проектах, ибо разобраться в аде зависимостей множества легаси модулей любого бизнесового интерпрайза под силу только после принятия изрядной доли алкоголя (ИИ же ещё не научился бухать?). Да и то, это должны быть хорошо поставленные и описанные таски, созданные тем, кто полностью понимает кодовую базу и точно знает, какой результат хочет получить.
По сути, даже тогда ИИ не заменит программистов. Но вот облегчить работу и приблизить четырех дневную рабочую неделю (оптимист, ха-ха) будет вполне способен.
Это не агентский плагин. А вот агенты Cline/RooCode закрывают большую часть функционала Cursor, тот же MCP, например, там реализован давно (но закрывают не весь функционал, не спорю). Механику клона IDE с помощью расширения может сделать и нельзя, но концептуально аналогичного результата можно добиться и иным способом, пусть решение в основе своей и будет отличаться.
Пишу не как хейтер курсора. Я и сам в последние две недели перешёл на курсор со своей кастомной солянки из VSCode+RooCode+Continue. Ибо он стал куда лучше последние месяцы (4 месяца назад уже пробовал его и он на моих тасках выдавал результаты хуже, чем кастомная сборка).
Но и сейчас у него есть проблемы. И их не мало. И кое-где он проигрывает обычному агентскому расширению RooCode. Просто именно на данный момент инструмент на моих задачах оказался лучшим из опробованного. Однако в любой момент это может поменяться и вперёд выйдет другое решение.
Я делал сравнительный анализ трёх инструментов (cursor, github copilot, tabnine) для своей компании при работе на наших тасках и с нашей кодовой базой, и если интересно, могу привести результаты.
Если коротко, то курсор с небольшим отрывом победил github copilot (и RooCode, который для меня стоит на одной с ним ступеньке).
Хорошо выглядит. Структурированные данные - это полезно для LLM. Без них какие способы организации промптов не применяй, на выходе можно получить кашу.
Единственное, результат вашего решения на больших и средних по размеру кодовых базах современные модели не потянут, просто-напросто контекст порвётся. max_lines здесь всё же больше костыль, ибо модели пока не могут впихнуть в себя все сервисы даже какого-нибудь средненького интерпрайза.
Можно, конечно, попытаться оптимизировать ваш алгоритм и для методов выводить только их api (для примера) (У вас же только чистые методы? Ведь чистые?). Поработать над суммаризацией комментов или как ещё сократить количество данных без потери структуры и смысла.
Но возможно, лучшим решением будет иметь максимально сжатый основной пакет со структурой, правилами, типами, используемыми модулями и api методов и классов, а также векторную базу, соответствующую коду. И уже на шаге обогащения контекста по запросу юзать rag по этой базе (либо руками писать алгоритмы, либо попытаться отдельного агента под работу с rag настроить) и обогащать уже конкретным зависимым или как иначе связанным кодом.
Но это всё на уровне мыслей, может я вообще полную ахинею несу, ибо с rag почти не работал)
Да, надо, чтобы jira и confluence читал, подтягивал все зависимые доки, мог смотреть на соответствующие мокапы figma, знал API всех используемых сервисов и модулей, мог нормально следовать корпоративным стандартам в имплементации программных решений, и не терял контекст в сессии хотя бы из 15 пар запросов/ответов (для таски средней сложности с небольшим количеством зависимостей).
Вот только если вы посмотрите на скриншот в комментарии выше (на которой и был дан ответ), то увидите, что там как раз-таки сервис gemini. И именно модель gemini-2.0-flash, которая не способна генерировать и редактировать изображения. О чём я и сообщил комментатору.
Пруфы того, что в сервисе gemini используется Imagen3 я предоставил. Если есть обратные пруфы - предоставьте пожалуйста (предлагаю не пропускать конструктивную часть диалога, как это сделал предыдущий комментатор).
Вас забанили в поисковике? Или может вы не видели на какой комментарий я отвечал изначально? Ещё раз повторю: на скриншоте - сервис gemini, и он использует imagen3. Если вам сложно разобраться в теме самому - то дарю вам пруф:
Знаю, в это сложно поверить, но сколько бы минусов вы не поставили под комментами, более правым вы от этого не станете.
На вашем скриншоте видно, что вы используете gemini. Gemini предоставляет не чистую модель, а модель + сервис, и использует под капотом Imagen3 чаще всего (но может использовать и другие модели, в зависимости от контекста (и, возможно, ещё какой скрытой логики)). aistudio в свою очередь предоставляет чистые модели, которые не генерирует картинки вовсе.
Как определил? Работаю с моделями gemini, как через api, так и напрямую в aistudio и gemini. Но и без этого никакой сложности в определении не вижу, если есть умения по использованию веб-поиска.
Ничего себе, за правдивый коммент по делу, без негатива и оскорблений, получил минус в карму. Хабровская справедливость.
Это Imagen3, сам gemini 2.0 пока на такое не способен
Глаза у котов - это пока отдельный вид искусства:
MCP поддерживает, а вот построить мультиагентную систему не удастся (по крайней мере когда я щупал он ничего такого не умел).
Нода с mcp клиентом неофициальная и никак не рекламится. Я тоже наткнулся только после того, как специально задался вопросом подключения парочки своих серверов к ассистенту на n8n.
Может что не так понял, но впервые вижу, как отсутствие строгой типизации приводит к прозрачному, доступному и удобному в сопровождении коду)
Но вообще, подход выглядит довольно интересно и, думаю, будет иметь своё место для проектов на полтора разработчика (LLM + js'ер, и тут сами решайте, кто в таком подходе идёт за половину разработчика).
Есть n8n, и кастомная нода на работу с mcp для него. Инструмент довольно сильный, но со своими проблемами. Ну и, грубо говоря, это no-code платформа (не кидайтесь тапками). Гибкости меньше, чем хотелось бы, но агентов создавать получается очень быстро. Развернуть можно без проблем локально.
Там не так уж и давно стало можно и папки засовывать в контекст. Ну и в общем, в курсор самая гибкая система обогащения контекста (серьезно, там чего только нет). Плюс поиск и автоматическое обогащение контекста в последние месяцы стали лучше и работают достаточно хорошо сами по себе.
Такой код существует?
Тоже верно
Там, у github copilot, вроде буквально сегодня должна была выйти версия 0.25, где обещали улучшить поиск по файлам и обогащение контекста (одна из двух основных причин превосходства курсора над ним). Но вообще, у него есть всякие интеграции из-под экосистемы гитхаб для интерпрайзов. Именно этим он привлекателен для команд. Но если нет большой команды, то, на мой взгляд, курсор в однозначных фаваритах.
Полностью согласен. Использую точно такой же поход к использованию агентов и делю время работы надвое.
Самое страшное, что именно так и будет.
Почему страшное? Потому как потеряется оптимальность и консистентность (хотя о какой консистентности можно говорить в контексте ИИ?))
Всё же их больше. Github copilot, OpenHands, AIDE с sidecar'ом (который много где юзаетсся, кстати). И Claude code хоть и хайповый, но ключевым бы его не назвал.
Агенты развиваются быстро, очень быстро. Но всё равно в такие сроки я не верю. Скорее только через 3-5 лет агенты смогут решать задачи полостью самостоятельно. И то, скорее только в новых проектах, ибо разобраться в аде зависимостей множества легаси модулей любого бизнесового интерпрайза под силу только после принятия изрядной доли алкоголя (ИИ же ещё не научился бухать?). Да и то, это должны быть хорошо поставленные и описанные таски, созданные тем, кто полностью понимает кодовую базу и точно знает, какой результат хочет получить.
По сути, даже тогда ИИ не заменит программистов. Но вот облегчить работу и приблизить четырех дневную рабочую неделю (оптимист, ха-ха) будет вполне способен.
Это не агентский плагин. А вот агенты Cline/RooCode закрывают большую часть функционала Cursor, тот же MCP, например, там реализован давно (но закрывают не весь функционал, не спорю). Механику клона IDE с помощью расширения может сделать и нельзя, но концептуально аналогичного результата можно добиться и иным способом, пусть решение в основе своей и будет отличаться.
Пишу не как хейтер курсора. Я и сам в последние две недели перешёл на курсор со своей кастомной солянки из VSCode+RooCode+Continue. Ибо он стал куда лучше последние месяцы (4 месяца назад уже пробовал его и он на моих тасках выдавал результаты хуже, чем кастомная сборка).
Но и сейчас у него есть проблемы. И их не мало. И кое-где он проигрывает обычному агентскому расширению RooCode. Просто именно на данный момент инструмент на моих задачах оказался лучшим из опробованного. Однако в любой момент это может поменяться и вперёд выйдет другое решение.
Я делал сравнительный анализ трёх инструментов (cursor, github copilot, tabnine) для своей компании при работе на наших тасках и с нашей кодовой базой, и если интересно, могу привести результаты.
Если коротко, то курсор с небольшим отрывом победил github copilot (и RooCode, который для меня стоит на одной с ним ступеньке).
Хорошо выглядит. Структурированные данные - это полезно для LLM. Без них какие способы организации промптов не применяй, на выходе можно получить кашу.
Единственное, результат вашего решения на больших и средних по размеру кодовых базах современные модели не потянут, просто-напросто контекст порвётся. max_lines здесь всё же больше костыль, ибо модели пока не могут впихнуть в себя все сервисы даже какого-нибудь средненького интерпрайза.
Можно, конечно, попытаться оптимизировать ваш алгоритм и для методов выводить только их api (для примера) (У вас же только чистые методы? Ведь чистые?). Поработать над суммаризацией комментов или как ещё сократить количество данных без потери структуры и смысла.
Но возможно, лучшим решением будет иметь максимально сжатый основной пакет со структурой, правилами, типами, используемыми модулями и api методов и классов, а также векторную базу, соответствующую коду. И уже на шаге обогащения контекста по запросу юзать rag по этой базе (либо руками писать алгоритмы, либо попытаться отдельного агента под работу с rag настроить) и обогащать уже конкретным зависимым или как иначе связанным кодом.
Но это всё на уровне мыслей, может я вообще полную ахинею несу, ибо с rag почти не работал)
Да, надо, чтобы jira и confluence читал, подтягивал все зависимые доки, мог смотреть на соответствующие мокапы figma, знал API всех используемых сервисов и модулей, мог нормально следовать корпоративным стандартам в имплементации программных решений, и не терял контекст в сессии хотя бы из 15 пар запросов/ответов (для таски средней сложности с небольшим количеством зависимостей).
Что-то пока слишком многого хочу)