Делаю машинку для инженерии мастерства

ailev · 30.Август.2026 22:51:02

Мои сегодняшние занятия
Мои текущие (вот прямо сегодня) занятия можно разделить на следующие группы:

борьба с проблемами оркестрации агентов (починки, починки, ремонты, ремонты). Chief operating officer, “чтобы всё жужжало как надо”, пять-шесть агентов всего – но мне хватает, я и за таким числом едва успеваю приглядывать. Если больше – не факт, что будет время думать. Почему отдельный пункт на эту текучку? Потому как больше занимаюсь не столько приглядом, сколько платформой: оркестрационными паттернами, которые всем рулят. Harness – это мне даёт Codex App, но оркестрация – наполовину моя (наполовину, ибо Codex App лезет и туда, агенты там ведут себя как взрослые, подкручивают все регламенты сами, и не всегда к лучшему).
стратегическое планирование (стратегирование и планирование): думаю больше всего как раз тут, это удержание целого. Текущие lytdybr-посты как раз про это: идеи и планы. Проблематизация и что с этими проблемами делать дальше (и делать ли вообще, а если делать – когда именно). Сегодняшний этот пост – как раз про это.
проект по созданию руководств: Learning Guide LPF как машинка по написанию руководств, а на выходе – кастомизированные руководства по потребности. Успехи пока более чем скромные, но есть. Пока отлаживаюсь на варианте “руководство из материалов семинара”. Побочный продукт – нарративизация материалов семинара “Развитие для развитых” с картинками. Кстати, немаленькое получилось, на 0.3M, 101 страница в .pdf – и я его отдал участникам семинара, который прошёл 1 февраля 2026 как “послепродажное обслуживание”.
проект по созданию Engineering DPF Suite. Три DPF готовы для первых проб (системная инженерия, а также культурная эволюция в музыке и танцах, но ещё и методология). Далее будут очередные архитектурные утрясания “всего со всем” – и потом потихоньку доработаются остальные 11.

Дальше в тексте я не слишком буду различать развитие и обучение, ибо learning sciences так просто не зачеркнёшь.

Пересобрать инженерное знание, а не переписать старые руководства
Затеянный мной проект создания DPF идёт так:

вытащил содержание из текущих моих руководств R0, R5-R10 как “основные идеи”;
сделал наброски архитектуры сборки этих идей на основе архитектуры методов, предусматривающей культурную эволюцию методов, холоническое представление (“вертикаль” одномоментного участия в работе), горизонталь “разложения метода” и навигацию внимания с опорой на мантры и целевой метод проекта примерно так же, как сделали навигацию с идеей целевой системы;
нарезал заново на предметные области и предложил структуру языков паттернов для предметных областей: это я говорю другими словами: “делаю Engineering DPF Suite”. Идеи оформляются в виде практических/деятельностных единиц знания – паттернов. Паттерн даёт акаузальное описание метода: что делать в узнаваемой проблемной ситуации и к чему это должно привести. Учебная показательная развёртка happy path (мы называем её “мантрой”) добавляет порядок показа и помогает управлять вниманием, хотя сам порядок ещё не является указанием причинности для планирования работ, скорее, причинности для объяснений;
Уже начерно сделан DPF системной инженерии, 0.8M (24 паттерна с Readme и предисловием), его уже пробуют – и радуются, что работает. У меня много вопросов к этому DPF, но как MVP это вполне сойдёт. Уже начерно сделан DPF по музыке и танцам, он поменьше, 0.7M (22 паттерна с Readme и предисловием), это стресс-тест для DPF по системной инженерии, ибо музыка-танцы тут рассматриваются системноинженерно. Уже начерно сделан Method Engineering DPF, 0.6M (17 паттернов, тоже с readme и предисловием), чтобы закрепить полииерархическую методологию, а также ввести управление вниманием к методам в проекте. Для управления вниманием как “общая для всех система”, к которой привязывается системная мантра, служит система в роли целевой системы проекта. А для метода такой привязки нет. Я не думаю, что это окончательное решение, но project Method-of-interest пока определён как общий объект внимания в проекте, и (как и с целевой системой проекта) надо будет довольно долго понимать, какой именно метод занимает эту роль. Я склоняюсь приклеить это к методу, которым делается проект в целом, то есть делается целевая система в целом.
следующими будем писать все остальные DPF. Всего в принятой подробной архитектуре 14 DPF и 255 планируемых паттернов. Попутно делаем пополнение и правку паттернов FPF, чтобы всё это согласовать с текущей версией FPF. Ещё пишем Engineering DPF Suite Reference, чтобы было понимание, что и почему входит в этот Engineering DPF Suite.
Последним в планируемый состав Engineering DPF Suite добавился Embodied Rhythmics Principles Framework. Это я дорвался до того, о чём пишут во всех лентах про AI-native разработку: попробовать заветные мечты оказывается относительно дёшево. Сам FPF примерно на 300 паттернов, ещё десяток трансдисциплинарных паттернов уже запланирован и потихоньку разрабатывается в не очень длинной очереди. Так что размер Engineering DPF Suite как текущей выжимки из руководств R0, R5-R10 получается сравнимого с FPF размера. Тут, конечно, надо учесть, что в текущих моих руководствах много такого, что уже находится в FPF как трансдисциплинарное содержание: планируемые паттерны DPF – не трансдисциплинарное, а прикладное содержание.

