Помимо спецификаций в таком подходе должны быть прописаны четкие правила написания кода (хотя бы конфиг линтера и форматтера) и подходов к реализации функционала. Описаны паттерны и антипаттерны. Общая архитектура. А также необходим артефакт, содержащий пополняемый список переиспользуемых модулей.
Иначе при вашем подходе у вас будет 127 черных ящиков, внутри которых можно будет часто встретить одинаковый, но не вынесенный функционал, разный код-стайл, разные подходы к чтению, валидации и обработке входных данных и тд.
Привести к единому стилю такие ящики будет довольно сложно. Либо можно этого не делать, но тогда, когда (а не если) что-то пойдет не так, отладить взаимодействие модулей будет достаточно трудоемкой задачей.
Gemini позиционирует свои модели как модели с большим контекстом, но в агентском режиме он размывается просто влёт. Забито только 60-80к контекста, а модель уже перестаёт помнить, что именно попросили, делает то, что не просили, меняет то, что её не касается, подгоняет размышления под результат и список можно продолжать.
Но! На мелких задачах, оторванных от сложной бизнес-логики она (3 - 3.1 pro) зачастую показывает себя лучше, чем даже opus 4.5 и gpt-5.3-codex. И это "лучше" чаще всего касается оптимизации кода и код-стайла проекта.
Для грубого примера, в чем бывает лучше: в ts файле прошу добавить логику сопоставления прав и доступных ресурсов. И opus с codex начинают писать мне if'ы и switch'и в немалых масштабах и почти всё в одной функции. Gemini же делает нормальный типизированный маппинг, затем везде, где это возможно обращается к элементам по ключу, использует set'ы, выделяет относительно сложную логику в отдельные функции, использует каррирование. Да, частично я сам виноват, что не добавил правила написания хорошего кода и правила работы с проектом в их контекст или где-то в проекте, где бы модели могли их взять. Но, согласитесь, они все должны по умолчанию писать таким образом и делать иначе только если есть запрос на говнокод.
Что касается последних opus и sonnet - ну это любимые модели: держат контекст, помнят что ты хотел изначально и сверяются с этим в процессе реализации фич. Хорошо проектируют среднеуровневую архитектуру и дают неплохие советы по общей архитектуре сервиса и межсервисных взаимодействий. Замечают проблемы чаще всего заранее. Могут сказать (в отличие от всех остальных), что твои запросы в начале и в середине конфликтуют между собой и надо что-то решать. Когда хорошо их настаиваешь и даёшь им субагентов на gemini 3.1 pro для реализации минимальных независимых частей, а их самих просишь писать все места межмодульных и межкомпонентных взаимодействий, то эта связка уже куда больше походит на по-настоящему рабочий инструмент.
Ну и codex - факт-чекинг действительно их сильная сторона, старается делать его без подсказок, но зачастую делает лишнее, хуже себя чувствует в архитектуре и проектировании, а потом в процессе реализации может что-то добавить, так как ему вот прям сейчас будет легче так сделать. Контекст держит относительно неплохо, но на сложных задачах начинает противоречить самому себе (его же план и его реализация у него зачастую не совпадают). Зато спеки реализует хорошо и быстро - не задумывается, как opus, ища архитектурные несостыковки, а просто делает, даже если в общем это противоречащие друг другу куски.
Есть несколько довольно хороших, не считая всякий нерабочий в агентском режиме мусор. А также есть агрегирующий "openrouter/free" (который по большому счёту справляется со своей ролью заглушки, когда есть проблемы с остальными моделями).
По тому, что нормально, а что нет в использовании моделей у всех разные представления. Кому-то важна задержка и скорость, а в каком-нибудь сервисе генерации текстов в фоновом режиме вообще без разницы, лишь бы тулы вызывались и качество было подходящее.
Плюс минус всё так, если без нюансов. Только тот же gpt-5.3 сейчас также хорош в агентском режиме, как и opus-4.6. Да и qwen3 с gemini 3 pro хоть и отстают, но с правильным контекстом и промптомагенты на них тоже уже вполне хороши, особенно в простых/средних по сложности повседневных задачах.
Так ведь скилл вполне позволяет добавить конкретную директиву на создание базы данных при первом запросе к скиллу. Если честно, не вижу тут принципиальных ограничений. Наоборот не будет никаких внешних надстроек к боту, которые нужно отдельно руками разворачивать.
Вот тоже не могу представить как в неконтролируемой среде получить таких специалистов, ибо они из ниоткуда не берутся. А тут мы просто лишаемся в отросли middle и junior этапов.
Выглядит так, что на какое-то время говнокода и сомнительных архитектурных решений в проектах станет на порядок больше. (Не хочу сказать, будто сейчас их не хватает).
Думаю, у большинства нормальных сервисов происходит определение языка на лету и подключение соответствующей дообученой модели как раз для этого конкретного языка (для виспера, кстати, тоже есть несколько ру-моделей на huggingface). Такой подход избавляет от большинства проблем. Мультиязычные модели пока не способны выдавать то же качество, что и дообученные (что не удивительно)
На счёт python не скажу, но на фронте при миграции фреймворков vue и react на новые мажорные версии справляется достаточно хорошо (с react вообще за одну итерацию с 18-ой на 19ую, с vue за три-четыре, но там и посложнее миграция). Но тут ещё и от агента зависит и от того как он настроен. Да и от размера проекта: какие-то небольшие можно целиком перенести, какие-то только частями.
Ограничение на длину/частоту публикации генерированного контента? Заставлять авторов рендерить не выше 720 все эти переставляющиеся статичные кадры и наезды камеры на фотографии?
Решение этой проблемы уже давно придумано и реализовано. В будущем именно web3 сети станут основой интернета. Хорошо ли это? Это уже другой вопрос.
Но со временем переход на него произойдет в любом случае, ибо информационная инфляция обгоняет возможности по обработке информации и расширению хранилищ web2 сети (и да, в первую очередь из-за сгенерированого ИИ контента).
Это да, лишняя морока. Но варианты для оплаты есть и их не мало, потому не вижу в этом особой проблемы (сам на данный момент пользуюсь услугами какого-то селлера с плати ру, раньше корпоративной зарубежной картой расчитывался)
Наконец-то статья не в стиле "Cursor - это волшебная палочка и делает всё за меня" или "Cursor - нерабочее г**** и не работает вообще".
Спасибо за изученные и описанные детали реализации инструмента. Особенно за нюанс с конкатенацией правил (это заставило меня просмотреть свои файлы правил на предмет того, нет ли такой же проблемы у меня).
У cursor не один уровень вложенности запуска субагентов. И вроде уже недели 3 как.
Помимо спецификаций в таком подходе должны быть прописаны четкие правила написания кода (хотя бы конфиг линтера и форматтера) и подходов к реализации функционала. Описаны паттерны и антипаттерны. Общая архитектура. А также необходим артефакт, содержащий пополняемый список переиспользуемых модулей.
Иначе при вашем подходе у вас будет 127 черных ящиков, внутри которых можно будет часто встретить одинаковый, но не вынесенный функционал, разный код-стайл, разные подходы к чтению, валидации и обработке входных данных и тд.
Привести к единому стилю такие ящики будет довольно сложно. Либо можно этого не делать, но тогда, когда (а не если) что-то пойдет не так, отладить взаимодействие модулей будет достаточно трудоемкой задачей.
Тогда тоже поделюсь, со стороны разработчика:
Gemini позиционирует свои модели как модели с большим контекстом, но в агентском режиме он размывается просто влёт. Забито только 60-80к контекста, а модель уже перестаёт помнить, что именно попросили, делает то, что не просили, меняет то, что её не касается, подгоняет размышления под результат и список можно продолжать.
Но! На мелких задачах, оторванных от сложной бизнес-логики она (3 - 3.1 pro) зачастую показывает себя лучше, чем даже opus 4.5 и gpt-5.3-codex. И это "лучше" чаще всего касается оптимизации кода и код-стайла проекта.
Для грубого примера, в чем бывает лучше: в ts файле прошу добавить логику сопоставления прав и доступных ресурсов. И opus с codex начинают писать мне if'ы и switch'и в немалых масштабах и почти всё в одной функции. Gemini же делает нормальный типизированный маппинг, затем везде, где это возможно обращается к элементам по ключу, использует set'ы, выделяет относительно сложную логику в отдельные функции, использует каррирование. Да, частично я сам виноват, что не добавил правила написания хорошего кода и правила работы с проектом в их контекст или где-то в проекте, где бы модели могли их взять. Но, согласитесь, они все должны по умолчанию писать таким образом и делать иначе только если есть запрос на говнокод.
Что касается последних opus и sonnet - ну это любимые модели: держат контекст, помнят что ты хотел изначально и сверяются с этим в процессе реализации фич. Хорошо проектируют среднеуровневую архитектуру и дают неплохие советы по общей архитектуре сервиса и межсервисных взаимодействий. Замечают проблемы чаще всего заранее. Могут сказать (в отличие от всех остальных), что твои запросы в начале и в середине конфликтуют между собой и надо что-то решать. Когда хорошо их настаиваешь и даёшь им субагентов на gemini 3.1 pro для реализации минимальных независимых частей, а их самих просишь писать все места межмодульных и межкомпонентных взаимодействий, то эта связка уже куда больше походит на по-настоящему рабочий инструмент.
Ну и codex - факт-чекинг действительно их сильная сторона, старается делать его без подсказок, но зачастую делает лишнее, хуже себя чувствует в архитектуре и проектировании, а потом в процессе реализации может что-то добавить, так как ему вот прям сейчас будет легче так сделать. Контекст держит относительно неплохо, но на сложных задачах начинает противоречить самому себе (его же план и его реализация у него зачастую не совпадают). Зато спеки реализует хорошо и быстро - не задумывается, как opus, ища архитектурные несостыковки, а просто делает, даже если в общем это противоречащие друг другу куски.
То есть вы решили эту проблему вставкой между моделью и поиском ещё одной модели и считаете, что ваш подход лучше, чем описанный в статье?
Если так, то вы истинный вайб-кодер.
Есть несколько довольно хороших, не считая всякий нерабочий в агентском режиме мусор. А также есть агрегирующий "openrouter/free" (который по большому счёту справляется со своей ролью заглушки, когда есть проблемы с остальными моделями).
По тому, что нормально, а что нет в использовании моделей у всех разные представления. Кому-то важна задержка и скорость, а в каком-нибудь сервисе генерации текстов в фоновом режиме вообще без разницы, лишь бы тулы вызывались и качество было подходящее.
Наличие бесплатных моделей в табличку добавте
Плюс минус всё так, если без нюансов. Только тот же gpt-5.3 сейчас также хорош в агентском режиме, как и opus-4.6. Да и qwen3 с gemini 3 pro хоть и отстают, но с правильным контекстом и промптомагенты на них тоже уже вполне хороши, особенно в простых/средних по сложности повседневных задачах.
Так ведь скилл вполне позволяет добавить конкретную директиву на создание базы данных при первом запросе к скиллу. Если честно, не вижу тут принципиальных ограничений. Наоборот не будет никаких внешних надстроек к боту, которые нужно отдельно руками разворачивать.
Или я что-то не так понял? Я могу и ошибаться)
Выглядит очень здорово. А может на github это всё вместе со скиллом оформить? Сразу готовый вариант и можно на clawhub выложить.
Тогда уж по вавилонской библиотеке. И менять представление нет необходимости.
Вот тоже не могу представить как в неконтролируемой среде получить таких специалистов, ибо они из ниоткуда не берутся. А тут мы просто лишаемся в отросли middle и junior этапов.
Выглядит так, что на какое-то время говнокода и сомнительных архитектурных решений в проектах станет на порядок больше. (Не хочу сказать, будто сейчас их не хватает).
Семь красных перпендикулярных метрик, две из них зелёные, а две прозрачные и одна в форме котика
Думаю, у большинства нормальных сервисов происходит определение языка на лету и подключение соответствующей дообученой модели как раз для этого конкретного языка (для виспера, кстати, тоже есть несколько ру-моделей на huggingface). Такой подход избавляет от большинства проблем. Мультиязычные модели пока не способны выдавать то же качество, что и дообученные (что не удивительно)
Токены закончились
На счёт python не скажу, но на фронте при миграции фреймворков vue и react на новые мажорные версии справляется достаточно хорошо (с react вообще за одну итерацию с 18-ой на 19ую, с vue за три-четыре, но там и посложнее миграция). Но тут ещё и от агента зависит и от того как он настроен. Да и от размера проекта: какие-то небольшие можно целиком перенести, какие-то только частями.
Решение этой проблемы уже давно придумано и реализовано. В будущем именно web3 сети станут основой интернета. Хорошо ли это? Это уже другой вопрос.
Но со временем переход на него произойдет в любом случае, ибо информационная инфляция обгоняет возможности по обработке информации и расширению хранилищ web2 сети (и да, в первую очередь из-за сгенерированого ИИ контента).
Это да, лишняя морока. Но варианты для оплаты есть и их не мало, потому не вижу в этом особой проблемы (сам на данный момент пользуюсь услугами какого-то селлера с плати ру, раньше корпоративной зарубежной картой расчитывался)
Наконец-то статья не в стиле "Cursor - это волшебная палочка и делает всё за меня" или "Cursor - нерабочее г**** и не работает вообще".
Спасибо за изученные и описанные детали реализации инструмента. Особенно за нюанс с конкатенацией правил (это заставило меня просмотреть свои файлы правил на предмет того, нет ли такой же проблемы у меня).
Ещё один способ заработка, с примерами и инструментами
Спасибо! Вы сэкономили мне время, но думаю, что не только мне