03 · Что такое артефакт (skill/agent/MCP/eval)

Опытный андеррайтер открывает заявку и за минуту чувствует подвох. Не по чек-листу — по тому, как сходятся цифры, как сформулировано назначение кредита, какой регион, какой месяц. За пятнадцать лет у него в голове сложилась тысяча таких паттернов, и ни один не записан в регламенте. Спросишь «почему отказ?» — объяснит. Спросишь заранее «по каким правилам ты решаешь?» — не сможет. Знание живёт не в правилах, а в столкновении с конкретным случаем. В день увольнения оно уходит вместе с ним: ни передать, ни продать, ни застраховать.

Вопрос, который меня в этой сцене не отпускает, другой. Не «как заменить андеррайтера» — а как снять с него эту тысячу паттернов, не заставляя его садиться и писать регламент, который он всё равно написать не может. Об этом и пойдёт речь: как неявная компетенция, которую её носитель не способен толком артикулировать заранее, становится версионируемым, исполняемым, проверяемым цифровым объектом. Сразу уточнение, иначе вся глава развалится. Артефакт — это примитив, а не большой промпт. Засунуть персону агента, базу знаний, инструкции к инструментам и требования к формату в один неструктурированный текстовый файл — самая частая ранняя ошибка компаний. Такой монолит хрупок. Он плохо ложится в Git, не собирается из модулей и ломается, как только его встраивают в многошаговый процесс.

Через главу я веду одну сквозную идею — сублимацию компетенции — и показываю её четыре передачи. SECI снимает узкое место кодификации. Skills дают знанию форму примитива. MCP даёт ему руки до корпоративных данных. Evals ставят ворота качества. Держит всю конструкцию один принцип: относиться к агентам как к боевым системам, а не как к умным стажёрам.

Узкое место всегда было одно

В классической модели создания знания Нонаки и Такеучи знание движется по спирали из четырёх фаз — социализация, экстернализация, комбинация, интернализация. Абстрактную спираль легче понять через момент, когда она рвётся.

Представьте мастера у диагностического стенда. Он слышит неисправность двигателя по звуку — буквально, на слух, за две секунды. Приходит инженер с диктофоном: «Опиши, как ты это делаешь, мы запишем в инструкцию». Мастер честно пытается. «Ну, когда вот так дребезжит на средних оборотах… нет, не дребезжит, а как бы… когда не сходится». Он не врёт и не жадничает. Он физически не может перевести то, что у него в руках и ушах, в сухой структурированный текст. Через час инженер уносит три страницы, из которых ни один новичок не услышит ту неисправность. Знание потеряно при переводе.

Это и есть историческое узкое место — фаза экстернализации, превращение неявного в явное. Не социализация, где мастер годами стоит рядом с подмастерьем. Не комбинация, где готовые документы пересобирают в новые. Именно экстернализация: эксперт не может выписать контекстные эвристики в регламент. На выходе — статичная документация, которая теряет суть и мгновенно расходится с тем, что реально происходит на полу. Стивен Гёрли когда-то критиковал жёсткую линейность этой модели: знание, мол, часто рождается не с социализации, а сразу с творческого синтеза. Спор академический, но он лишь подчёркивал практическую беду — ручная кодификация не работает.

Тот самый андеррайтер не уносил «секрет». Он уносил то, что в принципе не помещалось в инструкцию. Барьер был не в его нежелании поделиться. Барьер был в формате. Между «мастер слышит неисправность» и «новичок решает аномалию по запросу» лежала пропасть, которую тридцать лет пытались закрыть инструкциями и не закрыли.

Первая передача: цифровые фрагменты знания

Наоси Утихира предложил переписать спираль под генеративную эпоху — модель GenAI SECI (Uchihira, GenAI SECI Model, arXiv, 2026; [E]). Она разбирает «Gen-Ba», знание рабочего места, на три слоя, и это разделение оператору важнее любой схемы.

Первый слой — явное знание: то, что осознанно и уже систематически записано. Второй — латентное: полусознательная экспертиза, которую обычно не пишут, но можно фрагментарно выразить прямо во время работы — голосовой заметкой, фотографией, телеметрией, неструктурированным логом. Третий — узко-неявное: бессознательные, телесные техники и эстетические суждения, которые вербализовать в принципе невозможно (Uchihira, 2026; [E]). Третий слой стоит запомнить — к нему вернётся эпилог про несублимируемый 1%.

