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

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

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

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

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

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

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

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

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

Первый шаг: собрать обрывки вместо регламента

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Навык-программа как кирпичик

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

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

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

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

Второй шаг: дать знанию руки до данных компании

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

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

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

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

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

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

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

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

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

Третий шаг: поставить проверочные ворота

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

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

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

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

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

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

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

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

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

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

Юридически граница тоже жёсткая. В деле 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 на стороне скептика. Контртезис у меня один, и он проверяем той же датой: дисциплина — осмысленное именование, закрытые модули, проверочные ворота, NEEDS_HUMAN вместо тихого REJECT — это и есть то, что отделяет медиану каталога от витрины. Вопрос лишь в том, станет ли она нормой к 2027-му или останется привилегией немногих.

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

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

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