Встречаем апрель 2026: конференции, семинары, обновления FPF

ailev · 31.Март.2026 15:28:01

Напоминаю (прежде всего – себе!), что наши апрельские конференции уже вот прямо сейчас (10-я ежегодная конференция МИМ «Современный системный менеджмент и инженерия — 2026»: ailev — ЖЖ), и надо присылать мне заявки на доклады. Я и сам там буду докладывать (про развитие для развитых и новый инженерный процесс, про FPF):

10-я ежегодная конференция МИМ «Современный системный менеджмент и инженерия — 2026», 18-19 апреля 2026 года (суббота-воскресенье), это через 18 дней.
XVI рабочая встреча по проблемам системной инженерии Русского отделения INCOSE ожидается 4-5 апреля 2026 года, это уже в эти выходные.

И у меня ещё 12 апреля семинар по управлению точностью языка (как раз сейчас идёт большое обновление FPF на эту тему). Я ещё подумаю, как сказать про это всё популярно, ибо когда смотришь отдельные проблемы – то вау, шайтан-машинка реально работает, ловит дырки, ловит баги в мышлении, и особенно полезна для снятия лапши с ушей, которую навешивают тексты AI-агентов (они красивые, но часто и очень незаметно подменяют смысл на каждом шагу диалога). В целом же, если “без огонька”, то там примерно так:

Приглашаются инженеры-менеджеры, техлиды, архитекторы, product/operations leads, люди из quality/compliance и авторы внутренних стандартов.
Этот семинар для тех, у кого коллективный проект начинает буксовать не потому, что не хватает идей или данных, а потому, что одна и та же формулировка у разных людей (а сейчас и не всегда людей) неожиданно означает разное, summary незаметно меняет предмет описания, сводная таблица или иллюстрирующая диаграмма начинает утверждать больше, чем было в исходном материале, а dashboard внезапно получает несанкционированную нормативную силу и становится административно сильнее тех источников, на которые он должен был лишь опираться и из которых – лишь выводиться.
Основная разбираемая проблема: неточность языка не замечается, состояние “проект буксует” тоже не замечается, ибо “у нас всегда так, а что, можно было по-другому?!”. Это семинар не о филологической “литературной правке” и не о том, как “писать документы проекта красивее”. Он вообще не для “писателей” – он для инженеров-менеджеров, а рассматриваемые на нём паттерны FPF ещё и должны читаться и использоваться AI-агентами. Этот семинар про работу со смыслом, представлениями и публикацией в инженерном проекте. Это оказывается шире, чем просто “вопросы языка”. В FPF паттерны для работы со смыслом мы относим к semio-архитектуре (от “семиотики” – учения о знаковых представлениях). Для рабочего разговора по-русски говорим проще: разговор о том, как инженерная и организационная документация и базы данных, переписка и модели удерживают смысл, переносят этот смысл с контролируемыми искажениями между разными представлениями. Если эту semio-архитектуру реализовать, например, как проверки текстов AI-агентами, работающими с FPF, то язык не сможет тихо подрывать взаимопонимание в ходе рабочих проектов, ошибки будут пойманы. Люди осваивают архитектуру и критерии review, а AI-агенты с FPF затем помогают масштабировать это проверками.
Разговор на семинаре будет идти не о “семиотике вообще”, а о конкретных семиотических проблемах, с которыми часто сталкиваются инженеры-менеджеры. Если вы не знали, что вы делаете семиотические ошибки – будете знать об этом после семинара. Кто предупреждён – тот вооружён. На семинаре мы будем разбирать, как работать с ранним слабым понятийным сигналом до того, как этот “слабый сигнал” ещё не стал понятийно и терминологически оформленной гипотезой, решением, поручением или инженерной моделью. Это как раз переход от “настоящего Дао” к членораздельной речи, ибо “изречённое Дао – ненастоящее Дао”: тут и felt sense от Gendlin, и dynamic quality от Pirsig, и “онтологический дребезг” из руководств МИМ. Ещё разберём, как восстанавливать смысловую точность перегруженных слов вроде “сервис” или “контракт”; как переписывать текст с одного прикладного языка на другой, не меняя предмет описания; как переводить какой-то текст в таблицу, схему или dashboard без скрытого усиления смысла; как объяснять и сравнивать материалы так, чтобы записка или меморандум не превращались исподволь в приказ, новую онтологию или скрытое решение.
На семинаре расскажем про контролируемое упрощение текстов (намеренное уменьшение точности изложения, например, для “популярных объяснений”), интерпретационные ветви за пределами сравнительного чтения, онтологические сдвиги, работу с носителями информации и с пакетированием разнородных авторских единиц. То есть участники получат не только словарь текущих решений, но и карту того, куда эта архитектура уже растёт.
По ходу семинара внутренние термины FPF будут переводиться на рабочий русский. Например: коридор состояний формулировок (language-state corridor), восстановление смысловой точности (precision restoration), переписывание при сохранении того же предмета описания (same-entity rewrite), перевод в другую форму представления (representation transduction), дисциплина одной авторской единицы — одной записки, одного memo, одного слайда (authored-unit discipline), предмет разговора (object-of-talk).
Отдельно будет показано, что уже стабилизировано из semio-архитектуры в FPF, а что разрабатывается прямо сейчас. Будет также рассказано о методах разработки этой части FPF в мультиагентной среде Codex App с участием ChatGPT в качестве независимого reviewer.

