Выполнил трудовой подвиг, закончил основную работу над частью G в First principles framework, которая должна генерировать пакеты архитеорий, для этого ещё было много чего добавлено и в другие части. И ещё обновил предисловие, а то оно уже окончательно отстало от жизни. И, наконец, вписал второй строчкой, что я к этому тексту имею какое-то отношение, равно как и не очень живые мои коллеги. Итоговый текст (2.8Mзнаков в .md): First Principles Framework — Core Conceptual Specification (holonic).md — Яндекс Диск.
Основное, что теперь поддерживается в FPF:
– часть G даёт управляемую фабрику SoTA-пакетов архитеорий: как собирать, пакетировать и публиковать наборы конкурентных методологических традиций внутри какой-то инженерной или менеджерской дисциплины с едиными правилами сравнения и выбором под задачу (selector в паттерне G.5).
– алгоритмы многокритериальной оптимизации NQD (новизна качество решений, и не одно решение, а набор решений, которые выходят на границу Парето). Выигрывают (доминируют) решения или чрезвычайно сильные по какой-то характеристике, или дающие уникальное поведение, которое не дают другие. Доминируемые (у которых выграли) решения выкидываются, не-доминируемые – победители, они остаются все, а не берётся только какое-то одно.
– теорема бесплатного обеда (которого не бывает, NFL, no free lunch theorem): постановка задачи общая, эффективное решение можно найти методом для какого-то частного случая. Сигнатура и реализации.
– дисциплина как семейство описаний методов, которые делаются различными научными и инженерными школами
– выбор эффективного метода, если он есть, переход к созданию нового метода, если его нет
– открытая эволюция (open-ended evolution) через одновременную эволюцию проблем и решений (всё это вместе будет OEE-NQD, ибо эволюция будет разбегаться на множество решений, оптимальных для своих ниш, это не “получение одного решения”). Часть этого было в посте про развитие развитых: https://ailev.livejournal.com/1777619.html
– учёт “горького урока” (bitter lesson от Sutton и scaling laws из машинного обучения): если у тебя автономный агент, то от метода-предписания переходи к заданию правил-ограничений и бюджета, а дальше там пусть экспериментирует и эволюционирует.
Дальше смотрим, как вся эта “тарабарщина” описывает современные реалии инженерии и менеджмента, которые все оказываются реалиями бесконечного развития (open-ended evolution) примерно по той линии, которую я развернул в тексте “Развитие для развитых” (https://ailev.livejournal.com/1777619.html).
Например, берём последнюю строчку, про bitter lesson (оригинал текста про этот урок от Rich Sutton: http://www.incompleteideas.net/IncIdeas/BitterLesson.html, март 2019, этот урок подтвердился с тех пор многократно). Далее берём тренд на agile – и говорим, что это ведь ровно то же самое, только не для искусственного интеллекта, а для естественного. Надо только сообразить, что команда проекта – вполне себе “коллективный агент”, способный действовать автономно. Так что agile – это когда вы прекращаете “руководить” (давать людям инструкции, как именно им работать), а ставите какие-то ограничения (Constitutional CNI, natural collective intelligence), выдаёте бюджет – и просите результаты (и дальше долгие дискуссии, это будет “анархия” или действительно “подконтрольная производительная работа, как обещали”, в FPF это тоже затрагивается: “подконтрольная работа, а не анархия”). Поэтому грузим файл FPF в GPT-5 Pro и интересуемся: насколько FPF поддерживает bitter lesson preference, то есть инициативу агента в выборе метода по сравнению с чётким следованием скрипту? Ответ: на 9 баллов из 10! Ещё бы, я над этим усердно работал. Дальше спрашиваем GPT-5 Pro про то, верна ли наша догадка, что согласно FPF ход на agile тут тот же самый, что ход bitter lesson preference на “дайте AI-агенту простые инструменты, ограничения и возможность подумать побольше, а не предписывайте, как именно думать, метод он под свой частный случай подберёт сам – прорывы в эволюции этих размышлений, а не в хитроумности метода, которым вы заставите работать агента”?. Грубо говоря, что побеждает не хитромудрость скрипта-инструкции, а много ресурса и эволюция в условиях ограничений? Вот короткий ответ на не очень русском языке, но понятный: “Поддерживает ли FPF Bitter-Lesson «agile»? Да. В FPF есть явная BLP-политика (Bitter-Lesson Preference), требующая предпочитать общие, масштабируемые, дающие агенту свободу методы — при равной безопасности/законности — перед узкими, «подправленными руками» эвристиками. Также действует минимально-предписанный стиль: правила-как-запреты вместо пошаговых скриптов; агент сам выбирает последовательность функций в рамках ограничений (описано паттерном SoS-LOG). Это — прямое философское обоснование agile (автономные команды, итеративные решения, «обновляем инструкции текстом, а не перекомпилируем процесс»). В FPF это зафиксировано как BLP-3 (Minimal-Prescription Default) и Scale-Audit/параллель проверки доминирования при равных бюджетах (G.9 Parity + E/E-LOG)”.
Дальше этот ответ разворачивается подробно, со сравнениями терминологии lifecycle и agile. Всё это, начиная с вопроса о том, как соответствует FPF тренду bitter lesson и дальше разворотом про “правда ли, что это ход на agile, если учесть автономию команды” и даже в самом конце генерацией пакета отслеживания хода agile-проекта общего вида, можно почитать вот тут: https://chatgpt.com/share/68dbb823-76a0-8013-bf71-942073c89120. Язык там в жуткой “родной” (кхм, “нейтральной” по отношению к предметным областям) терминологии FPF, зато одинаковой для чего угодно, не только для описания agile. Словарик перевода “на аджайлный” или “проектного управления” там тоже приводится, тем более что там ведь ещё и разные варианты – скажем, биологические проекты используют другой язык описания того же самого, в этом и фишка. Да, многие ходы и сопоставления в этих ответах от нежити требуют ручной доводки, но попробуйте найти какого-нибудь живого спеца, с которым вы можете поговорить на эти темы “агентности, свободы и подкотрольности в agile, проектном управлении, AI агентах”, и чтобы этот живой спец делал в первой же прикидке (а по ссылке как раз “первая прикидка”, без какой-либо отладки) хотя бы столько же, а не много больше ошибок. Вопрос о том, чтобы этот живой спец уделил достаточно времени, я даже не ставлю: денег спец попросит много, результат выдаст так себе, и это сразу понятно, поэтому живой спец такой вопрос и не получит. Но нужен ли ответ на такой вопрос? Спросите у тех людей, которые разрабатывают все эти agile-правила для больших и маленьких команд, пишут книжки про этот agile, а до этого – людей, которые так же рьяно занимались процессным управлением, проектным управлением, писали стандарты серии ISO 9000, где прямо прописана “работа по скриптам”. Тут, конечно, будет буря народного возмущения, что это всё игнорирование даже не нюансов, а “природы проектов”, но нейтрального языка для обсуждения этого всего, увы, нет – кроме какого-то языка из моих руководств по рабочему развитию, а ещё вот этого более продвинутого языка FPF.
Следующий содержательный такт должен быть – это выделение кроме ролей агента (считайте, что BLP как раз про это: если у вас разумный агент, то вы даёте ему больше свободы, если не очень разумный – пишете более хитроумные скрипты) и роли преобразователя (в наших руководствах это “создатель”) и других трансдисциплинарных, то есть универсальных для многих предметных областей ролей. Скажем, роли модуля, для которой можно определять характеристики cohesiveness и coupling и который является основным предметом обсуждения в evolutionary architecture. И ещё разбирательство с ролями неуниверсальными “для прикладного применения” – каждый раз разными, отвечающими на разные интересы в разных прикладных ситуациях. Дальше ещё вопрос принятия решений в условиях неопределённости, и тут мы сразу попадаем в область архитектурных характеристик (-ilities) как универсальных характеристиках уже не системы, а холона в какой-то “архитектурной роли”, архитектурной динамики как движения холона в пространстве его архитектурных характеристик. Далее trade-offs в архитектурных решениях и там пакет архитеорий принятия решений (decision theories). Но это потом, после семинара.
Основное время у меня сейчас уходит на подготовку к семинару, где стоит задача не методологическая (у меня тут простые принципы: “собрать всё под одной обложкой, оптимизация потом, лексика потом, разъяснения потом – пока важно, чтобы было что оптимизировать, называть и разъяснять”), а методическая: как объяснить, зачем нужен FPF, что он такое, как устроен, как пользоваться? Семинар уже 4 октября 2025, в эту субботу, (https://ailev.livejournal.com/1776026.html), я готовлю к нему слайды. И поскольку речь идёт о первых принципах (о которых забывают рассказать даже в вузовских программах, тем более в школьных), а именно такие у меня в FPF, то это струдная задачка. Скажем, отличия аксиоматических теорий от постулатных, без различений которых нельзя говорить об инженерных обоснованиях, научных “доказательствах” (в кавычках!) и всяком подобном. Скажем, берём “аксиому”, затем “аксиоматические теории” и спрашиваем, как они связаны с проектами вроде атомной бомбы и спутника GPS. Ох, вам надо взять аксиоматическую теорию с теми самыми аксиомами, потом построить Риманову геометрию, на её базе теорию относительности, затем атомная бомба исходит из постулата, что скорость света не может быть больше 300тыс. км/секунду (нетривиально, да? Там E=mC^2, где С это та самая скорость света, а если масса чуток убудет, то высвободится дикое количество энергии, и оно каааак жахнет!), а GPS - никаких навигаторов, если не учесть кривизну пространства от массы Земли (не круглость Земли, нет – именно искривление пространства от массивного объекта “Земля”). И где-то там в основе этих уже понятных бомбы и GPS для “средств доставки” ты хорошо понимаешь, зачем оно. А что “оно” без аксиом и постулатов и понимания их различий где-то там “в первых принципах” никак, и ты можешь не понимать, а только по телевизору смотреть на понимание других – вот это уже не осознаётся, ибо даже в голову не приходит. FPF как раз про первые принципы, только тянем это дальше к инженерным процессам, к менеджменту, инженерии личности и общим идеям “Развития для развитых” (https://ailev.livejournal.com/1777619.html). Ну ничего, справимся как-нибудь.
