Вроде как минорный, но важный update от Anthropic.

Улучшили работу с памятью между сеансами.
Главная фишка — это project-scoped-memory.
Каждый проект имеет отдельную память.
Мне кажется этот момент до безобразия логичным и очевидным, но, возможно, я что-то упускаю.

Планируется, что мы сможем иметь доступ к этой памяти проекта и редактировать её на своё усмотрение.
Считаю это важным поинтом.

Контроль памяти проекта чем-то похож на claude.md в claude code.
Всё больше похоже, что Anthropic нащупало свою экосистему.

На фоне новостей о переговорах с Google по облачной инфраструктуре (речь про десятки миллиардов долларов на TPU), допускаю, что экосистема Anthropic может быть значимой.

Кратко по фактам:
- Контроль памяти для пользователей
- Project-scoped память (изоляция контекстов)

Хех, кажись я стал адептом Claude
И у меня появляются апдейты быстрее, чем в каналах побольше.
UI навигация по режиму планера в терминале, простигосподи, такое всдух говорить.

Это интересно, удобно, практично.
Пытаюсь сейчас написать функциональный statusline для CLI, чтоб отслеживать контекст в процессе и вовремя переходить в новый чат или /compact беседы. Так же мониторинг потраченных денег.

Прошу прощения, что не гифка, без понятия, как обработать на убунте видос, что поделать - vibe coder, что с меня взять )

В очередной раз убеждаюсь, что
краткий вариант - всегда приятнее.
Если на днях проверю все мерзкие сценарии и нигде не упаду, то скину описание и ссылку на гит, что уж добру пропадать.

Команда /context , кстати, выдает статистику уже с зарезервированными токенами под compact, что не очевидно,
Хотя, на самом деле, по факту, у тебя расход токенов многим меньше.
Такие дела.

Не, ребят, розовые сторисы на Youtube в реальности вряд-ли пока рабочие.

Все эти настроенные пре-сеты с:

- агенты с инструкциями для ведения документации
- списки команд для реализации длинных пайплайнов разработки, которые можно заранее шаблонно описать через markdown-memory
- features planned и стаус-планеры с апдейтами через агентов и автозаполнение в зависимости от этапа разработки
- /new-feature | Создать спецификацию фичи в backlog, для отдельного сценария обработки новой фичи и плавной интеграции в рамках общего автоматизированного пайпа

Вот эти всё - пока-что мечта.

Даже Claude умирает, он не соображает, когда можно и нужно запускать:
- субагента в параллельном потоке (это главная проблема)
- контекст сжирается
- время работы уходит в часы
- автоматический режим суммаризации контекста, на данный момент, ломает основной план действий

Если действовать примитивно в диалоге с моделью без автоматизации пайплайнов, а каждый пшик самостоятельно апрувить, то можно хотя бы вовремя осознать, что всё пошло по одному месту.

Но если сделать, как советуют уверованные в AGI, и просрать десятки часов на настройку автоматизацию всех суб-агентов, то:

Ты получишь непредсказуемый процесс с твоим проектом локальным, на github в течении нескольких часов без малейшего шанса вклиниться в процесс и результат будет, как ставка на стоимость Bitcoin'a

А какой итог?

Простой.

Вам я не советую пытаться автоматизировать всё то, что вы можете без потерь самостоятельно контролировать.

В этой жизни и так мало вещей, которые подлежат нашему контролю
Грустный кек

А я обязательно допишу оптимальный шаблон для оптимизации этих LLM агентов, чтоб и ТЫ и Я, всё же смогли переложить еще больше рутины на них и оставить себе больше времени на Рилсы)

Не долго Гугл танцевал, не долго песенка играла)
Как жаль, что не нашел я мем, где OpenAI, Google. Antropic, DeepSeek по кругу становятся "лучшими"