Прорыв здесь — понятие цифрового фрагментированного знания (Digital Fragmented Knowledge, DFK): неполные, частичные записи того, что человек на месте почувствовал, сделал или подумал, в сыром виде. Голосовые логи. Спонтанные сообщения. Кадры видео, фото с поля. Раньше эти обрывки были бесполезны — их нельзя было аккуратно сложить в структурированную базу. Теперь генеративная модель их интерпретирует: заглатывает обрывки и синтезирует на лету, минуя дорогую и медленную фазу полного «маннуализирования» (Uchihira, 2026; [E]).

Принципиально, где стоит модель. Утихира держит её строго вспомогательной — она агрегирует, структурирует и связывает обрывки человеческой интуиции, а не порождает «искусственное знание» как самостоятельный актор (это уже мой вывод из его рамки, не его измерение; [I]). Здесь узкое место экстернализации перестаёт быть узким. Андеррайтер больше не садится писать регламент. Он на ходу проговаривает, почему именно эта заявка пахнет риском, прямо в момент решения, а система собирает из обрывков связный фрагмент — без когнитивного трения ручной документации. Это апгрейд эксперта, а не замена: с человека снимают труд перевода, не суждение. Меня в этом цепляет именно то, что снимают не работу, а самую неприятную её часть — насилие над собой ради бумаги.

Воркфлоу «эксперт → готовый skill»: как это выглядит руками

Теория теорией, а оператору нужен путь по шагам. Источники дают его как парадигму выращивания агента (Nurture-First Agent Development, NFD; arXiv, 2026; [E]) — подход «сначала вынянчи», который переворачивает привычный «сначала закодируй». Способность агента не программируется целиком на старте, а выращивается через ежедневные разговорные взаимодействия с экспертом.

Сначала извлечение знания: контекстные интервью, логи взаимодействий, разбор историй решения инцидентов — чтобы поймать сырые эвристики. Память агента работает как репозиторий неструктурированного диалога и исторических кейсов. Дальше кристаллизация: накопленные разговоры периодически уплотняются в структурированные переиспользуемые активы. Это и есть цифровая операционализация фазы экстернализации, личное неявное превращается в явный исполняемый объект. Затем разработка фреймворка (классификаторы запросов, RAG-архитектуры, базы правил), встраивание в рабочий агентный процесс и, наконец, валидация: эксперт обязан вручную проверить минимум 200 реальных предсказаний — и код, и смысл — до выката в прод (arXiv, 2026; [E]).

NFD стоит включать не везде. Источник даёт пять критериев: эксперт не может артикулировать решение заранее, но объясняет его в контексте; между экспертами есть законная разница в подходе; среда меняется так часто, что статичные правила требуют постоянных дорогих апдейтов; основной режим взаимодействия — разговорный; полезность зависит от способности вспоминать историю решений. Если задача — детерминированный конвейер с жёсткими правилами, NFD не нужен. Если задача — «чутьё» андеррайтера, которое он не может выписать в правила, но безошибочно применяет к конкретному случаю, нужен именно он. Граница здесь та же, что отделяет процессы, которые остаются на человеке, от тех, что компилируются первыми (стек ролей держит ch05).

Снять знание с эксперта за неделю

Вот протокол, который реально умещается в пять рабочих дней. Не идеальный — рабочий. Берёшь одного эксперта, один узкий процесс (тот самый андеррайтинг малого бизнеса, а не «всё кредитование»), и идёшь по шагам.

День 1 — теневая запись. Эксперт работает как обычно, ничего не объясняя заранее. Он проговаривает вслух каждое решение в момент решения: «эту отклоняю — выручка скачет, а отрасль сезонная, не сходится». Пишешь не регламент, а голос: десять-пятнадцать живых кейсов с рассуждением. Это и есть сбор цифровых обрывков — латентный слой, который он никогда бы не сел писать.

День 2 — разбор пограничных случаев. Кладёшь перед ним не типовые заявки, а спорные: две почти одинаковые, одну он берёт, другую нет. «Почему?» Здесь вытаскиваешь эвристики, которых нет в стандартном потоке. Цель дня — поймать не правила, а исключения из них.

