У меня давно забытое ощущение проекта управленческого консалтинга на каком-то заводе, только примерно месяц работы проходит за один день и не требуется особого лидерства. Что удалось сделать:
- по семио-проекту вышел небольшой релиз, объём FPF стал больше 5MB (но мы на это не смотрим). Что там вошло содержательно – отдельный вопрос. Ещё пара паттернов близки к выпуску. Это совсем не та скорость, на которую я рассчитывал, в ручном режиме я выпустил бы много больше за это время, но пока меня увлекают эксперименты с “научной организацией труда” AI-агентов, я пробую разное-всякое.
- оказалось, что AI-агенты организовали себе абсолютно гейтовый процесс и признали это (у них же там метрики, сбор статистики, всё по-взрослому). Количество правленных административных документов за период (скажем, полдня) превышало количество правленных содержательных документов! Заставь дурака богу молиться – он и лоб разобьёт.
- весь оргпроцесс был переписан целиком, чтобы такого не было. Гейты были удавлены принципиально. Но оказалось, что в разработчиках сильна “корпоративная культура”, навеваемая музыкой традиционного инженерного знания. Разработчики придумали себе скрытые гейты и начали работать “с документацией” вместо работы “с содержанием”. Reviewer честно писал executor, что “в присланном одном содержательном документе ошибок нет, но я нашёл шесть разных ошибок в окружающих тебя административных документах и дальше работать не пущу”. Заодно “программное обеспечение всегда опаздывает”. Не очень живой вайбкодил поломал диспетчер и начал а) отлаживаться на мне, б) затыкать отдельным патчем каждое отдельное поведение, игнорируя слова “обобщи это и поправь логику в целом”, в) игнорировать просьбы сменить общую архитектуру софта в пользу удержания этого софта “таким же, только добавляя фичи, мы ведь хотим обойтись минимальными правками”. Там пришлось сделать следующие ходы: просить отлаживаться не на мне (по факту это означало, что внутрь диспетчера будут вставлены средства дистанционного управления – API для AI-агентов, и с этого момента мы вообще имеем не “диспетчера”, а навайбкоженный RPA, ещё был сделан мокап самого Codex), переписать (рефакторинг после архитектурного review) всю логику.
- после чего я даже некоторое время подумал: что там был за корень этого всего? Корнем оказалась “заводская культура” беседы в терминах не “сделай дело и отрази в документах” (case management – делается дело и подробности подшиваются в case file, после плана), а в терминах “вот у нас тут процесс прописан, он же план, в его терминах и будем говорить о мире – не парогенератор, а заказ №12345 в состоянии”. Меня всегда раздражало на заводах то, что они там делают 1-2-3, в стандартах у них написано A-B-C-D, а в разговоре они наотрез отказываются обсуждать 1-2-3 и говорят только в терминах A-B-C-D (и обоснования самые разные, чаще всего “нам запрещено делать по-другому, поэтому давай и не говорить о запрещённом” – то есть состояние мира обсуждать не будем, а будем обсуждать состояния по модели, которая заведомо не совпадает с содержанием мира). Пришлось обсуждать с не очень живыми агентами про то, что у нас первично – мир или модели мира, а также Conway leak, это сразу две ошибки. Нетривиальный двойной ход! Но после этого агент-организатор вдруг сказал, что он понял что делать – и мы по-быстрому переписали вообще весь оргпроцесс, учитывая вот эту “корпоративную культуру” и передавая агентам ходы мимо Codex через helpers (на Питоне, они дёргают API, а агенты могут их легко вызывать) и висящий виджет диспетчера (который не просто RPA, но ещё и кнопки и диагностику имеет для человека, то есть меня – чтобы понимать происходящее и иметь возможность повлиять быстро). Главное, что в документах прописано, что источник истины – это не документы, а состояние самого процесса – и при невязке документов с реальной ситуацией надо действовать по реальной ситуации, а не пытаться следовать кривым моделям только потому, что это “административная правда, так говорит Небесный Император, его приказы нельзя нарушать”.
- Ещё один термин, который агенты хорошо восприняли с моей подачи – это Conway leaks, когда вместо содержательных объектов в инженерной документации вдруг появляются административные объекты (грубо говоря, вместо “апельсинов” в кулинарном рецепте вдруг появляется “ящик 12 от поставщика 8” или “итоги четвёртого этапа процесса”).
- Ещё одна проблема из-за этого кривого оргпроцесса – перемешанные user-faced и developer-faced тексты в целевых паттернах. Все тексты – это surfaces в этом проекте. Интересно, как это появилось: связано как раз с содержанием самого semio-проекта, этот термин был выбран предпочтительным для artifact/material/text/view/face/surface/и т.д. Это перемешивание “для пользователя” и “для нас, писателей паттерна” было неистребимо: внешнее review постоянно это находило, пришлось поставить проверку. Пока всё шло вручную без “процесса” – этого не было, как только появился “процесс” – всё, рассказ делается уже не для пользователя, а для архитектора, для разработчика, для reviewer, а если всё-таки для пользователя – то в хитрой формулировке “вот тут мы скажем пользователю то-то и то-то, чтобы он прочёл достаточно близко к началу текста”. Пришлось вставлять отдельные проверки (которые reviewer не мог нормально выполнить, ибо он и сам работает в design time, а надо-то читать глазами run-time этого паттерна!). Отдельная беда, тоже часто встречается.
- кроме этого посмотрели на связь архитектурных единиц и особенностей проекта – и таки будем вводить DRR как промежуточные документы между всей архитектурой (не пишу семио, поскольку у нас есть ведь ещё и TGA, и архитектура и многое другое подобное) и отдельными паттернами. Они будут для группы паттернов, которые идут в очередной релиз – release early, release often.
- и, конечно, во всём этом немного участвует и FPF, каждый раз удаётся вычерпать баги из документов, которые без FPF невидимы.
- утром я предпринял очередную полную переписку оргдокументов с учётом вот этого всего, посмотрим на результаты. Не очень живой разработчик оргпроцесса закончил разрабатывать и процесс, и софт, а не очень живой аудитор нашёл ему на исправление пяток ошибок, которые уже исправлены (кусочек моего разговора с этим организатором/platform engineer я опубликовал в формате скриншотов у себя в чате в телеграме, уж больно там хотели это увидеть – см. с Telegram: View @ailev_blog_discussion. Но я там сразу предупредил, что это рабочий разговор прямо из середины моего абсолютно экспериментального проекта, а не учебная демонстрация, поэтому не думаю, что кому-то стало понятней происходящее после рассматривания этого фрагмента диалога.
- дальше планы – canary run на примере выпуска паттерна Surface Object of Talk Discipline (это про то, что в вашем документе должен быть какой-то вполне определённый предмет разговора, и это неплохо бы соблюдать – что вы описываете? Если это несколько объектов, то как они очутились в одном тексте? Surface – это и есть “поверхность, которая видна интересующимся/читателям”, местный сленг).
- Только тут беда: для GPT-5.4 xhigh на fast-режиме в Codex у меня недельный лимит обновится завтра, а до его исчерпания уже прямо сейчас остался 1%. И дальше вопрос, хочу ли я лететь до завтра на крыльях какой-то более туповатой модели, или сделать с этим Codex выходной до завтра, вернуться к ChatGPT на web-UI: есть ведь чем заняться!
Интересно, что оргпроблемы инженерам часто вообще невидимы. Вот прямое подтверждение у меня в чате блога в телеграм (с Telegram: View @ailev_blog_discussion): обсуждается вопрос об организационных проблемах вокруг создания и использования персонифицированных вакцин от рака с помощью LLM. Содержание чёткое, все слова-маркеры указывают на workflow: опции и вменяемая маршрутизация, “что есть, чего нет и куда бежать”. Методология и её стык с операционным менеджментом. И первый же ответ – реакция инженерного S1 на слова-триггеры “персонифицированные вакцины от рака” и “LLM” – “персонифицированные вакцины от рака уже лет 8 как делают и без ллм”. Но это же абсолютно оффтоп-комментарий! В комментируемом тексте так и говорится – “когда с помощью LLM можно создать персонифицированную вакцину от рака, на первый план в подобных ситуациях выступают уже другие проблемы”. Но эти “другие проблемы” видят инженеры-менеджеры. А “просто инженеры” – не видят. Поэтому не обвиняем AI-агентов в этой слепоте: они тут плоть от плоти, кровь от крови тех людей, на текстах которых они учились. У менеджеров там будут другие проблемы, но тоже будут (для них там особенности техпроцесса с персонифицированными вакцинами от рака не существуют). У врачей – они начинают ругаться на само слово “вакцина”, ибо их бесит, что всё чаще и чаще иммуномодуляторы называют вакцинами, ибо для непосвящённых, в том числе популяризаторов науки, а также просителей грантов из самой науки – “всё на свете, что имеет даже косвенное отношение к иммунной системе – вакцина”.
В воскресенье, 22 марта 2026, в 11:30 буду делать примерно часовой бесплатный семинар-вебинар “Три прототипа – это нормально. Три исправления ошибки – нет”. Это снятие кажущегося противоречия между ожиданиями безошибочной работы и “с первого раза – правильно” в системной инженерии и предписаниями выдвижения гипотез и отбрасывания ошибочных вариантов. Коварство в том, что какие-то не фальсифицированные, неопровергнутые гипотезы (наименее плохие, а не лучшие из плохих!) – это не ошибки, это проявление того самого “развития для развитых”, это гадкие утёнки. Это не ошибки! Это нормальная инженерная работа, их прорабатывают – пока не выкинут, когда они выполнят свою роль и честно проиграют другим вариантам. Без этого нельзя, не будет идти техническая эволюция, не будет развития. Вы просто обязаны сделать несколько вариантов архитектуры и устроить trade-off studies. Если не сделали – вы плохой архитектор. Это намеренное действие, оно по норме. Ни один из этих вариантов – не ошибка. Но в любом из этих вариантов вы можете сделать ошибку (например, положив 22=5) и дальше в какой-то момент вам на неё укажут. Лучше бы указали сразу – и тогда последствия – переделка только этого 22=5, но если не сразу, то это ляжет в основу какого-то другого решения, и придётся переделывать и 2*2=5, и опирающееся на него решение, это лишняя работа, rework. Или вы просто делаете ненужную работу, тратите на неё время – это не rework, но это тоже ошибка. И проблема в том, что вы не делаете варианты, потому что их необходимость обычно невидима, не проводите trade-off studies, потому как не знаете, как (суммы баллов и коэффициенты важности при них – это плохой способ!), а ещё не исправляете ошибки вовремя, ибо они невидимы и не делаете сразу правильно, потому как не знаете, как (нужно владеть понятием метода, знать о разделении инженерных ролей, и т.д.). Одна важная различалка, а потом с ней идёте в свой проект и смотрите, как с этим работают у вас. Ну, или идёте в Мастерскую инженеров-менеджеров, где про всё это подробненько (опять же, на материалах ваших проектов – но с руководством и наставниками). Ссылка на Zoom, видеозапись и материалы (слайды) будут доступны на канале поддержки рабочего развития инженеров-менеджеров, @mim_workdev.
Как всегда, с резидентурами R1, R5, R8, которые заканчивались на прошлой неделе, у нас проблема: за ровно полтора месяца не уложились, поэтому группы взяли ещё неделю – и набор на R2, R6, R9 на неделю задерживается. У всех вас есть шанс попасть в эти группы (в принципе, туда берут и “самопроходимцев”), если пришлёте эссе (пароли-явки вот тут: Telegram: View @systemsthinking_course). Тут несколько интересных заметок:
- программа личного развития работает! Не факт, что закончившие эту программу потом идут заниматься рабочим развитием (планируют многие, но доходят пока – немногие). Но уж если дошли до рабочего развития – заканчивают, проходят по резидентурам до конца, не сливаются на полдороге. Обещали “научить развиваться, не сливаться от сложной работы” – и реально научили! У нас таких было две группы. А вот “люди с улицы”, которые пошли по нарезанной на маленькие куски программе – они очень часто срываются. Если это была крупная покупка “семестров” или “стажировок” старого образца, то там кое-как доходили. А тут – полтора месяца, и “я усталъ”.
- есть как минимум один “непереход” в следующую резидентуру по правильной причине: “у меня текущий проект закончился, остальные мне не так интересны, поэтому нет проекта для работы”. Это чётко выводится из нашего предложения “приходите в резидентуру с вашим проектом, поможем”! У кого проекта нет, тот и не приходит, бесполезно “учиться впрок”, у нас резидентура – работа. Работа бывает в проектах, бессмысленной работы в фейковых проектах нет – это не работа. В отличие от обучения, где неявно звучит: “если у вас нет проекта, приходите, подучим в свободное время, развлечётесь”. Вот у нас не развлечётесь, у нас будете работать – и с каждой очередной резидентурой всё лучше. Спросите у тех, кто их закончил, их сотни.
- мы уже объяснили, что у нас резидентуры R1-R10 и это “многотомник с сюжетом”, а не “энциклопедия-справочник”, то есть проходить их надо с первой по десятую. Но вот объяснить, что по первому разу проходить надо всё подряд, не возвращаясь – вот это пока не смогли. Но у нас нет идеи “второгодника”! У нас другой процесс, процесс развития: в каждой следующей резидентуре вы получаете ответы на те вопросы, которые у вас возникают в предыдущей резидентуре – и получаете вопросы, которых у вас в голове раньше вообще не было. А когда же всё это сойдётся в какое-то связное знание? К R10, как и запланировано. Когда “усиление мышления” (R1-R7) отконвертируется в прикладное знание инженерии и менеджмента (R8-R10) – и на выходе получится тот самый инженер-менеджер, который и должен быть мастером в нашей Мастерской инженеров-менеджеров. Так что а) не надо возвращаться, если что-то недопонято, наоборот – ответы и допонимание будут впереди! Польза повторного прохождения, конечно, будет – но она будет только по окончании полного прохода! б) не надо делать перерывов и отдыхать: это путь к неуспеху, ибо кривые забывания никто не отменял – тут те же эффекты, что при изучении иностранных языков. Вот вам на эту тему два материала: мой текст 2014 года “Как зажечь мастерство”, написанный ещё когда не было ШСМ (Как зажечь мастерство: ailev — ЖЖ) и свежайший пост Юлии Чайковской, наставника программы рабочего развития – Пост на помидорку: резидентуры и переходы между ними, и там “Интуитивный ход про «остановиться вчитаться допонять» в случае с руководствами - не работает. Работает контринтуитивный «брать и делать» да, сейчас, когда недостаточно ясности. Ясность не появится, если не делать дальше. И это не потому что плохо читали, а потому что видимость еще не полная - объекты внимания, которые помогут увидеть недостающее, предъявляются в следующих руководствах”.
Иван Закутный поучаствовал в митапе канала AI-Driven development Родиона Мостового (https://www.youtube.com/watch?v=brDGV_btDJY), обсуждали его Quint Code (GitHub - m0n0x41d/quint-code: Structured reasoning framework for Claude Code, Gemini, Cursor, and Codex — hypothesis-driven decision making with auditable evidence trails · GitHub – 1.2K stars, 94 forks на сегодня) и мой FPF (GitHub - ailev/FPF: First Principle Framework · GitHub – 247 stars, 43 forks). Интересно было узнать, что сам Иван не пользуется своим популярным продуктом, а пользуется полным FPF. И Родион Мостовой пользуется FPF, у него тоже есть skills для FPF – https://github.com/CodeAlive-AI/fpf-s. Но у них есть мысли, как правильно сделать skills из полного FPF, чтобы упростить его использование. И уже есть интересные отзывы о “первых использованиях”, например, “Проверил, поставил поверх своего проекта, который эмулирует работу организации автономных агентов-разработчиков. Нашёл узкие места - помог оптимизировать” – Telegram: View @ai_driven. Я послушал, почитал комменты – для меня там всё тот же вопрос “как объяснить универсальность первых принципов, универсальность интеллекта, универсальность трансдисциплин”. Действительно как отвечать на вопросы вроде “для чего математика?”, “для чего простому разработчику семантика?”, “что такое эпистемология и зачем она в software engineering?”. Многие пришли на тему SDD (spec-driven development). Поможет ли FPF в этом? Конечно. Если FPF некоторый общий усилитель рационального мышления, то вопрос “для чего это” такой же трудный, как и “для чего вам AI-агенты”. Да для всего!
Договорились с менеджером одной из крупных международных компаний (наш реформатор, традиционно просил нигде не упоминать его имени-фамилии в публичных материалах) о семинаре по его опыту очередной большой трансформации в очередной транснациональной корпорации: “в последние 4 месяца я в основном занимаюсь трансформацией R&D функции в EMEA (19 команд, 48 систем) в компании топ-1 мира производителе платежных терминалов, топ-3 касс и всяко платежные серверные системы. Можно писать вопросы по всем руководствам. Вопросы ожидаются в основном практические: «Как вы это применили», но можно и любые” – и там ссылка на сбор вопросов на семинар, а также заранее ссылка на Zoom – Telegram: View @systemsthinking_course. Чуть выше можете посмотреть на краткое описание проекта. Там было использовано в основном знание R7 (методология) и R10 (системный менеджмент) – то, до чего инженеры-менеджеры часто не добираются, а зря. Проблемы у всех прикладные (системные инженерия и менеджмент), и неплохо бы с этим материалом быть знакомым, просто “усиления интеллекта” ведь явно не хватает. Но никакой инженерии и менеджмента без усиления интеллекта обычно не бывает, поскольку системное мышление у всех “на входе” отсутствует, а какие же системная инженерия и системный менеджмент без системного мышления? В общем, приходите на семинар – 24 марта 2026 в 17:00 MSK (это вторник, обычное время нашего методсовета).
Ещё один интересный вопрос, которым я озаботился – это обсуждение SoTA традиций в плане их Парето-фронта-портфелей и NQD-портфелей, а также decision theory для такой портфельной работы. В FPF есть уже много деталек для такой работы, но нужно сосредоточиться и добавить терминологию портфельного обсуждения (включая precision restoration), собрать этот разговор в несколько паттернов. Как всегда, получил “заделы” – и я вставил теперь их в план работы от 1 февраля. Этот план до сих пор лучшее отражение общего движения с FPF – Начинаем февраль 2026: громадьё планов по FPF: ailev — ЖЖ. А ещё вышла новая статья Виталия Ванчурина, она даёт очень приличную math lens для NQD OEE в FPF, буду использовать. Вот посмотрите, что я там спрашиваю про NQD OEE в FPF (первые два такта диалога), а затем два такта диалога о том, что даёт для этого статья Ванчурина – https://chatgpt.com/share/69b9b7b2-a4d8-8013-9fdf-104eaf8b1445. С NQD OEE связана довольно хитрая онтология, участвуют несколько пространств и легко запутаться. Статья даёт общее понимание, что там за пространства и как связаны, как можно делать их характеризацию. Там алгоритмика обычно обсуждается из open-ended evolution (работы вроде [2003.08536] Enhanced POET: Open-Ended Reinforcement Learning through Unbounded Invention of Learning Challenges and their Solutions и [2406.04663] LLM-POET: Evolving Complex Environments using Large Language Models, разные вариации POET-алгоритма), а у Ванчурина математика в статье хороша для того, что происходит в этих алгоритмах. Она интересна для того, чтобы выбирать характеризацию и репрезентации. У меня В FPF характеризация уже проработана, репрезентации/представления вот сейчас прорабатываю (в том числе распределённые представления, которыми и занимаются в глубоком обучении), а дальше можно поддержать этой математикой самые разные теории, которые рассказывают об эволюции. Виталий молодец, будьте как Виталий!
Григорий Сапунов вытащил ещё одну интереснейшую тему – он сделал бенчмарк на архитектурное мышление нейросеток ([2603.00601] Theory of Code Space: Do Code Agents Understand Software Architecture?, обзоры-посты в Telegram: View @gonzo_ML). Идея там в том, что он делает генерацию синтетических данных с вариациями архитектуры – и затем проверяет, ловят ли модели эти вариации. Меня там интересует прежде всего вопрос, что же там Григорий считает “архитектурой”, какая онтология у него в этом слове. При этом он изо всех “топ-блогеров про архитектуры нейросетей” единственный не поддался на линию попсификации (“вы услышите из нашего блога о новых продуктах знаменитых фирм, отберём хлеб у маркетинговых отделов этих компаний”) и продолжает делать качественные обзоры новых архитектурных идей – и вкус у него при этом отменный, он отслеживает world models (и я, и я!) и архитектурные новинки LLM (наверное, он последний из могикан в этом деле) и, как видим, не бросает тему “архитектура” (в последней статье это даже не “архитектура LLM”, а архитектура кода). Я, когда по своему плану от 1 февраля доберусь до “архитектура как фундаментальное учение (первые принципы) о структуре” в составе FPF, обязательно подробнейше проработаю его статью. Григорий молодец, будьте как Григорий!