По поводу апгрейда, Я на постоянке использовал Sonnet 4.5 , а Opus 4.1 юзал либо когда совсем зашился и уже потерял надежду на спасение, либо скоро обновится недельный лимит - нужно потратить.
Посыл в том, что прошлый Opus мягко говоря не уступает, а где-то опережает актуальный Sonnet.
А тут такой апдейт!

Настроили уровень "размышления", можно контролировать степень пожирания токенов на thinking.

по метрикам и в статье хвастаются аппом производительности агентских задач.

все ближе релиз Claude для Excel, это будет вообще разрыв! Сейчас уже многим доступен в том или ином виде.

Я чертовски доволен апдейтом.
https://www.anthropic.com/news/claude-opus-4-5

Последние несколько недель занимался одной штукой, которую давно хотел сделать.
Каждый раз, когда начинаю новый проект на FastAPI, происходит одно и то же. Создаю папки. Пишу настройку базы данных. Копирую обработку ошибок из прошлого проекта. Настраиваю логирование. И так по кругу.

В какой-то момент понял, что трачу первые дни работы над проектом на вещи, которые уже делал десять раз. А хочется сразу садиться и писать то, ради чего проект вообще затевался.
Собрал всё в одном месте.

https://github.com/nikitaCodeSave/FastAPI-kit

По сути это тот проект, который я хотел бы найти, когда сам начинал разбираться с FastAPI. Не нашёл — сделал сам.
Если работаете с FastAPI или только начинаете — загляните, возможно пригодится. Буду рад, если кому-то сэкономит время.

Крайне рекомендую прочитать хотя бы наискося
https://github.com/nikitaCodeSave/FastAPI-kit/tree/main/docs
Выжимки многих дней, как сейчас стоит писать проекты на FastAPI и что это из себя представляет.

В целом эти 2 файла могут быть достаточным для агента, который будет вам писать сервис для API. Для большинства задач этого хватит с головой.

По себе знаю, что многим в рот не сдалась никакая База данных, а подавай LLM!
Так что дополнил проект одним доменом "mistral"
https://github.com/nikitaCodeSave/FastAPI-kit/tree/main/backend/src/mistral

И тут сразу преимущество DOMAIN-BASED АРХИТЕКТУРЫ:
- каждый домен самодостаточен и в своей папке, ты можешь УДАЛИТЬ "example" с базой данных
и оставить только mistral - всё будет работать.

Из важного по Mistral - Я затронул тему function_calling.
(на изображении реализация)
Возможно по этой теме я в будущем напишу что-то подробное и полноценное, но пока работа меня шатает.
В документации и readme есть ссылки и расписан вариант, как можно потестить свои варианты вызова функций.

Mistral - потому-что это SimpleAGI за 2 кнопки получить бесплатный API и можно играться вдоволь.

Ну а мой проект:
https://github.com/nikitaCodeSave/FastAPI-kit/
Стал еще чуточку полезнее

Промо Claude Code на 7 дней.
https://claude.ai/referral/HNmjGiJvXQ

Жирно с тарифом PRO

Установить Claude Code

На днях вышел апдейт Manus 1.6
В ру комьюнити Манус не очень популярный из-за цены, как я понимаю.
Но ребята планомерно и уверенно шагают к
"one-shot task success"

Например попросил провести анализ и сгенерить слайды по теме
"Списки пожеланий на новогодние праздники и что люди друг другу дарят? насколько ожидания соотносятся с реальностью"

Так можно прям на слайде редактировать текст, в диалоге править дизайн и всё очень юзер-френдли.

Если цена изменится или увеличат бесплатные лимиты - то рекомендую добавить в закладки)

В последнее время вычитываю репозитории с агентскими плагинами и пресетами для claude code. Путешествие не самое приятное и объемное, но в какой-то степени этот путь предстоит пройти каждому.
Нашелся приятный агрегатор который явно рекомендую потыкать и почитать Skills ,
https://skillsmp.com/
Есть как документация по самой сущности skills для агентов, так и разбитые по категориям примеры с ссылками на github, куда можно провалиться,
А там, как правило - репозиторий - хранилище плагинов.

