Практически никакого отличия для не пишущих код. Стартовать в Cowork проще там есть готовые плагины под роли, результат видно прямо в чате.

Я разбираю Claude Code, потому что он даёт понять, как всё устроено изнутри. Видишь каждый шаг агента если результат не тот, понимаешь, где поправить. В Cowork получаешь готовый файл, но процесс скрыт.

Ну и дальше там тонкости, что cowork будет видеть только то, что в папке в которой запустился, установка библиотек, например как у нас в задаче с транскрибацией Whisper.

подписка на месяц, это же не АПИ) как она сгорит? у вас лимиты за 1 день да быстро потратятся, но не сгорит, не пугайте так)

Можно и нужно ограничивать, можно запускать в песочнице отдельной, что будет более прдепочтительным.

Да вы правы: но мы не про модель Deepseek говорим, а чат с Deepseek. И да от того что в claude работает через подмену API, DeepSeek, никак не мешает статье, а наоборот)
То есть от того что вы подключите модель принятия решений LLM вместо Claude opus, sonnet на какой-то deepseek r3, ничего не изменится оркестратор все равно claude code.
спасибо, что нашли время прокомментировать

В сегменте одностраничных сайтов точно могут конкурировать – назовем их маркетинговыми, или же коммуникационным дизайном, да безусловно могут конкурировать. И v0 как и другие его аналоги bolt, lovable, magic pattern позицонируют себя как «one prompt shot ready site» – типо за один промпт получили себе сайтик.

А Figma она все таки слегка другую задачу решает:
1. Дизайн сервисов, где важна историчность иттеративность – то етсь сделали дизайн сервиса какого-нибудь, через решили, что нужен новый функциона, продолжили делать новые макеты на основании старых.
2. Дизайн (пользоватльский опыт) "Сложных продуктов" ну нормальную CRM нельзя сделать промптом, пока нельзя. Нужно продумывать каждое взаимодействие с элементами интерфейса, проектирвоать путь пользователя, тут конечно фигму с дизайнером v0 и подобные сервисы пока не зменят.

Ну и дальше уже переходим на территорию продуктов с 100+ тысячной аудиторией, там ошибка стоит очень дорого, поэтому процесс строится таким образом:
Макет – прототип–тест макета–2 иттерация макета – тест – разработка – тест интерфейса – продакшен. В таком процессе фигма конечно незаменима, и дизайнер тоже пока не заменим. Но AI точно ускоряют все эти этапы, причем уже сильно

Вы правы, упустил!

Важные замечания, спасибо! в 3 части, где будем осбирать агента, все ваши вопросы разберу

Я использую такие методы:
1. Трейсинг каждого решения модели
2.. Метрики архитектурного здоровья
Проверяю Среднее число итераций на запрос (норма для ReAct 3-5, если 15+ что-то не так)
Процент задач где оркестратор создал «лишних» субагентов и т.д.
Откуда брать метрики ? 1 по бизнес требованиям, или смотреть бенчмарки рынка.
Подглядеть можно тут в документациях https://www.promptfoo.dev/docs/intro/ и тут например DeepEval


Дополнительно есть еще такой подход называется "chaos testing" это когда намерено допускаете ошибку и смотрите как LLM модель реагирует.

Клаасная статья! Интересный проект, на замену whisper можн еще расcмотреть модель STT мини от Mistral. Для Реалтайма показывается себя круче.

если речь про диаграммы то это нативный make chart из notion
если построение ворклоу архитектуры: то я использую langchain, можно и n8n и flowise

Да, вот статьи полезные от Anthropic

- https://www.anthropic.com/research/building-effective-agents — 6 паттернов агентов, от цепочки до оркестратора                                                                                                 

  - https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents — что реально влияет на качество агента                                                                                      

  - https://www.anthropic.com/engineering/writing-tools-for-agents — как описывать инструменты чтобы агент их правильно юзал

  - https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents — как строить обвязку для автономных агентов

мне понравилось как тут еще разобрали:
https://47billion.com/blog/ai-agents-in-production-frameworks-protocols-and-what-actually-works-in-2026/

а вот книга https://www.amazon.com/Building-Agents-LLMs-Knowledge-Graphs/dp/183508706X

кажется даже кто то переводил ее в интернете можете поискать)

да абсолютно вас поддерживаю, n8n или любой другой контрлиуремый фреймворк куда надежнее.

Действительно 😁

Несколько апдейтов из опыта, если будет полезно – круто!
1. Гибридный поиск (vector + BM25) + cross-encoder решает проблему "разного языка" без типовых вопросов
2.LLM-as-a-judge для "есть ли ответ" работает лучше логрегрессии и/или Ragas
3. Semantic caching для top запросов режет latency в 10x


Не понял зачем эмбединговую модель файнтюнить? но оставлю его открытым
Так же зачем BERT если речь как я понял идет о другой архитектруе, немного запутался:

Статья классня, спасибо

Подписываюсь под каждым словом: но есть нюансы как говорится:

Вы правы с тем что, дефолтный агент именно так как вы опсиали будет действовать писать на 1000+ строк доки, часть из которой вам никогда не пригодится и т.д. И тогда каждое последующее обновление кода или части функионала упирается в контексное окно + тупую техногию сжатия контакса с принципом "скользащего окна". ИИ агенты будут пложить фыайлы, не сомгу отредактирвоать и все! Рефакторинг обеспечен

Но есть же и другой подход к вайбкодингу: разделить отвественность и добавить правил. "Правила" – навино конечно, но это по факту систем промпт каждого AI кодера перед вызовом инструмента. При дестких ограничениях можно получить релаьно код продакшен реди.

Спасибо за статью полезно 👍🏼

👍🏼

а вот еще исследование рынка от https://openai.com/index/taisei/

Согласен, это нужно не всем

Со строительной отраслью примерно так же, если у вас есть в компании разработчики то смело передаайте статью коллегам.
если будут вопросы, открыт к обсжудению