Нода с 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 пар запросов/ответов (для таски средней сложности с небольшим количеством зависимостей).
Не увидел название моделей, с которыми идёт сравнение.
Откровенно говоря, не совсем понимаю смысла сравнения отдельной модели с сервисами-агрегаторами, которые в большинстве своем ещё и сами рефайнят промпты.
Раз нужно было что-то написать, чтобы вставить пять ссылок на свой сервис, то можно было и более глубоко погрузиться в тему. Тогда и проплаченные автоматические +10 к статье бы не понадобились.
Так никто и не говорит про человеческий интеллект.
Отчего-то многие вкладывают в слово "интеллект" (в контексте ИИ) его прямой первоначальный смысл. Хотя слово "искусственный" однозначно искажает этот смысл.
Artificial Intelligence (он же Искусственный Интеллект (на русском одним словом не написать по-другому), или я перестал понимать английский?) - уже устоявшееся словосочетание и имеет свой собственный смысл. Который нет необходимости так упорно примерять к первоначальному смыслу слова "интеллект".
Ну, у gemini по 1.5к запросов в день на модель (юзабельных там 4 по сути). Ну и в минуту тоже ограничения есть. Но для пет проектов или домашнего использования вполне хватает. Я тоже в качестве баловства с телегой интегрировался, но реализовывал на python. Модели gemini использовал сначала потому как хорошие лимиты, а потом и вовсе корпоративный доступ появился к ней.
Единственное, модели 1.5 очень уж непросто заставить нормально следовать инструкциям. Благо в 2.0 стало проще.
Выглядит, на первый взгляд, очень даже хорошо. Возможность простого построения графов и пайплайнов агентских взаимодействий - выглядит как ниша в которой мы точно ожидаем развития в ближайшем будущем.
Хоть я и предпочту делать агентские системы самостоятельно (благо инструментария уже достаточно) под конкретные задачи. Но это не умоляет достоинств вашей платформы.
Нода с 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 пар запросов/ответов (для таски средней сложности с небольшим количеством зависимостей).
Что-то пока слишком многого хочу)
Не увидел название моделей, с которыми идёт сравнение.
Откровенно говоря, не совсем понимаю смысла сравнения отдельной модели с сервисами-агрегаторами, которые в большинстве своем ещё и сами рефайнят промпты.
Раз нужно было что-то написать, чтобы вставить пять ссылок на свой сервис, то можно было и более глубоко погрузиться в тему. Тогда и проплаченные автоматические +10 к статье бы не понадобились.
Так никто и не говорит про человеческий интеллект.
Отчего-то многие вкладывают в слово "интеллект" (в контексте ИИ) его прямой первоначальный смысл. Хотя слово "искусственный" однозначно искажает этот смысл.
Artificial Intelligence (он же Искусственный Интеллект (на русском одним словом не написать по-другому), или я перестал понимать английский?) - уже устоявшееся словосочетание и имеет свой собственный смысл. Который нет необходимости так упорно примерять к первоначальному смыслу слова "интеллект".
Ну, у gemini по 1.5к запросов в день на модель (юзабельных там 4 по сути). Ну и в минуту тоже ограничения есть. Но для пет проектов или домашнего использования вполне хватает. Я тоже в качестве баловства с телегой интегрировался, но реализовывал на python. Модели gemini использовал сначала потому как хорошие лимиты, а потом и вовсе корпоративный доступ появился к ней.
Единственное, модели 1.5 очень уж непросто заставить нормально следовать инструкциям. Благо в 2.0 стало проще.
У gemini есть своё API, не под VertexAI, с бесплатными ключами. Ключи можно прямо из-под aistudio.google.com завести.
Возможно я покажусь дураком, но разве ответ DeepSeek (18) не является верным? Пересчитал несколько раз и не могу найти ошибку.
Выглядит, на первый взгляд, очень даже хорошо. Возможность простого построения графов и пайплайнов агентских взаимодействий - выглядит как ниша в которой мы точно ожидаем развития в ближайшем будущем.
Хоть я и предпочту делать агентские системы самостоятельно (благо инструментария уже достаточно) под конкретные задачи. Но это не умоляет достоинств вашей платформы.
Четыре пальца есть? Есть!