Рекомендую, как первую точку входа для решения задачи с "Поиск или написание скилла"

Вот сижу, разбираюсь с этим апдейтом Skills, что-то тестирую.
И бац, мысля в голову прилетела.
Ведь всё, что ново-модно сейчас обсуждать с агентами в разработке
Декомпозиция. Специализация. Оркестрация. Контракты
Всё это используем уже десятилетия в микросервисах.

Фундаментально решить пытаемся одну и ту же задачу:

Как управлять сложностью через декомпозицию?

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

| Микросервисы                     | Skills                          |
|----------------------------------|---------------------------------|
| Независимые deployment units     | Независимые SKILL.md файлы      |
| API контракты (OpenAPI)          | Контракты на естественном языке |
| Service discovery                | LLM-роутинг по описаниям        |
| Оркестрация (K8s)                | Оркестрация через LLM           |

Обе архитектуры обещают: модульность, переиспользование, независимую эволюцию компонентов, возможность комбинировать базовые блоки в сложные системы.

Но как справедливо отмечает Guille Ojeda в своём анализе:

Они обе делят сложность на управляемые части, но делают это по разным причинам и делят разную сложность.

Фундаментальное различие: зачем мы декомпозируем

Микросервисы: структура приложения

Микросервисы появились как ответ на боли монолита: медленные релизы, неэффективное масштабирование, технологический lock-in, каскадные отказы. Это паттерн софтверной архитектуры, направленный на улучшение жизненного цикла разработки.

Декомпозиция в микросервисах привязана к бизнес-доменам — стабильным концепциям предметной области. Сервис CatalogService управляет каталогом товаров. PaymentService — платежами. Границы сервисов отражают границы бизнеса, что обеспечивает долгосрочную поддерживаемость.

Skills: структура задачи

Skills появились как ответ на ограничения LLM: сложные задачи требуют многошаговых процессов, доступа к внешним инструментам, сохранения контекста. Это паттерн AI-системного дизайна, направленный на достижение автономного, целеориентированного поведения.

Декомпозиция в Skills привязана к логике выполнения задачи — функциональным шагам, ролям, рабочим процессам. Skill pdf знает, как извлекать текст из PDF. Skill code-review знает, как проводить ревью кода. Границы Skills отражают границы экспертизы, а не бизнес-домены.

Ключевой инсайт: Микросервисы декомпозируют структуру приложения. Skills декомпозируют процесс решения задачи.

Ради этой таблички пишу пост
В AI-native разработке формируется своя иерархия:

| Уровень     | Традиционный              | AI-Native                         |
|------------|----------------------------|-----------------------------------|
| Атомарный   | Функция                    | Tool (Read, Write, Bash)          |
| Экспертиза  | Модуль                     | Skill (домен + workflow)          |
| Автономный  | Сервис                     | Agent (reasoning + tools)         |
| Система     | Приложение                 | Agentic Workflow                  |

И почему же не получается полностью перенести весь "опыт" разработки на агентские рельсы?
Мысль то моя не нова и есть десятки репозиториев со сложными сценариями на десятки агентов, со сложными сценариями, которые "копируют" процесс разработки и автоматизируют его.
НО дальше концепта и звезд на GitHub не идет?
___
Bounded Contexts из Domain-Driven Design отлично работают для микросервисов, но плохо подходят для Skills. Skill декомпозируется по функциональным шагам, а не по доменным границам.
Попытка создать "UserProfileSkill" по аналогии с "UserProfileService" приведёт к размытым границам и неэффективному использованию.

Заключение
Skills — это не "микросервисы для AI". Это новый архитектурный паттерн, который заимствует идеи декомпозиции из микросервисного мира, но применяет их к принципиально другой проблеме: оркестрации интеллектуального поведения.