День 3 — первая кристаллизация. Превращаешь записи в черновой skill: классификатор сигналов риска плюс инструкция-рассуждение в файле SKILL.md. Эксперт читает экран и сразу спорит. «Нет, стоп. Тут ты упростил. Ты написал: высокий риск, если выручка скачет больше чем на сорок процентов между кварталами. А я так не думаю». Откидывается на стуле. «Если это пекарня — конечно скачет, декабрь против февраля, и это здоровая фирма. А если это юрфирма с такими качелями — вот это труп, у них клиент уходит. Дело не в проценте. Дело в том, бывает ли такая сезонность нормой для этой отрасли». Ты дописываешь в SKILL.md одну строку — про отраслевую базу сезонности — и стираешь жёсткий порог в сорок процентов, который сам же туда и вписал. Правишь текст, не код. Вот этот момент, когда эксперт видит свою эвристику чужими словами на экране и инстинктивно бьёт по неточности, и есть экстернализация, которая раньше не случалась. Он не смог бы написать это с чистого листа. Но поправить неправильное — может мгновенно.

День 4 — слепой прогон. Гоняешь skill на тридцати новых заявках, которых он не видел. Эксперт выносит свой вердикт, не глядя на машинный, потом сравниваешь. Каждое расхождение — либо дыра в артефакте, либо невысказанная эвристика. И то и другое дописываешь.

День 5 — фиксация ворот. Замораживаешь те расхождения, что эксперт счёл ошибками артефакта, как первый eval-набор (о нём ниже). Договариваешься, где порог NEEDS_HUMAN: какие заявки skill не решает сам, а поднимает человеку. Через неделю на руках не регламент, а исполняемый примитив с воротами. Сырой — но версионируемый, и дальше он растёт каждой пойманной ошибкой, а не переписывается с нуля.

Как выглядит первый eval-набор. Не сто кейсов и не дашборд — таблица из двадцати-тридцати строк, которую заполняет эксперт, а не инженер. Колонки простые: вход (текст заявки), что должен сделать skill (взять / отклонить / поднять человеку), почему (одна фраза эвристики), и какую метрику строка проверяет. Метрик на старте хватает трёх. Завершение задачи — принял ли skill то же решение, что эксперт. Верность обоснования — обосновал ли он его теми же сигналами, а не выдумал правдоподобную причину. Корректность формата — выдал ли результат в схеме, которую проглотит следующая система. Половину строк берёшь из дня 4, там, где skill ошибся: провальный кейс ценнее десяти успешных. Дальше каждый новый сбой в проде дописывается сюда строкой, и набор из артефакта-проверки сам становится сублимированным определением «хорошо». Без этой таблицы skill — просто большой промпт, которому повезло на первой сотне заявок.

Skills как примитив, а не текст

Решение монолитного промпта — сделать единицей знания не текст, а skill: дискретную, версионируемую, исполняемую единицу способности. Управляет конструкцией принцип наименьшего контекста: центральный оркестратор остаётся полностью невежественным относительно внутренней механики отдельных процессов — он работает строго как маршрутизатор, делегируя задачи специализированным саб-агентам и модульным skills (AI Skills as the Institutional Knowledge Primitive, arXiv, 2026; [E]).

Модульность держится на трёх правилах, и каждое — против конкретного режима отказа. Первое — осмысленное именование: существительные для саб-агентов, глаголы для навыков. Compliance_Auditor как саб-агент, parse_sec_filing как его конкретный навык; маршрутизация становится однозначной и читаемой человеком. Второе — инкапсуляция через плагины: саб-агенты и их навыки заворачиваются в плагины, что прячет приватные внутренние навыки от глобального оркестратора и не даёт «загрязнения контекста» — того эффекта, когда лишние определения в окне модели роняют точность. Третье — готовые тулкиты: накопленные навыки складываются в портативный класс цифровых активов, который человек уносит между работами (arXiv, 2026; [E]).

И здесь механика смыкается с рынком труда. Нанимающие менеджеры, по источнику, уже начинают предпочитать кандидатов с готовым тулкитом из собственных агентов, скиллов, хуков и правил — как раньше подмастерье ценили за собственноручно собранный инструмент (это наблюдение источника, ранний сигнал, а не статистика рынка; [I]). Способность перестала жить только в голове; часть её теперь в портфеле артефактов. Кому этот портфель принадлежит — эксперту, фирме, маркетплейсу или гиперскейлеру — отдельный вопрос владения, его держит ch05 про виртуального сотрудника. Здесь важно одно. Тулкит портативен только потому, что каждый навык дискретен, версионируем и не зашит в чужой контекст. Монолитный промпт унести нельзя, он рассыпается вне своей среды. Примитив унести можно.

Именно skills опускают технический барьер настолько, что эксперт может работать как «гражданский разработчик»: выражать сложную логику простыми средствами, тестировать вывод против собственного профессионального суждения и итерировать по реальной производительности, не написав ни строчки на Python. Граница между тем, кто задаёт знание, и тем, кто его собирает, размывается — и это меняет, кому в компании вообще нужно уметь «строить».

