Начинаем сентябрь 2026: намётки очередного планов громадья (1/2)

ailev · 23.Август.2026 19:57:13

Это начало текста (1/2), продолжение в Начинаем сентябрь 2026: намётки очередного планов громадья (2/2)

Февральское планов громадьё выполнено, думаем дальше – но сначала надо как-то удавить мультитаскинг
Главное событие сегодняшнего дня – это окончание онтологического ремонта FPF, который начался ещё в начале июля сразу после первого семинара и шёл два месяца. Этот рефакторинг много чего захватил: много паттернов пришлось просто переписать. И ещё опубликовано более-менее подробное описание экосистемы FPF: главным образом то, как делать концептуальный синтез в ходе создания отдельных DPF и DPF suites (наборов DPF, ибо часто эти DPF используются не по одиночке, а наборами). Результаты уже опубликованы, монолит подрос до 13M знаков: GitHub - ailev/FPF: First Principles Framework (FPF): Pattern language and core specification for admissible action in problematic engineering, research, and mixed human/AI work. · GitHub. По факту я закончил планы, громадьё которых я объявил в феврале 2026 – Начинаем февраль 2026: громадьё планов по FPF: ailev — ЖЖ; семимесячный марафон закончен, размышляю над очередными планами.

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

Работает не человек, а довольно сложная и хрупкая система-киберличность
Взял третью подписку ChatGPT Pro – ибо две предыдущие улетали за пару дней круглосуточной работы агентов, а в неделе семь дней – трёх подписок должно было почти хватать. Неожиданно третья подписка пошла очень медленно. Расследование показало, что это была временная серверная деградация GPT‑5.6 Sol: первый ответ модели увеличился с 4.2 секунды до 8.5 секунд, а полный модельный шаг с 8.8 секунд до 22.9 секунд. Замедление резко началось 19 августа около 03:00 МСК, одновременно у обеих независимых пар агентов, и закончилось 21 августа около 06:00. Понятно, что квота расходовалась медленней вдвое, но и работа шла медленней (примерно 51 час модель обслуживала запросы в 2.5 раза медленнее) – что было хорошо заметно.

Как я это всё узнал? Попросил своего ПочинкаWindows3 (ха-ха, это третье поколение агента, целая династия) провести расследование того, что там такое происходит. Конечно, никаких объявлений о замедлении работы GPT-5.6 Sol мы не увидели. Ещё я боролся довольно долго с перескоком модели Sol Pro (не путать с подпиской Pro) на модель Sol Instant, а ещё я за пару дней видел синие экраны смерти моего компьютера (эти BSOD уже давно чёрные, но из песни слов не выкинешь, за десятки лет привыкли), после одного из них слетел поисковый индекс с полутерабайта моих файлов, и потребовалось собирать его заново. Вспоминаю программистскую молодость: там ровно всё такое и было, даже подозрения, что “это ошибка машины” (то есть электроники, а не софта – мне агент так и сказал, что BSOD был в гипервизоре, причём пару раз по разным поводам, и это намёк, что Microsoft с Windows, Intel с его новенькой архитектурой процессора и ASUS с его новенькой машиной слегка не договорились и недоотладились, се ля ви). Какая тут “мораль истории”?

Возможность выполнить работу имеется не столько у человека, сколько у сложной системы киберличности “человек + модель LLM и режим вроде xhigh или Max + harness + skills + память + инструменты + компьютер + провайдер связи + ещё много чего” в какой-то определённый момент времени и в какой-то определённой ситуации. Мир хрупок и изменчив, надо уметь как-то удерживать его вокруг себя в какой-то рабочей стабильности, антихрупко и отказоустойчиво: или это делать самому при помощи не очень живых друзей, или зарабатывать достаточно в составе какого-то коллектива, чтобы вокруг бегал оплачиваемый твоим же трудом (ну, или трудом плодовитого коллеги) какой-нибудь корпоративный эникейщик.

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

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

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

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