О том, что “инженеры должны стать менеджерами” сейчас пишу уже не я (я писал, когда это ещё было не модно), а каждый первый англоязычный автор. Но это почему-то не воспринимается как совет “мышки, станьте ёжиками”. А у нас тут в МИМ довольно большой опыт по этой линии: с наставниками за год-два эта магическая трансформация происходит уже много лет. Я подтверждаю: никакой особой разницы нет ни между мышлением у инженеров и менеджеров, ни между мышлением о менеджменте у людей и не очень людей. Принципы-то одни и те же! Закон Амдаля тот же, закон Конвея тот же, а чтобы не делать ошибок – их надо знать! При этом мало просто знать эти магические слова, признавать эти идеи. Надо регулярно проверять организационную архитектуру (неважно, людской организации, или трёх агентов в Codex) и архитектуру какой-то системы (а хоть и софта, там хоть как-то архитектурой интересуются) на соответствие этим идеям. Например, попросите вашего любимого AI-агента: “сделай архитектурное review данных тебе документов проекта, обрати особое внимание на fanout”. Тут надо и знать магическое слово, и понимать, что это заклинание означает, что будет происходить, что вы потом сделаете с результатом. И главное, понимать, что это только начало: fanout вам укажут и даже из процесса уберут, как приказано. Но точно ли “два молодца, одинаковых с лица” при этом оставят usability, evolvability и всё такое прочее? И что там не про архитектуру, ведь архитектура – это не весь проект? Так что не расслабляемся, работаем, развиваемся.

У меня AI-агенты продолжают писать FPF, причём времени на организацию процесса у меня сейчас уходит даже больше, чем на само написание, ибо я прошёл ещё несколько шагов в своём оргконсультировании этой бригады:

пара агентов (Platform Engineer и его независимый оппонент) занимается процессом, один всё пишет (документы, хелперы на Питоне, а также панельку управления), а другой занят review всего написанного. Пишем-исправляем, пишем-исправляем, почти круглосуточно. RPA у меня не пошло на CDP (хотя вроде бы Codex построен на Electron, я пробовал и OpenCLI, и Puppeteer – всё тщетно), но наладилось на обычной Windows-механике работы с интерфейсом. Нужные страницы чатов листаются, промпты записываются, кнопки нажимаются. Сделал из Codex механическое пианино, оно как-то играет. Ещё текстовые описания потихоньку перекочёвывают в описания с контролем типов, процесс стал строже. Меньше слов и размышлений агентов над словами, больше классического софта.
исследовал skills: дают ли они в процессе улучшение хоть каких-то его характеристик. Выяснилось: ничего не дают, кроме облегчения переносимости ввиду следования стандарту и затем возможности пакетирования в формате плагина. Это просто другой формат того же самого. Поэтому плюнул – и не стал переходить. Если надо будет переносить – просто переписываются тексты в формат skills, и всё. Хотя я подозреваю, что после этого надо будет ещё отлаживаться. Но будут бить – будем плакать, пока же эту революцию перехода на skills не стал делать: она не сущностная.
процесс теперь один, а проекты по нему идут разные. Я уже описал общую архитектуру с workstreams и campaigns в “Процесс для производства AI-агентами текстов, которые читать противно, но возразить нечего” (Процесс для производства AI-агентами текстов, которые читать противно, но возразить нечего: ailev — ЖЖ), но теперь эта архитектура уже не на ручном ходу, а на каком-то (не до конца отлаженном, “программное обеспечение всегда опаздывает”) автоматическом ходу, и по ней прогнали большой кусок проекта реализации semio-архитектуры (и я надеюсь там ещё сильно продвинуться до семинара), а также прогнали “нестандартную campaign”. Эта campaign добавила шесть стартовых маршрутов чтения паттернов, чтобы проще было отвечать на эти вечные вопросы: “для чего именно у вас используется FPF, с какого паттерна лучше начинать читать”. И ещё поставил задачу на три подобных усиления. Ожидаю, что теперь такие небольшие усиления FPF перестанут занимать много времени. Идея, что FPF отслеживает какую-то SoTA и обновляет себя сам, казалась в начале этого проекта далёким будущим. Сейчас это уже можно обсуждать, при этом не надо это делать незаметно от санитаров.