Паттерн как единица описания мастерства
Дальше нужна методологическая основа учебного продукта: ответ на вопрос “чему учить”. Тут у меня сначала была модель попроще: на входе множество освоенных паттернов, на выходе другое множество, а их разность – “дельта обучения”. После двух подробных разборов терминологии с GPT-5.6 Pro стало понятно, что одним словом там называлось разное:

Паттерн – единица представления и организации описания метода. Классика, записано в FPF.
Владение методом приходится описывать отдельно от паттерна. Агент (в том числе и человек) может узнать название паттерна и пересказать его, но не распознать ситуацию, где он нужен; может развернуть метод по мантре с подсказками, но не выбрать его среди альтернатив по норме традиционных языков паттернов; может уверенно применять метод в знакомом случае, но не перенести в новый. Поэтому “освоил паттерн” надо разворачивать в проверяемое утверждение: кто умеет что именно делать с каким паттерном или набором паттернов, в каких ситуациях, с какими средствами, с какой самостоятельностью и с каким качеством результата. “Освоил” надо рассматривать так же дробно и раскрывать, как и любое “готово”, “согласовано” и т.д. – у нас про точность языка был четвёртый семинар в серии из пяти семинаров по FPF.

Разбираемся с этим пока на двух масштабах:

Для масштаба репертуара паттернов рабочей роли есть capability gap: человек, киберличность или команда пока не способны играть целевую роль с нужной степенью мастерства, то есть в реальной рабочей ситуации с реальными помехами со стороны окружения, с реальным отвлечением внимания выбирать и исполнять подходящие методы, описанные паттернами.
Для масштаба репертуара паттернов учебной программы этот разрыв разворачивается в proficiency gap – разрыв между нынешней и целевой оценками владения методами из этого репертуара паттернов. В образовательной литературе часто пишут competency gap, но competency слишком легко прочитать как ещё один пункт образовательного стандарта. Мне важнее способность действовать в роли и уровень владения нужными для неё методами (а паттерны тут – удобный формат описания этих методов, с которым понятно, какими методами работать).

Получается такая методологическая (“чему учить”, а не методическая “как учить”) машинка по созданию кастомизированной учебной программы в формате репертуара паттернов, описывающих осваиваемые в разной степени целевые методы работы:

по данным о текущих умениях (можно думать о том, как их получить: прямое тестирование или берём какие-то прокси вроде выполняемых в прошлом работ и оценки успешности их выполнения) строим текущую оценку того, какие паттерны человек умеет распознавать, выбирать, применять, проверять, адаптировать и комбинировать, в каких ситуациях, с какой самостоятельностью и надёжностью. В такой оценке “владения методами, данными в наборе/репертуаре паттернов” различаются случаи: какие-то паттерны (паттерны работы!) человек только узнаёт, но не может их применить, а какие-то использует настолько автоматически, что их задействование не выходит на уровень сознания. Вместе с такой оценкой хранятся логи наблюдаемых действий, созданные рабочие продукты, условия их получения, даты и оценки неопределённости – и сразу понятно, что получить такую оценку хоть сколь-нибудь надёжно невозможно, но критики (прежде всего AI-агенты с FPF) будут настаивать. Это отдельный вопрос, что делать с оценками такого сорта: доказательная learning science имеет примерно те же проблемы, что доказательная медицина и доказательная экономика – Pearl смеётся над всеми этими потугами каждый день, но воз и ныне там. Вообще, в FPF надо как-то поддержать эти “доказательные дисциплины” с их видимыми недостатками невозможности доказываемости (начиная с имени: фальсифицировать можно, доказать – нельзя).
выбираем целевой репертуар паттернов. Самое хитрое место, об этом раздел ниже: тут надо сочетать exploitation (выучивание игры по целевым ролям) и exploration (выучивание работы по методам трансдисциплинарного мышления и общепроектного действия).
в том же формате паттернов и ожидаемых результатов замеров в проверках задаём целевое владение методами и сразу описываем ситуации и задачи, на которых будем проверять игру по роли – задействование паттернов, выполнение работы по норме. Это классический ATDD (acceptance test-driven development): спецификация того, что создаём, задаётся сразу как программа испытаний, набор тестов. Опять же, 85% времени и сил на тестирование – это типовое в разработке инженерных систем и софта. Но что скажут люди, которых будут тестировать 85% времени, а 15% учить? Ну и если это софт, то можно пройти все тесты – и считать, что “всё работает как надо”. А если это люди, то они соптимизируют: подготовятся не к работе, а к сдаче экзамена.
разрыв между нынешней и целевой оценками владения методами – proficiency gap. Из него с учётом времени, зависимостей, ожидаемой пользы и допустимой помощи выбирается приоритетный набор learning targets. Learning gain, а точнее proficiency gain, – фактически обнаруженное и подтверждённое изменение владения методами после обучения;
число вошедших в планируемый репертуар паттернов показывает охват содержания, но не величину приращения мастерства. Паттерны разномасштабны, разные уровни владения одним паттерном дают разные результаты, а полезность часто возникает при композиции нескольких паттернов или после закрытия одного блокирующего пробела;
для группы строится распределение индивидуальных proficiency gaps. Из него можно выбрать общее ядро learning targets, максимизирующее пользу программы для группы, и оставить персонализированные хвосты учебных маршрутов. Если целевая система – команда, отдельно оценивается capability команды и координация индивидуальных умений.
строим варианты куррикулума (программы освоения заданного репертуара) и сравниваем их с учётом доступного времени и ожидаемой скорости развития владения методами при нынешней методике обучения. Тут первое замечание в том, что мы описываем мантру, базирующуюся на декларативной развёртке структуры работы машинки создания кастомизированной учебной программы. Когда строим варианты куррикулума, то они существенно ограничивают задание репертуара целевых методов: в трёхмесячное обучение не впихнёшь владение репертуаром, которым можно овладеть за год, а в годовое не впихнёшь то, что поддаётся трёхлетнему обучению. Люди учатся медленно, у них буквально отрастают синапсы, улучшается капиллярная сеть для кровоснабжения каких-то групп нейронов, а это скорость отрастания нервной ткани, дико медленная (медленнее, чем у мышечной ткани). И вот эта скорость при заданном интервале обучения сильно ограничивает предыдущее решение по выбору потребного репертуара. “Хочу быть концертирующим пианистом, на это у меня три месяца” – не работает. Второе замечание терминологическое: учебная программа имеет два значения – репертуар методов (чему учить, формат справочника) и куррикулум, то есть последовательность применения методов “как учить”. Мы пытаемся развести эти значения, поэтому и слова разные.

