Провёл в воскресенье семинар по инженерной семиотике (Семинар «Зачем вам семиотика в инженерных проектах и как её поддерживает FPF»: ailev — ЖЖ), после семинара оставил в чате семинара слайдомент и даже добавил текущий файл с архитектурными документами всего semio-workstream (по этим документам я планирую ещё провести десять кампаний по добавлению паттернов в FPF, вдруг кому интересна эта внутренняя кухня?). Семинар сработал ровно как задумано: я понимал, что за три часа не смогу ничему научить – но смогу пробудить какой-то интерес к семиотике, ибо станет понятно, что без неё в инженерных проектах не обойтись. Какие-то операции с документами проекта (найдёт плохие имена, скажет об обращении к неверной роли и т.д.) сделает semio-архитектура в FPF, но чтобы разобраться и воспользоваться этими и многими другими возможностями FPF, надо понимать, что делаешь. Ибо не понимаешь – не видишь ошибок, не видишь ошибок – получишь repair/rework (repair – содержательное view, rework – view операционного менеджмента, обсуждали на семинаре). И даже не догадаешься попросить FPF сделать починку. И даже будешь считать эти repair/rework неизбежным злом, хотя многих видов этого зла вполне можно избежать (и прямо в чате семинара участники привели пример, как они избегали семиотических неприятностей в своих проектах, хотя и без FPF, а “вручную”). Похоже, интерес к семиотике пробудить удалось. Уже участник семинара написал в чате про пару часов бесед с FPF+слайдомент на тему личных пробелов в понимании семиотики, и это уже сегодня. И дал общую оценку времени: на это надо потратить неделю. Видео, слайды, архитектурные документы – в чате, при этом в чат можно попасть (как и в другие чаты предыдущих семинаров – Семинары Мастерской инженеров-менеджеров). Сегодня утром в чате случилось очередное большое обсуждение, так что послесеминарская жизнь, как обычно, продолжается.
FPF потихоньку завоёвывает место под солнцем, там сегодня уже 320 stars и 52 forks – GitHub - ailev/FPF: First Principles Framework (FPF): Operating system for open-ended thought for engieering, research, and mixed human/AI teams: bounded contexts, auditable reasoning, decision records, and multi-view publication. · GitHub. Пользуйтесь! И он опять подрос: сегодня я закончил апдейт онтологии и терминологии NQD OEE, внёс согласованные правки в 14 паттернов. Это я делаю в порядке усиления материала семинара “Развитие для развитых”. И тут же начал новую кампанию, ибо всплыли архитектурные проблемы с самим FPF: математика NQD OEE должна быть общей, но уже вырисовались специализации для поиска SoTA школ/традиций в G.2 и поиска имён в F.18 – это надо аккуратно причесать. Пока же кампания Q-front уточнила в FPF язык и паттерны работы с множествами решений, вывела их на SoTA:
- palette = всё осмысленное поле доступных подходов до отбора, этот набор шире всех.
- frontier = недоминируемые варианты, отфильтрованные из palette по объявленному Q.
- shortlist = небольшой набор из frontier, который берут в ближайший дорогой раунд проверки.
- portfolio = набор решений, который потом сознательно держат в работе по итогам проверки shortlist.
- archive = сохранённые не-фронтирные или уже невыбранные варианты, которые держат как stepping stones или исследовательскую память.
В субботу-воскресенье десятая ежегодная конференция МИМ – 10-я ежегодная конференция МИМ «Современный системный менеджмент и инженерия — 2026»: ailev — ЖЖ; у меня там будет два доклада:
- Развитие для развитых в Мастерской инженеров-менеджеров – это я расскажу про изменения за последний год, когда мы из ШСМ вдруг стали МИМ (это же как раз было решено на прошлогодней конференции, всего год прошёл!). У меня было довольно много написано на эту тему – кратенько соберу. Из последнего тут – семинар “Развитие для развитых” и как раз вот это сегодняшнее уточнение онтологии-терминологии в FPF. Ну, и новые краски термина “инженер-менеджер”, когда все “просто инженеры” прихватили менеджмент для команд AI-агентов.
- Планы развития First Principles Framework – тут расскажу подробнее про “планов громадьё” по FPF от 1 февраля 2026, Начинаем февраль 2026: громадьё планов по FPF: ailev — ЖЖ. В феврале я писал тексты про МИМ, в марте разворачивал Codex и даже что-то при этом выполнил из планов, а сейчас машинка работает – и я намерен планы эти выполнить. В докладе разъясню, почему эти планы именно такие и что будет дальше.
Много разговоров про SPF (second principle framework, модель предметной области) и TPF (third principle framework, модель того, чем занимается конкретное предприятие): сразу становится понятно, что в FPF сейчас именно мета-мета-модель, только нулевые и первые принципы. Фреймворки вторых и третьих принципов каждому надо делать себе самому, ибо предметных областей разных множество, а уж предприятий и подавно много, впрок такое не сделаешь. Ещё ведь надо SoTA отслеживать – ибо интересует пересадка в AI-агента мышления лучшего современного специалиста по предмету, а не “среднего спеца с рынка”. FPF как трансдисциплинарный фреймворк не может заменить дисциплинарный (модель предметной области “как в учебнике”), и уж подавно не может заменить модель предметной области предприятия. Интересно, что многие инженеры-менеджеры уже потихоньку занимаются созданием SPF и TPF – но мне хорошо понятно, почему у них там трудности. Например, они мыслят о “пересадке мышления” как о пересадке алгоритма мышления, то есть как о чём-то пошаговом. Но методы, в том числе методы мышления, не сводятся к пошаговости. Формат нарративизации методов, как-то учитывающий их неминуемую факторизацию (например, в форме pattern languages), требует понимания, а он больше известен только архитекторам. Разные методы используются в разных bounded contexts и поэтому требуют всё равно “нейтрального английского” для контроля типов в описании этих методов. И так далее. Я потихоньку эти трудности разработки SPF и TPF решу, но это потребует времени:
- плохое понимание: 1) что это вообще такое – “модель предметной области”, “методы работы в предметной области” и 2) как они представимы в формате паттернов. Первое лечится прохождением наших резидентур по рабочему развитию, после чего слова “онтология” и “метод” уже не будут такими пугающими, а задача сопоставления предметов этих предметных областей и методов работы с ними не будет пробоваться решаться “в лоб” как сопоставление похожих терминов (как раз материал семинара по семиотике).
- отсутствие переносимой между разными AI-агентами машинки по написанию паттернов. У меня какой-то пакет паттернов для FPF готовится в Codex App и дополнительно в GPT-5.4 Pro по десятишаговому процессу со множеством проверок, это хоть как-то гарантирует его качество. Чтобы на потоке делать SPF, надо просто использовать эту машинку. Но она у меня пока не в виде продукта. У меня выбор – или доводить до продукта сам FPF, или заниматься отчуждением машинки по его изготовлению. Я выбираю пока заниматься FPF, чтобы потом фраза “FPF сам себя не напишет” оказалась ложной. Напишет: код его собственного процесса (часть E) будет доработан, но не вот прямо сейчас.
- всё-таки перед занятиями SPF мне надо докрутить сам FPF: надо всё-таки снять часть содержательных вопросов, вроде “а как мы выражаем процессы” (это TGA) и “а как мы выражаем архитектуры” (это ведь тоже в плане). Ну, и доработать до конца эту линию с open-ended evolution, реализовать полностью всё содержание “развития для развитых”. Пока вот это в приоритетах.
Постоянно борюсь с превращением архитектурных и процессных документов FPF AI-агентами в Codex в дублирующиеся исторические заметки: на исправление буквы A в один байт обязательно в этом же месте появятся guardrails про “никогда больше!”, а также запись “тут было вот так, стало вот так” – и это на каждом месте. Вместо 1 байта замены идёт вставка 350 байт заметок, после трёх раундов правок файл распухает – в нём полная история редактирования, рассказанная в каждом конкретном месте и ещё дубль всех запретов в каждом правленном месте. Ну, и fanout – он неистребим: запись о том, что “мы вот тут поправили, теперь это текущая версия”, вносится в десяток файлов, при этом предыдущие записи об этом не стираются. И ещё в ходе правок обязательно будет “о, вот это важный момент – давай об этом скажем ещё вот тут, тут и тут”, и ты с каждой чисткой неожиданно получаешь отрицательный эффект: “что-то я чищу и чищу, сокращаю и сокращаю, а объём документации только увеличивается, несмотря на рапорты агентов, что они там всё поправили”. Культура “безопасности” и связанная с этим культура “красного сторно внутри документов”. Ничего, мы и это победим.
Уже во многих местах видел про возросшую многозадачность: заряжаешь агентов на выполнение 10 разных проектов (рабочих и не очень), а потом только прислеживаешь. Так сказать, “новое стахановство” (вот, например, об этом пишет Григорий Сапунов – “Во всём этом богатстве главный челлендж теперь – находить достаточно непрерывного времени для глубокого обдумывания. Нормальное человеческое внимание – очень редкий и дорогой ресурс”, Telegram: View @gonzo_ML. Я этим не занимаюсь, ибо хорошо усвоил уроки операционного менеджмента (они у нас ведь прямо в резидентуре R1 по “распожаризации”, потом много раз повторяются, а затем ещё раз повторяются в R10 по системному менеджменту): много проектов в параллель – это много недоделанного в любой момент времени, “надкушено, но не съедено”. А если работают роботы, а ты ждёшь – почему не запустить ещё одного робота? Не ждёшь, а глубоко думаешь (как раз то время, на нехватку которого начинают повсеместно жаловаться). И дальше все бенефиты прямо по теории ограничений. Там один из ходов – если у тебя меньше проектов, то ты успеваешь их более глубоко продумать, и у тебя будет потом меньше возвратов из-за ошибок. Время будет абсолютно экономиться за счёт отсутствия rework. Бэклог у меня огромный, но я его не запускаю в дело весь, а стараюсь держать один проект основной full time, и ещё один-два дополнительных (вроде написать посты и почитать новости, подумать над новостями), но не больше. Мои агенты крутят не пяток циклов, а только один цикл в параллель (ну, часто и два – но это содержательный цикл, из которого выпрыгивают какие-то процессные ошибки, и процессный цикл, где я эти процессные ошибки использую для изменения процесса, защищаюсь от повторения этих ошибок). Да, это контринтуитивно. Да, это моё несправедливое конкурентное преимущество: ровно по Голдратту, который говорил “другие просто не поверят, поэтому не смогут повторить, вы будете самыми быстрыми”. Про Голдратта все знают, но его идеям (ОК, не его идеям, а популяризируемым им идеям) не следуют. А я следую.
Мне показали моё двенадцатиминутное видео трёхлетней давности – и я с удивлением обнаружил у него 137 лайков. Более того, это не видео, а аудио: в видеочасти там просто заставка с моим портретом и заголовок “Зачем публиковать посты”, https://www.youtube.com/watch?v=MnCV3sOkVVw. Судя по всему, это видео действительно многим помогло. И комменты там подчёркивают: я устный и я письменный – это два совершенно разных продукта! А если взять мои руководства, мои посты в блоге, мои семинары, FPF – это ведь абсолютно разные представления/representations, хотя часто это представления об одном и том же предмете. Устный я обычно много понятней, ибо обращаюсь к кому-то, а письменный – понятней в руководствах (до которых мало кто доходит), а вот в блоге малопонятный, ибо пишу в основном для себя, в FPF – вообще непонятный, ибо вроде и пишу уже не совсем я, хотя я автор, и читатели тут – AI-агенты (но и люди читают, мне сегодня рассказывали, что читать FPF очень интересно, очень меня этим удивили). В видео я в том числе говорю, что на пост из пяти абзацев могу потратить пять часов – по часу на абзац. Ибо суть поста у меня не в том, чтобы объяснить что-то кому-то проходящему мимо моего “Лабораторного журнала”, а чтобы удержать внимание моего собственного мозга на каких-то моментах. Вот и этот мой пост – он прежде всего для меня. Но я знаю, что, как и в случае с FPF, найдутся люди, которым прочесть эти мои заметки будет интересно. Надеюсь, я их не разочаровал.
