Вот сижу, разбираюсь с этим апдейтом 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". Это новый архитектурный паттерн, который заимствует идеи декомпозиции из микросервисного мира, но применяет их к принципиально другой проблеме: оркестрации интеллектуального поведения.