Текущая оценка владения методами получается в форме модели мастерства как модели “владения методами” (входная и выходная модели мастерства): она связывает выбранный репертуар методов с наблюдаемыми действиями человека в значимых рабочих ситуациях. Один паттерн может требовать нескольких различений и приёмов; несколько паттернов могут совместно поддерживать одно умение (скажем, в FPF и DPF такие умения решать затруднения выносятся с их мантрами в карточки практического использования в README). Целостная рабочая задача обычно требует задействования очень многих умений, самого разного мастерства. В DPF методологии даётся довольно развитая онтология полииерархии методов, поэтому что-то обсуждать тут можно после готовности этого DPF. Гранулярность придётся проверять по тому, насколько модель мастерства как “владения методами” помогает предсказывать исполнение роли в новых ситуациях, а не по красоте каталога.

Для задания входной и выходной моделей степени мастерства (то есть оценок владения методами), промежуточных замеров в ходе длительного обучения и планирования учебных работ ближе всего к SoTA так называемый expanded Evidence-Centered Design (eECD): отдельно моделируется, о каком умении делается вывод, какая задача должна вызвать диагностичное поведение и почему наблюдаемые действия и рабочие продукты дают основания для этого вывода. Для обучения добавляется ещё и предполагаемый переход: что должно измениться, какая поддержка этому поможет и какие наблюдения позволят заключить, что переход действительно произошёл (Frontiers | The Expanded Evidence-Centered Design (e-ECD) for Learning and Assessment Systems: A Framework for Incorporating Learning Goals and Processes Within Assessment Design). Это всё абсолютно рационально и инженерно, мы и сами всё это написали, но этот eECD нужен для того, чтобы прихватить терминологию – а затем по этой терминологии таскать конкретные прикладные приёмы, до которых дошли в learning sciences.

ATDD как извод BDD отлично подходит для формулировки входных и выходных замеров/тестов на языке, знакомом инженерам. На этом языке Given задаёт рабочую ситуацию, ограничения и доступные средства; When – действие человека (в общем случае – агента) в проверяемой роли; Then – наблюдаемый результат, характеристики хода работы и следы/traces/логи, по которым пересматривается текущая оценка степени мастерства (владения методами). Главный вопрос остаётся прежним: почему это наблюдение даёт основания ожидать, что в другой релевантной ситуации человек снова выберет и исполнит подходящий метод? Для такого вывода нужны варьирование условий и хотя бы одна задача на перенос, а воспроизведения один раз показанного happy path мало.

В AI-native обучении надо явно фиксировать носителя проверяемой способности. Человек без AI, человек с AI-экзокортексом и целая команда “люди + агенты + рабочая среда” – разные обладатели целевых capabilities. Тут много нюансов – надо отдельно определять, что в той учебной машинке, которая строится, общее для агентов, а что только для людей. Более того, учить можно и организации – умеют ли они что-то делать как целая организация, и на какой степени мастерства.

Виды работ в развитии
Выбор следующей задачи развития, проектирование куррикулума для неё, развитие способности/capability ученика (собственно обучение), замеры способности (тестирование/испытания/проверки) тесно связаны, но в каждом потоке меняется свой целевой объект. Если представить их одной мантрой “надо научить тому-то, выбрали паттерны, составили программу, провели обучение, получили данные испытаний, пересмотрели оценку владения методами, порекомендовали продолжение – вернулись к началу”, потеряются внутренние мантры каждого шага, а они есть:

при проектировании репертуара методов для развития агента нужны описания методов работы в осваиваемой роли и ситуаций её исполнения – это как раз дают паттерны. Но ещё нужны нынешняя оценка владения нужными методами, целевая оценка владения ими, ограничения по времени и ожидаемая польза (часто там польза для обучаемого, но и для других проектных ролей – работодателей, родителей, коллег, участников какого-то community of practice и т.д.). Результат – задание на обучение, “чему учить”, итоговая методологическая работа. Тут много подводных камней. Например, вы собираетесь учить чему-то такому, для чего вообще ещё не делалось описаний – нет доступных языков паттернов. Можно выбирать и такое, рассматривая паттерны как решения проблем в интересных предметных областях. Отсутствие паттерна в экосистеме FPF означает как минимум два разных случая. Известный SoTA-метод может быть ещё просто не описан в формате DPF – тогда надо подготовить описание. Подходящего метода может ещё не быть или его основания могут быть сомнительны – тогда нужна исследовательская работа. Или важен полный стек методов (как в руководстве по системному мышлению приведён стек методов, по которому можно учить танцоров – все эти методы требуют разных описаний, ибо между ними метахолонные переходы). Обратная связь тут будет от того, что скажут методисты, которые готовят куррикулум и проектируют возможный достигаемый им результат. И тут ещё обратный ход от обучения к развитию экосистемы FPF. Если несколько репертуаров методов упираются в одну и ту же дыру в этой экосистеме, её можно один раз закрыть исследованием и результирующим новым или исправленным паттерном (DPF), а не заниматься исследованием каждый раз для каждого отдельного требуемого репертуара методов.
методическая работа: на входе у неё – результаты методологической работы, а также знания о доступных ресурсах и времени для учебного процесса, начальном уровне владения методом у ученика, а также тонких моментах вроде честной оценки мотивации, умений наставников и прочих возможных осложнений. На выходе у неё – куррикулум. Но тут тоже обратные связи. Если куррикулум заведомо не достигает целевой степени мастерства на доступных ресурсах, то методологам посылается сигнал урезать запланированный ими репертуар методов и целевую степень мастерства в них с мотивировкой “чудес не бывает”. И тут же – характеризация: каких характеристик мастерства надо достичь. Это знает как раз методолог.
при собственно развитии способности агент (человек, робот, организация) учится играть выбранную роль: распознавать рабочую ситуацию, выбирать и исполнять подходящий метод, проверять результат, получать обратную связь и исправлять ошибки – делая это всё более и более бегло, а также переходя “на автомат” по мере освоения отдельных операций в решётке метода (будем честны: там не стек методов, а решётка – объект, хорошо знакомый онтологам. Вот с методами тоже она, про “вертикаль” и “горизонталь” в ней мы уже упоминали). Методика обучения задаёт учебные задачи, поддержку наставников (и справочников вроде освоения чтения иностранных текстов “со словарём”) и порядок её снятия, все формулировки про “зону ближнего развития” как раз про это – “возможность что-то сделать с наставником, чтобы получить возможность что-то сделать без наставника”. Способность именно этого человека играть роль меняется через его учебную и рабочую практику, мозг должен работать, чтобы выучиться. Хотя AI-агенты просто “читают” – и готовы. Ну вроде как Нео получал загрузку в мозг искусства управления вертолётом. Увы, это только в Голливуде, а в жизни – только у роботов так.
при проверке способности человек решает диагностическую (хуже: ситуация “экзамена”, лишние тесты и закон Гудхарта) или проектную рабочую задачу (правильно!) в этой роли. Наблюдаемые действия, созданные им рабочие продукты и следы решения задачи используются как основания для вывода о том, какими методами, в каких ситуациях, с какой самостоятельностью и надёжностью он способен пользоваться. Результат этого вида работ – пересмотренная текущая оценка владения методами, “модель степени мастерства”; возможное изменение самой способности во время диагностической работы оценивается отдельно (оно есть! И в FPF есть паттерн квантовоподобности – он ровно про это: изменение системы от её замера. Хауторнский эффект тут самое простое проявление). Тут много чего на входе и много чего на выходе. Изменения по нескольким характеристикам дают вектор прироста владения методом, который иногда сворачивают в одно число для решения о продолжении программы – и вот это сворачивание в скаляр вполне себе “зло”, часто являющееся “меньшим злом”. Ещё дальше можно проверять полезность нового мастерства лонгитюдно (“выучился читать на суахили, но зря, ничего на нём пять лет не читал”);
при прохождении куррикулума всё не так просто: похоже, на входе он будет планом работ, который годен только для того, чтобы оценить потребные ресурсы – а потом его надо выбросить, ибо сам процесс идёт agile, планирование следующей учебной задачи идёт on the fly, текущая оценка владения методами, целевая способность/capability, ограничения и уже накопленный опыт (подтверждённый замерами) используются для выбора задачи и допустимой поддержки. Выполнение задачи даёт новые наблюдения и рабочие продукты, оценка владения методами пересматривается, и следующая задача может оказаться другой. Этот контур связывает проектирование, практику и проверку, сохраняя отдельные решения и результаты каждого потока. В принципе, тут подходят описания самых разных циклов улучшений, например, open-ended evolution с проблематизацией и научением решать проблемы.
и это не конец списка. Ещё ведь Platform Engineering для всего этого, организация потока студентов и т.д. – в руководстве по инженерии мастерства даны более подробные описания.