В FPF у меня медленный рост популярности: сейчас там 285 stars и 51 forks. FPF работает, наносит непоправимую пользу самым разным командам, и это меня чрезвычайно радует. Я сделал очередное обновление FPF, добавил пару паттернов как раз про семиотику. А ещё вместо “главной стартовой точки” и одного маршрута первого чтения паттернов появилось шесть альтернативных вариантов как в самом тексте FPF, так и в readme.md (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). У старых больших спецификаций есть типичная проблема: когда они ещё маленькие, можно честно показать один рекомендуемый стартовый проход. Но когда содержание разрастается, такой проход начинает врать – и первые наборы skills для FPF (вроде Quint Code) уже в это попадали. Эти “дистилляции из FPF” сокращали полный FPF только до одной ниточки “цикла абдуктивного мышления”. Явное указание одного маршрута “начните с чтения вот таких паттернов” в FPF уже не помогало начать работу, а навязывало один и тот же учебный рецепт там, где у людей самые разные рабочие проблемы. Теперь сама спецификация и её рекомендации по началу работы перестроены под другую логику: “выбирайте не порядок паттернов, а первую практическую задачу, а нужные паттерны подтягивайте под эту задачу”. В этом плане FPF может читаться не как детектив или учебник с начала до конца, а как справочник – “по потребности”, это ведь язык паттернов (pattern language).

В ReadMe.md в FPF это прямо сформулировано как пример шести маршрутов, но и в самой спецификации это закреплено как набор из шести “first practical entry routes”. FPF теперь подаётся не как текст, который нужно “правильно прочесть от первого паттерна до последнего”, а как инструмент для ситуации современной AI-агентской разработки, где узкое место — не уровень интеллекта отдельного человека или AI-агента, а координация их совместного мышления через точный язык и нейтральную для разных ролей терминологию, явное описание характеристик для честного сравнения вариантов и надёжного тестирования, проверяемые передачи работы (handoffs), выдача и выполнение обещаний, и тому подобное. Из вот этого многообразия проблем коллективной разработки и вытекают примеры разных начальных маршрутов знакомства с паттернами. Раньше FPF было легко воспринимать как большой “монолит” (на сленге AI-разработчиков FPF он так и называется), в который нужно “правильно войти, и затем полностью освоить”, теперь же возможных стартов шесть (и лиха беда начало, я бы добавлял ещё и ещё): упорядочивание проекта, работа со слабым интуитивным сигналом, распаковка языка описания границы, характеризация и справедливое сравнение, сборка воспроизводимого генератора описаний SoTA-дисциплин и аккуратное переобъяснение существующего материала.