Вторая передача: MCP как водопровод контекста

Навык бесполезен, если ему нечем дотянуться до данных компании. До появления Model Context Protocol, открытого Anthropic в ноябре 2024-го ([E], Anthropic), подключение моделей к корпоративным источникам было проблемой N×M: каждое приложение писало кастомный код под каждый инструмент, базу или API, и при N моделях и M системах требовалось до N×M коннекторов. Дорого, хрупко, не масштабируется.

MCP сплющивает кривую до N+M: и хосты, и серверы реализуют протокол один раз. Архитектура — три опоры. Хост — оркестрирующий рантайм. Клиент — компонент внутри хоста, держащий выделенную сессию с сервером. Сервер — лёгкая внешняя программа, превращающая запросы в реальные действия. Сервер выставляет наружу три примитива: инструменты (действия, меняющие состояние), ресурсы (контекст только на чтение) и промпты (переиспользуемые шаблоны инструкций). Это стандарт, который делает руки агента взаимозаменяемыми между моделями, а не «ещё один API».

Дальше нетривиальный инженерный ход. Если грузить все определения инструментов в контекст на старте, точность деградирует по мере роста окна. Решение — прогрессивное раскрытие: MCP-серверы подаются как библиотеки на виртуальной файловой системе, и агент достаёт только нужную ему сейчас схему. Аналогия для неинженера простая. Это разница между поваром, которому на кухню вывалили всё содержимое супермаркета сразу, и поваром, у которого есть каталог, и он берёт с полки те три ингредиента, что нужны для текущего блюда. Первый утонет в товаре ещё до готовки. Второй работает быстро и не путается. Эффект измерим: потребление токенов на определения инструментов падает примерно со 150 000 до менее 2 000 на шаг, экономия порядка 98,7% контекста и стоимости ([E], Anthropic, Code execution with MCP). Это сцепляется с тем спусковым крючком сдвига, который разбирает ch02: интеллект обрушился в цене за два года (−×280, Stanford HAI 2025), а прогрессивное раскрытие срезает ещё порядок сверху. Дешёвый интеллект плюс дешёвый контекст — вот почему артефакт стал экономически возможен именно сейчас, а не в 2021-м.

Здесь рождается механизм, замыкающий круг с навыками. Когда агент пишет и успешно проверяет скрипт под сложную задачу, он сохраняет код как переиспользуемую функцию с описанием в файле SKILL.md — и постепенно строит собственный оптимизированный тулбокс ([E], Anthropic, Code execution with MCP). Навык, рождённый разговором с экспертом, и навык, выкристаллизовавшийся из исполнения, сходятся в один формат. Сублимация идёт с двух концов — сверху от человека и снизу от самой системы — и встречается в одном примитиве.

Реальная сцена: команда безопасности без единой строчки кода

Конкретный кейс. GoDaddy построила архитектуру ревью безопасности приложений без единой строчки кода, которая работает прямо на машине разработчика до пуша в репозиторий. Вся система — каталог из менее чем десяти Markdown-файлов: ни Python-фреймворков, ни векторных баз, ни кастомных контейнеров (GoDaddy, The Zero-Code Security Team, 2026; [E]).

Работает по топологии «хаб и спицы». Хук перед коммитом запускает агента. Оркестратор, чья логика управления описана обычным английским в файле CLAUDE.md, читает git diff и по расширениям изменённых файлов параллельно порождает узко заточенных доменных агентов: агент по уязвимостям кода не лезет в бизнес-логику, а агент по инфраструктуре вызывается только если тронули terraform. Перед запуском оркестратор подаёт в стартовый промпт каждого агента точечные политики — агенту по коду уходят крипто-стандарты, агенту по инфраструктуре — требования к тегированию ресурсов.

Самое интересное — паттерн «адвоката дьявола». Каждый доменный агент спарен с проверяющим, который работает из жёсткой презумпции, что находка домена неверна. А если база политик недоступна, режим отказа проверяющего захардкожен как NEEDS_HUMAN, а не REJECT: система не глотает молча реальную уязвимость во время сбоя инфраструктуры. И петля замыкается. Каждый отказ логируется на дашборд, инженеры безопасности еженедельно его разбирают и правят системные промпты. Улучшить инструмент здесь — значит отредактировать Markdown-файл; не-программист правит инструкцию, и обновлённая способность мгновенно расходится по всем средам разработки.

