Вот и до меня дошёл нейрослоп, в arXiv появилась статья со ссылкой на мою работу по системной инженерии и FPF. По содержанию там – типичное приложение FPF к анализу LLM-проектов, но авторы “не справляются с языком” и свою формализацию так и называют – FPF (а не “что-то наше на базе FPF”), год публикации FPF вообще ставят 2023 (хорошо что хоть вообще сослались). Вот, полюбуйтесь: “AI-Assisted Engineering Should Track the Epistemic Status and Temporal Validity of Architectural Decisions”, [2601.21116] AI-Assisted Engineering Should Track the Epistemic Status and Temporal Validity of Architectural Decisions (это мне Google Scholar сказал, что “тебя тут цитируют”). Как вам такое прямо в абстракте: “We formalize these requirements as the First Principles Framework (FPF), ground its aggregation semantics in fuzzy logic, and define a quintet of invariants that any valid aggregation operator must satisfy. Our retrospective audit applying FPF criteria to two internal projects found that 20-25% of architectural decisions had stale evidence within two months, validating the need for temporal accountability”. “Формализовали как FPF” вместо ожидаемого “формализовали на основе/с помощью FPF”. Внутри там всё такое. Скажем, “The Transformer Mandate. We introduce this term for a structural constraint: the entity that finalizes a decision must be external to the generation loop. An LLM may propose hypotheses and gather supporting evidence (Abduction and Induction), but ratification requires an external verifier” – но ни слова о том, что термин The Transformer Mandate введён не этими авторами, а упоминается в FPF. И то же самое со многими другими терминами и идеями. Зато в табличке сравнения с 6 фреймворками выиграл FPF – но это ж мой FPF, так что мне радоваться! Всё ведь хорошо: FPF как раз был использован по назначению, первый автор Sankalp Gilda из флоридской DeepThought Solutions, второй – Shlok Gilda, Department of Computer Science, University of Florida, хотя я не сомневаюсь, что авторы сами написали там много строк, ибо насмотрелся самых разных генераций на основе FPF (и FPF ведь именно для такого заточен! Для качественных генераций текста на своей основе). Моя реакция: расслабиться, получать удовольствие. Мы этого хотели, вот нам! Не удивлюсь, если у FPF появится ещё десяток авторов, которые его придумали и “застолбили” в науке. Пока же FPF прямо на сейчас имеет 188 звёзд и 36 форков в GitHub, свободно лежит вот тут: GitHub - ailev/FPF: First Principle Framework. Пользуйтесь!
Ситуация с AI-агентами и IDE (integrated development environment) ощутимо сдвинулась где-то в конце декабря-середине января: там произошла конвергенция (термин этот любит в таком смысле упоминать Tony Seba) довольно большого числа технологий: пришло новое поколение железа, оно дало новое поколение более умных моделей, эти модели поддержали скоростную разработку своей инструментальной и интерфейсной (к людям и другому софту) обвязки. Всё это нацелено сейчас на поддержку workflow для программистов, но мне кажется, что как раз вот прямо сейчас можно уже думать о поддержке проблематизации в разработке софта, что существенно отличается по workflow от “написал тест как постановку задачи, написал код, кручу теперь в цикле, отлаживаюсь”. Эффекты в real life требуют совершенно других действий для их характеризации и учёта, у меня как раз был последний семинар про это, это ж “развитие для развитых”: вам надо куда-то двигать ваш готовый уже код, чтобы он решал какую-то проблему, а мир дрейфует и проблемы меняются. На эту же тему любит писать LeCun, говоря о том, что реальный AI должен действовать в мире и наблюдать эффекты. И выхваченный флоридскими авторами из прошлого абзаца кусок FPF бьёт в эту же точку: решение вчерашней проблемы не является решением, “осетрина или первой свежести, или не осетрина”. А дальше можно сдвигаться и на другие инженерные процессы, которые не так просто автоматизируются без роботов. И вот тут IDE могут сдвинуться и на IWE, но в новом понимании этого слова. Я писал про integrated writing environment и ходам на личный и затем корпоративный экзокортекс в “Мышление кодированием в IDE, мышление письмом в IWE” (2020, Мышление кодированием в IDE, мышление письмом в IWE : ailev — ЖЖ) – всё тамошнее содержание по факту реализовано, но вот с “общей памятью для коллективной работы” и стыком коллективного и личного до сих пор концептуальные проблемы, а “работа с Git” пока не вышла за пределы навыков программистского сообщества. Даже у машиностроителей всё устроено в части управления версионированием и коллективной разработкой не так, как у разработчиков софта. В любом случае, пошло что-то вроде “войны браузеров” — это когда каждый браузер добавлял фичи по сравнению с конкурентами и стандарт HTML быстро вырос до пятой версии, чтобы хоть как-то удержать универсальность. Мы имеем теперь такую же “войну IDE” как универсального IWE, где W уже не writing, а working. IWE – integrated working environment. При этом интеллект слишком разнообразен, чтобы удержать его стандартизацией, но законы системности достаточно универсальны, чтобы универсализовать нижние системные уровни, например, MCP вполне может оказаться “стандартом интернета AI-агентов”. Конечно, всяческие инструменты организации экзокортекса разработчика софта, писателя (неважно, художественной литературы или технического писателя), инженера (CAD, PLM), менеджера (ERP, CRM) существовали десятилетиями, новое тут только в быстром росте поддержки workflow для AI-агентов и стандартизации подключения контекста с инструментами (слово “контекст” ещё пару лет назад не использовалось, это всё были “корпоративные данные”, “корпоративные базы данных” – безотносительно того, что за системы или люди их обрабатывают. Язык поменялся: для агентов это всё “контекст”, многоуровневая память).
Вообще, вот это резкое ускорение развития я уже наблюдал на примере фондового рынка. В начале 90-х годов прошлого века появились брокер-дилеры, организующие выполнение заказов своих клиентов через интернет, затем они обнаружили, что “на одного трейдера приходится 11 программистов”. Автоматизация заключения сделки привела к тому, что сделка вместо секунд на биржевом аукционе начала занимать время меньше секунды, а затем и вообще – миллисекунды в HFT (high frequenсy trading), люди-трейдеры заведомо перестали успевать, принятие решений о сделке перешло к роботам, исчез тот самый “один трейдер на 11 программистов”. Профессионалы стали развивать системы автоматической торговли, мастерство трейдеров стало в этом. Ситуация на рынке меняется за миллисекунды и люди принципиально не успевают разобраться и принять решение, как реагировать на эту ситуацию, какие именно сделки заключать. Торговля стала алгоритмической, и это основные объёмы торговли, принятие торговых решений на биржевом рынке людьми занимает всё меньшую долю. Сингулярность часто определяют как скорость изменения мира такая, что люди прекращают ориентироваться в этих изменениях: лёг спать – мир был одним, а проснулся – мир уже совсем другой во многих важных чертах, поэтому уже надо решать другие проблемы, и так уже всё время. Можно считать, что когда постановка проблем ввиду скорости изменения мира перестаёт выполняться людьми и сдвигается на роботов точно так же, как заключение сделок на рынке ценных бумаг перестало выполняться людьми-трейдерами, которые уже не могут успевать реагировать на изменения рынка в масштабе миллисекунд, то это и есть сингулярность. Аналогия с фондовым рынком тут более чем аналогия: фондовый рынок представляет собой интерфейс для обмена сигналами о потребностях людей, ибо капитал течёт туда, где есть потребности – кто-то научился решать очередной класс проблем, за которые потребители готовы платить. Фондовый рынок – это один из механизмов оценки качества развития на крупных масштабах: если фирма хорошо развивается, её акции стоят дорого. Если застряла в развитии, то акции резко дешевеют. Мы говорим о развитии себя и мира в условиях наступающей сингулярности, когда люди уже не в состоянии сами проходить шаги развития, они могут только присматривать за серверами и алгоритмами, которые что-то там развивают – то есть и ставят проблемы, и решают их, и собирают информацию о качестве решения и дрейфе окружения, о новых возможностях и возвращаются к постановке очередного портфеля проблем из зоны ближнего развития с получением очередного портфеля решений. Вот, всполохи сингулярности есть: когда ты как человек не успеваешь за Парето-фронтом интересных проблем, а не только за Парето-фронтом решений для этих проблем, но “машины развития” успевают – на миллисекундных интервалах, корпорации становятся “высокочастотными” в плане своего цикла развития (проблематизации, стратегирования, нахождения решения, производства, сбыта, получения информации о результатах и о дрейфе среды использования и дрейфе среды возможностей). А люди? Люди перемещаются в “директоров по развитию роботов-компаний”, как трейдеры стали “директорами по развитию роботов-трейдеров”. Нет, я не оспариваю общепринятое определение сингулярности (их три разных), но сингулярность по моему определению проще замерить, причём она оказывается немного неравномерной по предметным областям, у системных программистов (написать браузер или компилятор, даже операционную систему) наступает пораньше, у прикладных программистов (эффекты во внешнем мире! Так просто тесты не напишешь!) попозже, у многих других ещё позже – но всё-таки у всех довольно быстро.
Стартовали группы резидентур R1 (распожаризация), R5 (системное мышление), R8 (системная инженерия). Я автор руководства по системному мышлению и системной инженерии, поэтому активно участвую в чатах R5 и R8. А как научный руководитель ещё и иногда комментирую посты в клубе участников R1. Самый главный вопрос обычно – это определение целевой системы. На этой неделе опять занимались целевой системой ритейла (почитайте комменты в Упражнение "Назови систему", там мне особенно приятна фраза “Мне кажется я за эти пару дней узнал об устройстве компании больше, чем за год работы” – это обычно для нашей программы рабочего развития). В R5 обсуждали разницу между “разработчиком системы” с масштабом влияния на несколько тысяч человек и “архитектором системы”. R5 – это ведь резидентура по системному мышлению, а разница проясняется в R8, резидентуре по системной инженерии, я давал ссылку вперёд: отличия ролей разработчика с “делегированием разработки” и архитектора с “отслеживанием архитектуры, в том числе отсутствия деградации от изменений в ходе распределённой разработки”. А в R8 опять встретилось банкротство, и там обычная засада: смотрят на банкрота как целевого, а что при этом происходит ограбление кредиторов (“Вам были должны? Расслабьтесь, забудьте об убытках, мы объявили должника банкротом и тем самым простили ему долги”) забывают. И тут же вылезает, что “должник” может означать абсолютно разные роли: сторону судебного процесса по процессуальному кодексу, “должник в обязательстве перед кредиторами”, и “банкрот”.
На методсовете мы решили, что я сделаю небольшую паузу в работе над FPF и напишу “Руководство по Мастерской инженеров-менеджеров”. У меня накопилось некоторое количество постов, которые я перепишу и организую в общее оглавление. Будет инструкция по устройству и пользованию МИМ. Положим его ко всем остальным руководствам, надстроим над этим AI-ассистента (он у нас называется Aisystant), будут все приходящие и продолжающие получать там ответы на типовые вопросы, главный из которых – “а оно мне надо?!” и следующий – “ОК, оно мне надо. А теперь куда, и что?”. Удивительно, но после того, как я собрал в кучку мои предыдущие посты, наметил оглавление, дописал какие-то кусочки, получилось уже 400К знаков, это небольшая книжка. Оказывается, про МИМ можно много чего рассказывать! Неудивительно, что все путаются: действительно много всего, раскиданного по разным местам в зачастую устаревших версиях. Так что я некоторое время буду “писать в стол”, иногда публиковать тут отрывки, а затем выложу результат в стандартной форме руководства. Раньше мой темп был 20К готового текста в тучные дни и 5К в тощие дни, а сейчас посмотрим. В любом случае, я хотел бы с этим справиться ещё в феврале, а там посмотрим. Сингулярность, она такая – каждый день что-то новенькое из проблем. А пока чищу фразы с описанием типового цикла развития, вроде “Обновление портфеля проблем → Проблематизация: ставка на проблему в зоне ближайшего развития → Стратегирование (выход на портфель решений и ставка на конкретное решение) → Проверка решения и его воплощение → Ввод в эксплуатацию → Замер результатов → переход к следующему шагу (обновление портфеля проблем)”.
Мои рассмотрения/review проектов по первому шагу системного мышления начнутся 12 февраля и будут идти примерно раз в месяц – по тому же формату, что я опробовал весной 2025 года, содержание изложено в тексте про “барышню-мадам”: Тренировка "Вы пойдёте к топ-менеджеру?" или "Барышня-мадам".: ailev — ЖЖ. Пять человек мини-группа, на два часа в онлайне, чат, слайды, 20 минут моего рассказа, а затем по 20 минут на проект каждого участника. Поскольку люди иногда появляются весьма продвинутые, мы сдвигаемся с первого шага мантры системного мышления на второй, но до третьего шага не помню, чтобы доходили (разве что в режиме “вот дальше вы там подумайте об этом и вот этом”. Но особенность формата позволяет участвовать в нём и вообще “с улицы”, и такое бывало – хотя редко, чаще приходили люди, уже хлебнувшие проектной ясности из наших руководств.
Приняли решение проводить XVI рабочую встречу INCOSE RUS по проблемам системной инженерии в этом году 4-5 апреля, а конференцию МИМ по современной системной инженерии и менеджменту 18-19 апреля, готовлю об этом официальное объявление, но вы можете уже отмечать даты в своих молескинах.