Agile планирование развития
Выбор учебной программы (репертуар и его куррикулум) и выбор следующего учебного хода – два масштаба, но по большому счёту это одна и та же задача. Абсолютно характерное холоническое рассмотрение, “одно и то же на разных масштабах” (часто тут говорят “рекурсивное рассмотрение” вроде “рекурсивное применение системного мышления” или “рекурсивное применение инженерного процесса”). Да, конечно, методы в силу метахолонного перехода меняются на этих масштабах, но всё-таки инварианты рассмотрения остаются. На длинном масштабе выбирается программа или несколько недоминируемых продолжений; на коротком – следующая учебная работа как “маленькая программа” и условие пересмотра. В общем случае – горизонтов планирования может быть несколько, приём, хорошо известный (“долгосрочные, среднесрочные, краткосрочные планы” – это сразу три уровня). Паттерн тут будет основной единицей содержания на среднем уровне, DPF (который легко и сам представить “большим паттерном”) на более высоком, а на более низком – локальная мантра паттерна (которую тоже легко представить паттерном на каждом её шаге).

В ходе обучения можно или начинать заниматься новым DPF, паттерном, шагом локальной мантры паттерна (в зависимости от того, какой масштаб вы посчитали “ходом обучения”), или углублять владение уже знакомым, проверять то, что осталось неясным в текущей оценке владения методами, можно давать интегративную работу на композицию методов, ремонтировать ошибочную концептуализацию в мышлении, тренировать перенос в другие контексты или возвращать забытое умение. Выбор следующего хода должен учитывать как минимум вероятность успеха сейчас, ожидаемое после планируемого учебного хода изменение способности, ближайшую рабочую полезность, открываемые на более высоких масштабах продолжения развития, стоимость времени, внимания и просто денег. Тут могут быть самые разные ситуации: иногда следующая работа нужна главным образом затем, чтобы выяснить, что человек уже умеет.

