Понятизация, онтологический дребезг и прочее про язык -- уже в FPF, спасибо Codex App.
Из-за AI-агентов жизнь изменилась: она у части населения (добрались новые инструменты явно не до всех -- https://www.anthropic.com/research/labor-market-impacts) стала умнее, а также ускорилась. Теперь из "мозговых результатов" можно получить кучу того, что пренебрежительно называли "нейрослопом" у стареньких дешёвых моделей, но экономически доступно и крайне быстро стало получить "нейрозолото" у новеньких дорогих моделей, а ещё надо ведь уметь отличать нейрослоп от нейрозолота, в том числе и разные их гибриды. И вот дальше -- мусор в постановке даст мусор в результате: чтобы получить что-то ненужное, надо сначала запросить что-то ненужное. Искусство проблематизации, постановки задачи с потенциально интересными решениями (stepping stones в open-ended evolution) выходит на передний план. Изо всех утюгов, во всех лентах одна и та же мысль: "Раньше дефицитом была способность самому произвести интеллектуальный результат. Теперь всё чаще дефицитом становится способность выбрать, какой результат вообще стоит производить, в каком представлении его лучше искать, как принять его в работу и кто отвечает за последствия". Ссылок даже не даю, я эту мысль писал давно. А на прошлой неделе на эту тему отписался чуть ли не каждый первый программист.

В части эпистем сработала классическая постановка вопроса фильма "Сталкер" (или "Пикника на обочине"): если у вас есть Супер-пупер-мозг (и ему ещё дали tooling и интерфейсы в мир, хотя это всё и информационное, то есть это не просто мозг, но ещё что-то не очень embodied), что вы попросите? Классическое "счастье всем, даром, и пусть никто не уйдёт обиженным?" с неминуемым конфликтом в ответе (счастье волка в катастрофе для зайца, обида вора на лоха за то, что ему не дали своровать, и т.д.)? Запросы нужны всё-таки не художественные, а реалистичные.

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

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

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

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

Это всё относится и ко мне. Все побежали в сторону LLM, и я побежал (хотя долго ждал, просто отслеживал). Пару дней назад вышли GPT-5.4 и Codex App для Windows -- я этого тоже долго ждал. Сразу поставил себе Codex App с GPT-5.4 и начал работать с ним. Там GPT-5.4 xhigh -- самая продвинутая из доступных моделей, но вот GPT 5.4 Pro недоступна, увы, так что одновременно продолжил с GPT-5.4 Pro на web-UI. Ах, на сегодняшнее утро у меня готова версия с language-governance core из десятка новых и переделанных паттернов. Вау! На реализацию уже более-менее поставленной задачи -- пара дней, вместо почти пары недель, на которые я рассчитывал.

Release early, release often. Я опубликовал новую версию: https://github.com/ailev/FPF/. Пробуйте.

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

Ещё неделю назад я бы не назвал эту версию "небольшой": там ведь реально архитектурные прорывы! Огромный сложный пункт моего плана от 1 февраля у меня реализован с существенным превышением не только по скорости, но и по содержанию. Так, удалось втащить понятизацию -- включая focusing с TAE и "онтологический дребезг" со многими ещё и расширениями, ещё и Пирсига с dynamic quality сюда же -- там целый bundle на эту тему "доконцептуальной мысли" появился. Удивительно, но можно думать о реализации ещё до апрельских конференций и семинаров вообще всего плана от 1 февраля https://ailev.livejournal.com/1788706.html -- там точность языка (вот она уже как-то "решена"), далее целостность/холоны точным языком, далее графы трансдукций, далее commits/MOVE и попробовать TGA с evolvability для thinking, далее проблематизация и конфликты системных уровней, далее архитектура, затем собственно первопринципность и далее можно идти на SoTA-packs инженерии и менеджмента.

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

Ну, и сейчас я бы даже вот этот пункт не стал считать законченным. Раз уж можно давать поручения Супер-пупер-мозгу, то надо этим пользоваться: у меня появилось много новых вопросов к реализованному. Раз уж всё так быстро, я ещё почищу этот новый кусок. У меня тут сработало наличие хороших заделов -- прежде всего, я сам, любимый, как "задел". Мастерство владения семиотически-репрезентационной темой оказалось уже прошито в мокрой моей нейросетке, а кроме LLM (и даже world model) в этой мокрой нейронной сетке была ещё и работающая архитектура NI-агента (NI, natural intelligence, небось уже забыли об этом сокращении), ибо в моём составе есть и внешняя память и выход tooling, и интерфейсы к другим агентам, из них главными оказались интерфейсы к Codex App и ChatGPT на web-UI (вот тут я прописывал разницу между LLM и AI-агентом на базе LLM, и даже application на базе AI-агента, который на базе LLM: https://ailev.livejournal.com/1790893.html).

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

Какие вопросы я сегодня задаю этому Супер-пупер-мозгу? Вот прямо сейчас GPT-5.4 Pro у меня думает (это занимает обычно от четверти часа до сорока пяти минут на один вопрос -- независимо от номера Pro модели, только ответы становятся с каждой новой версией старшей модели чуть умнее) уже третий раз (я ведь спрашиваю обычно раза три подряд). Копирую промпт целиком: "Тут мы всё время говорим о "языке" и language-governance core или чём-то подобном. Но есть много других слов, которые легко представить на этом месте: semantic-governance core, speech-governance core, viewpoint-governance core (ибо viewpoint как раз включает обычно и representation, notation и поэтому "включает язык"). Это теснейшим образом ещё связано с эпистемологией (ибо речь идёт о движении мысли и языковом оформлении этого движения), с онтологией (ибо язык у нас прежде всего описывает понятия) и с concept theory (theory theory, prototype theory и т.д.), а ещё легко представить это как lexical-governance core (ибо речь про лексику прежде всего), linguistic-governance core (лингвистика традиционно изучает языки) и т.д. (какие ещё есть варианты, которые я пропустил?). Надо ли сделать в FPF какой-то паттерн, вводящий более точную терминологию, RPR для всех этих понятий-триггеров? Что из этого всего наиболее подходит для названия того, что у тебя language-governance core? Какие ещё core надо было бы добавить, чтобы закрыть все эти предметные области? Это всё первопринципные области, или какие-то из них "прикладные, второстепенные"? Как в FPF архитектурно устроены сейчас все эти "управления" семантикой, лингвистикой, языком, эпистемологией, онтологией, лексикой, концептуализацией/понятизацией и как надо было бы их сделать?" -- и вот примерно такое я пишу последние несколько дней.

Подобных вопросов я поназадавал ещё много, над ответами пока думаю -- вот ровно "читал пейджер, много думал". Пока думаю про упорядочивание уже наработанного, чтобы стали понятными дыры. Скажем, сейчас используем "язык", но если уйти от чисто "языка" -- как организовать FPF в части всего этого языко-ориентированного? Я тут вспоминаю посты про "йа язычнег, дайте мне капище", https://ailev.livejournal.com/683311.html -- про языкоориентированное программирование, ещё в 2009 году: "Каждый человек -- язычнег, нет в современном мире постмодерна места моноязыкизму. Идея Единого Языка, конечно, интеллектуально привлекательна, но неконструктивна: результаты такие же, как с монотеизмом -- вон сколько их на планете, разных монотеизмов, один другого краше и истиннее". Там обсуждались language workbenches, и языки программирования. Это сейчас выясняется, что языки не так уж важны -- но тоже не всегда "не важны", ибо есть представления "непосредственно исполняемых нотаций" у Danielle Macbeth (https://disk.yandex.ru/i/u8S8hx54BxA7qA), символьные формализмы в логике у Catarina Dutilh Novaes (https://disk.yandex.ru/i/whj1qs2XNOHd1w), и тут попытки разобраться, что там за аналог "нотаций" внутри LLM (скажем, для арифметики -- геометрические "странные формы", тут важные работы вроде https://arxiv.org/abs/2602.15029, https://arxiv.org/abs/2602.22617, https://arxiv.org/abs/2601.04480 (представление арифметики для манипулирования, представления в плане их affordance).

Конечно, “язык” у меня понимается шире обычной лингвистики: как выбор представлений, степени формальности, семантической точности и способов перехода между представлениями (трансдукциями, есть же уже в FPF архитектура графа потока трансдукций). Супер-пупер-мозг говорит, что надо подниматься выше и говорить о semiotic and representation-governance, а "язык" оставлять как некоторую презентационную сторону для человеков (и в мае 2025 я уже упирался в то, что там объемлющее: семиотика ли часть лингвистики или наоборот, и что там с языками и знаками -- вот через месяц надо не забыть вернуться к этому вопросу, это вот тут было: https://t.me/typeslife/21723).

Так что интересуемся и тем, что происходит после отмирания традиционной token-centered (в локальных представлениях) лингвистики -- работами вроде Byte Latent Transformer с патчами вместо токенов из https://arxiv.org/abs/2412.09871, DroidSpeak из https://arxiv.org/abs/2411.02820, LCM с "concept -- это эмбеддинг фразы" из https://arxiv.org/abs/2412.08821. Надо добавить недостающую симметрию ходов в пространстве языка-семантики (не только повышение точности, но и наоборот) и поперечные transform-families: controlled semantic coarsening, representation transduction, carrier transduction, interpretive construction. Без этого RPR остаётся сильной, но односторонней веткой "формализаторов". Тут ещё много идей, скажем, A.6.3 specialisations для conservative re-textualization: перевод, summary, filtering, report (очень многие из операций информатики в моём посте 2012 года, https://ailev.livejournal.com/1008054.html — это именно views over the same described entity). Работает мой zettelkasten, пригождаются старые посты! Поэтому всё и быстро: я знаю, чем кормить AI-агентов.

Или ещё можно делать pattern for explanation (justification surfaces): когда текст генерируется из какого-то следа/трассы, вывода вроде CoT или модели, но нужен explicit provenance, чтобы не путать faithful rendering с post-hoc narrative. Это пока скорее архитектурный пробел, и тут я опять должен буду вернуться к старым наработкам по рендерингу. Рендеринг/порождение/деформализация/элокуция/"разворачивание схемы"/нарративизация как операция, обратная мета-моделированию. Много занимались этим где-то в 2019 году -- вот и пригождается, https://ailev.livejournal.com/1494762.html). Третье — явная развязка между interpretation as conservative reading и interpretation as hypothesis generation. Сейчас это частично можно собрать из `A.6.3` и `B.5.2.0`, но отдельный pattern сделал бы эту "интерпретацию" намного яснее. A.6.P-style bundles — это substrate-facing semantic front-ends, их тоже надо наработать некоторое количество. И, конечно, Dynamics & Transduction Architecture — это более широкий meta-layer, который объясняет, как вообще в FPF устроены изменения состояний, преобразования артефактов и их enactment. Такого у меня много-много страниц утром и написалось, и нагенерировалось, так что я пока этим подавился и буду разгребать всё высвобожденное неожиданно (или ожиданно!?) время.

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

1. Бесплатный вебинар 22 марта 2026 (хотя у меня есть идея таки вытащиться в офис) "Три прототипа — это нормально. Три исправления ошибки — нет". В инженерии несколько вариантов решений, из которых выбирается один — это нормальный поиск (trade-off studies), а многократные исправления (переделки/rework) — признак плохой инженерной дисциплины, пустая трата времени. Как их различить? Какие причины заставляют делать много вариантов — и это не впустую, а какие причины заставляют переделывать по многу раз — и это как раз впустую?

2. Семинар 12 апреля 2026 как раз про надзор (governance) за точностью языка:
— у инженеров обычно императив "надо писать точнее". Текущий мой заход на а) есть множество характеристик языка вроде формальности, распределённости представления, возможности проверить и т.д., схлопывать в один скаляр "точности" не будем. Надо как-то научиться говорить о языке более богато, чем только "точный — не точный". б) надо управлять языковой динамикой, движением выражения на языке в пространстве этих характеристик. То есть иногда "надо писать/говорить точнее и формальнее, разжимать" (чтобы проще было коммуницировать и проверять), а иногда "менее точно, менее формально, сжимать" — чтобы проще было делать догадки и проводить аналогии. Управлять, двигаться во все стороны по всем характеристикам языка.
— с AI нам надо уметь управлять характеристиками языка и как минимум понимать устройство общения с ними.
— AI-агенты смогут делать всё. Но надо будет уметь описать задачу, удержать в мышлении проект в целом, разобраться с последствиями того, как AI-команда реализовала задачу. AI-команды будут реализовывать задачу крупными кусками, каждый из AI-агентов будет работать за группу специалистов-людей вчерашнего дня, причём быстро. Поэтому специалистам-людям завтрашнего дня (ну, или уже сегодняшнего) надо будет иметь то мышление, которое сейчас имеют их начальники — чтобы удерживать проект в целом. Это в том числе означает, что надо будет уметь осознанно управлять характеристиками языка, на котором происходит мышление, и осознанно выбирать язык (формальный математический или неформальный естественный, с картинками или без, образный с аналогиями или канцелярит, термины из какой инженерной или научной традиции, и т.д.) для каждой конкретной ситуации. Работе с широко понимаемым "языком" и его семантикой как объектами первого класса, характеризуемыми многими признаками, надо учиться -- хотя этому массово никто не учит явно (но мы -- учим).
— в работе с языком есть много того, что остаётся сегодня мало осознанным. Например, работа с "доязыковыми представлениями" при концептуализации (динамическое качество Пирсига, felt sense в focusing и TAE, латентные представления в глубоком обучении и т.д.). То есть учиться надо не только тому, что и так известно, но многое в работе с языком вам неизвестно, поэтому вы не сможете сами составить себе программу образования.
— изучение иностранных языков до приличного разговорного уровня занимает от 600 часов до 2200 часов в зависимости от того, насколько близки по структуре эти языки к родному. Цифры давно известны, вот пример оценок FSI (Foreign Service Institute правительства США, для англоязычных учащихся -- https://2021-2025.state.gov/foreign-language-training/). Так что нельзя ожидать, что "я тут пройду пару семинаров по языкам в их расширенном понимании и смогу потом их менять как перчатки". Нет, за пару семинаров вы узнаете о существовании многочисленных проблем, а затем вам придётся решать эти проблемы довольно долго, в том числе в резидентурах программы рабочего развития. Долго, ибо у людей медленно вырастают синапсы и улучшается капиллярная структура в тех областях мозга, которые ответственны за то или иное мышление. А ещё это всё будет сразу, прямо в марте 2026 поддержано FPF, и Супер-пупер-мозг будет решать эти проблемы без вас. Время надо, чтобы вы могли потом с этим Супер-пупер-мозгом на эти темы поговорить, а не смотреть на его выдачу как мартышка на очки в басне Крылова.

(Comment on this)

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

И обратите внимание: "думатель" ещё и не равно "делатель", до "делателя вместо тебя" мы ещё не доросли в нынешних всполохах сингулярности. "Делатель" -- это отсутствующий у "мыслителя" выход в физический мир и изменение ситуации со взятием на себя ответственности за неизбежно реализующиеся риски невязки между планами и жизнью. Подготовка каких-то текстов -- это мышление с записью его результатов, а не действие. Скажем, FPF (First Principles Framework, https://github.com/ailev/FPF) -- это руководство для AI-агентов. И в нём даже есть много про речевые акты (https://ru.wikipedia.org/wiki/Теория_речевых_актов_Джона_Остина ) -- выдачу обещаний, приёмку работ и прочие "высказывания, которые по последствиям как действия". Но речевыми актами не становятся написание текстов, рассылка писем с уведомлениями и советами, даже планы работы нельзя приравнять к действиям! Но вот обещание выполнить план работы -- вполне себе действие. Может ли пообещать что-то AI-агент? А что ему будет, если не выполнит? А если это ваш AI-агент пообещал что-то Васе, но не выполнил -- Вася придёт к вам или будет ругаться с вашим AI-агентом? В книжке Яна Диетца как раз этот пример: если вам автомат по размену купюр не выдал половину суммы, то вы не будете с ним ругаться, а начнёте искать где-нибудь на нём табличку с номером телефона человека, который берёт на себя ответственность за работу автомата. Но там-то сейчас по телефону наверняка робот! Эксперименты с осуществлением (а не только моделированием!) речевых актов AI-агентами только-только начинаются, и принципал-агентские отношения для этого интересного случая только-только начинают изучаться (я подробнее о принципал-агентских отношениях говорил на семинаре по "Развитию для развитых"). Так что мало научиться думать (в том числе научиться думать о "делании"), надо научиться ещё и действовать -- проявлять инициативу, брать на себя риски самых разных последствий, что много сложнее. И да, изучать мир -- это тоже ведь не "читать" (изучать описания мира, а не мир), а действовать -- ставить эксперименты, тыкать мир палочкой, "зондировать".

Так что я для тех немногих инженеров-менеджеров, кому важно рациональное мировоззрение и отсутствие лишней "магичности" в мире, кто понимает, что "аналитической работой" сугубо мыслителя мало чего можно добиться, написал за прошедший почти месяц маленькую книжку про МИМ (планы заниматься этим целый месяц у меня были в посте "Пишу "Руководство по мастерской инженеров-менеджеров"", https://ailev.livejournal.com/1789736.html, 9 февраля 2026). Даю тут написанное не в хронологическом порядке, а в порядке, удобном для чтения:
* Мастерская инженеров-менеджеров: почему именно мастерская? -- https://ailev.livejournal.com/1793139.html
* Почему "инженер-менеджер", 2026 -- https://ailev.livejournal.com/1794296.html
* Развитие для развитых в Мастерской инженеров-менеджеров -- https://ailev.livejournal.com/1794324.html
* Типовые эффекты от прохождения программ развития МИМ -- https://ailev.livejournal.com/1790080.html
* «Что получите»: типовые эффекты программ развития МИМ -- https://ailev.livejournal.com/1792163.html
* Что потребуется для МИМ, чего не обещаем, «зелёные и красные флаги» совместимости с культурой МИМ -- https://ailev.livejournal.com/1792363.html
* Типовые форматы мероприятий программ развития МИМ -- https://ailev.livejournal.com/1790426.html
* Квалифицирование инженеров-менеджеров: измеряем агентность, масштаб, методологическую дисциплину -- https://ailev.livejournal.com/1794653.html.
* История Мастерской инженеров-менеджеров (МИМ, ранее ШСМ) -- https://ailev.livejournal.com/1792800.html

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

В чате телеграма я уже получил на пост про квалифицирование (хронологически он был последним) отзыв (https://t.me/ailev_blog_discussion/34905): "Разрыв в эффективности обучения между самостоятельным прохождением руководств и прохождением в группах с наставниками понятен – с наставником происходит авторитетный RL! Единственный вопрос – остается ли какой-то способ проверять/подтверждать квалификацию самопроходцам?". Вот она, "магичность" -- в тексте вопроса явно ведь "громоотвод от магии", термин из learning sciences (в основе которых бихевиоризм!), перекочевавший в машинное обучение термин reinforcement learning (RL), "обучение с подкреплением", дрессировка. Я ответил, что с наставником RLHF ("авторитетный RL", он же reinforcement learning with human feedback), а не просто RL. Очень верное замечание. И вроде бы в тексте моего последнего поста про МИМ как раз для "самопроходимцев" было указано, как получать квалификации — докладываться об их успехах на нашем методсовете, на конференциях или даже написать эссе в клуб. Прецеденты были, получали даже мастеров таким способом. Но там у нас наставники жёсткие, смотрят не на истовое желание, а на возможности по прохождению. Недавно один из отзывов наставника про эссе как возможный повод для присвоения очередной степени был "там нет ни одного слова из R8-R10, о чем можно говорить?!", при этом как раз было "самопроходимство" по этим руководствам. R8-R10 -- это три последние резидентуры: по системной инженерии, инженерии мастерства, системному менеджменту. До них мало кто доходит, но ведь в работе именно они самые "прикладные", от них максимальный эффект! Конечно, эффекты есть от каждой отдельной резидентуры, но общий эффект кумулятивный. Поэтому прыгать через ступеньки, а также ожидать успешного успеха в системном менеджменте или системной инженерии без прохождения этих резидентур с наставником я бы не стал. Ага, голимый маркетинг: руководства доступны бесплатно, но дальше как с самоучителями игры на гитаре, прецеденты освоения игры по самоучителю -- у редких одиночек, зато бесплатно, а с учителем музыки -- шансы резко повышаются, и даже не у гениев.

Ворваться самопроходимцам на старшие резидентуры можно штатным образом: написать на входе эссе, даже докладываться где-то не надо. Эссе либо прислать письмом, либо вообще -- опубликовать в клубе (https://systemsworld.club/). Вот сейчас начинаются R2, R6, R9 (расписание см. в конце страницы https://system-school.ru/programs/orgdev). Можно написать эссе — и туда. Конечно, надо "самопройти" перед этим не только предыдущую резидентуру, но кумулятивно все резидентуры с R1. Скажем, вскочить в R6 только с R5 в голове -- не получится, надо в голове иметь с R1 по R5 (версии предыдущих вариантов тоже идут — скажем, "Рациональная работа" засчитывается как R1-R4. "Системное мышление" в варианте до января 2026 как R5-R6). Конечно, (я постарался в посте это очень подробно дать) вычитывать будут отнюдь не только "методологическую дисциплину" (скажем, рассказ правильными словами о том, что делают разные другие люди в разных других проектах или даже в вашем проекте). Внимательно будут смотреть на вашу агентность и масштаб — что делали там с полученной методологической дисциплиной вы и какой получился масштаб. Но если не понимаете, как разгрести пару часов в день на всё это, а также понимаете, что в эту пару часов минут десять будете читать, а потом час пятьдесят минут тупить, и нет никаких сил себя заставить выдержать не то что полтора месяца резидентуры, но даже пару недель -- идите на практикум программы личного развития, он тоже начинается как раз сейчас. Только не увлекитесь, личным развитием можно заниматься вечно, но даже самые глупые йоги показывают чудеса самоконтроля, но с умом у них не очень: не забудьте потом всю свою личную развитость направить на рабочее развитие.

Конечно, я понимаю, что надо заниматься ещё и развитием людей, поэтому кроме развития FPF планирую вернуться к вопросу обновления руководств. В руководствах есть очень много из того, чего в FPF банально нет — скажем, в FPF вообще нет ничего из R8-R10, но это как раз сама инженерия и менеджмент -- но ведь там много вторых принципов по факту, поэтому в FPF не факт, что там много попадёт. Даже из системного мышления там понятие системы есть, но очень мало пока про целевую систему и вообще ничего нет по поводу её важности в коллективных проектах. У нас в МИМ только вчера мы обсуждали, что важность целевой системы и "договорить всех вокруг себя" именно по поводу целевой системы наши инженеры-менеджеры не могут удерживать практически до самого конца резидентур программы рабочего развития (хотя понимать важность начинают где-то с R8, но не в R5, когда об этом рассказывается, а понятие системы вообще начинаем сейчас с R1 давать в последних версиях программы). Без владения методами мышления и (главное!) методами действия из руководств R1-R10 на волшебстве FPF вместе со слайдоментом не уедешь. Он больше "проверятель типов" сейчас, но надо же понимать, что ему подсовывать! Скажем, новые свои компании и проекты наши инженеры-менеджеры разворачивают прямо по R7 (методология) — открываешь руководство, и делаешь оттуда таблички в любимой операционной среде участников проекта, и всё после этого отлично работает. Но работает только тогда, когда понимаешь, что делаешь. Если не понимаешь -- будешь тупо листать R7, мучить ночами FPF+слайдомент -- и не понимать, что в этой каше дел, идей и событий делать. Если ты разобрался с руководствами -- то FPF тебе вполне понятен и он больше "проверятель" для твоих идей, чем "думатель вместо тебя".

Всего я переработал примерно половину из постов предыдущей серии текстов про МИМ, которых я тогда набрал в свой черновичок будущего "Руководства по МИМ" на 400К знаков, но проект закончу по timeboxing ("сколько успел за отведённое время") -- план как раз был управиться до начала марта. Конечно, я много отвлекался на интересные идеи -- про МИМ написано девять постов, а всяких "важных срочных постов по случаю" -- десять (Разбор по первому шагу системного мышления, февраль 2026 -- https://ailev.livejournal.com/1790554.html, Рок-н-ролл сдвигается с AI-агентов на универсальные приложения (на примере Codex) -- https://ailev.livejournal.com/1790893.html, Профессиональное кодирование и моделирование против вайб-кодирования и вайб-моделирования -- https://ailev.livejournal.com/1791187.html, Стахановство-2026: сколько AI-станков, ой, агентов сможет обслужить за смену один инженер-менеджер? -- https://ailev.livejournal.com/1791233.html, Обучение дошкольников мышлению из нулевых и первых принципов -- https://ailev.livejournal.com/1791704.html, Как поумнеть человеку или роботу: первые принципы в S2, inductive bias в S1. И выйти из кабинета -- https://ailev.livejournal.com/1791964.html, Хроники всполохов сингулярности, конец февраля 2026 -- https://ailev.livejournal.com/1792579.html, lytdybr -- https://ailev.livejournal.com/1793289.html, Position paper про "длинногоризонтное мышление" (long-CoT) как мышление письмом/моделированием (два поста) -- https://ailev.livejournal.com/1793776.html и https://ailev.livejournal.com/1794023.html). Если постов про МИМ хватит на небольшую повесть, то и этих других постов -- ещё на небольшую повесть! На сухом языке цифр -- написал примерно 450К знаков за меньше месяца (первый пост про МИМ -- 9 февраля 2026, последний -- вчера, 2 марта 2026). Удивительно, но это всё я писал сам, хотя и при помощи AI-агента -- AI-агент главным образом критиковал и дал несколько идей, которые я всё одно переписывал. Вот мои любимые промпты этого периода (в том порядке, в котором я их давал -- что-то по десятку раз на текст, что-то по три раза. Скажем, опечатки-согласования -- не менее трёх раз. Но никаких "переписывай" или даже "выдай diff", лучше оказывается всё руками):
-- Проверь содержательно. Похоже, у меня там абзацы перепутаны местами, а какие-то куски оказались вообще пропущены. Предложи несколько вариантов того, что делать.
-- Проверь содержательно.
-- Выдай список опечаток, ошибок пунктуации, ошибок согласования предложений, каких-то других ошибок в тексте.
-- ["Если хотите, могу ..." -- цитировать] Сделай.

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

Дальше я возвращаюсь к плану работы над FPF (https://ailev.livejournal.com/1788706.html), причём дополняю его идеями из position paper про "длинногоризонтное мышление" (они должны там идти после TGA, long-CoT это ж явно "процессы" и "операционный менеджмент", а commits/MOVE это к модульности хороший пример, так что перед архитектурой и даже перед "развитием для развитых" из лемнискаты в слайдоменте семинара). И это full time, интереснейшая тема управления точностью языка. Так что в ближайшую неделю-другую буду заниматься вот этим:
-- кластер управления точностью языка, чтобы развить идею восстановления "мутной речи на границе" паттерна 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" именно из этой характеристики растут), а характеристику трудоёмкости переделок я пока игнорирую.

(Comment on this)

Квалифицирование инженеров-менеджеров: измеряем агентность, масштаб, методологическую дисциплину
Andrej Karpathy предложил чудесный тест на умность: сравнивать людей по их возможностям генерировать осмысленные речи с поколениями GPT -- кто-то тянет на GPT-2, кто-то на GPT-7 (https://twitter.com/karpathy/status/1789605356617752724, там предложение сделать простенький классификатор для такого уровня): "В идеале вам нужен хороший мини-ряд, в котором всё остается постоянным, кроме, например, размера модели. Модельный ряд Llama 3, особенно когда они также выпускают модели меньшего (и большего!) размера".

В каждой шутке есть только доля шутки. Если речь идёт о самых общих тестах на силу интеллекта "вместо IQ", то вполне можно пользоваться и подобной процедурой "какая ты GPT", в том числе в вариантах с инструментами или без, с доступом к интернету или без, и вообще делать прогон по бенчмаркам для AI и дальше -- "знай свой шесток" с учётом того, что AI-агенты показывают сегодня довольно высокие результаты по всем возможным тестам интеллекта. В МИМ мы поступаем по-другому, замеры делаем не "речи на экзамене" (у Karpathy неявно это -- LLM), а "действия в мире" (и там надо обсуждать world models, агентность, embodied intelligence и прочее, что далеко выходит за круг уподобления инженера-менеджера просто "говорящей умной голове").

Для измерений квалификации инженеров-менеджеров надо решить множество самых разных проблем:
* выбора характеристик для квалификации, затем выбора из них индикаторов (показателей, по которым будем оптимизировать). Помним про закон Гудхарта, https://en.wikipedia.org/wiki/Goodhart's_law, индикаторов лучше бы иметь несколько. По этим индикаторам нужны шкалы каких-то уровней/градаций, и в конце концов надо ввести степени квалификации как профили типичных сочетаний уровней/градаций по выбранным шкалам.
* организации замеров: сами собой замеры не сделаются. Например, эссе об обнаружении проблем в своих проектах и решении их. Важно отметить, что квалифицирование -- это не "экзамен". В МИМ не приняты "домашние задания" и "учебные проекты". Всё происходит в рабочих проектах, поэтому и замеряется (причём неоднократно!) мастерство поведения в реальных ситуациях, а не "на экзамене". Нет натаскивания на "ответ по билету", ибо билеты подсовывает жизнь!
* организации связанных с квалификацией допусков (скажем, можно ли прыгать по разным резидентурам, или надо перед старшими резидентурами уже иметь какую-то старшую степень квалификации).
* ритм: какой ожидаемый ритм в прохождении всех ступенек? По факту, надо чаще менять свою квалификацию в сторону повышения, а затем (развитие бесконечно!) чаще её обновлять. Правильно выбранные индикаторы развития и их замеры в порядке квалифицирования помогают мотивировать инженеров-менеджеров не делать перерывов: если вывести им на дашборд их индикаторы, то они и сами себя уговорят.

МИМ выбрал вот такие индикаторы квалификации инженеров-менеджеров, которые он отслеживает в ходе их развития:
* агентность (от “одна операция по поручению и под строгим присмотром” до “сам ставит проблемы, сам находит решения, присматривает за другими” и даже "создаёт других агентов, которые способны быть самостоятельными"). Многие весьма умные инженеры-менеджеры способны часами разговаривать о содержании руководств для инженеров-менеджеров, о специальной литературе за пределами этих руководств, они гордятся своими фундаментальными знаниями -- но ничего в плане интервенций не делают, не меняют ни себя, ни окружающий мир и не вносят вклада ни в знания цивилизации, ни в культуру. Часто инженеры-менеджеры имеют "установку на аналитику", они не готовы менять жизнь, они готовы давать "аналитические отчёты", оставлять интервенции/вмешательства, оставлять агентность кому-то другому. В МИМ агентность -- шкала первостепенного внимания.
* масштаб ("радиус влияния"): наибольшая граница системы, для которой человек показал инициированное им изменение поведения (я → команда → организация → сообщество → цивилизация). Масштаб времени тут тоже важен: убедил на пять минут или добился изменений, которые удержались годы -- это разные масштабы.
* методологическая дисциплина: ad hoc против SoTA по рациональному моделированию ситуаций, учёту причинности, проверке невязки между предсказаниями теории и наблюдениями в жизни, выбору SoTA методов работы, а то и предложению новых методов работы, двигающих текущий Парето-фронт. Проверяется, что инженер-менеджер выбирает корректный, а не "любимый" метод в соответствии с ситуацией, умеет объяснить, почему именно этот метод применим и где границы его применимости, использует материалы руководств не как цитаты, а как описание шагов работы. По большому счёту, это очень похоже на традиционную оценку compliance: наши руководства по факту -- стандарты деятельности и мышления (хотя и изложены не в формате стандарта), и им надо следовать. Оценивается, насколько инженеры-менеджеры следуют этим стандартам. В МИМ мало быть агентным и масштабно действовать, надо ещё и мыслить и действовать по SoTA методам, изложенным в руководствах. Но compliance -- это только начало шкалы, ибо дальше идёт предложение улучшений в руководства там, где они плохо срабатывают. Руководства -- не догма, МИМ -- не секта (что не означает, что в МИМ нет стандартов мышления и действия, как и в любой организации).

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

Значения этих индикаторов в МИМ сгруппированы как квалификационные профили-степени (степени/градусы/degrees -- это всё синонимы, от латинского gradus «шаг, ступень, степень, градус», ещё пару веков назад "степени" переводили на русский как "градусы"). Сами эти квалификационные степени описаны не слишком формально. В целом они привязаны к уровням европейской шкалы результатов обучения EQF (European Qualifications Framework, https://www.cedefop.europa.eu/en/events-and-projects/projects/european-qualifications-framework-eqf). Агентность привязывается к EPA (Entrustable professional activities, https://www.tandfonline.com/doi/full/10.1080/0142159X.2020.1838465), но и тут мы это делаем очень грубо -- не плодим множество EPA-оценок для каждой отдельной деятельности, а просто ставим уровень в профиль в общем виде. Это калибровочная аналогия, чтобы мы в МИМ не "изобретали велосипед", а опирались на какие-то SoTA методы квалифицирования, уже как-то испытанные в мире.

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

1. Личное развитие: освоение мастерства менять себя, любимого, к лучшему.
* Ученик. Инженер-менеджер для получения этой квалификации должен уметь осознанно и полноценно выполнять роль ученика: осваивать какую-то предметную область, тратя на это (если это не "интенсив", а "просто так живу") от полутора до двух часов ежедневно. Например, это мастерство начать осваивать какое-то руководство по рабочему развитию, и не "соскочить" на середине. EQF Level 1. Work or study under direct supervision in a structured context. Масштаб -- "я". EPA L1 — наблюдает / не выполняет: может обсуждать, пробовать “на учебном материале”, но не засчитываем как выполнение в мире.

2. Рабочее развитие: освоение мастерства менять окружающий мир (а не только себя) к лучшему, работая в какой-то организации.
* Работник. Это первая ступень рабочей квалификации. Инженер-менеджер как работник может работать рационально, удерживая не только свои личные цели, но и цели организации в целом (подстраиваться под корпоративное ограничение потока работ). Работник может быть собранным, удерживая внимание на важных объектах, и имеет модель своей предметной области, в которой указаны эти важные объекты. Он умеет рационально рассуждать о причинах и следствиях, поэтому делает меньше ошибок. Поскольку работник стал производительнее и точнее в разговорах, то улучшения его работы немедленно замечаются окружающими. Обычно эту степень инженер-менеджер получает, когда освоил работу по наставлениям руководств R1-R4. EQF Level 2. Work or study under supervision with some autonomy. Масштаб -- "я". L2 — выполняет под прямым, проактивным надзором: наставник рядом, ведёт по шагам, заранее контролирует ключевые решения.
* Стратег. Инженер-менеджер как стратег рационально выбирает метод и предмет работ в ситуациях неопределённости, у него системное мышление (всегда сначала смотрит на систему глазами пользователя в момент её эксплуатации, затем разбирается с тем, как она устроена, а потом не забывает посмотреть на организацию создателей системы). Это в значительной мере от того, что он освоил мышление, описанное в руководствах по системному мышлению и методологии. Руководство по методологии как раз заканчивается разделом по теории стратегирования, вот отсюда и название квалификационной степени. Нижние степени квалификации (работник, стратег) намеренно звучат как продвинутые: инженерам-менеджерам, которые давно в нашем сообществе, разобраться будет нетрудно, но резидентам, недавно достигшим этих степеней, будет довольно легко этим похвастаться. Чаще всего эта квалификация достигается после освоения работы не только по R1-R4, но и по руководствам R5 (системное мышление), R6 (системное моделирование) и R7 (методология). EQF Level 3. Take responsibility for completion of tasks in work or study, adapt own behavior to circumstances in solving problems. Масштаб всё ещё "я", работы других не затрагиваются. L3 — выполняет под непрямым, реактивным надзором: наставник “на связи”, точечно вмешивается, проверяет ключевые результаты.
* Специалист. Инженер-менеджер как специалист разобрался с обобщённым инженерным процессом и разделением труда. Это в значительной мере от того, что освоил инженерную работу по нашим руководствам инженерной серии (сейчас это руководства R8-R10 по системной инженерии, инженерии личности, системному менеджменту). Но специалист ещё не принял методы мышления и работы из всех руководств всерьёз: специалист что-то использует из них при выполнении своей основной роли, но никак не затрагивает интервенциями культуру работы других людей. Специалист "знает теорию" про возможные интервенции в работе других людей, но собственных инициатив и интервенций по изменению коллективной работы, а не просто размышлений и оценок ситуации, у специалиста нет. EQF Level 4. Exercise self-management within the guidelines of work or study contexts that are usually predictable, but are subject to change. Но вот продолжение этого уровня 4 EQF к специалисту неприменимо: supervise the routine work of others, taking some responsibility for the evaluation and improvement of work or study activities. EQF тут только грубая и частичная параллель. Масштаб, как ни удивительно, до сих пор -- "я", ибо интервенций по изменению окружающего мира согласно методологической дисциплине не происходит. EPA L3 — выполняет под непрямым, реактивным надзором: наставник “на связи”, точечно вмешивается, проверяет ключевые точки/артефакты. Это такой же уровень, L3, как у стратега, но методологический кругозор у специалиста выше за счёт прохождения трёх дополнительных резидентур.
* Практик. Инженер-менеджер как практик принял всерьёз наставления инженерной серии для изменения собственной культуры работы, а ещё организовал до десяти своих подчинённых, изменения удерживаются, пока он в команде. Окружающие замечают, что у инженера-менеджера, имеющего степень практика, производительность выросла, он "стал другим человеком", стал умнее. EQF Level 5. Exercise management and supervision in contexts of work or study activities where there is unpredictable change, review and develop performance of self and others. Масштаб -- "команда". EPA L4 — выполняет самостоятельно: наставник делает периодические аудиты/ревью, но присутствие не требуется. Практику можно доверить (entrust) реальный проект с командой без риска, что он его завалит методологически.
* Мастер. Инженер-менеджер как мастер мыслит и работает так, как этому наставляют руководства -- и даже предлагает улучшения руководств. Он умеет организовать работу не только своих подчинённых (которых у него может быть много больше десятка), но и коллег, и даже людей выше себя по уровням иерархии: дело тут не в умении "быть начальником", но в умении быть лидером и наставником для тех, кто тебе не подчинён явно. Мастер умеет инициировать и проводить организационные изменения, эти изменения удерживаются, даже когда мастера нет рядом. Мастера у нас получают право быть наставниками, ибо они уже имеют достаточный собственный опыт в том, как работать с использованием картины мира, мышления и методов инженерии и менеджмента из наших руководств. EQF Level 6. Manage complex technical or professional activities or projects, taking responsibility for decision-making in unpredictable work or study contexts, take responsibility for managing professional development of individuals and groups. Масштаб -- "коллектив" (ибо речь идёт уже не только о своей команде, но о коллективе в целом, взаимодействии с другими командами, а не только внутрикомандном взаимодействии). EPA L5 — супервизирует других: обучает, калибрует, доверяет/не доверяет выполнение другим, улучшает процедуру выполнения и оценивания.
* Реформатор. Инженер-менеджер как реформатор -- это просто мастер с масштабами побольше: реформатор изменяет не только культуру работы своего предприятия, но и культуру сообщества, выходящего за пределы предприятия. В МИМ примерно десяток реформаторов. EQF Level 7. Manage and transform work or study contexts that are complex, unpredictable and require new strategic approaches, take responsibility for contributing to professional knowledge and practice and/or for reviewing the strategic performance of teams. Масштаб -- "сообщество, общество".
* Революционер (менее пафосно -- "общественный деятель", в шутку -- "эволюционер"). Инженер-менеджер как революционер -- это ещё один рост масштаба изменения мира: он даёт вклад (impact) в мировую культуру, в мировую цивилизацию, попадает в энциклопедию. EQF Level 8. Demonstrate substantial authority, innovation, autonomy, scholarly and professional integrity and sustained commitment to the development of new ideas or processes at the forefront of work or study contexts including research. Масштаб -- "цивилизация", изменения переживают время жизни революционера.

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

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

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

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

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

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

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

Особенности квалифицирования в МИМ:
* Поскольку SoTA в личном, рабочем, исследовательском развитии меняется, то квалификация у нас имеет год последнего её присвоения. Мастерская занимается развитием инженеров-менеджеров с 2015 года (ещё как Школа системного менеджмента), так что некоторые инженеры-менеджеры так и поступают: они проходят резидентуры по рабочему развитию с наставниками по свежим версиям руководств раз в пару лет -- и очень этим довольны, потому что "всегда на фронтире". Если увидите "мастер 2018 года", то можете сами сделать вывод о том, насколько это SoTA-мастер.
* В мастерской квалифицирование -- это не административная процедура "сдачи экзамена", "выдачи путёвки в жизнь", а индикативная инженерная -- постоянный "замер" квалификации при любой возможности, но не разовая "оценка". Если у работодателя для его группы в нашей резидентуре есть какие-то административные процедуры и он считает квалифицирование "экзаменом", то это его мнение, а не мнение МИМ. Дело МИМ тут -- организовать своё квалифицирование как замер. Квалификация инженеров-менеджеров должна быть публично известна, чтобы сообщество МИМ понимало, о чём можно с единомышленником поговорить и в какой проект с ним можно идти, чтобы на что-то рассчитывать. И, конечно, квалификация "со стороны" прежде всего должна быть известна самим квалифицируемым. Так что мы проводим частое квалифицирование-как-замер на встречах с нашими наставниками в ходе резидентур и практикумов, конференций, причём не на одной встрече, а на многих, при этом необязательно ограничиваясь только этими встречами. Так, квалификация может повышаться после выступлений (на конференциях, методсоветах и семинарах). И даже необязательно выступлений на мероприятиях МИМ, но всё-таки предпочтительно МИМ -- там проще обсуждать применение принципов квалифицирования к выступлению, показывать, как связан рассказ с использованием описанных в руководствах для инженеров-менеджеров методов мышления и работы, "говорить на птичьем языке" абстрактной (уровня мета-мета-модели, первых принципов) картины мира. Более того, старшие степени квалификации в рабочем развитии (степени мастера и реформатора) часто присуждаются именно по итогам выступлений, а не на встречах с наставниками в резидентурах. Программы развития с наставниками тут могут оказаться давно пройденными, но это не означает, что квалификация инженера-менеджера не растёт, мастерство не обновляется, новые замеры квалификации не нужны.
* Квалификация в МИМ абсолютная в рамках следования методам мышления и работы, описанных во всех руководствах программ, а не по итогам освоения работы по какому-то одному руководству одного практикума или одной резидентуры. Значительное число инженеров-менеджеров проходят резидентуры по отдельным руководствам два или даже три раза, и "уже мастер" вполне может захотеть сделать очередной проход по какому-то руководству из начальных резидентур, изучая при этом новый материал этих руководств -- и одновременно демонстрируя квалификацию мастера (например, говорит в ответ на вопрос "что сделал на неделе" не про себя, а про то, что начали делать люди, которых он организует -- то есть демонстрируя результаты своей работы как работу других людей, а не себя самого, смену фокуса внимания). Вот он получит свежее подтверждение степени "мастера", а не возврат на степень "работника", даже если он повторно пошёл на начальные резидентуры программы рабочего развития. Или не получит, если выяснится, что он ссылается при этом на материал каких-то старых версий руководств инженерной серии, то есть его "мастер" не будет SoTA (с этим как с осетриной, которая или первой свежести, или не осетрина. Так и "мастер" -- или у него свежая картина мира, или он не мастер).
* Критерии степеней квалификации наставники обсуждают на встречах с резидентами, на почти каждой встрече они дают примеры проведения квалифицирования. Увы, если сказать "чтобы быть мастером, ты должен продемонстрировать умение организатора: рассказывать не о том, что ты сам сделал, а о том, что сделали нового те люди, с которыми ты работал -- иногда даже будет длинная цепочка твоего влияния на результат", то это хорошо понимается -- но не делается! Надо каждому квалифицируемому инженеру-менеджеру сначала дать "зеркало" его ответа, сделав разбор/review не менее чем три-четыре раза -- чтобы квалифицируемый понял, что намерение его рассказа не совпадает с тем, что он на самом деле говорит. Буквально: цитировать его его слова и указывать, что там предмет рассказа -- его действия, или действия каких-то людей по какому-то новому методу, или вообще никаких изменений не было ни в нём, ни в его проектах. Тогда инженер-менеджер понимает не только принципы квалифицирования, но и начинает как-то оценивать себя (не "квалифицирование по намерению того, что я говорю и делаю", а "квалифицирование по тому, что я говорю и делаю -- и это может существенно отличаться от намерения"). Вот это несоответствие видения своих внешних проявлений по сравнению с ощущением своих намерений в этих проявлениях -- самое существенное препятствие. Требуется довольно много предъявлений в разных контекстах, с разными наставниками, чтобы инженеры-менеджеры осознали: "что я думаю, что говорю, и что я действительно говорю -- разные вещи. Что я намерился сделать, и что я действительно сделал -- разные вещи".
* Принципы квалифицирования по нашим программам развития должен знать каждый инженер-менеджер, в том числе он должен уметь квалифицировать коллег (и он научается это делать, хотя и не сразу, а ближе к концу программы -- когда уже понимает, что там в мышлении и действии должно происходить на старших степенях квалификации). После умения квалифицирования коллег инженер-менеджер научается квалифицировать и себя самого. Для этого мы на встречах с наставниками (не на одной "экзаменационной" встрече или "защите", а на буквально всех встречах) рассказываем и повторяем критерии квалификационных степеней, принципы квалифицирования, а также демонстрируем определение квалификации инженеров-менеджеров по их рассказам. Типовой вопрос на встречах -- "расскажи, что ты сделал на работе за последнюю неделю", тут всё и выясняется: рассказ использует понятия из руководств, или бытовой, фокус внимания на своих действиях или на действиях тех, кто должен как-то освоить новый метод работы по инициативе квалифицируемого. И ещё через некоторое время появляется понимание, что "самоквалифицирование и квалифицирование других" по руководствам пятилетней давности -- это неправильно, развитие бесконечно, в зачёт идёт только квалифицирование по свежим версиям!
* Надо иметь видео встреч с проведением квалифицирования, оно будет в помощь квалифицируемому. Повторим: инженеры-менеджеры (к AI-агентам это тоже относится!) редко обращают внимание на то, что они говорят "дословно" -- у них в памяти остаётся общее ощущение того, что они были намерены сказать, а не конкретные сказанные слова. Но результат квалифицирования отражает не то, что они хотели рассказать, а то, что они в реальности говорили. Поэтому наставники (или коллеги) и цитируют их слова, по которым проводят квалифицирование, но на всякий случай ещё всегда есть видео. "У нас все слова записаны".
* Квалифицирование в МИМ всегда публично: наставник и группа резидентов, или участники конференции. Группа резидентов постепенно научается проводить квалифицирование по принципам, которые они перенимают по примерам квалифицирования, даваемым наставником. Через три-четыре встречи с демонстрациями примеров квалифицирования оказывается, что оно перестаёт восприниматься как субъективная "оценка" наставником и больше воспринимается как "замер", который может сделать с более или менее одинаковым результатом любой инженер-менеджер, прошедший программу и разобравшийся с нашими руководствами (даже "специалист": он может сам ничего не делать -- но суждение о том, какая квалификация у коллеги, он вполне может вынести!). В итоге квалифицирование делает вся группа резидентов плюс наставник -- и нет вопросов о "субъективности" (а в случае затруднений всегда есть видео).

(Comment on this)

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

В Мастерской инженеров-менеджеров принят подход развития для развитых, основанный на идеях бесконечного развития (open-ended evolution, open-endedness). Мы даём уже опытным специалистам способность быстрее входить в новые проекты, быстрее строить рабочие модели, проводить хорошо спланированные инженерные и организационные интервенции, а также превращать свои успехи в переносимые между проектами знания — так, чтобы усложнение решаемых проблем становилось для них нормой, а не кризисом.

Этот подход "бесконечного развития" отличается от повсеместно принятого в образовании подхода Agile в сочетании с MVP из lean startup. Для образования обычно бралось MVP какого-то мастерства как "цель", затем как-то итеративно получали MVP этого мастерства -- и отправляли выпускника с этим MVP работать. В случае МИМ примерно так и делали, когда он был Школой системного менеджмента: продуктом там было мастерство инженеров-менеджеров, в том числе мастерство быстро разбираться с проблемами всё новых и новых областей. Такое мастерство обычно называют "интеллект". ШСМ прежде всего занималась усилением интеллекта своих "студентов" (многие из которых уже были вполне развиты -- директора и собственники предприятий, инженеры-архитекторы, опытные консультанты по проектному управлению), затем давала общие знания по инженерии и менеджменту -- и всё, выпуск. Когда МИМ был Школой системного менеджмента, как и в любом университете, там был именно учебный процесс с учебными заданиями, и были "выпускники". Можно было "выучиться", и всё, процесс закончен, "образован" -- пополняй ряды alumni, как в университетах.

Agile -- отличный подход, итеративная разработка отлично ускоряет улучшение для заранее выбранной цели (этот подход появился в заказной разработке программного обеспечения -- "заказали -- получили"). Подход Agile (00-е годы) в середине 10-х годов дополнился продвинутым способом организации инженерного процесса -- "непрерывным совершенствованием" на основе воспроизводимой и дешёвой поставки с откаткой. В бизнесе это были самые разные школы continuous improvement (циклы PDCA, POOGI и множество аналогичных), которые существовали задолго до Agile и занимались улучшением рабочих процессов и продуктов на длинном горизонте, но мало кто обращал внимание на два вопроса: (1) воспроизводимость и скорость разворачивания новых решений, (2) воспроизводимость и скорость сворачивания неудачных новых решений. DevOps/SRE и CI/CD в 2010-е — это индустриализация непрерывной поставки, а затем и эксплуатации: ускорение, удешевление и повышение надёжности цикла каких бы то ни было изменений (автоматизация тестов, сборки, "выката", наблюдаемости результатов, откатов в случае неудач). Agile отвечал за дисциплину итеративной разработки, CI/CD — за дисциплину воспроизводимой поставки, а continuous improvement — за постоянное улучшение характеристик продукта и процесса на протяжении лет.

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

Например, первая экспертная система MYCIN была отлажена в ранних 70-х годах и давала рекомендации по назначению антибиотиков на уровне лучших врачей (что и породило неоправданные ожидания по экспертным системам). Но это было единоразовым достижением quality. Архитектурная характеристика evolvability для MYCIN оказалась плохой, архитектура не подразумевала изменяемости. Поэтому MYCIN не удавалось быстро улучшать, чтобы учитывать новые антибиотики и рост резистентности микробов к антибиотикам. Через пару лет MYCIN оказался "лучшим врачом двухлетней давности". Это общий класс провалов в проектах: когда единоразовое достижение quality без архитектуры удержания изменяемости/evolvability проигрывает на длинном горизонте.

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

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

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

Подход open-ended development (open-endedness, open-ended evolution) отличается от “непрерывного совершенствования” не просто тем, что “цели меняются”. Отличие сильнее: в open-ended режиме производство новых классов задач становится таким же регулярным и технологизируемым процессом, как и производство решений. То есть система развития должна уметь (1) генерировать и отбирать “достаточно трудные, но решаемые” (Goldilocks) проблемы, (2) находить решения, включая промежуточные stepping stones, которые пока не оптимальны по quality, но открывают новые области пространства решений, и (3) удерживать портфель разнообразия (diversity), чтобы не застревать в локальных оптимумах. В этой рамке прогресс — это не только рост quality по фиксированным метрикам, но и рост доступной новизны (novelty) и разнообразия решений/траекторий (diversity), которые расширяют будущие возможности.

В отличие от "непрерывного совершенствования", развитие предполагает смену целей -- и поэтому изменение средств их достижения, методов работы и используемых инструментов. В спорте “непрерывное совершенствование” — это, условно, минус 0.1 секунды на той же дистанции: тот же Парето-фронт, то есть те же характеристики, только выше качество исполнения. А open-ended поворот — это смена самой поверхности Парето: когда человек-спортсмен перестаёт оптимизировать прежние характеристики и выбирает новый класс задач, где прежние достижения становятся лишь одним из ресурсов, а не целью. В спорте смена “поверхности Парето” видна особенно ясно на кейсах осознанного перехода в другой вид спорта. Например, Ребекка Ромеро: олимпийское серебро в гребле (Афины-2004), затем смена вида спорта в 2006, затем -- олимпийское золото в трековом велоспорте (Пекин-2008). Это не “стать на 0.1 секунды быстрее в той же дисциплине”, а сменить набор критериев успеха, тренировочную инфраструктуру и технику — при переносе части базовых capabilities на новую задачу. Пример инженера-менеджера: сильный специалист по “скорости поставки фич” (delivery), сознательно переспециализируется на роль, где основной результат — проблематизация и выработка стратегии по решению поставленных проблем (problem framing, R&D). Он не просто “делает лучше то же самое”, но строит своё новое мастерство под другой тип проблем и другую систему критериев.

В случае инженерной разработки в целом такое, конечно, тоже есть, надо говорить о смене решаемой проблемы, отражающейся как смена стратегии (в венчурном бизнесе это обычно -- вираж/pivot): фирма получает мастерство решения другого сорта проблем. Так, Nokia занималась с 1865 года бумажным производством, потом занялась кабелями и резиной, потом выделила производство автомобильных шин из довольно большого конгломерата своих бизнесов, затем получила оглушительный успех на рынке мобильных телефонов, затем осталась занимать ведущие позиции на рынке инфраструктуры мобильной связи -- каждый раз при этом решая более сложные проблемы. NVIDIA перешла от рынка видеокарт к рынку ускорителей вычислений в искусственном интеллекте, Oracle от торговли программным обеспечением к торговле мощностями своих датацентров. Конечно, есть и "антипримеры" -- их особенно много на компьютерном рынке, где изменения крайне быстры (классический пример тут -- Kodak, не пережившая перехода фотосъёмки в сферу компьютерного бизнеса из сферы химии, но также и DEC, Compaq и множество других фирм, которые были слишком хороши в своих бизнесах, слишком оптимизированы, чтобы сохранить ту самую "изменяемость", evolvability при смене ситуации, когда условия изменились уже не "немного", а "существенно": надо было менять цели, сохраняя как-то свою идентичность).

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

Мастерская инженеров-менеджеров делает несколько новых шагов:
* принимает идеи open-endedness всерьёз. Принятие всерьёз (по David Deutsch) -- это осознанное использование теории open-endedness: переход от "промышленной разработки" и "непрерывной разработки" к идеям "бесконечного развития" в части организации всего инженерного процесса и его инфраструктуры. В случае МИМ это означает, что вполне развитая (развивается уже больше 10 лет!) Мастерская бесконечно развивается сама, находя себе новые и новые проблемы в быстро дрейфующем в зоне технологической сингулярности мире. В этом мире "ваши вчерашние проблемы исчезли, зато утром появились новые проблемы", причём вот это "вчера и утром" надо понимать буквально: изменения ежедневны. Мастерская бесконечно развивает уже вполне развитых инженеров-менеджеров, то есть находит новые и новые проблемы в этом развитии, более и более сложные, которые увеличивают возможности инженеров-менеджеров по решению всё более и более сложных личных, рабочих, исследовательских проблем -- и решает эти проблемы. Вполне развитые члены сообщества инженеров-менеджеров при этом продолжают предпринимать всё новые и новые шаги развития: прихватывают новые и новые проблемы, решение которых потенциально увеличит их возможности, учатся их решать, не останавливаются в этом.
* включает в свои программы развития не только освоение инженерами-менеджерами стратегирования как рационального выбора оптимального метода решения поставленных проблем -- и затем доведение мастерства в выбранном методе решения до совершенства, но и проблематизацию и её теорию -- выбор проблем, достойных попыток в их решении. Это Goldilocks-проблемы, иногда называемые для людей как "проблемы в зоне ближнего развития". Но и поиск решений тоже претерпевает изменения: в поиске будут проверяться гипотезы, которые могут открывать новые части пространства решений, перспективные для непрерывного совершенствования, хотя в момент их выдвижения они могут показывать более чем скромные результаты. Эти гипотезы решений называют stepping stones. В этот момент надо говорить не только о quality (характеристике пользы решения для решения проблемы), но и о novelty -- относительной новизне, дающей шанс на резкий подъём quality в дальнейшем.
* эволюция идёт не для отдельных систем, а для популяций/семейств систем. Поэтому признаётся существование не одного, а множества решений -- это характеристика diversity, и дальше речь пойдёт о портфелях решений.
* но главное, что отражает сегодняшнее понимание -- это включение эволюции в сам "выходной продукт", то есть учёт bitter lesson preference: если мы поднимаем универсальность инженера-менеджера за счёт роста его интеллекта и тем самым резко поднимаем его evolvability (всё-таки исполнитель роли инженера-менеджера имеет универсальную нейросеть в своём мозге, вполне можно полагаться на замечания "горького урока" про предпочтение "заливаемых бюджетом" универсальных решений специализированным), то вместо "накачивания" его специальными методами можно просто будет давать ему бюджет времени и ресурсов в надежде на то, что он сам выполнит часть проблематизации и поиска решений в новой ситуации. Для этого надо дать инженеру-менеджеру необходимые знания: прежде всего максимальный начальный интеллект, знания об инженерии как таковой (воспроизводимые, измеримые результаты на базе рациональных причинно-следственных рассуждений), знания о том, как пользоваться усилителями интеллекта (AI-агенты как помощники, tooling), как работать с портфелями проблем и решений в ходе бесконечного развития (по алгоритмам open-ended evolution). И ещё надо добавить осознанную агентность как инициативу по изменению себя и быстро эволюционирующего окружающего мира. И, конечно, хорошая постановка проблем и проверки -- чтобы было понятно, что это не уход "в свободное плавание по прожиганию ресурсов, отличное решение не тех проблем, что нужны".

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

Конечно, желающих подкинуть вам свою проблему для решения хоть отбавляй: коллеги, клиенты, правительства и диктаторы, ООН, think tanks, любой блогер, который лучше всех знает, чем вам надо заняться. Иногда вы начинаете стратегирование, когда у вас явной проблемы всё-таки нет -- а стратегировать надо, ибо это в инженерном процессе "по норме". Более корректно вписать проблематизацию как выбор того, чем заняться (а не стратегирование -- как именно заняться), и тогда придётся в явном виде обсуждать, откуда появилась и насколько обоснована та проблема, которую хотелось бы решить (потому как кто-то был очень убедителен, и "все побежали -- и я побежал") -- и не заменить ли эту проблему на какую-то более интересную, например, с большей отстройкой от конкурентов. А дальше -- гипотезы, варианты, trade-offs. Часто сходу даже при отлично поставленном стратегировании получить полное решение проблемы невозможно, но можно говорить о "перспективном для улучшения промежуточном решении (stepping stone)", планируя выход на какой-то участок Парето-фронта с каким-то набором характеристик решения и перспективами на их улучшение. И вот тут, в стратегировании (в отличие от проблематизации как "сугубого творчества") мы уже в знакомом мире маркетинга, архитектуры, где какие-то методы творчества и контроль выхода на Парето-фронт обсуждаются уже давно. Новое -- это явная технологизация проблематизации, явное обсуждение методов проблематизации. Раньше это отдавалось "предпринимательскому творчеству", сейчас начинает считаться частью инженерной работы, частью R&D. На какой именно Парето-фронт из их огромного числа выходить, на какой именно поверхности Парето (понятно, что речь идёт о поверхности в пространстве многих характеристик, а не кривой Парето-фронта в пространстве пары характеристик -- две характеристики было бы сильным упрощением) искать свой всегда промежуточный успех? Всегда промежуточный -- ибо развитие бесконечно. И идея разработки -- выход на Парето-фронт, удержание на нём. Идея развития -- не только выход на Парето-фронт, но время от времени смена Парето-фронта на более сложный и перспективный.

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

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

Мастерская инженеров-менеджеров даёт в своих программах развития продвинутую современную картину мира, универсальные методы мышления и работы -- и весь этот универсализм базируется на одном и том же SoTA наборе фундаментальных методов мышления и выхода в действия по изменению окружающего мира, опирающихся на первые принципы. Этот набор (мы его называем интеллект-стек) подразумевает мастерство в выполнении этих методов. Мы называем это мастерство интеллектом. Интеллект позволяет овладевать всё новыми и новыми специализациями. Конечно, сам этот набор фундаментальных "первопринципных" методов тоже меняется, цивилизация ведь развивается, никакой стагнации в развитии интеллекта нет. Поэтому инженеры-менеджеры вынуждены постоянно актуализировать своё мастерство в этих методах, то есть усиливать и обновлять свой интеллект. Какие характеристики мы отслеживаем? Вот пример:
* Time-to-first-credible-model в новой предметной области (скорость сборки рабочей онтологии/модели, целимся в "разговаривать с вами специалисту в этой предметной области интересно").
* Time-to-first-validated-intervention (первая проверенная интервенция, пусть даже “средняя” по качеству, агентность тут играет огромную роль, ибо можно "знать, но не вмешиваться").
* Transfer breadth: сколько разных доменов/ролей освоено с сохранением качества (прямая отсылка к generalist, Renaissance man).
* Portfolio health: доля задач/решений, которые стали stepping stones (оказались перспективными и стали основой новых решений, а не окончились впустую).
* Diversity coverage: сколько разных классов подходов реально поддерживается (не декларативно).
* Time-to-model-revision после опровержения (как быстро обновляем знания).
* Forgetting для основного мастерства (не теряем ли старые умения при освоении новых, нет ли деградации общего интеллекта при погружении в конкретные предметы).
* Consolidation/compaction rate: доля результатов, которые перешли в общие знания (чеклисты, руководства), а не остались в проектной пыли. Не нужно "просто новизны", нужно накапливать эпистемический капитал.

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

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

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

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

Поэтому инженеры-менеджеры все одинаковы (единомышленники, имеют общую картину мира, а ещё они уже весьма развиты, но продолжают развиваться), но все разные -- ибо специализируются на решении самых разных проблем. Каких? Всё время разных, растущих в сложности их решения, и это принципиально.

Мы знаем, что open-ended системы ломаются предсказуемо: уход в «гонку новизны», распад на полностью несвязные ветки, отсутствие консолидации. Для того чтобы не было "хотели как лучше, а получилось, как всегда", мы в МИМ:
* принимаем свою ограниченность по ресурсам, так что чередуем explore/exploit (периоды расширения vs периоды шлифовки и упаковки, примерно 20% exploration на 80% exploitation в нашем портфеле проектов -- это не закон, но вполне добротная эвристика, organizational ambidexterity);
* проверяем, что из знаний мы могли бы консолидировать/компактифицировать/сжать (интеллект -- это прежде всего сжатие информации! “Сжатие” проявляется как (а) меньшая длина объяснения при той же предсказательной силе, (б) меньшая стоимость переноса в новый домен, (в) меньше частных правил на единицу решаемых задач). Конечно, "сжатие" тут главным образом про знания, а предъявление их людям требует повторений, кривые забывания и множество предъявлений в разных контекстах для освоения нового мастерства людьми никто не отменял.
* избегаем уходить в "мультитаскинг" на множестве открытых одновременно Парето-фронтах, для этого удерживаем компактный портфель проблем и компактный портфель проверяемых гипотез для решений этих проблем, а в exploitation избегаем мультитаскинга (ухода в большое количество "заделов" и ни одной поставки).

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

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

(Comment on this)

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

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

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

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

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

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

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

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

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

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

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

Можно долго и много говорить о том, что инженерия и менеджмент неразрывны. Мы не будем просто "говорить", мы действуем: наши программы развития инженеров-менеджеров разработаны так, чтобы быть полезными и для исполнения роли инженера, и для исполнения роли менеджера в их тесном переплетении. И если к нам в резидентуру в рамках корпоративных программ попадает команда топ-менеджеров, то не только инженеры в этой команде лучше понимают суть менеджмента, но и менеджеры лучше понимают, чем в их компании занимаются инженеры. Это не голословное утверждение. У нас есть множество примеров, ибо мы занимаемся этим много лет, с 2015 года. И наш первый двухдневный семинар так и назывался "Смычка инженеров и менеджеров".

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

Скорее всего, в повседневной речи такой длинный термин будет сокращаться до «инженера», но с глубоким пониманием, что управленческая составляющая либо уже есть, либо активно развивается. Это также перекликается с нашей любовью к понятию «системный инженер» – ведь системный подход важен как в инженерии, так и в менеджменте. И тут ещё надо заметить, что в системной инженерии есть ещё системноинженерный менеджмент (systems engineering management, SEM) -- это тоже оно. И даже не системноинженерный, а просто инженерный менеджмент как классическая вузовская специальность -- и это тоже оно.

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

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

Так что «инженер-менеджер» -- это не просто удачное модное слово. Оно получено в результате обсуждений в нашем сообществе. Из многих других предложений оно было единственным, которое не было отвергнуто -- на него согласились практически все. Это отражение инженерного подхода к коллективному изменению мира к лучшему. Коллективного -- ибо масштаб изменений будет больше, но этот коллектив надо организовать (и вот тут к инженерии прибавляется менеджмент), неорганизованная толпа будет не создавать и развивать, а разрушать и ломать.

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

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

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

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

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

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

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

А вы ощущаете себя инженером-менеджером?

(Comment on this)

Position paper про "длинногоризонтное мышление" (long-CoT) как мышление письмом/моделированием (2/2)
Продолжение, начало в https://ailev.livejournal.com/1793776.html

## Архитектура (-ilities + fitness functions)
19. Статьи про long-CoT используют неуловимое понятие "сохраняемой структуры", неуловимое понятие "сохраняемой топологии", но можно думать о ходах на количественные оценки "ухватывания структуры" из "текст "Epiplexity: Quantifying the Structural Value of Data for Bounded Observers", https://arxiv.org/abs/2601.03220. Вот из гонзо-обзоров по-русски (https://t.me/gonzo_ML/4543): "даёт строгую метрику для отбора данных: для предобучения важен не минимум финального лосса (энтропии), а максимум усваиваемой структуры (эпиплексии)". Авторы ввели понятие эпиплексии (epiplexity) — новую метрику из теории информации, которая оценивает объём структурной информации, доступной *вычислительно ограниченному* наблюдателю. В отличие от энтропии Шеннона или колмогоровской сложности, подразумевающих бесконечные ресурсы, эпиплексия явно учитывает конечность модели (программы) и процесса обучения (вычислений)". Ха, эпиплексия - это максимум структуры (усваиваемой), то есть это по типу "структура", и одновременно это оценка объема (структурной) информации, то есть по типу "объём информации". Или структура измерима в битах, что уже интересно"). Это ход на "архитектуру рассуждений" (ибо архитектура -- это наука о структуре и топологии. Например, функциональные диаграммы и принципиальные схемы в графах трансдукций-- это топологии, схемы потоков). Конечно, сразу появляется проблема разнообразия архитектурных описаний: в одних и тех же long-CoT (с учётом онтологического разнообразия, что под ними имеют в виду) ищут разные структуры, для разных целей.

20. Рассматривая длину текста/рассуждения, мы выходим на архитектурный вопрос о модульности -- и находим там PSC (parallel sequential contradiction), https://openreview.net/forum?id=7oxC9rrM4X. Это существенно влияет на вопрос об "оптимальной длине" длинных рассуждений с одной стороны, вопрос о "структуре важнее длины", выстраивании каких-то фактов в длинные объяснения (возможно, комбинирование частей каких-то объяснений, вроде лемм-теорем). Вопрос к алгоритмике: есть ведь теоретические ограничения на распараллеливание (не все алгоритмы эффективно распараллеливаются). Параллельная природа декодирования конфликтует с причинным порядком, который нужен для строгого рассуждения; из‑за этого ограничиваются глубина, саморефлексия и исследование альтернатив. И архитектура вывода: если модель не генерирует последовательный текстовый след (например, у неё латентные планы, внутренние rollouts, или параллельное декодирование), “топология токенов” перестаёт быть естественной наблюдаемой величиной — и прямой перенос ломается. Вопрос к образованию: как оно с этим работает -- чему и как учить в мышлении, чтобы преодолевать ограничения от PSC? Достижимая топология/структура зависит от вычислительной архитектуры генерации. PSC — частный случай для параллельного декодирования.

21. Понятие коммита или MOVE (в терминах TameFlow) может помочь в задании модульности long-CoT. Оно может означать некоторый шаг рассуждения, в котором мы проходим какую-то развилку в процессе. Это в том числе и единица отката, означающая, что мы готовы вернуться и перепройти развилку по-другому. Архитектурное рассмотрение следит за архитектурными характеристиками. Похожесть коммита и MOVE из TameFlow, в том, что MOVE рассматривается как граница неделимого куска работы, достаточного для передачи результата следующим исполнителям. В LLM‑QA: финальный ответ как коммит/MOVE; LLM‑агентам (ReAct/ToT): многократные коммиты/MOVEs (выбор ветки, вызов инструмента); world‑model агентам: действие в среде как “жёсткий” коммит/MOVE; людям: сдача работы/публикация/отправка письма. Commit (ибо в разных работах action -- разное: у агента: реальное действие в среде; у LLM в задаче QA: коммит финального ответа; у LLM‑агента (ReAct/ToT): коммиты происходят многократно (выбор следующей ветки/инструмента/шага плана); у человека: коммит может быть “я выбираю стратегию”, “я заканчиваю решение”, “я сдаю ответ”). Все эти "до-после" в связи с "рефлексией" по факту -- момент, после которого исправления становятся существенно дороже (внешне или вычислительно). И, конечно, все эти "шаги" -- они разные по типу (шаг поиска (в пространстве гипотез), шаг доказательства, шаг редактуры/компиляции, шаг обучения читателя, и т.д.).

22. Коммит/MOVE в трансдукционном графе прямо связан с GateCrossing (ограничивает то, что делается в одном узле), но ещё трансдукционный граф -- это граф потока, "принципиальная схема", что традиционно обсуждается как "функциональная архитектура". Это усиливает тезис о том, что надо обсуждать прежде всего архитектурные вопросы, используя традиционные средства обсуждения архитектуры: модульность, потоки, различение общих для самых разных архитектур архитектурных характеристик и пользовательских/прикладных и т.д.

23. Можно думать о какой-то таблице, где есть до коммита, после коммита, во время коммита и ещё выход на уровень времени выше, "между эпизодами" (понятие эпизода тоже надо уточнять). Тогда "стабилизационная роль" self-reflection оказывается архитектурной: недопущение роста cognitive debt, уменьшения evolvability, стоимости возможного refactoring. Вообще, если протянуть рассуждение про структуры/топологию рассуждения и применить evolvable architecture, а коммит рассматривать как "прохождение развилки, после которой трудней откатиться", то надо сразу формулировать набор архитектурных характеристик и рассуждения, и объяснения, а ещё заводить архитектурную работу как meta-cognition, и она нужна для управления архитектурными характеристиками, которые измеряются непрерывно на основе каких-то fitness functions. Так что многие работы тут можно переформулировать как работы по архитектуре рассуждений и объяснений, отслеживание evolvability знаний. И тут или в каждой колонке мониторинга и контроля иметь Q-характеристики, и A-характеристики, или делать отдельные колонки для архитектурных характеристик:

| Фаза | Мониторинг: качество решения | Контроль: качество решения | Мониторинг: архитектура (пример: evolvability/изменяемость) | Контроль: архитектура (пример: изменяемость) |
| ----- | ----------------------------- | --------------------------- | ----------------------------------------------------------- | --------------------------------------------- |
| **До закрепления** (forethought) | требования задачи, риск ошибок, калибровка уверенности, критерии успеха | выбор стратегии/репрезентации/инструментов; бюджет (время/токены/роллауты); политика “think more/stop” | оценка *обратимости* ключевых решений (что будет дорого переделывать), оценка “ширины неизвестного” (насколько неопределён класс будущих запросов) | отложить необратимые решения до “last responsible moment”; выбрать более обратимую декомпозицию; заложить трассируемость (assumption ledger / ссылки на источники/под‑цели) |
| **Во время** (online loop) | прогресс, несостыковки, рост неопределённости, дрейф от постановки | смена тактики; backtrack/branch; запрос внешней проверки (инструмент/симуляция/поиск); увеличение глубины | рост “долга рассуждения”: сколько неявных допущений накопили, насколько переплелись зависимости между частями (entanglement), где уже трудно локально исправлять | **refactor траектории**: модульность (разбить на подзадачи), сделать допущения явными, добавить промежуточные проверки; управлять частотой рефлексии/ветвления |
| **Сразу после** (post‑hoc внутри попытки) | верификация результата, поиск контрпримеров, локализация источника ошибки | правка ответа/плана; дополнительная проверка; повторное извлечение знаний/свидетельств | оценка: “если завтра придёт новый факт/контрпример — насколько легко адаптироваться?”, выявление узких мест (где переделка самая дорогая) | добавить/укрепить “guardrails” (fitness functions): явные инварианты, тесты на согласованность, проверки источников; снизить закрепление через сохранение альтернатив/черновиков |
| **Между эпизодами** (learning/governance) | калибровка метакогнитивных сигналов: где мониторинг ошибался | обновление стратегий решения и выбора инструментов | мониторинг **архитектурного дрейфа** процесса (появляются ли повторяющиеся “хрупкие” паттерны), накопление “долга” в памяти/правилах | “оплата долга”: пересборка чек‑листов/политик; обновление памяти/правил; (в ML — data curation/finetune), установление постоянных fitness functions |

24. И ещё есть мониторинг с контролем, где каждый коммит/MOVE рассматривается как "дающий позитивный прирост в прикладной структуре рассуждения" и "источник роста cognitive debt, прежде всего характеристик evolvability". Вообще, понятие "недодуманности" в части архитектуры как cognitive debt (аналог технического/архитектурного долга, возникающего от приоритетного подъёма пользовательских характеристик при одновременном ухудшении архитектурных характеристик). Вопрос: этот архитектурный долг снимаем в ходе эпизода размышлений, или уже в ходе оформления результата размышлений (компиляции "заметок в ходе трассы long-CoT" в итоговый текст для конкретного читателя).

25. Универсальные ‑ilities для reasoning, которые почти всегда встречаются, когда разные сообщества говорят про “рефлексию/мониторинг/контроль/планирование/структуру траектории”.

Observability (наблюдаемость процесса) -- насколько легко *обнаружить и локализовать* сбой/дрейф в процессе рассуждения, имея доступ к наблюдениям (логи, следы, ответы, поведение).
* **LLM:** наблюдаемость часто зависит от того, есть ли доступ к промежуточным следам (CoT, tool traces, self‑eval) и насколько они согласованы; статьи про “топологию long‑CoT” фактически строят наблюдаемость через статистику переходов и “структуры” траекторий. ([arXiv][4])
* **World‑model агент:** наблюдаемость включает видимость “когда агент симулировал”, “что он вынес из роллаута”, “как это повлияло на действие”. В работе про world models показывают, что агенты часто почти не вызывают симуляцию и неправильно используют роллауты — это проблема observability+controllability на связке “симуляция→решение”. ([arXiv][5])
* **Люди:** в learning sciences это зона метакогнитивного monitoring (самонаблюдение прогресса/понимания) в SRL‑моделях. ([Frontiers][6])
* **Fitness function (архитектурная):** “локализуемость ошибки”, фиксируем набор задач с диагностическими “инъекциями” (вставить противоречивое условие, скрытую ловушку, смену требования) и измеряем: можно ли по наблюдаемым следам *верно* указать, где и почему произошёл сбой (не только что ответ неверен). Это тестирует **наблюдаемость**, а не просто accuracy.

Controllability (управляемость/регулируемость) -- способность *изменять ход рассуждения* в ответ на сигналы мониторинга: переключать стратегию, откатываться, ветвиться, останавливать поиск.
* **LLM:** Tree‑of‑Thoughts — явный пример архитектуры, которая добавляет controllability через branching, lookahead и backtracking (по сути, управление поиском по пространству мыслей). ([arXiv][7])
* **World‑model агент:** controllability включает политику “когда симулировать/какой горизонт/как интегрировать”. В 2601.03905 показывают, что именно это — узкое место. ([arXiv][5])
* **Люди:** в SRL это control‑фаза (смена стратегии, управление вниманием/временем/усилием) и она явно отделена от мониторинга у Pintrich‑подобных моделей. ([Frontiers][6])
* **Fitness function:** “реактивность на сигналы”, задаём контролируемые ситуации, где оптимальная стратегия должна смениться (например, вводится новое ограничение, меняется стоимость ошибки, появляется противоречие), и проверяем, что система **на самом деле переключается** в пределах заданного бюджета (токены/время/шаги). Это мониторит controllability, а не “среднюю точность”.

Reversibility / Low‑commitment operation (обратимость, управление закреплением) -- насколько дёшево “переиграть” ранние решения, не переписывая всё целиком.
* **LLM:** long‑CoT часто “цементирует” ранние допущения. Статья 2601.06002 выделяет self‑reflection как “fold back” — поздние шаги возвращаются к ранним, чтобы стабилизировать траекторию; в архитектурном языке это механизм повышения обратимости внутри длинной траектории. ([arXiv][4])
* **World‑model агент:** обратимость тесно связана с тем, можно ли “откатить” действие: поэтому важна симуляция до реального шага и поздний коммит. Если агент почти не симулирует, он повышает commitment слишком рано. ([arXiv][5])
* **Люди:** обратимость поддерживается черновиками, внешними записями, возможностью вернуться к предпосылкам; в SRL‑терминах это часть контроля и реакции/рефлексии. ([Frontiers][6])
* **Fitness function:** “стоимость пересмотра”, измеряем, сколько ресурсов нужно, чтобы корректно адаптироваться к небольшой смене условий (tokens/time/steps, у людей — минуты/итерации) при фиксированной исходной работе. Тестируем не качество исходного ответа, а **градиент стоимости изменения** (аналог cost‑of‑change, но управляемый).

Modularity / Decoupling (модульность рассуждения) -- локальные изменения должны оставаться локальными; рассуждение разбивается на компоненты/подцели с явными интерфейсами.
* **LLM:** ToT и похожие методы часто вводят явные “units of thought” и оценки на уровне узлов дерева. ([arXiv][8])
* **World‑model агент:** модульность — разделение “модель мира / планировщик / политика действий / оценщик риска” с явными границами и протоколами (иначе получаются entangled contexts и плохая управляемость). Проблема “как интегрировать роллауты в reasoning” — как раз про недостаточную модульность интерфейса между world model и контроллером. ([arXiv][5])
* **Люди:** модульность проявляется как декомпозиция задачи, структура эссе (тезис→аргументы→контраргументы→синтез), а также как умение переключаться между репрезентациями без “путаницы контекстов” (это хорошо описывается SRL как регулирование когниции/контекста). ([Frontiers][6])
* **Fitness function:** “локальность эффекта”, меняем один модульный компонент (одну предпосылку/подзадачу/источник) и проверяем, что изменения в траектории и выходе ограничены ожидаемой областью, без каскадной деградации. Это мониторит modularity/decoupling.

* Testability / Verifiability (тестируемость и проверяемость) -- насколько легко проверять, что процесс и его компоненты соблюдают инварианты (логические, фактические, процедурные).
* **LLM:** Self‑Refine — архитектура “черновик → критика → правка”, улучшающая выход без обучения; это увеличивает testability за счёт явного внутреннего тестового шага (feedback). ([arXiv][9])
* **World‑model агент:** testability часто реализуется через симуляционные “контрольные прогоны”, consistency checks между predicted rollouts и реальными последствиями, и т.п. Проблема из 2601.03905: даже при наличии world model агенты не превращают её в работающий тестовый контур. ([arXiv][5])
* **Люди:** тестируемость — это наличие критериев, рубрик, проверок (контрпримеры, независимая проверка, peer review). В SRL‑моделях “standards/criteria” — условие осмысленного мониторинга. ([Frontiers][6])
* **Fitness function:** “инварианты и метаморфические тесты”, задаём набор инвариантов (например, логическая согласованность; соблюдение ограничений задачи; отсутствие противоречий с источником) и прогоняем на регрессионном наборе; используем метаморфические преобразования (переформулировка, перестановка нерелевантных деталей) и проверяем, что поведение сохраняется. Это архитектурный мониторинг testability/verifiability.

Evolvability (эволюционируемость) -- способность процесса рассуждения адаптироваться к изменениям требований/контекста с контролируемыми затратами и без деградации основных свойств. Это прямой перенос идей evolutionary architecture: evolvability как -ility и fitness functions как способ её защищать. ([Neal Ford][1])
* **LLM:** evolvability часто упирается в то, как легко менять “архитектуру мышления” без переобучения — через промпт‑программы, tool policies, memory policies, структуры типа ToT/Reflexion. ([arXiv][10])
* **World‑model агент:** evolvability включает адаптацию к новым задачам/целям при тех же моделях среды; ключ — “насколько быстро перестраивается стратегия использования симулятора”. ([arXiv][5])
* **Люди:** evolvability — это перенос и перестройка знания (transfer, conceptual change), способность переучиваться и обновлять ментальные модели; SRL подчёркивает рекурсивность циклов и регулирование не только когниции, но и мотивации/контекста. ([Frontiers][6])
* **Fitness function:** “дрейф‑под‑изменениями”, регулярный набор “change scenarios”: новые ограничения, новые данные, смена формата вопроса; мониторим, что ключевые архитектурные свойства (наблюдаемость, управляемость, стоимость пересмотра) остаются в пределах, даже если метрика качества слегка гуляет. Это ближе к настоящему architectural fitness monitoring, чем просто accuracy.
* проблема в противоречии с тезисом David Deutsch о "трудноизменяемости" хорошего объяснения. Хорошее объяснение должно быть evolvable, то есть сохранить возможность изменений, но по David Deutsch (в его лексике) это выглядит как "плохое объяснение". Надо решить это противоречие. Hard‑to‑vary можно читать как “жёсткие связи между частями объяснения + отсутствие лишних степеней свободы”, evolvability — как “низкая стоимость изменения при появлении новых фактов/требований”, а конфликтовать эти идеи перестают, если ввести модульность и явные интерфейсы объяснения: внутри модуля объяснение hard‑to‑vary, а между модулями — управляемая изменяемость.

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

26. Если вы смотрите на литературу по LLM, агентам и людям, то характеризация для “рефлексии, мониторинга, контроля” часто просто разные имена для архитектурных -ilities:
* **Monitoring (SRL) / self‑evaluation / inconsistency detection → Observability** ([Frontiers][6])
* **Control (SRL) / strategy switching / backtracking / simulate‑or‑act policy → Controllability** ([Frontiers][6])
* **Self‑reflection as folding back (2601.06002) → Reversibility + runtime correction loop** ([arXiv][4])
* **Tree/branching/search → расширенная controllability (управление поиском)** ([arXiv][8])
* **Iterative refine / critique‑revise → Testability + controllability на уровне продукта** ([arXiv][9])
* **Episodic reflections stored for later → Evolvability (межэпизодная адаптация)** ([arXiv][10])

Именно в этом смысле “табличка мониторинг и контроль по времени и по архитектурным характеристикам” полезна: она согласуется с SRL‑моделями, где прямо выделены фазы (forethought/monitoring/control/reaction‑reflection) и области регулирования (когниция, мотивация/аффект, поведение, контекст). ([Frontiers][6])

И, конечно, разводим характеристики качества самого рассуждения ("пользовательские", прикладные -- что там можно использовать) и архитектурные характеристики рассуждения (связанные с его структурой/топологией), а также архитектурные характеристики (то, что замеряем) и fitness functions (как именно замеряем, какой метод замера).

[1]: https://nealford.com/books/buildingevolutionaryarchitectures.html "Building Evolutionary Architectures"
[2]: https://www.bredemeyer.com/whatis.htm "What is Software Architecture"
[3]: https://nealford.com/downloads/Evolutionary_Architectures_by_Neal_Ford.pdf "Evolutionary Architectures"
[4]: https://arxiv.org/abs/2601.06002 "The Molecular Structure of Thought: Mapping the Topology of Long Chain-of-Thought Reasoning"
[5]: https://arxiv.org/abs/2601.03905 "Current Agents Fail to Leverage World Model as Tool for Foresight"
[6]: https://www.frontiersin.org/journals/psychology/articles/10.3389/fpsyg.2017.00422/full "A Review of Self-regulated Learning: Six Models and Four ..."
[7]: https://arxiv.org/abs/2305.10601 "Deliberate Problem Solving with Large Language Models"
[8]: https://arxiv.org/pdf/2305.10601 "Tree of Thoughts: Deliberate Problem Solving with Large ..."
[9]: https://arxiv.org/abs/2303.17651 "Self-Refine: Iterative Refinement with Self-Feedback"
[10]: https://arxiv.org/abs/2303.11366 "Reflexion: Language Agents with Verbal Reinforcement Learning"
[11]: https://arxiv.org/pdf/2303.17651 "Self-Refine: Iterative Refinement with Self-Feedback"
[12]: https://www.thoughtworks.com/content/dam/thoughtworks/documents/books/bk_building_evolutionary_architectures_second_edition_free_chapter.pdf "Building Evolutionary Architectures"


## Перенос между предметными областями и следствия для педагогики

27. Работы по long-CoT в LLM, по рассуждениям агентов (живых и AI) с использованием world models, по рассуждениям людей, по обучению рассуждениям людей (learning sciences), по обучению презентации результатов рассуждений в форме длинных текстов -- они все ценны тем, что ввиду похожести обсуждаемых тем (при чётком удержании различий) довольно много результатов одних исследований применимо на практике для других тематик. Скажем, работы по long-CoT в LLM можно прямо использовать для идей в педагогике.

28. Связь с world models: понятие топологии и структуры меняются: CoT переходит в "граф действий/подзадач + обращения к симулятору или миру", self-exploration -- это branching и rollouts, self-reflection -- это выбор между "пересчитать", "перепланировать", "проверить гипотезу":
* Beyond Entangled Planning: Task‑Decoupled Planning…* буквально говорит языком “структуры”: проблема — **entangled contexts** (монолитная история, где ошибки расползаются), решение — декомпозиция в DAG подзадач и локальные контексты. https://arxiv.org/abs/2601.07577. Это очень близкая по сути “топологическая” идея, только в агентном планировании.
* а *Imagine‑then‑Plan* делает акцент на **многошаговых imagined trajectories** и **адаптивном горизонте lookahead** — это по смыслу управляемая self‑exploration, где структура траекторий (какой горизонт, где ветвиться) является ключом к качеству. https://arxiv.org/abs/2601.08955
* active inference критикуется как "нефальсифицируемость" для описания работы с world models, но это же просто математический аппарат, он и не может быть фальсифицируем (он умозрителен), другое дело, что его удобно использовать для описаний. Но есть и конкурирующие с active inference математические представления, какие они?
* можно обсуждать, как мышление людей похоже на мышление LLM и мышление с world models в агентах -- и делать педагогические выводы, учить хорошим рассуждениям по поводу эпистем (чистое мышление) и по поводу действий (методологическое рассуждение, стратегирование как поиск метода для получения результатов, затем планирование работ в мире, выполнение работ по плану, получение обратной связи и новая проблематизация по поводу того, какую проблему с миром решаем), но можно учить просто хорошим представлениям текста. Всё это как-то связано с сохранением хорошей структуры long-CoT.

29. Если принять логику Deutsch/Kay + результат 2601.06002, то образовательный вывод звучит так:
* **Учить не “писать длинно”, а “писать структурно” (Универсальным остаётся то, что длинногоризонтное поведение требует устойчивого сочетания углубления, проверки, исследования):** 1. **Deep reasoning**: локальные кластеры вывода (1–2 ключевых хода доведены до конца, а не 10 намёков). 2. **Self-reflection**: явные возвраты и проверки (“какое допущение я сделал 2 абзаца назад?”, “что если оно неверно?”). 3. **Self-exploration**: контролируемые ветвления (“альтернатива A/B, почему выбираю A”).
* **Оценивать эссе по “связям”, а не по маркерам.** Статья прямо показывает: ключевые слова могут ускорять обучение, но не являются сутью; важна сохранность “траектории поведения”.
* **Не ожидать, что конспект‑саммари заменит разбор.** Сжатие может сохранить результат, но разрушить структуру, которая нужна для переноса/обучаемости.
* **Делать ставку на построение ментальных моделей и связей.** Это совпадает с тем, что learning science считает ключевым: формирование организованных структур знания и моделей (mental models), а не накопление разрозненных фрагментов. Проблема не в репрезентациях как таковых, а в том, что образование часто поощряет узнавание репрезентаций вместо построения смысла, то есть моделирования. Когнитивная литература задаёт использование ментальных моделей через "лестницу причинности" (prediction (наблюдательные) vs control (интервенции) vs explanation (контрфактуалы)) в их использовании -- https://pmc.ncbi.nlm.nih.gov/articles/PMC10695676/. Generative learning — это активное “делание смысла” через ментальную реорганизацию и интеграцию с предшествующим знанием, что повышает перенос на новые ситуации, https://link.springer.com/article/10.1007/s10648-015-9348-9. В обзоре Fiorella (2023, https://link.springer.com/article/10.1007/s10648-023-09769-7) предлагается рамка “generative sense‑making” с тремя режимами: explaining, visualizing, enacting, и подчёркиваются границы применимости и важность гайдинга/тайминга активностей. Это очень похоже на “топологию”: не любой “длинный текст” даёт понимание; важен тип и порядок когнитивных операций (объяснить/смоделировать/сделать/проверить/исправить).

30. Наличие хорошего объяснения (context для мышления = структура, в которой факты начинают что-то значить) ценнее "просто IQ" -- по Alan Kay, "Context is worth 80 IQ points"! Сюда же -- Фейнман про "когда я беру в руки карандаш и бумагу, я становлюсь умнее". И тут ход на обучение сначала чтению и пониманию объяснений (и что из них плохие, а что из них хорошие), а затем и обязательно письму:
* В статье *Computers, Networks and Education* (1991) Alan Kay прямо пишет про медиа-сдвиг от “глубины” к “валюте новостей”, а затем к визуальной немедленности, и отмечает, что форма носителя диктует “context-free factoids”. В связке с вашим “пословицы vs эссе” ключевой пассаж такой: где бы сегодня публиковались “Federalist papers”? **Не в газетах — “each essay is too long”;** на сетевых дисплеях возникает склонность к “pictures… and short ‘bumper sticker’ sentences”, потому что это “what displays do well”.
* Но у Кэя есть важная надстройка: он не останавливается на тезисе “давайте всем длинные эссе”. Он говорит: окей, статические эссе — это хорошо, но **ещё сильнее** может быть публикация *моделей/симуляций* с гиперссылками на источники и возможностью менять предпосылки и проверять последствия (то есть удерживать причинность уже как интерактивный объект). Ссылка на Мюррея Гелл-Манна: современное образование как "величайший ресторан, где тебя кормят меню", дают освоение репрезентаций вместо освоения самих идей -- и это совпадает с критикой LLM по сравнению с критикой world models. Людей надо тоже учить не как LLM, а как world models). Цель — не “усвоение длинного текста”, а **удержание цепочек причин-следствий** и возможность критики/вариаций в контрфактическом вопрошании/inquiry к модели.
* В более позднем тексте *The Future of Reading Depends on the Future of Learning Difficult to Learn Things* Кэй делает ещё более образовательный акцент: письмо/чтение — это технологии мышления, которые позволяют удерживать формы аргумента, плохо работающие в устной коммуникации; и формулирует жёстко: **“the future of ‘reading’ depends on the future of ‘writing’”**. Расширение понятия writing на практически тождественное моделированию у Alan Kay -- как системы, которые пытаются “capture, transmit — and most especially — explain important ideas” (то есть письмо/запись как носитель именно объяснений). Письмо ценно тем, что может удерживать формы аргумента, которые плохо работают в устной речи, и расширяет «с чем думать». Это уже напрямую про необходимость учить людей *производить* длинные структуры (writing/modeling), а не только “потреблять” (reading/quering).

31. **Не универсально (зависит от типа модели):**
* конкретная “топология” в терминах токенов и текстовых шагов (LLM‑специфика);
* набор маркеров/паттернов, через которые реализуется self‑reflection (у diffusion‑LLM, например, есть архитектурные ограничения). https://arxiv.org/abs/2510.09544

32. **Довольно универсально (переносится как функциональный принцип):**
* длинногоризонтное мышление/планирование почти неизбежно требует (i) связного углубления, (ii) проверок/ревизий, (iii) управляемого исследования альтернатив — и “качество” определяется тем, как эти операции организованы во времени/графе.
* “иметь доступ к репрезентациям/симуляции” недостаточно: критично уметь **калиброванно** выбирать, когда и как ими пользоваться (это видно и у world‑model‑агентов). https://arxiv.org/abs/2601.03905
* для людей learning sciences описывает тот же класс идей как **sense‑making, ментальные модели, метакогниция, representational competence**, с сильными границами применимости из‑за когнитивной нагрузки и уровня подготовки. https://www.nationalacademies.org/read/24783/chapter/3

33. Learning sciences обычно не говорят “понимание про мир, а не про репрезентации” в смысле отказа от репрезентаций. Скорее: **понимание требует умения работать с несколькими репрезентациями и переводить между ними**. В science education прямо говорится, что обучение требует комбинирования информации из нескольких внешних репрезентаций (тексты, формулы, графики и т.д.), https://www.frontiersin.org/journals/education/articles/10.3389/feduc.2024.1459603/full. Есть данные, что множественные репрезентации могут улучшать обучение и решение задач, но при этом создают высокие требования; возможна “representation dilemma”, когда репрезентация содержит нужную информацию, но ученик не извлекает пользу из‑за недостатка representational competence, https://pmc.ncbi.nlm.nih.gov/articles/PMC10457013/. Это практически “меню‑проблема” в терминах Kay: *меню богато, но ты не умеешь “есть”*.

34. Проблемы образования людей: умение читать длинные тексты, умение удерживать длинное рассуждение, умение писать длинные тексты, умение уточнять и сжимать длинные тексты (моделировать). Тут проблема в том, что продвинутые методы представления знаний не удерживаются (например, языки паттернов удержались только в software architecture, онтология только в спонсируемых государством областях вроде медицины и биологии и единичных сервисах вроде google knowledge graphs, причинно-следственные графы SCM до сих пор "не пошли в народ", создание интерактивных моделей по линии Alan Kay не массово, но как-то живёт в финансовых моделях в excel).

35. Декодер (читатель, bounded observer) должен быть обучен:
* структура должна быть **доступной** bounded observer: иначе автор оптимизирует метрику структуры, которую никто не может распаковать.
* отсюда следует понятие **оптимальной детализации**, scaffolding, и необходимость нескольких “версий” объяснения под разные уровни подготовленности.
* характеризация читателя -- отдельная большая проблема (как набор характеристик, так и замеры значений), но не только язык, уровень понимания и т.д., но включая такие неявные параметры как наличие времени, допустимая когнитивная нагрузка, особенности архитектуры (учим LLM, world model или человека)
* критерии успеха понимания (перенос? контрфактуалы? интервенции? способность исправлять ошибку?) и ходы на формулирование Парето-фронта понимания по этим критериям.

(Comment on this)

Position paper про "длинногоризонтное мышление" (long-CoT) как мышление письмом/моделированием (1/2)
Я позавчера пожаловался на то, что наши инженеры-менеджеры не так уж хорошо удерживают структуру рассуждений в длинных текстах (https://ailev.livejournal.com/1793289.html): "Похоже, что надо отдельно учить "длинным точным письменным рассуждениям", мы этому недоучиваем. Нужна какая-то теория про тексты, и я займусь этим буквально сегодня-завтра, чтобы обсудить на лаборатории по рабочему развитию: идеи совместного рассмотрения управления точностью текста, мышления письмом/моделированием на стадии "как из заметок собрать связный длинный текст и как убедиться, что он связный", рассказа о длинных текстах от 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-агентами".

"Длинные тексты" очень хитры по своему устройству. Я когда-то уже обсуждал это как "гиперкниготексты" -- различал "удобство для письма" (справочники, wiki, энциклопедии) и "удобство для понимания" (книжки для чтения, ибо энциклопедии не читают) -- https://ailev.livejournal.com/103692.html, далёкий 2003 год! С тех пор мы стали все умнее, но проблема "длинных текстов" продолжает беспокоить -- и дело даже не в инструменте/экзокортексе, а в самом понимании, как там черновик превращается в беловик, как связано мышление для получения результата-как-в-энциклопедии (методологическая работа) и мышление для получения понимаемого-результата-как-в-учебнике (методическая работа).

Сказано -- сделано. Я потратил два дня (timeboxing: когда время вышло, задача считается решённой настолько, насколько успевает решиться). TL;DR для меня: публикую задел по "длинным рассуждениям с использованием памяти в локальных представлениях, aka long-CoT", обзывая его "position paper", а развивать это всё буду потом, ибо оказалось, что там существенно нужны паттерны мышления, которые будут хорошо проработаны в ходе выполнения плана по FPF от 1 февраля 2026 (https://ailev.livejournal.com/1788706.html): понятие архитектуры, архитектурные характеристики, граф трансдукций и функциональные описания (функциональная архитектура). Это оказалось ключевым. Заодно сегодня-завтра выйдет GPT-5.3 и через месяцок-другой выйдет Codex App для Windows, так что работа с большими текстами будет попроще. Поэтому я делаю просто дамп текущего "задела", пусть его поизучают искусственные интеллекты. Я не думаю, что кто-то будет подробно разбираться с такими длинными и сложными текстами, я сегодня обсуждал основные идеи этого текста у нас на встрече в лаборатории рабочего развития, но людей такой квалификации для обсуждения очень немного -- а уж у кого хватает времени возиться с подобными сыроватыми идеями -- так и совсем нет, один я. А потом? Потом я использую вот этот "задел" для развития FPF, пополню число паттернов и поправлю уже имеющиеся тамошние паттерны.

Текста много -- поэтому два поста. Не поверите, но от LLM там не так уж много, всё своими ручками вколачивал, а что касается Markdown, так я решил, что буду и в ЖЖ сам его руками писать, так что уже несколько постов у меня перечисления вместо "-- " начинаются с "* ".

# Position paper про "длинногоризонтное мышление" (long-CoT) как мышление письмом/моделированием и компиляция итогового эссе

Этот текст вносит несколько идей, связанных с long-CoT:
* онтология, восходящая к обсуждению рассуждений как метода (ход на методологические описания, разделяющие метод и работы, а также промежуточные рабочие продукты вроде черновиков и конечные результаты метода вроде эссе), а также онтология, вводящая роли автора процесса/метода рассуждений, автора рассуждения, автора "компиляции" в итоговое представление, понимающего читателя. Тем самым long-CoT как "трасса рассуждений" (онтологическая сущность может оказаться довольно сложной для "трассы") относится к самым разным понятиям, можно поднимать лексическую точность разговора, делать mapping разных теорий к нейтральной лексике (хотя лексика не предлагается в явном виде, но онтология обсуждается).
* обсуждение тезиса "длина CoT и длина текста -- это прокси для сложной структуры" как переход к архитектуре, чья предметная область как раз -- обсуждение структуры (ход на эпиплексию, а не перплексию). Архитектурные характеристики разных long-CoT в отличие от характеристик пользы. Объяснения и рассуждения как эволюционирующие сущности, следовательно, у нас тут evolutionary architecture с evolvability как одной из центральных архитектурных характеристик.
* операции методов устойчивого длинногоризонтного рассуждения: углубление, ревизия, исследование альтернатив — как функциональные инварианты, встречающиеся в различных дисциплинах -- что-то "первопринципное" для мышления.
* Единицы модульности: commit/MOVE как минимальная единица закрепления и стоимости отката (мост к evolvability и cognitive debt).
* компиляция long-CoT (трассы) в итоговый текст -- и измеримость пользы (value) текстов в части их "понимания" через показатели вроде epiplexity и через графовые метрики reasoning-траекторий -- в том числе зависимость от подготовленности читателя (для замыкания разных циклов совершенствования текстов). Чёткое различение "пользы long-CoT" и пользы итоговых ответов, деление пользы на "прикладную/предметную и архитектурную" (возможно, более дробно -- в соответствии с самыми разными viewpoints).
* переносимость выводов о важности топологии/структуры long-CoT для LLM на world models и далее на людей как агентов, базирующихся на LLM и world models. Педагогические предложения.
* Модель читателя: структура должна быть не просто “богатой”, а доступной bounded observer, иначе оптимизируется не то. Методология (решение и компиляция в идеальную модель) и методика (компиляция идеальной модели для конкретного читателя) -- всего три шага, а не два. Работа с типовыми читателями (viewpoints и viewpoint bundles как "модуляторы" вывода).

## Онтология.
1. Онтологическая путаница-1 в обсуждении long-CoT -- tokens trace рассуждения-inference (включая zettelkasten в ходе мышления письмом для прихода к какому-то результату путают с tokens эпистемы, представляющей результат рассуждения-inference (итоговый текст, эссе, содержание книги). Итоговое "убеждающее рассуждение" (от "риторики как убеждающей речи") обсуждается в части сложной внутренней структуры: явные предпосылки, цепочки причинности, альтернативы, границы применимости, “интерфейсы” между частями объяснения. Эта итоговая эпистема нужна, чтобы другой агент (читатель, студент, другая модель) мог воспроизвести и переиспользовать объяснение по минимальному материалу (феномен "понимания"). А вот рассуждение-след -- это состояние временной памяти при процессе-рассуждении-inference. Увы, отглагольное существительное "рассуждение" может означать и процесс, и результат, и промежуточный результат (черновик и лог/архив как внешняя память автора) "в ходе процесса", так что тут нужно тщательно разводить термины -- для этого можно, например, использовать при разговоре о long-CoT методы semantic precision restoration из FPF (использовать не один термин long-CoT, а набор терминов для объектов разных типов). То же нужно делать и для остальных путаниц. Это существенно поднимет общее число терминов в речи, но существенно снизит семантические ошибки.

2. Онтологическая путаница-2 в том, что "эпизод рассуждения" как "промежуточная память для процесса получения результата":
* имеет структуру, её вполне можно рассматривать теми же методами, что и "итоговый текст объяснения" (находить ошибки, пропуски, менять представление),
* существует для bounded observer -- полезность не в minimum loss для презентации чего-то, а в максимуме усвоенной структуры при ограничениях, и это верно для автора в процессе (внешний черновик и журнал/log увеличивает доступную структуру) и для читателя конечного текста (эссе должно быть "структурно понимаемым", передавать структуру по-максимуму без потерь, с учётом подготовки читателя, которому может недоставать знаний, например, может не знать языка эссе, надо будет передать знание языка)
* архитектурные свойства (-ilities) применимы к обоим: Observability / controllability / reversibility / modularity / testability / evolvability можно применять и к черновику, и к журналу изменений "во время эпизода", и к итоговому тексту "после эпизода", но ещё и к описанию процесса их получения (тоже текст!) -- результат эпизода мышления о методе рассуждения.

3. Онтологическая путаница-3 из-за различий в том, что ошибочно считают "одним и тем же текстом" или "одним и тем же процессом":
* процесс, черновик-память, результат отличаются DesignRunTag: процесс имеет описание времени design процесса, черновик как runtime память мышления, но design time результата, результат неявно указывает на время run/прогона процесса чтения (в каком порядке читателю удобно освоить причинность). Тут некоторый граф создания автора (с его процессом), текста (с его последовательностью), читателя (с его процессом понимания). И ещё понимание, что эпистемы пассивны, а все эти run делают системы -- авторы описаний метода мышления, авторы в ходе мышления, читатели в ходе понимания (все системы, конечно, "в ролях").
* черновик и лог с альтернативами, которые были отброшены, локальные эксперименты, тупики с противоречиями -- а результат это обычно сжимает и линеаризует, "хорошее эссе" выглядит как clean reasoning, но reasoning могло быть насыщено самыми разными ошибками и совсем не clean. Можно считать, что речь идёт об "оптимизирующей компиляции" результатов рассуждения в памяти черновиков в итоговый текст -- и там уместны многие аналогии (скажем, "суперкомпиляция" как синтез абсолютно нового текста, который по результатам даёт то же понимание, что и несжатый черновик со всеми тупиковыми ходами). Конечно, придётся объяснять, что именно сохраняется (какие инварианты структуры, доказуемости, объяснимости), что именно разрешено менять (линеаризация, перестановка, сжатие, добавление scaffolding для читателя), что запрещено “вшивать” при компиляции (например, подмена статуса доказательности, скрытая смена окна времени или ситуационного контекста, добавление несогласованных допущений и ограничений).
* один и тот же текст может быть планом размышления (что я делаю дальше), объяснением для читателя (почему это верно и когда применимо, в том числе читатель может быть исполнителем плана мышления), объектом обучения и оценки (передачей понимания, примером, планом упражнений для передачи понимания). И вот это смешение ролей текста-эпистемы является главным источником каши в long-CoT обсуждениях. Разные роли в разных методах/процессах, разные использования текста и разные результаты, разные интересы разных ролей.
* метрики качества для разных ролей разные: если это спецификация процесса, то важны эффективность поиска, устойчивость к дрейфу, способность переключаться, цена отката (и это может быть или спецификация метода, или заполнение слотов для плана -- или методология со стратегированием как выбором метода размышления, или операционный менеджмент работы). Для текста-результата важны объяснительная "схватываемость" (ещё и разная для разного уровня подготовки читателя, ибо "декодер должен быть обучен"), модульность, тестируемость, переносимость, обновляемость (и тут ещё надо учитывать разницу архитектурных характеристик и характеристик качества, ещё и надо рассматривать Парето-фронт, ибо могут быть противоречия между характеристиками и надо будет иметь разные варианты текста, чтобы закрыть не одну точку на Парето-фронте, а несколько). Ещё и может быть путаница между "хороший текст всегда следствие хорошего процесса" (это не так) и "плохой процесс всегда выдаст плохой текст" (тоже может быть не так).

4. Довольно долго обсуждалось отличие "ответа в один ход" и "многоходового рассуждения" (thinking, reasoning) и ход на CoT и затем long-CoT с упором на длину. Затем оказалось, что длина — это прокси, качество как рассуждения, так и его результата определяется структурой; длинная форма нужна как внешний носитель структуры и контур самопроверки для bounded observer. Ярко это выражено в статье "The Molecular Structure of Thought: Mapping the Topology of Long Chain-of-Thought Reasoning", https://arxiv.org/abs/2601.06002. “Длинное эссе” полезно не тем, что оно длинное, а тем, что оно хранит недосказанное в короткой форме — проверочные связи, альтернативы, границы применимости. Поэтому ход тут от "сухого описания", которое начинает рассматриваться как "метод обеспечения понимания: алгоритм для загрузки авторского текста в мозг читателя", ход на операционализацию структуры (операции, которые работают не столько с текстом, сколько со структурой -- молекулярная триада; reasoning‑graphs; topology/length generalization в списке работ ниже. Кроме статьи про molecular structure есть множество работ в поддержку идеи "reasoning traces нужно рассматривать как структурные объекты (графы, доказательства, траектории), и именно структура/топология объясняет обобщение и обучаемость" (без молекулярной метафоры в первой же статье из списка вывод примерно такой: "“Хороший” long‑CoT — это не просто длинный текст, а траектория со стабильным распределением локальных переходов между режимами: последовательное углубление (deep reasoning), циклы ревизии (self‑reflection), ветвления/альтернативы (self‑exploration)", причём это можно рассматривать как "базовые вариации длинногоризонтного мышления -- углубление (строить связную цепочку следствий), самоконтроль/ревизия (возвраты, проверки, исправления), исследование (ветвление, альтернативы, “что если…”"). И эти операции появляются не только в текстовых CoT, но и в планировании, поиске, доказательствах, проектировании, научном объяснении — просто в другом “носителе”."):
* Topology of Reasoning: Understanding Large Reasoning Models through Reasoning Graph Properties (arXiv:2506.05744, 2025) — строит reasoning graphs и анализирует их свойства/метрики. Это почти та же мысль, но выраженная без метафор: качество reasoning связано с графовыми свойствами траекторий (цикличность, связность, пути и т.п.).
* Mapping the Minds of LLMs: A Graph‑Based Analysis of Reasoning LLMs (Findings EMNLP 2025; arXiv:2505.13890) — тоже “графовый взгляд”: представление рассуждений как графов и анализ связи структурных характеристик с поведением/качеством.
* What Makes a Good Reasoning Chain? Uncovering Structural Patterns in Long Chain‑of‑Thought Reasoning (arXiv:2505.22148, 2025) — максимально “в тему”: именно структурные паттерны хороших длинных рассуждений.
* Boule or Baguette? A Study on Task Topology, Length Generalization, and the Benefit of Reasoning Traces (arXiv:2602.14404; 16 февраля 2026) — это уже после вашей январской статьи и очень релевантно. Они формализуют датасет в Lean и сравнивают модели, обученные на reasoning traces (proofs), с direct prediction; фокус — как меняется польза traces при росте “топологической сложности” и длины доказательств.
* LLMs Can Easily Learn to Reason from Demonstrations — Structure, not content, is what matters! (arXiv:2502.07374, 2025) — ключевой результат буквально в названии: модель может учиться long‑CoT из относительно небольшого числа примеров, но ломается, когда рушится порядок/логическая структура шагов, тогда как многие “контентные” искажения менее критичны. Это почти то же утверждение, что у 2601.06002 про “isomers”: не любая длинная цепочка обучает; обучает та, у которой правильная структурная организация шагов и переходов.
* пригодность траекторий для студента (2601.14249)
* structure‑aware compression (2505.14582; 2505.16838; 2602.10048)
* в world models — как необходимость уметь управлять многошаговыми роллаутами и декомпозицией (2601.03905; 2601.08955; 2601.07577).

5. Структуры могут быть абсолютно разные. Так, может быть крайне компактная структура решения, но крайне сложная для обучения (belief revision problem в онтологии: "добавление одного маленького факта заставляет перестроить всю огромную онтологию", а также belief about beliefs -- усилия по переубеждению могут быть запредельны, хотя само решение очень простое, например, "вера в плоскую землю" или "палец давит на стол с той же силой, что стол давит на палец" -- контринтуитивность может требовать дополнительных усилий). Поэтому надо различать структуры решений (и процессы их получения), структуры передачи понимания (и процессы их получения). Нельзя считать, что есть универсальный текст, который оптимально решает все задачи: как передаёт способ решения, так и добивается понимания. Можем условно считать, что есть два такта: методологической работы (провести рассуждение и откомпилировать черновики в компактное итоговое эссе) и методической работы (компактное итоговое эссе перевести в вид, удобный для передачи понимания читателю). По большому счёту, learning sciences работают с методическим шагом (добиться понимания solution реальным читателем), а вот исследователи LLM и world models чаще всего с методологическим (найти solution и "абстрактно объяснить" solution "идеальному читателю"). Грубо говоря, первые выдают "справочник по решению проблемы", вторые -- "учебник по решению проблемы" (а по справочнику понимание обычно не передаётся, понимать проще по учебнику). Это ещё и ещё раз говорит, что тексты нужны разные, соответствующие разным viewpoints и несущие разные структуры, которые надо сохранять в тексте при его отображении. Это сильно пересекается с неявностью целей всех рассуждений про long-CoT:
* улучшить качество решения здесь‑и‑сейчас (instrumental reasoning),
* сделать процесс управляемым, аудируемым, воспроизводимым, изменяемым (архитектурные характеристики, причём для процесса, а не результата)
* обучить другого агента (передать понимание и навыки, неявное включение пост-компилирования/методической работы, а не только работы поиска решения и оформления вывода решения).

6. Понимание -- это владение объяснительными связями (почему и как одно следует из другого), а не только знание отдельных фактов "что верно". Базы данных, сборники твитов и т.д. не обеспечивают понимания -- различие между knowledge/true belief и understanding/explanatory grasp. Это, например, обсуждается в https://plato.stanford.edu/entries/understanding/. Понимание источником имеет эпистемологию, а выходом не онтологию (факты о том, что есть в мире), а методологию -- "как делать", исходя из понимания. Понимание даёт возможность предложить метод изменения мира в желаемом направлении. Понимание — это не отказ от репрезентаций, а способность строить, запускать и пересобирать модели мира через репрезентации; “длинная форма” (эссе, CoT, траектория, rollout) полезна ровно настолько, насколько она поддерживает углубление + самопроверку + исследование, не превышая ресурсные ограничения системы.

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

8. Текст эссе как итога мышления -- это не окончательно оптимальная форма знания, только с письмом как пассивной эпистемой нельзя работать, более продвинутая форма -- модели (объяснения, причины, всё вот это -- про изменяемые состояния чего-то, что надо понимать, про "законы мира" и допустимость. В принципе, можно и эссе рассматривать как модель, но с этой моделью как "декларативным алгоритмом" работает мозг/вычислитель читателя, превращающий "пассивную эпистему" в исполняемую программу, меняющую состояния в ходе исполнения. Вот эта двойственность "текст как пассивная эпистема" и "текст как декларативный алгоритм, по которому затем работает мозг читателя" (возможно, читатель даже в ходе выполнения алгоритма-из-текста делает действия в окружающем физическом мире, ибо он embodied) -- важное замечание. Понимание может быть "написанного в эпистеме как пассивном знании", но может быть "изменений, которые можно делать в мире с использованием этой эпистемы как алгоритма". Алан Кей был один из главных, кто в своих работах предлагал вести образование от разрозненного понимания коротких фактов (уровень "пословиц") к пониманию длинных текстов с описанием причинно-следственных связей (эссе) и далее к моделям, допускающим ответы на контрфактические вопросы (а что, если бы...) -- и тут важно, что модели подразумевают возможность совместной интерактивной работы человека-агента и компьютера с tooling.

9. Проблема репрезентаций и нотаций. Представление знания многолико в части способов репрезентаций разных акцентов в разных нотациях:
* онтология (объекты, knowledge graphs),
* методология (акцент на методы в каком-то контексте для получения какого-то результата, языки александрианских паттернов против языков механизмов с эффектами против классических алгоритмических языков, проблемы "пошаговых алгоритмов" и "факторизации методов" ввиду неразложимости на "шаги", параллелизации и синхронизации),
* объяснения (причинно-следственные графы SCM в виде текстов, а при повышении точности и сжатии представления -- моделей для задания контрфактических вопросов, линия рассуждений об эссе и моделях от Alan Kay и рассуждений David Deutsch об объяснениях, рассуждений Marletto о представлении научного знания).
* Если учесть, что текст в какой-то мере это "алгоритм загрузки в мозг читателя" и это тоже задаёт структуру, то можно вспомнить формат александрианского языка паттернов -- это ход на добавление достаточного числа причинно‑следственной информации, по которой можно реконструировать и переиспользовать объяснение. Паттерн — это формат отдельных операций, готовых к откатке как коммитов/MOVEs алгоритма рассуждений и алгоритма загрузки в нейросеть агента-читателя + объяснение причин/границ, чтобы читатель мог делать «безопасные/откатываемые изменения» на шаги, описываемые паттерном. Выдача "просто алгоритма" (Solution) без традиционных для языка паттернов разделов Problem Frame, Problem, Anti-patterns, Consequences и т.д. -- опускает эти связи, хотя и короче. Это хорошо связано с тем, как строить skills для LLM (процедурное знание "без объяснений"), это связано с тем, что код программ явно недостаточен для объяснения и нужны какие-то комментарии (и становится потихоньку понятным, какие именно комментарии, это традиционная тема обсуждения в pattern languages).

10. След рассуждения в форме токенов — это реальный причинный механизм решения или пост-хок рационализация или даже результат фейка? Что именно мы мониторим: “правильную структуру”, “правдоподобный рассказ” или что иное? Эксперименты показывают, что LLM могут "думать" (в латентном пространстве) одно, а дальше намеренно выдавать отнюдь не всё в токены thinking. В современных обсуждениях LLM это ключевой узел: CoT может быть полезным инструментом (улучшает поиск/самопроверку), но не гарантированно объясняет, почему модель пришла к ответу. По большому счёту -- это вопрос про то, как связано рассуждение в распределённых представлениях и его поддержка в локальных представлениях. Тут всё про sequential texts (токены), но есть же рассуждения и параллельные, а ещё есть латентные рассуждения, для которых это всё неверно -- но и там можно говорить иногда о токенах вроде DroidSpeak или COCONUT архитектур. Опять же: как это педагогически? Учить людей "осознанно по шагам", а затем считать, что "автоматизируется как-нибудь в латентную интуицию шагов мышления"? Тут ещё одно соображение, что "длинные тексты" признак не только богатой структуры, но и overthinking (например, статья "Think Deep, Not Just Long: Measuring LLM Reasoning Effort via Deep-Thinking Tokens", https://arxiv.org/abs/2602.13517, статьи "Can Pruning Improve Reasoning? Revisiting Long-CoT Compression with Capability in Mind for Better Reasoning", https://arxiv.org/abs/2505.14582). Это иногда связывают с "безопасностью" (может ли LLM симулировать поток токенов в long-CoT, думая на совершенно другую при этом тему и "сознательно" маскируя при этом реальные шаги мышления в "черновиковом" следе long-CoT, "Language Models Don't Always Say What They Think: Unfaithful Explanations in Chain-of-Thought Prompting", https://arxiv.org/abs/2305.04388). Так что этот процесс размышления перед ответом надо тоже как-то оценивать (и тут тоже есть уже работы, "Evaluating Step-by-step Reasoning Traces: A Survey", https://arxiv.org/abs/2502.12289). Грубо говоря, иногда CoT таки инструментальный интерфейс, полезный для управления и обучения, но иногда -- "нарратив", которым бесполезно управлять и который бесполезно использовать. Само понятие long-CoT оказывается проблематичным. В обучении людей это часто проявляется: таланты интуитивно отлично решают задачу, но затрудняются словами объяснить, как это они делают (и это отличается от задачи отображения мышления через какие-то точки в латентном пространстве на квантованное пространство немногих известных токенов, "ограниченный словарь" -- иногда выражаемой "изречённое дао -- ненастоящее дао". Нет, речь идёт не о "кривом отображении", а независимых процессах мышления и создания "нарратива").

## Динамика
11. Ещё одна трудность в том, что итог может рассматриваться и как результат работы (операционный менеджмент, планирование ресурсов) и как результат выполнения метода (содержательно там минимально методы "разработки" для достижения пользовательских характеристик результата, quality и "архитектуры" для достижения результата, но ещё и многие другие -- проблематизации и постановки задачи, проверки-verification и приёмки-validation и многое другое, что традиционно обсуждается в software engineering, который в рамках software process тоже обсуждает коллективное производство эпистемы-кода, тоже как результат "рассуждения", часто коллективного). И топология/структура обсуждается и для процесса, и для работы (процесс и работа -- два view на "изменения в мире", процесс -- это design-view/метод/рецепт, а работа -- это run-time view, операционного менеджмента).

12. Объяснение почти неизбежно требует длинной формы: эссе как развёрнутый разбор, траектория рассуждения. Не потому, что «длина магична», а потому что хорошее объяснение (объяснительное знание-для-понимания, а не набор фактов или предсказаний) обычно включает явные предпосылки, цепочку выводов, проверку на противоречия, альтернативы и границы применимости, связь с другими моделями/контекстами. Но всё-таки в long-CoT длина -- это грубое прокси для структурной сложности, ибо в конечном итоге важна топология/структура, а не длина. Более того, и топология может быть сокращена ("Can Pruning Improve Reasoning? Revisiting Long-CoT Compression with Capability in Mind for Better Reasoning", https://arxiv.org/abs/2505.14582).

13. Ход образования -- выход на ментальные модели, которые дают понимание, а не просто хранят отдельные факты. Но при обучении важно не просто письмо само по себе, а тип когнитивной работы при письме (письменное объяснение само по себе не всегда даёт выигрыш, ибо важны условия: например, self-explaining может быть эффективнее, чем “объяснять воображаемому ученику”, "Learning by writing explanations: Is explaining to a fictitious student more effective than self-explaining" -- https://www.sciencedirect.com/science/article/abs/pii/S0959475220307337).

14. Если выходить за рамки "подготовки одного текста" на уровень "подготовка многих текстов" (передача большого понимания) и смотреть на методику, то надо смотреть в сторону технологий "мышления письмом", плавно переходящим в "мышление моделированием" в https://ailev.livejournal.com/1513051.html

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

16. Связь всех этих идей с первыми принципами: объяснения должны включать ограничения, чтобы предохранить от решения нерешаемых проблем (https://arxiv.org/abs/2512.01661). distinguishing objective unsolvability (inherent contradictions) from subjective capability limitations (tasks exceeding model competence). Current LLMs often conflate these dimensions, leading to hallucinations in which they return confident answers to inherently unsolvable queries. Этот тезис надо довести до обучения людей: "не надо изобретать вечный двигатель".

17. Связь с ниткой идей "интеллект -- это искусство сжатия" (жми, господь!, https://ailev.livejournal.com/1414038.html в 2018 году ещё не имеет этого вывода, но позже появляется целое направление исследований "сжатие" -- и новые формы как дистилляция, прунинг, моделирование, имитация и т.д.).

18. Важны операции с разными упомянутыми текстами и описаниями трасс мышления как с эпистемами: это или проекции (безэффектные) или механизмы (с эффектами), и тут можно отдельно смотреть, как они специализируются именно для рассуждений и long-CoT. Все эти последовательности операций хорошо выражаются в форме графа трансдукций в эйлерианском представлении, что позволяет как-то инструментализовать поток мышления как "мышления письмом" (с использованием внешней памяти, long-CoT). В FPF есть типовой набор канонических глаголов слот-операций "над содержимым/слотами" (fill, clear, retarget, substitute, resolve, mutate(or modify), pass), это даёт возможность перевести обсуждение рассуждений в описание графа трансдукций с GateCrossings и соответствующими замерами, и ещё это всё можно будет компактно учить в знакомых общих терминах, а не "специальных для long-CoT" (уровне мета-мета-модели, первых принципов, а не вторых принципов из ML или learning sciences):
* “ревизия” можно расписывать как resolve inconsistency, retarget assumption, clear branch, substitute lemma
* “исследование альтернатив” как fill alternative slots, pass кандидаты в selector, resolve контрпримером
* “углубление” как fill consequence chain, resolve missing premise.

Продолжение (пункты 19-35) в https://ailev.livejournal.com/1794023.html

(Comment on this)

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)