Правка проекта. Это маршрут для ситуации, когда команда уже что-то делает, но путает роли, методы, планы и фактическое исполнение. Кто за что отвечает? Что тут способ работы, а что — описание способа? Где план, а где факт – реально сделанное? Такой старт в использовании FPF нужен не для “философии процесса”, а чтобы быстро согласовать общее понимание проекта: карту контекстов, явное разведение ответственности по ролям, перестать путать метод, план работ и работы. Именно здесь FPF становится полезен менеджеру: он помогает убрать вечный туман вокруг “процесса”, когда одним словом называют и регламент, и расписание, и фактическую деятельность и даже подразделение. Start with: A.1.1, then A.15, then A.15.2 / A.15.3, then B.5.1. Add F.11 when method/work vocabulary itself must be aligned across contexts, and F.9 where bridge discipline matters. Land on F.17 (UTS).
Работа с ещё неоформленным (чаще всего кинестетическим) мыслительным сигналом, cue. Иногда проблема не в том, что у нас плохое решение, а в том, что у нас пока есть только смутный (чаще всего кинестетический, “ощущение”) сигнал: ощущаемая странность в данных, инженерное “чутьё”, цепляющееся за ранний симптом инцидента внимание, исследовательская ещё даже непроизносимая (слова ещё не придуманы!) идея. Раньше такие вещи часто либо терялись (“показалось, ладно”), либо насильно превращались в невнятное утверждение. Этот новый вариант старта в FPF предлагает сначала аккуратно сохранить/стабилизировать cue как наблюдение “ощущений”, ещё не делая вид, будто это уже диагноз, точное описание ситуации или даже план действий. И уже потом превращать это постепенно во всё более и более точные описания. При таком использовании FPF первый результат — не “решение”, а хорошо зафиксированная ранняя зацепка, которую потом можно честно маршрутизировать дальше: в присвоение осмысленных имён, в разбор аномалии, в в уточнение характеристики, в формулировку действия. Это помощь в выполнении роли “поэта”, давать имена чему-то едва ощущаемому. Start with: C.2.2a, then C.2.LS / C.2.4-C.2.7, then A.16 / A.16.1 / A.16.2, then B.4.1 / B.5.2.0, and only then move into the relevant endpoint owner.
Распаковка языка на границе объектов. Это один из самых прикладных новых стартов в использовании FPF. Он нужен там, где текст упоминает какую-то границу, описывает отношение между объектами: API, контракт, регламент, SLA/SLO, техническое регулирование с описанием надлежащего поведения на границе системы, интерфейсное описание. Обычная болезнь текстов о таких объектах — всё свалено в одну кашу: в одном абзаце одновременно определение, условие допуска, обязательство и способ проверки. В FPF для этого есть паттерны, которые можно использовать как отдельный вариант стартового маршрута чтения: он помогает разложить граничные высказывания на атомарные элементы и перестать путать, например, сервис-как-обещание, сервис-как-работу, сервис-как-интерфейс. Первый полезный результат здесь — не эссе и не красивый документ, а сортировка: что тут правило, что тут условием допуска, что обязательство, что наблюдаемый эффект и его доказательства. Для инженера-менеджера это означает отделение обсуждения характеристик от обсуждения обязательств по этим характеристикам. Start with: A.6, then A.6.B, then A.6.C. When the boundary text hides overloaded quality language or generic doing-words, continue with A.6.P, then A.6.Q or A.6.A.
Сравнение и выбор. Во многих организациях сравнение вариантов до сих пор выглядит как спор мнений или как притянутый к одному числу “скоринговый итог” (умножаем значения каких-то характеристик на произвольно выбранные “коэффициенты важности”). FPF теперь явно выделяет отдельный стартовый маршрут для ситуаций, где нужно не просто “оценить”, а справедливо сравнить: задать характеристики, их шкалы, критерии сопоставимости, минимальные требования к данным и только потом сравнивать и на основе сравнения – выбирать. Сравнение не обязано сводиться к одному победителю. Наоборот, в FPF специально закреплено, что результатом часто должен быть портфель вариантов (shortlist), а не искусственно скаляризованный один победитель “лучший по сумме баллов”. Это особенно полезно там, где решения дорогие и рискованные и где нужно пройти развилку (trade-off) в выборе каких-то вариантов архитектуры или стратегии. Start with: A.19:0, then A.17-A.19, then G.0, then A.19.CPM and A.19.SelectorMechanism, and then G.5.
Сборка воспроизводимого сборщика решений, выбора SoTA и генератора портфеля SoTA-решений. FPF задуман для порождения множества SPF (second principles frameworks), похожих на него по организации и опирающихся на него фреймворков принципов для прикладных предметных областей. Для этого в FPF есть воспроизводимый процесс: как собирать описания SoTA (state of the art, лучшее из известного на сейчас) какой-то дисциплины, как генерировать варианты традиций/школ знания, как их отбирать, как обновлять всё это по мере появления в мире новых знаний. Для этого стартового маршрута чтения паттернов теперь есть отдельная точка входа. Этот маршрут нужен там, где работают не только люди, но и AI-агенты, где нужен повторяемый поиск, сравнение семейств методов, регулярное обновление и дисциплина публикации результатов. Start with: A.0, then G.0, then G.1, then G.2 and G.5. When creative search or explore/exploit policy is already central, add B.5.2.1 and C.17-C.19 early.
Переобъяснение без подмены предмета разговора. Этот маршрут будет стартовым для тех, кому нужно переписать, объяснить, переформатировать или сопоставить уже существующий материал, но при этом случайно не подменить сам объект разговора (“начал за здравие, кончил за упокой” – такое в инженерных текстах сплошь и рядом). Нужны разные описания одного и того же объекта для удовлетворения интересов разных сторон, а ещё нужно как-то это обсудить, чтобы само обсуждение не воспринималось как “директивные указания”, а вопросы на понимание не воспринимались как высказывание претензий. Это кажется редакторской мелочью, но на практике именно здесь часто рождается хаос: под видом “правки объяснения” команда незаметно вносит новые утверждения, новые требования или новые решения, а оригиналы начинают отставать, появляются коллизии. Этот стартовый маршрут нужен как раз затем, чтобы разделить эти случаи и удержать объяснение в честных границах. Start with: A.6.3.CR for same-entity retextualization, A.6.3.RT for representation-scheme transition, E.17.EFP for explanation-facing rendering, E.17.ID.CR for bounded comparative reading, and E.17.AUD.LHR / E.17.AUD.OOTD for local repair and authored-unit stability.