Тут и встречаются exploitation и exploration. Exploitation добирает полный поддерживающий набор DPF, паттернов, шагов локальной мантры (на разных масштабах суть дела одна и та же) и практики до мастерства в какой-то роли: участие метода паттерна (подставляйте сами каждый раз DPF или паттерны какой-то мантры из entry card, или локальные шаги мантры – в зависимости от масштаба) в степени мастерства/способности/capability ещё не даёт возможности выполнить работу, требующую многих паттернов. Exploration расширяет набор будущих достижимых способностей, в том числе через трансдисциплинарные знания и неожиданные интересы. Стратегия (метод, выбранный для обучения) чередует эти режимы: exploration открывает будущие способности, exploitation доводит выбранные способности до исполнения роли. Рекомендательные алгоритмы музыкальных сервисов, которые пытаются «развивать вкус», но при этом играют любимые жанры, тут хороший образец, его вполне можно использовать для создания учебных программ бесконечного развития: составление куррикулума сводится к выдаче рекомендаций. Конечно, натяжка тут некоторая есть, но уж больно похожи задачи! Для пущей математизации есть и более прямая линия trajectory-based recommender systems: долгосрочную рекомендацию предлагают рассматривать как управление траекторией, в том числе образовательной ([2606.22957] Trajectory-Based Recommender Systems as Control Systems). У нас задача чуть шире: меняются состояние мастерства ученика, следующий учебный ход и доступный для обучения корпус методов (экосистема FPF).

Маржинальное мышление (прирост мастерства небольшими инкрементами) тут действительно центральное: ценность очередного куска знания зависит от того, что уже освоено, что осталось добрать до возможности выполнять работу по роли и какие продолжения в выполнении каких работ по каким ролям открываются после обучения. Вариационное исчисление становится подходящей math lens, если у нас действительно принята линия варьируемых образовательных траекторий.

Изменение корпуса методов иногда требует обновить уже сформированное мастерство, “переучиться наново”. Когда изменился DPF, прежний способ принимать рабочее решение надо переучить. Значит, “история освоения должна хранить редакции, условия и дату, после которой прежние наблюдения и рабочие продукты уже нельзя без новой проверки использовать для вывода о нынешнем владении методами”. Это, конечно, легче сформулировать вот таким казённым языком, но нелегко реализовать – при этом казённый язык будет давать AI-агентам повод лишний раз насыпать соль на эту рану. Рекомендатель учебного хода (может, это так надо называть в траекторном подходе?) должен уметь предложить переход со старой уже не-SoTA практики на новую или со старого уже не-SoTA метода на новый. Первым случаем может стать переход для освоивших работу по руководствам R5-R10: какие рабочие решения после нынешней пересборки они должны принимать иначе и чему для этого доучиться? Это вполне актуальная задача, можно уже планировать её решение. По идее, подписка на материалы МИМ должна решать не только задачи развития инженеров-менеджеров в плане прихвата нового мастерства, но и обслуживать обновление имеющегося мастерства до SoTA. Скажем, они все выучили, что “онтология – это важно, это наше всё”, а сейчас надо понимать, что онтология только часть важного: онтология не говорит, что делать, она только задаёт предметы для действий, а надо ведь знать, что делать! Поэтому методология таки важнее, онтология подчинена методологическим задачам (это и сейчас говорится, но судя по обсуждениям в чатах, не понято из текущих R1-R10, поэтому надо бы всех инженеров-менеджеров переучить).

Дальше нужны прикладные какие-то продуктные действия:

для выбранных целей обучения – приоритетной части разрыва между нынешней и целевой оценками владения методами – формулируем самые разные учебные программы B2C и B2B, и для “новеньких”, и для “стареньких”: разные исходные оценки владения, разные продолжительности, разные желаемые уровни мастерства. Между нынешней и целевой оценками строится выбранный план учебной работы: нарратив, практикум, поддержка и последовательное снятие поддержки;
генерируем учебные нарративы с картинками (руководства) для этих учебных программ;
ведём резидентуры, получаем инженеров-менеджеров – и проверяем, какие роли они научились играть, в каких ситуациях им это удаётся, какие методы удержали и куда смогли их перенести;
по новым замерам их мастерства, их итоговым рабочим продуктам пересматриваем текущую оценку владения методами (квалифицирование, но более детальное) и рекомендуем какое-то продолжение (этот Рекомендатель, конечно, надо ещё сделать).