Вот сублимация компетенции в чистом виде: знание инженера безопасности живёт в версионируемом артефакте, а не в его голове. Уйдёт инженер — артефакт останется, и обновлять его сможет следующий, читая diff, а не переучиваясь с нуля. Я долго искал именно такой кейс — не разбор провала, а работающую витрину. Их пока мало, и это честно стоит держать в уме: GoDaddy — зрелая команда, а не медиана рынка. Но он показывает не «как могло бы быть», а как уже есть у тех, кто соблюдает дисциплину.

Третья передача: evals как ворота

Здесь — главный принцип главы. Детерминированный софт проверяется бинарными утверждениями: прошло / не прошло. Генеративные системы так проверять нельзя — они стохастичны, их нужно аудировать непрерывно и по смыслу. Если относиться к агенту как к умному стажёру, которому веришь на слово, цепочка из таких стажёров даёт лавинообразный рост ошибки. Если относиться к нему как к боевой системе — ставишь ворота.

Эти ворота — программные evals через паттерн «модель-судья», встроенный прямо в конвейер сборки. Движок автоматически прогоняет новую версию промпта, конфигурацию модели или процесс против версионируемого тест-набора, собранного из реальных боевых трейсов, и ловит регрессии по нескольким смысловым метрикам, чтобы оптимизация под одну задачу не уронила молча другую (Braintrust; DeepEval; [E*]). Сама схема «модель-судья» как инженерный паттерн — обобщение из этих источников, не их измерение ([I]).

Метрики стоит назвать — это инженерное определение «качества» для сублимированного знания. Релевантность ответа — отвечает ли модель на запрос. Верность контексту — выводится ли утверждение строго из поданного контекста, а не из памяти модели, защита от галлюцинаций. Корректность формата — схема и лимиты, детерминированной проверкой, чтобы не падали парсеры дальше по конвейеру. Тон бренда — профессионализм, эмпатия, корпоративный голос. Завершение задачи — инструменты вызвались, но достигнута ли цель. Парное сравнение — слепое сличение двух версий судьёй более высокого уровня. Eval-набор не разовый тест. Это живой артефакт, который растёт каждой пойманной ошибкой.

Чтобы судья сам не врал, источники задают инженерные правила. Модель-судья обязана выписать рассуждение по шагам до выставления оценки. Проверки фактов привязываются к эталонным ответам, а не к памяти модели. Провальные пограничные кейсы из прода динамически дописываются в батч сборки как регрессионные ворота (Braintrust; Traceloop; [E*]). Именно eval-ворота отличают инженерную систему от хобби-проекта на промптах. И именно тут проходит грань: где стоит eval — там артефакт; где его нет — там просто большой промпт, которому повезло пройти первую сотню запросов.

Диагностический агент AMIE, обошедший врачей по 29 из 32 осей эталонного сравнения (Nature Medicine, май 2026; [E]; подробнее в ch06), работает так не потому, что модель «умнее врача». Под ним версионируемая рубрика оценки по десяткам осей, против которой его гоняли. Eval — это сублимированное суждение о том, что значит хорошо. Без рубрики тот результат не существует как факт: его нечем измерить.

Где судьёй остаётся человек

Сублимация не означает, что человек уходит. Она означает, что человек поднимается по стеку — от ручного исполнения к направлению и надзору. И источники честно показывают, где это ломается.

Сцена. Эндоскопист с двадцатилетним стажем смотрит колоноскопию. Раньше он сам вычёсывал глазом каждую складку слизистой — полип бывает плоский, бледный, в две-три миллиметра, его легко проскочить. Теперь рядом ИИ-детектор обводит подозрительные участки рамкой в реальном времени. Год врач работает с ассистентом, привыкает, расслабляется — машина и так подсветит. А потом исследование показывает неприятное: у врачей после долгой работы с детектором просела выявляемость полипов, когда детектор убрали (разбираю с числами в ch10). Рука разучилась. Глаз перестал искать сам, потому что искал не он.

Вот это и есть парадокс деквалификации-при-надзоре: автоматизация эрозирует технические навыки оператора, одновременно увеличивая его надзорную ответственность. Оператор теряет руки, но обязан вмешаться за долю секунды в аномалию, которую уже не понимает. Это счёт за когнитивную разгрузку, который приходит позже. И приходит он не только к врачам — к любому, кто год отдавал решение машине, а потом обязан её внезапно переиграть.

