Что могу сказать: я второй месяц собираю автономного агента на локальных LLM, в которого можно закинуть идею, а он сам бы её исследовал, расписал, согласовал, разбил на задачи и реализовал. На текущий момент Qwen 3.6-27b для агентских задач — самая продвинутая из доступных для моей 3090Ti локально. Но это всё ещё далеко от качества облачных решений типа Composer 2.0.
Хочу дополнить резюме автора своим наблюдением: одного Reviewer Agent недостаточно.
Без жесткой архитектуры это превращается в бесконечный цикл «отклонение → переделка → отклонение», который никогда не закончится, пока не иссякнет контекст или терпение.
В базе нужна действительно большая модель (уровня Kimi-k2,6), способная удерживать весь контекст проекта, плюс обязательное дообучение (LoRA) под специфические инструменты среды.
Нужен не просто Reviewer, а комплексная система оркестрации, включающая:
Детерминированный роутинг сценариев: Четкое разделение на роли (Архитектор, Инженер, Тестировщик, Дебаггер и тд), где каждая роль имеет свои права доступа к инструментам и лимиты итераций.
Верификатор как внешний арбитр: Механизм, который не доверяет словам модели, а самостоятельно запускает тесты/линтеры и принимает решение о статусе задачи (done/blocked) только на основе объективных доказательств (DoD).
Safety Kernel и Loop Guards: Жесткие ограничители, которые прерывают цикл после N неудачных попыток и автоматически эскалируют задачу на человека или меняют стратегию (например, переход от «попытки исправить» к «перепланированию»).
Память проекта в виде артефактов: Хранение контекста не в чате, а в версионируемых файлах, чтобы агент мог обращаться к истории решений, а не галлюцинировать заново.
Стратегии сжатия контекста: Автоматическое архивирование старых частей диалога в краткие резюме для освобождения места под текущую работу без потери смысла.
Контур самообучения: Автоматическое извлечение регрессионных кейсов из неудачных попыток для обновления базы знаний системы.
Сквозная индексация: Единое промежуточное представление и граф зависимостей, связывающие код, тесты, требования и правила в единую сеть. Это позволяет агенту видеть влияние изменений (если я поменяю эту функцию, какие тесты и модули затронуты?) и поддерживать трассируемость от бизнес-цели до конкретной строки кода.
Управление блокировками и конкурентным доступом: Механизм блокировки файлов и ресурсов, предотвращающий конфликты записи при параллельном выполнении задач разными ролями.
Бюджетирование и лимиты ресурсов: Контроль расхода токенов, времени GPU и стоимости операций в реальном времени с автоматической остановкой при превышении лимитов.
Мета-тестирование поведения агента: Набор адверсарных тестов специально для проверки устойчивости самой системы оркестрации к сбоям и галлюцинациям.
Объяснимость решений: Визуализация цепочки рассуждений и причин принятия решений прямо в UI (почему агент выбрал именно этот файл?).
Реакция на внешние события: Возможность автоматически создавать задачи в при внешних триггерах (падение CI, пуш в репозиторий).
Версионирование промптов и конфигураций: Хранение версий системных промптов и правил ролей в Git для возможности отката поведения агента при деградации качества.
Фишка курсора, что он индексирует до 50 000 файлов проекта для понимания контекста, как вы решили данную задачу? Мне как дизайнеру смотреть в код практически не приходится, всё взаимодействие через чат. Я на node.js собираю веб проект, лежит на домене мастерклик.рф Все лимиты на тарифе ультра этих гиперконтекстных моделей я выжигаю за неделю и основная работа идёт на компоузере 1.5, он видимо безлимитный. Как можно перейти на плагины, я не очень понимаю, так как по API бесплатных токенов не видел.
Я тоже навайбкодил за месяц проектик, но не рвусь бежать и писать про это статьи. В чем смысл поста, не понятно. Описанный процесс вообще не похож на тот, который выработался у меня. Все лимиты этих умных гипермоделей я потратил в первую неделю, толку от них никакого, пишут кучу не того что нужно. $200 в плане ультра улетели и оставшиеся 3 недели я дописывал на компоузере 1.5, который судя по всему безлимитный, так как по графику затрат он показывал в районе $800 под конец месяца, то есть далеко за пределами самого тарифа. За этот месяц я собрал дизайн систему с компонентами на дизайн токенах. Интегрировал сторонние сервисы по геокодированию, поисковым подсказкам, отображению карт. Выстроил флоу заказчика и исполнителя. Админку для управления контентом и настройкой. Всякие там адаптеры для платежных провайдеров, цели для метрики и тому подобное. MVP еще не закончен, но если интересно, лежит тут мастерклик.рф
Я правильно понимаю, что вы вместо того, чтобы изучать и копировать привычные и устоявшиеся паттерны поведения продукта-конкурента, зачем-то еще занимаетесь UX-исследованием и внесением изменений в эти устоявшиеся паттерны на основе ваших тестов?
Как мне кажется, ваша стратегия должна состоять из точного копирования и закрытия по функциональности, а изменения, это перспектива будущего, в зависимости от скорости ваших возможностей по клонированию.
Что первым делают пользователи обновившиеся с 10 на 11 винду? Правильно, идут прибивать кнопку пуск к левому-нижнему углу. Им эти новые механики *** не сдались...
Текущие схемы не понятны не из-за визуальной формы, а из-за информационной неполноты. Графы тоже визуально отображаются в виде DAG-графов, это тоже схемы, просто без циклов. Смысл ioHasC в уходе от функционального описания к информационному, с указанием целей.
Мне как дизайнеру ваши схемки абсолютно не понятны, (вы их уже привыкли строить, поэтому топите за схемки), но заполнить таблицу последовательности действий я могу и мне это просто. А по фен-шую делается эксперимент, берутся 3 разных бизнес-процесса и описываются разными способами, а потом тестируется понимание на разных пользователях. Сразу уберётся весь судейский субъективизм, с которым мы так боремся в автоматизации процессов :)
Мы используем Хаск-модель Зайцева (ioHasC) весь продукт декомпозируем на информационные графы в логистическом формате, где начало графа — это позиция того что имеем, конец графа — это цель и маршрут — как из А попасть в Б. Я сокращено это назвал АБВ (point A, point B, Way). Такой формат понимают и аналитики и дизайнеры и программисты и даже не имеющие отношение к решению люди, он прост, понятен и универсален, так как в этом формате можно описать любые процессы, алгоритмы, продукты, договора, интерфейсы и тд. Так же ABW является техзаданием, частью бэклога и даже документацией и комментариями к коду и дизайну. Не понимаю, зачем люди себе усложняют жизнь используя чужие методики )))
так это уже давно, просто некоторые просят шифроваться стилем написания и не бросаются в глаза, как эти пункты.
Что могу сказать: я второй месяц собираю автономного агента на локальных LLM, в которого можно закинуть идею, а он сам бы её исследовал, расписал, согласовал, разбил на задачи и реализовал. На текущий момент Qwen 3.6-27b для агентских задач — самая продвинутая из доступных для моей 3090Ti локально. Но это всё ещё далеко от качества облачных решений типа Composer 2.0.
Хочу дополнить резюме автора своим наблюдением: одного Reviewer Agent недостаточно.
Без жесткой архитектуры это превращается в бесконечный цикл «отклонение → переделка → отклонение», который никогда не закончится, пока не иссякнет контекст или терпение.
В базе нужна действительно большая модель (уровня Kimi-k2,6), способная удерживать весь контекст проекта, плюс обязательное дообучение (LoRA) под специфические инструменты среды.
Нужен не просто Reviewer, а комплексная система оркестрации, включающая:
Детерминированный роутинг сценариев: Четкое разделение на роли (Архитектор, Инженер, Тестировщик, Дебаггер и тд), где каждая роль имеет свои права доступа к инструментам и лимиты итераций.
Верификатор как внешний арбитр: Механизм, который не доверяет словам модели, а самостоятельно запускает тесты/линтеры и принимает решение о статусе задачи (
done/blocked) только на основе объективных доказательств (DoD).Safety Kernel и Loop Guards: Жесткие ограничители, которые прерывают цикл после N неудачных попыток и автоматически эскалируют задачу на человека или меняют стратегию (например, переход от «попытки исправить» к «перепланированию»).
Память проекта в виде артефактов: Хранение контекста не в чате, а в версионируемых файлах, чтобы агент мог обращаться к истории решений, а не галлюцинировать заново.
Стратегии сжатия контекста: Автоматическое архивирование старых частей диалога в краткие резюме для освобождения места под текущую работу без потери смысла.
Контур самообучения: Автоматическое извлечение регрессионных кейсов из неудачных попыток для обновления базы знаний системы.
Сквозная индексация: Единое промежуточное представление и граф зависимостей, связывающие код, тесты, требования и правила в единую сеть. Это позволяет агенту видеть влияние изменений (если я поменяю эту функцию, какие тесты и модули затронуты?) и поддерживать трассируемость от бизнес-цели до конкретной строки кода.
Управление блокировками и конкурентным доступом: Механизм блокировки файлов и ресурсов, предотвращающий конфликты записи при параллельном выполнении задач разными ролями.
Бюджетирование и лимиты ресурсов: Контроль расхода токенов, времени GPU и стоимости операций в реальном времени с автоматической остановкой при превышении лимитов.
Мета-тестирование поведения агента: Набор адверсарных тестов специально для проверки устойчивости самой системы оркестрации к сбоям и галлюцинациям.
Объяснимость решений: Визуализация цепочки рассуждений и причин принятия решений прямо в UI (почему агент выбрал именно этот файл?).
Реакция на внешние события: Возможность автоматически создавать задачи в при внешних триггерах (падение CI, пуш в репозиторий).
Версионирование промптов и конфигураций: Хранение версий системных промптов и правил ролей в Git для возможности отката поведения агента при деградации качества.
Ну и там много чего еще...
У меня почему то 2.5 coder не дружит с tool calling. А его с агентом так и не подружил.
3.6 уже выкатили
Насколько дешевле курсора вышло?
Фишка курсора, что он индексирует до 50 000 файлов проекта для понимания контекста, как вы решили данную задачу? Мне как дизайнеру смотреть в код практически не приходится, всё взаимодействие через чат. Я на node.js собираю веб проект, лежит на домене мастерклик.рф Все лимиты на тарифе ультра этих гиперконтекстных моделей я выжигаю за неделю и основная работа идёт на компоузере 1.5, он видимо безлимитный. Как можно перейти на плагины, я не очень понимаю, так как по API бесплатных токенов не видел.
Я тоже навайбкодил за месяц проектик, но не рвусь бежать и писать про это статьи. В чем смысл поста, не понятно. Описанный процесс вообще не похож на тот, который выработался у меня. Все лимиты этих умных гипермоделей я потратил в первую неделю, толку от них никакого, пишут кучу не того что нужно. $200 в плане ультра улетели и оставшиеся 3 недели я дописывал на компоузере 1.5, который судя по всему безлимитный, так как по графику затрат он показывал в районе $800 под конец месяца, то есть далеко за пределами самого тарифа. За этот месяц я собрал дизайн систему с компонентами на дизайн токенах. Интегрировал сторонние сервисы по геокодированию, поисковым подсказкам, отображению карт. Выстроил флоу заказчика и исполнителя. Админку для управления контентом и настройкой. Всякие там адаптеры для платежных провайдеров, цели для метрики и тому подобное. MVP еще не закончен, но если интересно, лежит тут мастерклик.рф
Flash, который сейчас Adobe Animate поддерживает публикацию в html5.
Я правильно понимаю, что вы вместо того, чтобы изучать и копировать привычные и устоявшиеся паттерны поведения продукта-конкурента, зачем-то еще занимаетесь UX-исследованием и внесением изменений в эти устоявшиеся паттерны на основе ваших тестов?
Как мне кажется, ваша стратегия должна состоять из точного копирования и закрытия по функциональности, а изменения, это перспектива будущего, в зависимости от скорости ваших возможностей по клонированию.
Что первым делают пользователи обновившиеся с 10 на 11 винду? Правильно, идут прибивать кнопку пуск к левому-нижнему углу. Им эти новые механики *** не сдались...
Тоже не вижу причин, описывайте Хаск-модель в формате BPMN, вам никто не запрещает. Если всей команде будет понятно, кто же вас отговорит от этого.
Текущие схемы не понятны не из-за визуальной формы, а из-за информационной неполноты. Графы тоже визуально отображаются в виде DAG-графов, это тоже схемы, просто без циклов. Смысл ioHasC в уходе от функционального описания к информационному, с указанием целей.
В схеме bpmn есть: клиент —> принятие заявки —> регистрация заказа —> принятие оплаты —> доставка —> закрытие заказа.
В ioHasC: Получить данные от пользователя —> Проверить наличие товара —> Получить оплату от пользователя —> Доставить товар
Мне как дизайнеру ваши схемки абсолютно не понятны, (вы их уже привыкли строить, поэтому топите за схемки), но заполнить таблицу последовательности действий я могу и мне это просто. А по фен-шую делается эксперимент, берутся 3 разных бизнес-процесса и описываются разными способами, а потом тестируется понимание на разных пользователях. Сразу уберётся весь судейский субъективизм, с которым мы так боремся в автоматизации процессов :)
Мы используем Хаск-модель Зайцева (ioHasC) весь продукт декомпозируем на информационные графы в логистическом формате, где начало графа — это позиция того что имеем, конец графа — это цель и маршрут — как из А попасть в Б. Я сокращено это назвал АБВ (point A, point B, Way). Такой формат понимают и аналитики и дизайнеры и программисты и даже не имеющие отношение к решению люди, он прост, понятен и универсален, так как в этом формате можно описать любые процессы, алгоритмы, продукты, договора, интерфейсы и тд. Так же ABW является техзаданием, частью бэклога и даже документацией и комментариями к коду и дизайну. Не понимаю, зачем люди себе усложняют жизнь используя чужие методики )))
да, пишите в личку