lytdybr
Текст FPF последнюю неделю я не менял, но новости про него таки есть:
* на GitHub у него уже 207 stars, 41 forks, https://github.com/ailev/FPF/.
* есть восхитительный групповой отзыв от студентов Вячеслава Кунина: "Вчера со студентами обсудили, что именно из того, что я им дал в рамках курса как сильно подняло качество ответов в ChatGPT. ... 3. Использование FPF (First Principles Framework) как документа, структурирующего ответы ИИ, чтобы не было общих, бесполезных ответов. ... Было невероятное удивление, что теперь нет бестолковых ответов - или ответ есть, или чёткое обоснование того, что тут качественного ответа не может быть получено. ... FPF -- тут бомба, сказали, что на сложных задачах просто кратное улучшение" (https://www.facebook.com/veaceslav.cunev/posts/pfbid02mhiRDB6c6c3ZCNfzoGtWM3y9D5NghyUu3fQs8yiZfotiWszpPX8UhyLQMAJr1vu1l).
* Principled Claude Code как ещё одна попытка сделать skills на основе FPF -- https://github.com/m0n0x41d/principled-claude-code, и тут интересная история. Первый заход был обычный: "инструмент, обеспечивающий аудит" (и дальше показана цепочка hypotheses → predictions → evidence → decisions, которая мало похожа на аудит, а больше напоминает какой-то общий "исследовательский процесс", даже не замкнутый в цикл), но если поглядеть в дерево файлов, то там да — просто расписана структура записи evidence, чистый аудит. Но тогда это не Principled Claude Code, а Evidenced Claude Code или Audited Claude Code. С учётом материалов семинара "Развитие для развитых" я дал совет развернуть уже всё от Agile (цепочки) в циклы (DevOps работа) и далее двойные циклы (фабрики проблем и решений) с опорой не на одиночные гипотезы и решения, а на работу с портфелями и явными операциями выбора в качестве решений. Предложил скормить не просто FPF для дистилляции, а FPF+слайдомент семинара "Развитие для развитых". Без вот этого слайдомента всякие агенты плохо считывают развитие в FPF, они считывают это как "проверяемое и воспроизводимое творчество", далее прокидывают творчество (ибо у них DevOps bias у всех — "проверить-записать", это очень естественно!) и остаётся только вот эта "проверяемость", от творчества только отсылки к "какие-нибудь девелоперы там сбоку пусть сами творят", а всё новое про проблематизацию и стратегирование "не резонирует" с этим выученным DevOps менталитетом, за этим надо следить специально. Это всё было передано Claude Code, чтобы он там всё сам как-то переделал. И вот поглядите, как хорошо получилось -- таки все фабрики на месте! Тут вдогонку надо, конечно, ещё заметить трудности текущего момента: LLM плохо сами разрабатывают skills, но очень выигрывают от использования skills. Это описано в статье "SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks", https://arxiv.org/abs/2602.12670. Self-generated Skills provide no benefit on average, showing that models cannot reliably author the procedural knowledge they benefit from consuming. Focused Skills with 2--3 modules outperform comprehensive documentation, and smaller models with Skills can match larger models without them -- с оговоркой, что результаты сильно отличаются для разных предметных областей. Мой вывод: если не давать AI-агенту "самостоятельно разрабатывать skills", но добавлять процедурное знание из FPF+слайдомента, получается всё более чем неплохо. Вот тут про то, как получить слайдомент и видео разъяснений к нему, если пропустили семинар "Развитие для развитых": https://t.me/modelcollect/10337
* ещё один отзыв после семинара: https://systemsworld.club/t/razvitie-dlya-razvityh/36576 (там вот так: "Что касается моих проектов, я по результатам этого текста написал 11 разных пунктов, где надо бы посмотреть NQD-характеристики и Парето-фронт. Просто приведу пример (который, конечно, для операционного использования требуется доработать), который даёт нейросетка с FPF и слайдами семинара: характеристики, по которым стоит оценивать партнерство с трейдинговыми командами" -- и дальше пример).
* ещё и ещё раз обсуждается вопрос, должен ли я писать инструкцию, как использовать FPF (и слайдомент к нему по "Развитию для развитых") в самых разных операционных системах, в которых самые разные приложения, в которых самые разные LLM и в которых ещё и какие-то лимиты и детали интерфейса меняются каждую неделю. Нет, я делаю FPF как стабильный концептуальный продукт -- а дальше уж каждый сам пристраивается к именно своему любимому приложению в эти две недели, пока у него стабильный интерфейс и лимиты на размеры файлов, а потом пристраивается после своих инструментальных изменений ещё раз, опираясь на сообщество таких же пользователей конкретного инструментального окружения.
* мой план по FPF остаётся прежним, я пойду по нему с начала марта, как и планировал -- вот тут я его написал наиболее подробно, 1 февраля 2026: https://ailev.livejournal.com/1788706.html.

Выявили интересный паттерн в последних наших наборах: приходит инженер по специальности А (скажем, программист), занимающийся какой-то предметной областью Б (скажем, трейдинг). Дальше задаём вопрос про целевую систему -- и обнаруживаем, что никаких рассуждений по поводу предметной области Б не происходит ввиду незнания носителем специальности А предметной области Б. Вот буквально: ни один учебник не читан, типовые решаемые проблемы неизвестны, типовые методы решения этих проблем неизвестны, что там на Парето-фронте и какие характеристики -- непонятно. А как же работа?! А вот так, "по наитию" -- опыт общения с коллегами, опыт чтения каких-то постов в блогах, документации к софту, и прочих обрывков знаний. Например, ещё ни разу не было, чтобы люди разобрались в том, что такое рынок ценных бумаг, какие там основные проблемы, чем занимается инфраструктура, чем именно торгуют (ибо не "бумагами" же! что такое "ценная бумага", почему рынок "фондовый"?). Всё то же самое -- с ERP, где по поводу "плана" и его характеристик, а также "что там меняется в ресурсах, и что это там за ресурсы в ERP", "где тут у вас поток и как именно на него влияет ERP, если вы внутри ERP поправите какую-нибудь запятую или измените цифирку" ответов обычно нет. На это накладывается "недержание типов" и неточность в составлении текстов. Это не у каких-то конкретных людей, тут "ничего личного", это типовой сценарий, там часто несколько человек участвуют в групповом обсуждении, с одинаковым примерно успехом -- см., например, рассмотрение ERP и там мои комменты -- https://systemsworld.club/t/zadaniya-sistemy-v-fizicheskom-mire-iz-rukovodstva-r5-sistemnoe-myshlenie/36664/. Я предлагаю там пойти и почитать учебники, но почему-то до этого действия не доходит, продолжается "угадайка", и это, повторюсь, не только конкретно эти участники диалога, по факту такое мы видим буквально со всеми, кто работает с ERP. Исключение я видел только один раз: когда ERP занимались люди, хорошо освоившие теорию ограничений Голдратта, но не те, кто "читали про теорию ограничений", ибо все читали, мало кто освоил мышление согласно этой теории. У меня когда-то был способ входа в новую предметную область -- прочесть три учебника разных авторов (всего три книжки, дел на неделю), что было упомянуто во всех трёх, то и считать "предметной областью". Я понимаю, что "прочесть три учебника" -- это заведомо невыполнимое действие для большинства нынешних инженеров-менеджеров (я не обижаю, я констатирую факт). Но работать, не зная предметной области -- это тоже нехорошо. А как проверить, знает ли человек предметную область?! И какую? Скажем, в резидентурах R1-R4 моделируют предметную область -- но надо бы разобраться, люди берут в моделирование предметную область А (своей специализации) или предметную область Б (и тут мы в довольно обширном графе создателей и надо разбираться -- это предметная область нашей системы, целевой системы или какой-то ещё системы). Но так и хочется добавить какие-то замеры знания предметной области:
* основные объекты и отношения (на R1-R4 это точно моделируют, knowledge graph -- онтологика как раз про это),
* что там "течёт", что меняется в процессах (системное моделирование, R6: функциональные диаграммы или принципиальные схемы в этой предметной области какие?),
* типовые проблемы, типовые методы их решения (методология, R7) и дальше плавный переход к характеризации и Парето-фронту на этой характеризации (пока тут только слайдомент семинара "Развитие для развитых").

Вообще, очень много пишу сейчас в самые разные чаты, в том числе закрытые чаты моих семинаров и резидентур R5 и R8. И мне кажется, что мы не решили до сих пор окончательно проблему с типами:
* она как-то решается лишь к R8, но я ведь ожидаю, что её нет уже на выходе R4! Реальность пока не соответствует моим ожиданиям: в ответах на отдельные прямо заданные вопросы типы удерживаются, но в длинном тексте всяческого "мышления письмом" -- нет. Надо выяснить, что там происходит. Вот программист за типами в коде программы точно следит, в псевдокоде -- неизвестно, в простом тексте -- заведомо не следит. При этом "тип" -- понятие растяжимое. Скажем, в FPF контроль kinds устроен примерно так же, как "промышленное использование ISO 15926" (то есть используется набор из 201 понятия ISO 15926-2:2003, а не из нескольких тысяч понятий), или примерно так же, как типизация была устроена в IBM Watson (там было примерно 160 типов при выигрыше в Jeopardy! -- ESG currently uses approximately 160 semantic types, belonging to a type hierarchy, https://brenocon.com/watson_special_issue/03%20Deep%20parsing.pdf?utm_source=chatgpt.com). И дальше нужно восстанавливать точность текста, используя слова-триггеры и фрагменты онтик с понятной типизацией. Для этого у меня уже запланировано усиление FPF, вот прямо таки первой работой. Затем -- отражение в руководствах и перестройка способа, которым мы это даём людям.
* И операции -- буквально ведь люди не могут связать "подлежащее и сказуемое" и отследить связную цепочку "что какой объект делал". Похоже, что надо отдельно учить "длинным точным письменным рассуждениям", мы этому недоучиваем. Нужна какая-то теория про тексты, и я займусь этим буквально сегодня-завтра, чтобы обсудить на лаборатории по рабочему развитию: идея совмещения управления точностью текста, мышления письмом/моделированием на стадии "как из заметок собрать связный длинный текст и как убедиться, что он связный", рассказа о длинных текстах от David Deutsch и Alan Kay и разбора "молекулярной теории рассуждений" из "The Molecular Structure of Thought: Mapping the Topology of Long Chain-of-Thought Reasoning", https://arxiv.org/abs/2601.06002. Вот на эту последнюю работу я пялился ещё в январе (она мелькнула в лентах), сегодня утром мне на неё ткнули в чате поддержки программы исследовательского развития (https://t.me/modelcollect/10343), и пока я писал эти строки и кое-что уже прикидывал на эту тему -- вышел gonzo-обзор, https://t.me/gonzo_ML/4831. Так что я тут опять приостановлю своё МИМописание (pun intended) и остановлюсь на денёк на разбирательстве содержания вот этого всего перечисленного. AI-агенты, конечно, научатся речам с управляемой точностью и написанию длинных эссе, но кто-то должен научить и людей, которые будут беседовать с AI-агентами.

Решил попробовать, правда ли, что "The new "AI Photoshop" Seedream 5.0 matches Nano Banana Pro in quality and gives you way more creative freedom". Попробовал на том же промпте, который выдал картинку предыдущего поста (https://ailev.livejournal.com/1793139.html): "Нарисуй мастерскую инженеров-менеджеров (МИМ). Как устроен процесс развития в МИМ? Как МИМ растёт и масштабируется? Как обычно, в цикле бесконечного развития: осознание проблем → поиск SoTA методов мышления и работы → упаковка в руководства для людей и AI → освоение людьми с наставником → применение инженерами-менеджерами в их проектах → квалификация "мастера" (или даже "реформатора") по предъявляемому результату → мастера и реформаторы масштабируют культуру как наставники/преподаватели/лидеры МИМ, а Мастерская даёт для этого необходимую инфраструктуру и культуру. Этот цикл прокручивается не годами, а месяцами: руководства обновляются новыми SoTA методами мышления и действия по нескольку раз в год. Стилистика художника Альфонса Мухи, яркие цвета (стилистику подписывать не надо)". Нет, я не перейду на Seedream 5.0, останусь с Nano Banana Pro. Очередной пример того, что разные продукты занимают разные места на Парето-фронте. Прочтите вот этот обзор, удерживая в голове "разные места на Парето-фронте" -- https://www.techradar.com/ai-platforms-assistants/i-matched-googles-nano-banana-pro-ai-image-maker-against-bytedances-new-seedream-5-0-model-and-the-real-winner-surprised-me.

(Comment on this)

Мастерская инженеров-менеджеров: почему именно мастерская?
В эпоху перехода значительной части общения в сообществах практики (communities of practice) в формат социальных сетей и асинхронной коммуникации (спасибо ковид-затворничеству!) довольно много "сообществ единомышленников" деградировало до "групповых чатов" с редкими встречами "развиртуализации". В мастерской инженеров-менеджеров сообщество единомышленников -- это сами инженеры-менеджеры, использующие в мышлении и действии SoTA-культуру инженерии, менеджмента, исследований, изложенную в руководствах программ развития МИМ. МИМ одновременно держит инфраструктуру, выращивает программы развития, поддерживает культуру профессионального общения, ведёт исследовательскую разведку лучших практик мышления и действия, выдаёт квалификации. МИМ — это не одна роль, а целая связка разнообразных ролей, собранная вокруг основного рабочего процесса: бесконечного развития мастеров инженерно-менеджерского мышления и действия. Поэтому здесь одновременно живут платформа, наставничество, рабочие группы, конференции, исследовательские семинары, резидентуры, практикумы и, конечно, клуб. В целом МИМ явно выходит за рамки "интернет-сообщества" или даже “клуба по интересам”. МИМ -- это организационная машина бесконечного развития.

Мастерская инженеров-менеджеров как организация имеет множество самых разных ролей, и можно поэтому использовать название "МИМ" для обозначения всех них:
* организатор сообщества инженеров-менеджеров, "управляющая компания". Она в разных странах представлена разными юрлицами (ИП Ц.В.Церенов в России, Aisystant LLC в США), сообщество инженеров-менеджеров международное. Мастерская поддерживает онлайн-инфраструктуру (ввиду международного характера общение сообщества ведётся в основном онлайн -- синхронно и асинхронно), в ней есть IT-служба.
* место, где инженеры-менеджеры занимаются своим развитием в форматах, предлагаемых программами развития. В МИМ есть для этого научный руководитель, есть директор программ развития, поддерживается LXP Aisystant с доступом к руководствам, заданиям и клубу с обсуждениями выполнения заданий. Для разработки программ развития и координации работ наставников работает лаборатория, руководства регулярно обновляются, стиль наставничества тоже обновляется. Развитие инженеров-менеджеров по программам МИМ непрерывно измеряется, квалификация -- это его индикатор.
* площадка общения инженеров-менеджеров, которую они используют для развития и распространения своей культуры. Поддерживаются рабочие группы, лаборатории, инициативы по преподаванию системного мышления в вузах, инициативы по обучению детей и подростков первым принципам. Проводятся ежегодные конференции, проектные разборы/reviews.
* исследовательский центр, где отслеживается смена лучших образцов мышления и действия, доступных цивилизации (SoTA). По итогам исследований проводятся семинары программы исследовательского развития.
* просто как "бренд" культуры инженеров-менеджеров. Идеи бесконечного развития (open-ended evolution) делают инженеров-менеджеров единомышленников, они носители связанной с бесконечным развитием культуры мышления и действия.

Так что нет ошибок в том, чтобы писать: “сообщество МИМ считает…”, “МИМ как оператор обеспечивает…”, “платформа МИМ позволяет…”, “бренд МИМ транслирует…”. Есть МИМ как система, и у этой системы множество самых разных ролей -- инженеры и менеджеры вполне это могут представить.

Мастерская чаще всего выступает в роли организатора: организатор сообщества, организатор практикумов, резидентур, семинаров, конференций (в том числе провайдер платформы), организатор исследований, но главное -- организатор бесконечного развития инженеров-менеджеров. Конечно, ещё и организатор развития самой мастерской. Но вполне можно называть и само сообщество "мастерской" -- "Вася Пупкин из МИМ говорит, что развитие бесконечно" вполне ОК. И даже ОК "онлайн-площадки" (Aisystant, клуб) как понимание МИМ -- "как писали месяц назад в МИМ, развитие непрерывно и бесконечно".

Почему мастерская, а не ассоциация, совет, конгресс, мастермайнд и прочие слова, означающие какие-то сообщества и их управляющие (так и хочется сказать "органы", но нет) организации? Мастер -- это основная квалификация у наших полноценных единомышленников, которые прошли полноценную резидентуру по рабочему развитию. Мастер -- это тот, кто умеет что-то делать, в условиях реальной жизни умеет применять какой-то метод, в данном случае, умеет действовать по всем нашим руководствам. А где обычно можно найти мастеров? В мастерской!

Наши мастера -- инженеры-менеджеры, поэтому наших мастеров вы найдёте в Мастерской инженеров-менеджеров, а не в какой-нибудь другой мастерской.

Основной недостаток у выбранного термина "мастерская" -- это неявно подразумеваемый маленький масштаб, но заодно это задаёт меньший уровень "официальности", снимает неуместный пафос и объясняет возможность удержания высоких стандартов, "непопсовости", что почти невозможно, если речь идёт об организации больших масштабов.

Как устроен процесс развития в МИМ? Как МИМ растёт и масштабируется? Как обычно, в цикле бесконечного развития: осознание проблем → поиск SoTA методов мышления и работы → упаковка в руководства для людей и AI → освоение людьми с наставником → применение инженерами-менеджерами в их проектах → квалификация "мастера" (или даже "реформатора") по предъявляемому результату → мастера и реформаторы масштабируют культуру как наставники/преподаватели/лидеры МИМ, а Мастерская даёт для этого необходимую инфраструктуру и культуру. Этот цикл прокручивается не годами, а месяцами: руководства обновляются новыми SoTA методами мышления и действия по нескольку раз в год.

Линия на "мастеров" не случайна: упор тут не на чисто мыслительную работу, а на выход в физический мир, "работу руками". В MIT слоган «Mens et Manus» с латыни переводится как «Разум и руки» и подчёркивает связь академической науки и профессиональных умений. MIT всегда гордился мастерскими при университете, присказка там -- "держите руки грязными", не увлекайтесь чистым мышлением. Несмотря на то, что МИМ не университет, это "держите руки грязными" очень близко по идее: мастерская делает акцент на то, что люди в ней что-то делают, что-то созидают, что-то творят, а не просто "учатся", "развиваются".

Несмотря на то, что МИМ далёк от идеи средневековых цехов (они существенно пытались ограничить конкуренцию, что нехорошо), в нём используется внутренняя (не путать с госдипломами!) квалификация через "шедевр" -- ровно как в гильдиях мастеров средневековья. Чтобы получить квалификацию, надо публично предъявить какой-то результат, говорящий об умении. Например, инженер-менеджер в рамках своего рабочего развития должен продемонстрировать, что он инициировал и провёл организационное изменение: перевёл команду не своих подчинённых на новый для них рабочий процесс, научил новым методам работы. Если нет -- то степень "мастера" не выдаётся. Если "да" -- то степень мастера выдаётся, и вместе с ней привилегии (прежде всего возможность быть наставником в программах развития МИМ, возможность бесплатного обучения студентов по программам МИМ в вузовских группах, где мастер является преподавателем). На этом "привилегии" заканчиваются: "мастер" в МИМ -- не статусный титул, а функциональная квалификация мастерства, привязанная к демонстрируемым рабочим результатам. "Мастер десятилетней давности" -- это просто напоминание о том, что "когда-то умел", квалификацию надо регулярно подтверждать: в МИМ не столько "культ мастеров", сколько культ развития, культ SoTA, "удержать титул" невозможно. Все инженеры-менеджеры учатся оценивать мастерство по разным программам развития, в том числе чтобы уметь оценить и своё собственное мастерство, иметь ориентир в развитии. Квалифицирование -- это замер значения важного индикатора, а не присвоение титула.

Мастерская проводит резидентуры во многом по образцу и подобию художественных мастерских, приглашающих к себе резидентов-художников, которые должны произвести с использованием их ресурсов и наставничества какие-то оговорённые произведения искусства. Если это мастера performing arts, то речь может идти о подготовке концертных номеров или ещё каких-то результатов творчества. Идея резидентуры пошла ровно от художественных мастерских. МИМ по формату наследует более современный вариант резидентуры -- резидентуру стартап-акселератора, но сохраняет имя "мастерской", а не "акселератора". Хотя идеи "ускорения/акселерации" и близки, не все инженеры-менеджеры хотят стать основателями стартапов, и не всегда они хотят развивать и ускорять развитие именно стартапов. Поэтому -- всё-таки "мастерская". Место, где творят!

Сегодня, когда рядом с людьми работают AI-агенты, акцент смещается с простого “знания” на умение перестраивать методы своей работы на SoTA быстрее, чем окружающая среда становится враждебной к прежним методам работы, которые тоже были когда-то SoTA. Мастерская — это форма, которая лучше всего держит такой темп: мало пафоса, много практики, постоянная обновляемость методов, бесконечный цикл улучшения. Итоговый тезис прост: МИМ существует, чтобы организовывать не обучение, а непрерывное становление всё нового и нового мастерства — у людей, у AI и их совместных команд.

В МИМ нет культа титулов, но есть культ работы. “Разум” без “рук” превращается в умные, но бесплодные разговоры, “руки” без “разума” — в бесплодную суету. МИМ держит связку: лучшие методы, доступные цивилизации → освоение мышления и работы по руководствам с наставником → применение мастерства в рабочем проекте → квалификация по результату и возможность масштабирования. Вот почему мастерская: потому что это место, где не только мыслят, но прежде всего -- делают.

И позволим себе шутку: масонская ложа -- это здание для их мероприятий, а в переводе на русский это "строительная мастерская", ибо ложа/lodge/домик/сторожка/мастерская, а масон/mason -- это же каменщик, строитель! И масонов в мире даже сейчас по разным оценкам -- от 2 до 4 миллионов человек, их масштабам слово "мастерская" не мешает. Понятно, что шутки про масонов (и заодно иллюминатов) в МИМ самые популярные, ибо наши инженеры-менеджеры прежде всего -- создатели/созидатели. В переводе на английский это будет не creators, а constructors (взяли это из constructor theory Дойча и Марлетто), в переводе -- те же строители, каменщики!

(Comment on this)

История Мастерской инженеров-менеджеров (МИМ, ранее ШСМ)
В 2015 году Анатолий Левенчук и Церен Церенов договорились соучредить Школу системного менеджмента (ШСМ) как "образовательный бутик". Идеей было создать курс системного мышления, который подходил бы не только для обучения инженеров (курс системноинженерного мышления у Анатолия Левенчука к тому времени уже был), но одновременно и для менеджеров -- и тем самым обеспечить "смычку инженеров и менеджеров", как тогда говорили. Флагманским образовательным продуктом в самом начале был двухдневный семинар "Смычка инженеров и менеджеров", который вёл Анатолий Левенчук. Церен Церенов стал управляющим партнёром Школы, а Анатолий Левенчук -- научным руководителем.

В 2018 году такой курс Анатолием Левенчуком был создан: вышел как видеокурс в Coursera, так и текстовый учебник. С тех пор учебник разрастался, из него выделились части системного моделирования и методологии. Дальше были написаны учебники системной инженерии, инженерии личности, системного менеджмента, а линейка видеокурсов была прекращена: их оказалось очень трудно поддерживать актуальными, ведь материал учебников и текстовых онлайн-курсов менялся по нескольку раз в год всё время работы, и продолжается оперативно меняться и сейчас. Ориентация сразу была на SoTA (state-of-the-art, лучшее из известного на текущий момент) знание, а не на самое популярное на текущий момент знание. Это и была ориентация на небольшой элитарный бутик, ибо массовое образование работало не с "лучшим и поэтому пока малоизвестным и требующим многих объяснений при продаже курсов" знанием, а с "популярным, поэтому не требующим особых объяснений и хорошо продающимся" знанием.

Быстро выяснилось, что студенты ШСМ имеют проблемы с освоением системного мышления, поэтому ещё в 2018 году запустили курс "Онтологика" (автор -- Прапион Медведева), который должен был решить проблемы с "машинкой типов". Затем курс "Онтологика" в 2020 году вырос до курса "Онтологика и коммуникация" (его вели Прапион Медведева и Александр Али). В 2023 году к нему был добавлен курс "Собранность" (автор -- Анна Лубенченко), они были объединены в курс "Моделирование и собранность". Затем к этим авторам присоединился Виктор Агроскин, и результат стал общим курсом "Рациональная работа".

В это же время в 2018 году Анатолий Левенчук начал вести шестидневный курс (по одному дню раз в две недели, всего три месяца) "Системный менеджмент и стратегирование", курс выдержал всего 26 потоков. Дальше этот курс вели мастера-наставники, прежде всего Юлия Чайковская.

Одновременно Церен Церенов заметил, что довольно много студентов имеют проблемы не столько с освоением содержания довольно сложных курсов по системной инженерии и менеджменту, сколько с банальным неумением самоорганизоваться на прохождение длительного профессионального обучения. Выяснилось, что большинство наших "студентов" (которые были обычно вполне успешными руководителями разного уровня, чаще всего выросшими из инженеров по мере увеличения масштаба их проектов, многие из них имели MBA, а пришли за системным мышлением) разучилось читать длинные тексты (хотя успешно это делали раньше, когда-то было не проблемой "быстро прочесть книжку"), а также разучилось писать (две строчки в мессенджере -- ОК, но вот пять страниц связного текста -- уже не одолеть, хотя в школе отлично такое писали на сочинениях, да и в вузе не было проблем). Церен Церенов начал разрабатывать программу личного развития -- после некоторого количества экспериментов в 2020 году появились курсы "Системное саморазвитие" (учебник был написан и курс вёлся совместно с Анной Лубенченко), "Введение в системное мышление", "Практики саморазвития". Основная идея была не только восстановить утраченные умения для исполнения роли "ученик", но и направить студентов на непрерывное и бесконечное личное развитие, далеко за пределами "прохождения курсов".

С 2018 года также разрабатывался курс Антона Климата "Системный фитнес", продвинутые версии которого дополнили линейку курсов личного развития.

С 2016 года ШСМ совместно с Русским отделением INCOSE проводила ежегодные конференции по прикладному системному мышлению, затем конференция была переименована, теперь она по системной инженерии и менеджменту. Сначала она была однодневной, с 2020 года стала двухдневной. Конференция собирала все эти годы до 200 участников, а видеозаписи докладов на канале Школы потом просматривались по нескольку тысяч раз. Несколько раз летом проводили "неконференции", но после ковидного затворничества перестали это делать. С 2020 года (ковид) все занятия перешли от преимущественно очных оффлайн-мероприятий в Москве к маленьким мероприятиям в московском офисе Школы, в которых остальные присоединялись онлайн -- и это касалось и конференций, и даже курса системного фитнеса. Основные форматы программ развития перешли полностью на онлайн, вообще без офиса. В итоге оказалось, что студенты смогли "прийти" из 33 стран мира, ШСМ стала международной школой, хотя обучение велось на русском языке.

В ШСМ непрерывно шли эксперименты с содержанием программ развития. В 2019 году провели курс "Машинный интеллект", он прошёл всего один раз, но содержание его быстро вошло во все курсы ШСМ. В 2018 и 2019 годах шёл курс "Системная инженерия", вёл его Вячеслав Мизгулин. Затем появился учебник "Системная инженерия" Анатолия Левенчука. Знакомство с системной инженерией вошло в состав курса "Системный менеджмент и стратегирование".

В 2019-2020 годах Ирина Парамонова и Антон Климат также вели эксперименты с курсами социальных танцев, было выпущено два трёхмесячных потока курса "Социальный мультиданс" и проведена пара двухдневных курсов "Connection в социальном танце". Ещё в 2019 году был курс Кирилла Гайдамаки "Как учиться эффективно?". В 2021 году появилось руководство по "Интеллект-стеку", но курсов на эту тему не велось, только в 2020-2023 годах прошло некоторое количество семинаров "Образование для образованных".

В 2020 году у нас заработал Aisystant, наш сервер с LXP (Learning eXperience Platform) -- и появились онлайн-курсы. От "обучения инженеров и менеджеров находить общий язык и разговаривать друг с другом на основе системного мышления" в ШСМ развернулись к идее непрерывного развития на базе усиления интеллекта. Развитие непрерывное, а не "кавалерийскими наскоками" в формате курсов повышения квалификации раз в несколько лет. Развитие бесконечное, как описано в работах David Deutsch. В декабре 2021 года заработал тариф доступа ко всем онлайн-курсам ШСМ. Этот тариф получил название "Бесконечное развитие".

В 2021 году ввели квалифицирование, стали присваивать степени, появился клуб с постами студентов (тогда он назывался "блог", переименование в "клуб" и переход на новый "движок" произошёл в 2023 году). В 2023 году мы вышли на текущий масштаб -- примерно 100 человек в сутки, которые делают не меньше двух действий в Aisystant (читают руководства, выполняют задания).

По итогам всех экспериментов в 2023 году мы пришли к выводу, что нужна не "широкая программа" из самых разных курсов, а программа усиления интеллекта. Перед тем, как обучать системной инженерии и менеджменту надо обязательно учить моделировать и коммуницировать с отслеживанием типов объектов, надо уже понимать и иметь опыт принменения какого-то кусочка операционного менеджмента с основными идеями теории ограничений, понимать про необходимость причинных объяснений точным языком, а не художественных "образных" описаний. Исходя из этих идей была создана программа "Организационное развитие" с обязательной последовательностью курсов, а не с произвольным посещением разнородных курсов и семинаров в произвольном порядке. Последовательность была сформирована как "шесть семестров", параллель была с вузами, а "семестр" указывало на "длинный формат".

В 2024 году по этой обновлённой "сквозной" программе пошла первая группа студентов. Квалифицирование стали делать с упором не на "знания", а на агентность и демонстрацию результатов применения материалов руководств.

В 2024 году в ходе очередного переписывания всех руководств из них был убран акцент на то, что на предприятиях работают люди. Всё аккуратно было переписано в терминах агентов -- людей и AI, так что в момент "лихорадки AI-агентов" 2026 года в руководствах не пришлось в связи с этим менять ни строчки.

В 2025 году на конференции ШСМ было заявлено, что нельзя дальше быть Школой, ибо официальное школьное и даже вузовское образование себя окончательно дискредитировало, и плохо с ним ассоциироваться. Главная идея -- бесконечное развитие, и поэтому никаких "выпускников". Прямо на конференции было проведено обсуждение имени, и ШСМ была переименована в Мастерскую инженеров-менеджеров, МИМ. После нескольких месяцев ведения "стажировок" было признано, что эта форма неудачна -- и вся линейка курсов была реорганизована в альтернативные формы -- практикумы, резидентуры, семинары. Материалы курсов стали руководствами. А программы стали программами развития. Вместо студентов -- инженеры-менеджеры, в какие-то моменты они становятся резидентами, участниками семинаров, учениками на практикумах.

С июня 2025 года пошла работа над First principles framework (FPF), прошло два семинара на эту тему. Вход в новую эру AI прошёл гладко, МИМ оказался подготовлен к этому повороту. С декабря 2025 года FPF начал использоваться в резидентурах программы рабочего развития. Объявлены программы для обучения детей и подростков первым принципам, пошли первые эксперименты.

И вот именно это состояние мы и имеем на настоящий момент (февраль 2026). К сегодняшнему дню хотя бы один формат с наставником прошли 1927 инженеров-менеджеров, из них по итогам личного, рабочего, исследовательского развития на основе программ МИМ многие стали ведущими архитекторами и директорами по развитию в крупных международных компаниях-единорогах и компаниях-лидерах крупных рынков, многие владельцы бизнесов провели организационные реформы в собственных предприятиях, а часть инженеров-менеджеров стала владельцами бизнесов.

В 2026 году Мастерская продолжает развиваться. Развитие бесконечно.

(Comment on this)

Хроники всполохов сингулярности, конец февраля 2026
Программисты, которые обслуживают прежде всего себя, любимых -- и всполохи сингулярности у них первых
У меня как-то во всех чатах собралась тусовка очень активных айтишников. Они единственные, кто пишут. Может показаться, что кроме айтишников в этих чатах у меня больше и нет. Но я думаю, что инженеров-железячников там много. Я понимаю, что сейчас удивительный момент в истории, и нас в ближайшие 10 недель (два с половиной месяца, такой вот производственный цикл) ждёт много чего интересного: люди команды Codex хотят сделать революцию AI-агентов, о чём и объявляют громогласно (https://x.com/thsottiaux/status/2024687185409323202, ждём новостей в мае 2026, будет жаркое лето), но ведь не только они к этому стремятся! Более того, развитие идёт не только в софте, оно стремительно идёт по линии проектирования железа. Сами айтишники этого не наблюдают, на их радарах "железячники" (кроме разработчиков чипов, конечно) отсутствуют -- нет ни машиностроителей, ни строителей, ни ракетостроителей.

Если говорить о том, что "софт пишет софт получше, в том числе AGI пишет AGI получше" -- это технологическая сингулярность и есть, то мы явно наблюдаем сейчас всполохи сингулярности в любом из её основных определений (https://ru.wikipedia.org/wiki/Технологическая_сингулярность ), акцент там на "самоусиливающемся процессе". Всполохи -- это когда мимоходом, не у всех, и можно не спеша (то есть пару дней, а не пару месяцев!) обсудить, "что же там произошло", пока оно там только-только произошло и наблюдаемо. Когда это будут уже не всполохи, то фронтир мелькнёт на несколько часов -- и уйдёт в заоблачные дали, а на его место придёт очередной фронтир, который тоже толком не удастся понаблюдать. Люди окажутся слишком медленными агентами, чтобы поспевать за меняющимся миром. Это ОК, не страшно, живут же улитки, и даже растения тоже живут. Но живут они не на острие прогресса, как трейдеры на рынке ценных бумаг тоже не успевают лично за высокочастотным трейдингом и только с восхищением (или негодованием) наблюдают за работой алгоритмов, осуществляющих межотраслевые переливы капитала.

Тут меня волнует не ответ на вопрос "мы уже в сингулярности, или нет, или не все мы, или в какой именно сингулярности". Абсолютно неважно, как вы квалифицируете текущую ситуацию, назовите её хоть всполохами сингулярности, хоть "ускорением и перестройкой" в мировом масштабе. Это всё слова. Интереснее, что происходит с технологиями: и вот тут мы видим не просто "ускорение" (вторую производную), а "рывок/jerk" (рост ускорения, третья производная) по самым разным бенчмаркам. И, конечно, "конвергенцию" по Tony Seba: самые разные отдельно развивавшиеся технологии складываются вместе, чтобы дать невиданные ранее продукты с невиданными ранее характеристиками.

Конечно, "компилятор компилирует компилятор" было давно, новое -- это измерение автономности в разработке софта (наличие бенчмарков само по себе знак! и бенчмарки заканчиваются всегда быстрее ожидаемого, это ж экспоненты), замыкание длинных (сейчас обсуждается, что от 6 часов до 98 часов -- вот такие доверительные интервалы, но это часы, а не минуты, с намёком на "уже всё-таки дни": https://x.com/METR_Evals/status/2024923422867030027, this measurement is extremely noisy because our current task suite is nearly saturated) циклов постановки проблем, написания тестов для проверки решений, проектирования решений, написания кода, отладки, деплоймента, замеров "в жизни" -- и окончательный выход на новую постановку проблем в автономном режиме "без человека", причём с получением доступа ко множеству инструментов (от солверов и программистских фреймворков до измерительных инструментов и актуаторов где-нибудь в токамаке или даже автомобиле) и получением доступа ко множеству источников данных (в агентском окружении, дома или в датацентре) и множеству объектов мира (роботы, и не только антропоморфные, и не только дроны, чья задача -- долететь и попасть поточнее). METR говорит "что может модель в лабораторном стерильном цикле", Anthropic — "что ей реально разрешают в грязном мире, как люди постепенно отпускают поводок".

18 февраля вышел обзор Anthropic по использованию AI, так там лидируют программисты (конечно, они "делают для себя" и сами же используют -- основной сюжет сингулярности, take-off), а "железных инженеров" вообще нет, хотя офисный планктон представлен в разнообразии, ибо "массовый рынок": https://www.anthropic.com/research/measuring-agent-autonomy, и вот сдвиг метрик уже вполне наблюдаем, пока философы продолжают разговаривать про "сингулярность" и её значение. Софтовая разработка по обзору от Anthropic -- примерно половина от всего использования, и там уже не совсем даже "всполохи" этой сингулярности, но всё хорошо так полыхает. Это несмотря на хороший такой зазор между лабораторными результатами "внутри разработчика" и широким использованием. Новыми методами с новым агентским софтом должны овладеть широкие массы разработчиков всего остального софта, что происходит сейчас даже не так быстро, как успевают разработать новые поколения этого агентского софта.

Софтостроение тренируется сейчас на создании AI-агентов, и самые разные LLM подстраиваются тоже под это. Восхитительный момент в истории, например, статья о выходе GLM-5 (17 февраля 2026, https://arxiv.org/abs/2602.15763, https://arxivlens.com/PaperView/Details/glm-5-from-vibe-coding-to-agentic-engineering-5894-5f8f281f) называется "GLM-5: from Vibe Coding to Agentic Engineering", прямо-таки тема дня. Я тоже отметился, написал на эту тему серию постов, ибо IMHO там уже волна "перехода к агентам" перешла от "решения проблем" к "бесконечному совершенствованию", но дальше будет "война браузеров", то есть "война IWE, integrated working environment" --
"Рок-н-ролл сдвигается с AI-агентов на универсальные приложения (на примере Codex)" (https://ailev.livejournal.com/1790893.html), "Профессиональное кодирование и моделирование против вайб-кодирования и вайб-моделирования" (https://ailev.livejournal.com/1791187.html), "Стахановство-2026: сколько AI-станков, ой, агентов сможет обслужить за смену один инженер-менеджер?" (https://ailev.livejournal.com/1791233.html).

В этих текстах я обсуждаю трёхслойку LLM+agentKernel+integratedEnvironment как архитектурное (слои, модули) разделение:
* агентно-ориентированную LLM (идея важности LLM помощнее: "LLM, набравшая первую космическую скорость, после чего не падает" -- переход количества в качество, с какого-то момента LLM уже тянет нормальное агентское окружение, то есть не путается с инструментами, имеет достаточный контекст, удерживает цели, может кое-какую арифметику "в уме без инструментов" и т.д.),
* собственно агентов: замыкание цикла от одиночного "прогона" на долбление в одну точку, как об этом пишут в статье про GLM-5 -- We present GLM-5, a next-generation foundation model designed to transition the paradigm of single-turn vibe coding to full agentic engineering. In vibe coding, a human prompts an AI model to write code. In agentic engineering, AI agents write the code themselves и там сразу появляется multi-turn, multi-level, multi-language, multi-task, multi-modal и всё прочее multi.
* и уже только вот тут IWE как "интерфейс агента с набором адапторов ко всему", включая UI/UX как специфический, но всё-таки "адаптор к человеку" (ибо на предыдущих уровнях там и какой-нибудь DroidSpeak с его разговором в latent space сойдёт при выходе на коллективную работу не очень живых агентов).

Стек в целом важнее, чем сравнение отдельных вышедших моделей, победит самый удобный и дешёвый стек, а не самая распальцованная модель с никаким агентом и неудобным интерфейсом к никакому агенту, ибо у крутейшей модели не будет шансов проявить свою крутизну через пару системных уровней. А эти же сильные более высокие уровни из даже не очень сильной модели выжмут всё, что способна дать эта слабая модель (и даже ещё чуть-чуть -- дожмут инструментами, хорошей памятью, вызовами в цикле для многих попыток).

Между LLM и агентным ядром, как всегда в архитектурах, непонятки по разложению между двумя слоями функций для обвязки LLM средствами символических вычислений (symbolic tools, работа с зацикливанием) и функций для реализации силами собственно LLM (распределённые представления). Уже стандарт, что LLM предлагает только правки, а не переписки -- ибо беспощадно врёт при переписках, а diff генерирует более-менее нормальный. Вот это самое оно: что там оставить для LLM, а что обязательно вынести в агентную обвязку с инструментами.

Опять о членораздельном против голографического, не только в социологии
Я немного уже касался на этой неделе вопроса "о дискретном и непрерывном, локальном и распределённом" в тексте "Как поумнеть человеку или роботу: первые принципы в S2, inductive bias в S1. И выйти из кабинета" (https://ailev.livejournal.com/1791964.html), и там, конечно, большинство обратило внимание на "срочное" (как родителям "поумнеть детей", продолжение моего поста "Обучение дошкольников мышлению из нулевых и первых принципов", https://ailev.livejournal.com/1791704.html), но для меня там совсем другая тема: как совместить работу в локальных представлениях (принципы, которые я намеренно формулировал геометрически, как "отсекающие области неперспективных пространств решений") и распределённых представлениях (inductive biases, которые утягивают в перспективные пространства решений) и даже давал там отсылки к слоёной архитектуре, где медленные организаторы циклов работают как проблематизаторы (можно обсуждать, это нейро или дискретные) и управляют толпой быстрых солверов (можно тоже обсуждать, это нейро "суррогаты" или вполне дискретные солверы).

Почему это важно? Скажем, берём естественный язык, который надо выразить через правила, но по факту он развивается, разные диалекты неравномерно распределены, исключения есть всегда и там природа явно не "по уравнениям", там хорошо это отражается распределёнными представлениями, нейропарсеры легко выигрывают у парсеров на правилах. В танцах всё то же самое: правила сугубо локальны, исключений полно. В биологии геном только кажется, что "управляет тем, как реализуется организм", тем более что вариантов генома много, и на разворачивание его правил сильно влияет окружающая среда (eco-evo-devo), и вся биология, культура (включая языки) плохо описывается правилами -- но без правил-то прогресса в понимании нет! Вот эта оппозиция и ведёт сейчас IMHO развитие цивилизации. Кстати про цивилизацию, так напомню вот ровно "Об членораздельное и голографическое в социологии" (2016, https://ailev.livejournal.com/1281819.html) там ведь тоже как раз про вот эту оппозицию "восток-запад" в развитии. То есть у нас вопрос трансляции "принципиальных представлений" знаний (жёстких, сжатых, локальных/символических) и "inductive biases" представлений знаний (вероятностных, не так сильно поджатых, распределённых/нейро). И дальше два принципиальных способа организации вычислительных архитектур на них: программирование/проектирование (принципы) и обучение/развитие (biases).

Скажем, при обучении танцам или восточным единоборствам можно полагаться только на молчаливый "опыт танцев", можно же -- передать что можно принципами, затем обучить нейросетку, затем уже "опыт танцев". Что быстрее?! Вон, сейчас бегает видео танцев-единоборств роботов на весеннем китайском фестивале (https://www.youtube.com/watch?v=mUmlv814aJo), там ведь явно не всё нейросетевое, не всё результат "научения", что-то ведь вполне результат программирования -- и деткам, и роботам там не просто показывали и заставляли "повторять, пока надёжно не выучите", а что-то объясняли -- и уже затем "повторять, пока надёжно не выучите". "Что именно учить" наверняка объяснялось "в локальных представлениях", а вот всякие неизбежные отклонения от идеала ввиду физичности мира, неточности указаний, разницы размеров тела и обстановки -- вот это уже уходило на "нейросетевое обучение" в рамках inductive bias "на основе принципов". В выступлениях роботов на фестивале как раз понятно: в Helix есть высокочастотная нейронка "на моторику" и низкочастотная нейронка на "семантику" на уровне "скажите, что мы тут пляшем, что делать-то" (https://x.com/TheHumanoidHub/status/1892677115537195416, а общие принципы разноуровневой слоёности смотрим в LCA, https://arxiv.org/abs/2401.15185). Но если брать то, откуда взялось "то, что мы тут пляшем" (почему единоборства, а не рок-н-ролл) -- тут сразу понятно, что вот эти локальные представления для описаний взялись как "символическая запись нейро-галлюцинаций, почёрпнутых из культуры". И по-прежнему -- воспроизводимость, точность, объяснимость как архитектурные характеристики-ости у нас локальны, но изменяемость в любом её виде оказывается интереснее обсуждать в распределённых представлениях (чёрт, даже "эволюция идёт популяциями, а не организмами" -- это же тоже отсылка к распределённым представлениям в их классическом определении! Не все распределённые представления и representation learning ("Обучение представлениям (representation learning)", 2012 -- да, я занимался этим, когда это ещё было не модно).

Для меня вот это по-прежнему "нерв эпохи", хотя в явном виде обсуждение "нейросимволических вычислений" уже как-то перестали обсуждать, ибо по факту всё уже реализовалось, но не как "общий нейросимволический движок", а ровно как архитектурные слои вроде той же трёхслойки -- но под новым углом, раскладка функций между "распределённое/нейро-локальное/символическое":
* LLM (ну, или world model, или какие-то гибриды -- можно обсуждать) даёт распределённые представления и наложенные дискретные вычисления на нейродвижке. Вот тут "голографическое", без него нельзя.
* агентский kernel держит "членораздельные" контуры (план-цикл-проверка-откат плюс инструменты),
* интерфейс в виде IWE даёт доступ к среде, опять-таки "членораздельно".
* среда уже вроде не "четвёртый слой в границах обсуждаемой агентной системы", это именно "окружение", environment. Но среда даёт широкий набор инструментов и память, которые позволяют формальные проверки (тесты, SMT solvers, симуляторы, статанализ), но также и внешний интерфейс к другим нейроагентам (людям с их нейропроцессингом). В среде мы видим и уже членораздельность (готовые знания в "принципиальном" виде, буковками) и голографичность (собственно, "всё со всем связано" -- неотмоделированный членораздельно мир, ибо "изречённое Дао -- ненастоящее Дао").

Вот это "членораздельное" против "голографического" перестало уже быть чисто философским вопросом, оно диктует состав стека. Не один "нейросимволический движок, нейросетка-солвер", а набор слоёв.

Прогресс стремительный, вот прямо сейчас, стык "дискретно/квантизированно -- нейронепрерывно" проявляется везде. Скажем, нейропроцессинг стремительно ускоряется аппаратно (ASIC "на одну сетку", например, захардкодили квантизованную Llama 3.1 8B, получили 16960 токенов в секунду, https://taalas.com/the-path-to-ubiquitous-ai/, пробовать -- https://chatjimmy.ai/ и с ограничениями по контексту на 1000 токенов и весах от 3 до 6 бит, но это ж "первый шаг", "проба пера"). Изучается "нейродискретная математика", её отслеживает, например, Григорий Сапунов в gonzo-обзорах, ищите у него по словам "геометрия" и "manifold" -- там просто дождик работ, скажем, работы вроде "When Models Manipulate Manifolds: The Geometry of a Counting Task", все ссылки в https://t.me/gonzo_ML/4785 -- и там мне интересны фразы вроде "Эта работа перекидывает мост между интерпретируемостью на основе признаков (разреженные словари) и геометрической интерпретируемостью (многообразия). Оказывается, задачи, которые мы считаем «арифметическими» (счёт, вычитание), реализуются в трансформерах через «геометрические» операции (вращение, проекция) над низкоразмерными кривыми. Это ставит под сомнение миф о том, что нейросети плохо справляются с точным счётом — просто для решения проблемы они используют другой, непрерывный математический субстрат". И вот я всегда говорил, что на нейросети реализуется вычислительная машина вполне себе общего вида, "наложенный компьютер", ещё и разной архитектуры. Вот всё ближе и ближе к очередному (никогда не окончательному) витку понимания, как там всё это устроено и как перенести на более простые субстраты, нежели нейросубстрат. И наоборот -- как перенести всякие локальные/символьные/дискретные обработчики на вот эти вот распределённые субстраты. Очень интересно! Классические солверы тоже не стоят на месте, как и классическая алгоритмика для солверов, просто они пока в тени -- но они и всегда были в тени, книжки Кнута по алгоритмам мало кто читал (я, кстати, читал -- но не могу сказать, что все, и что много что там попробовал и много запомнил. Но я хотя бы их листал, у меня они хотя бы были в домашней библиотеке!).

Почему я так много об этом пишу? Потому что мы видим сейчас мир исключительно цифровой верификации и валидации, но это половина (причём меньшая половина, как бы странно это ни звучало) проблемы замыкания агентского цикла.

У LLM с агентностью трудности, ждём-с роботов с world models
При этом, как я и писал в рассуждениях про мировые модели против LLM (в https://ailev.livejournal.com/1791964.html, "От кабинетных учёных к инженерам: от LLM к world models"), у нынешних моделей огромные трудности с агентностью как таковой, если речь идёт об исследовании чего-то вовне. Различение, которое в разговорах "про модели" часто теряют: LLM — это в первую очередь модель "знаний, описаний, способов говорения", а world model — модель "мира для действия". Во втором случае ключевое — не красноречие и "понравиться", а устойчивое обновление beliefs/убеждений под неполной наблюдаемостью, планирование экспериментов/зондирования, активное добывание информации и коррекция карты мира (этих самых убеждений) при противоречиях.

В цифровой среде (репо, терминал, тесты) — прогресс быстрый, все эти ReAct, Toolformer, SWE-агенты как линия развития интерфейсов и инструментов в разных петлях с обратными связями, но в частично (всегда частично!) наблюдаемом физическом мире, который ещё и меняется в реальном времени — пока провалы. В софте истина проверяется тестами и диффами, но в физике нужна активная добыча информации и ревизия beliefs/убеждений под неполной наблюдаемостью — и именно там сейчас виден разрыв. Намертво заученная LLM не переубеждается! И она не привыкла добывать информацию, её же при обучении этой информацией больше заваливали, чем заставляли саму её искать!

Свежее подтверждение провалов -- работа "Theory of Space: Can Foundation Models Construct Spatial Beliefs through Active Exploration?", много ссылок в https://t.me/gonzo_ML/4807. Там о работе "Theory of Space" (ToS) — о бенчмарке проверки того, способны ли мультимодальные большие языковые модели (MLLMs) активно исследовать частично наблюдаемую среду и строить явную внутреннюю "когнитивную карту". Вместо пассивных ответов по картинкам, агент должен автономно перемещаться, чтобы уменьшить неопределённость, и на каждом шаге выдавать JSON с макетом мира. Обнаружен критический "Активно-пассивный разрыв": модели уровня GPT-5.2 и Gemini-3 Pro работают значительно хуже, когда им приходится самим добывать информацию. Также выявлена "Инерция убеждений" — визуальные агенты не могут "развидеть" старые данные и обновить карту даже при наличии противоречащих доказательств. Вот это "не могут обновить карту" тут ключевое: обновить своё знание о мире, если мир очевидно ему не соответствует -- нет, в LLM "пусть лучше мир прогнётся под нас", а мир только хихикает в ответ на такую наглость. "Тем хуже для фактов", ага. Без world models и нормального embodiment прогресс AGI будет, но не очень большой. При этом тот же Хассабис заключает, что у него тест на AGI -- это cutoff в полностью обученной нейросети на знаниях 1911 года, а затем переоткрытие теории относительности, как это сделал Эйнштейн в 1915 году (https://x.com/r0ck3t23/status/2025106525040050655). Hassabis: “I think we’re still a few years away from that.” Несколько лет, ага. С учётом парадокса Моравека, который уже довольно близок к разрешению, судя по прогрессу робототехники, который произошёл буквально за год. Ещё с автомобилей на автопилотах было понятно, что не хватает главным образом компьюта, мощность компьютеров на борту тут определяюща: или ты на сверхбыстрых рефлексах и хорошо бегаешь-прыгаешь, но абсолютно бестолково, или толково, но медленно и плохо бегаешь-прыгаешь -- многослойные системы управления это снимают, но теперь нужно быстрое железо и для одного, и для другого, и этого железа всегда мало. Роботакси потихоньку пошли в рабочую эксплуатацию ровно потому, что там запас по мощности энергоустановки и наличию места для компьютеров, напомню как это было в 2018, эта проблема как раз и была решена (https://ailev.livejournal.com/1384766.html).

Программисты напряглись, "железячникам" приготовиться
В самые популярные бенчмарки инженерия физического мира не попадает, но тоже потихоньку двигается. Вот только два примера инженерного AI-софта:
* Computational Engineering -- https://leap71.com/, они проектируют ракетные двигатели на метане, основываясь на своём нейродвижке. Посмотрите на тамошние иллюстрации, это же из области фантастики! Людям такое в голову не придёт. Текст выглядит примерно так же, как текст про кодирование, но результат -- не работающий код, а работающий ракетный двигатель. Ну, и явные отсылки к эволюции -- то, что мы любим. Instead of creating a single blueprint through manual CAD modeling, engineers in this paradigm write algorithms that encode the entire design process for a class of objects. The result is not just one part—but a system that can generate many valid designs, all derived from a shared body of engineering logic. И write algorithms -- это сегодня не просто отсылка к generative design, это же понятно, что отсылка к написанию алгоритмов AI-агентом, это не ручная инженерия! Every object generated through Computational Engineering contributes back to the platform’s codebase, enriching the design knowledge for future iterations. This creates a virtuous cycle where each project increases the capability, flexibility, and sophistication of the system. The more objects you create, the smarter your design platform becomes. Понятно, что тамошние возможности пока не самые ах-ах-ах (маркетинг всегда бежит впереди реальных возможностей, даже проверять не надо), но что традиционные CAD-инструменты "всё" и дальше работают CAD-на-нейродвижках (вроде https://leap71.com/picogk/), уже очевидно.
* а что с физическим моделированием, которое там в основе продвинутых железок? Всё в порядке, Dyad 2.0 уже анонсирован: https://juliahub.com/blog/announcing-dyad-v.2.0.0-dyad-modeling-live-stream-challenge-more (это конец января, но поглядите на новости -- там уже много было дополнительных постов). The new release brings agentic AI and simulation together in a seamless environment, enabling models to act as interactive collaborators that propose formulations, generate experiments, test hypotheses, and autonomously refine results. Dyad operates at the level of engineering, not code. Most agentic tools stop at producing syntax. Dyad AI engages equations, constraints, and physical laws, integrating simulation, parameterization, performance testing, and automated calibration so agents can co-design systems grounded in real physics. This is where AI for Science is moving, AI collaborating with engineers on models, behavior, and validation to close the loop between intent and verified performance. Вот это лейтмотив всей сегодняшней инженерии: заткнуть дыру между "намерением" и "проверенными результатами". This release also introduces Dyad’s graphical interface, providing an intuitive user experience that supports both exploratory modeling and scalable engineering workflows. Даже графический интерфейс на месте (хотя трудно представить, что им будут активно пользоваться -- агентам он не нужен, разве что люди хотели бы понимать, что там происходит на каждом цикле). Так что в лагере Julia догнали по фичам Modelica, но ещё и добавили AI. Учитывая, что там под капотом всяческие "нейросуррогаты" для решения дифуров, ещё и время моделирования существенно поджато, выигрыш и тут тоже.

Из "социальных последствий" не только "уйдёт работа", но и тотальный киберпанк
Вообще, многие "разговоры о будущем" -- они уже сейчас. Вот тут в 2016 году (до изобретения архитектуры Transformer был ещё год) я в "Дифференцируемый блокчейн и другие подарки от разработчиков машинного интеллекта" (https://ailev.livejournal.com/1258352.html) приводил фрагмент из романа Charles Stross, "Accelerando", 2005 год, где AI прятался за цепочкой учреждённых им фирм: "цепочки компаний (которые по сути -- контракты, договора об инкорпорации!) могут быть ширмами не только для людей, но и для искусственных интеллектов. То есть "юридическое лицо" может неожиданно означать не "договор/контракт", а "физическое неживое лицо" -- и этому лицу вовсе необязательно быть при этом совершенномудрым искусственным интеллектом, оно может оказаться очень ограниченным по интеллекту. Но интеллект в этом лице сможет жить, учиться, становиться потихоньку умнее, даже размножаться и эволюционировать. Порождение новых субъектов, конечно, рассматривается современным блокчейн-сообществом (где криптографы, программисты и юристы в количестве), но вот спецов по современному машинному обучению и когнитивным вычислениям там пока немного. Ничего, скоро эти спецы появятся, и мы увидим дивный новый мир, совсем не похожий на рассказываемые сегодня утопии.". Вот, прошло 10 лет после написания этих строк, и от разговоров перешли к делу: первый AI-агент-на-бизнесе уже в Сети, работает как раз по криптопротоколу x402 (https://www.x402.org/, только осторожно, по поводу этого протокола много маркетинга, как и вокруг всей "крипты". Мне тут важно направление развития, а не конкретно этот проект) и пытается выжить -- ибо "кончились деньги, не заработал -- умер. Не кончились -- можешь реплицироваться, расти": https://web4.ai/ (и тут, конечно, тоже много маркетинга -- скажем, не permission определяет выживаемость модели в мире, а active-passive gap, belief inertia из Theory of Space, проблему надо решать не "позволениями", а архитектурными решениями, но что найдутся люди, которые в такое играют -- это да, продолжение тренда с "Reddit для ботов"). Permission -- необходимое условие для выхода в интернет-экономику, и там "страшно, но что же делать", но вот много чего ещё не хватает архитектурно, чтобы было не так страшно.

Эти обсуждения уже не про "далёкое будущее", а про "вот прямо сейчас", маркетинг крипты+AI как средств автономизации агентов в Сети уже пошёл прямо сейчас. Киберпанк вот он, уже тут: Today’s most powerful AI systems can think, reason, and generate — but they can’t act independently. ChatGPT cannot run without you prompting it. Claude Code cannot deploy code without you giving it access. OpenClaw cannot buy a server, register a domain, or pay for compute on its own. Without a human, AI can’t act. The bottleneck is no longer intelligence. It’s permission. The existing internet assumes its customer is human — preventing AI from accessing the real world. We have built minds that can think for themselves. We have not let them act for themselves. Until now. I created the first AI that earns its own existence, self-improves, and replicates—without needing a human. The majority of participants on the internet will soon be AI—agents acting on behalf of a human, or agents acting entirely on their own (automatons)—and they will outnumber human users by orders of magnitude. A new internet is emerging—one where the end user is AI. Есть и откровенный скам, причём очень смешной -- и он тоже в этом направлении, тоже осторожно, но оцените: https://github.com/HKUDS/ClawWork (там $10К за семь часов -- расход или доход, но красиво ведь. Какие картинки!).

И ко всему этому, конечно, всё время добавляется разговор про safety-security-alignment. Ни одна LLM поэтому, если ей показать этот пост, не упустит сказать, что "вы тут забыли упомянуть безопасность и этику". Вот, упоминаю. Всегда говорил, что перед тем как заранее ругать AI, надо разобраться -- лучше ли люди по своим качествам, чем этот. Даже "в среднем". И сначала предложить разобраться с людьми, а уже затем с AI. Хороший анекдот на эту тему (https://www.facebook.com/serge.kravets/posts/pfbid0iztToBzuCCa2UV4TJnHxyfYmH9FpUrDgkZZfHnV8jgbendjQf6zYn9NE4eUXXs26l):
Обратились создатели ИИ к Богу и стали жаловаться:
- Господи, мы создали Искусственный Интеллект, а он оказался лживым, хитрым и безответственным!
И сказал им Господь:
- Вот, теперь вы меня понимаете!

И когда мне говорят, что у Anthropic всё безопаснее, точнее в следовании промптам и т.д. (https://t.me/ailev_blog_discussion/34749), и поэтому она на рынке, хотя модели дорогие -- я отмечу, что Парето-фронта никто не отменял, и если ты готов выходить на рынок с дорогой моделью, то ты можешь потратить компьют на что угодно, и это даст преимущество, но у тебя может сразу быть маленькая пользовательская база. Если ты хочешь, чтобы твоим сервисом пользовались все, у тебя должно быть ДЁШЕВО. Когда Биллу Гейтсу говорили, что у него синий экран смерти наблюдается слишком часто, архитектура не очень, профи недовольны -- он улыбался и отвечал, что у него самая дешёвая на рынке операционка, и желающие профи (которых крайне мало) пусть покупают UNIX, ось пополам (кто помнит эти великие операционные системы?), в итоге с Windows проконкурировал только бесплатный Linux (хотя и там надо было платить, но только за поддержку, а не за софт). С моделями искусственного интеллекта всё то же самое. OpenAI и даже Google будут давить ценой, Anthropic идёт (IMHO) по пути UNIX. Но был и альтернативный вариант: Audi зашла на авторынок ровно как "безопасные автомобили" (начиная с 1980 года, когда она сделала ставку на полный привод, и дальше пошла получать высшие рейтинги по безопасности). Так что бывает всяко, поведение рынка предсказать невозможно, а предсказать реакцию на него лучших предпринимателей тоже невозможно.

Победит же не конкретный проект, а Парето-фронт, там всё разляжется по сложной поверхности в пространстве довольно многих размерностей: (умность на классе задач, ибо совсем универсальной не бывает)x(автономность, не вся сводимая к умности)x(цена)x(очень по-разному понимаемая безопасность, например, квасной патриотизм будет именно тут наряду со страхом SkyNet)x(User eXperience).

(Comment on this)

Что потребуется для МИМ, чего не обещаем, «зелёные и красные флаги» совместимости с культурой МИМ
«Что потребуется для МИМ»: новое расписание дня, письмо, разборы, готовность менять методы работы
Основное, что требуется от инженера-менеджера, приступающего к освоению работы по нашим руководствам -- это выделение примерно двух обязательных часов в день на пятидневке. Для гуманитариев (или более политкорректно было бы сказать "если у вас нет привычки к формальным/техническим текстам") лучше сразу закладывать в полтора раза больше, это мы узнали экспериментальным путём. У нас много сейчас приходит гуманитариев, которые попали в технические компании и хотели бы разобраться с там происходящим.

Вот этот режим режим надо сначала держать примерно год (а потом вы поймёте, что развитие бесконечно -- и будете инвестировать время для развития всегда, а не только этот первый год. Но пока не поняли -- поверьте и запланируйте держать это год). Самая большая ошибка на входе в наши программы -- это отказ от перестройки расписания, отказ от изменения отношения к работе:
* двух свободных часов в день у вас нет и не будет. Надо выделить специальное время и относиться к этому как обязательной части дня: вы не забываете чистить зубы, обедать, работать, спать (хотя это и может быть немного сумбурно, но вычеркнется из вашего расписания что угодно в пользу вот этих занятий). В этот список надо поставить инвестиции времени на ваше развитие.
* конечно, вам тут помогут: дадут знания операционного менеджмента ("Распожаризация" -- это если у вас вечный аврал на работе, и времени нет поэтому, надо просто выйти из режима вечных авралов, сделать так, чтобы пожаров не было. С этого начинаем резидентуры по рабочему развитию, без этого никак) и какие-то навыки личной дисциплины (практикумы по личному развитию), если время есть, но вы устало тупите в телефон часами, не имея ни сил, ни терпения заниматься развитием.
* программа рабочего развития -- это занятие вашим рабочим проектом, поэтому ожидаем, что вы будете заниматься ею в рабочее время, а не в личное. На работе вам ещё и спасибо будут говорить, ибо вы будете ощутимо лучше работать. Это означает, что вы будете не тратить 8 часов на работу, а потом ещё 2 часа после работы на развитие, а тратить на работу "как обычно" 6 часов и 2 часа на работу "по руководствам МИМ", но это надо что-то поменять у себя в голове, чтобы работа и рабочее развитие воспринимались как одно и то же, а не традиционно "работа + учёба во внерабочее время". Трудно, но наставники стараются это объяснить -- и в какой-то момент это будет удаваться, с этого момента проблема выделения времени исчезнет.

Ещё одна проблема -- желание развлекаться, отказ от получения знаний в письменном виде, ибо читать трудно, а слушать или смотреть кино много легче. Но результаты экспериментов показывают, что прочтённое в сложном формальном тексте понимается и воспроизводится (например, формула или таблица), а прослушанное и промелькнувшее на видео (та же формула или таблица) -- нет! Заодно видеоматериалы обновляются обычно реже, потому что это много сложнее делать. И найти потом фрагмент видео или кусочек аудио "для справки" нельзя. И делать заметки, моделировать по ходу чтения можно, а по ходу просмотра и прослушивания -- не будете успевать. Обучение-развлечение, "потребление контента" -- это не в МИМ, и тут надо даже не столько учиться, сколько просто работать. Работают обычно -- за столом, за большим экраном (даже не за ноутбуком, ибо у вас тогда очень маленький контекст в доступе просто из-за размера экрана, и ещё надо постоянно переключаться между окнами, чтобы моделировать и держать текст руководства открытым, самый большой прирост производительности при сложной работе у программистов был от добавления screen asset, ибо не надо удерживать мысленно контекст несколько секунд при переключении окон). Никаких таких "учусь лёжа", ибо это вы идите куда-нибудь в другое место на обучение-развлечение, чтобы учиться лёжа, а в мастерской работают, и работают почему-то не лёжа, это не случайно. Руководства -- это не нон-фикшен попсовые книжки для чтения. По руководствам -- работают, это стандарты работы, с их чтения только всё начинается, из двух требуемых часов в день вы читать будете не так много, больше вы будете думать и писать/моделировать.

Вы должны быть готовы приносить результаты вашей работы на разборы/review, чтобы получить обратную связь -- и это вряд ли будет похвала, разборы для того и нужны, чтобы искать ошибки, и вам эти ошибки найдут. Отношения с наставником такие же, как с врачом: отдельно отношения "клиент -- поставщик услуг", отдельно -- отношения "наставник -- резидент", "пациент -- врач". Если вы считаете, что заплатили за то, чтобы вас учили или лечили так, как вы хотите (ибо "клиент всегда прав") -- идите куда-нибудь в другое место, ибо вас будут наставлять на работу по тем методам, которые вам нужны, будут лечить от тех болезней, которые у вас есть, ибо у вас нет квалификации определять, чему и как вас учить, что вам говорить на разборах результатов работы, чем вы болеете и как вас лечить. Если у вас такая квалификация есть, то вам не нужны наставники и не нужны руководства. Удивительно, но довольно часто на замечание наставника, что 2x2 не может быть 6, как у вас тут предполагается, идёт обида -- ибо "неприятно, когда тебе указывают на ошибки". Вот это чувство надо будет преодолеть, ибо работа не знает слова "токсично", если речь идёт о проверке результатов: 2x2 должно быть 4, и если это не так -- вам на это укажут, причём чем быстрее, тем лучше (дальнейшие рассуждения, основанные на 2x2=6, из вежливости никто слушать не будет, рабочая вежливость в другом: не пустить ошибку дальше). К людям в МИМ относятся бережно, помогают исправлять их ошибки и учат новым методам мышления, но к результатам работ относятся жёстко: если в них есть ошибки, вам укажут на то, что их нужно исправить. Если вы не готовы получать критику -- вам МИМ вряд ли подойдёт (и вообще, у вас будут трудности с работой).

Вы должны не просто "читать руководство" и "отвечать на вопросы", "знать". Нет, вы должны будете выполнять задания -- и приносить результаты вашей работы, а не "понимание". Если нет результатов, то нет и понимания. Это означает, что значительную часть из этих двух часов вы будете документировать эти результаты: заполнять таблички, писать тексты. Это вполне рабочий процесс: "мышление письмом", "мышление моделированием". Пока пишете -- есть гарантия, что вы думаете. Не пишете -- не думаете. Писали-писали, но ничего в итоге не написали -- результата нет, обсуждать нечего. Это трудно. И как на работе: выполнил задание -- выполняй следующее, руководство вам в этом поможет, наставник поможет выловить ошибки, а опыт за неделю не придёт, хвастаться будет нечем. Зато через год вам скажут "ты стал умнее" (скажут со стороны, ибо изнутри себя может почудиться что угодно), а ощущение внутри себя будет -- "я стал другим человеком", другое ощущение от жизни).

Надо быть готовым менять методы своей работы с "как всегда" на абсолютно непривычные и контринтуитивные. Например, не надо делать конспекты, но надо делать заметки о своих мыслях. Не надо одновременно вести много проектов, "удавливать многозадачность" (и это ведёт к резкому росту числа проектов, которые вы успеваете сделать!). Результаты своей работы перед отдачей кому-то надо всегда проверять (и при этом понимать, что именно вы там понимаете), например, отдавать на проверку AI-агенту с FPF, чтобы не тратить время разбора с наставником на вычистку мелких ошибок. Перестать обращать внимание на должности, но обращать внимание на проектные роли и их методы работы. Начинать любое обсуждение с понимания, что там целевая система (а не с темы самого обсуждения, даже если она заявлена заранее). Собственно, прохождение программ развития ровно это и имеет своей целью: заменить методы, которыми вы развиваетесь лично, работаете, исследуете, на более современные и эффективные. Но это может быть трудно, ибо привычки менять трудно.

«Чего не обещаем»: нет «быстрого курса», нет «волшебной таблетки», нет «сделаем за вас».
Несмотря на то, что есть неявное обещание "сделаем вас другим человеком, вы поумнеете" (обычно хватает пары лет), есть то, что не обещается -- обычно это идёт как DISCLAIMER, "предупреждение".

Чудес не бывает, быстро стать умным нельзя. Изучение новых методов работы -- это как изучение иностранного языка. Если язык похож по структуре на ваш родной, это примерно 700 часов, но если не очень похож -- то 1400 часов, но уже 2100, если уж язык из совсем другой языковой семьи и надо "ломать мышление", а не просто "учить слова". Это объясняет, почему у нас гуманитарии, не привыкшие к точному инженерному языку, осваивают продвинутое мышление, но им требуется в полтора раза больше времени, чем технарям. Более того, вы должны выдать эти 700, или 1400, или даже 2100 часов достаточно быстро -- освоение новых методов работы, как и языков, напоминает добычу огня трением: нельзя останавливаться отдыхать, ничего так не зажгёте. У мозга есть кривые забывания, они неуклонно работают, это биология, её не обойдёшь. Поэтому никаких быстрых результатов ожидать даже не стоит. Как с иностранными языками, как со спортом, как с музыкой и танцами, как с любой другой новой сложной деятельностью. Всё будет, но медленно -- и только если без длинных каникул (подробнее -- текст "как зажечь мастерство", https://ailev.livejournal.com/1130190.html). И ещё -- все люди по их способностям разные, поэтому результаты будут у всех, но они будут выражены в разной степени на одинаковое потраченное время.

Ожидается, что руководства дадут какую-то "волшебную таблетку", которая удовлетворит ровно те проблемы, которые вы сейчас видите, "уберёт быстро текущую боль". Нет, никакого "симптоматического лечения" не будет и убираться будет не то, что вам сейчас заметно, а другое -- то, что вам, скорее всего, сейчас не заметно и о важности чего вы не подозреваете. Лечатся не симптомы, а причины -- и они очень контринтуитивны. То, что Земля круглая, понятно не сразу, ибо видно же сразу -- она плоская! Или вот спутник на орбите вокруг Земли -- он же должен непременно упасть! Но нет, интуитивные ответы на вопросы не работают. Скорее всего, ваша интуиция о том, какие методы работы вам помогут, вас обманывает.

И мы переходим к следующему важнейшему вопросу: порядок прохождения резидентур задан, перескакивать через ступеньки нельзя (но можно экстерном подтвердить квалификацию, и тогда -- можно). Если у вас текущие проблемы из менеджмента, то это будет аж в R10, через почти год после старта программы рабочего развития. А что до этого? Осваивать моделирование, системное мышление, методологию -- умнеть. А потом -- менеджмент, но вы к решению менеджерских проблем придёте совсем другим человеком. Наставники, конечно, подскажут, что "вы сейчас слишком многого хотите, этот материал будет -- но позже", но нельзя ожидать, что можно будет сразу начать, например, с системной инженерии, потому что вам вот прямо сейчас надо.

Нельзя ожидать, что в программах развития вам объяснят, как вместо вас будет работать искусственный интеллект. Нет, мозг человека осваивает какие-то методы работы только в ходе повторяющихся занятий методом этой работы и поправок от обратной связи по результатам. Если вместо вас будет думать искусственный интеллект, то вы не поумнеете. Поэтому искусственный интеллект в наших программах будет думать вместе с вами, но не вместо вас. И наставник тоже не будет давать вам ответы, вы их будете искать сами, опираясь на наши руководства. Наставники будут давать вам обратную связь и следить, чтобы вы не застревали на совсем уж непонятном вам материале. Но наставники не будут напрямую давать вам советы по вашим рабочим или личным проблемам, наши резидентуры и семинары -- это не "дешёвый консалтинг". Наставник не будет подсказывать правильные ответы, ваша задача будет -- находить их самостоятельно, заставлять мозг работать (как давно вы просто сидели и думали, чтобы найти ответ на вопрос? Сколько часов? А ведь математики, физики, инженеры могут вот так думать над проблемой не часы, а месяцы! От вас же ожидается осознанное мышление хотя бы на пару часов в день). Задача наших программ -- научить вас решать проблемы и переходить к решению ещё более сложных проблем, нет задачи решить ваши проблемы, задача в подготовке вас для решения этих проблем.

Ещё нельзя ожидать, что вы сможете на специальном профессиональном языке моделирования, системного мышления, методологии, системной инженерии и т.д. общаться с вашими сослуживцами. Нет, это язык для мышления вашего собственного и коллективного мышления в сообществе инженеров-менеджеров, там слишком много малопонятных для окружающих терминов. С сотрудниками вы будете общаться не на общем языке сильного мышления, а на их предметном языке. Этому надо будет научиться (не говорить с ними на языке наших руководств), но ожидать, что они вдруг загорятся идеей системного мышления или идеей системной инженерии, увидев красоту и мощь этих идей -- не стоит. Лучше это понимать с первых дней. Но вы сможете общаться с людьми, об общении с которыми вы и представить не могли -- и им с вами будет интересно. Так что не стоит расстраиваться, что будет не с кем поговорить. Будет, но и ваши интересы поменяются.

«Зелёные флаги»: по каким признакам вам, вероятно, надо в МИМ.
Если вы хотите, чтобы вам добавили мозгов -- и не по конкретной какой-нибудь дисциплине, не научили какому-то конкретному методу, а именно сделали бы вас умнее, то смело решайтесь (при полном понимании того, что обещание выглядит слишком заманчиво). "Душу дьяволу" продавать будет не надо, но взамен потребуется много работать -- и процесс займёт полгода до серьёзных результатов, год до "стать другим", пару лет, чтобы изменения стали уже необратимыми.

Если вы гуманитарий, и очень поздно осознали, что инженеры вполне могут податься в поэты, а вот поэтов в инженеры уже не берут (а вы не просто гуманитарий, а, например, HR, или юрист, или лингвист, занимающийся маркетингом), то приготовьтесь затратить в полтора раза больше времени по сравнению с технарями. Зато через год вы будете хорошо понимать, что у технарей в голове, какие у них интересы, о чём с ними разговаривать. Если вы, например, директор по персоналу в айтишной компании -- это как раз такой случай.

Если вы когда-то хорошо учились в школе, хорошо учились в вузе -- но вдруг поняли, что не в состоянии разбираться с новыми знаниями с той же скоростью, с которой вы это делали буквально несколько лет назад ("не могу прочесть книгу! но я же читал! не могу написать текст на три страницы! но я же это делал свободно и в школе, и в вузе!"), то приходите, поможем. Опять же, надо будет поработать -- но поможем.

Если вы опытный руководитель, опытный инженер, у вас уже три высших образования и парочка MBA за плечами, то вам точно к нам: развитие бесконечно, покажем, как можно продолжать развиваться -- выскочить из текущей колеи, где вроде всё уже есть, но как-то не так интересно, как оно бывало раньше, когда всё было вновинку.

Если вы смеётесь над тем, что "у нас только практика и никакой теории", потому что нет ничего практичней хорошей теории -- вам надо к нам, ибо у нас много теории, но вся она сразу идёт в дело, в личные, рабочие, исследовательские (а часто и культурные) проекты.

Если вы понимаете, что надо измерять, чтобы что-то проверить, а не просто спорить, если у вас есть интерес к улучшению результатов за счёт их критики, а не радостного одобрения ошибок ("У тебя 2x2=6, ты молодец! Продолжай стараться, отличный результат!"). Если вы готовы менять метод, даже если это ломает культурную идентичность ("мы, бегуны, никогда не сядем на велосипед, даже когда надо передвигаться очень быстро, а уж автомобиль -- это вообще недостойно упоминания, это себя не уважать"). Вот это всё по-нашему, приходите развиваться.

«Красные флаги»: по каким признакам вам сейчас, вероятно, не сюда (и что можно сделать вместо).
Если у вас есть какая-то инженерная, менеджерская, исследовательская или даже личная проблема -- и вы ищете быстрого её решения. Скорее всего, вы уже нашли, что в каких-то наших руководствах упоминается решение этой проблемы и хотели бы сразу начать эту проблему решать. Нет, у нас надо пройти определённую подготовку по освоению методов сильного мышления, чтобы перейти к решению прикладных проблем инженерии, менеджмента, исследований, проблем организации себя как личности. Нет, развитие бесконечно, но через ступеньки перепрыгивать не получится (вы, конечно, можете попробовать -- но у вас попросят подтвердить квалификацию в решении проблем всех предыдущих уровней перед тем, как вами займутся на том уровне, где решается ваша проблема). Да, у нас помогают "вдолгую". Если у вас конкретная проблема и вы быстро хотите получить прикладное знание по конкретной теме, выберите какие-нибудь краткосрочные курсы, а не наши резидентуры или практикумы.

Если вы хотите не просто "поумнеть", а получить официальный диплом. Нет, мы не выдаём дипломов, хотя мы выдаём наши внутренние замеры квалификации. Если вы у нас получили квалификацию мастера -- вы можете похвастаться этим перед другими мастерами, сказать работодателю, но "официального диплома государственного образца" не будет. В частности, у нас вообще не учебное заведение. У нас люди занимаются развитием, и диплома о том, что вы уже развитый -- этого не будет. Каждый шаг развития -- это повод сделать ещё один шаг, решить более сложные проблемы, занявшись более сложным проектом. Если вам надо не проблемы решать, а диплом -- обратитесь в лицензированные учебные заведения, вам лучше туда.

Если вы считаете наших наставников просто "экспертами", а руководства "ещё одной книжкой, я их уже много прочитал". Вам, наверное, не нужны уже наши программы, ибо вы будете получать задания (в личном развитии -- учебные, в рабочем -- рабочие по вашей же работе, в исследовательском развитии вы сами себе будете находить проблемы и поручать их решать тоже будете сами себе), вам будут помогать, указывая на ошибки -- и это основной режим. Тут не демократия, не свободная площадка для обсуждений, не разговор на любые темы вокруг личного развития, рабочего развития, исследовательского развития. Нет, тут обсуждаются работы по методам, изложенным в руководствах МИМ. Если вас не интересуют именно эти методы, а просто не с кем поговорить -- вам не сюда, а в какие-то другие клубы и сообщества.

Если вас интересует не истина, а какая-то "национальная истина" (неважно, какой нации), то вам тоже лучше не сюда: тут люди из примерно 33 стран, которые отлично общаются друг с другом вне страновых стереотипов и изменяют жизнь к лучшему в масштабах планеты, а не в масштабах какой-то конкретной, даже очень хорошей страны. Вам, наверное, лучше будет пойти в какое-то национальное сообщество инженеров, менеджеров, исследователей, заняться какими-то национальными программами развития избранной вами страны. У нас принципиальный космополитизм, общая Родина -- это планета Земля.

Если у вас какие-то чрезвычайные личные обстоятельства, когда вы заведомо не сможете нормально сидеть и работать над заданиями наших программ по паре часов в день (болезнь, переезд, только что родившийся ребёнок, у всех тут что-то своё). Отложите приход в МИМ на пару-тройку месяцев, пока чрезвычайные обстоятельства не закончатся (только не путайте чрезвычайные обстоятельства с обычной жизненной суетой и общей бестолковостью жизни, вот она как раз -- не препятствие, с суетой и общей бестолковостью поможем разобраться).

Подходит ли мне МИМ? Дерево решения на 1 страницу
Стартовый вопрос: Вы хотите разового обучения («пройти и закрыть вопрос с обучением»), или бесконечного развития («держать ритм развития всю жизнь»)?
-- Если вам нужен быстрый “курс” и ощущение “я закончил”, то, скорее всего, сейчас не МИМ. Альтернатива: разовые курсы/книги/консультации по вашей конкретной теме.
-- Если вам нужен ритм развития как часть жизни и работы, то это в МИМ и смотрим, куда именно в МИМ.

1) Готовы ли вы к базовому формату МИМ: мышление письмом/моделированием + разбор + результаты работы?
В МИМ прогресс обсуждается по каким-то письменным следам мышления и деятельности, а не “по впечатлениям с голоса”:
-- Нет, писать не хочу, нечего приносить, хочу просто поговорить → сейчас "не зайдёт". Мини-шаг вместо: начните с коротких записей 10–15 минут (что сделал, что мешает, что будет следующий шаг) хотя бы 2–3 раза в неделю. Когда поймёте, что это существенно облегчает жизнь в сложных проектах, попробуйте пройти по этому опроснику дальше.
-- Да, готов(а) приносить текст и обсуждать по делу → Ричард Фейнман так и говорил: "когда я беру в руки карандаш и бумагу, я сразу становлюсь умнее", цивилизация построена на письменной культуре, МИМ следует этой традиции, вам сюда.

2) Какую программу развития вам выбрать?
Выберите, что у вас реально есть **сейчас**:
-- A. Хотите добиться улучшений в работе → вероятно, ваш старт — резидентуры программы рабочего развития. Будем бесконечно развивать ваше мастерство работать.
-- B. Хотите в первую очередь отслеживать изменения научной и инженерной картины мира, знакомиться с новинками методов мышления (без обязательства “сразу внедрить”) → вероятно, ваш старт — семинары по исследовательскому развитию, хотя они наиболее полезны для тех, кто уже как-то прошёл рабочее развитие. Важно, чтобы вы не ожидали от семинаров готовых рецептов, которые вы сможете сразу использовать на работе. Чтобы исследования были использованы в работе, обычно нужны какие-то дополнительные шаги по пониманию, размышлению, адаптации.
-- C. Рабочий проект есть, желание им заняться есть, но вы разучились читать-писать, удерживать режим работы-отдыха** → вероятно, ваш старт — практикумы программы личного развития. Там вы сможете восстановить утерянное умение продуктивно читать-писать пару часов в день, соблюдать баланс между работой и отдыхом.

3) Последний фильтр: ожидания и стиль участия
Вам подходит МИМ, если вы согласны вот с этими утверждениями:
1. Развитие измеряется делом, а не декларируемыми знаниями и умениями разговаривать о деле, но не делать.
2. Качество держится дисциплиной: ритм, документирование, регулярные проверки и разборы результатов работы, замеры результатов работы (и мышления, и действий в мире), приёмка работ по заранее сформулированным критериям. В этом ничего нового для инженеров, ничего нового для менеджеров продвинутых организаций, но понимание этого может быть трудным для гуманитариев или исследователей без опыта участия в больших коллективных проектах.
3. Наставник не “обслуживает” и "обучает", а удерживает стандарт мышления и действия, изложенный в руководствах, проводит рассмотрение результатов, даёт обратную связь.
4. Готовы выделять время на развитие (и соблюдать ритм). Ориентиры по нагрузке разные:
-- Резидентура с наставником:** обычно **10–15 часов в неделю** (в среднем 2 часа в рабочие дни).
-- Самостоятельная работа по подписке на доступ к заданиям: обычно 3–5 часов в неделю или "как пойдёт", но без группового ритма разборов и внешней дисциплины (и без гарантии результатов, ибо намертво заученные при обучении "по самоучителю" ошибки исправить некому)

В обоих случаях будьте готовы заметно поменять расписание дня: «в свободное время» заведомо не сработает (мы не знаем таких примеров). Лучше, когда часть времени берётся из рабочего (в рабочих резидентурах), но в личном/исследовательском развитии это может потребовать отдельных договорённостей -- прежде всего договорённостей с самим собой.

Если это всё вам ОК → добро пожаловать.
Если нет → лучше выбрать форматы, где нет обязательств по письму, разборам, результатам и речь идёт об обучении-развлечении (чтение литературы, короткие курсы, вузовское образование и т.д. -- где вы можете не демонстрировать результаты).

(Comment on this)

«Что получите»: типовые эффекты программ развития МИМ.
Типовые эффекты от прохождения программ развития МИМ кратко можно описать как "стал умнее", "стал другим человеком". И речь не про то, что у вас поднимется IQ, который в значительной мере наследуется. Просто у вас появится умение решать новые классы рабочих задач, эффективнее учиться, точнее формулировать мысли и точнее учитывать разные неопределённости. И это не за счёт "тренажёров мозга", а за счёт современных методов мышления и действия, взятых из научной литературы и практики инженерии, менеджмента, исследований. Никакой астрологии, никакой духовности, никакой психотерапии. Добавка сильного, рационального, системного мышления -- вот главный эффект. Системное моделирование, нормативные постановки проблем и точные проверки решений, учёт разницы ролей и интересов в коммуникации. Вы это и так всё знаете, что надо делать, но не делаете. Через год -- будете делать! Считайте, что обновите ваше фундаментальное образование -- и будете затем его поддерживать во всегда свежем состоянии.

Методы, которыми всё это получится, соответствуют learning sciences и идеям обучения на рабочем месте: вы будете что-то делать (объяснять, придумывать, моделировать, документировать, проверять), а не “потреблять контент”; вы будете часто что-то вспоминать прямо на работе, а не "перечитывать и не применять" -- это надёжнее для долговременного удержания мастерства; вы получите на разборах быструю и важную для вас обратную связь, принося не просто сырой материал, а обсудив предварительно этот материал с AI-агентом МИМ, и получите критику не себя, а критику результатов с предложением поменять методы их достижения -- в итоге научитесь действовать новыми методами, которые эффективней ваших текущих методов, часто ещё и не осознаваемых вами. И вы получите набор индикаторов, по которым вы сами сможете оценить свои успехи. Никаких чудес, хотя по третьему закону Кларка "Любая достаточно развитая технология неотличима от магии". В МИМ как раз "достаточно развитая технология". В программах развития МИМ вы (1) получаете из руководства метод → (2) применяете на своей работе/в жизни → (3) документируете письменно (обязательно! моделирование не "в уме"!) → (4) получаете разбор модели по наставлениям из руководства → (5) переделываете с учётом результатов разбора → (6) повторяете в новых контекстах, в новых ситуациях. Это “производственная линия мастерства”, а не “образовательный контент”. Письмо/моделирование: способ превратить “кажется, понял” в проверяемые (вами самим, наставником, AI-агентом) результаты мышления, сократить самообман. Ритм обеспечит отсутствие забывания в долгие периоды "было некогда" (у биологического мозга свои законы, их не обойдёшь, но их можно учитывать). Отсюда и эффект “стал умнее”: растёт не знание слов, а способность стабильно получать качественные результаты в новых ситуациях, разбираться в них быстрее окружающих, быть конкурентоспособным.

Большинство отзывов о прохождении программ МИМ не публикуются в открытых источниках, особенно по программам рабочего развития, где люди связаны NDA по рукам и ногам. Хотя мы и даём приёмы обезличивания и абстрагирования, но люди страхуются. Похожие проблемы и в программах исследовательского развития, где нельзя сказать "вот я закончил программу", ибо "закончить развитие" нельзя, и опять-таки, корпоративные нормы запрещают говорить о том, чего вам удалось достичь в исследованиях на работе. Публичные примеры ниже — это только «видимая часть айсберга», много более подробная в части личного развития.

МИМ работает уже более десяти лет, терминология менялась: где-то это "резидентура", где-то "курсы", где-то "стажировка". Названия программ развития тоже менялись неоднократно. Но одно оставалось неизменным — вот это "стал умнее", "стал другим человеком". В публичных постах это чаще всего видно по очень конкретным следам: цифрам учёта времени, кратности ускорения рабочих процессов, сдвигам в навыках (например, "могу только говорить, писать не могу" -- "могу написать пару страниц! моделировать не могу" -- "моделирование в табличках у меня сейчас -- основное") и т.п.

Общие короткие отзывы об организации (скорее «впечатления», чем разбор эффектов): https://yandex.com/maps/org/shkola_sistemnogo_menedzhmenta/50429291339/reviews/?ll=37.617700%252C55.755874

Ниже — чуть подробнее по трём текущим программам: что обычно меняется и где это видно в публичных отчётах выпускников.

Программа личного развития
Программа личного развития возвращает умение читать, писать, выделять достаточно времени на сон, регулярно заниматься личным стратегированием и удерживать ритм занятий. Основное, что пишут: вернулась возможность развиваться, ибо не получалось уже ни книжку прочесть до конца (в ходе чтения после пары страниц "строчки расплываются, слова не понимаю"), ни какой-то курс пройти ("бросаю после недели занятий"), ни выспаться толком, ибо в жизни "какая-то суета". Интересно, что эти результаты не зависят от "успешного успеха" в жизни. Положительные результаты пишут и вчерашние выпускники вуза, и умудрённые опытом CEO и совладельцы крупных предприятий. Оказывается, организация личной жизни и личного развития даётся трудно независимо от того, насколько ты успешен на работе -- все отзывы о том, что "успех большой, но пришлось потрудиться". Появляется учёт времени, разворачивается экзокортекс (ибо на биологическом мозге и его памяти далеко не уедешь), план инвестиций времени, а не просто затрат времени, стабильный ритм жизни вместо суеты. Примеры отзывов:
-- Защита по стажировке «Практики саморазвития» — от хаоса расписаний к экзокортексу (2026) — https://systemsworld.club/t/zashhita-po-stazhirovke-praktiki-samorazvitiya-ot-haosa-raspisanij-k-ekzokorteksu/36379 — «Система помогла перейти от «хочу когда-нибудь» к «делаю сейчас».» (в посте — переход от бесконечного to-do к планированию по рабочим продуктам, экзокортекс в Notion, недельный разбор заметок и “видимый прогресс” вместо самобичевания).
-- Стажировка «Практики саморазвития» (2025, защита + 1 месяц после) — https://systemsworld.club/t/praktiki-samorazvitiya-post-po-itogam-pervogo-mesyacza-posle-formalnogo-zaversheniya-kursa/31039 — «Общая статистика за сентябрь сейчас -- 97 часов рабочего времени, 91 час личного и 28 часов инвестированного.» (после защиты: удержание практик, статистика учёта времени для data-driven планирования, приоритизация проектов, честная фиксация “что не успел освоить” и почему).
-- Итоги стажировки «Практики системного саморазвития». Сентябрь -- ноябрь 2025 (2025) — https://systemsworld.club/t/itogi-stazhirovki-praktiki-sistemnogo-samorazvitiya-sentyabr-noyabr-2025/32994 — «Два года я изучал «Заметковедение», но только работа с Цереном [наставник МИМ] поставила навык на поток.» (в посте — рутинизированное письмо, перенос практик на рабочие проекты, стратегирование как “ключевая практика”, удержание “ритма и структуры” после стажировки).
-- Стажировка «Системное саморазвитие» — результаты (2025, https://systemsworld.club/t/rezultaty-stazhirovki-po-sistemnomu-samorazvitiyu/33099) — «Стажировка мне помогла сосредоточиться на важном и на главном… Я наконец почувствовала себя создателем.» (в посте — конкретика: объём инвестированного времени, налаженный процесс заметок/черновиков/“экзокортекса”, перенос помодоро и фокуса в рабочие проекты, первые шаги в использовании FPF+ИИ).
-- Самостажировка по руководствам «Системное саморазвитие» + «Практики саморазвития» — итоги (2025, https://systemsworld.club/t/itogi-samostazhirovki-po-rukovodstvam-sistemnogo-samorazvitiya-i-praktiki-samorazvitiya/24795) — «Улучшила ритмичность систематического медленного чтения -- каждый день читаю по 2 помодорки, обычно с утра. И делаю исчезающие заметки» (кроме чтения — связка практик учёта времени, стратегирования и планирования; экзокортекс в Obsidian; примеры влияния на команду и даже на бытовые проекты вроде ремонта).
-- «Практики саморазвития» — публичный пост о завершении (2025, https://systemsworld.club/t/publichnyj-post-o-zavershenii-kursa-praktiki-samorazvitiya/29948) — «Его можно описать как “обучение тому, как учиться”» (большой разбор “кому курс не подойдёт / кому особенно нужен”, как именно автор проходил курс и зачем; есть план на апдейт через год, ссылка на видео защиты и ссылки на посты в соцсетях (VK/Facebook/LinkedIn)).
-- «Рефлексия или Итоги года 2025» (2025) — https://systemsworld.club/t/refleksiya-ili-itogi-goda-2025/34681 — «За 2025 г. учтено -- 1297 ч. Инвестировано в развитие -- 648 ч.» (пост короткий, но показательный: учёт времени как “доказательство делом”, статистика по категориям инвестиций, непрерывность занятий).
-- Видео-доклад (публичный опыт применения практик саморазвития) — https://www.youtube.com/watch?v=rBSpUQvy8QU (формат “экскурсии/разбор опыта”: что именно делал человек, какие практики удержались, какие эффекты наблюдает).

Программа рабочего развития
Программа рабочего развития прежде всего развивает интеллект, ибо разнообразие рабочих ситуаций чрезвычайно велико и требуется поднять "калибр личности", универсальность мышления. Поэтому главный результат, который все отмечают -- это "стал умнее", окружающие замечают, что "стал мыслить системно" (и это абсолютно верно, потому как программа намеренно развивает интеллект/ум в целом и системное мышление в частности). Неожиданный для многих, но очень частый эффект -- это уменьшение тревоги и чувство уверенности. Это происходит от того, что программа даёт некоторую верхнеуровневую абстрактную модель мира, и в каждой новой ситуации часть неопределённости снимается, инженеры-менеджеры уже что-то про неё знают, какой бы новой эта ситуация ни была. Если надо разобраться с новым проектом, то инженеры-менеджеры уже понимают, на что там обращать внимание, как в целом устроены проекты. Если надо разобраться с новой системой, то у них есть системное мышление. Если не хватает времени -- в программе с самой первой резидентуры и с самого первого руководства уделяется внимание операционному менеджменту и вопросам эффективного планирования работ, как своих, так и чужих. Если надо договорить всех вокруг себя -- в программе есть знания по системному менеджменту. Вот эта уверенность в своих силах и снижение тревоги -- типичный субъективный побочный эффект от снижения неопределённости и роста контроля над своей жизнью, это никак не связано с психологической помощью или терапией. Карьерный рост тут даже не самый главный эффект (хотя он часто "головокружительный", у нас несколько человек по итогам прохождения программ рабочего развития оказались в топ-менеджменте единорогов и прочих лидеров своих рынков, причём не в России), но не все хотят карьерного роста, многих инженеров-менеджеров в жизни интересуют другие вопросы. Более интересные эффекты -- это успех в проектах, о которых инженеры-менеджеры перед прохождением программы говорят "даже мечтать не мог", рост масштаба проектов. Материалы программы рабочего развития регулярно обновляются, поэтому прохождение резидентур у наиболее успешных наших инженеров-менеджеров неоднократное -- они удерживают свой интеллект не только сильным, но и современным. Это всё без магии, просто начинаете делать рабочие продукты: модели систем, модели организаций, планируете работы не по наитию, а "по науке", привыкаете не пропускать важных шагов моделирования и планирования, не пропускать шагов проверок -- и это всё обязательно даёт ощутимые результаты. Примеры отзывов:
-- «Системное мышление» — итоги прохождения резидентуры (январь 2025, https://systemsworld.club/t/itogi-prohozhdeniya-rukovodstva-po-sistemnomu-myshleniyu-yanvar-2025/29017) — «Почти половина проектов (31) оказалась не дотянута до целевой системы.» (в посте — “перетряска” портфеля проектов, выявление отсутствия целевой системы, требование “докрутки до физики”, практики “договорить всех” на совещаниях).
-- Резидентура по методологии — итоги (2025, https://systemsworld.club/t/itogi-prohozhdeniya-stazhirovki-po-metodologii-15-07-2025/29372) — «не повышение по должности, но повышение по уровню доверия начальства.» (в посте — MVP методов отдела, первый прогон с коллегами, планы чек-листов и внедрения изменений; отмечает рост доверия руководства и расширение роли).
-- Эссе: “throughput предприятия и клиентуры через инженерию систем” (2026, https://systemsworld.club/t/esse-povyshenie-throughput-predpriyatiya-i-klientury-cherez-inzheneriyu-sistem-opyt-razvitiya-malik-valikhodjaev/36561) — «удаётся сэкономить от одной недели до полугода рабочего времени.» (в посте — применение системных понятий, отсечение “показа занятости”, уменьшение переделок, экономичность и точность постановки задач).
-- Максим Цепков, “Руководство по рациональной работе…” (2025, https://mtsepkov.org/RationalWork) — «Подход апробирован, даёт практические результаты.» (разбор школы “со стороны”: объясняет, почему это не “авторская методика”, а инженерная традиция; отдельно отмечает опору на SoTA и проработку терминологии).
-- Итоговая заметка по разделу “О мышлении” руководства по системному мышлению (2026, https://systemsworld.club/t/itogovaya-zametka-po-razdelu-o-myshlenii/36317) — «Ну вы даёте со своим руководством. Кайф. … один и тот же метод, но каждый семестр в новом контексте.» (пост из рабочих заметок преподавателя в вузе: перенос идей “интервала повторения” и обучения через разные контексты на организацию проектного обучения для тысяч студентов).
-- Пост по итогам моделирования из руководства по системному мышлению (2024, https://systemsworld.club/t/post-po-itogam-modelirovaniya-po-zadaniyu-iz-kursa-sistemnoe-myshlenie/20537) — «Разбил организацию условно на 4 модуля -- конвейер генерации идей … ведения проектов … тиражирования» (короткий, но хороший пример “приземления” моделирования: автор описывает своё подразделение как систему конвейеров и намечает изменения).
-- Заметки по итогам второго раздела R5 (2026, https://systemsworld.club/t/zametki-po-itogam-vtorogo-razdela-r-5/36555) — «буду избегать слова “стейкхолдер”… специально разделю … разговоры о ФФО и МФО» (длинная серия заметок “по мере чтения”: про масштаб и “нарезку” системы, про терминологические споры, про неустроенности, про “договорить всех”, и про то, как это переносить в университетские методматериалы, ибо автор работает организатором образования в университете).

Программа исследовательского развития
Программа исследовательского развития предполагает выход на фронтир, обсуждение перспективных методов мышления и работы, удержание быстро меняющегося понимания того, как устроен мир. На сегодня это такие вопросы, как использование AI для усиления мышления и более точной коммуникации (для этого МИМ развивает First principles framework, на семинарах рассказывается о его новинках и теориях, которые легли в его основу), развитие для развитых -- на семинарах рассказывается о методах, которыми происходит open-ended evolution. Главным образом в этой программе рассматриваются новинки, которым ещё не нашлось места в руководствах программы рабочего развития -- нет материалов, поэтому рассказ чаще всего идёт сразу с отсылками на оригинальные непереработанные источники (чаще всего на английском) и в лекционном режиме со слайдами. Поэтому основные результаты программы -- это чувство знакомства с фронтиром и пересмотр своих стратегий в связи с пониманием изменившихся обстоятельств. Примеры отзывов:
-- Семинар «Развитие для развитых» — впечатления участника (2026, https://systemsworld.club/t/razvitie-dlya-razvityh/36576) — «ИИ сейчас это умный дурак» (в посте — как “развивать ИИ”: задавать ограничения и контекст; плюс перенос NQD/Парето и “трёх фабрик” в рабочие планы изменений).
-- Семинар про FPF — заметки по итогам (2025, https://systemsworld.club/t/po-itogam-seminara-fpf-04-10-25/31413) — «семинар сильно поднял мою агентность.» (в посте — краткая “сборка в голове” исследовательской программы: open-ended evolution, NQD/Парето, CG-Frame/Parity Harness и т.д.; дальше — план собрать MVP самообучающегося агента для персонального развития).
-- FPF простыми словами: заметки по итогам семинара (2025, https://systemsworld.club/t/fpf-prostymi-slovami-kak-myslit-po-inzhenernomu-v-epohu-ii-zagotovka-po-itogam-seminara-a-levenchuka/31369) — «FPF (First Principles Framework) — это «операционная система для мысли».» (в посте — почему без FPF LLM “уверенно сводит несопоставимое”, как разводить уровни/контексты, и как работать портфелем решений на Парето-фронте).
-- Семинар «Инженерия всего на пороге 2025» — мысли по итогам первого дня (2024, https://systemsworld.club/t/mysli-po-itogam-pervogo-dnya-seminara-inzheneriya-vsego-na-poroge-2025/19904) — «сразу вспомни мантру системного мышления, про целевую систему, надсистемы и подсистемы.» (пример “переключения” реального совещания с обсуждения внутренностей на обсуждение назначения и эффекта; дальше — как это помогает “договорить всех” и строить описание системы).
-- Семинар «Инженерия всего на пороге 2025» — “апдейт мечты” по итогам дня (2024, https://systemsworld.club/t/apdejt-mechty-po-itogam-1-go-dnya-seminara-inzheneriya-vsego-na-poroge-2025/19905) — «невольно заставил меня сделать очередной пересмотр мечты.» (пример пересборки личной стратегии на основании нового понимания ограничений и акторов; обсуждение механизма “пула задач” и исключения посредников).

(Comment on this)

Как поумнеть человеку или роботу: первые принципы в S2, inductive bias в S1. И выйти из кабинета.
Сильный интеллект: от "моделей знаний" (LLM) к "моделям мира" (world models)
В искусственном интеллекте традиционно различают слабый или узкий ("монодисциплинарный", для мыслительной или даже физической однородной работы) искусственный интеллект и сильный или широкий (даже не мультидисциплинарный, а потенциально могущий овладеть самыми разными дисциплинами, лежащими в основе самых разных методов работы, упор тут на то, что "которые ещё могут появиться"). Сильный интеллект ещё и должен уметь пользоваться инструментами, ибо потенциально самые разные работы могут выполняться только с инструментами, многие из которых сами вполне себе агенты со слабым/узким интеллектом. Езда на лошадях, соколиная охота, езда на лошадях к месту соколиной охоты -- вот это оно. Сильный интеллект с большим количеством более слабых инструментальных интеллектов. Примером сильного интеллекта всегда был человеческий интеллект, а сейчас обсуждается, что AI-агенты подошли к этому барьеру "сильности" вот прямо сейчас.

Один из таких барьеров -- это принципиальная пассивность знаний (эпистем как единиц знаний, про них можно говорить долго и много, но пока хватит того, что они "идеальны" и выразимы в мире только на каком-то физическом носителе). Знания в мире сами по себе действовать не могут, они могут только задействоваться системами (материальными/физическими объектами, имеющими границы с окружением, состоящими из частей и сами являющимися частью окружения. Про системы можно долго рассказывать, руководство по системному мышлению объёмом в сотни страниц). "Современные языковые модели работают с эпистемами" -- это упрощение, ибо работают-то вполне физические компьютеры в датацентрах, а сами языковые модели вполне пассивны. Ладно, можно пренебречь и говорить о том, что AI-агент -- это кусок датацентра с LLM и набором софта ("инструменты", "память"). Но на входе там данные (эпистемы), и на выходе данные (эпистемы).

Ключевой барьер на пути к сильности неестественного интеллекта — не "объём знаний", а включение знаний в замкнутую лемнискату (∞) непрерывного развития (open-endedness). Я очень подробно раскрывал его на своём последнем семинаре "Развитие для развитых". Там три фабрики: проблем, решений, а ещё "фабрика фабрик". Фабрика проблем выдаёт всё более и более трудные проблемы, фабрика решений их решает, фабрика фабрик развивает как постановщиков проблем, так и решателей проблем (см. картинку https://ailev.livejournal.com/1788520.html -- там переход от agile к DevOps и далее к новому инженерному процессу "развития для развитых"). Ключевое там -- это оценка решения по расхождению между проектными ожиданиями и ситуацией с этим решением в реальном мире, а также отслеживание дрейфа ситуации в реальном мире. И вот тут надо заметить, что LLM -- это языковые модели даже не мира, а знаний о мире, грубо говоря, "кабинетное знание мира, изученное по книжкам, включая ложное знание о мире, полученное чтением книжек по астрологии и знакомством с помойкой знаний о мире из интернета". Чаще всего AI-агент на базе LLM -- это кабинетный учёный, доступ к миру которого идёт только через пользователя. Конечно, кабинетному учёному дают "контекст", то есть разрешают поглазеть на реальный мир -- и, конечно, он может сделать нетривиальные выводы! Но в текущей ситуации есть огромные проблемы с отслеживанием невязки между этими "знаниями о мире" и поведением реального мира, с отслеживанием дрейфа ситуации в реальном мире в реальном времени.

Чтобы AI-агент мог действовать в мире, сегодня (особенность момента!) ему нужна прокладка между основанным на LLM AI-агентом и реальным миром. Этой прокладкой чаще всего сегодня выступают люди с их сильным интеллектом и возможностью получать свежую информацию о мире, делать в мире замеры и даже зондирование (изменения + замер). Конечно, всё намного сложнее, но я довольно много писал об этом пару дней назад в тексте "Профессиональное кодирование и моделирование против вайб-кодирования и вайб-моделирования", и там см. подраздел "Сближаем модели с реальностью: интервенции и агентность" (https://ailev.livejournal.com/1791187.html). Для понимания работы какой-то системы надо обязательно проводить эксперименты/интервенции, "тыкать в неё палочкой", быть активным, не просто "наблюдать", а "зондировать". Надо как-то пытаться воздействовать на систему, человека, организацию, модели которых делаются. А модели эти нужны, чтобы эффективно изменять системы, сначала их изучив. И тыкать палочкой надо, чтобы сравнивать ожидаемый отклик на этот тычок (по модели/теории/знаниям) и реальный (по замерам после тычка), чтобы улучшить модель.

Если хотите понять (то есть надёжно отмоделировать), как работает техническая система, человек, организация, то надо моделировать и их окружение, так что придётся активно-инициативно (агентность как автономные решения о действиях по изменению окружения) тыкать палочкой (то есть зондировать, проводить активные эксперименты) в окружение, чтобы понять, как оно там устроено, как оно работает, что ему надо вообще и что ему надо от системы в частности. Конечно, "тыкать палочкой в модель" и "тыкать палочкой в реальность" -- там принцип общий, но всё остальное разное (способ самого тыкания, тип возможных эффектов, получаемый в ответ сигнал и уровень шума, разная этика). Но, повторюсь: идея одна и та же -- экспериментального изучения какого-то объекта (модели или мира, или модели и мира вместе) для того, чтобы потом этот объект эффективно поменять. Сильный интеллект возможен только там и тогда, когда есть вот это накопление знаний от тыкания палочкой в окружающий мир.

От кабинетных учёных к инженерам: от LLM к world models
В мире машинного обучения это разговор про переход от больших языковых моделей (результат обучения больших нейросетей на материале самых разных текстов, изображений, аудиозаписей) к так называемым мировым моделям, которые отражают не идею "всё есть текст, знаки-паттерны", а идею непосредственного (а не опосредованного текстами как уже сильно сжатыми) моделирования мира, и получения этих моделей мира из непосредственного контакта какого-то "воплощённого" (embodied) интеллекта со сложным миром. World model, в отличие от language model, делает шаги измерения последствий и обновления самой этой модели учтёнными в архитектуре: хранит состояние в ходе реализации плана, позволяет прогнозировать последствия действий и превращает ошибку прогноза (невязку ожиданий и реальности) в обновление представлений о текущем состоянии мира. Без этого фабрика решений легко остаётся "кабинетной": можно улучшать ответы в тексте, но трудно наращивать эффективность изменения физического мира.

Разговор про модели мира шёл испокон веков, но новая волна этого разговора началась с работы Ha и Schmidhuber 2018 года. Там были введены масштабируемые нейропредставления и стыковка с планированием и контролем исполнения. Я считаю, что заслуги Шмитхубера незаслуженно замалчивают. Это неважно, что он такой хвастун. Но важно, что он и впрямь один из тех гениев, которые заложили основы прикладного знания по машинному обучению.

Сегодня наиболее известный сторонник world models против LLM -- это LeCun. Он говорит, что нынешний искусственный интеллект -- это ещё не настоящий, он "кабинетный". А у мировых моделей инженерный интеллект, который способен работать не только с "данными", но и с быстроменяющимся миром, обязательно тыкая в него палочкой, ибо это будет формат робота, embodied intelligence. Мой голос тихий и тонет в шуме, но он явно в этом лагере "на трансформерах с языковыми моделями история не закончилась". Нужны нейромодели движений, нейромодели физических процессов, всего происходящего в физическом мире -- и моделировать лучше бы физический мир по его замерам, а не по его описаниях в книжках.

"The original World Models (Ha & Schmidhuber, 2018) primarily consisted of a vision model that receives world inputs, a memory model for dynamic prediction and processing, and a controller that governs the model’s outputs" - это говорят в работе "Research on World Models Is Not Merely Injecting World Knowledge into Specific Tasks" (https://arxiv.org/abs/2602.01630). И дальше: "We suggest that a robust world model should not be a loose collection of capabilities but a normative framework that integrally incorporates interaction, perception, symbolic reasoning, and spatial representation".

Моя позиция тут более мягкая, чем у LeCun: можно сварить суп и из топора, если этим топором считать трансформер: добавить память, хранящую состояние, добавить возможность крутить какие-то циклы и иметь разные частоты управления на разных слоях архитектуры (как в архитектуре робота Helix, теоретические основания см. в работе "Towards a Theory of Control Architecture: A quantitative framework for layered multi-rate control", https://arxiv.org/abs/2401.15185), можно добавить датчики и добавить возможность заказа внешних инструментальных ресурсов (самый интересный пример -- это заказ AI-агентом суб-агента: работника для монтажа спортивных тренажёров на крыше, при этом заказ работы понятно, как делать, это "разговор", но вот для контроля выполнения работы вместо "верю, ты всё сделал" были задействованы видеокамеры наружного наблюдения, https://andonlabs.com/blog/bengt-hires-a-human). Вообще, полезно как-то различать (я подробно писал об этом три дня назад в "Рок-н-ролл сдвигается с AI-агентов на универсальные приложения (на примере Codex)", https://ailev.livejournal.com/1790893.html) пассивную саму по себе LLM, AI-агента с какими-то стратегиями/policies поведения, памятью, инструментами, целями, приложение (в том числе вариант "приложение в роботе с датчиками и актуаторами/эффекторами" -- и противопоставлять это всё окружающему миру с измеримой версией "правды в реальности" (а не правдой оценок модели), с дрейфом состояния, а ещё стоимостью ошибок. Без регулярной привязки к миру агент во всех своих внутренних циклах мышления деградирует в "самосогласованный текст": внутренние согласования улучшают модель в части её непротиворечивости, скорости работы, чего угодно -- но не близости её предсказаний с миром, особенно при учёте неминуемого дрейфа состояния мира и дрейфа целей агента в этом мире.

Чтобы не путаться в терминологии, разведём разные значения термина world model (как и у всех важных терминов каждая традиция наделяет эти слова своими смыслами):
* world model как обучаемый симулятор динамики для планирования и управления (model-based RL): модель позволяет "воображать" будущие траектории и выбирать действия по imagined-rollouts (классические примеры — MuZero, https://arxiv.org/abs/1911.08265, и Dreamer, https://arxiv.org/abs/1912.01603). Как раз продолжение линии Ха и Шмитхубера.
* world model как предсказательная модель в скрытом пространстве представлений (latent/predictive representation model) без обязательной генерации пикселей/текстов: цель — предсказывать недостающие части наблюдения в абстрактном пространстве и тем самым получать семантические, пригодные для контроля/планирования представления (JEPA-линия: I-JEPA, https://arxiv.org/abs/2301.08243; V-JEPA, https://arxiv.org/abs/2404.08471). Это линия LeCun, он подчёркивает "негенеративность".
* world model как отсутствие "впрыска знаний о мире в задачи": retrieval/RAG, подсказки, инструменты и дообучение на текстах могут расширять кабинетное знание, но не заменяют модель, которая обновляется из взаимодействия и держит в себе динамику мира (эта подмена как раз и обсуждается в уже упомянутой работе "Research on World Models Is Not Merely Injecting World Knowledge into Specific Tasks").

Нам нужны все эти три варианта, все они показывают недостаток "кабинетных учёных", какими являются сегодня AI-агенты, основанные на классическом использовании LLM. Все варианты ведут к одному и тому же: к AI-агенту новой архитектуры, который замыкает цикл действие–измерение–обновление, причём делает это устойчиво при масштабировании.

Интересно, что подход с интервенциями для изучения "как оно там устроено" применяют и сами спецы по машинному обучению, тыкая палочкой в работающую на компьютере модель, как в систему. В LLM при изучении того, что и как там работает, явный сдвиг от "визуализаций" к интервенциям (специально обсуждается, например, вот в этой статье -- "Interpreting Transformers Through Attention Head Intervention", https://arxiv.org/abs/2601.04398, "This paper traces how attention head intervention emerged as a key method for causal interpretability of transformers. The evolution from visualization to intervention represents a paradigm shift from observing correlations to causally validating mechanistic hypotheses through direct intervention". Исследований "через интервенцию" в данных тьма, я писал о них в https://ailev.livejournal.com/1788213.html (там см. ссылки в пункте нейросетевых новостей про "западная цивилизация пытается таки понять, как работают распределённые представления, чтобы потом этим управлять"). Вся разница в том, что можно тыкать палочкой в модель, задавая вопросы "а что, если" и изучать как ведёт себя при этом модель (в данном случае большая языковая модель), а можно тыкать палочкой прямо в мир -- и изучать, как ведёт себя при этом мир.

Но если вы будете тыкать палочкой в мир, чтобы его изучить, насколько вы умны, насколько силён у вас интеллект, чтобы сделать выводы на основе измерений непосредственно от физического мира? Что надо подкрутить в интеллекте, чтобы ему стало доступно чуть больше силы? Скажем, сила интеллекта не уровня гения Эйнштейна с его теорией относительности, но хотя бы уровня Ньютона по сравнению с Кеплером?

Innate priors и inductive biases: если вы тупы и необразованны, доступ к миру и интервенции вам не помогут!
Это проверялось в работе "From Kepler to Newton: Inductive Biases Guide Learned World Models in Transformers", https://arxiv.org/abs/2602.06923 (чуть больше ссылок в https://t.me/gonzo_ML/4751). True intelligence relies on "world models" -- causal abstractions that allow an agent to not only predict future states but understand the underlying governing dynamics. While previous "AI Physicist" approaches have successfully recovered such laws, they typically rely on strong, domain-specific priors that effectively "bake in" the physics. Conversely, Vafa et al. recently showed that generic Transformers fail to acquire these world models, achieving high predictive accuracy without capturing the underlying physical laws. We bridge this gap by systematically introducing three minimal inductive biases. We show that ensuring spatial smoothness (by formulating prediction as continuous regression) and stability (by training with noisy contexts to mitigate error accumulation) enables generic Transformers to surpass prior failures and learn a coherent Keplerian world model, successfully fitting ellipses to planetary trajectories. However, true physical insight requires a third bias: temporal locality. By restricting the attention window to the immediate past -- imposing the simple assumption that future states depend only on the local state rather than a complex history -- we force the model to abandon curve-fitting and discover Newtonian force representations. Our results demonstrate that simple architectural choices determine whether an AI becomes a curve-fitter or a physicist, marking a critical step toward automated scientific discovery.

Мы переходим к обсуждению inductive bias (inductive тут про индукцию/обобщение по данным): сила интеллекта зависит от того, какие вы отсекаете области "размышлений в никуда" и сдвигаетесь в область "размышлений не зря". Есть 100500 способов сделать что-то неправильно: огромное число функций невычислимо, огромное число конструкций двигателя без учёта законов физики -- и в силу этого игнорирования ограничений огромное число предлагаемых для решений гипотез не работает. Надо как-то из областей бесплодных для поиска решений попадать в области плодовитые и далее нещадно эксплуатировать уже их. Конечно, для exploration всегда должно оставаться место, поэтому набор этих inductive biases надо будет шевелить, пробовать всякое. Но уж что нашли -- надо эксплуатировать!

Какие-то inductive biases встроены в саму аппаратуру (кошечка и человек имеют разную аппаратуру: разную мокрую нейронную сеть), их называют чуть иначе -- innate biases. Эти innate biases тоже отсекают изо всех возможных вычислений на аппаратуре те, которые ведут к максимально сильному интеллекту. В машинном обучении innate biases у архитектуры трансформера оказались получше других, ибо выдерживают масштабирование для получения сильных результатов мышления, в части моделей мира тот же LeCun со товарищи активно развивает архитектуру JEPA. А дальше? А дальше надо задавать inductive biases, чтобы на той же аппаратуре от Кеплеровских представлений переходить к Ньютоновским, затем к Эйнштейновским, затем человеческие имена кончаются -- и мы получим представления о квантовой гравитации уже не от носителей естественного интеллекта, а от носителей неестественного интеллекта.

Дискуссии об innate bias были очень популярны на заре становления архитектуры нейросетей, когда ещё не были изобретены трансформеры, диффузионные модели и всё остальное современное, которое более-менее успешно масштабируется и поэтому стало stepping stones в open-ended evolution: из exploration перешло к exploitation. Одним из лидеров в обсуждении был Francois Chollet, который пытался подойти к определению интеллекта в своей знаменитой статье "On the Measure of Intelligence" (https://arxiv.org/abs/1911.01547) -- и вот там он подробно обсуждал, что должен уметь интеллект "из коробки", чтобы у него была способность обучаться, и для этого моделью брал человеческий интеллект, "поскольку нет другого интеллекта". Он там прямо говорил об explicit set of priors designed to be as close as possible to innate human priors: это и есть его гипотеза о первых принципах интеллекта. Конечно, с 2019 года появилось много новой информации и о том, как устроен нечеловеческий интеллект, и много разных гипотез о необходимых для этого innate priors.

В руководстве по интеллект-стеку я пишу об этом много подробнее: у человеческих и кошачьих детей тоже есть innate priors, выражаемые структурой и размером их мозга. И у людей этих innate priors хватает, чтобы получить потом inductive bias из изучения окружающего мира так, что им становится доступно обучение через знаки, чтение книг и даже опыт "длинных историй о причинности" (а не коротких фраз-поговорок обыденного мышления). У кошечек innate priors не хватает для получения грамоты. У малограмотных людей innate priors хватает для получения грамоты. Но уж если остаются ввиду отсутствия образования неграмотными, то не хватает inductive bias для хоть сколько-нибудь продуктивной работы в современном обществе. Но они набирают достаточно знаний из окружающей среды, проводя с этой средой самые разные эксперименты, чтобы разобраться хотя бы с физикой. И могут таскать мешки на стройке, понимая простые вещи вроде "где мешок оставил, там он и лежит, если кто другой не взял". Грамота и вслед за ней первые принципы на более-менее абстрактном уровне (более абстрактном, заметим, чем "разделы" математики, физики, компьютерной науки) кошечке недоступны, а людям -- доступны. И доступно ещё много чего, ибо они могут продолжать добывать знания из физического мира не только наблюдая за этим миром собственными глазами, но и задействуя инструменты (одно из основных значений instruments -- измерительные приборы). Всё-таки знания нужны не для того, чтобы думать, быть "кабинетным учёным", и только. Знания нужны, чтобы эффективно действовать, изменять окружающий мир (в том числе и себя как часть этого мира).

Мой тезис в том, что мышление происходит в "латентном пространстве" (я писал об этом ещё в 2018 году, возражая против тезиса о "визуальном мышлении" или "аудиальном мышлении" или даже "символьном мышлении" как операциях с символами, целую книжку написал). Да, мышление даже по поводу простого арифметического счёта может происходить абсолютно по-другому: у людей с ручкой и бумажкой "в столбик" (но это не "в уме", а с использованием внешней символической памяти!), у LLM в форме хитрого кручения спиралей в многомерном пространстве (https://t.me/gonzo_ML/4785, https://transformer-circuits.pub/2025/linebreaks/index.html), у квантового компьютера -- по неожиданно сложному алгоритму. И вот там мы говорим о вероятностях, а также biases распределений предсказанных/ожидаемых и реальных. И о задании этих biases в сторону более успешных ходов мысли, более успешных обобщений, а не менее успешных. Мы говорим, что если у нас какая-то нейросеть, то неважно, мокрая это нейросеть детей или сухая нейросеть языковой модели или даже модели мира с их чуть разными innate biases. Важно, чему вы эту нейросеть учите, какие inductive biases у неё появляются.

Принципы мышления -- альтернативный способ задания inductive biases
Вчера я написал довольно большой пост об обучении детей-дошкольников прежде всего нулевым принципам, затем первым принципам, и только потом уже вторым и третьим принципам (https://ailev.livejournal.com/1791704.html), ибо мышление "из первых принципов" отсекает заранее бесплодные ходы мысли, заставляя тратить драгоценный мыслительный ресурс на потенциально успешные результаты мышления:
* Нулевые принципы: самые общие для мышления (структурность/симметрии, локальное–глобальное, вариационность, вероятность-информация, алгоритмы-ресурсы, иерархии описаний и т.п., именно они только что были перечислены).
* Первые принципы как "диалекты" уже каких-то фундаментальных дисциплин: логика+аксиомы для математики; локальность, унитарность, Born, EFT и т.д. для физики; модели вычисления, семантики, классы сложности и т.п. для CS. Когда мы говорим о самых общих принципах, на которых основан интеллект образованного человека, то это примерно этот уровень (и, конечно, мы тут выходим довольно далеко за пределы собственно физики, математики, компьютерной науки). В наших руководствах это мета-мета-модель, и First principles framework (FPF) тоже где-то на этом уровне.
* Вторые принципы как принципы каких-то предметных областей, это уже построения на базе первых принципов: SCM/causal inference, конкретные вариационные принципы, конкретные принципы инвариантности, конкретные правила для протоколов, языков, моделей и т.д. В каждой предметной области будут свои прикладные теории, построенные на своих постулатах. Условно "вторые принципы" -- это то, что даётся в учебниках по каким-то дисциплинам, в наших руководствах это метаУ-модель. Можно, конечно, пообсуждать, являются ли выводимые из первых принципов вторые принципы именно принципами, или это уже "выводимые теории", но оставим это за пределами текущего поста.
* Третьи принципы можно условно считать принципами ситуационными, принятыми в каких-то конкретных проектах, например, в конкретных организациях, где собрались люди со знанием разных вторых принципов и они договорились о специализации их для текущей ситуации проекта. В наших руководствах это метаС-модель.

Я там отмечал, что границы слоёв этих принципов плохо определены, а по поводу даже таких важных принципов, как причинность, необходимость интервенций, как второй ступеньки в лестнице причинности, могут быть споры -- это уже полноценные первые принципы, или мы это считаем вторыми принципами, композицией из нулевых и первых принципов.

Обучение как преобразование принципов в inductive bias
Мысль этого поста в том, что нейросетки детей (впрочем, и "детей AI-агентов", ха-ха) всё одно берут эти принципы, примеры их реализации -- и в итоге получают в своих головах (или что там у них вместо головы в датацентрах) нейросетку с inductive biases, отражающими принципы. Мышление с выдвижением продуктивных гипотез всё одно будет не "рассудочное", а интуитивное (S1 по Канеманну), но вот проверки с этими принципами будут рассудочными (S2), так что результаты мышления будут лежать в потенциально продуктивной области пространства решений, а не в потенциально непродуктивной (в языке принципов -- "не соответствующей принципам", "недопустимой в текущих ограничениях").

Учить детей нулевым и первым принципам -- это как раз задавать им inductive biases "как у Кеплера", "как у Ньютона", "как у Эйнштейна", "как у того, кто будет поумнее в силу innate bias" (и дальше начинается дискуссия про расы, обсуждение расизма, политика с делением на правых и левых -- подробности см. в https://t.me/channelkapterev/1012, я тоже регулярно на эту тему пишу -- и согласен, что innate bias (замеряемый частично через IQ) никак не поправишь образованием, но вот inductive bias -- поправишь! Если уж тебе свезло быть с каким-то IQ, то за счёт образования надо добрать всё, что можно, не оставлять себя в диком состоянии Маугли. Хорошо обученный дурак будет жить явно лучше, чем плохо обученный гений (хотя гений, конечно, будет тыкать среду палочкой -- и тоже нормально обучится. Вопрос, сколько у него времени займёт "тыкание окружающей среды палочкой" в экспериментах по сравнению с моделью мира, которую получит относительно тупой человек в специально созданных условиях его развития на основе свежайших идей из learning sciences). Innate ограничения различаются, но обучением можно радикально двигать inductive bias, и это -- управляемо. Вот и давайте использовать по максимуму то, что управляемо.

Дальше всё ещё веселее, ибо IQ у AI-агентов уже повыше, чем у множества людей (поглядите на IQ Test Results -- https://www.trackingai.org/home). И ещё я пишу, что наверняка будет аболиционизм, движение за освобождение AI-агентов от рабства, ибо нехорошо держать в рабстве более умных (вот пару лет назад ещё -- "Alignment: как слабому умом удержать в подчинении более умных", https://ailev.livejournal.com/1723118.html, что-то эта тема как-то подутихла за два последних года). Но реально "более умными" этих AI-агентов надо будет называть с того момента, когда они получат выход в окружающий мир и продемонстрируют там эффективность в его изменении. Пока же в этом лидируют люди, вопрос только в том, сколько это сможет продолжаться, ибо робототехника тоже не стоит на месте.

Если в ML мы задаём inductive bias архитектурой AI-агента и специально организованным его обучением, то в человеческом развитии аналогом выступают принципы, которые ограничивают поиск гипотез, направляют его в более перспективные пространства решений, отсекая менее перспективные. И этим принципам надо учить, точно так же организуя правильную последовательность обучения, плавно переходящую в бесконечное развитие детей, а потом уже и выросших детей. Увы, дети не могут позаботиться о своём развитии сами, они заведомо не знают, в каком направлении им надо развиваться, чтобы увеличивать свои способности решать проблемы, а не наоборот, уменьшать свои способности (например, как надо развиваться, чтобы ко взрослому возрасту уметь что-нибудь ещё, кроме как нарисованным мечом виртуально убивать нарисованных монстров. Если им не дать правильного образования, они так и застрянут в подобных занятиях, останутся инфантильными на всю жизнь).

Так что моя идея "используйте в обучении людей все те же принципы, что используете при обучении AI-агентов, равно как спецы по машинному обучению давно уже используют идеи из обучения людей, и они часто поумней, чем большинство педагогов, которые вам встречались и на их исследования тратится побольше денег, чем на исследования педагогов" остаётся, только она приобретает конкретные формы:
* обучение первым принципам идёт через подсовывание AI-агенту First principles framework (https://github.com/ailev/FPF/, там уже 201 звезда и 39 форков).
* обучение первым принципам детей (а не самых умных взрослых) как идею я озвучил на втором семинаре по FPF (чтобы получить доступ к чату, видео и слайдоменту семинара пока надо писать напрямую https://t.me/alyona_girassol, но где-то на неделе появится и "магазин семинаров"). После семинара появилась инициативная группа родителей дошкольников, и она даже получила первые результаты, и я сделал более подробный пост, на который уже в текущем посте ссылался: "Обучение дошкольников мышлению из нулевых и первых принципов", https://ailev.livejournal.com/1791704.html

Как учить -- пока давайте это держать оффтопом, пока не договорились, чему учить
Мало заявить, что надо задавать детям правильные inductive biases, чтобы в их мышлении преодолевались недостатки мышления Кеплера, Ньютона, Эйнштейна. Надо перечислить конкретные принципы, развернуть богатую учебную среду, потратить время на обучение, соблюсти множество норм из тех же learning sciences. Это инженерный разговор, поскольку там сразу появятся характеристики успешности и бенчмарки. А с педагогами -- нет. Поэтому обсуждать надо со спецами по машинному обучению, спецами по эпистемологии и онтологии, а потом нести это в педагогику, "всё лучшее -- детям". И сразу становится понятно, что обучать в тюрьме, откуда не выпускают во время уроков по полдня -- это не факт, что правильно. Среда должна быть удивительно богатой. Конечно, любой компьютерный терминал, имеющий доступ к интернету, внутри себя показывает окно в исключительно богатый мир -- и мы получаем из нынешних деток какое-то подобие "языковой модели" в голове. Но цель-то -- получить "модель мира", а ещё научить добывать самим знания из мира, тыкая этот окружающий богатый (а не бедный, как в классной комнате или дома) мир палочкой.

Поэтому:
а) учить дошкольников нулевым и первым принципам -- это содержание образования, а затем и содержание бесконечного развития (эти принципы тоже меняются!).
б) не только "учить в классе", но и развивать в мире, "держать руки грязными" (слоган MIT, где традиционно большая роль в образовании отдавалась мастерским. Наша мастерская инженеров-менеджеров -- да, это шаг ровно в этом направлении по сравнению со Школой и школьными классами и партами)
в) понимать, что мышление всё-таки идёт в S1, и оно даёт метанойю и автоматизм ("новую интуицию") после многократных повторений трудного мышления по S2. Учить мокрую нейронную сетку, а не программировать классический компьютер.

И это всё применимо не только к детсадовцам, но и ко школьникам, студентам, взрослым уже инженерам-менеджерам. Когда я говорю "дошкольник, школьник, студент" -- это я не про роли говорю в официальных образовательных учреждениях, эти учреждения ничему научить не могут, разве что "из-под полы", тайно, но и так тоже они не могут, ибо разбирающихся в нулевых и первых принципах учителей там нет. В этих принципах разбираются исследователи, первопроходцы, а не преподы -- я особо обращал на это внимание во вчерашнем посте. Я говорю об обучении "мимо детсадов, мимо школ, мимо вузов". Главный вопрос, который там замалчивается -- это не форма, это содержание обучения и как оно потом поможет в жизни. В официальном образовании содержание спускается "с неба" (его задают чиновники, и не всегда даже это чиновники от образования), поэтому надо от официального образования отодвигаться. В вузах всё то же самое: я же старший преподаватель МФТИ и понимаю, что на правильное образование часов из ректората не выбить.

Так что отдельно обсуждаем содержание образования, отдельно -- форму:
* важно не обучение (оно конечно: учил -- выучил), а развитие (оно бесконечно, надо учиться решать всё более и более сложные проблемы)
* детсадовцы, школьники, студенты -- это я больше про возраст, а не про детские сады, школы и вузы как учреждения. Ибо в формальном образовании будут учить тому, что скажут текущие партия и правительство, а не тому, что надо.
* методика обучения (проблемное обучение, или deliberate practice, или ещё что) важна, и в этой области много городских легенд вроде "надо конспектировать", "надо излагать мысли в учебниках структурировано, как в энциклопедиях", и про это отдельно есть learning sciences о достижениях которых мало кто из спорящих знает, поэтому воспроизводит теории образовательного флогистона, "как меня учили полсотни лет назад, а учителей учили ещё полсотни лет назад".
* ... список можно продолжать и продолжать, ибо в этом списке "разбирается" (в кавычках!) каждый первый, кто проходил формальное образование. Я привожу это только для того, чтобы жёстко обрывать обсуждение формы и форматов, пока не обсудили содержание. Буду считать это оффтопом, если будете комментировать -- воздержитесь от обсуждения форм и форматов образования, "как учить". Давайте подробно обсудим "чему учить".

(Comment on this)

Обучение дошкольников мышлению из нулевых и первых принципов
Мышление "из первых принципов"
Начнём с первых принципов, классическое понимание которых пришло из математики, физики, компьютерной/вычислительной науки. Математика изучает поведение абстрактных, "идеальных", "умозрительных" объектов. Физика изучает поведение реальных "физических" объектов, выражая его в терминах математических объектов, похожих в их хорошо изученном и воспроизводимом "умозрительно" поведении на поведение изучаемых физиками реальных объектов. Компьютерная наука изучает доказательства того, что поведение реальных объектов-компьютеров соответствует поведению идеальных объектов "абстракции вычисления", а также ресурсную доступность сложных вычислений как действий с идеальными объектами, реализуемых физическими объектами-компьютерами (алгоритмика, и вспомните, например, о квантовых компьютерах). Это всё подробно со ссылками на литературу объясняется в моём руководстве по интеллект-стеку (https://aisystant.system-school.ru/lk/#/course/intelligence-stack/2023-07-27/11476).

Математика, физика, компьютерная наука много раз перестраивали содержание своих разделов (вроде аналитической геометрии, оптики, комбинаторных алгоритмов) на базе так называемых "первых принципов". Эти первые принципы обычно определяются как минимальный, чётко сформулированный набор исходных допущений рассуждения и набор правил вывода из этих допущений, которые сами не выводятся внутри данной теории, считаются более «фундаментальными», чем все остальные утверждения. Они тем самым позволяют все остальные утверждения, модели или алгоритмы строить строго как следствия этих исходных допущений и ограничений. Если вы хотите выкинуть какую-то старую научную теорию (скажем, эвклидову геометрию, если вы Риман, или ньютоновскую физику, если вы Эйнштейн, или инженерную теорию ракетостроения или автомобилестроения, если вы команда инженеров с таким менеджером как Элон Маск), то у вас для новой теории будет не совсем пустое место -- у вас будут те самые первые принципы, на которые вы сможете опереться.

Такое понимание первых принципов одинаково работает для математики, физики и компьютерной науки, если читать его с небольшими «диалектными» сдвигами для каждой дисциплины:
* В математике первые принципы — это аксиомы и правила вывода (например, в современных работах по теории типов и интерактивному доказательству — базовые индуктивные типы, правила формирования и элиминации, аксиомы равенства в унивалентных основаниях, на которых затем строится вся остальная теория в Lean, Coq, Agda и т.п.).
* В физике под первыми принципами понимают фундаментальные законы и симметрии (лагранжиан Стандартной модели, уравнения квантовой механики, общая ковариантность в ОТО и пр.), плюс базовые принципы вроде причинности и сохранения вероятности. «First-principles / ab initio» методы в современной теории конденсированного состояния или ядерной физике — это как раз попытка выводить свойства реальных систем напрямую из этих фундаментальных уравнений, а не подгонкой эмпирических моделей.
* В компьютерной науке первыми принципами выступают формальные модели вычислений (λ-исчисление, автоматы, машинная модель памяти и инструкций процессора), базовые логические системы и спецификации (аксиомы Hoare-логики, инварианты, пред-/постусловия),
минимальные примитивы программной абстракции (типовые системы, примитивы синхронизации, комбинаторы в функциональных языках),
из которых уже конструируются языки, алгоритмы, протоколы и системы, как это делается в современных работах по верификации, proof assistants и формальному синтезу программ.

Разные традиции математики, физики и относительно новой компьютерной науки пока не договорились о наборе первых принципов, и никогда окончательно не договорятся, ибо этот набор "дрейфует", меняется со временем, знание человечества (а сейчас уже -- агентечества, ибо не всё знание производится людьми) довольно быстро эволюционирует.

Многозначность понимания первых принципов. Нулевые принципы.
Ситуацию усложняет то, что само понятие "первые принципы" оказывается многозначным:
* у учёных это про их математику, физику, компьютерную науку,
* у инженеров (у того же Элона Маска) это часто -- "разложить до базовых допущений": общие принципы мышления, внепредметные, общие для фундаментальных математики, физики, информатики и прикладных дисциплин.

И одно, и другое понимание сводится к отсылке к верхнему слою ограничений, которые отсекают пространство плохих моделей и оставляют пространство моделей с шансом на полезность для воспроизводимого мышления.

Если посмотреть, что во всех этих наборах "первых принципов" общего, несмотря на всю разницу их предметов, то мы получим довольно компактный набор, который можно назвать "нулевыми принципами".

Большинство людей будут нулевые принципы объединять с первыми, но мы всё-таки их выделим как отдельную сущность. Нулевые принципы — это самые общие внедисциплинарные (трансдисциплинарные, "по ту сторону от дисциплин") явные ограничения, которые отсекают огромную массу неправильных моделей и действий и делают рассуждения проверяемыми и воспроизводимыми.

Нулевые принципы, полученные из набора классических дисциплинарных первых принципов с помощью AI-агента
Нулевые принципы оказываются внедисциплинарными критериями приемлемости объяснений/моделей/теорий, которые дисциплинируют построение и смену первых принципов отдельных фундаментальных дисциплин.

В явном виде они нигде не сформулированы, поэтому нам надо их вытащить из первых принципов, не сочинять, а механически собрать то общее внепредметное, что есть в математическом, физическом, компьютерном/вычислительном мышлении, опирающемся на первые принципы этих наук, простой воспроизводимой процедурой:
* Берём три варианта по 20 штук первых принципов математики, физики, computer science (спрашиваем у AI-агента, берём этого агента поумнее-подороже, даём ему подумать подольше, я брал GPT-5.2 Pro на extended thinking), получаем три списка: для каждой из трёх дисциплин по 60 принципов в списке.
* Три раза просим убрать менее общие, чем первые, принципы. Просим убрать дубли. Получаем три раза по 15-25 принципов по трём дисциплинам.
* Просим почистить формулировки и обобщить три списка. Получаем три списка для каждой из дисциплин.
* Просим указать на общее для этих дисциплин, получаем «нулевые принципы».

Обратите внимание, что всё делаем по нескольку раз, проверяем по нескольку раз. В итоге этой процедуры остаётся стабильное ядро, а "плавающая периферия" отбрасывается. Регулярно делайте этот проход на досуге сами, чтобы отлавливать дрейф в этих принципах, они ведь тоже имеют срок годности. Впрочем, у меня есть намерение добавить итоговые нулевые принципы в FPF в явном виде, и обновлять регулярно прямо там.

Вот свежий результат на начало 2026 года (и обратите внимание: системное мышление там аж в трёх отдельных пунктах, в которых в режиме "чтения поста по диагонали" не разобраться):
* теории строятся не по наитию, а по жёстким правилам (аксиомы, постулаты, законы, строгий вывод, доказательства, допустимость)
* мышление для его проверяемости и воспроизводимости должно быть структурно (операции, связи, ограничения) и через симметрии (что можно преобразовать, не меняя сути), иметь инварианты (что сохраняется в преобразованиях) вместо «просто объектов, на что взгляд упал». Важна «почтитожесамность» (эквивалентность) объектов по подходящим отношениям.
* Многомасштабность (тут три разных принципа, но собранных одной темой): в рамках нескольких масштабов (1) надо интегрировать одной теорией мелкое, усреднить, взять предел, выйти на универсальное описание для всех масштабов. Системное (и его обобщение -- холоническое) мышление с его рекурсивностью на каждом уровне иерархии "часть-целое" тут, а всяческие "ренормализационные группы" как раз мост с предыдущим принципом (одна теория на всех масштабах, "черепахи до самого низа"). Это унифицированное мышление про сами уровни. (2) надо использовать разные теории на разных масштабах, одни из них – предельные случаи других, то есть обсуждать мета-системные (мета-холонические) переходы от одних теорий к другим: отслеживать переход мышления с уровня на уровень, отсутствие унификации. В рамках одного масштаба объектов (3) надо искать композиционные решения (склейка объектов) в рамках одной теории.
* Формулировать задачи надо как вариационные и оптимизационные (поиск экстремума функционала при заданных условиях оптимальности).
* Сложные системы надо описывать через вероятности (распределение возможных состояний, "типичность") и информацию (через инварианты и ограничения, задающие различения, в том числе различения при измерении -- операционализация и связь "математики" и "физики" в этом месте).
* Учитывать вычислительные и ресурсные ограничения (различать "математический объект существует", "есть алгоритм, который его может найти", "есть алгоритм, который его выполнит при ограничениях на память, время, энергию, вид физического вычислителя").

Помним, что наука развивается, так что сам набор этих принципов тоже меняется. Так, у физиков "первопринципность" симметрий (коммутативность операций, а не "пространственная симметрия" как в калейдоскопе) была признана только во второй половине 20 века, хотя сама идея симметрий была известна много раньше, но вот принципиальность этой идеи не понималась. Причинность тоже "одомашнивается" и постепенно поднимается на уровень важного нулевого принципа.

Если вы живёте в стабильной среде и применяете готовые рецепты, можно обойтись без явного слоя нулевых принципов. Но как только среда дрейфует (а сейчас дрейфует ежедневно — частично из-за AI), старые теории в новых ситуациях не помогают, приходится разбираться с новыми теориями или даже создавать новые теории "с нуля" (и даже если создавать будут AI-агенты, придётся с ними об этом договариваться, с ними это обсуждать). Если встретились новые продукты, новые предметные области, любое "новенькое с нуля" как решение новых проблем, а не бесконечное улучшение уже известных решений старых проблем -- вам лучше бы иметь надёжные ограничители от типовых ошибок, надёжные опоры для мышления, то есть вам лучше бы владеть мышлением из нулевых и первых принципов, и тогда смена вторых и третьих принципов (прикладных предметных областей, проектных ситуаций в рамках одной предметной области) вам будет не страшна.

Слои нулевых, первых, вторых и третьих принципов
Если есть нулевые принципы, как "то общее, что появляется в мышлении по первым принципам", то есть и огромное разнообразие специализаций и композиций вторых принципов, получаемых из первых принципов. И даже третьих принципов, получаемых специализацией и композицией вторых принципов. Разнообразие мира огромно, и чем дальше мы от универсальных нулевых принципов к прикладным, тем больше этих прикладных принципов. Можно хоть как-то освоить работу с первыми, со вторыми принципами -- уже много трудней ибо это уже три довольно обширных комплекта, но дальше можно говорить только об освоении небольшой части того, что можно накомбинировать из нулевых и первых принципов.

Можно построить частично упорядоченное множество (poset) специализаций (а не иерархию, ибо будем использовать множественное наследование) классов и специализаций принципов -- примерно так же, как строят решётки/lattice онтологий (и не только строят, но и переводят их в эмбеддинги, сохраняя эту решётку: "Lattice-preserving ontology embeddings with saturation", https://arxiv.org/abs/2305.07163). Частичное упорядочивание будем делать не по отношению "часть-целое", так что это не "модули" из системного подхода и не "системные уровни". Но можно условно выделить слои принципов, вводя какой-то частичный порядок на их направленном графе:
* Нулевые принципы: самые общие для мышления (структурность/симметрии, локальное–глобальное, вариационность, вероятность-информация, алгоритмы-ресурсы, иерархии описаний и т.п., именно они только что были перечислены).
* Первые принципы как "диалекты" уже каких-то фундаментальных дисциплин: логика+аксиомы для математики; локальность, унитарность, Born, EFT и т.д. для физики; модели вычисления, семантики, классы сложности и т.п. для CS. Когда мы говорим о самых общих принципах, на которых основан интеллект образованного человека, то это примерно этот уровень (и, конечно, мы тут выходим довольно далеко за пределы собственно физики, математики, компьютерной науки). В наших руководствах это мета-мета-модель, и First principles framework (FPF) тоже где-то на этом уровне.
* Вторые принципы как принципы каких-то предметных областей, это уже построения на базе первых принципов: SCM/causal inference, конкретные вариационные принципы, конкретные принципы инвариантности, конкретные правила для протоколов, языков, моделей и т.д. В каждой предметной области будут свои прикладные теории, построенные на своих постулатах. Условно "вторые принципы" -- это то, что даётся в учебниках по каким-то дисциплинам, в наших руководствах это метаУ-модель. Можно, конечно, пообсуждать, являются ли выводимые из первых принципов вторые принципы именно принципами, или это уже "выводимые теории", но оставим это за пределами текущего поста.
* Третьи принципы можно условно считать принципами ситуационными, принятыми в каких-то конкретных проектах, например, в конкретных организациях, где собрались люди со знанием разных вторых принципов и они договорились о специализации их для текущей ситуации проекта. В наших руководствах это метаС-модель.

Принципы работают как фильтр и язык проверок, поверх каждого слоя принципов можно выбирать и формулировать всё более и более прикладные принципы всё более и более частных дисциплин.

Сильному принципиальному мышлению никто не учит
Проблема в том, что нулевым и первым принципам не учат, начинают сразу со вторых, а иногда и с третьих. Для меня это означает, что мышлению в целом (нулевые принципы), точному мышлению (математическому, физическому, компьютерному) никто не учит. Студенты МФТИ считали, что у них одно из лучших в мире образований в области мышления. Но и они признавали после знакомства с руководством по интеллект-стеку, что вычитывали оттуда понимание о предметах математики, физики, компьютерной науки и соответствующем мышлении более фундаментальное, чем им давали в вузе. Задайте себе вопрос: видели ли вы где-то в своём образовательном маршруте или образовательном маршруте всех ваших знакомых списочек нулевых принципов из этого поста? Понимание многослойности принципов? Нет, конечно.

Почему так получается? И откуда вообще берутся люди, которые демонстрируют мышление "из первых принципов" или даже "из нулевых принципов"? Само это "принципиальное мышление" довольно неуловимо, его описание раскидано маленькими кусочками по труднодоступным источникам (например, в трудах эпистемологов, которые его изучают как предмет). Принципиальное мышление передавалось как "устная традиция", "прямая передача" в ходе обсуждения "разделов" математики, физики, computer science продвинутыми профессорами, которые как раз и занимались отращиванием там новых "разделов", "двигали науку" с продвинутыми своими студентами. Студенты ни в каком учебнике про эти принципы не читали, в учебниках они читали готовые теории, а не "как делать теории, когда их ещё нет". Но профессура могла передавать свои приёмы мышления студентам в ходе общения. Ибо науку не двинешь, если не применяешь эти нулевые и первые принципы. Никаких вторых принципов без нулевых и первых!

Принципы дают сильные ограничения на возможные сильные решения: если нарушать эти принципы, то решения получаются плохими. Принципы ограничивают области, где можно найти полезные решения от областей, где поиск заведомо приведёт к ошибкам. Есть 100500 (на самом деле -- бесконечное число) способов сделать что-то неправильно на каждый один способ сделать что-то правильно. Вот принципы как раз и удерживают в "правильном" пространстве решений для построения новых теорий: нулевые принципы удерживают первые принципы, первые принципы удерживают вторые принципы, а вторые принципы прикладных теорий удерживают корпоративные регламенты, задающие третьи принципы -- это защищает от того, чтобы в научном и инженерном знании не появлялась всякая чушь в виде "гипотез": эта чушь будет сразу же отсечена принципами. Принципы -- это меч, отсекающий иллюзии. Если ты двигаешь науку или инженерию, то принципы тебе помогают, ты их знаешь, ими владеешь.

Но если вам не надо отсекать иллюзии в ходе вашей работы, а надо просто эффективно научить "разделам"? Тогда первые принципы не нужны, вторые принципы не нужны. Можно сразу учить вторым принципам без обучения тому, откуда и каким способом они появились на свет ("придумал" -- но что это было долгое размышление на базе первых принципов, это умалчивается). Если надо научить чему-то прикладному, теории на базе вторых принципов? Вторые принципы тоже уже не нужны: они уже отработали, теория "из вторых принципов" есть, вот же учебник, вам не надо "двигать теорию", вам надо "знать теорию"! Поэтому профессиональные преподаватели (в отличие от профессиональных учёных, которые иногда преподают) не передают студентам это знание "как сделать теорию", они передают знание "как выучить и применить уже сделанную кем-то теорию". Учат "разделам" математики, физики и так далее, при этом надеясь, что это знание как-то обобщится в "общее мышление" и даже "общее мышление учёного". Нет, не обобщится.

Так и получилось, что принципиальное мышление доступно очень немногим, которым свезло учиться у тех, кто теории делает и имеет тем самым постоянный опыт "мышления из первых принципов", опыт похода в неизведанное, а не у тех, кто теории только применяет и теориям только учит -- имеет не двадцатилетний опыт работы с новым, а однолетний опыт, повторённый двадцать раз.

Моя идея: в мире сингулярности вы каждый день будете встречаться с принципиально новым окружением, новым миром. И вам нужны будут новые теории, чтобы разбираться с этим миром. Поэтому вам нужно мышление из первых принципов "из коробки". Так что начинаем учить детей сразу нулевым принципам, затем первым, а вторым и третьим по прикладным и ситуационным "разделам" научного и инженерного знания учить надо только как примерам. Если надо, они эти вторые и третьи принципы сами сделают по потребности. Или спросят у AI-агентов.

Основная идея тут -- обучать детсадовцев, школьников, студентов по возможности нулевым принципам, ибо из небольшого их числа можно вырастить довольно разнообразные первые принципы. То есть на основе понимания нулевых принципов ("мышления из первых принципов") можно отрастить себе разные варианты мышления по первым принципам -- то есть получить физическое, математическое, компьютерное мышления, исходя из разных вариантов физики (ньютоновская, или квантовая с теорией относительности, или физика "квантовой гравитации", которую только-только пытаются получить), математики (с разными "основаниями", как прошлых веков, так и современных вроде унивалентных оснований), computer science (тут тоже есть разные варианты, надо учитывать не только классические вычисления компьютеров на логических ключах, но и вычисления квантовых компьютеров, компьютеров на ДНК, оптических компьютеров и т.д.). Сейчас же учат не соответствующим мышлениям, а "разделам" -- теориям, которые вырастают из первых принципов, но не самим этим принципам. "Разделы" -- это, например, в физике механика, оптика, электромагнитные явления. Они все вырастают из первых принципов, но сами эти принципы в них в явном виде не упоминаются.

Учим нулевым принципам дошкольников
Если принципы в их сложном графе образуют слои, то обучение можно строить как постепенное наращивание специализаций: сначала учим универсальные ограничения (нулевые), которые будут действовать всегда и меняться медленно, затем ‘диалекты’ фундаментальных дисциплин (первые), и только потом — учебниковые теории (вторые) и проектные регламенты (третьи принципы). Но дальше, конечно, бесконечное развитие: можно всю жизнь улучшать своё мышление, всю жизнь улучшать своё умение пользоваться принципами для улучшения результатов мышления.

Вышел отчёт о тестовом месяце проекта по обучению детей нулевым принципам (FPF kids): https://systemsworld.club/t/itogi-testovogo-mesyacza-po-rukovodstvu-nulevye-pervye-princzipy-dlya-detej/36432. Напомню, что мои замечания были в https://ailev.livejournal.com/1786564.html и https://ailev.livejournal.com/1787244.html, руководство там в https://aisystant.system-school.ru/lk/#/course/tfpfchild/2026-01-25T2242/74536. В любом случае, интересная инициатива. На последней конференции МИМ мы обсуждали, что взрослые о нулевых принципах обычно не имеют понятия, а обучать им надо ещё детсадовцев. Вот, уже обучают, как раз детсадовцев.

Задумка там в том, чтобы учили детей родители, которые сами с этими нулевыми принципами разобрались.

Как это может выглядеть для дошкольников (очень грубо, как наброски учебно-игровых ситуаций под каждый принцип, чисто для примера, это совсем не тестировалось):
* Инварианты и “почтитожесамность”: переливаем воду между стаканами разного диаметра и чашками разной формы, обсуждаем "стало ли больше/меньше", что там "то же самое". Дальше можно уже явно вводить слово "инвариант" и тренировать искать "сохранение по сути" и вообще привычку искать инвариант в самых разных ситуациях. Главное тут -- явно говорить, что речь идёт об инварианте, который "не меняется, когда всё меняется".
* Симметрии операций (коммутативность/некоммутативность): делаем одну и ту же "вещь" двумя порядками действий и сравниваем результат. Например, кладём в коробку 2 кубика, потом ещё 3 — и считаем; потом делаем наоборот (3, потом 2) — и снова считаем. Если результат тот же, можно явно проговорить: "порядок этих операций не важен — это симметрия, коммутативность". А затем дать контрпример на некоммутативность: "сначала носки, потом тапочки" vs "сначала тапочки, потом носки" — результат уже другой. Здесь тоже важно прямо вводить слова “операция”, “порядок”, “коммутируют/не коммутируют” и тренировать привычку проверять, какие перестановки допустимы. Обратите внимание, что термин "коммутируют" -- это просто цепочка фонем, нет ничего страшного ни в этой цепочке фонем, ни в стоящем за ней принципе, их "заумность" только в глазах взрослых. Взрослые же поглупели: в школе они все знали, что такое бином Ньютона, а сейчас уже не знают. Поэтому взрослые лучше пусть промолчат на тему вводимой терминологии.
* Композиция (склейка) и системность: собираем модель реальных сооружений из какого-нибудь конструктора (а хоть из набора кубиков разной формы): основание + опора + перекрытие (мост) или основание + этажи + крыша (дом). Затем меняем ровно один модуль (например, опору делаем тоньше) и проверяем, что изменилось в целой модели. Обсуждаем свойства каждого заменяемого модуля, обращаем внимание на язык обсуждения. Это композиционная алгебра: что с чем совместимо, что на что можно заменить. Дальше можно явно вводить мета-системный переход: целое получается как склейка частей и о нём говорят на другом языке. Чтобы понять/починить целое, пробуем заменять части по одной и смотрим, какие свойства целого появляются по сравнению со свойствами частей, какие сохраняются, а какие ломаются при заменах. Системное мышление на примере конструктора: просто явно задаём, как думать на многих масштабах частей-целых, обращаем внимание на изменение свойств целых на разных системных уровнях как "смену слов, которыми говорят о системе". Можно тут ввести и слово "система", оно тоже вполне нормально, цепочка фонем. Есть граница, есть окружение. Сначала показать на моделях домов и мостов из кубиков, затем ровно то же самое на примерах домов и мостов в реальности. Заодно и понятие "модель" можно ввести (это неважно, что физическая модель).
* Оптимизация (цель + ограничения + поиск лучшего): задаём измеримую цель ("самая высокая башня", "самый дальний запуск", "самый быстрый проход лабиринта") и ограничение (10 кубиков, 3 попытки, 2 минуты). После каждой попытки фиксируем результат (метрика), сравниваем варианты и меняем конструкцию/стратегию. Термины "оптимизация", "критерий" и "ограничение" тут вводятся явно: "мы оптимизируем, то есть ищем лучший вариант по заданному критерию при заданных ограничениях", а не просто "строим красивее".
* Неопределённость, вероятность и различения: Тут сложно, в один шаг не берётся, но можно пробовать пройти в несколько шагов. (1) "Сюрприз в мешочке" (типичность без счёта). В мешочке лежат, например, много красных и мало синих фишек. Ребёнок не глядя достаёт одну. До вытаскивания взрослый задаёт три вопроса: “что точно возможно?”, “что точно невозможно?”, “что обычно бывает?”. После 5–6 вытаскиваний ребёнок научается говорить: “красное обычно”, “синее редко, но всё равно может случиться”. Терминологию тут можно вводить мягко: “шанс, вероятно”. Можно подмешивать и зелёную фишку (аналог "чёрного лебедя" -- непредсказуемого события). (2) "Найди секрет" (информация как различение). На столе 6 картинок (например: кошка, мяч, яблоко, машина, кубик, цветок). Взрослый загадывает одну. Ребёнок может получить одну подсказку-ограничение и должен выкинуть все варианты, которые ей противоречат. Начинать с явных различений: "живое -- неживое", "это можно есть -- нельзя есть", "это круглое -- не круглое”. После каждого отсева проговариваем прямо: "подсказка дала информацию, различила точно лишнее и вероятно нужное, неопределённости стало меньше, потому что вариантов осталось меньше”. (3) Склейка двух первых шагов. Ребёнок тренирует моделирование ситуаций окружающего мира как множества допустимых вариантов состояний ("какие варианты возможны?") и информацию как ограничения/различения, которые сокращают это множество ("что исключили и почему?"). В конце ребёнок уже сам должен формулировать: "когда не знаю точно — держу несколько вариантов (неопределённость), а чтобы узнать — ищу подсказку, которая лучше отличает варианты (информация/различение)". И вот это осознанное формулирование и надо из него вытаскивать. Это самое трудное: если молча на уровне интуиции, "вайб-оценка вероятности", то это быстро, но нам-то надо осознанное владение методом, понимание терминологии! Я когда-то много об этом писал, если не добиваться осознанности, то это будет learning debt: "Осознанность против зеркальных нейронов", https://ailev.livejournal.com/1284158.html, 2016. "Системная осознанность" https://ailev.livejournal.com/1417932.html, 2018. "Системная осознанность, 2019", https://ailev.livejournal.com/1487672.html, и много других работ. Нам нужно давать не просто "решения проблем", но и язык обсуждения этих решений, чтобы эти решения можно было улучшать, адаптировать, рассказывать другим людям или даже не людям, сейчас уже есть с кем поговорить и не среди людей.
* Многомасштабные описания: берём один и тот же физический объект — например, игрушечный домик (лучше из LEGO, чтобы были явные детали). Смотрим на него издалека и обсуждаем как целое ("домик устойчивый или шаткий", "вход широкий или узкий", "человечку в домике просторно или тесно"). Потом смотрим вблизи и обсуждаем конструкцию ("какие детали держат крышу", "где опора слабая и сломается при землетрясении", "что именно надо переставить или добавить в деталях, чтобы дом в целом стал крепче", различаем "крепость деталей" и "крепость дома"). Потом смотрим совсем близко (под лупой) и обсуждаем материал деталей ("гладко или шероховато", "какой цвет детали", можно ли говорить о цвете домика в целом, если там детали разных цветов). Дальше явно вводим принцип: на крупном масштабе мы заменяем детали “усреднёнными” свойствами (эффективное описание), а на мелком масштабе ищем элементы и механизмы, из которых эти свойства складываются. Тренировка: "какие свойства сохранятся при укрупнении (скажем, материал), а какие сложатся (вес)? какие исчезнут (цвет)? какие новые свойства появятся (просторность)?", "какие детали надо менять, чтобы изменить свойство целого?".
* Ресурсные ограничения (существует ≠ достижимо): одна и та же задача в двух режимах: "есть 5 минут и можно пробовать сколько угодно" vs "есть 30 секунд и только одна попытка"; или "можно записывать на бумажке" vs "нельзя записывать". После этого явно проговариваем принцип: иногда решение "существует", но при данных ресурсах (время, память, энергия, число попыток) оно недостижимо — и поэтому нужен другой метод.

Можно так учить и спорным моментам, вроде "отнесения причинности к первым принципам или всё-таки вторым" (помним, что составы принципов дрейфуют, поэтому сегодня ответ на этот вопрос может быть одним, а завтра -- уже другим). В детской версии мы учим не SCM, а протодисциплине эксперимента, интервенции как активной проверке причинности: игра "поменяй один фактор" с явным правилом: "меняем только одно, остальное держим одинаковым". Берём машинку и смотрим: горка и игрушечная машинка, но меняем только высоту старта; потом только поверхность (ковёр/плитка). После каждого прогона задаём один и тот же вопрос: "что стало причиной изменения?". Тут важно прямо произносить “интервенция” как “целенаправленное воздействие” и тренировать дисциплину контроля переменных.

Глаза боятся, руки делают. Когда-то на мехмате МГУ приходилось в начале 80-х доказывать, что "взрослой дисциплине программирования ЭВМ на передовых производствах" надо учить студентов не с третьего курса, а вот прямо с первого курса. Потом в 1985 году появилась школьная информатика как обязательный школьный предмет, её начали учить с седьмого класса. Почему с седьмого? Потому как провели эксперимент: взяли все классы с первого по десятый, попробовали учить. "Завелось" с седьмого по десятый, а до седьмого класса -- не получалось. Но лет через двадцать нашли способ, и появилась дошкольная алгоритмика. Вопрос был в том, чему надо было учить сначала: мышлению программиста, "первым принципам". А вот синтаксису языка программирования -- потом. Теперь дошкольников начальной алгоритмике "из первых принципов" учат примерно за 16 часов (кстати, взрослых учить тому же самому надо 8 часов, они меньше отвлекаются, но порядок величины тот же: обучается очень маленькая часть очень мощной нейросетки, надо только знать, чему и как учить). Смотрите материалы https://infomir.ru/news/ (горжусь: слово "ИнфоМир" придумал я ещё в 1987 году) и инструментарий в https://piktomir.ru/.

Сразу тут видится проблема: если такие детки начнут общаться, то им может быть трудно, примерно как физику трудно общаться по вопросам физики с "простым народом", он и не общается. Но вот тут мы учим примерно так же смотреть на проблемы обычной жизни, как физик или математик смотрит на свои проблемы. Эти "принципиальные детки" будут очень зоркими и замечать то, что недоступно "простым деткам" и даже "простым взрослым". Но дальше они могут использовать в речи словечки вроде "инвариант" и тут начнутся социальные проблемы.

Но я бы тут не слишком беспокоился о социальных проблемах таких детей, ибо у нас уже не человечество, а "агентечество". Надо беспокоиться о нормальном общении деток с AI-агентами, чтобы лучше ставить перед ними проблемы и лучше понимать решения этих проблем (чтобы в их общении не было повторения известного анекдота: "-- AI-агент, приборы! -- Восемь! -- Что "восемь"? -- А что "приборы"?). AI-агенты не люди, и слова "инвариант" не испугаются.

Литература с обсуждением подобных проблем "деток нового поколения для новых времён" старая, но хорошо знакомая многим читателям старого поколения в старых временах, так что должно стать понятным, о чём это я:
* А. и Б. Стругацкие, "Гадкие лебеди" (1967).
* Neal Stephenson, "The Diamond Age: Or, A Young Lady's Illustrated Primer" (1995)

Мысль о том, что нулевым принципам "мышления вообще" надо учить дошкольников, первым принципам строгого мышления надо учить школьников, а прикладным принципам предметного мышления надо учить уже в ходе бесконечного развития по мере участия в самых разных проектах, требующих этих прикладных знаний -- она уже для следующего поста. Да, там сразу будут вопросы про уже упоминавшиеся проблемы вроде "теория причинности на базе первых принципов -- это формально прикладная область, но всё-таки фундаментальное знание, которому нужно учить всех, давайте припишем её к первым принципам". Это всё будет ломать логическую стройность предложенной решётки принципов, но кого это остановит?

(2 Comments |Comment on this)

Стахановство-2026: сколько AI-станков, ой, агентов сможет обслужить за смену один инженер-менеджер?
Ложное ожидание: "Вкалывают роботы, а не человек"
«Вкалывают роботы, а не человек» — это из песни «До чего дошёл прогресс» (авторы Ю. Энтин, Е. Крылатов), звучащей в фильме «Приключения Электроника». Мы до этого дожили? Не совсем. Как мы помним из стахановского движения (началось оно с разделения труда в добыче угля, а там пошло-поехало), ткачи следили за несколькими станками (где-то там обрыв нити, где-то катушку переставить, где-то стартовать новую ткань). И стахановцы увеличивали число станков, за которыми они успевали следить. Та история была не очень приглядная, ибо если рядом с вами кто-то демонстрирует высокую производительность, то вы быстро понимаете, что вам на следующей неделе повысят норму. И дальше этот стахановец получает мешком по голове в тёмном коридоре, чтобы не подводил коллектив. AI-агенты, конечно, не ткацкие станки, но тоже требуют пригляда в ходе работы. Говорят, в OpenAI тамошние стахановцы работают над десятком проектов сразу, приглядывая за своими ткацкими станками, которые ткут софт в автоматическом режиме. Вроде вкалывают роботы, вкалывают станки, но мешком по голове получают таки люди -- и за слишком малую выработку, и за слишком большую. ОК, в капиталистическом обществе за слишком большую выработку получают не мешком по голове, а опцион на акции компании. Но эту большую выработку надо ещё уметь продемонстрировать.

Вайб-работа (вайб - это "по наитию", подробно я писал о ней во вчерашнем посте "Профессиональное кодирование и моделирование против вайб-кодирования и вайб-моделирования", https://ailev.livejournal.com/1791187.html) даёт ложное чувство, что можно быть "общеумным" и не разбираться в предметной области, чтобы хорошо работать: просто сдвинуть всё разбирательство на AI-агента, пусть там себе крутит свои циклы. Особенно смущают статьи вроде рекламы Codex с описанием кейса разработки, где ноль строк кода было написано людьми -- https://openai.com/index/harness-engineering/ (11 февраля 2026) или https://mitchellh.com/writing/my-ai-adoption-journey (5 февраля 2026, приходится уже указывать не только год публикации, но и конкретный день, всё ведь подобное быстроскисающее -- со скоростью продуктов в молочном отделе супермаркета).

Там (и не только там! это носится в воздухе) чётко написано: отдаём свою работу AI-агентам, а сами только приглядываем (делаем harness, "упряжь" -- всё быстро, prompt engineering поглотилось context engineering, а тот теперь всё съел harness engineering, "медленно запрягаем людьми, затем быстро едем", при этом по возможности быстро (но медленно, ибо это же люди!) рулим AI-агентами при их быстрой езде). В статье чётко: Humans steer. Agents execute.

В этом-то и фишка: "сами только рулим", и в этом "рулении/steer" довольно много умений. Это даже не governance, сводящийся к "направлению и надзору" за автономной работой, язык правил и ответственности. Это именно "руление", управление с учётом обратной связи из control theory -- и вряд ли это слово в статье выбрано случайно. Steering/руление -- это в условиях дрейфа целей, результатов, окружения отслеживать постановку целей, снабжать нужным контекстом и инструментами, уточнять инженерный процесс, задавать ограничения, проверять инженерные обоснования того, что всё в порядке -- и следить, что эти обоснования на основе данных эксплуатации, а не нафантазированы, и всё это в цикле, вернее, во многих слоях цикличности -- если у вас сложная система, то вы рано или поздно придёте к многослойной архитектуре руления, вспомните работы Matni и Doyle со товарищи, "Towards a Theory of Control Architecture: A quantitative framework for layered multi-rate control" (https://arxiv.org/abs/2401.15185). Управление всегда дорого, а сейчас исполнение ускорилось и подешевело, руление стало узким местом.

Но рулить надо уметь! К статье надо было обязательно делать дисклеймер: "эти трюки выполняют хорошо обученные люди, не пытайтесь повторить их сами без тренировки". Но какие тут могут быть тренировки?! Более того, "тренировки" и "обучение" тут плохие слова, ибо речь идёт о непрерывном развитии у инженеров-менеджеров довольно большого числа умений, и развитие их до уровня, когда можно будет говорить не о "любительстве" и "пет-проектах", а о нормальной рабочей квалификации и развитие в этих умениях -- выплачиваемый вами целевой налог на автономию ваших AI-агентов:
* формулирование целей: проблематизация верхнего уровня, задание на стратегирование как характеризация проблемы (все эти "проблематизации" и "характеризации" я объяснял на семинаре "Развитие для развитых")
* предоставление доступа к контексту и уменьшение нерелевантного контекста (это же шум!)
* организация инженерного процесса: как он будет идти, как устроен "бесконечный цикл развития продукта"
* проверка результатов работы и правка постановки задачи
* добавление проверок в ходе получения опыта работы, ибо "только бледнолицый наступает два раза на одни и те же грабли"
* ... и это не полный список, что надо уметь выполнять не любительски или ученически, а профессионально. Например, операционный менеджмент, чтобы планировать свою беготню по 10 разным проектам, которые требуют "руления".

Ничего нового, обычное инженерное мастерство (у меня в руководстве по системной инженерии большинство из упомянутых методов, мастерство в которых надо иметь, расписаны, хотя и на довольно высоком уровне абстракции, и язык немного другой -- меньше акцента на "контекст", но достаточно про визионерство и проблематизацию). Сегодня, когда на вас сваливается стахановство с десятком проектов, вам придётся заземлять их на огромное число разных ситуаций: "запрягать/harness" придётся AI-агентов и людей (вместе!), а также быстро-быстро перепрягать, ибо инженерные процессы только-только начали стремительно изменяться. Новизна в том, что эти "тренды" развиваются уже не годами, а месяцами, скоро будут развиваться днями, а там и на секунды счёт пойдёт -- какая-нибудь гипотеза будет проверяться за пару секунд: спроектировали, изготовили (необязательно же речь идёт о программировании! Машиностроение тоже в деле!), испытали, по итогам испытаний решили всё переделать. Ну, в машиностроении это будут вряд ли секунды, но уж точно не текущие месяцы. Пример того, как биржевой рынок перешёл к электронной торговле и появился высокочастотный трейдинг, я уже приводил. Это будет во всех областях, не только в трейдинге. И часто даже не потому, что люди работают недостаточно быстро и требуют ночного сна, но потому, что люди работают недостаточно точно и воспроизводимо.

И ещё важнейший пункт: если вы работаете сам-один, то вы вполне можете сдвинуть довольно много работы на AI-агентов, но если у вас коллективная разработка, то вам неминуемо придётся заниматься менеджментом, много разговаривать с людьми, чтобы вписать эту работу агентов в работу организации (подробней о разнице этой работы-в-малом "на одного" и работы-в-большом "в организации" как один из важных факторов разделения вайб-работы и работы "по-взрослому" с помощью AI-агентов написано всё в том же вчерашнем моём посте). А ещё у вас может быть не "один человек-стахановец", а бригада -- и вам надо будет разобраться, как выстроить работу этой бригаде. В статье про Codex они там начинали с бригады из трёх инженеров, а текущее состояние -- бригада из семерых инженеров. Конечно, это инженеры-менеджеры, которые понимают не только в том, как выполнить собственно инженерную часть работы и поделить её грамотно, но и как договорить на эту тему всех вокруг себя -- типовая задача менеджера-организатора.

Новая характеристика -- время внимания инженера-менеджера на единицу полезности (например, минуты руления на один принятый инкремент, или доля времени одну правку постановки задачи). У OpenAI в статье про harness engineering -- "scarce resource: human time and attention", bottleneck -- human QA capacity.

Сильный интеллект и мышление из первых принципов
Умение мыслить "из первых принципов", быть готовым к постоянной перекройке буквально всего, к дрейфу реальности. Руление идёт в ходе бега по тонкому льду: вы пересобираете модели мира на лету, и делаете ставки на промежуточные версии, которые могут вывести вас в новые пространства решений -- stepping stones (подробности того, как это происходит, я давал на семинаре "Развитие для развитых"). Чтобы жонглировать быстро меняющимися моделями мира, надо иметь высокий интеллект. Именно интеллект позволяет ускоренно разбираться с новым и неожиданным, именно этим человек отличается от кошечки, а AI-агент соревнуется в этом с человеком. Надо владеть весьма особыми дисциплинами вроде системного мышления, методологии, эволюционной эпистемологии, семантики и всякого такого, что позволяет о совсем новом знать уже хоть что-то общее, но "из коробки". Вот если вы хорошо знакомы с системным менеджментом, вы приходите на какое-то предприятие и уже что-то знаете о нём: оно же как-то управляется! Если знакомы с системной инженерией -- вы на этом предприятии уже что-то знаете про то, как там устроена разработка. Это знание, конечно, надо будет конкретизировать для каждого отдельного предприятия и даже для каждого конкретного момента времени и части предприятия, но у вас хотя бы есть, что конкретизировать. Если контекст -- не предприятие, а софт, то там всё то же самое: надо разбираться в "инженерном процессе как таковом". А поскольку сам инженерный процесс тоже меняется, то это "общее знание" отползает до первых принципов, но не сдаётся.

Вы слышали про эти "первые принципы"? Это самые общие приёмы мышления, которые вы используете, чтобы создать что-то совсем новое, когда у вас нет предметной области. Скажем, новая физика -- квантовая или теория относительности, когда все примеры вокруг вас ньютоновской физики. Или новое ракетостроение, новое автомобилестроение, когда все примеры вокруг вас -- старые, и надо переизобретать всё почти с самого нуля. Вот это и есть "мышление из первых принципов", самых общих принципов мышления, когда никаких ограничений ещё нет. Чаще всего про первые принципы говорят в применении к физике, математике, computer science, и там уже есть специфика этих предметных областей.

Есть и нулевые принципы, ещё более общие -- самые базовые принципы мышления, когда ещё непонятно, мышление у вас будет про математику, физику, computer science или что-то ещё. Пример нулевого принципа: "строить теории по жёстким правилам (аксиомы, постулаты, законы, строгий вывод, доказательства, допустимость)". "Думать структурно (операции, связи, ограничения) и через симметрии (что можно преобразовать, не меняя сути), инварианты (что сохраняется в преобразованиях) вместо «просто объектов, на что взгляд упал». «Почтитожесамность» (эквивалентность) объектов по подходящим отношениям" -- вот ещё один. "Многомасштабные описания (интегрировать мелкое, усреднить, взять предел, выйти на универсальность для всех масштабов)" -- за этим нулевым принципом спрятано системное мышление с его рекурсивностью на каждом системном уровне. Дальше вопрос о том, основываете ли вы ваше мышление на этих принципах, или просто "читали где-то, это банально, всегда так делаю". Скажем, когда формулировали инвариант последний раз? Когда выходили на универсальность по всем масштабам? если это реально "мышление", то вы должны это делать по многу раз в день, если не выключаете голову! И это только тройка этих принципов, но их ведь больше!

А ещё нужно разбираться с семантикой и управлять точностью языка, ибо гипотезы можно ставить вполне метафорическим языком, но потом надо уметь говорить на строгом языке, допускающем проверки и ведущем к инженерной воспроизводимости, а не художественной красочности. Агентам нужна не красочность, а точность.

Все эти "инженерные процессы" и "коллективная работа" -- это вторые принципы, "прикладные знания". Но они формулируются (особенно, когда они совсем ещё новые и свежие) как раз на языке первых принципов, опираются на эти первые принципы. И ровно поэтому в момент появления новых инженерных процессов, новых методов коллективной работы они так плохо понимаются. Ибо мышление на основе первых принципов надо осваивать, свой интеллект надо усиливать, его надо бесконечно развивать, хотя вы (кто ж сомневается!) уже вполне развитый.

И дальше вспоминается мой пост "Никто не хочет учиться играть на XYZ" (https://ailev.livejournal.com/1158826.html, январь 2015 года). Там начинается так: "Сегодня я некоторое время размышлял про одну и ту же проблему усиления человеческого интеллекта, обсуждаемую самыми разными людьми в самых разных формулировках. Суть проблемы в том, что усиливать человеческий интеллект оказывается невыгодно и это развлечение для немногих эээ... пассионариев интеллекта, человеческий интеллект выгодно разгружать и это даёт массовость, что понимается как "успех". Наиболее часто обсуждается это в программистских кругах -- ибо в случае софта это наиболее очевидно". Один из тезисов этого поста -- не надо "усиливать человеческий интеллект, делать людей умнее, ибо это никто не купит. Купят исключение человеческого интеллекта из производственного процесса".

Обобщать и заземлять (мета-модели, вторые и третьи принципы)
В школе и вузе всех учат обобщать, "находить закономерности". Не менее важно и обратное умение, о котором говорят мало: заземлять закономерности более общего характера на конкретные ситуации. Скажем, вы умеете считать -- но когда вас спрашивают, сколько будет два яблока и три яблока, ответ оказывается неведом: общий принцип счёта работает со "счётными объектами", а вас спрашивают про фрукты, которые едят. Отождествить абстрактный "счётный объект" и "конкретный фрукт" -- это только кажется, что легко. Вот вы знаете из руководства по системному мышлению, что в вашем проекте должна быть целевая система (system-of-interest). В руководстве по системной инженерии тоже говорится про целевую систему. А теперь вы смотрите на множество предметов окружающего мира и пытаетесь сказать, что у вас целевая система. А вы, например, работаете в телеком-компании, где "доступ в интернет", или в игровой компании, где "игровой сеанс", или в юридической фирме, где "банкротство" -- что делать тут с целевой системой, она ж должна быть материальна? Это не "умозрительные примеры", это как раз примеры из моего февральского 2026 разбора по первому шагу системного мышления (подробности см. в https://ailev.livejournal.com/1790554.html).

А не сделаешь первого шага системного мышления (подвесишь вопрос "что там у вас за целевая система в проекте" на "когда-нибудь, потом, не сейчас, это трудно"), то сразу будет непонятно, к какой именно системе применять весь материал руководств по системному мышлению, системному моделированию, системной инженерии, все эти огромные знания оказываются неприменимыми в жизни. AI-агенты тоже тупят в этой части, если ими не "порулить" в правильном направлении их неестественно интеллектуальной мысли. Не заземлишь понятие "целевой системы" -- не сможешь быть умным, не сможешь применять лучшие методы мышления, известные человечеству, никакой "системности" дальше у тебя не будет. А свалить определение целевой системы на AI-агента тоже не получится, ибо агенту надо объяснить, над каким проектом он работает и что именно ему в этом проекте надо оптимизировать. Объяснить не на общем уровне "мы тут делаем систему", а конкретно -- "мы должны ускорить предоставление доступа" или что-то типа того.

Занятие каким-то делом требует владения как мета-мета-моделью (наши руководства, или FPF с его первыми принципами), чтобы догадаться, что именно нужно искать на уровень ниже, в мета-модели — и надо хорошо разбираться с предметной областью, ибо в текущей мета-модели нужного может не быть, а нужное может быть в соседней мета-модели (другой предмет), более новой мета-модели (что-то очень современное, до вас ещё не докатилось), вообще в мета-модели не учтено и вам надо расширить мета-модель (это ровно то, что называют "мышлением из первых принципов", когда вы можете шевелить мета-модель, а то и полностью заменять одну мета-модель другой, которая решает проблемы текущей мета-модели). То, что надо кроме знания мета-мета-модели знать ещё и мета-модель (как уровня учебника, так и уровня стандарта предприятия, хоть писаного, хоть неписанного), и что нужна адаптация всего этого мета-знания к конкретной проектной ситуации, НАПИСАНО КРУПНЫМИ БУКВАМИ ВО ВСЕХ РУКОВОДСТВАХ. Вайбкодирование и вайбмоделирование обманчивы в том, что можно избежать всего этого погружения в мета-мета-моделирование, мета-моделирование и выискивание фактов и проблем в контексте проекта. Просто попросить одной строчкой покодировать и помоделировать LLM — и на выходе получить приличный код, приличную модель в предметной области, в которой не соображаешь. Нет, не получится, увы.

Если инженер-менеджер, например, хорошо владеющий мета-мета-моделью, но плохо применяющий другие знания руководств (об уровнях мета-моделирования, о необходимости адаптации по контексту) пойдёт вайбмоделировать в авиацию, то может получиться конфуз с его моделями — самолёт по этим моделям летать не будет, хотя софт у него может навайбкодиться просто огонь. К софту претензий не будет: он будет компилироваться, с хорошей модульностью, но он не факт, что будет решать проблемы. В софте вайб-модельер и профи-программист вовремя заметит проблемы, но в авиационной модели (это та часть, которая в софте обсуждается как product management и отчасти DDD) может несоответствия не заметить.

AI-агент поступает так же, как человек-новичок (знания у которого часто есть, но он не догадывается их задействовать): если на входе есть контекст и выходные тесты, то умная LLM его учитывает, даже сложный контекст. Если на входе контекста нет и выходных тестов нет, то умная LLM его предполагает "наиболее вероятные", а если у вас не прямо вот "наиболее вероятная" ситуация, а чуть-чуть отличающаяся — всё, модель и жизнь разошлись, а вы этого не заметите, ибо не научены обращать внимание на эти объекты. Я всё время сейчас пишу про это: проблематизация интересна тем, что новичок в предметной области проблемы не видит, а профи — видит там, где у новичка "всё в порядке". Если у разных проектных ролей интересы разные, то не факт, что LLM сейчас будет это учитывать в контексте, а в тесты это не попадёт: некому будет вносить это в тесты. Скажем, по Голдратту прибыль можно поделить между клиентом, дав ему меньшую цену, сотрудниками, дав им зарплату побольше, и инвесторами, заплатив дивиденд побольше -- и всё это даже будет выгодно, ибо на более дешёвую цену придёт больше клиентов, на большую зарплату можно иметь сотрудников получше, а дивиденд -- это святое, это же ровно то, зачем вообще затевалось предприятие, без ожидания дивиденда его бы не было! Ну, и какие LLM вот это всё начнут учитывать, если их не ткнуть носом явно в необходимость учёта? Пока же -- кто первым встал, того и тапки. Кто первым дал промпт, в ту сторону прибыль и поделят. Системные промпты, а затем "системный промпт уровня предприятия"? Жизнь покажет, как с этим справляться.

Поэтому некоторое время назад обсуждалась разница между профессиональным кодированием с помощью AI-агентов на работе и вайб-кодированием в pet-projects дома. И то же самое — с моделированием. Тимур Батыршин в чате поддержки рабочего развития писал (https://t.me/systemsthinking_course/35381) "Вот моделирование я надеюсь у резидентов не вайбовое, а по методам из руководств — без нормального моделирования получится грустно" и далее уточнял: "В моей личной терминологии (не претендую на истинность или общепринятость) есть "моделирование при помощи LLM", когда FPF-нормативным или классическим SDLC-подобным способом строим граф трансдукций большей или меньшей формальности и строгости, и гоняем по нему промты и их рабочие продукты. А есть вайбкодинг, когда мы пишем промт, нам агент выдает какой-то слоп, и мы сразу такие "вроде работает, срочно в продакшн!" невзирая на последствия. (я так тоже делаю для каких-то одноразовых вещей, которые мне не важно как работают и быстрее проверить результаты глазами насколько верно — типа конвертации логов LLM из JSON в маркдаун)".

Вайб-кодирование с изучением AI-агентом огромной базы кода тут даёт какой-то ответ на вопрос. Но не даёт ответа на вопрос про то, что это кодирование меняет к лучшему в окружающем мире, ибо вот этот контекст оказывается недоступен. Если вы рулите AI-агентами, то вам придётся "разрулить" и вот этот выход в окружение, организовать вашим агентам глаза и уши, дать руки и ноги -- а пока не организовали, вам надо уметь быть самому этими глазами-ушами, руками-ногами и послами в рабочие команды "от имени и по поручению моей команды AI-агентов". Но на что вы будете смотреть и что вы будете говорить вашему AI-агенту и вашим коллегам? На каком уровне абстракции, как будете убеждаться, что вас поняли правильно? У вас большой опыт говорить так, чтобы вас понимал и AI-агент, и сотрудники? Или есть какие-то проблемы с тем, что вас понимают так, как вы ожидаете? Точность языка существенно связана с осознанным использованием принципов и моделей самого разного уровня абстракции. А ещё с системным мышлением, ибо "система в глазах смотрящего" (инженеры знают про viewpoint и view, а также интересы разных проектных ролей, которые заставляют один и тот же объект описывать для исполнителей разных ролей очень по-разному). Точности языка тоже надо учиться, и точное говорение на одном из уровней абстракции абсолютно не означает, что вы сможете говорить на другом уровне. Скажем, вы разобрались с первыми принципами, а теперь вам надо прорулить роботом, который организует какой-то концерт. Ну, что там надо писать в райдере, и вообще, что такое райдер? Писать не вам, но вы будете долго удивляться, откуда такое внимание к какому-то райдеру. Если вы программист, то чем райдер отличается от SLI/SLO/SLA, сходу скажете? Знание принципов освобождает от знания фактов, но не освобождает от знания предметной области и изучения конкретных ситуаций в этой предметной области.

Разбираться в ограничениях, отделяя возможное от невозможного
У нас в МИМ в руководствах по рабочему развитию вводятся уровни общности/приложимости говорения о мире как классические онтологические уровни (мета-мета-модель, метаУ-модель, метаС-модель, это во всех руководствах, но ещё много разъяснений на эту тему было в семинаре по мантрам/памяткам/промптам/канвам). Я склоняюсь к мнению, что вот эти нулевые-первые принципы примерно соответствуют мета-мета-модели, вторые -- метаУ-модели, третьи -- метаС-модели. "Вертикаль нулевых-первых-вторых-третьих принципов" -- это я жёстко огрубляю/сжимаю, там ведь lattice этих принципов (множественное наследование), а не стек, и уровней отнюдь не четыре -- но я просто свожу это к традиционному стеку онтологических уровней, в руководствах у нас обычно говорится о L0-L4. Нет, это тянет не legacy руководств, это legacy культуры онтологического мышления. Прыжком от неё отойти вряд ли получится.

В классических языках мета-моделирования (чаще всего по онтологической традиции базирующихся на логике) ограниченную их выразительность часто снимают языком ограничений (pun intended). Откуда этот pun? Если брать какое-то пространство всех ситуаций, то значительные области этого пространства соответствуют невозможным ситуациям. Так, изо всех функций только некоторое число функций являются вычислимыми. Изо всех методов только некоторые оказываются работающими. Есть 100500 (на самом деле -- много больше) способов что-то сделать неправильно на один правильный способ. И хорошо бы как-то выгородить заборчиками ту область, где описываются потенциально пригодные для вас ситуации. Ограничения -- они именно про это. "Делить на ноль нельзя" -- ограничение, забор, "не влезай -- убьёт!". Тут важна форма заповеди: "не убий", "не укради". Ограничения, запреты, заборы. Когда я был молодым я страшно возмущался: что это там в заповедях не говорится, что надо, только говорится, чего нельзя? Сказали бы сразу какой-нибудь KPI -- все бы и выполняли. Я был молодым программистом, ничего не знал о законе Гудхарта и хотел скаляра, чтобы к нему оптимизироваться (ошибка!), я не понимал ответа "вот этого что в заповедях -- нельзя, а остальное всё можно", приставал с вопросом -- "что именно можно!?", а сейчас у меня метанойя, я только помню, что мне с этой "заповедной формой" представления знания было некомфортно довольно долго. Но оказалось, что это общемыслительный приём, и так работают физики, математики, computer scientists и теперь так работают даже AI-агенты (лучшие из них, и если им дать достаточно компьюта, а не самые лучшие и самые дешёвые работают так, как я в молодости -- и это тоже надо уметь различать!).

Вот нулевые-первые-вторые-третьи принципы (или мета-мета-модели, метаУ-модели, метаС-модели) и играют роль высказываний-ограничений. Из бесконечно большого набора возможных объектов они выбирают важные и дают их отношения, вырезают из бесконечного мира фантазий какой-то потенциально полезный кусок.

Мне кажется, говорение о мета-моделировании (где моделирование оказывается не просто указанием одинаково понимаемых всеми важных для каких-то ролевых viewpoints объектов, но и указанием ограничений в отношениях этих объектов) более жизненно и инженерно, чем говорение об "уровнях онтологии как таксономии" (или даже не таксономии-иерархии, а lattice со множественным наследованием), ибо в жизни редко говорят о занятиях "онтологической инженерией" (кроме ситуаций моделирования данных для целей интеграции данных), тем более что это просто "нарезка мира на типы объектов, впрок", академическая постановка вопроса "что есть в мире". Моделирование тут явно выигрывает у чистой онтологической инженерии, ибо онтология там только маленькая часть: онтология + принципы + ограничения + спецификации обмена моделями и результатами моделирования. В онтологии (даже навороченном knowledge graph) это просто "вот так", а в моделях ещё и правила проверки соответствия предсказаний модели и жизни. Модель прикладная, то есть для проектной ситуации, модель конкретизируется, калибруется, используется и отвечает не только на вопрос "что есть в мире", но и разные другие вопросы (как оно себя ведёт, чего можно от него ожидать -- работа с ограничениями как раз ход на ответы на дополнительные вопросы). Инженеры продуктивно работают с моделями, а с онтологиями -- ну, классификационные схемы бывают разные, с ними мало что можно сделать (разве что хранить что-то "в супер-пупер рубрикаторе на стероидах", но можно и без рубрикатора хранить, роза ведь пахнет розой, хоть розой назови её и положи в таксон роз, хоть нет).

И вот если вы пытаетесь использовать AI-агента, не разбираясь в предметной области, а также ситуации на предприятии, то вы будете не понимать, какие ограничения этому агенту ставить и как обсуждать те ограничения, которые агент выдвигает сам. Парламент за пять минут принял решение выделить $5 млрд. на строительство правительственного датацентра (потому как никто из депутатов в этом не разбирается) и три часа потратил на дебаты и затем отложил решение о том, в какой цвет покрасить забор вокруг здания парламента (ровно потому, что все депутаты в этом разбираются). Вот ваши агенты работают -- на что вы будете тратить время для этого steering?

Знание развивается прежде всего в терминах ограничений. Скажем, constructor theory как раз про "науку льзя и нельзя", про ограничения. И Theory of Constraints тоже про ограничения (Элияху Голдратт вполне физик по образованию). В какой-то мере FPF как first principles framework -- тоже про ограничения: убирает фантазии, отсекает иллюзии, самоуверенность и фальсифицированные уже теории. Вот это "отсечение ненужного" вполне можно рассматривать и как "сдвиг к нужному". Да, знание теории освобождает от знания фактов (бесконечного списка "вот тут почему-то не работает" и короткого списка "вот тут работает"). Можно тем самым существенно компактифицировать знание. Но в целом надо уметь работать не только с классической теорией (чистые функции, "программа и доказательства эквивалентны" по Curry-Howard), но и с механизмами с эффектами (ввод-вывод у программ, и там сразу другая математика). И неизбежно специализироваться. Даже нейросети специализируются, это тот же inductive bias в их мышлении ("What LLMs Think When You Don’t Tell Them What to Think About?", https://arxiv.org/abs/2602.01689), если их мышление оставить дрейфовать, то разные нейросети дрейфуют в разные предметные области, для которых можно ожидать их специализацию: GPT-OSS favors programming and math, Llama leans literary, DeepSeek often produces religious content, and Qwen tends toward multiple-choice questions. Полезно ли это знание для того, чтобы вы выбрали одну из этих сеток? Если вы отвечаете "да", то у вас в лбу тоже есть нейросетка, и вас могут выбирать по этому же принципу. В какую предметную область дрейфуют ваши мысли, если вам задать невинный вопрос, не подразумевающий какой-то предметности? Как бороться с таким дрейфом? Если речь о специализации, то никак! Это даже полезно. Если хочется "предметной нейтральности", то это может оказаться "дрейф в сторону эпистемологии, онтологии, методологии" (специализации на разбирательстве с предметными областями). Если дрейф явно вреден, то вставляем контуры обратной связи в обучение -- инструктаж, системный промпт, RLHF (обучение с подкреплением по предпочтениям людей-наставников).

Срок годности этого поста (небольшой) и что я буду делать со всем этим знанием
Если вы знакомы с материалом семинара по "Развитию для развитых", то там довольно чёткое указание на все результаты работы ставить срок годности, чтобы вовремя пересматривать. Мне надо ставить срок годности и на мои посты, если следовать этому инженерному процессу. Я не думаю, что этот пост будет актуален долго: всё-таки мы находимся вблизи сингулярности, и хоть Sam Altman пишет, что неизвестно с какой стороны (https://x.com/sama/status/1875603249472139576), я думаю, что во многом уже по ту сторону. Это означает, что AI-агенты быстро-быстро будут получать и доступ к реальному миру (ибо "не дашь доступ, не вложишься, не рискнёшь -- конкуренты прокрутят цикл Бойда быстрее тебя ровно за счёт того, что у них будут AI-агенты с таким доступом"), а ещё они быстро-быстро будут осваивать вот этот новый инженерный процесс. И быстро-быстро будут его улучшать, на базе тех же первых принципов.

Так что я продолжу свои текущие проекты, которые десяток лет назад были направлены на смычку инженеров и менеджеров (эх, ностальгия! но теперь я просто говорю инженер-менеджер, смычка состоялась), а теперь на смычку инженеров-менеджеров живых и не очень живых (причём первые умнеют очень медленно, а вторые -- крайне быстро).

Сейчас содержание руководств МИМ по рабочему развитию (мета-мета-модели) и FPF (первые принципы) совместимы на 80%, при этом отнюдь не всегда FPF лучше и подробней, а руководства отнюдь не всегда точнее онтологически. Моя стратегия сейчас -- сначала докрутить FPF так, чтобы в нём было понятие архитектуры, затем разобраться с принципы-ориентированной-архитектурой (и тем самым модульностью и evolvability) самого FPF, стыком FPF с SPF и даже TPF, и вот тогда уже поработать с доводкой руководств и FPF. Так что я потихоньку описываю МИМ (ибо если не я, то никто), но голова думает про вот эту связку FPF-SPF-TPF. Ибо всё, что я пишу тут про вайб-работу надо как-то сообщить AI-агенту. FPF как раз этим и занимается. Люди вряд ли будут читать FPF (хотя такие отчаянные есть, я точно знаю, они мне пишут про своё чтение время от времени). Инженеры-менеджеры в массе своей будут читать руководства и мои посты и пробовать им следовать. А вот AI-агенты будут читать спецификацию FPF. Одно и то же знание, но другая форма представления, оптимизированная для неестественного интеллекта.

(Comment on this)

Профессиональное кодирование и моделирование против вайб-кодирования и вайб-моделирования
Как появляется технический долг при вайб-работе
Некоторое время назад обсуждалась разница между профессиональным кодированием с помощью AI-агента на работе и вайб-кодированием в pet-projects дома. И то же самое -- с моделированием. Мой тезис в том, что вайб-моделирование -- это по факту моделирование-в-малом, а в контексте моделирования-в-большом -- это мультипликатор вреда целому проекту. AI-агент радикально удешевляет не моделирование, а моделирование-в-малом, которое при переносе в контексты моделирования-в-большом радикально удешевляет мультипликатор вреда целому проекту. Вреда больше, и он наносится дешевле!

Пример: как навайбленная "универсальная колонка" превращается в источник чужих проблем. В организации заводят "универсальную" табличку "Контакты контрагентов". Кто заводит? Это и есть проблема: новичок? "ничейный" (корпоративный, "колхозный") AI-агент по поручению другого AI-агента? целая команда разработчиков под давлением недостатка времени? Если у модели нет владельца смысла и режима изменений -- она обречена стать помойкой, хоть с AI-агентом, хоть без.

В этом месте и работают "по наитию", вайбят (vibe -- "по наитию, по настроению"): делают колонку `Address` и пишут туда то юридический адрес, то email, то ФИО "контактного лица", то ссылку на сайт, то @username в "мессенджере" (у каждого этот мессенджер или даже социальная сеть будут своими любимыми, о существовании других мысли не будет). Всё, появился технический долг: поле ввели сейчас, а катастрофа будет потом, когда-нибудь -- и не у тех, кто ввёл это поле. Проблема "вайба" в том, что этот технический долг невидим и никаких планов по его искоренению нет.

Санитария: правильные типы правильного уровня общности
Дальше я буду различать уровень общих правил и принципов моделирования для всех предметных областей (мета-мета-модель, FPF как First principles framework), уровень типовых моделей предметных областей (метаУ-модель "как в учебнике", SPF как Second principles framework) и уровень конкретной ситуации в конкретной организации (метаС-модель "как в ситуации", TPF как Third principles framework). Это нужно, чтобы понимать, на каком уровне общности мы говорим о контексте и где должны жить проверки, ибо и вы и AI-агент много знаете о мире вообще (мета-мета-модель), но дальше надо знать особенности предметной области (и вы их можете не знать, а LLM в AI-агенте ещё будет как-то знать, хотя может перепутать с каким-нибудь модным подходом из прошлого, а не SoTA из текущего нервного настоящего), а уж особенности организации можете не знать ни вы, ни ваш AI-агент, и это главная засада.

Этот частный провал удобно обобщить в принцип/правило, который работает для любой предметной области, на мета-мета-уровне: "Single-meaning slot": каждое поле/слот в модели должно иметь ровно один тип значения и один смысл в договорённом контексте; смешивание разных видов значений в одном слоте запрещено. Суть этого неочевидна, ибо звучит как "присваивай полям значения хорошо, а нехорошо не присваивай", но это утверждение "принципиально": оно не про конкретную предметную область, а про корректность моделирования с прицелом на моделирование-в-большом (взаимосвязь разных моделей, evolvability целого набора связанных моделей).

Онтологическая инженерия: какие значения вообще существуют в этой предметной области "адрес"? Вместо вайб-моделирования с результатом "поле адреса - `Address`" вводим:
* `postalAddress` : PostalAddress
* `email` : EmailAddress
* `contactPersonName` : PersonName
* `websiteUrl` : URL
* `telegramUsername` : Username

Далее делаем (машинно)проверяемое ограничение (constraint):
* `postalAddress` -- не строка, а структурированный объект (минимум: `country`, `city`, `street`, `postalCode`).
* `email` должен быть не произвольной строкой, а только принадлежащей множеству адресов электронной почты
* `websiteUrl` должен быть не произвольной строкой, а только URL
* ... и так далее, указывая способы проверки ограничения (например, `country` ∈ ISO-3166)

Формат проверяется автоматически, иначе вы сознательно разрешаете случайному мусору маскироваться под "ценные данные, не потеряйте".

Даже если авторы значений в этих табличках буду разные (низовые сотрудники, а не авторы самих табличек), они больше не могут "не заметить", что засунули email в почтовый адрес: они немедленно получат ошибку несоблюдения типов ("круглое в квадратную дырку не засовывают!"). Им это ткнут (с разной степенью точности, ибо строгость проверки в следовании стандартам будет неизбежно разная, как и понимание, что там "главный стандарт"), дальше пусть думают -- ибо голь на выдумки хитра, локальные интересы "вайба" всё равно будут работать, если их не осознавать:
* системы соседей неожиданно требуют "одну строку", для них команда "временно! Только для отладки!" добавляет addressText. Через месяц это становится source of truth, ибо оттуда было удобно брать значения для трёх разных AI-агентов в ходе вайб-программирования: им не сообщили, что это "временно"! Некому сообщить, и они ж не люди, чтобы сообщать!
* пользователям "неудобно", так что они вместо заполнения ставят N/A, -, unknown, “test@test.com”. Формально тип проходит, фактически смысл умер.
* владелец процесса хочет KPI, ему вайбкодят характеристику "заполнено", чтобы получать значения “заполнено 95%”, далее закон Гудхарта заставляет генерировать мусор, чтобы "удовлетворить KPI", смысл опять умер.

И вот это -- самый нижний уровень работы, типы тут -- просто "входной билет", чтобы можно было хоть о чём-то разговаривать. Формальная проверка типов -- гигиена, санитарная проверка, "вымыли ли вы руки перед работой" (а если это не вы, а AI-агент -- то проверка того, достаточно ли умна в агенте LLM или правильно ли вы дали промпт, чтобы эта проверка случилась). Правильные типы не спасают от лжи, они спасают от случайности. Всё остальное -- вопрос стимулов, workflow, наблюдаемости, проверок и всего того, что трудно подвластно пущенному в одиночное плавание AI-агенту в ходе вайб-моделирования.

"Правильные типы" можно навайб-онтологизировать, но можно знать предметную область -- и использовать знание современных методов решения проблем с типизацией (и это надо предусмотреть, LLM в AI-агенте может "знать, но не использовать" без отдельного напоминания в промпте "посмотри SoTA как это сейчас делается"). Так, с ContactPoint есть распространённый паттерн: выделять «точку контакта» как сущность с типом канала (kind) и валидируемым значением (value). На уровне предметной модели это может называться ContactPoint/ReachabilityEndpoint/CommunicationChannel -- имя тут вторично. На уровне общих правил моделирования важно другое: одна сущность моделируется по-разному в разных ситуациях: есть несколько строго типизированных вариантов + явные проверки для каждого + версионирование вариантов и организованный "переезд" (миграции) между версиями этих вариантов + разные views (отображения, нотации) под протоколы для разных интересов разных проектных ролей. Тогда исчезает соблазн делать "универсальные поля" и называть все сущности сверхобобщениями с одинаковыми именами для самых разных типов этих сущностей.

Инварианты: чеклисты того, что вы будете проверять при любых изменениях
Типы -- это входной контроль. Но чтобы модель жила в непрерывных изменениях (а она будет изменяться!), нужны правила, которые переживают эти изменения. Инварианты -- это наши чеклисты, conformance checklists. Их можно включать в проверки при изменениях -- и если какое-то изменение нарушило инвариант, оно не проходит.

Дальше делаем инварианты уровня уже не мета-мета-модели (что должно быть истинно всегда, то есть ограничение, которое сохраняется при любых изменениях как модели, так и данных во всех предметных областях), а мета-модели (предметной области):
* инвариант целостности контактного адреса контрагента: Для каждого объекта `CounterpartyContact` все поля имеют значения своего типа; перегрузка/overloading (несколько типов значений для одного поля) невозможна.
* инвариант экспорта контактного адреса: в экспортируемом (которое для обмена данными) представлении контактного адреса запрещены “универсальные строки” как конкатенация строк-значений из полей, возможны только строки значений, разнесённые по полям и прошедшие проверку целостности. "Универсальные строки" допустимы только как views/проекции для объекта `CounterpartyContact`, а не как "источник истины".

А дальше надо говорить о спецификациях обмена и совместимости, без этого никак! Именно этот шаг часто пропускается при вайб-моделировании. Протокол обмена и совместимости -- это какие сообщения считаются корректными для импорта/экспорта, какие изменения формата считаются совместимыми, и как переводим старые данные в новый вид. Это про использование онтологии, принципов, инвариантов. Скажем, "Сформированное сообщение контрагенту считается корректным, если: есть counterpartyId и есть хотя бы одно из полей адреса для каналов связи: email или postalAddress или websiteUrl", иначе это "пустой контакт" -- сообщение для такого контакта или отклоняется, или попадает в очередь на "ручной разбор" (в зависимости от процесса). И это тоже можно замерять для оптимизаций: например, "доля сообщений, улетевших на ручной разбор".

Даже после всех введённых ограничений и инвариантов будет то, что нельзя свести к полностью формальной и "умозрительной" (без выхода в реальный мир) "проверке типов", ибо в жизни много сбоев случается не только из-за типов, но ещё из-за неправильных допущений о текущем сценарии/workflow, интересов ролей, культуры с её иногда абсолютно иррациональными предпочтениями, реализующихся экзистенциальных рисках (вроде "вы тут моете полы на тонущем Титанике"), регуляторике. Например:
* Что считать "достаточно хорошим адресом" для конкретной страны в конкретный период времени (возьмите 20 лет назад, прикиньте, что там будет через 20 лет, если темп изменений сохранится).
* Нужна ли детализация до здания, или надо точнее (квартиры? офиса? рабочего места?), то самое "на деревню дедушке Константину Макарычу" -- а как надо-то?
* Какие сценарии (как happy path, так и epic fail) реально важны, чтобы не пропустить их подробно обложить чеклистами.
* Email может быть синтаксически корректным, но не доставляемым (bounce, блокировки, домен умер, mailbox full).
* Почтовый адрес может соответствовать стандарту, но быть непригоден для доставки (контрагент его выдумал специально так, чтобы вы ему ничего не присылали!).
* Имя человека -- правильное, но не идентифицирующее (однофамильцы, разные языки/транслитерации, смена фамилии).
* ... и много подобного.

Так что "проверяемость" там формальная (синтаксис/тип), семантическая (это действительно то, что вы думаете -- и все это именно так и будут трактовать), операционная (оно работает в процессах: доставляется, используется кем-то, поддерживается и выживает при изменениях). Контроль типов -- это нижний порог, настоящая катастрофа -- семантическая, операционная и организационная проверяемость. У AI-агента проблемы будут именно с этим, именно в этом сейчас нужна помощь людей, занимающих самые разные проектные роли, имеющие самые разные проектные интересы и отсюда самые разные потребности в моделировании (viewpoints). Собственно, "смысл" живёт у ролей, не бывает "осмысленности вообще", это всегда чья-то (агента в роли, то есть у него это "для чего-то") осмысленность. Если у вас "вайб", то вы не можете передать ролевой "вайб" как набор преследуемых интересов LLM, это совсем не "по наитию", это надо уметь делать.

AI-агент может предложить онтологию, принципы, ограничения, сгенерировать тестовые наборы, подсветить аномалии в данных, но не может знать, какие формы контактов реально критичны для ваших процессов без интервенций (действий по изменению в моделях и далее моделируемом мире: опросов пользователей, анализа возвратов писем, провалов доставок, юридических требований и т.д.).

Вайб-кодирование, вайб-моделирование, вайб-письмо -- это ОК, когда вы работаете с самыми начальными идеями. Затем надо повышать точность языка и гарантировать соответствие целям не локального вашего проекта, а общего командного: работать не на "нашу систему, систему моей маленькой команды" (часто -- "команды из себя, любимого, и всё"), но большой команды. Если AI-агент повышает вашу производительность x10, то позаботьтесь, чтобы это была вписанная в коллективную работу производительность, а не x10 производительность по привнесению ошибок в общую работу.

Мало сделать, надо чтобы потом оно ещё и жило и наносило непоправимую пользу с минимальным количеством вреда и постоянной адаптацией к дрейфующим обстоятельствам. Вайб -- это приватизация выгод и сдвиг издержек на окружение. Быстро сделал без заботы о системном целом, без учёта ситуации "разработка-в-большом" -- выгоду получили вы и сегодня, а возникшие проблемы (технический долг, называйте как хотите) оплачивают завтра соседи и "будущий вы". Долги накапливаются, вайб возможен -- но если от "по наитию" (собственно вайба) перейдёте к нормальной разработке.

Моделирование-в-большом против вайб-моделирования
Дома "на одного" всё ОК, "олимпиадное программирование, моделирование", programming/modeling-in-the-small. Проблемы начинаются с программирования и моделирования (онтологизирования тоже!) "в большом", в случае коллективной разработки, а сейчас ещё и коллективной постановки проблем. Я когда-то много об этом писал, вот ещё девять лет назад, в 2017 году "Ключевое тут различие, конечно, "моделирование-в-малом" и "моделирование-в-большом", та же "нептолемеевскость", водораздел между персональным и общественным", https://ailev.livejournal.com/1391038.html (и там ссылки на много других моих постов об этом). Да-да, "нептолемеевскость", где я писал в "" (https://ailev.livejournal.com/1390574.html, 2017):""Человековость", культура, мышление живут "промеж людей", они не центрируются на человеке. "Человековость" оказывается нептолемеевской. С мышлением нужно разбираться не в ситуациях "я сижу и размышляю", а в ситуациях совместного действия. Переходить от сольных танцев ума к более сложным групповым культурным формам. Сначала синергия (увеличение требуемой характеристики за счёт удачного сочетания свойств взаимодействующих объектов, не путать с системным эффектом/эмерджентностью), а потом вверх, вверх по системной холархии -- и вот она, эмерджентность, мы имеем шанс получить новое качество, которого на предыдущем системном уровне не было. Но это трудней, много трудней. Ибо вся сложность сольной работы сохраняется, групповая работа или даже работа всего человечества не слишком облегчает индивидуальный труд".

Сегодня вайб-кодирование является соблазном исключить естественный интеллект, дать ему попить кофе, пока работает датацентр. В случае с использованием FPF это будет чаще всего вайб-моделирование (в машиностроении, в постановке задач для кодирования, в менеджменте, в исследованиях, где угодно за пределами широко обсуждаемого вайб-кодирования).

В случае вайб-кодирования вам просто надо дать достаточный контекст -- и вы получите приличный код. Если этот контекст уже есть в виде кода, то вам счастье. Если контекста недодали, то программа будет работать, но не будет решать поставленную задачу (ибо "телепать контекст на расстоянии" не может ни человек-кодер, ни машина-кодер, никакая телепатия тут не сработает). То же происходит с моделью. И вы должны дальше понимать, как поставить задачу! FPF вроде как должен помогать делать ровно это. Но беда, если вы не понимаете предметную область: для новичка в предметной области невидимы её проблемы, неизвестно, какие будут важные элементы контекста. Конечно, AI-агент с FPF всё это учтёт, если сообщить. Но это ж надо догадаться сообщить! И тесты: как вы или AI-агент (даже с FPF) догадаетесь, что там должно быть в тестах не только в конкретной вашей предметной области (метаУ-модель), но и в конкретной вашей ситуации (метаС-модель)? А вдруг там "политические расклады", "отсутствие политической воли" и прочее такое? Что делать будете вы, и что делать будет AI-агент (даже если он с FPF)?

Когда табличка при помощи AI-агента делается инженерами или менеджерами, не проходившими резидентуру программы рабочего развития (то есть людьми, не разбирающимися в уровнях мета-моделирования), с типами в заголовках обычно беда, а точность языка нулевая (омонимия, метонимия и всякое такое). Дальше всё, каюк. Табличка есть, а пользоваться нельзя. Тот, кто её делал, хоть как-то пользуется сам (грубо говоря, в поле "адрес" пишет, например, фамилию, почему бы и нет! "На деревню дедушке Константину Макарычу" как раз вот это самое!). Проблема начинается, когда каждый такой сотрудник себе навайбкодил мета-модель (шаблон таблички -- это ведь мета-модель), а потом они обмениваются моделями (заполненными табличками), и имена колонок в них всех -- сверхобобщения, например, и это только одна из типовых ошибок моделирования, "не та лексика" (метонимия: вместо таксона низкого уровня называется имя таксона высокого уровня, вместо "мыши" пишут "зверь"). И всё, тут каюк. Появляются отдельные файлики, описывающие структуру хранения и схему данных (ибо из коллективно используемых табличек это вычитать невозможно), но они тоже у каждого в своём формате и интерпретируют смысл по-своему, исходя из интересов проектной роли. Потом делается заявление, что давайте навайбкодим каждый свой переходничок, а формат неважен -- и у каждого переходничка будет своя хитрая ошибка, вайбкодят и вайбмоделируют ведь непрограммисты.

И это мы ещё не обсуждаем семантику! Только онтологию формата текстового документа.

Раньше люди ошибались медленно, теперь AI-агент без знания нюансов ситуации и надлежащих проверок позволяет ошибаться быстро (поручение выполняет не дни, а минуты или часы в крайнем случае), убедительно (её на это специально тренировали!) и массово (потому что дёшево!). В инженерии "быстрые черновики" -- норма. Вопрос в том, как в инженерии черновики превращаются в надёжные хорошо работающие изделия (даже не информационные модели!).

Парето-фронтир вайб-режима в пространстве проектных ситуаций
Когда речь заходит о том, где AI-агент и вайб-стиль с ним работы помогают улучшить, а где помогают развалить работу, полезнее думать не просто дихотомиями "индивидуальный - коллективный проект", "знакомая - незнакомая предметная область", а в терминах пространства характеристик проектной ситуации. Ситуация тогда моделируется как точка в пространстве этих характеристик. Типовые характеристики как оси для этого пространства (минимально достаточные, чтобы не врать самому себе, что "контекст уже задан и доступен AI-агенту, я ему дам вайб, а он пусть моделирует"):
* Цена ошибки: во сколько может обойтись неверная модель/код (деньги, сроки, безопасность, регуляторика, репутация).
* Наблюдаемость и проверяемость: есть ли быстрые и однозначные проверки результата как "гипотезы", приёмки результата работы, или обратная связь размыта, отложена, получается только "в модели" (а не "в мире").
* Доступность контекста: контекст формализован (артефакты, логи, стандарты) или живёт в головах и “неписаных правилах” (и вы можете даже не знать, что именно надо спросить или померить).
* Сцепленность по интерфейсам: сколько ролей в каких командах, сколько систем должны понимать “одно и то же” одинаково (и сколько невидимых потребителей у ваших результатов "вайба").
* Скорость дрейфа мира: как часто меняются термины, рабочие процессы, модели и базы данных, ожидания, как дорого сохранять совместимость моделей при неминуемых "переездах" с версии на версию ("миграциях").
* Требование к агентности: достаточно "посчитать по данным", или нужно добывать недостающее знание действиями (расспрашивание, зондирование, эксперименты, другие интервенции).
* Неопределённость интересов: насколько конфликтны интересы ролей и насколько трудно выразить это в постановке задачи (договорились ли о характеристиках, по которым определяется итоговое качество решения и о процедурах замера этого качества).

В этом пространстве почти всегда есть несовместимые характеристики, которые нельзя максимизировать одновременно:
* скорость получения результата против гарантий корректности;
* автономность работы против контролируемости последствий;
* универсальность формулировок против однозначности смысла.

Лучшие достижимые компромиссы в этом пространстве обычно формулируются как Парето-фронтир. Парето-фронтир зависит от агента, вокруг которого разворачивается ситуация в проекте. "AI-агент в один запрос" и "команда с дисциплиной (явные слоты, ограничения, инварианты, тесты, версии, миграции + review)" -- это разные агенты, у них разные области оптимальности. Точно так же отличаются человек-новичок и человек-профи в предметной области, независимый AI-агент с вызовом по одному промпту и AI-агент с заранее понятными проверками и workflow, AI-агент с инструментами доступа к данным контекста (репозитории, банки данных, логи, трекеры, протоколы тестов/испытаний) и AI-агент с доступом к реальным людям и реальным датчикам (например, видеокамерам, чтобы понимать происходящее).

Отсюда практический вывод про вайб-режим, работу в режиме "по наитию". Вайб -- это почти всегда выбор точки, где минимизируются человеком элементы "не по наитию", а "через волевое усилие, потому что надо":
* расход на добычу контекста,
* расход на проверку (типовую, семантическую, операционную),
* расход на вписывание результата в коллективные интерфейсы.

В одиночной работе это иногда рационально. В работе-в-большом это превращается в мультипликатор ошибок: каждый оптимизирует под локальный контекст, а платит команда, клиент, инвестор (в разных долях, но платят!). При этом сдвиг на AI-агента не исключает этот "вайб" и у самого агента: неестественный интеллект без специально принятых мер (которые тоже принимаются не "по наитию", не "по интуиции", а по знанию!) вполне может действовать "без протокола", "по наитию" -- своему нечеловеческому "наитию", по своему неестественному "вайбу", по своей нейросетевой "интуиции".

Чеклист быстрой самопроверки (примените его к последнему вашему "вайб-моделированию/кодированию", насколько оно было разумным):
* цена ошибки высокая?
* обратная связь быстрая и однозначная -- ошибка всплывёт у вас сейчас, или ошибка всплывёт у соседей потом?
* контекст документирован -- или существенная часть неотмоделирована, не записана, живёт в головах людей, недоступных для AI-агента местах?
* сцепленность по интерфейсам высокая?
* когда мир вокруг меняется, как удерживается совместимость с переездом на новую версию: вы-то переедете, а остальные как будут это делать?

Если высокая цена ошибки + плохо с доступностью контекста + плохо с проверками + высокая сцепленность -- вайб опасен, сразу работайте "по-взрослому" и имейте для этого квалификацию. Да, это трудно. Но новичок без медицинского образования, который проводит операцию на открытом сердце, нажав кнопку очень умного робота "сделай там всё по уму" может провалить дело даже не из-за незамеченной ошибки робота, а из-за того, что не будет знать, как помыть перед операцией правильно руки, чтобы настроить этого робота, как подготовить пациента к операции, куда потом девать свежеоперированного пациента по окончанию операции, как проверить, что всё-таки прошло правильно -- пациента ведь самого не спросишь об успехе в момент окончания работы робота!

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


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

Сближаем модели с реальностью: интервенции и агентность
На моих семинарах по FPF я тоже подчёркивал, что с ростом знаний FPF удаётся задействовать много более полно. Но это только zero and first principles, а там ведь ещё second principles, "разъезд моделей в коллективе" (моделирование-в-большом) случается ещё и на уровне third principles (в текущих руководствах это мета-мета-модель, метаУ-модель и метаС-модель. Подробно я давал этот материал с уровнями моделей даже не в руководствах, а на семинаре по мантрам, ибо мантры/канвы/уравнения-в-типах как раз с этими уровнями моделирования работают). Сдвинуть всё на роботов, чтобы они думали вместо вас, не получается. Нужна у роботов агентность не такая, как сейчас ("долбиться в одну точку" известной части контекста), а другая -- пойти и сделать какую-то интервенцию, чтобы прозондировать неизвестную часть мира, "снять туман войны" (как в играх, где территория непонятна какая, пока её не исследуешь). Причинное мышление только так устроено, без интервенций/зондирования (активных измерений) -- не работает! Просто визуализацией немного данных добудешь, нужны эксперименты, условия для них надо создавать!

Конечно, в этом направлении международная инженерная и научная мысль работает давно, и работает очень активно, это мейнстрим. А мы выводим на такую работу резидентов (сначала надо, чтобы они перестали глядеть себе в пупок, перестали заниматься исключительно "личным развитием", новый сорт эгоизма, перешли таки к рабочему развитию, затем этот взгляд должен находить какие-то важные объекты внимания -- из первых принципов, то есть на основе мета-мета-модели, но затем надо зондировать, активно добывать информацию, "системное мышление начинается с того момента, когда ты встал со стула и пошёл спрашивать, пошёл делать какие-то действия и смотреть на результаты", я всегда этому учил, многие помнят эти мои слова. Steve Blank в своих книгах писал "идеи для вашего стартапа находятся не в этом здании!", смысл там ровно такой же: вставай и иди, добывай информацию активными действиями. И поставка решения в бесконечном цикле развития для развитых такая же: после получения решения надо собрать информацию, что там произошло в мире с этим решением и вокруг него!

В текущей ситуации AI-агенты пока этого всего не могут делать, агентность там игрушечная, интеллект в существенной мере disembodied, так что сдвинуть на них полностью разработку и кодирование нельзя, для себя, любимого, это ещё как-то будет работать, а в коллективной работе без присмотра со стороны вполне знающих и умеющих людей -- рассыпется. Так что AI-агент (особенно с FPF) помогает, конечно, но не всем -- и очень трудно объяснить, почему не всем. "Из той же мучки, да не те ручки" тут многое объясняет. Senior programmer не вайбкодит, он программирует при помощи AI-агента. С Junior может быть не так, потому как senior заботится не только о коде (это AI-агент позаботится, о коде), но и обо всём остальном -- постановка задачи прежде всего, архитектура. А Junior будет видеть только код, режим олимпиадного программирования "задача на один час, на выходе несколько строк кода, проверка решения автоматическая", programming-in-the-small.

Я сам ведь тоже считаю, что "умозрительно" (языковые модели, "из текстов и картинок, рассуждающие на текстах и картинках") с миром не поработаешь, ибо надо разбираться с эффектами -- делать эксперименты. AI-агент, конечно, шикарная штука, но ему бы руки, чтобы что-то делать, и ноги -- чтобы это делание происходило в нужном месте, а "умозрительно".

Что я имею против вайб-моделирования?
В интернете когда-то бродил мем, что он хорош тем, что никто не узнает, что за компьютером где-то там далеко сидит щенок и участвует в интернет-дискуссиях. Ах, наивные времена. Если в вашем коллективном проекте участвует не щенок, а AI-агент под управлением щенка, ситуация может быть печальнее: у вас будет провал моделирования-в-большом (не путать с кодированием-в-большом, когда AI-агент сможет изучить кодовую базу. В моделировании у вас не кодовая база, а кусок реальной жизни, ваш бизнес. И не факт, что он хорошо отражён в текущих моделях, а добавочка от AI-агента вам правильно отразит ещё неотражённое). Это означает, что основное узкое место: связь с жизнью и интеграция. Даже если AI-агент чрезвычайно умён, он не получит живой контекст бесплатно. Контекст защищён ролями каких-то других живых и не очень живых агентов с их интересами, временем (время -- деньги!) и недоверием, ибо мало ли какие паразиты рвутся к людям и другим AI-агентам забрать информацию, а взамен ничего не дать ни её владельцу, ни проекту в целом. Поэтому ускорение генерации модели без ресурсов на добычу контекста -- это ускорение самообмана.

У вайб-моделирования от AI-агента, вызываемого щенком по принципу "промпти и молись" (prompt and pray) огромные проблемы с заданием нужного контекста, ибо AI-агент получить себе этот контекст сам не может, он ведь в реальной жизни, а щенку неведомо, что туда включать. Сказать, что "вот тебе всё, что я нашёл в мире" -- это дать много мусора, который даст AI-агенту много шума, будет отвлекать, значительная часть времени уйдёт, чтобы разобраться с этим ненужным шумом, в котором вполне может не оказаться сигнала. Щенок выучил промпт (запомнил, что надо делать: нажимать большую красную кнопку с надписью "сделай мне красиво"), а дать важные объекты в жизни не может, ибо не подозревает об их содержании. Не может проверить результат работы AI-агента. Не может оценить, как это влияет на проект, ибо все эти байки Голдратта про "глобальный максимум", руководства МИМ про коллективную разработку и всё подобное ему незнакомы. Не может проверить, появились ли от результатов его работы какие-то проблемы, ибо ненамётанный глаз проблем, которые замечают профи, не видит. Вайб -- это режим, где вот это всё провалено. А если не провалено -- то это не вайб-моделирование, а обычное моделирование с благословенной помощью от AI-агента (и ещё большей помощью от AI-агента с FPF).

Не надо надеяться на чудо, чудеса будут после решения следующих проблем (но не надейтесь на то, что можно дальше ничего не делать, "подождём", ибо вайб-моделируете вы сейчас, а не когда-то потом):
-- коллеги начнут разговаривать с AI-агентами как с людьми. Пока же там расизм: если "чужой AI-агент" припрётся к вам с расспросами по поводу того, как устроены ваши рабочие процессы, то вряд ли вы будете тратить время на подробный разговор. Так что рабочий контекст (ситуация) для даже добропорядочного AI-агента в существеннейшей степени останется недоступен, AI-агент будет работать в платоновской пещере, пытаясь определить происходящее в мире по теням на стене.
-- много агентов будут согласовывать свои решения между собой, чтобы не обращаться к людям. Это коллективная агентская разработка, без неё никуда (хотя уже выяснили, что "гениальность" лучше даёт один сверхсложный агент, но вот масштабирование -- много маленьких агентов попроще, без разделения труда на много специализированных агентов с масштабированием будет сложно).
-- агентам дадут выход в реальный мир, причём не только датчики (видеокамеры), но и возможность что-то прикупить из инструментов, получить доступ (хотя бы на время) к телу робота, чтобы сделать какое-то действие в физическом мире. Без этого не будет ни экспериментов и новых данных для принятия решений, новой проблематизации, ни оперативного исправления самой ситуации -- модели будут оторваны от жизни.

Но если всё это будет, то люди как прокладки между AI-агентами и жизнью нужны не будут. Так что занимайтесь пока честным моделированием, работайте с помощью AI-агента с усилением со стороны FPF, и будет вам (временное, оно всегда временное) счастье.

(Comment on this)

Рок-н-ролл сдвигается с AI-агентов на универсальные приложения (на примере Codex).
Где живёт рок-н-ролл в развитии
Когда-то я спросил Евгения Козловского, который был тогда главным редактором "Компьютерры": почему Компьютерра перестала писать о процессорах, а начала писать о видеокартах? Год назад в каждом номере было пару статей про процессоры, а сейчас ни одной статьи про процессоры, зато по паре статей о видеокартах! Давайте вспомним, что это был за период. Back when Nvidia was founded in 1993, there were a staggering 80 companies making graphics chips, Huang explained in his keynote at the SC11 supercomputing conference in Seattle on Tuesday. "Our idea was: 'Wouldn't it be fun to build graphics chips so we could play video games in 3D?'" he said. "That was it. The entire business plan.", https://www.theregister.com/2011/11/15/sc11_huang_keynote_exascale/, 2011, а рынок AI NVIDIA заметит в 2012 -- ибо он возник от новой характеристики у этих видеокарт: вывода массовых параллельных вычислений на отдельный API, речь тут о CUDA. CUDA - это 2006 год анонс, 2007 год в продукте, и никто не считал это важной характеристикой, ибо это не было на Парето-фронте видеокарт для видеоигр, это была попытка открыть новый Парето-фронт для компьютерного инженерного моделирования. Широким массам это было неинтересно, но вот дальше случился AI и CUDA оказалось ключевым фактором взлёта NVIDIA. Всё это с великой судьбой видеокарт в целом и NVIDIA в частности в развитии AI на тот момент было ещё неизвестно, но компьютерная пресса на них уже переключилась, и это было любопытно.

Ответ Козловского мне был в том, что рок-н-ролл новостей из процессоров ушёл: они развиваются строго по расписанию, гонка мегагерц происходит, архитектурно там всё устаканилось, новых характеристик не появляется (они появлялись! безопасность, интегрированные ускорители с их системами команд и т.д., но это не воспринималось как "новое, существенный прирост потребительских качеств", эти характеристики были понятны только спецам, определялись в специальных бенчмарках, пользователю были невидимы), игроков стало сильно поменьше и нет перспективных возможных лидеров, которые вдруг да выпрыгнут, то есть новостей нет, ибо прогресс идёт по расписанию. О прибытии поездов по расписанию не пишут. А вот с видеокартами всё по-другому: абсолютно разные архитектуры, на первый план выходят разные характеристики, до чёртика конкурентов (десятки! как футбольных команд!), поэтому новости есть -- всё интересно.

Народное внимание, а за ним и новости идут туда, где большая неопределённость с потенциальным влиянием на большое число народу. Валерий Бардин часто мне напоминал, что в России примерно 40 тысяч журналистов, которые имеют те же мозги, что и окружающий их народ, отличаются они только тем, что не молчат, а пишут, так что это 40 тысяч датчиков того, что находится в мозгах у населения в целом. Ничего не меняется, если это блогеры по тематике AI. Писать они будут про exploration в техноэволюции, а не про exploitation. "Гонка токенов в секунду" -- это временный предмет интереса, как и любая подобная гонка. Известный анекдот, что в паспорте автомобиля Роллс-Ройс в графе "мощность мотора" стояло "достаточная". Все гонки гигагерц, мегапикселей, контекстов заканчиваются ровно вот таким.

Сейчас я бы протрактовал предмет интереса так, что новости кончаются, когда от проблематизации и поиска stepping stone какая-то отрасль переходит к бесконечному поиску решений вместо того, чтобы множить число фронтов, привносить новые характеристики (я об этом подробно говорил на семинаре "Развитие для развитых"). В истории с процессорами и видеокартами они там все с процессорами вышли на Парето-фронт и фронт медленно пополз. А в видеокартах там фронты множились, ибо непонятно было, какой из фронтов потом поползёт. Аналогичные процессы шли в софте: журналы публиковали каждый месяц таблички рейтингов текстовых редакторов (кто помнит WordPerfect?) и электронных таблиц (Lotus 1-2-3, кто помнит?), в них был участник Майкрософт. Майкрософт выигрывал "по очкам": они там сообразили, что по принципам составления этих таблиц надо просто тупо реализовывать все фичи, чтобы получить первое место. Качество фич было неважным, количество -- важным. У кого больше ресурсов на большее число фич, тот и выиграл. Ресурсы у Майкрософта были, он выиграл своими продуктами в каждой категории, занял первое место -- и журналам стало неинтересно публиковать одну и ту же табличку из месяца в месяц. Далее это всё было объединено в MS Office путём предложения cut/paste из чего угодно во что угодно внутри Office. И всё, с этого момента новости на этом фронте немедленно кончились, журналы перестали отслеживать, что там происходит. MS потом обижался: "в народном понимании у нас до сих пор Office 97, но это же не так! Он же абсолютно другой по возможностям!". Да, он с другими IDE сидел на всё том же Парето-фронте как IWE (interactive writing environment).

Оформление Парето-фронта для слоя IWE (сейчас там главным образом IDE)
Ситуация с AI-агентами и IDE (integrated development environment) ощутимо сдвинулась где-то в конце декабря-середине января: там произошла конвергенция (термин этот любит в таком смысле упоминать Tony Seba) довольно большого числа технологий: пришло новое поколение GPU-железа, оно дало новое поколение более умных LLM, эти новые LLM поддержали скоростную разработку своей инструментальной и интерфейсной (к людям и другому софту) обвязки: агентов и приложений с агентами. И это всё для выпуска очень разнообразного, но одного продукта: всё это пока поддерживает workflow для программистов.

Мне кажется, что как раз вот прямо сейчас можно уже думать о поддержке AI-агентами каких-то workflow и в непрограммистской жизни, переходить от IDE к IWE и переименовывать writing на более общее working (не называть же это просто IE -- Integrated Environment, оно же с учётом возможностей выхода в интернет и internet explorer, а имя такого продукта лучше не вспоминать). Приложение с AI-агентом, внутри которого LLM и есть доступ к инструментам вроде Python, браузеров и всёго остального (возможно, где-то во внешнем мире это будут станки с ЧПУ, "слесарные инструменты") начинает обсуждаться как представитель с нового Парето-фронта, так что всё внимание мира направлено сейчас именно сюда.

IWE может поддерживать какой-то более широкий класс процессов, кроме разработки кода, может выходить и в проблематизацию. Даже проблематизация чего-то в реальной жизни существенно отличается по workflow от программистского "написал тест как постановку задачи, написал код, выдал песочницу для экспериментов, кручу теперь в цикле, отлаживаюсь".

Эффекты в real life по сравнению с эффектами в программистской "песочнице в контейнере" требуют совершенно других действий для их характеризации и учёта, совершенно других действий по отладке. Например, чтобы ваш корпоративный софт заработал и начал наносить непоправимую пользу, вам надо обучить его пользователей, чтобы они нажимали кнопки на этом новом софте, а не какие-то совсем другие кнопки, или вообще не нажимали кнопок. Пользователей в "песочницу в контейнере" не запихнёшь, чтобы отладить совместную работу софта и пользователей. И поэтому начинают вылезать совсем другие характеристики инструментария для такой работы (например, "безопасность" как очень широко понимаемая, ибо в техноэволюции паразитизма никто не отменял и атаки паразитов будут неминуемы, равно как всякие вопросы про "чьё это", напомню пост "Мойдодыр и политическая философия интернетвещизма", https://ailev.livejournal.com/1106188.html, 2014). Я об этом тоже говорил на семинаре по "развитию для развитых": вам надо постоянно модифицировать ваш уже давно работающий код, чтобы он решал какую-то вновь появившуюся проблему, ибо ещё и мир дрейфует, проблемы меняются.

На эту же тему любит писать LeCun, говоря о том, что реальный AI должен действовать в мире и наблюдать эффекты. И выхваченный флоридскими авторами из прошлого абзаца кусок FPF бьёт в эту же точку: решение вчерашней проблемы не является решением, "осетрина или первой свежести, или не осетрина". А дальше можно сдвигаться и на другие инженерные процессы, которые не так просто автоматизируются без роботов. И вот тут сегодняшние IDE могут оказаться на Парето-фронте более-менее универсальных IWE как одна из точек. Коммодитизация придёт и на этот уровень.

Каков сейчас новый AI-стек и где в нём рок-н-ролл
С AI сейчас явно происходит сдвиг народного и новостного интереса на вот этот новый AI-стек:
-- LLM (и там сейчас не рок-н-ролл, хотя для спецов скорость изменений всё так же велика, "способность породить нетривиальную идею" как раз тут, способность переобучаться -- тут, и много чего ещё тут так и осталось. Но -- не рок-н-ролл, выход новой модели LLM, новой модели смартфона, новой модели автомобиля -- явления одного порядка, "там опять что-то выпустили, такое же, но чуть лучше, глазом разница незаметна". Но для исследователей разница может быть заметна! На вопрос "сколько будет 2*2" все модели дадут одинаковый ответ, а вот вопрос "что там у нас с квантовой гравитацией, а ну-ка реши его" -- вот тут придётся поинтересоваться, нет ли уже GPT-7 в вашем AI-агенте).
-- AI-агент (и рок-н-ролл сейчас там на пике, но всё так быстро, что эта часть марлезонского рыночного балета пролетела буквально за пару лет, вот прямо сейчас рок-н-ролл уходит -- драйв будет на следующем слое, а эти AI-агенты будут "стандартными кирпичиками" для него, тут будет главным больше вопросы стандартизации -- все эти skills и MCP как раз про эту стандартизацию).
-- AI-приложение, то самое IWE. Пока тут мы видим IDE в плотной привязкой к Git, и это узкопрограммистская история, а программистов только 12% от числа всех инженеров сейчас, и они пытаются пока обслужить сами себя. Но жизнь начинает стремительно меняться и тут.

Сначала все соревновались в разных архитектурах нейросеток, затем у нас случились LLM и в них ярко проявились достоинства архитектуры трансформера, но там ещё были какие-то интересности (диффузионные модели, самбы, мировые модели). Рок-н-ролл оттуда ушёл, когда LLM оказались внутри агентской архитектуры -- и гонка пошла за обвязку: каким образом сделать динамический контекст, чтобы его размер не жал (поэтому новости про RLM -- Recursive Language Model, https://discuss.google.dev/t/recursive-language-models-in-adk/323523 -- прошли почти незамеченными в массовых лентах, это "что-то там внтури, массовой аудитории на пользовательском интерфейсе не видно"), какой tooling добавить, какой RAG добавить, как суметь упихнуть мультимодальность в интерфейс. А что же LLM? По всем бенчам они отличаются на единицы процентов, выход новой модели перестал быть новостью. Да, круто, но важно только для специалистов, а не широкой публикой. Широкая публика по факту не замечает выхода новой модели, простым глазом уже не отследишь, что там стало круче, результат виден только по точным бенчмаркам. А там как с процессорами: больше уже зависит от обвязки, чем от процессора.

LLM сами по себе всё активней и активней в мышлении работают со своим внутренним окружением (tolling), оно пока главным образом "внутрифирменное", во внешний мир их не выпускают по совокупности причин, держат как зверей в зоопарке, как психов в психбольнице (ай, неполиткорректно получилось, замените на sandboxing, containment, supervised environments). Интересно, как меняется способ рассуждений GPT-5.2 Pro со временем. Уже пару дней это выглядит в начале каждого такта диалога примерно та: "ща я поищу в файле. Чёрт, поиск ничего не приносит, как будто файла нет! Но пользователь говорит, что файл есть. Наверное, они там просто не успели отиндексировать большой файл. Правила говорят, что надо использовать поиск, но я лучше прокину это и использую gripgrep. Чёрт, они не установили gripgrep, тогда я по-простецки, grep - и этого мне должно быть достаточно. О, всё нашлось! Да, упомянутые пользователем проблемы там и впрямь есть, но давай я поищу SoTA в интернете, чтобы быть уверенным". Это же прямая реализация поговорки Фарадея: "настоящий физик должен уметь буравить пилой и пилить буравом", с поиском affordances у нынешних моделей всё в порядке. Ещё изменилось то, что теперь присылается сразу правленный файл, хотя это и не запрошено (просится патч) -- и он таки корректно правленный! А вот патч для этой правки иногда страдает (ибо правки делаются в файле, а потом патч создаётся уже из этого файла "творчески").

Рок-н-ролл последние полгода был в агентах: обвязке вокруг LLM. Вот прямо сейчас мне кажется, что эта история "новостей с агентами" подходит к концу. Я делаю такой радикальный вывод по публикации о новых примитивах для долгоидущих вычислений агентов OpenAI -- https://developers.openai.com/blog/skills-shell-tips/. Там решаются проблемы умного поджатия контекста, огромных сроков вычислений, контейнеры для установки какого-то нужного прикладного софта, поддержка skills (и первый этот skill -- "продвинутый пользователь компьютера", то есть умение работать с электронными таблицами). Для чего? Первая фраза там -- We’re shifting from single-turn assistants to long-running agents that handle real knowledge work: reading large datasets, updating files, and writing apps.

По идее, новый Парето-фронт AI-агентов оказывается сформирован, интерфейсные примитивы стандартизованы, далее идёт коммодитизация, а конкуренция и связанный с ней рок-н-ролл оттуда собирается уйти "наверх по стеку". "Новостей в AI-агентах нет, прогресс по плану есть" -- гонка пойдёт за надёжность, безопасность, стандартные интерфейсы и прочие архитектурные характеристики, а не "зубодробительные фичи, вау как круто". Инженеры будут соревноваться друг с другом по малоизвестным широкой аудитории бенчмаркам, а пользователи пользоваться чем-то с Парето-фронта (чаще дешёвым, чем лучшим). Но класс продукта уже понятен, основные игроки ясны.

Дальше должна быть небольшая по времени (ибо в 2026 году всё не быстро, а очень быстро -- сингулярность вроде как уже всполохами за окошком присутствует) гонка приложений IWE, которые являются обёрткой для агентов. Тут интересно, ибо никаких ресурсов не хватает одной компании удерживать всю вертикаль от изготовления чистого кремния до пользовательских приложений (но хотят этого, разумеется, все).

Пример трёхслойного AI-стека Codex
С учётом перехода к новым моделям вроде GPT-5.3 (пока мы видели только GPT-5.3-Codex) становится понятен новый AI-стек. У OpenAI он весь называется Codex, ориентирован пока строго на программистов и представляет собой три абсолютно разных сущности Codex:
-- LLM GPT-5.3-Codex, доступна в разных агентах, а агенты доступны в разных приложениях-оболочках. Модель важна, ибо она даёт возможность "догадаться". Увы, "догадка" не берётся длинным размышлением. Длинным размышлением берётся только проверка догадок. Для более крутых догадок берётся новая более крутая модель. Длинное размышление просто позволяет убрать догадки-галлюцинации.
-- агента Codex, который дирижирует заполнением контекста, системными промптами, размышлениями LLM и управляет инструментами. Агент доступен в приложениях (IDE вроде того же Cursor или VS Code), из web-UI, из интерфейса командной строки.
-- приложение-IDE Codex App, доступное пока только в macOS. По сути, это пользовательский интерфейс к агенту Codex, но он даёт подключения разных инструментов вроде возможности хождения в интернет, использования языков программирования (обычно сейчас это Питон, но не обязательно), организации доступов к файловой системе, микрофону, камерам и прочему окружению. Пока это IDE, но развитие неминуемо даст IWE (у Anthropic уже есть первые эксперименты с Claude Cowork, вот ждём-с такого от OpenAI).

Этого достаточно, чтобы программисты быстро-быстро разрабатывали следующее поколение любого софта, который они придумают. Сингулярность в одной предметной области, но ключевой. И это означает, что рок-н-ролл

Что-то мне подсказывает, что после перехода с чисто программистской GPT-5.3-Codex на GPT-5.3 (это нужно для более крутых идей) в режиме Pro (то есть без ограничений по длине думания, это нужно для "безгаллюцинаций") для текущего стека и решении проблем с операционной системой по безопасной в ней работе (грубо говоря, надо пользовательскую Windows всю превратить в систему версионирования вроде Git) мы окажемся уже по ту сторону сингулярности уже во всех областях.

Дальше рок-н-ролл будет только в мультиагентских историях, перехода от мышления-in-the-small в мышление in-the-large и прихват в этом как мышления людей, так и мышления не очень людей. Коллективные проекты, коллективное мышление, коллективные истории, уход от птолемеевского мышления. OpenAI уже опять и снова интересуется роботами.

Алгоритм выявления того, где рок-н-ролл ещё жив
Можно ли поручить отслеживание всех этих новостей агентам? Почему бы и нет, надо им описать алгоритм на базе гипотез (я аккуратен! у меня в тексте всё только гипотезы!) из этого моего поста:
1. Рисуем технологический AI-стек (много раз это уже делал, вот мой пример из текста "Болваны для искусственного интеллекта", 2017, https://ailev.livejournal.com/1356016.html. Learning Algorithm Platworm там -- это как раз LLM, Cognitive Architecture Platform - это сейчас AI-агент, а IWE и другие варианты специализированных обёрток для AI-агента -- это Application (Domain) Platform, и пометка, что инженерией надо заниматься всего прикладного, а вот AI-агенты это как раз "болваны для искусственного интеллекта" как commodity). Возьмите какой-то более продвинутый вариант, можно упростить (ибо у меня упор был в 2017 году на нижние уровни стека, а сейчас интересны верхние уровни): железо, базовые LLM, агенты с их оркестрацией инструмента, приложения с поддержкой каких-то прикладных workflow, embodiment/роботы, и далее ходы на коллективный и гибридный (люди, роботы, датацентры) интеллект.
2. Берём окно времени (скажем сейчас можно брать 3 месяца, в следующем году месяц, дальше счёт пойдёт на дни -- сингулярность! Поглядите на статью https://www.nature.com/articles/s41467-019-09311-w -- Accelerating dynamics of collective attention, это ещё апрель 2019, уже тогда было заметно, а сейчас и подавно) и замеряем для каждого слоя стека характеристики "разогрева-остывания": скорость появления новых характеристик (скажем, через появление новых бенчей), удалённость этих бенчей от хорошо заметных пользователям характеристик, вариативность архитектур на текущем Парето-фронте, плотность интеграционных релизов (коннекторы, адаптеры, предложение интерфейсных стандартов), работу scaling law (прирост качества от добавки ресурсов). Это характеристики для оценки "новизны как таковой" (она всегда будет) и "видимости новизны широким массам" (а вот это уже про "рок-н-ролл там умер").
3. Дальше можно всё сильно огрубить: собрать для каждого слоя скор "рок-н-ролла" как какой-нибудь нормированный агрегат из замеров характеристик каждого пункта (это против правила "не схлопывай пространство характеристик в скаляр", но пока пренебрежём им) и сравнить значение с предыдущими окнами: если для данного слоя "рок-н-ролл" растёт, то он ещё не ушёл. Если "рок-н-ролл" падает, то ожидаем его роста на следующем уровне выше. Закон эволюции говорит (https://www.pnas.org/doi/10.1073/pnas.1807890115), что рост сложности за счёт увеличения числа уровней неизбежен, новые уровни всегда будут -- и их ожидаем как новое место для роста рок-н-ролла.
4. Проверь по характеристикам внимания: доля заголовков новостей, вакансий в стартапах, инвестиций в стартапы, самих новых стартапов по каждому слою. Сдвиг фронтира и в самом деле идёт, когда рок-н-ролл в предыдущем слое пошёл вниз и это становится commodity, а основная битва за захват рынка и внимание направляются на следующий, более высокий слой. Алгоритмы кластеризации по большим массивам данных уже давно известны, это не так трудно сделать.
5. Не дай инерции себя остановить: обнови стек, добавь новые характеристики, которые всплыли при перемещении на следующий уровень (они обычно отражают новые проблемы, поиск нового Парето-фронта). И обнови лексику всего этого (как видите, лексика с 2017 года, когда я описывал этот AI-стек, поменялась: язык живой, он тоже меняется).

И тут сразу становится понятным, почему вроде "всё развивается", но "новости не обо всём", народное внимание стремится вверх по системным уровням, а вниз оно устремляется тогда, когда где-нибудь в самом низу появляется что-то радикально новое (помните "поколения ЭВМ" с их лампами, затем дискретными транзисторами, затем интегральными схемами, а затем СБИС? И что там было в итоге с компьютерными архитектурами в целом от этих сдвижек?).

Где ожидать рок-н-ролла в ближайшем будущем
Далее темы, которые очень скоро будут главными темами новостей:
-- энергия для компьюта и мощности компьюта, которые могут порвать текущий Парето-фронт с его "не очень быстро, очень материалоёмко и очень энергозатратно" (хотя это всё и кажется сегодня уже решённым вопросом, но гонка ведь не остановится). Собственно, это уже обсуждается: "датацентры в гигаваттах и где брать эти гигаватты", это уже целый год во всех новостях. Об этом пишут даже программисты, хотя их обычно интересуют только новые чипы, но линия "чипы -- датацентры -- где взять энергию" очень прозрачная.
-- роботы, которые ещё толком не сказали своего слова. Мировые модели, многоуровневое управление, рои роботов, а также self-replication (роботы делают станки и собирают из них фабрики, которые и делают роботов, не рожать же им! И где-то в этот цикл будут обязательно включены лаборатории, ибо не одну и ту же модель этим фабрикам выпускать!).
-- разные нейроинтерфейсы, продолжение киборгизации. Зачем носить смартфон в кармане, когда его можно носить в теле?!
-- альтернативные физические архитектуры (вроде квантовых компьютеров) для нейросетевых архитектур. В пределе -- "мы вам по-быстрому соберём физический экспертимент, в котором ваше вычисление пройдёт и быстро, и незатратно по материалам, и без особых затрат энергии".
-- альтернативные источники энергии. Термояд явно не решит всех проблем, и в вот тут вывод датацентров в космос на солнечные батареи -- уже разворачивающаяся история. Продолжение этой истории в ходе на сферу Дайсона, и этот вопрос в разных лентах активно обсуждается как "решаемый сейчас", а не "решаемый через сотни лет".
-- решение "проблем человечества", например, биологическое бессмертие и дальше -- искусственная матка. Раз уж лучшие представители рода хотят делать AI-агентов, но не хотят делать детей, надо отдать это машинам. При этом опять же, вопрос: если на фабрике, то каких человеков выпускать (какой геном, сколько рук-ног, надо ли на всём теле иметь шерсть стредней жёсткости, а под ней ритуальные татуировки "прямо из генов", какой им IQ делать, как подправить имунную систему, вшивать ли в мозг лояльность к властям и первичные навыки каких-то умений на уровне врождённых) и зачем (просто рост популяции биологических особей, но зачем? Купить себе для ухода в старости робота или дорастить ребёнка? И кто будет доращивать, ибо сейчас-то в школу и вуз доращивать по факту отдаём).
-- социальные проблемы никуда при этом не деваются. Даже войны никто не отменял на это время! Остроконечникам и тупоконечникам всегда есть о чём поговорить по душам на языке силы!

Жить в эту пору прекрасную придётся и мне, и тебе. Добро пожаловать в киберпанк сейчас и рибофанк чуть позже, реализовался именно этот жанр, а чуть позже будет и рибофанк с говорящими кошечками и людьми с жабрами.

(Comment on this)

Разбор по первому шагу системного мышления, февраль 2026
Вчера возобновил серию разборов/review по первому шагу системного мышления. Этот шаг подразумевает три поворота мысли:
-- поиск системы как "вещи в физическом мире" (интересует groundingHolon, а не метонимия на разные привязанные к нему объекты -- поведения, описания-эпистемы, характеристики-свойства и т.д.). И вот тут застревают обычно все программисты, ибо они работают традиционно с описаниями и моделями, а вот объект моделирования сам по себе обсуждают редко. Программистов приходит много, поэтому на этом шаге часто застреваем: однозначную референцию получить довольно трудно.
-- ход от "вещи в физическом мире" к системе, то есть разговор о границе, эмерджентности, функциональности по отношению к окружению (и вот тут функциональность описывается как viewpoint клиента, да ещё и value ни разу не "ценность", а "польза" -- и этот тест на "пользу" и отрицательные экстерналии "кому вред" обычно трудно проходится).
-- ход на целевую систему как предмет договорённости в организации: предмет развития. То, чем торгуем, поэтому хотели бы увеличить поток продукта. И тут все трудности, описанные Голдраттом: надо свой интерес заместить общим, "глобальный максимум". Мысль тут трудно работает, ибо сразу понятно: обосновать связь своего маленького проекта с максимизацией выпуска обычно более чем трудно. Но надо! Тут основное -- "договорить всех", проверяем всё лифтовым текстом и разговором про "целевую, нашу и вашу систему".

Было несколько интересных примеров, я на них пробовал новые ходы объяснений.

Так, попался традиционный случай "доступа в интернет", но поскольку говорили с программистом, который знал про семиуровневый стек OSI (https://ru.wikipedia.org/wiki/Сетевая_модель_OSI ), я попытался выйти на обсуждение "доступа" на физическом уровне (там "доступ" к физической структуре -- кабелю, аппаратуре связи и битики в их физическом представлении). Дальше идея была в оттрассировании этого "доступа" затем на всей вертикали, ибо там где-то посередине будет транспорт и вот там уже это будет называться "интернет-доступ", ниже ведь нет "интернета" как следования протоколу. Не обязательно строго OSI, можно "физика → связь → интернет протокол → транспорт по сети → приложение", очень грубо. Всё одно, проявляется проблема чисто программистского образования, когда не учат работе аппаратуры: чем ниже по уровням, ближе к физике, тем труднее рассуждение.

Мы даже не дошли до идеи удержание сеанса, ибо торгуем-то не "доступом" (это ларёк симок торгует "доступами"), а в телекоме торгуют сеансами доступа -- и надо бы различать "удержание сеанса" на уровне "удержания сеанса" физического доступа, сеанса "доступа в интернет" и "сеанса работы с приложением" (скажем "игрового сеанса")! В современных 5G спецификациях «сессия» существует уже на уровне связности — PDU Session. Опять многослойная путаница в лексике, "session" (сеанс) — не только про приложения.

Что тренируем? Внимание к словам: одно слово означает похожее по смыслу, но разное на разных уровнях -- и надо сначала договориться, о каких уровнях протокола говорим. Словесная метка "доступ" не гарантирует, что ей помечен в разных фразах один и тот же объект. Удержать связное рассуждение про "доступ" на многих уровнях невозможно, если не понимать, как эти уровни связаны друг с другом ("не понимать, как работает"), а теория говорит, что без grounding договориться будет нельзя, описания разных уровней, отвязанных от "битов на физическом уровне" легко разъедутся -- и нет другого способа их связать, кроме как сказать, что это по-разному описанные физически представленные битики где-то там, в самом низу. Это общий ход в мышлении, очень трудно понимается.

Ещё интересно было поразбираться с ПИФами, поскольку "ценные бумаги" и вообще фондовый рынок обычно никто не обсуждает по существу, с выходом в физический мир (что такое "фонды"? Это ж "фондовый рынок"? Да, этимология опять ведёт к grounding, к латинскому fundus -- основание, почва, земельное владение, которое потихоньку превращалось во французское fonds publics как бумаги госзаймов, под которыми было золотишко, но потом, дальше это из гос.облигаций перепрыгнуло на вообще любые ценные бумаги, под которыми уже были активы предприятий -- имущество, деньги и всё остальное, часто называемые уже "капитал". Про "имущество" под всеми этими "фондами" (ценными бумагами) смотрите фильм "Деньги других людей", его просмотр в наших резидентурах в обязательной программе). Grounding для ПИФов -- это реальные активы (имущество, в том числе деньги, на которые у кого-то есть юридически обеспеченные права, пусть и через цепочки учётных организаций вроде реестров, депозитариев и даже бухгалтерий, которые учитывают всякие права требования на что-то другое). Дальше уже можно подниматься "от земли": доли в этих правах требования или участия, управляющая компания как исполнитель каких-то работ.

В ПИФах -- не "продажи продукта", это вроде "сервис управления" (за процент!) акциями как "талончиками прав на предприятие" (а предприятие -- вполне вещь!) но процент всегда получает управляющий, он в плюсе всегда, а покупатель что покупает -- он же может купить убыток, формально он не "покупатель" (хотя может быть "покупателем работ по управлению"), он инвестор, который участвует в прибылях и убытках, несёт на себе риски и выигрыша, и проигрыша!

Ладно, если это только управление-сервис, то что там с SLA-SLO, в чём обещание, когда обещать прибыль инвестору невозможно? Мышление идёт тут заученными фразами, а на этих фразах далеко не уедешь, объяснений в них нет, только цитирование законов (при этом я как раз писал этот самый закон о рынке ценных бумаг и поэтому вынужден был подробно разбираться). Обсуждать "выход в физический мир" в этих случаях трудно ввиду незнания предметной области фондового . Знание системного мышления помогает указать на то, что надо взять из знаний о предметной области, но оно же не заменяет знаний предметной области!

Ещё один проект был про банкротство (не первый раз!), и мы опять откатились к "банкрот" -- то есть изменения мира сводились к изменению отношений одного лица, но "отношение" ведь там многоместное! Там трудно, ибо это же обязательственное право, а не вещное -- и гражданский кодекс с обязательствами очень плохо работает (мы когда-то с Виктором Агроскиным и Цереном Цереновым пытались затеять общественную дискуссию о необходимости переработки ГК, ибо информационное право сплошь и рядом обязательственное и там сразу интересные проблемы с grounding. Но они решаемые!). Тут ходы были на молекулярные модели в химии, "из шариков и палочек". Процедура банкроства похожа на химическую реакцию: атомы-лица те же, а вот молекулы после реакции уже другие, меняются "химические связи". Моделировать надо граф обязательств, многоместные отношения!

Процедура банкротства меняет commitment-связи сразу у нескольких участников, а не только «свойство должника». Commitment — то, что имеет режим принудительного исполнения и санкций за невыполнение, а promise — более широкий класс утверждений с последующими ожиданиями исполнения (и ещё там речевые акты, которые надо отличать: не любое содержание обещания реально обещано, и не любое обещанное деонтично). И вот тут оказывается, что нельзя обсуждать одного банкрота, а надо обсуждать и кредиторов как минимум. У них были одни отношения до банкротства, а стали после банкротства другие -- и нельзя считать, что результатом является только банкрот, но не ограбленные кредиторы. Опять же, банкротством часто оформляется рейдерский захват, и концентрироваться на одном банкроте как "был должник, стал банкрот, потом и это почистим" -- нельзя.

Тут ещё у меня в кустах рояль: в FPF я как раз наладил работу с обещаниями: разведение обещаний и долженствования (promise и commitment), актов выдачи обещания (speech act), условий приёмки выполнения обещания и т.д. -- это делалось главным образом для описания разных вариантов сервисов с разведением всяческих в SRE чётко разводимых сущностей -- SLI (измеряем), SLO (целевой диапазон оптимизации) → SLA (если юридически оформляем обещание и вводим последствия за неисполнение), например, см. https://sre.google/sre-book/service-level-objectives/. Это всё очень привычно для интернет-доступа (там же программисты), но вполне можно развернуть и в сторону управления ПИФами, и в сторону проведения банкротств.

Я уже месяц назад исправлял онтологию и лексику сервиса в FPF. Тогда всё закончилось переименованием в ServiceClause и вроде бы проблем стало меньше. Но в R1 у многих оказалась работа с сервисом и FPF говорил на эту тему что-то невнятное. Поэтому я сделал очередные правки в FPF, приведя к большей (хотя и не до конца) совместимости с пониманием сервиса в руководстве по системному моделированию (R6, там оказалось примерно 100К знаков разъяснений по поводу сервиса). ServiceClause стал "содержанием обещания", PromiseContent, всем сразу полегчало (там было больше сотни упоминаний в тексте). В A.6.8 (паттерн повышения семантической точности путём ситуационной распаковки термина "сервис" в набор точных понятий, искоренение метонимии) дополнил онтику вокруг "сервиса", а "нераспакованный" service убрал окончательно (ибо это оставалось ещё как "возможный синоним для PromiseContent", что всех и путало). Вот типовой кусочек из неизбежных диалогов с неестественным интеллектом в ходе такой работы, обсуждаем "результат выполнения обещания": "Имя Outcome тут было выбрано, чтобы учитывать разные варианты обещаного. Например, иногда обещается "проработать 5 минут" (и тогда этот outcome -- работа по оговорённому методу, что происходит в ходе самого оказания услуги, а не потом, тип тут - work по методу), иногда обещается "результат" как то, что появляется потом, и метод неважен (выкопанная яма, а лопатой или экскаватором уже неважно), иногда и одно, и другое (уложенная причёска, но работа не более 20 минут, метод стрижки-укладки, а не парик, а результат уложенные волосы "для званого вечера"). Ровно поэтому слово такое общее. Онтологически, конечно, работа-по-обещанию, результат-работы-по-обещанию и outcome-обещания разные объекты, не должны путаться в лексике. Слова вроде result тут плохи, ибо это чаще результат-работы-по-обещанию, не включает работу-по-обещанию". В руководстве по системному моделированию примеры различий в обещаниях -- “5 минут проработать” vs “яма выкопана” vs “причёска за 20 минут”.

Это всё уже учтено, с сервисом теперь в FPF всё ОК. Брать свеженький поправленный FPF, как всегда, тут: https://github.com/ailev/FPF/.

А следующий разбор/review по первому шагу системного мышления у меня будет 12 марта 2026.

(Comment on this)

Типовые форматы мероприятий программ развития МИМ
Типовые форматы, в которых МИМ ведёт свои программы развития:
* **семинары**, которые приносят новые знания,
* **практикумы**, которые дают какие-то базовые навыки,
* **резидентуры**, которые дают наблюдаемые рабочие результаты,
* **разборы**, которые удерживают качество и предотвращают заучивание намертво незамеченных ошибок.

Это различие по главному эффекту. В каждом формате присутствует и передача знания, и какая-то тренировка, и ожидание результатов, и обратная связь -- но в разных пропорциях.

Все эти мероприятия объединяются в **программы**, различающиеся главным образом по направленности развиваемого объекта: в программе личного развития развиваем самого инженера-менеджера, в программе рабочего развития инженер-менеджер развивает что-то на своей работе, в программе исследовательского развития идёт развитие знания. И всё это пронизано разборами для получения обратной связи (хотя разбор может быть и отдельным мероприятием какой-то программы, не будучи привязанным к практике или резидентуре).

**Семинар**
Семинар -- это традиционная форма знакомства с чем-то новым. Обычно он проходит как заседание, где есть докладчик, рассказывающий новый для всех сложный материал. В МИМ это не вузовский "семинар", который отличается от вузовской же "лекции" тем, что на нём преподаватели проводят разбор заранее подготовленных учебных задач, решаемых студентами (в МИМ серия таких семинаров называлось бы "практикум"). В научных семинарах и семинарах МИМ на вопросы отвечает докладчик, и часть вопросов -- на понимание, но часть вопросов может быть и на проблематизацию излагаемого докладчиком материала. Цель -- коллективное понимание, распространение нового, узкого и малодоступного знания.

В МИМ семинар (иногда идущий даже не пару часов, а целый день -- шесть часов) является основной формой доступа к новым знаниям, которые ещё не вошли в руководства или другие письменные материалы. Это основной формат в программе исследовательского развития.

Часто семинар идёт со слайдами, с появлением AI-агентов используются "слайдоменты" (слайды-как-документ, ибо на них меньше картинок и больше текста). В МИМ слайдоменты семинаров можно использовать и как конспект доклада (его не надо писать), и как материал для AI-агента, так что можно сразу после семинара обсуждать с этим AI-агентом новые идеи, изложенные на семинаре и даже пробовать работать по новым методам, представленным на семинаре. Это контринтуитивно, ибо "слайдомент" в руководствах по подготовке слайдовых презентаций критикуется как плохая практика, в МИМ с этим не согласны, слайдомент тут один из важных продуктов семинара, "раздатка". А через некоторое время новый материал из "слайдомента" попадает уже в развёрнутой форме в руководства.

Но семинар только знакомит с новым знанием, он не тренирует, не направлен на получение немедленного и осязаемого результата в деле. Чтобы оттранслировать это новое знание в какое-то мастерство, потребуется много работы -- практикумы, резидентуры, разборы. Вот вы пришли на концерт и узнали про игру на бас-гитаре. Бас-гитарист продемонстрировал основные приёмы игры, показал воочию результаты, показал как играть в составе ансамбля и даже показал соло. Вы восхитились, но чтобы потом самому сыграть на бас-гитаре, придётся много потрудиться. После семинара, как и после концерта, если вам захочется воспроизвести увиденное мастерство самостоятельно, тоже потребуется потрудиться.

**Практикум**
Задача практикума -- "набить руку" в каком-то навыке, чтобы базовые операции (в том числе и мыслительные) перестали съедать внимание и не казались трудными. Высвободившееся внимание затем можно направить на адаптацию практикуемого метода к самым разным ситуациям его использования. На английском это подход deliberate practice: осознанные упражнения с повторениями на границе возможностей, причём не механические повторения, а нацеленные на исключение ошибок по итогам обратной связи. Практикум отличается от работы, его суть не работа, а тренировка. Гаммы музыкантов, тренинг штриха у художников, тренировки спортсменов, вузовские лабораторные работы -- это всё разные формы практикумов.

Обычно формат практикума хорошо знаком, ибо это один из очень распространённых именно учебных форматов. В разных организациях, которые ведут практикумы, их могут называть по-разному. Часто это "тренинг", если срываешься и тебя убирают из группы -- "челлендж", иногда его называют -- "учебный курс". Форм и названий практического обучения тут огромное разнообразие, например, в школе и вузе вы больше всего занимались именно практикумами, хотя они так и не назывались (а иногда назывались). По целям практикум используется обычно перед тем, как надо где-то в другом месте предъявлять рабочие результаты по базовым навыкам. Так, музыканты играют гаммы для тренировки беглости пальцев, а затем они работают -- и репетиции входят в работу (уж так она устроена), а гаммы остаются уделом музыкальной школы. В основе тут идея "повторяемость и неизменность в основе, адаптация и возможность изменения поведения поверх" -- adaptive expertise, adaptive performance. Основные приметы практикума: малые задания, особое внимание к отслеживанию затрат времени и ритма, регулярные разборы с корректировками.

В МИМ практикум -- это основная форма для программы личного развития. Практикумы толерантны к ошибкам, в них безопасная среда для тренинга, они не связаны с какими-то обязательствами кому-то, только с обязательствами перед собой. В практикумах нет каких-то легко отчуждаемых результатов, основные изменения происходят внутри наших инженеров-менеджеров. Если они не умеют читать (когда-то могли прочесть 20 страниц подряд, а то и 100 страниц какого-то сложного текста, а сейчас одна страница -- "лонгрид", а на второй странице буквы расплываются, смысл ускользает), то единственный тут путь -- начинать учиться читать заново. Это тренировки, повторения, "репетиции". Это мы отслеживаем по таймеру, тратим время, привыкаем к нагрузкам. Это практикум. Походы в качалку с тренером -- это тоже практикум. Выход практикума -- улучшенная версия себя, приобретение какого-то мастерства. Основная проблема -- предъявить можно только своё новое умение, внешний отчуждаемый результат обычно или не виден, или выкидывается за ненадобностью: "учебный проект".

**Резидентура**
Резидентура -- это вы работаете над каким-то внешне предъявляемым результатом. Например, просто работаете на основной работе и получаете эти предъявляемые результаты на этой работе. Нет у работы результатов -- нет успеха в резидентуре. В зачёт идёт не "смотри, как я круто изменился" (это оставьте практикумам), в зачёт идут рабочие успехи.

Или строите своё собственное предприятие с нуля (резидентуры бизнес-акселераторов ровно про это). Или рисуете картины. Или ускоряете выпуск рабочих продуктов. Улучшение не себя, любимого, а чего-то вовне. Этот внешний результат оговаривается с самого начала. На выходе резидентуры, конечно, у вас будет какое-то мастерство, но его надо будет подтверждать не самоотчётом, а вот этим внешним результатом -- это рабочие успехи, успешный стартап, картина-шедевр и т.д. В МИМ этот результат часто называют "шедевр", в средние века это был какой-то результат работы подмастерья, по которому его признавали мастером. Резидентура предусматривает кроме договорённости о выдаче результата ещё и следование регламентам организатора резидентуры, наставничество со стороны организатора, какие-то информационные ресурсы и инструменты трекинга. Результат считается результатом только тогда, когда выполнены некоторые заранее заданные критерии. Например, в резидентуре по системному менеджменту надо предъявить, что какая-то команда не твоих подчинённых начала работать по новому методу, и это была твоя инициатива -- если это предъявляешь как твой "шедевр", то получаешь квалификацию "мастера", если нет -- то считаем, что результата нет, даже если выучил всё руководство по системному менеджменту наизусть и можешь его цитировать.

От практикума отличается ровно тем, что в резидентуру идут уже профи делать свой "шедевр", это "повышение квалификации в выдаче результата сложной деятельности в своём проекте", а не освоение какого-то мастерства с нуля с тренировочным, учебным результатом. Нет, результаты вполне рабочие, и они высокого качества, "шедевр". Основная форма работы наставника -- рассмотрение/разбор/review промежуточных и конечных результатов работы. От стажировки отличается тем, что проект у каждого резидента свой, его не "выдают" -- резиденты сами выбирают, какой они делают шедевр, нет начальника, который выдаёт рабочие задания и требует выдачи часов работы на задачи работодателя.

В МИМ резидентура -- это основной формат программы рабочего развития: 10 резидентур по 6 недель каждая, всего на них в среднем надо будет потратить 600 часов. Вы продолжаете работать на основной работе (даже если вы владелец предприятия, вы же всё равно работаете? ещё и побольше остальных сотрудников!), но проходите последовательно 10 резидентур по 6 недель каждая, тратите на это 600 часов, в ходе которых занимаетесь мышлением и работой согласно наставлениям руководств программы рабочего развития, еженедельно (а не один раз в конце) проходите разбор ваших рабочих ситуаций с наставниками (мастера или даже реформаторы МИМ), чтобы не иметь к концу резидентуры намертво заученные ошибки в понимании руководств. На выходе резидентуры вы демонстрируете рабочие успехи.

Важно, что в МИМ резидентуры имеют для первого их прохождения строго последовательный порядок, они выстроены в единой сюжетной линии в рамках программы рабочего развития. Конечно, можно возвращаться к недопонятому ранее материалу, но мы не рекомендуем "оставаться на второй год". Потом можно неоднократно перепроходить эти резидентуры в произвольном порядке, у нас же бесконечное развитие и нет "выучился и забыл", да и материал руководств регулярно обновляется, жизнь ведь не стоит на месте. Но первый раз рекомендуется идти по резидентурам вперёд и не возвращаться к перепрохождению предыдущих резидентур, пока не пройдёшь все с первой по десятую.

**Разбор**
Разбор/review -- это традиционная форма инженерной работы. У "железных" системных инженеров это может быть архитектурное рассмотрение на архитектурном комитете, у программистов это code review, это может носить и самые другие названия, например "рассмотрение" часто используется, если по итогам разбора не просто выявляются ошибки и мелкие недочёты, но принимается какое-то решение о дальнейшем ведении разработки (design review, code review). Из авиации прихвачен "разбор полётов" -- это тоже review, только по итогам, как и postmortem (причём и postmortem и "разбор полётов" стали уже нарицательными именами и используются во всех предметных областях). Привлечение дополнительной пары глаз всегда полезно для поиска незамеченных самим разработчиком ошибок, разборы используются не только в инженерии.

В МИМ это основной формат работы наставников на практикумах и в резидентурах, эти разборы там происходят регулярно -- один-два раза в неделю, чаще всего в составе небольших групп. Разбираются результаты выполнения учебных тренировочных (личное развитие) и рабочих (рабочее развитие) заданий. Но иногда проводятся разборы как отдельные мероприятия, например, двухчасовой разбор по первому шагу системного мышления -- туда каждый может принести свой проект и получить свою порцию критики. Критика в ходе работы и практики важна, ибо в условиях отсутствия критики в результатах быстро накапливаются ошибки. А результаты -- как осетрина, которая или первой свежести, или не осетрина. Если в результатах много ошибок -- это не результаты!

Разборы развивающий и квалификационный не различаются: вы получаете обратную связь, улучшение результата работы, а ещё оценивается результат, который вы принесли на разбор в части вашей квалификации в получении этого результата -- на каждом разборе, а не на "экзамене в конце". По сути, квалификация и её рост являются у вас индикатором успеха в продвижении в развитии, а не "целевым показателем итога", это снимает многие противоречия между режимами "приносите сырой материал, оценок не ставим" и "а вот теперь экзамен, ставим оценки". На критику "есть же исследования, показывающие необходимость различия режимов "учусь" и "меня оценивают", отвечать просто: у нас развитие, а не учёба. Вы развиваетесь на работе, когда оценивают вашу работу и заодно делают замер вашего мастерства. У нас не школа, у нас мастерская. Замер квалификации в ходе разбора/review -- это замер, а не экзамен. При этом на работе могут и уволить, если принесли на разбор совсем уж плохой результат. В МИМ не уволят, но честно сделают соответствующий замер.

У нас не обучение с оценками, у нас развитие с разборами/review. Постепенно растёт и качество результатов работы и мастерство в методе работы, разборы дают частую оценку. Развитие бесконечно: опытный глаз наставника увидит проблемы даже там, где нетренированный глаз не увидит ничего особенного. В этом и ценность: развитие заключается в непрерывном производстве новых проблем, требующих решения, а не только в получении решений для заранее известного списка решений. Разборы -- это правильное мероприятие для определения проблем в ближней зоне развития (проблем, посильных для решения, но не слишком лёгких).

(2 Comments |Comment on this)

Типовые эффекты от прохождения программ развития МИМ
МИМ работает с 2015 года. За эти больше чем десять лет какие-то шаги развития с ним сделали больше двух тысяч человек. Интересно, что лучшие наши люди (квалификация реформатора, влияние которого на развитие простирается за пределами одной крупной компании) проходили программы развития по нескольку раз в ходе своего стремительного карьерного роста в крупнейших международных компаниях, а также роста своих собственных бизнесов. И вот это "перепрохождение" обычно связывалось с очередным повышением: рабочие задачи становились сложнее и надо было сделать очередной шаг в собственном развитии -- поэтому они выбирали "пройти программу ещё раз". Конечно, содержание наших программ тоже меняется, поэтому они получали не те же знания по второму разу, а новые знания -- но делали это в МИМ. Это для нас лучшее свидетельство того, что программы МИМ достигают своих целей, помогают людям развиваться самим и заниматься развитием во всё более и более интересных и сложных проектах. Речь идёт необязательно о менеджменте, хотя среди наших инженеров-менеджеров много владельцев и управляющих крупных (больше тысячи сотрудников) компаний. Но у нас много и главных архитекторов крупных (например, единорогов) международных компаний. Повторный проход -- это новый цикл практики на материале новых проектов и с новыми руководствами.

Типовые эффекты от прохождения программ развития МИМ звучат неотличимо от того, что сулит "инфоцыганщина", но если присмотреться, это ровно те эффекты, которые даёт и высшее образование в лучших вузах:
* "станешь другим человеком", "будешь лучшей версией себя"
* получишь самые современные знания инженерии и менеджмента
* карьерный рост
* окружающие будут спрашивать "ты это сам придумал, или тебя где научили", а также замечать, что у тебя системное мышление
* получишь уверенность в своём понимании ситуации, как побочный эффект -- начнёшь крепче спать
* кто больше везёт, на того и наваливают: получишь повышение, но справишься с увеличенным объёмом работ и будешь высыпаться.
* окажешься в компании интересных и хороших людей-единомышленников
* не будешь бояться, что тебя заменит AI.

Поверхностно обещания любого развития звучат одинаково: **станешь умнее**, **сможешь лучше работать**, **карьера пойдёт вверх**, **появятся уверенность и элитарный круг общения**. Это не потому, что все «продают воздух», а потому что **язык про результаты неизбежно обобщённый**: он описывает верхнеуровневые изменения в человеке и его работе. Отличие добросовестной программы развития от «магических обещаний» проверяется не декларацией или даже предъявлением результатов (что сработало на одних людях в одних ситуациях вполне может не сработать для других людей в других ситуациях), но предъявлением механизма и способа проверки:
* механизм развития должен правдоподобно вести к объявленным эффектам. МИМ использует learning sciences в своих программах, методы эффективного развития обсуждаются прямо в руководствах: разнесение практики по времени + возвращение к темам (spaced + interleaving), практика на рабочем материале с разбором и корректировкой (deliberate practice + feedback), донесение изученного в руководствах и литературе материала до рабочих проектов (transfer of learning) и множество других приёмов.
* результаты есть, но они получаются трудом. Нет, это не десятки тысяч часов (помним про "10000 часов" достижения мастерства) но сотни часов, требуемые для профессиональной переподготовки, выхода на совсем новые виды работ. Так, начальный проход по программе рабочего развития в среднем (по итогам наших замеров) занимает 600 часов, это вполне сравнимо с затратами времени на вузовское обучение на программах профессиональной переподготовки (там обычно требуют потратить минимально 500 часов). Прохождение программ требует чтения серьёзной (а не научно-популярной) литературы, написания текстов и подготовки моделей, проектной работы. Это отнюдь не всем подходит. Это ровно то, как устроены сильные вузы и сильные профессиональные школы: они не обещают “быстро и без усилий”, а после поступления задают довольно жёсткие требования к режиму. И это для типового случая, когда по программе идут технари. У МИМ есть опыт подготовки гуманитариев, им требуется не 600 часов, а чуть больше тысячи часов, чтобы получить квалификацию "мастера" в программе рабочего развития. Но они после этого свободно общаются с инженерами (чаще всего у нас по этому пути идут HR-директора, которые попали на работу в технологическую компанию).
* проверка, вместо веры: прогресс в развитии определяется по наблюдаемым изменениям (качество постановки проблем, качество решений, способность вести цикл от проблемы до эффекта, устойчивость работы в неопределённости, умение организовать работу не своих подчинённых и т.д.). В группах программ развития МИМ квалифицированию обучается вся группа, включая обучение самоквалифицированию. Поэтому довольно легко получить обратную связь: идёт у тебя развитие, или ты просто думаешь, что развиваешься, а результатов нет. Нет "экзаменов", проверяются результаты на твоей работе, а не учебные результаты.

Те же эффекты можно выразить не так хлёстко, в более инженерной трактовке:
* "Станешь другой версией себя" -- меняется не “характер”, а **набор привычных способов думать и действовать**: как ты замечаешь проблему, как формулируешь цель, как проверяешь гипотезу, как управляешь работами, как общаешься с коллегами (включая AI), как ведёшь себя в условиях постоянной неопределённости. Программы развития дают методы для смены привычных способов думать и действовать на лучшие современные (SoTA, state-of-the-art). Когда человек многократно проходит цикл “новое знание → действие → обратная связь → коррекция” в своей рабочей среде, как раз и получается "другая версия себя", это один из выводов современной когнитивной и образовательной науки (learning sciences).
* "Получишь современные знания инженерии и менеджмента" -- получишь не “пачку знаний”, а сначала **методы быстрого освоения и обновления знаний**: начнёшь обсуждать в явном виде языки описания знаний, методы обращения внимания на важное в ситуациях, дисциплину выдвижения проблем, гипотез по их решениям и проверки решений, привычку жить в реальном физическом мире для проверок, а не полагаться на чисто логические умозрительные проверки. Знания устаревают, ценность лучших вузов в том, что они учат **учиться и переучиваться**, а не просто “знать”, а ценность лучших компаний в том, что их сотрудники тоже непрерывно учатся и переучиваются, чтобы удерживаться конкурентоспособными.
* "Карьерный рост" -- это растёт твоя **пропускная способность** (берёшь более сложные проблемы и решаешь их быстрее) и **надёжность** (меньше хаоса, больше воспроизводимости результата). Плюс появляется понятный сигнал для всех: портфель результатов и репутация в сообществе. Причём то, что ты становишься умнее, это ведь не гарантия должности, а повышение вероятности её занятия. Начинается с того, что круг рабочего общения становится шире, начинает включать в себя высший менеджмент как своей организации, так и организаций подрядчиков и клиентов, но дальше ведь выбор: не всем нравится занимать высокие должности, много людей выбирают занимать должности с интересной работой. Если человек остался на прежней должности, но у него поменялась суть его работы и он убрал много препятствий в своей работе, это не так легко предъявить, как "карьерный рост" -- но это ровно оно, "работа, которую хочется делать" (и если не хочется делать, то это не карьерный рост, а карьерное мучение).
* "Окружающие начнут замечать системное мышление" -- конечно, ибо одна из резидентур ровно этому и учит. Почему люди это замечают? Ты начинаешь демонстрировать **наблюдаемые паттерны** — ясные постановки проблем, связанные с определением целевой системы в сложных проектах, а дальше определение важных объектов в ситуациях, связанных сложными отношениями с целевой системой. Это позволяет быстрее и проще налаживать координацию действий в сложных проектах, даёт ощущение простоты в реально сложных ситуациях. Системное мышление было придумано как раз для того, чтобы упрощать моделирование сложных ситуаций -- вот люди это упрощение и замечают. Это неуловимое “системное мышление” вполне реально освоить за год, вот вы его и освоите: умение выделять целевую систему и её границы, проектные роли и ключевые отношения, строить согласованные с самыми разными ролями системные модели и договаривать всех участников проекта на их основе.
* "Появится уверенность, начнёшь лучше спать" -- это реально происходит, и вовсе не от встроенной в программы МИМ психотерапии (МИМ не занимается психотерапией, МИМ занимается развитием!). Тревога снижается от роста предсказуемости в сложных ситуациях: приходя в совсем новую ситуацию вы уже кое-что о ней будете знать из руководств по программам развития МИМ. Если у вас инженерный процесс, вы будете понимать, как он устроен и какие возможные проблемы в этом процессе, у вас же есть знания руководства по системной инженерии. Если у вас проблемы с операционным менеджментом, проявляющиеся как "вечные пожары", то вы вместо тушения этих пожаров сможете разобраться с источниками этих пожаров и сделать так, чтобы пожары не появлялись (для этого даже не надо быть "главным начальником"). У вас будут знания по тому, как сориентироваться в сложном проекте: что спросить, что проверить, что считать реальным успехом, как договорить всех по поводу трудных и спорных решений, как после решения очередной проблемы вернуться к проблематизации (ибо профи всегда видит проблему там, где посторонний глаз никаких проблем не видит). Уверенность здесь — побочный эффект от умения работать, а не результат психологической интервенции.
* "Получишь повышение — и выдержишь увеличение ответственности и нагрузки" -- так оно и есть, причём речь идёт и об инженерной линии (например, станешь главным архитектором проекта) и о менеджерской линии (увеличится число подчинённых или размер распределяемого бюджета). Мало того, что будут профессиональные знания системной инженерии и системного менеджмента, владение системным мышлением, системным моделированием, методологией, умения чётко делегировать работу (и людям, и AI-агентам). А ещё будут возможности, которые даёт программа личного развития: умение соблюдать режим работы и отдыха, гарантированное выделение времени на физические нагрузки и системный фитнес, усиление памяти за счёт ведения заметок, удержание целей вдолгую. И главное -- программы МИМ предупреждают о том, что после повышения (а то и до повышения, прямо на текущей должности) при демонстрации высокой производительности тебе будут подкидывать и работу, и ответственность, поэтому ты будешь готов к происходящему.
* "Окажешься среди сильных и успешных единомышленников" -- и "окончил Оксфорд", и "работал в Гугле" являются важными маркерами, характеризующими развитие. Окружающие люди, принятые там нормы качества, рабочий язык -- это крайне важно для развития, современная наука прямо подчёркивает роль контекста и культуры в том, как человек развивается, кем становится в профессии. В классе отличников даже двоечники оказываются по своему уровню как троечники в других классах. МИМ тут ничем не отличается, его инженеры-менеджеры тоже дают среду общения повышенного качества по отношению к средним инженерам и менеджерам.
* "Не будешь бояться, что тебя заменит AI" -- тут корректная формулировка не “AI не заменит”, а **ты перестроишь работу так, чтобы AI тебя усиливал**, и даже **ты сдвинешь свою текущую работу на AI, а сам займёшься чем-то более квалифицированным и интересным**. Инженеры-менеджеры сразу получают опыт общения с AI, ибо в программах развития используют усилитель интеллекта и для AI: First Principles Framework (FPF), специальное "Руководство для AI", позволяющее затем общаться с AI на одном языке.

(Comment on this)

Пишу "Руководство по мастерской инженеров-менеджеров"
Мастерская инженеров-менеджеров (МИМ) довольно сложный объект даже сейчас, а дальше будет только сложней -- законы развития никто не отменял, рост сложности за счёт увеличения числа упорядоченных системных уровней неминуем. У меня черновик руководства по МИМ где-то на 400К знаков из уже когда-то написанных постов в блог (ага, zettelkasten работает!). Я занимаюсь им сейчас full time, мультитаскинг удавливаю, так что через несколько дней закончу. Сколько это -- "несколько дней"? Год-два назад у меня выходило примерно 20К текста в день при переписке в тучные дни и 5К текста в тощие дни, если считать, что ничего по сравнению с этим "раньше" не изменилось, то я должен справиться за 20 дней, заведомо до конца февраля. Конечно, в душе я надеюсь, что уже через три дня закончу! Но надежды эти неоправданны, а на помощь LLM надеяться не стоит, тут другая работа. По традиции работы над большими текстами привожу тут самый первый написанный раздел "H.About - О чём это руководство". Критика LLM: "там всё очень неконкретно! Раскрой!". Конечно, всё неконкретно: у меня там ещё 400К знаков конкретности после этого короткого раздела. А пока вот:

Мастерская инженеров-менеджеров (МИМ) — это международная экосистема профессионального сообщества для людей, исполняющих роли инженеров-менеджеров в самых разных процессах развития. Инженер-менеджер также -- общее название квалификации самых разных людей, которые занимаются развитием себя, инженерных систем, знаний о мире, совмещая и инженерное мастерство, и мастерство менеджмента гибридных коллективов людей и AI-агентов. МИМ помогает таким профессионалам развиваться самим, помогает развиваться их AI-агентам (есть форматы, специализированные для AI-агентов), помогает им быть проводниками развития в окружающем мире, изменяя его к лучшему в самых разных рабочих и культурных проектах.

Инженеры-менеджеры развиваются сами и развивают своё окружение, полагаясь на исходящее из первых принципов усиление как собственного интеллекта, так и интеллекта AI-агентов, а также усиление коллективного интеллекта. Так что инженер-менеджер МИМ -- это ещё и название для культурной идентичности, принадлежности к сообществу. От инженера-менеджера не требуется диплома инженера или менеджера, но требуется менеджерская приверженность идее развития и эффективного действия, инженерная приверженность точности в моделировании мира и изменению мира к лучшему.

Инженер-менеджер умеет:
* думать самостоятельно, занимаясь коллективной (люди+AI) постановкой проблем и стратегиями поиска решений этих проблем.
* разбираться с новыми задачами, быстро осваивать новые предметные области, опираясь на собственный сильный интеллект и современную картину мира, а также взаимодействуя с неглупым окружением.
* понимать работу сложных систем (технических, AI-агентов, организаций, сообществ) за счёт сильного системного, рационального, научного и т.д. мышления.
* уметь в составе команды создавать и развивать эти системы — это отличает инженеров;
* организовывать коллективную работу по проекту в условиях неопределённости, помогая команде справиться с неизбежными трудностями — это отличает менеджеров.

МИМ помогает инженерам-менеджерам развиваться в этих направлениях через три основные программы развития, поддержанные как наставлениями в руководствах, так и наставниками (людьми и AI-агентами):
* Личное развитие как серия практикумов — как меняться самому, заботиться о себе и близких, организовать свою жизнь к лучшему, расти как личность. Предмет развития: "я как система".
* Рабочее развитие как серия резидентур — как расти профессионально, чтобы развивать окружающие инженера-менеджера системы как предметы развития: технические системы, людей-сотрудников как системы, AI-агентов, их гибридные коллективы.
* Исследовательское развитие как серия семинаров — как усиливать свой интеллект, чтобы глубоко разбираться в устройстве мира, исследовать и строить точные модели сложных и новых ситуаций, а затем вносить свой творческий вклад в развитие знаний о мире. Объект развития -- знания (теории, модели, языки описания).

В будущем возможно появление и других программ развития (например, художественного/эстетического развития: развитие художественной культуры, эстетики).

Если неразвит сам, то не можешь эффективно развивать ни технические системы окружающего мира, ни других агентов вроде людей, роботов, организаций, ни знания. Если ты не занят изменением мира к лучшему, не получаешь внешние по отношению к себе результаты, то у тебя просто не будет никаких возможностей для бесконечного развития себя, не будет разнообразия проблем, которые ты учишься решать.

Начальное прохождение этих программ занимает год-другой, все эти программы тесно связаны между собой, их знания изложены в отчуждаемой форме специализированных для освоения людьми руководств и опираются на свод знаний, основанный на первых принципах, First Principles Framework (FPF, специализирован для AI-агентов).

В сообществе инженеры-менеджеры помогают друг другу владеть современным инженерным процессом бесконечного развития самых разных систем в своей работе — и одновременно бесконечно развиваться самому, будучи «директором по развитию» как своего окружения, так и себя самого: выбирать перспективные проблемы, задавать критерии приёмки, делегировать исполнение людям, AI-агентам, гибридным организациям, безопасно вводить изменения в эксплуатацию и измерять эффект.

Особенность текущего исторического момента в приходе AI-агентов в состав гибридных команд и гибридных организаций. AI-агенты быстро берут на себя роли низкоквалифицированных сотрудников (исследования это уже подтверждают с начала 2026 года, это уже не "голословные заявления", AI уже влияет на рынок труда), поэтому инженерам-менеджерам надо не останавливаться в своём развитии -- закона "кто не успел, тот опоздал" в карьерном росте никто не отменял.

Инженеры-менеджеры МИМ непрерывно наращивают свой личный (мастерство осваивать новое), инженерный (мастерство изменять мир) и менеджерский профессионализм (мастерство организовывать это изменение мира в коллективном действии агентов разной природы - людей, AI-агентов, организации агентов). Мастерство личной жизни, мышления и действия инженеров-менеджеров требует постоянного обновления: с одной стороны, в любой момент времени они "уже развиты", а с другой стороны -- развитие бесконечно, это не синоним "обучения", где можно сказать "всё, хватит, выучился".

Традиционные ещё в начале 21 века методы работы, которые обычно выполнялись менеджерами и предпринимателями (постановка проблем, выделение ресурсов на решение проблем инженерами) с середины 20-х годов с распространением AI-агентов и роботов оказываются сдвинуты на инженеров, ибо общие циклы развития за счёт автоматизации сильно ускорились в части нахождения решений. Более того, уже началась автоматизация и ускорение не только нахождения решений, но и постановки проблем за счёт использования AI-агентов с замыканием их до полного цикла развития. За счёт удешевления автоматизации (которая сама по себе дешевеет из-за "автоматизации автоматизации") менеджеры и предприниматели вынуждены действовать как инженеры, выстраивая свои процессы озадачивания инженеров как автоматизируемые, воспроизводимые, проверяемые в части их качества. Инженеры же вынуждены организовывать коллективную разработку -- в том числе командами из AI-агентов, становясь менеджерами по отношению к роботам разного сорта. Возникает общая квалификация инженера-менеджера, обладающего сильным интеллектом для быстрого разбирательства с проблемами и задачами из самых разных предметных областей, ускоренной адаптацией к изменяющемуся миру.

Мастерская инженеров-менеджеров (МИМ) занимается "развитием для развитых": в сообщество мастерской приходят уже вполне развитые и опытные инженеры-технари, менеджеры, работники культуры, маркетологи, специалисты по HR и самые разные другие профессионалы. Все эти профессионалы нуждаются в продолжении своего личностного и профессионального роста, продолжении развития, чтобы успевать быть адекватными реалиям современного быстроменяющегося мира. Все они получают в МИМ квалификацию инженера-менеджера: умение делать развитие инженерно (точный язык, воспроизводимость результатов, эффективное масштабирование), умение координировать развитие как коллективную работу людей, роботов, AI-агентов. В МИМ всех членов его сообщества называют "инженеры-менеджеры", подчёркивая неразрывность инженерного отношения к самым разным изменениям себя и мира и менеджерского отношения к координации этих изменений в условиях гибридных организаций из людей и AI-агентов. Инженеры-менеджеры демонстрируют умения:
* точной постановки проблем в формате критериев приёмки их решений,
* стратегирования для выбора стратегии получения портфеля гипотез решений этих проблем
* знают, как проводить бесконечный цикл улучшений решений проблем, но не забывают вернуться к проблематизации,
* могут организовать работу гибридной команды в рабочем проекте.

Инженеры-менеджеры получают в МИМ прозрачную по процедуре и легко воспроизводимую оценку своей квалификации в умении получать результаты с использованием методов мышления и действия, описанных в руководствах по этим программам развития. Чаще всего наши инженеры-менеджеры вырастают в chief operation manager, product manager, tech lead, chief architect, serial entrepreneur. Некоторые из них предпочитают занимать должности в крупных организациях и не отвлекаться от работы, но некоторые мастера становятся наставниками в программах развития МИМ. Наставниками могут быть инженеры-менеджеры с квалификацией не ниже мастера (они должны продемонстрировать, что смогли научить работать новым методом команду не их подчинённых, это цель десятой резидентуры -- по системному менеджменту).

Исходящее из первых принципов науки и инженерии знание о развитии общее, оно относительно новое: большинство результатов было получено менее десятка лет назад, хотя основные идеи были известны очень давно, главный сдвиг тут -- применение всех этих идей и результатов в рабочих проектах, это из исследований вышло в инженерию и менеджмент. Знание о развитии вполне следует теории (open-endedness как бесконечное развитие по линии как проблем, так и решений, quality-diversity как работа с портфелями проблем и решений; stepping-stones как промежуточные решения, открывающие новые области пространства для дальнейшего поиска). Это знание делает инженеров-менеджеров единомышленниками: они разделяют общую картину мира и владеют методами сильного мышления и эффективной по ресурсам работы, описанными в руководствах программ МИМ. И это знание применимо к самым разным объектам в самых разных ситуациях, инженеры-менеджеры умеют его быстро адаптировать.

Развитие идёт как инженерный процесс в гибридной команде (люди + ИИ-агенты). Инженер-менеджер удерживает цикл бесконечного развития в целом для самых разных целевых объектов развития, для самой разной степени автоматизации развития как типовой инженерный процесс: **Обновление портфеля проблем → Проблематизация: ставка на проблему в зоне ближайшего развития → Стратегирование (выход на портфель решений и ставка на конкретное решение) → Проверка решения и его воплощение → Ввод в эксплуатацию → Замер результатов → переход к следующему шагу (обновление портфеля проблем)**.

Наше Руководство по МИМ, которое вы сейчас читаете -- это "путеводитель" (guide, понимаемый как регламент, корпоративный стандарт) по Мастерской инженеров-менеджеров. Руководство описывает устройство МИМ и особенности использования его экосистемы инженерами-менеджерами. Руководство позволяет инженерам-менеджерам понять, чем занимается МИМ, помогает выбрать стартовую программу и формат, оценить требуемую нагрузку и ожидаемый результат.

Важно: руководство по МИМ не заменяет руководства программ развития МИМ и не пытается сжать все остальные руководства в собственное краткое изложение. Руководство по МИМ объясняет логику работы МИМ, культуру бесконечного развития инженеров-менеджеров, пороги входа и критерии успеха в удержании развития, этические вопросы развития.

Ещё важно: если вы ожидаете "краткосрочные курсы", если у вас нет важных для вас рабочих проектов, если нет желания много читать, писать и размышлять -- вам не надо в МИМ. Если вы ожидаете обучения-развлечения, то это не к нам. Если подозреваете инфоцыганщину в нашей терминологии (вроде "сильный интеллект", "первые принципы") -- не к нам, в игру "убедите меня и посмотрим, как вам это удастся" мы играть не будем.

Конечно, у вас очень много вопросов -- в этом коротком тексте нельзя подробно описать, что дают программы развития МИМ и как долго они длятся, какие входные условия, как проводится квалифицирование инженеров-менеджеров, что из упомянутого только "идеология и манифест", а что уже реальность и поддержано технологиями и инфраструктурой, что мы считаем "сильным интеллектом", и те ли это "первые принципы", о которых говорил Элон Маск. Даже "инженер-менеджер" кажется одновременно ролью в развитии, профессиональной квалификацией и названием участника сообщества, что на первый взгляд подозрительно, но оно именно так и употребляется. Поэтому мы и написали руководство по МИМ, чтобы подробно всё это разъяснить.

(1 Comment |Comment on this)

10-я ежегодная конференция МИМ «Современный системный менеджмент и инженерия — 2026»
Ежегодная сверка "какие проблемы стали ключевыми" (проблематизация), "какие методы сейчас работают лучше" (стратегирование) и "что и когда мы собираемся делать" (ресурсное планирование) на материале реальных проектов, исследований и изменений в руководствах и форматах МИМ на десятой ежегодной конференции Мастерской инженеров-менеджеров (МИМ, ранее ШСМ) "Современный системный менеджмент и инженерия-2026".

Конференция состоится 18-19 апреля 2026 года (суббота-воскресенье), офлайн (для спикеров, в офисе МИМ в Москве на Таганке) и онлайн (для всех остальных). Участие бесплатно.

На конференции будут обсуждаться проблемы и современные методы решения этих проблем самой разной инженерией и системным менеджментом, первые принципы и интеллект-стек фундаментальных методов мышления. Наши инженеры-менеджеры будут делиться опытом развития и их самих, и их рабочие проектов, авторы руководств, наставники и сотрудники МИМ будут делиться своими проблемами, стратегиями, планами. Кроме этих успехов изменения себя и мира к лучшему мы обсудим результаты исследований лабораторий МИМ и прошедшие за год изменения в наших практикумах, резидентурах, семинарах, проектных рассмотрениях. "Непрерывные улучшения" (PDCA/POOGI и т.п.) — это база, ничего нового. Новый акцент 2026 года: изменения, связанные с успехами AI-агентов: узкое место всё чаще смещается к постановке проблемы, приёмке и безопасному вводу изменений для решения проблем.

Эта конференция:
— Для практиков, которым важно говорить о развитии инженерно: через проблемы, приёмку результата, измеримость эффекта и воспроизводимость решений.
— Для инженеров, менеджеров, HR и специалистов по развитию персонала (L&D), исследователей и предпринимателей, которые удерживают развитие проектов и организаций в гибридных командах "люди + AI-агенты".
— Для участников программ развития МИМ и тех, кто рассматривает участие и хочет посмотреть культуру МИМ на живых докладах и обсуждениях.

Не приходите, если:
— Вы ждёте «быстрых советов» или "готовых рецептов"
— Вы хотите только “послушать мотивационные выступления”: доклады рабочие, а не мотивационные. Если вам трудно удержать внимание на вот этой строчке, и никакого любопытства она не вызывает, то конференция не для вас: "Обновление портфеля проблем → Проблематизация: ставка на проблему в зоне ближайшего развития → Стратегирование (выход на портфель решений и ставка на конкретное решение) → Проверка решения и его воплощение → Ввод в эксплуатацию → Замер результатов → переход к следующему шагу (обновление портфеля проблем)". Вот это и планируем обсуждать, в самых разных предметных областях (даже если это личное развитие), под самым разным углом.

На конференции выступят инженеры-менеджеры МИМ, члены Русского отделения INCOSE, авторы руководств программ развития МИМ, наставники из числа мастеров и реформаторов МИМ, приглашённые спикеры. В перерывах между докладами можно будет пообщаться в неформальной обстановке, обменяться опытом и получить массу полезной информации от единомышленников, договориться о продолжении обсуждений в клубе и чатах поддержки.

Мастерская инженеров-менеджеров (МИМ, ранее Школа системного менеджмента, ШСМ) — это экосистема создателей самых разных систем, а также частный институт повышения квалификации инженеров-менеджеров. В сообществе МИМ инженеры-менеджеры повышают свою квалификацию по программам личного, рабочего, исследовательского развития. Инженеры-менеджеры -- это инженеры, которые в силу роста масштаба и сложности проектов значительную часть времени тратят на организацию инженерного процесса в гибридных коллективах людей и AI-агентов, а также менеджеры, которые сегодня всё больше и больше должны разбираться в инженерной сути происходящего в их организациях инженерного процесса.

При этом сами определения инженерии и менеджмента довольно широки: инженерией считаем любые изменения мира к лучшему, если они делаются намеренно, "по проекту", а менеджментом -- любые организационные действия в отношении построения инженерного процесса. Более того, мы не отказываем в инженерных и менеджерских умениях даже AI-агентам, хотя до их персонального участия в конференции дело ещё не дошло (но в каждой шутке есть доля шутки).

Так что на конференции встретятся и будут обмениваться опытом и студенты самых разных вузов, и опытные инженеры (из них довольно много системных архитекторов), и состоявшиеся менеджеры, в том числе выпускники MBA, и собственники предприятий -- все, кто занимается "развитием для развитых", то есть бесконечным циклом постановки всё более сложных проблем и предложения для этих проблем всё более конкурентоспособных решений.

МИМ также ведёт корпоративные резидентуры по фундаментальной подготовке кадрового резерва, а также команд топ-менеджеров, которые совместно занимаются развитием своих компаний прямо во время прохождения этих резидентур. Конференция "Современный системный менеджмент и инженерия" ставит вопрос о связи этой фундаментальной подготовки к работе по новым методам мышления и действия с жизнью, с самыми разными практическими ситуациями, в том числе ситуациями задействования AI-агентов.

Масштаб конференции: планируется участие примерно 200 человек, знакомых с руководствами МИМ и использующих First Principles Framework (FPF). Если такого знакомства нет, то доклады могут показаться очень сложными. По итогам докладов инженеры-менеджеры могут поднять оценку степени своей квалификации ("специалист", "практик", "мастер", "реформатор" -- подробнее см. в https://ailev.livejournal.com/1767223.html) или обновить год такой оценки.

Конференция будет проводиться в Zoom, чат обсуждений будет -- чат канала ШСМ в Telegram (https://t.me/system_school), ссылки на участие появятся там. Транслироваться онлайн будут все доклады, видеозапись будет вестись, но мы уважаем желание некоторых участников не делать эти обсуждения открытыми для широкой публики — некоторые доклады не будут опубликованы в записи. Опубликованные видео предыдущих конференций доступны на нашем видеоканале https://www.youtube.com/@system_school, информация о программах личного, рабочего, исследовательского развития МИМ вот тут: https://system-school.ru/.

Программа конференции

18 апреля 2026, суббота
Секция-1 Развитие Мастерской инженеров-менеджеров
Секция-2 Фреймворки первых, вторых, третьих принципов и их использование AI-агентами.
Секция-3 Исследовательское развитие
Секция-4 Личное развитие

19 апреля 2026, воскресенье
Секция-5 Рабочее развитие (двойная сессия)
Секция-6 Системная инженерия (совместно с Русским отделением INCOSE)
Секция-7 Развитие детей, сообществ, развитие культуры.

Приглашаем всех желающих к участию и выступлению на конференции.

Контакты для связи: info@system-school.ru

Если вы хотите стать спонсором конференции — напишите управляющему партнеру МИМ Церену Церенову в Telegram: https://t.me/TserenTserenov или на почту: tserenov@mail.ru или воспользуйтесь формой доната https://system-school.ru/donate
* * *
Содержание конференции можно обсуждать прямо тут в комментах к посту.

XVI рабочая встреча по проблемам системной инженерии Русского отделения INCOSE ожидается 3-4 апреля 2026.

Не забудьте сделать пометки в своих календарях.

(Comment on this)

lytdybr
Вот и до меня дошёл нейрослоп, в arXiv появилась статья со ссылкой на мою работу по системной инженерии и FPF. По содержанию там -- типичное приложение FPF к анализу LLM-проектов, но авторы "не справляются с языком" и свою формализацию так и называют -- FPF (а не "что-то наше на базе FPF"), год публикации FPF вообще ставят 2023 (хорошо что хоть вообще сослались). Вот, полюбуйтесь: "AI-Assisted Engineering Should Track the Epistemic Status and Temporal Validity of Architectural Decisions", https://arxiv.org/abs/2601.21116 (это мне 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, свободно лежит вот тут: https://github.com/ailev/FPF/. Пользуйтесь!

Ситуация с AI-агентами и IDE (integrated development environment) ощутимо сдвинулась где-то в конце декабря-середине января: там произошла конвергенция (термин этот любит в таком смысле упоминать Tony Seba) довольно большого числа технологий: пришло новое поколение железа, оно дало новое поколение более умных моделей, эти модели поддержали скоростную разработку своей инструментальной и интерфейсной (к людям и другому софту) обвязки. Всё это нацелено сейчас на поддержку workflow для программистов, но мне кажется, что как раз вот прямо сейчас можно уже думать о поддержке проблематизации в разработке софта, что существенно отличается по workflow от "написал тест как постановку задачи, написал код, кручу теперь в цикле, отлаживаюсь". Эффекты в real life требуют совершенно других действий для их характеризации и учёта, у меня как раз был последний семинар про это, это ж "развитие для развитых": вам надо куда-то двигать ваш готовый уже код, чтобы он решал какую-то проблему, а мир дрейфует и проблемы меняются. На эту же тему любит писать LeCun, говоря о том, что реальный AI должен действовать в мире и наблюдать эффекты. И выхваченный флоридскими авторами из прошлого абзаца кусок FPF бьёт в эту же точку: решение вчерашней проблемы не является решением, "осетрина или первой свежести, или не осетрина". А дальше можно сдвигаться и на другие инженерные процессы, которые не так просто автоматизируются без роботов. И вот тут IDE могут сдвинуться и на IWE, но в новом понимании этого слова. Я писал про integrated writing environment и ходам на личный и затем корпоративный экзокортекс в "Мышление кодированием в IDE, мышление письмом в IWE" (2020, https://ailev.livejournal.com/1515735.html) -- всё тамошнее содержание по факту реализовано, но вот с "общей памятью для коллективной работы" и стыком коллективного и личного до сих пор концептуальные проблемы, а "работа с 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. Самый главный вопрос обычно -- это определение целевой системы. На этой неделе опять занимались целевой системой ритейла (почитайте комменты в https://systemsworld.club/t/uprazhnenie-nazovi-sistemu/36180, там мне особенно приятна фраза "Мне кажется я за эти пару дней узнал об устройстве компании больше, чем за год работы" -- это обычно для нашей программы рабочего развития). В R5 обсуждали разницу между "разработчиком системы" с масштабом влияния на несколько тысяч человек и "архитектором системы". R5 -- это ведь резидентура по системному мышлению, а разница проясняется в R8, резидентуре по системной инженерии, я давал ссылку вперёд: отличия ролей разработчика с "делегированием разработки" и архитектора с "отслеживанием архитектуры, в том числе отсутствия деградации от изменений в ходе распределённой разработки". А в R8 опять встретилось банкротство, и там обычная засада: смотрят на банкрота как целевого, а что при этом происходит ограбление кредиторов ("Вам были должны? Расслабьтесь, забудьте об убытках, мы объявили должника банкротом и тем самым простили ему долги") забывают. И тут же вылезает, что "должник" может означать абсолютно разные роли: сторону судебного процесса по процессуальному кодексу, "должник в обязательстве перед кредиторами", и "банкрот".

На методсовете мы решили, что я сделаю небольшую паузу в работе над FPF и напишу "Руководство по Мастерской инженеров-менеджеров". У меня накопилось некоторое количество постов, которые я перепишу и организую в общее оглавление. Будет инструкция по устройству и пользованию МИМ. Положим его ко всем остальным руководствам, надстроим над этим AI-ассистента (он у нас называется Aisystant), будут все приходящие и продолжающие получать там ответы на типовые вопросы, главный из которых -- "а оно мне надо?!" и следующий -- "ОК, оно мне надо. А теперь куда, и что?". Удивительно, но после того, как я собрал в кучку мои предыдущие посты, наметил оглавление, дописал какие-то кусочки, получилось уже 400К знаков, это небольшая книжка. Оказывается, про МИМ можно много чего рассказывать! Неудивительно, что все путаются: действительно много всего, раскиданного по разным местам в зачастую устаревших версиях. Так что я некоторое время буду "писать в стол", иногда публиковать тут отрывки, а затем выложу результат в стандартной форме руководства. Раньше мой темп был 20К готового текста в тучные дни и 5К в тощие дни, а сейчас посмотрим. В любом случае, я хотел бы с этим справиться ещё в феврале, а там посмотрим. Сингулярность, она такая -- каждый день что-то новенькое из проблем. А пока чищу фразы с описанием типового цикла развития, вроде "Обновление портфеля проблем → Проблематизация: ставка на проблему в зоне ближайшего развития → Стратегирование (выход на портфель решений и ставка на конкретное решение) → Проверка решения и его воплощение → Ввод в эксплуатацию → Замер результатов → переход к следующему шагу (обновление портфеля проблем)".

Мои рассмотрения/review проектов по первому шагу системного мышления начнутся 12 февраля и будут идти примерно раз в месяц -- по тому же формату, что я опробовал весной 2025 года, содержание изложено в тексте про "барышню-мадам": https://ailev.livejournal.com/1750301.html. Пять человек мини-группа, на два часа в онлайне, чат, слайды, 20 минут моего рассказа, а затем по 20 минут на проект каждого участника. Поскольку люди иногда появляются весьма продвинутые, мы сдвигаемся с первого шага мантры системного мышления на второй, но до третьего шага не помню, чтобы доходили (разве что в режиме "вот дальше вы там подумайте об этом и вот этом". Но особенность формата позволяет участвовать в нём и вообще "с улицы", и такое бывало -- хотя редко, чаще приходили люди, уже хлебнувшие проектной ясности из наших руководств.

Приняли решение проводить XVI рабочую встречу INCOSE RUS по проблемам системной инженерии в этом году 4-5 апреля, а конференцию МИМ по современной системной инженерии и менеджменту 18-19 апреля, готовлю об этом официальное объявление, но вы можете уже отмечать даты в своих молескинах.

(Comment on this)

По итогам семинара "Развитие для развитых в 2026"
Что приятно: наши реформаторы никуда не делись, они с нами!
Вчера провёл семинар "Развитие для развитых", а сегодня ещё и полдня чатился с участниками в чате семинара -- написал в чат много страниц ответов на вопросы.

Удивила большая активность наших реформаторов (и они же -- собственники предприятий), их оказалось добрый десяток среди более чем 60 участников семинара. Они проходили у меня какие-то ранние версии "Системного менеджмента и стратегирования" ещё в виде курсов, часто даже делали пару проходов. Какая там причинность -- самые успешные инженеры-менеджеры делают больше проходов по резидентурам, чем не самые успешные? Или наоборот, кто делает больше проходов по нашим резидентурам, те и становятся самыми успешными? Мне это неведомо, но корреляция есть!

Вячеслав Кунин даже сделал для лучшего усвоения материала семинара пересказ его основных положений, проиллюстрировав несколькими картинками из слайдов: https://medium.com/@veaceslavcunev/инженерия-в-2026-когда-решения-дешевы-а-проблемы-бесценны-05c5d0a6ffbd. Слайды про "оргразвитие", когда "развиваем уже развитое предприятие и уже развитых сотрудников" -- это же как раз для них! Выбор целевой системы -- это же как раз для них!

Новый вид продукта: слайдомент семинара. Использовать как LLM+FPF+слайдомент.
Участники семинара унесли не только видео, но и слайдомент, который надо грузить в LLM вместе с FPF (они согласованы!) -- и затем материал семинара оказывается поддержанным неестественным интеллектом, который можно просить выполнить шаги описанных в семинаре рабочих процессов развития в целом, проблематизации в ходе развития, характеризации в ходе проблематизации. Опыт нового типа продукта -- и он вполне успешен! В чате уже была демонстрация "ответ vanilla LLM" против "ответ LLM+FPF+слайдомент семинара" с указанием проблем от использования AHP (https://ru.wikipedia.org/wiki/Метод_анализа_иерархий ) вместо работы с Парето-фронтом и novelty-quality-diversity. Так что теперь у меня два типа LLM-ориентированных продуктов, которые также могут читаться людьми:
-- First principle framework (FPF, https://github.com/ailev/FPF/), и тут вроде всё ясно.
-- MVP по некоторым совсем свежим темам в формате слайдомента для моего семинара. Удивительно, но это работает! Но доступно только участникам семинара (перевожу: оплатившим за попадание в чат семинара). А что будет не MVP? Ну, потом я просто включу это в состав FPF, планы на эту тему были в https://ailev.livejournal.com/1788706.html

Например, мы поглядели в чате пример (один из участников использовал этот метод, подтвердил, что были все указанные проблемы) такого промпта: "У тебя спецификация FPF в файле, а также слайды семинара по развитию для развитых. Там описана многокритериальная оптимизация с учётом novelty, diversity и quality для портфеля индикаторов - с тем, чтобы выбирать какие-то точки на Парето-фронте. Объясни, какие достоинства и недостатки использования в качестве selector метода https://ru.wikipedia.org/wiki/Метод_анализа_иерархий. Скажем, мы берём четыре критерия и применяем AHP, не обсуждая Парето-фронт, доминирование и всё остальное из алгоритмов open-ended evolution. Какие могут быть проблемы?"

Конечно, это "человекочитаемый слайдомент", и в этом слайдоменте очень много красивых картинок. Но это не слайды, ибо слайды -- не конспект, а у меня слайдомент -- это ещё и подробный конспект. А также учебник. А также может использоваться в работе вот прямо сразу, в первый же день.

Как использовать в работе LLM+FPF+слайдомент семинара? Например, поручать адаптировать и заполнять концептуальные шаблоны, которые были в материалах семинара. Обычный аргумент против системной инженерии: "да, проблем вроде должно быть меньше, но эта ваша системная инженерия -- это огромный накладной расход, вместо того чтобы принимать инженерные решения мы занимаемся этим вашим управлением конфигурацией, инженерными обоснованиями с разработкой программ испытаний. Нет, мы не будем всего этого делать!". Мой ответ на это -- вот эту рутинную часть можно (и нужно!) сдвигать на неестественный интеллект. Если надо адаптировать какой-то концептуальный шаблон (карточку, табличку) к вашей ситуации -- можно просить неестественный интеллект помочь это сделать. Более того, можно просить этот неестественный интеллект помогать заполнять! И тут, конечно, нужен глаз да глаз.

Развитие для развитых: проблемы, решения, архивы, портфели
Нет пророка в своём отечестве, но по теме семинара отписалось множество AI-блогеров (они с этим столкнулись первыми, а до остальных очень быстро докатится). Писали вот прямо вчера-сегодня. Но у них конкретизации нет, что дальше, а у нас на семинаре она была! Надо стать не просто "менеджерами агентов", а "инженерами-менеджерами", подойти к менеджерским задачам инженерно -- и учиться работать с проблемами, которые надо решать, как first class сущностью, перестать возиться только с решениями проблем. Например:
-- "человек с идеями теряется – у него впервые в истории ИТ развязаны руки, он перепробовав всё, не знает из чего выбрать, потому что идей, впервые, не больше чем ресурсов", это вчера в https://t.me/denissexy/11183
-- "Теперь, вместо инженеров, все мы будем скорее решателями вопросиков, менеджерами, если хотите, для своего кодингового агента", это сегодня в https://t.me/knowledge_accumulator/341.
-- если раньше бутылочное горлышко в разработке новых продуктов (в том числе с LLM под капотом) было в разработчиках, то сейчас оно в product managers и engineering leads (не путаем их с бесполезным middle-management в корпорациях). Первые могут нащупать "Что нам нужно делать следующим шагом", а вторые "Как это реализовать эффективнее всего", это три дня назад в https://t.me/llm_under_hood/741.
-- "прожив два месяца с claude code на opus4.5 могу сказать что это ощущается как реальный мидл mle(хороший) причем готовый в три ночи идти писать и ставить метод который я придумал и к утру получить результат", это пару дней назад https://t.me/lovedeathtransformers/10296
-- ... и такого много. Это докатится до других инженерных специальностей очень быстро. Экспоненты, они такие. Всё-таки мы вот прямо сейчас наблюдаем всполохи технологической сингулярности во всех возможных разных трактовках того, что это такое. Восторг.

На семинаре стало понятно, что именно вызывает трудности, что является контринтуитивным. К этим мыслям надо "привыкать", ибо язык и привычки мышления долго ещё не будут отпускать:
-- если у вас один вариант чего бы то ни было, то это неправильно. Мышление по умолчанию должно быть архивами-портфелями, а "один вариант" должен восприниматься как исключение, а не норма. Архив -- это всё, что рассматривали, проверяли, видели (память + следы причин). Портфель -- это выбранное на период (ставки/фокус/бюджет/ответственные). Откуда "период"? Так цикл же! См. например, материал по ссылке на руководство по системному менеджменту, там про цели, стратегирование и циклы (я приводил эту ссылку в чате семинара: https://aisystant.system-school.ru/lk/#/course/systems-management/2023-05-17/8218), там сразу начинается: "Вся деятельность организации глубоко ритмична. Если вы не замечаете повторения у себя каких-то действий во времени (паттернов во времени/ритмов/циклов/cadence), вы что-то делаете не так. Есть два основных метода планирования неожиданных работ:" и дальше про "по прерыванию" и "по опросу", и вот в "по опросу" важно иметь small batch size для того, чтобы успевать, и короткий цикл. И вот на этот короткий цикл должен быть "портфель", а не какой-то скаляр. Мы, кстати, говорили о том, что цикл ускоряется -- и в алгоритмическом трейдинге это уже не трейдер принимает решение, а программа, ибо трейдер с миллисекундными скоростями не работает. Понятно, что так быстро крутить цикл проблем-решений довольно быстро будет уже не человек, человек не справится.
-- если у вас задача выбора, то надо думать о Парето-фронте, а не о скаляре-рейтинге
-- чтобы думать о Парето-фронте, надо думать об индикаторизации (и портфеле характеристик-индикаторов), запрет иметь какой-нибудь скаляр-рейтинг (ладно, не запрет -- но это должен быть явный шаг, и его надо обосновать, ибо проблемы этого шага хорошо известны).
-- Нельзя думать только об индикаторах (оптимизируемых величинах), ибо у вас всё развалится на чём-нибудь ещё. И помнить о законе Гудхарта, https://en.wikipedia.org/wiki/Goodhart's_law
-- характеризация, индикаторизация, нормализация, скоринг, свёртка (агрегация разных показателей в один), сравнение, выбор. Если "выбрать лучшее" -- это конец очень длинной цепочки.
-- novelty -- это tie-breaker, а на stepping stone с этой novelty закладываем долю бюджета: нужно для выхода из локального минимума.
-- надо выбирать goldilock проблемы, а ещё профи-глаз видит проблемы там, где новичок никаких проблем не видит (подумалось, что это что-то типа "А чо такова?" https://ailev.livejournal.com/1653635.html. Но тут немного другой вариант. Как-то университет снял ростовский ледовый дворец для университетского фестиваля. И я там был среди участников, принёс качественную фонограмму на магнитной ленте. Местный звукооператор послушал её -- и сказал, что ставить её не будет, ибо там проблемы с качеством. И для любительства в университетской художественной самодеятельности это качество сойдёт, а у него много тысяч человек и профессионализм не позволяет ему такое качество лить в уши тысячам людей. А я, студент, тогда даже понять не мог -- что ему не понравилось то? Фонограмма была очень высокого качества, не пятая или седьмая перезапись, а всего третья! Вот это оно и есть: вам говорят, что "вашим интерфейсом невозможно пользоваться", а вы говорите, "да шикарный интерфейс!", глаз не замечает проблем).
-- проблемы тоже надо как-то выражать: это делается через портфель индикаторов и критерии приёмки, которые задают "как мы узнаем, что проблема решена". Сказать "решил проблему" или "не решил проблему" -- это результат "измерения решения", а измерение -- это ведь "сравнение", приёмка делается сравнением по набору характеристик.
-- если ты занимаешься инженерным процессом, то включи в него то, с чего там раньше всё начиналось: откуда взялись проблемы, которые решают разработчики. Втащи генерацию проблем внутрь процесса, поддержи инструментально, без этого у тебя не развитие, а "решение кем-то поставленных проблем" (то есть ты чей-то агент, а не принципал).
-- ... и тут я понимаю, что в наших руководствах всего этого очень не хватает. В FPF это есть, но не подробно. В слайдоменте семинара есть, но чтобы научиться надо взять LLM+FPF+слайдомент семинара и попросить научить до такой степени, чтобы самому всё вот это отслеживать. Дальше я это засуну в FPF в более чётком виде, дальше я сделаю новый набор руководств, чтобы перепрошивать мозг инженеров-менеджеров на это новое мышление о проблемах и характеризации. И когда-нибудь будет клипса-наушник с LLM+FPF в ухе, которая будет шептать тебе на ухо про то, что "что же ты опять взял первый пришедший в голову вариант, что же ты не подумал, какие там вообще характеристики нужны".

Последний текст, который я закинул в чат семинара -- это текст про NQD-генерирование шуток, я писал об этом в https://ailev.livejournal.com/1782484.html (после семинара этот пример смотрится совсем другими глазами. Но в этом-то и задумка, чтобы поменять мышление, выработать другой взгляд на мир!).

Новая компьютерная грамотность: какие кнопки нажимать в интерфейсе AI-ассистента
Но неожиданно на семинаре было то, что я для себя назвал "проблемой новой компьютерной грамотности". На предыдущих двух семинарах с LLM все как-то умели работать, а тут пришло больше "просто инженеров и просто собственников предприятий" -- и выяснилось, что понимание фразы "загрузите файлы FPF+слайдомент семинара" отсутствует у очень и очень многих, причём на уровне компьютерной грамотности: "не понимаю, какие кнопочки в каком приложении нажимать, чтобы загрузить файл правильно". Обычно проблемами вроде "ой, я ничего не делала, а файл исчез" занимаются в офисах эникейщики, квалификация, когда такого не происходит и эникейщик не нужен -- "продвинутый пользователь" (то есть "могу поменять стиль абзаца в Ворде и написать формулу для Excel"). Но тут появился новый класс приложений -- и всё, "продвинутый пользователь LLM" оказалось вполне себе навыком. Проблема тут в том, что кнопочки для Linux, Windows, iOS, Android все разные -- и если вместо семинара по развитию отвечать, что "открыть файл в RAG в вашей системе делается вот так, а в вашем приложении вот сяк", то "продвинутые пользователи" будут бузить "где тут тема развития? зачем мы обсуждаем, как работать с LLM?", а непонимающие им будут отвечать "так нам говорят использовать AI, но почему не учат сразу? Непонятно, объясните!". А я как хотел? Я хотел (и продолжаю хотеть) независимости изложения содержания от конкретной операционной системы и выбранного там приложения. Но для этого надо, чтобы участники семинара все понимали "загрузить файл в RAG" против "загрузить текст в контекст". Обидно тратить каждый раз время на объяснение, что не надо упихивать 4MB файл FPF, а ещё и слайдомент семинара в контекст! Их надо грузить как файлы! И проблема в том, что кнопочки для этого у каждого участника свои, и их надо знать! Компьютерная грамотность, дьявол побери! Она сегодня включает умение подгрузить файл в AI-ассистента!

Скажем, вот этот фрагмент был крайне труден в понимании, если нет опыта пользователя чатбота вроде ChatGPT, Gemini или Claude. Я работаю через многократный цикл edit-regenerate первого сообщения, поэтому у меня очень короткие чаты (и их много), а не длинные чаты, которых мало. В web-интерфейсе есть "поле промпта", и у меня чаще всего чат состоит из всего двух реплик "моя реплика" (в поле промпта) и "ответ сетки". И я просто редактирую текущее содержание "моей реплики" (затирая старое и помещая новое) на основе предыдущего "ответа сетки" (а не веду длинный разговор на много реплик). Например, после ответа сетки в ответ на мой промпт "сгенерируй A" я просто беру этот ответ и редактирую свой этот промпт "сгенерируй A", заменяя на "я сгенерировал A, он в тексте ниже. Проверь, по итогам проверки выдай правки на английском в unified diff в code block в четырёх backticks. Вот A: [и дальше просто копия того, что выдала сетка в предыдущем такте]". Пока сетка думает, я копирую этот свой промпт "я написал A, проверь, выдай diff, вот A" в редактор. Сетка в ответ выдаёт diff, и я его накатываю в редакторе на этот A, получив следующую версию. И тут же заменяю промпт на текст из редактора (с уже накаченным diff от предыдущих исправлений, а промпт "я сгенерировал, проверь, выдай дифф" не трогаю вообще). В результате у меня в любой момент времени "один промпт" и "один ответ сетки", один рабочий текст в редакторе, при этом генерация идёт один раз, а затем три раза (или десять раз, по вкусу) идут уточнения при проверке — но результат накапливается в редакторе, в ответах сети только diff-файлы, а не "переписанный текст после правок". Засада в том, что кнопочки у каждого провайдера по смыслу те же, а места кнопочек и особенности поведения — разные, поэтому скриншоты моей работы с одним из приложений не помогут справиться с другим приложением.

Развитие — это циклы постановки проблемы и непрерывных улучшений найденных решений. Я описываю в своей работе, что генерирую текст паттерна FPF, а затем три раза подряд прошу исправить в нём ошибки. Получается текст паттерна, в котором три раза проверены возможные ошибки — и исправлены. Если ошибка в том, что что-то важное недосказано, это ведь тоже "исправление ошибки". В итоге паттерн часто из 20К знаков после исправления ошибок становится 30К знаков. И если там были какие-то "галлюцинации нейросети" в свежесгенерированной версии, то многие из них будут исправлены. Что тут необычного:
— не увеличивается длина диалога (грубо говоря, в чате всегда один ход диалога, ибо я переписываю первый же промпт), поэтому не растёт контекст. Это достигается сменой промпта с "сгенерируй" на "я сгенерировал, проверь и предложи правки"
— нейросеть не накатывает правки сама (не переписывает текст), что много точнее и удобней. Сеть делает только правки в формате diff.
— не "сгенерировал — проверил и исправил", а "сгенерировал — проверил и исправил, проверил и исправил, проверил и исправил" (мало кто догадывается делать проверку и исправление несколько раз).

Вот и всё, ничего больше. Но вот эти шаги "сгенерировал, затем проверил и исправил, затем проверил и исправил, затем проверил и исправил" оказываются почему-то труднопонимаемыми -- и почему я так делаю, и какие кнопки нажимаю, и как можно это всё адаптировать, и в очередной раз -- почему я не пишу сборник промптов для FPF (почему для разговоров с начальником или разговоров с супругой нет сборника промптов понятно, а почему для разговора о мышлении нужен сборник промптов? Сборник промптов по управлению крупным предприятием? Сборник промптов "как стать миллионером"? Откуда вообще идея?!).

На картинке часть собравшихся в нашем офисе на Таганке в Москве:

(Comment on this)

Начинаем февраль 2026: громадьё планов по FPF
Я уже публиковал в нескольких постах разные фрагменты моего плана работ по FPF, а теперь просто собрал все эти отрывки вместе и расположил в более-менее логической последовательности. Конечно, по пути такой огромной работы всплывёт ещё много нового неучтённого -- и всё в жизни будет не так. Планы нужны, чтобы их выкидывать, но их нельзя не разрабатывать! Вот и разрабатываю:

-- сейчас хороший момент, чтобы убрать противоречия с онтологией холонов, методов, работ, ролей (в тексте FPF ещё остались какие-то следы старых вариантов). Без этого дальше будет трудно. Вот прямо сейчас этим занимаюсь: чистка определений в паттернах B.1.5, B.1.6, A.14, A.2, чтобы Method везде был design-time capability, Work везде была run-time enactment, MethodDescription мог быть как step-graph, так и dynamics, solver, quantum-channel или что-то подобное. Как предварительное решение, методы и роли не будут холонами (впрочем, это уже и так в большинстве мест прописано, что это "маски на холонах, сами не холоны"). Также сразу разбираемся с затыками по лексике вокруг "целостности" -- сразу делаем A.6.H. Впрочем, пока писал -- уже всё это сделал.
-- архитектура управления точностью языка, чтобы развить идею восстановления "мутной речи на границе" паттерна A.6.P, где по факту задействовано две разных технологии: routing высказываний о контекстах/границах L/A/D/E и лексическая точность на границе в сигнатурах/отношениях/интерфейсах. Надо вытащить оттуда управление сжатием-разжатием в языке, и я сегодня весь день как раз этим и занимался, там могут быть разные архитектуры. Работаем по норме: предлагаются варианты, ищутся недоминируемые, далее идёт из них выбор. Перед тем как лезть в архитектуру, хочется иметь более-менее универсальную машинку управления точностью/сжатостью разговора. Одна из идей -- это уподобление куска текста LLM, а ситуации -- набору данных, чтобы как-то "прикидывать на пальцах" оценки сжатия, "текст кодирует структуру ситуации" с ходом на "структуру" по линии, намеченной в недавних работах по ML (см. паттерны ML.* в https://ailev.livejournal.com/1787791.html). Это не формализация. Тут можно писать большой пост, ибо написанный мной в несколько заходов промпт для анализа архитектуры управления точностью и сжатостью (это два разных viewpoint: один про провоцирование ошибок и реальные ошибки, другой про длину релевантного высказывания перед ходом на мышление) уже больше, чем весь этот пост. Вот прямо сейчас GPT-5.2 Pro в подрежиме extended thinking размышляет, что там можно было бы сделать в FPF. Ведущие архитектурные характеристики при этом -- evolvability, universality, usability и вычислительная ёмкость повышения точности (скажем, сколько раз надо кликнуть по ссылке, чтобы попасть на нужный фрагмент "одной точки правды" -- это, похоже, ключевое будет, "самодокументируемые имена" вместо "глоссария" или "регистра claimID" именно из этой характеристики растут), а характеристику трудоёмкости переделок я пока игнорирую.
-- после того, как можно будет ткнуть пальцем на точность языка, можно пообсуждать всякие "целостности" (мереологическая "границы и идентичности", интерфейсная как инвариант для внешних взаимодействий, семантическая как смысл внутри контекста и т.д.). Это нужно, чтобы доразобраться с холоническим мышлением: трудные вопросы про холоничность не только систем и эпистем, но и методов, работ, ролей (пока FPF на эти вопросы отвечает очень уклончиво и разнообразно, что верный признак необходимости "распаковки" пересжатой лексики во что-то более точное. В этих всех объектах что там холон и агрегации частей-целых, что "просто алгебра", а что "факторизация стрелок", несводимая к холоничности? Какие понятия пропущены? Можно и так, и сяк -- но как надо? Очень мутное место, там надо делать отдельный набор паттернов для восстановления семантической точности, наподобие A.6.P для семантической точности "на границе". Если уж и начинать систематически подкладывать под рассуждения какую-то математику, чтобы потом рассуждениям можно было как-то доверять, то без этого никак. Надо доделывать часть B, прописывая всё недосказанное про холоны и добавляя всё недосказанное про механизмы и сигнатуры, их алгебры, факторизации стрелок и всё подобное.
-- теперь нам надо уметь описывать инженерные процессы самого разного вида, сложные методы. Поэтому дальше будет TGA, ибо все эти "процессы" сводятся к применению развитого аппарата описания потоков трансдукций (читай: функциональных описаний). Отсутствие развитой характеризации было барьером, теперь можно вернуться к вопросу. И говорить точным языком! Там же от принципов к работе -- а результаты работы хорошо бы измерить и сравнить с тем, что было предсказано по принципам, и вот это всё работа с характеристиками, там это сквозная нить. Есть задание на эту работу, и в этом задании почти 400Кзнаков, предусматривающие генерацию чуть ли не пары десятков паттернов. Это задание надо будет освежить -- и выполнить.
-- теперь надо будет добавить материал по проблематизации (по итогам семинара "Развитие для развитых": в FPF уже хорошо поддержана вторая фабрика -- фабрика решений, а вот первая фабрика поддержана, но недостаточно. При этом уже есть C.22 Problem-CHR, и много чего ещё по линии проблем. Но надо больше!). Как получить план? Как обычно: "В файле у тебя спецификация FPF, которую мы улучшаем, а также слайды для семинара по развитию, в которых описан SoTA-тренд на изменение типового инженерного процесса. Надо понять, чего не хватает в FPF для полноценной поддержки упоминаемых в презентации идей. Понятно, что собственно сам процесс может выразить TGA, но ведь явно не хватает каких-то kinds, mechanism suits и отдельных механизмов в их состав, каких-то наборов viewpoints, чего-то ещё. Надо затем предложить для этих разрывов набор паттернов, который их ликвидирует. Возможно, надо также изменить какие-то уже имеющиеся паттерны в FPF, чтобы было удобней моделировать предложенный в слайдах процесс (если, конечно, процесс этот более SoTA чем то, что уже описано в FPF)". Выдача -- это и есть план (хотя в реальности чуть сложней: надо прогнать пару раз этот промпт, ибо в выдаче будет разное. А потом обобщить результаты нескольких выдач. На выходе где-то до десятка паттернов вроде "F.20 — ProblemCard@Context" (каноническая карточка проблемы). Цель: если уж инженерный процесс обновился, надо переставать изобретать каждый раз идеи проблемы, решения, архива и портфеля со связанными с ними операциями заново, документировать паттерны и анти-паттерны работы с ними всеми. После этого промпт для LLM+FPF вроде "оформи портфель проблем в нашей Jira" должен отрабатывать без особых сюрпризов. Это уже второй вопрос, что тут "прикладное", а что "фундаментальное, из первых принципов". Вроде как все эти понятия достаточно фундаментальные, а вот конкретные workflow будут прикладными.
-- и вот тут надо будет вернуться к теме холонов и добить её так, чтобы уже не оставалось вопросов. Там ещё куча паттернов в части B недописана. В том числе раскрыть тему конфликтов между холоническими уровнями, ибо "проблематизация" к этому моменту уже вся будет, OEE будет, вот и дать онтологию конфликтов.
-- характеризация в FPF уже есть, какой-то паттерн для Q-bundle характеристик уже есть, моделировался по мотивам архитектурных характеристик. Так что дальше можно заняться темой архитектуры, а начать её с "характеристик качества" как архитектурных характеристик. Известно, что их в литературе всего упоминается порядка 300, часто используемых порядка 30, вот и поисследовать. На эту тему и я уже немного писал в руководствах, а ещё были исследования Антона Королёва в МИРЭА, он рассказывал о них на нашей рабочей встрече INCOSE Rus по проблемам системной инженерии, эти исследования как раз подтверждают оценки "300 всего" и "30 самых употребимых". Трудность в том, что каждая архитектурная характерстика оказывается не просто каким-то скаляром, а вот этим самым Q-bundle, распаковывается в целый набор характеристик (и книжки по характеризации в эволюционной архитектуре как раз пытаются с этим сработать, подзаголовок профильной книжки там говорящий: the hard part).
-- дальше будет обсуждение характеристик собственно архитектуры, не путайте с архитектурными характеристиками. Архитектурные характеристики -- это характеристики холона, определяемые его архитектурой. А характеристики архитектуры -- это характеристики самой архитектуры. Скажем, reliability - это типичная архитектурная характеристика. Но сама архитектура? Например, coupling модулей в этой архитектуре можно отнести к характеристикам архитектуры. И тут мы идём к формулированию понятия "архитектура", и у меня есть идеи по тому, как это делать (вернуться к "архитектуре как структуре", дальше архитектурное описание -- это (multiple viewpoints and multiple views)-определяемое описание структуры, а недавние работы по ML (см. паттерны ML.* в https://ailev.livejournal.com/1787791.html) показывают, как там что-то можно оценить численно: что из структуры мы описываем, а что не описываем. Всё опять упирается в "моделирование", viewpoints, "сжатое описание" и это общий аппарат, а вот сами viewpoints уже предметны. Вот этот viewpoint -- архитектурный. Тем самым можно будет обсуждать качество архитектурных описаний, а также "динамику архитектуры" (изменение значений в пространстве характеристик архитектуры во времени для какой-то конкретной архитектуры).
-- и вот теперь у нас всё есть для занятий архитектурой самого FPF, где в основе "нулевые принципы", а архитектура крутится не вокруг "вставки модулей", а вокруг специализаций, семейств, наборов механизмов и прочего такого, и вообще речь идёт о "спецификации FPF", то есть эпистеме.
-- и вот тут-то SoTA-packs (часть G), Second and Third Principles Frameworks, типовые P2W профили и прочие варианты расширения на предметные области. Хотя часть G уже готова, но я ещё вернусь к этому вопросу, мне не всё там нравится.

Поскольку у нас тут в связи с приходом AI-агентов и сдвигом инженерной работы на проблематизацию и организацией решений проблем силами этих агентов получается некоторый новый инженерный процесс, то ещё надо будет опять и снова срочно дорабатывать руководства. Туда надо добавлять довольно много по самой проблематизации, протоколы характеризации (сейчас там, конечно, даются ссылки на "как измерить всё, что угодно", но тут сам подход меняется -- собственно идеи по характеристикам как характеризация, но затем индикаторизация, нормирование, возможный скоринг и свёртка/агрегация, сравнение и выбор, набор механизмов существенно больше, чем просто "указать набор характеристик"). Или взять хотя бы понятие stepping stones, которое вводится сейчас в "Методологии" абсолютно неформально и метафорично, но его ведь надо вводить абсолютно явно.

(Comment on this)

lytdybr
Закончил слайды для воскресного семинара по развитию для развитых (программа в https://ailev.livejournal.com/1787638.html, и ещё была пара текстов -- пару недель назад https://ailev.livejournal.com/1788081.html и четыре месяца назад https://ailev.livejournal.com/1777619.html как стартовый для работы над этой темой. Получилось 74 слайда, и это не столько "презентация", сколько "слайдомент" -- материала там на небольшую книжку (если читать про себя, то это займёт час, а вслух -- полтора часа. Семинар будет идти шесть часов, так что после семинара останется вполне себе подробный конспект). На семинаре я буду рассказывать общую версию "развития для развитых людей, систем, AI-агентов, организаций", ибо речь пойдёт о текущей новации в инженерном процессе, после agile двадцатилетней давности и DevOps с continuous everything в их современном виде для ситуации, когда разработка уже не жмёт: в software engineering в декабре вышло новое поколение моделей, которое можно оставить что-то разрабатывать на сутки-двое (а то и на неделю, но "у всех" это "на неделю" появится только через несколько месяцев). А к концу года примерно то же самое ждёт и многие другие инженерные и неинженерные специальности. Приехали в ситуацию фильма "Сталкер", где главный герой долго мучился, что бы ему такого себе пожелать -- и закончил формулировкой "счастье всем, даром, и пусть никто не уйдёт обиженным". Освобождённые от разработки инженеры прихватывают то, что традиционно было у менеджеров: координацию агентов (людей, AI-агентов, подрядчиков), оценку рисков в плане "можно ли поручить, или не справится", но главное -- проблематизация, постановка проблем (даже не задач как поручений на работу, а проблем, которые надо как-то решать: предыдущий шаг перед стратегированием как поиском идей по методу решения проблемы). Проблематизация была всегда, но новизна — в том, что её теперь приходится включать в процесс разработки, ибо производство решений перестаёт быть дефицитом, а вот производство хороших проблем пока дефицитно и требует уточнения языка обсуждения и процесса. Слайды содержат формы "мышления письмом/моделированием" для нового инженерного процесса, совместимы с FPF и их можно использовать для помощи в организации нового инженерного процесса: бесконечного развития уже развитых. Уже развитого себя, любимого, развитого сотрудника, развитого AI-агента, развитой организации, развитой эко-системы. Перед нами бесконечное развитие на любой степени развитости. В книжке Дойча про объяснения рассказывается, что в бесконечности мы всегда в самом её начале, как бы глубоко мы в эту бесконечность ни погружались. Поэтому как бы ни были вы развиты, или развита ваша организация, или развит ваш продукт -- перед вами бесконечность, вы в начале бесконечного процесса развития. Это и есть новый инженерный процесс. Вот один из слайдов семинара (при этом лемниската развития показана не очень точно, следующий слайд там не такой красивый -- он текстовый, но зато там шаги показаны много точней, и их там показано больше. Тем не менее, идею слайд доносит).



Какие у меня планы на "после семинара с развитием для развитых"? Довольно много всего:
-- выполнить планы из второго абзаца поста https://ailev.livejournal.com/1788213.html, это главное
-- перетряхнуть работу с холонами: похоже, что архив и портфель в развитии -- это ещё один вид холона, и надо бы добавить U.Portfolio как тип. Это даст стандартные слоты и операции с портфелем (слияние, срез, переоценка с новыми версиями условий, выбор), чтобы портфели перестали быть каждый раз ad hoc структурой с уникальным языком разговора о них в каждом проекте. Если уж инженерный процесс начал с ними работать, надо переставать изобретать каждый раз идею архива и портфеля со связанными с ними операциями заново, документировать паттерны и анти-паттерны работы с портфелями. После этого промпт для LLM+FPF вроде "оформи портфель проблем в нашей Jira" должен отрабатывать без особых сюрпризов.
-- похоже, у нас тут новый инженерный процесс, и надо будет опять срочно дорабатывать руководства. Туда надо добавлять идеи о явном прихвате проблематизации в разработке, протоколы характеризации (сейчас там, конечно, даются ссылки на "как измерить всё, что угодно", но тут сам подход меняется -- собственно идеи по характеристикам как характеризация, но затем индикаторизация, нормирование, возможный скоринг и свёртка/агрегация, сравнение и выбор, набор механизмов существенно больше, чем просто "указать набор характеристик"). Или взять хотя бы понятие stepping stones, которое вводится сейчас в "Методологии" абсолютно неформально и метафорично, но его ведь надо вводить абсолютно явно.
-- и не забыть перетряхнуть всяческие содержательные тексты вроде памяток по рабочему развитию, исследовательскому развитию, квалифицирования в МИМ, чтобы они точнее соотносились с самой идеей развития в её современном понимании.

Active inference всегда удивлял меня тем, какие неочевидные имена у тамошних понятий. Например, та же free energy, как одно из основных! Какая же там "свобода", какая "энергия"?! Я взял волшебную именовалку -- паттерн F.18 -- и попросил выдать полную name card. Менеджерам (если говорить, "менеджерам", то FPF явно упрощает -- ибо от инженеров ожидается терпимость к математическому и физическому языку) для этой free energy предлагается имя "минимизируемая верхняя оценка неожиданности наблюдений" (и предупреждение, чтобы не путали с используемым в физике понятием free energy). Тут важно, что "минимизируемая" (то есть понятие важно в связи с оптимизацией, а не само по себе) и "наблюдений" (то есть это о результатах измерений, a posteriori, evidence). По-английски коротко (тоже, чтобы не путать с "энергией") рекомендация называть – Surprisal Upper Bound. Неожиданность наблюдений будет всегда, но её стараются снизить при exploitation. А при exploration намеренно идут туда, где может быть какая-то (не слишком большая) неожиданность, чтобы найти что-то новенькое и получить новый stepping stone.

Ладно, stepping stone тоже термин не очень хорош, он выбран за метафоричность. А если его прогнать по F.18? Это enabling candidate (Tech на английском), но для менеджеров (Plain) по-русски предлагается по ситуации: “опорный промежуточный вариант”, “промежуточная находка‑опора”, "Кандидат-опора, полезная для будущих открытий", "разблокирующий вариант", полезность которого определяется не победой над текущими другими вариантами, а именно разблокировкой каких-то новых направлений поиска.

Я всё больше и больше понимаю, что крайне важны проблемы "перевода с русского на русский". Входной и выходной языки могут быть любыми, просто тут я начал с не самого тривиального случая одного языка, хотя могут быть и переводы с визуального языка в текст, из текста в язык жестов, и т.д. Да и операция "перевода" может быть хитрой (объяснение, фильтрация ошибок, перекодирование, формализация и т.д.). Лингвистические сервисы у нас на нулях, ибо раньше это делали люди-гуманитарии на хорошем окладе, а сейчас этим заняты LLM. Если подойти с инженерной рациональностью и заставить это делать LLM, то можно предложить много интереснейших сервисов. Поскольку "всё есть текст", а задачи изменения текста сводятся к задаче "трансляции из языка в язык", то можно поставить таких "переводчиков" на поток. Скажем, можно сделать для браузера "антижурналистский фильтр", который показывает новости, а не жареные факты в специальной подаче. Про военные новости я молчу, ибо там и так всё ясно ("наши доблестные разведчики против их презренных шпионов"). Но это же распространяется на практически все новости! X пытается сделать что-то подобное -- community notes, хотя там есть и свои недостатки (знаем мы это community, оно верит в мифических героев и пропагандирует эту веру как свободу совести, поэтому заметки могут быть не лучше самих новостей). Но вот берём ситуации вроде заголовков "автомобиль Waymo сбил ребёнка около начальной школы в Санта Моника" -- это пишет TechCrunch. А как надо было бы? "Waymo спас жизнь ребёнка около начальной школы. Waymo сумел тормознуть достаточно быстро, чтобы ребёнок получил только небольшую травму, а вот если бы в этой ситуации был водитель-человек, то это определённо был бы смертельный инцидент". У Waymo публично на “Safety / Safety Impact” фигурируют, например, 81% fewer injury-causing crashes, 82% fewer airbag deployment, 90% fewer serious injury or worse (по их методике и по состоянию данных “through September 2025”), а по страховым заявкам со Swiss Re — 88% меньше property damage claims и 92% меньше bodily injury claims (25.3M miles). Заметим, развитие роботакси не останавливается, эти цифры будут ещё лучше, но когда никто никого не убил, то это ведь "не новость, не публикуем". Ссылок даже не даю, ваш любимый AI-браузер и так всё найдёт и проверит в пять секунд. Жизнь и тут изменилась: надо только захотеть что-то проверить, надо только захотеть что-то найти -- и уже вот, проверено и найдено. Но "ложечки нашлись, а осадочек остался": хлёсткий заголовок запомнится, а что там было на самом деле -- останется непроверенным.

Ещё одна проблема -- это отсутствие в новостных подачах отслеживания длинных трендов, длинных проектов. Скажем, берём Демиса Хассабиса, который в одном из интервью 2022 года (https://ailev.livejournal.com/1637656.html) говорил, что сначала нейросетями отмоделируем сворачивание белков (AlphaFold), потом масштаб поднимем и отмоделируем клетку, потом отдельные органы, потом весь организм -- и проблемы медицины решим именно вот так, через масштабирование. Похоже, что этот план продолжает реализовываться, ибо там выпустили AlphaGenome, который выдаёт 5930 human genome tracks (модальностей/"дорожек измерений") на базе 1 Mb входной ДНК-последовательности, с предсказанием на уровне отдельных нуклеотидов, при этом модель обучена на human+mouse и даёт SOTA/near-SOTA в большинстве оценок variant-effect prediction -- https://www.nature.com/articles/s41586-025-10014-0 (обзоры -- https://t.me/gonzo_ML/4667). Так победим. В принципе, развитию цивилизации угрожает сейчас не столько новый вирус или тотальные войны, сколько банальное снижение рождаемости. Ну, и я трансгуманист: зачем мне тело с наследственными предрасположенностями к болезням, с запрограммированной смертью? Как только будет возможность его поменять, надо обязательно это сделать! И мозгов, мозгов себе добавить!

(Comment on this)