Собираем киберличность
Основное направление вырисовывается как проработка архитектуры киберличности: человека и его не очень живых сотрудников. Мы имеем в простейшем случае двух агентов разной природы: NI-агента и AI-агента (кто забыл – это natural и artificial intelligence агенты, про “естественный интеллект” как-то уже и не говорят последние годы). Это две аппаратные базы, которые получаются предобучением и затем обучением с подкреплением, RL (reinforcement learning, в особо жёстких случаях NI-агента в ходе обучения бьют ремнём или линейкой по рукам, а во взрослом возрасте могут и в тюрьму посадить – метод кнута, в случае же хорошего обучения могут дать ему стабильную обеспеченную жизнь или даже нестабильный высокий доход). В конечном итоге у нас есть:

естественноинтеллектуальная личность (личность как совокупность всех видов мастерства агента), умеющая усиливать возможности своего мозга как мокрой нейронной сетки эффективными процедурами мышления (“фундаментальное образование”, а ещё и прикладное обучение), а также усиливать возможности тела инструментами и ещё удерживать киберсобранность при помощи ручки-бумажки, а то и компьютера. И вот тут появился AI-агент, на которого тоже можно сдвинуть какое-то мышление, а в случае роботического тела можно сдвинуть и действие. В принципе, это примерно то же самое, что “стать менеджером или инженером-менеджером: уметь делегировать работу и проверять результаты работы”. Проблема: чтобы доучивать чему-то личность, надо долго что-то повторять-тренировать. Освоить какой-нибудь сложный регламент местного инженерного процесса даже киберличности – долго, нужен “опыт работы”. Аппаратура мокрой нейронной сетки не позволяет за ночь прочесть толстенький регламент, а потом быстро-быстро действовать по этому регламенту. Зато накопленных за долгую жизнь знаний хватает, чтобы ориентироваться в довольно сложных проектах – не отличаясь при этом эрудицией, это ведь очень специальные знания.
искусственноинтеллектуальная личность, которая уже проучилась в датацентре несколько месяцев (текущие реалии) и приобрела широкую эрудицию. Но зато у неё память очень коротка (пока), и поэтому взять работу и выполнить её в приемлемое время эта не очень живая личность не может. Этой личности зато можно дать какой-то регламент (мышления, работы по какой-то роли, способа решения какой-то задачи) и попросить действовать по регламенту – и худо-бедно это будет сделано немедленно, не надо ждать месяц-другой-третий, как пришлось бы ждать примерно таких же результатов от человека. Тут, правда, можно ещё чуть-чуть оптимизировать: как и для человека, можно попробовать откомпилировать какие-то паттерны в формат skills и MCP v2, тут тоже можно получить усиление (см. пример статьи https://arc-skill.vercel.app/ – я ожидаю волны обсуждений и волны оптимизационных мер для использования skills, это будет как “машинный язык” для агентов, поэтому паттерны можно будет пробовать компилировать в этот машинный язык, добавив туда ещё одну технологию: skills over MCP Skills Over MCP Charter - Model Context Protocol и тамошние расширения вроде SEP-2640, где 11 августа 2026 прошло голосование core maintainers SEP-2640: Skills Extension by pja-ant · Pull Request #2640 · modelcontextprotocol/modelcontextprotocol · GitHub и в OpenAI появился такой “плагин”, что следует из заметок: Skills Over MCP Working Group - August 11th 2026 Meeting Notes · modelcontextprotocol/modelcontextprotocol · Discussion #3230 · GitHub – early adoption есть, надо присоединяться). ARC-skill из статьи содержит 129 строк инструкций, но вместе с ним работает CLI на 4343 строки: перед действием агент был обязан предсказать изменение среды, harness отвергал действие без предсказания, а результат автоматически сопоставлялся с наблюдением. То есть сработала довольно большая конструкция, а не сам skill. У меня LPF тоже не сводится к набору паттернов, там ещё и многое другое – в Codex это тоже уже не skill, а “плагин”. Тут вырисовывается отдельная исследовательская (и производственная, как же без этого) программа оптимизирующей компиляции паттернов – там много нюансов, я уже сделал пару прикидок, нужно будет писать отдельный большой пост.
а теперь надо сделать киберличность: киборга (человек и его AI-ассистент) или хиброта (AI-агент и его оператор-человек, вроде как экскаватор – заказываете вы обычно экскаватор, а экскаваторщик к нему прилагается, а не наоборот – заказываете экскаваторщика, к которому прилагается экскаватор. Тут надо быть честными: не факт, что главным тут будет царь природы, ибо главным может оказаться царь мышления – и он будет на первых порах не слишком живой, а там посмотрим). Вот главная задача сейчас – это архитектура этой киберличности: какие знания кому в какой форме дать, чтобы они вместе стали как “экскаватор с экскаваторщиком”, одной системой с уникальными эмерджентными свойствами, недостижимыми ни для NI-агента, ни для AI-агента. Вся история с экосистемой FPF, руководствами и резидентурами – она про это.
дальше мы говорим про коллективный организованный интеллект, ибо сложные инженерные проекты (в том числе культурная эволюция, которая интересует всё больше и больше) делаются обычно не в одиночку. Нужно понимать, как делать организации из хорошо скоординированных N NI-агентов и M AI-агентов.
что мы хотим иметь на выходе? Какие и чьи capabilities? Тут, конечно, нам поможет паттерн “E.23.CDI - Developing Capability for a Named Work Family” – в FPF сейчас есть и такие паттерны!
и все эти “абстрактные” рассуждения о знаниях можно существенно конкретизировать, если единицей знания считать не онтологему (но онтологию мы учтём!), не мем (но культурную эволюцию мы учтём!), а что-то вроде александрианского паттерна: описание метода. Методология рулит. Я себя последние годы как раз называю методологом, если по основному роду занятий. А раньше я и когнитологом себя называл (на заре занятий искусственным интеллектом), и онтологом (когда этот AI стал постарше), очень короткое время – эпистемологом, но затем разобрался – я методолог!

Тут ещё надо развести разные архитектурные характеристики методов, описываемых паттернами: у варианта метода есть как минимум оценка того, насколько хорошо он работает в проекте, и совсем другая оценка того, насколько легко он передаётся, распознаётся, осваивается, вызывается и удерживается культурой. Хороший метод может не распространиться, потому что его трудно объяснять и тренировать. Плохой метод может отлично распространяться, потому что он короткий, яркий и легко проверяется суррогатной метрикой. Поэтому составляющие экосистемы FPF будут закрывать Парето-фронт этих характеристик: FPF+DPF удерживают точное знание и варианты; skills уменьшают цену его вызова агентом; руководства и резидентуры обеспечивают человеческое освоение; посты и семинары дают распознавание; сообщество обеспечивает передачу и удержание; а замеры разной эффективности собственно применения методов и обучения этому применению предотвращают подмены рабочей эффективности популярностью. 13 миллионов знаков хорошо работающего FPF ещё не означают культурного успеха: генерация и каноническое удержание вполне работающего знания могут уже перестать быть узким местом, а вот передача, освоение и рабочий перенос — ещё нет. Продвижению тоже надо уделять внимание, продукт делать удобным в том числе и для продвижения, иначе в культурной эволюции не победить.

Тринадцать DPF и архитектура методов
Проект по конвертации R0, R5-R10 в FPF и Engineering DPF Suite (вот так это сейчас называется) потихоньку движется:

определён список из 13 DPF в составе Suite, которые можно было бы выпустить на основе этих руководств. Этот список только отчасти напоминает отражение структуры этих руководств: очень много уже в FPF, а что-то было сочтено недостаточно “domain”, то есть недостаточно самостоятельной дисциплиной. Границы каждого из DPF так и не утрясены, только-только опять “начали сначала” (проблема со специализациями: поскольку специализация выглядит как дублирование общего высказывания – её немедленно выкидывают. “Мыши едят зерно, тигры едят мясо” – это высказывание объявляется дублем “животные едят”, после чего выкидывается). Опять починили, опять всё сначала. Я пока предложил перенести критерий из MG-DA: с лексики на DPF. Ещё для этих DPF suites будут suite guides.
главное продвижение тут будет связано с архитектурным взглядом на холон метода – поскольку метод у нас стал холоном, а архитектура введена как выбранные структуры холонов. Выделяем “вертикаль” одновременного выполнения работы по методам в каком-то стеке (“пирамидке”, “конусе” – это вернее) методов, как это показано для танцевального стека в руководствах R5-R7. Ключевое тут – “одновременность” работы (сами методы абстрактны, это “переиспользуемые способы работы”, а вот работы по этим методам в “вертикали/стеке” – одновременны), нельзя сказать, что “сначала работает мышца танцора, затем он выполняет вращение”. И тут важны метахолонные (метаметодологические в этом случае) переходы между масштабами (времени, участвующих систем – тут мутновато, ибо и одно и другое оказываются участвующими вместе). Путаница тут с “сначала одно, затем другое” – ибо это потоки преобразований, которые выполняются по методам, в декларативном (CGUS) представлении методы получаются в таких потоках плохо отличимыми от стеков: там какие-то списки и тут какие-то списки. Эвристика тут с “сначала одно, затем другое”: “сначала танцор вращается, затем шагает”. Всё ещё запутанней, если там build the builder: “сначала точим нож, затем режем ножом салат”, ибо сеть трансформаций отличается от просто структуры трансформаций какого-то одного объекта (например, “все операции с салатом” в отличие от “сначала займёмся ножом, потом займёмся салатом”). Агенты тут начинают отчаянно путаться, ибо в руководствах холонов нет, а в FPF нет танцев, системной инженерии, системного менеджмента и всего остального – ибо я требую, чтобы вот эта холонная структура была не только для танцев, но и для системной инженерии, системного менеджмента и вообще как-то отражалась в DPF. Почему это важно? Чтобы готовить танцора, надо понимать, каким стеком методов он пользуется. Чтобы готовить системного инженера, надо понимать, каким стеком методов он пользуется. Учить-тренировать надо по всей вертикали. Но это тоже упрощённое понимание: ведь там важен не стек методов как одна структура. Там важны несколько разных выбранных структур методов – архитектура. Вот эти структуры надо поименовать явно и указать, какие затруднения в проектах снимает их рассмотрение. Один набор методов может одновременно иметь в качестве архитектуры структуру реализации (“вертикаль” уровней стека), поток преобразований (“горизонталь” на одном уровне, “мантра”), структуру подготовки средств (сеть build the builder) и структуру объяснений (структура учебного нарратива) – и это могут быть ещё и не все структуры в архитектуре метода, список может быть больше (тут смотреть паттерн “C.32.MWA - Practice Architecture Synthesis from Several Structures”). Проверить, что для этих идей в FPF есть все необходимые паттерны, ибо эти соображения общие для всех проектов, они трансдисциплинарные, это не только про Engineering DPF Suite. Как минимум, нужны паттерны для разных структур – реализационная структура отвечает на вопрос, какие вклады совместно дают результат; transformation flow — что должно измениться или стать доступным раньше другого; provider/build-the-builder — откуда берётся способность выполнять целевую работу; структура контроля и свидетельств — где обнаруживается отклонение и кто его корректирует; учебный нарратив — в каком порядке строить понимание; культурная структура — как варианты передаются, узнаются и удерживаются; архитектура методов как выбор подобных структур, каждую из которых можно не строить, если в проекте нет связанных с этими структурами затруднений, но хорошо бы о них знать, чтобы не забыть о них подумать, это же готовый чеклист для методолога.
интеллект-стек тоже стек, но там одновременность (вертикаль) в его трансдисциплинарности. Что же до уровневости внутри его самого, то там всё неправильно как “стек реализации” – эта уровневость введена как “верхние уровни объясняются через нижние”, это совершенно другого рода стек, на другой структуре отношений, “последовательность нарратива” (вовсе не “стек”, там “сначала” и “потом”, цепочка).
и вот тут я прошу для реализационного стека рассмотреть межуровневые конфликты и задать культурную эволюцию (она же будет стилевой инженерией), которая идёт от попыток снять конфликты. Для “истории танцев” и “истории музыки” это вполне естественно, это “эволюция стилей” – поэтому ход на “теперь для танцевального и музыкального стеков погляди на конфликты и опиши с учётом вот этой картины мира” выполняется, примеры я тут публиковал в блоге. Дальше надо ровно то же самое натянуть на системную инженерию, системный менеджмент и всё остальное: это ведь та же эволюция стилей, та же стилевая инженерия. Когда мы переползаем со всеобщего водопада в процессах на agile, то авторы agile manifesto мало отличались от какой-нибудь Deep Purple с их предложением hard rock или Gwen и Dizzy с их предложением tarraxo. Говорить об этом надо уметь одинаково, моделировать похоже. Агентам тут дико трудно, ибо текстов мало, холоническое описание недоопределено, музыкальный заход академический (никаких “вот такая проблема – вот такой первый ход”), ибо левацкий-описательный, а инженерный ход – ресурсно-агентский (и отказ от создания DPF на основании того, что “литература по стилистике не поддерживает никакой инженерии, она вся только описывает – вот поглядите на авторитетные университетские монографии в доказательство” у агентов был, пришлось им делать суровое внушение). Но ничего, поднакопим текстов, агентам станет легче. «Обучение по всей вертикали» тут заключается в тренировке выделения вниманием этих уровней стека, чтобы координировать одновременно исполнение какими-то агентами разных масштабов одновременно действующих методов этих масштабов, обнаруживать их конфликты и уменьшать frustrations (неустроенности/неустаканенности/нестабильности), снимая неопределённость в получении общего результата из-за нестабильности, вызываемой конфликтами. Это линия главным образом Кацнельсона со товарищи.
Культурная эволюция (изменения культуры) тут будет только тогда, когда вот этот выбранный вариант согласованных “горизонталей-потоков” в рамках одной “вертикали одномоментной многомасштабной реализации” начали передавать, узнавать, выбирать и удерживать в коллективной практике – по паттерну C.36. Наблюдаемый набор межуровневых конфликтов сам по себе ещё не создаёт эволюцию. Он создаёт давление неопределённости/неустойчивости выбора (frustration), после чего должна пройти цепочка: “конфликт → генерация варианта метода → его применение в локальной работе → распознавание и сравнение → выбор или отвержение → передача другим → удержание и воспроизводство → популяционное изменение распределения вариантов в практике”. И вот это “популяционное изменение распределения вариантов в практике” и можно будет назвать “прошедшим шагом культурной эволюции”. Agile Manifesto и предложение hard rock в отдельных композициях каких-то рок-групп похожи не тем, что они «задают стили», а тем, что они предлагают вмешательства в текущую популяцию стилей, фокусируют внимание на новых вариантах, которые становятся стилями после признания, распространения и удержания сообществом.
всё это порождает огромное количество частных определений в FPF: и уточнение холонов методов, и уточнение понимания “что такое DPF и как их создавать”, и переделка части G для поддержки концептуального синтеза (ибо что ещё такое “создание DPF”, как не унификация методологии какой-то предметной области, не концептуальный синтез?). Это всё новёхонькое, поэтому всё идёт медленно и неправильно, зато идёт.
и тут же идут две кампании: R5-E11 с описанием того, как делать DPF (и там уже дважды не получалось сделать нормальный landing, опять пропускались проверки – и это вело к пересмотру ещё и FPF, и DPF, чтобы такое не повторялось), а ещё R5-E11-S1 с описанием DPF Suites и их Guides; она прошла наполовину, но пока была заморожена до окончания проверок.
всё это на фоне непрерывной возни с LPF. Скажем, вместо одного проверяемого staged-набора агенты начали мысленно вести цепочки HEAD → successor → successor hash, и пошли массовые ошибки при работе с Git. Почему? А это была попытка улучшить работу с Git. Сегодня различение sibling / candidate-descended successor было добавлено в commit 268d3872…, как реакция на сбой landing R5–E11. Но оно не создало исходный сбой — оно превратило разовую техническую проблему в обязательную модель мышления и тем самым усилило путаницу (и ошибки пошли уже массовые). Ошибка была внесена более ранним переходом от простого staged-кандидата к ReviewedCandidateRoot + predecessor + working successor. Тоже, заметим, из благих намерений – которыми очень часто мостится дорога в ад. У меня работа вроде как “научный руководитель агентов”: должен вести их к светлому будущему, а на деле – чиню, чиню, чиню. Для этого отслеживаю, что “у нас тут поломано”, а затем ещё и тыкаю носом в то, что поломано, часто ещё и приходится подсказывать, как это чинить. В этой ситуации люди-сотрудники бы жаловались: “у нас тут плохая корпоративная культура, нас бьют по рукам, не дают проявить инициативу”. Эх, что в одних глазах – “инициатива, путь к счастью”, в других (в данном случае моих) глазах – “опять напоролись на давно известные грабли, сколько ж можно!”.

Продолжение в Начинаем сентябрь 2026: намётки очередного планов громадья (2/2)