Провёл вчера четвёртый семинар по использованию FPF в рабочих проектах. Участники были ровно в том же составе, никого не потеряли – 91 человек четвёртый семинар подряд. В чате – очередные истории успеха. Тема – про важность явной работы с языком, затрачиваемые на это ресурсы, онтологию описывания чего бы то ни было (EntityOfConcern) через ходы на эпистемы, публикации, формы публикаций, носители, а также view и viewpoints и даже вопрос о том, сколько времени мы экономим, если вдруг заморачиваемся проблемой точного языка (хинт: разговоры в итоге будут не короче, а чуть-чуть длиннее, зато будет меньше времени проекта, ибо станет меньше rework из-за “я тебя не так понял”). На семинаре я выкатил “слайдомент-полуруководство” на 164 слайда с учебными красочными плакатами на них, там ещё и слайды с описанием практикумов, но рассказывал я больше байки, чем раскрывал содержание слайдов (слайды можно прочесть, всё непонятное спросить у AI-агента, которому дали FPF). Про FPF не было ещё русскоязычных текстов, вот я и написал 1M знаков (примерно 700 страниц) вот эти слайдоменты к семинару. В FPF 12M знаков на английском, в материалах семинара об этом 1M знаков по-русски только в текстовой части (и ещё сотни картинок!), это масштаб примерно 1:10, хотя семинары закрывают не все темы, которые поддерживает FPF. Можно обсуждать качество этих текстов, но главное их качество в том, что они полезны (благодарности в чат уже пишут, “слайды помогают”), и они вообще есть – я смог их подготовить. Этот проект с “полуруководствами” как раз пример AI-native разработки не программистского кода, а чего-то другого, и даже не FPF, в котором нет нарративизации, нет картинок, нет целей “научить”. Но это всё-таки AI-native непрограммистская разработка, а на семинарах я привожу её как пример такой разработки с использованием FPF, показываю трудности, даю оценки потребных ресурсов. Основной объём моего письма сейчас идёт не в блог, не в какие-то руководства и даже не в чаты Codex App, а в чаты семинара – я там ой-ой-ой сколько уже написал. Через неделю последний семинар серии, черновик слайдомента к нему уже готов – и в нём 144 слайда с картинками и табличками. Конечно, я буду его ещё дорабатывать.
Всё-таки мощь трансдисциплинарного фреймворка удивительна. У меня в участниках семинара проекты и AI-native разработки софта (как же без них!), и программ детского садика (даже яслей) Монтессори, и разработки стандартов проектного управления для немаленькой отрасли (ну, или немаленькой госкомпании – в чате активно обсуждается, чем отличаются и какой онтологический статус “отрасли” и почему про госкомпанию вообще оговаривают “отрасль” – FPF всё это ловит, хотя и не совсем автомагически), и строительные проекты, и много чего ещё столь же разного. Основная проблема этого семинара: формально он вроде посвящён FPF, а вопросы всплывают про то, какие есть SoTA методы работы. То есть обсуждаем не FPF и как им пользоваться, а “как работать” – другая тема! То есть не “как донести мысль до AI-агента”, а “как донести мысль до коллег-людей” (и дальше уже неважно, эту мысль “сам придумал” или “AI-агент подсказал”). После завершения всей серии надо будет крепко подумать, какое должно быть продолжение проекта – вряд ли “повторить серию”, хотя может быть и вариант “продолжить серию”. В ней ведь всего пять тем, легко можно предложить ещё несколько тем, которые в FPF представлены множеством паттернов, но в текущих семинарах не затронуты.
Онтологический ремонт FPF продолжается, масштабы недетские: в самом FPF 104 тыс. строк (те самые 12MB), за период с 3 июля по 3 августа было добавлено 30066 строк и удалено 20221 строк – правилась примерно треть FPF. Вот оно – бесконечное развитие, continuous development, continuous integration, continuous delivering. И это ещё не конец всей истории, поскольку сегодня пошёл ремонт в кампании R3 – Governed-subject pattern relations and declarative neighboring-pattern language (уже написан и сейчас проверяется DRR для этой кампании). А ещё в плане R4 (Role ontology and wording-use precision restoration) и R5 (Relation-ontology corpus projection and structure harmonization – завершающая чистка оставшихся онтологических хвостов после проходов R1-4). И тогда заживём! Что, впрочем, сомнительно. Планов громадьё:
- семинар начался с идеи рассказать по-русски про то, что есть в FPF, ибо никто этого по факту не знал. Пять тем, пять интересных новинок. Но на семинар записалась почти сотня наших инженеров-менеджеров, стартовал ремонт онтологии – и вся ситуация точно попала в предмет паттерна ## C.36 - Cultural Evolution and Cultural-Evolution Engineering. Поэтому ситуация семинара интересна как стресс-тест в описании многоуровневой культурной и технической эволюции – это методология. Нет, это не тот же ход, который делают СМД-методологи, в сотый и тысячный раз разбирая по косточкам историю ММК – пример какой-то культурной эволюции, хорошо знакомый всем участникам. И не чистое “community management”, хотя и этот аспект для МИМ весьма интересен. Это зародыш культуры использования FPF в рабочих проектах: сообщество, в котором есть канон, варианты канона, обучение новеньких, применение канона в проектах, вовлекаемые в использование канона не совсем живые агенты, отбор удачных ходов и изменение общего корпуса как трансдисциплинарных, так и предметных знаний (всё это подробно обсуждает C.36). Если это культура, то она практикуется в рабочих проектах – и тогда надо делать разборы настоящих рабочих ситуаций, чтобы получить проблематизацию. Что именно обнаружилось: дефицит FPF? DPF? Недостаток квалификации инженера-менеджера и надо менять “то, что у нас служит руководством”? Сбои местного LPF или это специфика данного проекта (скажем, госпроект, который заведомо будет неудачным)? В принципе, чаты семинаров хорошее место, чтобы после окончания серии продолжать этот разговор. И уже от выявленных проблем планировать и изменения FPF, и изменения в программах резидентур МИМ.
- ещё по той же линии проблематизации – посмотреть через тот же паттерн культурной эволюции и инженерии культуры C.36 вариант культурной эволюции в социальных танцах, описание их эволюции через уровни и межуровневые конфликты. Заделы тут есть (скажем, идея импровизации – Методология кейс-менеджмента, диджейской, джазовой, кулинарной, танцевальной импровизации : ailev — ЖЖ, или идея развития музыки и танцев как преодоления многоуровневых конфликтов в ходе OEE – lytdybr: ailev — ЖЖ), но все эти заделы надо доделать. У меня есть ощущение, что сильные ходы компактификации многих и многих ситуаций появятся отсюда: архитектурная работа с многоуровневыми нестандартными структурами в их эволюционной динамике. Это тема “бесконечного развития”: без проблематизации можно незаметно для себя закиснуть – и культура вымрет.
- и после этих двух очевидных ходов (сообщество FPF-практики, community of practice для FPF, сообщество социальных танцоров) можно пообсуждать и эволюцию корпоративной культуры, ходы на всяческие “реформы” и “радикальные новации”. Без проблематизации плохо. Если внимательно посмотреть, то все ходы ниже – это чистить-блистить уже найденные решения. А тут есть шанс двинуть фронтир. Но пока надо проверить хотя бы C.36 – какие отношения между каноном, реальным репертуаром, обучением, признанием и посредниками действительно нужны, чтобы вариант распространялся и становился рабочим, а не просто заметным? Если C.36 не различает в этих случаях режим реального применения и режим видимости/признания, не даёт solution в виде рабочих инженерных ходов, а просто даёт онтологию-лексику, то это архитектурная дыра, которую надо латать. При этом хорошо понятно, что затыкать такую дыру надо примерно так же, как с нарративистикой: там тоже один паттерн в FPF, а много прикладных паттернов вытеснены в DPF. В культурном строительстве (назовём это и так тоже) тоже должен появиться свой DPF. Может быть, с него эту культурную линию и начать – как я начал подготовку семинара с создания DPF по нарративистике.
- ещё одно исследование по линии не методологии, а методики – это learning sciences, разрыв между “обучением объяснением” (для рационального мозга) и “обучением повторением” (для нейросетки и пластичного мозга – всё должно запомниться, а нервная ткань должна отрасти). Хороший тест тут – те же танцы как смесь “танцев по правилам”, зыбкости правил в ходе культурной эволюции, но ещё и научение сложным координациям, которые легко отрабатываются в медленном сознательном режиме, но в реальном времени требуют для отработки тысяч повторений, многих лет практики (и тут примеры спортивных обучающих практик, музыкальных обучающих практик и только дальше менее многочисленных танцевальных обучающих практик). Заделы тут тоже есть, а пример важности – обучение иностранным языкам или языкам программирования (где можно ещё пообсуждать их многоуровневость, ибо внимание к одному уровню – а проверка-то затрагивает много уровней умений!). Скажем, NSTD.8 из DPF нарративистики даёт очевидное: справочник с объяснениями и учебник для приобретения беглости в использовании имеют разные архитектуры. И вот тут легко представить отдачу всего методологического богатства FPF для объяснения силами AI-агентов, но какое тогда малое ядро надо усвоить в дорогом для человека ходе обучения? Не хотелось бы повторять плохой пример обычного образования, где учат “разделам наук”, но не учат мышлению, которое позволяет в этих разделах ориентироваться. Какой минимум надо загрузить в мозг человека как “начальный загрузчик” разных других знаний, которые могут быть доступны в форме справочного материала и эпизодических объяснений, но не обязательны к “налёту часов” при загрузке в мозг для получения беглости? Что должно стать автоматическим у человека, если агент уже способен немедленно прочитать FPF и предложить ответ на вопрос? Понятно, что “умение сформулировать вопрос и понять ответ” – но это общие слова, а надо бы конкретно. Точно не надо знать, что там в 293 паттернах!
- в порядке “цикла непрерывных улучшений” я хотел бы сделать архитектурную чистку FPF, более детально прописав устройство экосистемы FPF, DPF, LPF. После моих семинаров люди массово начнут писать добавочки и расширения, архитектура должна будет не только выдержать эти расширения, но и поддержать их. Проблематизация тут уже была, дальше надо почиститься и дополниться – чтобы отмасштабироваться, переварить все возможные вклады в экосистему. И ещё тут тоже проблема: разнообразие LPF и явный недостаток “новой компьютерной грамотности”, и ещё потихоньку переползание know-how разработчиков harness в commodity софт вроде Codex, Claude Code, Cursor.
- онтологическая чистка: в FPF наверняка сейчас есть попытки вырастить отдельные онтологии там, где уже есть какие-то (скажем, одну такую попытку вырастить дубль декларативной онтологии CGUS и структуры потоков преобразований я только что пресёк при подготовке DRR для декларативной работы с паттернами, но сколько подобных попыток осталось непресечёнными? Я уже несколько раз схлопывал разные онтологии и лексики, получающиеся из различия EoC и описания – и это тоже только что опять начало появляться). Цель? Не только предотвращение онтологических коллизий, но и компактификация FPF. Риск? Обычно одна онтология – это опасно, надо как-то явно предусмотреть возможность использования множества онтологий (“онтология множественности онтологий”, мета-онтология – вечные проблемы экспертных систем).
- я не устаю повторять, что онтология – это 10% из того, что важно. Надо докрутить FPF в сторону “паттерны описывают методы, которые меняют следующие ходы проектов, а не просто дают онтологию”. В FPF множество очень древних паттернов, которые никто никогда не проверял так, как проверялись новые паттерны. Вот взять – и проверить, поднять качество каждого паттерна, всех 293 штук (их сейчас столько). В результате ожидаю чуть меньшую “академичность” и чуть большую “пользу инженерам”.
- добавить материал из руководства по интеллект-стеку
- с учётом того, что у нас уже экосистема, отжать в формат паттернов материалы моих руководств – часть материалов в сам FPF, но часть – в соответствующие DPF. Заодно проверить, остаётся ли это у нас SoTA. В ходе семинара это уже началось (начали перетаскивать понятие целевой системы проекта, как-то втащили case management).
- разобраться с возможными учебными нарративами (первая попытка тут – слайдоменты семинаров, но я описывал возможные ходы на кастомизацию этих нарративов в третьем абзаце по адресу lytdybr: ailev — ЖЖ). Это обратный ход – создание кастомизированных руководств на базе FPF.
- более чётко выраженная опора на математику и физику (вариант “для МФТИ”, по большому счёту – это тот же ход на сообщества и культурную эволюцию, но это немного другая “тусовка”, чем тусовка “применятелей классического варианта FPF в рабочих проектах”), прихват математического и физического мышления как основы инженерного мышления.
- … если выдохнуть и заварить ещё кофе, то этот список можно влёгкую увеличить втрое, подумав лишних полчаса. Но и написанного хватит на год интенсивнейшей работы (и интенсивнейшего финансирования, токены для работы такого уровня уже немало стоят).
Вечером 29 июля 2026 года в разгар подготовки к семинару мой ноутбук (купленный в ноябре 2023, lytdybr: ailev — ЖЖ) вдруг начал замирать на минуту-другую при практически нулевой нагрузке процессора. Но при полной загрузке интерфейса с диском. Почему?! Расследование показало, что я начал работать с Codex App с картинками, которые попадали в JSON файлы чатов – и эти чаты быстро распухли до файлов в несколько Gb каждый. Один из этих файлов оказался 8.7Gb, а замирания – это операционка уходила в своп страниц оперативной памяти! Я спросил у ясеня, ой, агента – “ты же говорил, что мне для работы с ChatGPT моих 16Gb памяти хватит за глаза!” Ответ был: “это когда ты работал через браузер в далёком облаке, а с марта месяца у тебя Codex, и он очень жруч до памяти, а ещё я гляжу, ты кроме Mozilla ещё и Edge запустил рядом – и что ты хотел? Тебе и 32Gb может не хватить, на дворе 2026 год, а не 2023”. И он быстро предложил мне на выбор несколько ноутбуков моего класса, но уже с 64Gb. Когда я сказал, что готов их срочно купить, покажи магазин в Москве – ответ резко поменялся. “А, если ты в Москве, то они для тебя недоступны. И вообще, у тебя уникальная модель, ибо выше – это сразу бизнес-линейки и игровые линейки с ненужными тебе GPU, а в офисных и домашних линейках сейчас только 32Gb, а 64Gb модели, может быть, приедут в Москву только где-то к октябрю-декабрю”. Ох, переживаю трудности вместе со страной. Но делать-то что? Я же понимаю, что работать нельзя – ибо уходящий в непрерывный своп из-за недостатка оперативки компьютер – это беда, я хорошо помню работу на компьютерах с крошечной памятью и “программирование оверлеев”. Агент говорит, что надо будет тогда доплатить: перейти из линейки “таких как Vivobook” в линейку “таких как ExpertBook” – и вот моделька с 64Gb, весит на 600 грамм меньше твоего (всего там 1.09 кило), но извини, экран всего 14", процессор примерно такой же, разве что энергии кушает меньше, другое поколение. Доплатить придётся за уменьшение размера и память, а работать с твоими огромными текстами на маленьком экране будет трудно, но тебе OK, ибо у тебя же 43" внешний экран. А других опций, если ты в Москве, у тебя нет. Утром 30 июля на свежую голову я заказал ASUS ExpertBook Ultra B9406CAA-TH0598X, комплектация 90NX09J2-M00MV0, днём 31 июля его привезли, и я его включил-проверил – но не более. Большие чаты в Codex я починил, старый комп испугался своего нового конкурента и ведёт себя пока опять смирно, но раз уж я сделал инвестицию в железо – значит надо переезжать. Ох, ужас переезда с одного компа на другой комп я помню, неоднократно это проходил. Два дня, выпадающие из жизни.