Авантюра: экспериментальные лабораторные результаты – прямо в руководства
Всё это примерно такая же авантюра, какую я делал в 2012-2015 годах, когда только-только начинал преподавать системную инженерию, потом ещё и системное мышление, потом ещё и системный менеджмент и стратегирование. Слайдов не было, вещалось всё “с голоса”, курсы (тогда это были университетские курсы и курсы ШСМ) были короткие, пару раз переписывал учебник системноинженерного мышления (читать без слёз было нельзя), потом появился полностью не удовлетворяющий меня видеокурс системного мышления, и сразу вместе с ним – текст учебника; менеджмент давался со слайдов устно, потом сделали видео, потом-потом-потом только написал учебник. Всё это переписывалось десяток раз, сейчас уже заматерело и хорошего качества.

Но пришла AI-native разработка, и я решил всю эту линию бросить и заново собрать SoTA-решения самых разных проблем под одной обложкой. Я делю написание учебников на методологическую работу “собрать под одной обложкой то, чему нужно учить” и методическую – переписать много раз так, чтобы был внятный учебник. Вот FPF (примерно соответствует интеллект-стеку) и Engineering DPF Suite (примерно соответствует R5-R10) пока в стадии “собрать под одной обложкой”. Они свеженькие, кривенькие, решают многочисленные проблемы, которые не решали руководства:

формат “энциклопедии”, “справочника”, из которого будет генерироваться много учебных форм. Методология и методика будут разделены;
методы SoTA, а не предыдущих поколений инженерных процессов;
культурная эволюция, многоуровневость методов, холоничность, конструктивная онтология – всё, что годами откладывалось “на потом”, все “исследовательские заделы” – вот они прямо сейчас реализуются;
если кто захочет приобщиться к этому SoTA-знанию, то придётся мириться с несовершенством формы. Но зато содержание там – огонь огненный. Те, кто пришёл ко мне на серию из пяти семинаров, в этом убедились. Передаётся понимание текущей технологической ситуации, а не глянцевое содержание академической дисциплины. Ибо если потратить время на наведение глянца – жизнь уедет вперёд. Конечно, глянец наводится, AI-агенты в этом в помощь, но либо я пару лет вручную редактирую весь текущий материал (цикл прохода по руководствам моей ручной правкой на fulltime – как раз пара лет), либо я рассказываю текущий материал прямо сегодня. Образ – “профессор вышел из лаборатории к студентам и рассказал им то, чем занимался на этой неделе, ибо никаких учебников ещё не написано”;
содержание нового корпуса отбирается заново: набор паттернов не будет соответствовать прежним руководствам, и выбор идей для инженеров-менеджеров в нашей мастерской будет другим. Сохранившиеся идеи тоже даются другим языком и в другой онтологии;
я точно не прослежу за точностью и понятностью всех деталей, но я сделаю какой-то набросок общей архитектуры, которую можно будет обсуждать. А пока слышу претензии не к слону, а к верёвке (но это хвост слона), столбам (но это ноги слона) и так далее – я постараюсь выкатить кривую, потому как банально нет времени выправлять, архитектуру, но целиком и работающую – для начала экосистему FPF и какую-то машинку по созданию руководств из материалов семинаров и FPF+DPF. А потом версия за версией эту архитектуру развивать. Так всегда делал, по-другому не получится. Собственно, сам FPF я так же делал – собирал его до такого уровня, когда стало очевидно, что он хорошо работает, стало очевидно, что это такое. На начальных же стадиях работы было абсолютно непонятно, что это (впрочем, многим непонятно и сейчас – но можно посмотреть в GitHub – GitHub - ailev/FPF: First Principles Framework (FPF): Pattern language and core specification for admissible action in problematic engineering, research, and mixed human/AI work. · GitHub).