Различие между «низко-информативными» и «высоко-информативными» системами здесь решает всё. Первые дают сырое бинарное решение и убивают навык. Вторые дают объяснения, атрибуции признаков и прецеденты — улучшают результат сейчас и сохраняют обучение человека. И дизайн петли решает. Если участие человека содержательное — реальное право решать, когнитивная вовлечённость, профессиональное признание — парадокс снимается. Если номинальное — на человека вешают ответственность без контекста и без инструментов override, и приходят техностресс и текучка. Это прямой проектный вывод, а не мораль: eval-ворота и точку, где решает человек, надо проектировать так, чтобы он оставался судьёй, а не губкой для ответственности. Меня это пугает сильнее всего остального в главе — потому что деградация навыка незаметна вплоть до того дня, когда машина ошиблась, а человек уже не умеет это поймать.

Юридически граница тоже жёсткая. В деле Moffatt v. Air Canada чат-бот авиакомпании выдумал несуществующую скидку на похоронный тариф, пассажир на неё положился, а компания потом отказалась её соблюдать, заявив, что бот — отдельная сущность, отвечающая за свои слова сама. Трибунал это отверг и обязал авиакомпанию заплатить: организация отвечает за обещание, которое сгаллюцинировал её бот (Moffatt v. Air Canada, 2024; [E]). Перекладывать ответственность на «бота» не работает. И это уже не про механику — это про несублимируемый 1%, к которому придёт эпилог: право остановить и обязанность ответить остаются на человеке по закону, потому что у артефакта нет правосубъектности.

Честный фальсификатор

Теперь то, что обрушит тезис этой главы, если сбудется. Вся конструкция держится на допущении, что сублимированный артефакт безопаснее и стабильнее монолитного промпта. Данные по MCP-экосистеме это допущение уже надкусывают. Аудиты открытых каталогов нашли тревожную долю вредоносных скиллов и скиллов с уязвимостями — цифры и источники я свожу в ch10, в главе про эрозию верификатора. Если эта доля не падает, а растёт, то «водопровод контекста» превращается в открытую трубу для атак, и тезис «артефакт остаётся надёжным активом» рушится: остаётся не актив, а пассив, который ещё и сам себя распространяет через готовые тулкиты.

Конкретный фальсификатор с датой. Если к концу 2027 года доля скиллов с уязвимостями в крупнейших публичных реестрах не опустится ниже февральского уровня 2026 (36,82% скиллов с уязвимостями на 3984, из них критических около 13,4%, Snyk; [E]) при росте их установок — значит, дисциплина сублимации не масштабируется, и «артефакт как примитив» остаётся практикой отдельных зрелых команд, а не нормой. Тогда тезис главы рушится. Сам этот провал, с числами на руках, разбирает ch10. Здесь фиксирую честно: механика выше — это как должно быть при дисциплине, а не как уже есть в среднем по рынку.

Скептик, которого тут стоит услышать прямо: «Вы показываете отлаженный GoDaddy и отлаженный AMIE — это витрина зрелых команд. А медиана реестра — груда скиллов с уязвимостями, которые кто-то ставит себе в прод по инструкции из README». Возразить по существу пока нечем — данные февраля 2026 на стороне скептика. Контртезис у меня один, и он проверяем той же датой выше: дисциплина — осмысленное именование, инкапсуляция, eval-ворота, NEEDS_HUMAN вместо тихого REJECT — это и есть то, что отделяет медиану реестра от витрины. Вопрос лишь в том, станет ли она дефолтом реестров к 2027-му или останется привилегией немногих.

Что это значит

Сублимация компетенции — не магия и не одна кнопка. Это конвейер из четырёх передач: SECI снимает узкое место экстернализации, skills дают знанию форму версионируемого примитива, MCP даёт ему руки до корпоративных данных, evals дают ему ворота качества. Каждая передача без следующей бессмысленна. Навык без данных слеп. Данные без ворот опасны. Ворота без живого человека на нагруженной границе — фикция.

И именно потому, что петля замыкается на эксперте, андеррайтер с первой сцены не уносит свою тысячу паттернов в день увольнения. Его суждение остаётся в репозитории — исполняемое, проверяемое, версионируемое. Та самая строчка про отраслевую базу сезонности, которую он продиктовал на третий день, ткнув пальцем в экран, теперь живёт без него. Компетенция ушла с человеком; артефакт остался в фирме. Апгрейд при дисциплине, а не замена. Но как только знание становится активом, который можно унести, скопировать и присвоить, возникает следующий вопрос — уже не инженерный. Что при этом дешевеет, что дорожает и кому артефакт принадлежит. К нему — дальше.