Lytdybr -- от 9 июня 2026

ailev · 09.Июнь.2026 13:13:48

Все ленты/каналы/паблики/журналы/страницы вокруг меня цитируют “организацию циклов” для AI-агентов. Для меня это опять же – люди из AI-тусовки переизобретают принципы менеджмента, впервые сталкиваются с оргстроительством и изобретают велосипед. Кстати, обобщённый цикл улучшений в FPF, конечно, есть, можно пользоваться – Циклы улучшения (OODA, POOGI, PDCA и даже Ralph loop) "в одном флаконе" -- уже в FPF: ailev — ЖЖ. Но раздел в “Системном моделировании менеджмента”, где я говорил, что “Если в вашей жизни ничего не повторяется во времени, значит вы делаете что-то совсем не так, живёте в хаосе. Жизнь и работа — они ритмичны!”, написан давным-давно, в эпоху “до AI” (“4D системность: паттерны в пространстве-времени, ритмы”, Aisystant). И отказ от “жизненного цикла” в руководствах и FPF тоже был давным-давно сделан в пользу бесконечного развития, и семинар был “Развитие для развитых”, где я давал схему с двумя циклами (проблематизации и поиска решений – Развитие для развитых в 2026). Надеюсь, теперь все эти тексты будут читаться внимательней, идея “давайте займёмся циклами”, наконец, дошла до AI-инженеров. Что следующее они возьмут из менеджмента, что будет цитироваться во всех блогах?

AI в музыке уже победил примерно так же, как поначалу было с изображениями. Демократизация изображений привела к тому, что всё на свете преображалось в картины Ван Гога (боже, почему именно его картины?), но сейчас об этом смешно вспоминать. Стиль узнаваем, но вот в этом стиле изображалась всякая ерунда. Прошло время, и современные AI-модели (начиная с Nano Banana, но потом и вообще все остальные) начали не только соблюдать стиль, но и генерировать приличное содержание для изображений. Стиль перестал быть украшением без того, что стоило бы украсить. С песнями всё так же: отовсюду выдаёт вокальные украшения лужёная глотка Канье Уэста, который исполняет роль “музыкального Ван Гога”, но эти вокальные украшения украшают пустое место: вы не сможете напеть исходную мелодию – или же это будет перепев уже известной мелодии, “перенос стиля” как аранжировки и исполнения. Но это очень недолгий период, и он будет ещё короче, чем ситуация с генерацией изображений. Я побывал в субботу-воскресенье на фестивале Киззафро, потанцевал пару дней на свежем воздухе. Половина треков – чётко слышно, что это свеженький AI. И это прямо “свежая струя”, много лучше, чем натыканные одним пальцем диджеями-любителями треки прошлого года. Для меня музыка – это не цирк и не спорт (не что-то с “арены”, хоть и гладиаторской). В цирке и спорте демонстрируются победы людей над собственным телом, какой-то героизм. Мне нужна сама музыка, а кем или чем она исполняется – лаптем, знаменитостью с обложки Billboard или самым искусственным изо всех интеллектов – всё равно. Если музыка плохая, но её сочинил хороший человек – не буду её слушать. Если музыка хорошая, но сочинила её машина – буду слушать, а сказки про “тёплый ламповый звук” меня не пронимают (нынешнее поколение этих сказок уже и не помнит, а я не злопамятный – я просто злой, а память у меня хорошая).

Танцы пока держатся, но и там потихоньку идёт работа. Например, Дмитрий Файзулин (преподаватель зука и инженер-менеджер из МИМ) начал моделирование бразильского зука с использованием FPF – Формализация телесного знания: IWE и FPF в Brazilian Zouk. Я теперь этот проект моделирования танцев с целью упрощения обучения объединяю у себя в голове с двумя проектами:

проектом эволюционной стилевой инженерии, ибо мы по факту имеем дело с эволюцией (подробней писал в lytdybr: ailev — ЖЖ).
проектом методическим, “как учить чему-то эволюционирующему”. Для меня “эволюционирующее” – это не моделируемое какими-то жёсткими правилами: архитектура (структуры) там не схватывается формулами, ибо “исключений больше, чем правил” и надо тупо обучать нейронную сетку мимо правил. В языках, которые тоже эволюционны, прямо говорят, что “правило выгодно делать, когда оно покрывает 70% применений, но остальное – исключения”. Танцы, музыка, иностранные языки – они все эволюционны, там нет “строгой логической структуры”. И поэтому часть обучения доступна через логическое объяснение (те самые 70%), но часть – только “впитыванием через повторение, обучением нейросети”, и это ведь “исключения”, которых обычно аж 30%. И вот это обучение надо понимать как строить: что в каких упражнениях повторять (методология: “что там базовое, что можно объяснить и повторить”), как затыкать разрыв между тем, что хочется (скажем, “разговаривайте больше”, когда вы ещё ни бум-бум, “танцуйте больше”, когда вы ещё тоже ни бум-бум, “работайте больше”, когда вы ещё портите своими неумениями работу больше, чем приносите пользы) и бессмысленными и беспощадными повторениями – гаммы и этюды, парадидлы и прочие “упражнения”, которые намеренно отвязаны от задействования всего целевого умения.
спорт, игра на музыкальных инструментах, вокал, танцы – это всё мышечная работа. Но там каждый препод – и методолог, и методист, и умелец. То есть уровень преподавания ниже нижней планки, я не знаю людей, которых научили бы играть на музыкальных инструментах в музыкальной школе. Поэтому смотреть на успешность обучения надо в спорте (там банально конкуренция и хорошие замеры умений, работает цикл улучшений), в игре на музыкальных инструментах (тоже есть минимальное число работ по сравнению методов), а в танцах и вокале – там по факту научных работ нет, поэтому в плане методики сплошная “художественная самодеятельность” (pun intended). Но методы по большей части могут быть одинаковы. Например, танцоров бальбоа надо учить примерно так же, как учат джазовых барабанщиков играть щётками – и это заметили даже сами бальбошники, но так не учат. А надо так учить! Почему? Потому что барабанщиков, выученных играть на щётках, в мире миллионы, а бальбошников – мало. Чисто статистически хорошие методы обучения игре на щётках и моделирование того, чему именно там учить (методология) появятся в среде джазовых барабанщиков, а не в среде бальбошников. Более того, в среде джазовых барабанщиков это обучение будет сразу направлено на импровизацию, а в среде бальбошников традиционное “по связкам”. Так, в рисовании тебе сначала “ставят руку”, ты делаешь миллионы штрихов – и миллионный штрих у тебя совсем другого качества, чем первый (у художников “другие руки” в части выражения того, что они хотят мозгом, у вокалистов – “другие голосовые связки”, вы так не споёте, даже если знаете, “как надо”). При игре на щётках надо сначала научиться ритмично делать круги одной рукой, не сбиваясь с ритма в тот момент, когда другая рука делает акценты. В бальбоа вроде тоже надо научиться не сбиваться с ритма на пульсе одной ноги, когда другая нога делает акценты – но у музыкантов вы этот удерживаемый ритм сразу услышите (хотя тоже не мешает договориться, что же это: там ведь “подразумеваемые места во времени, когда ничего не происходит, но пульс именно в них”), а бальбошники до сих пор не могут договориться, что такое “пульс”, чтобы его удерживать (ибо ищут его “в теле”, а надо искать в envelope толчка в пол, чисто методологическая задача – определить саму интересующую сущность, EntityOfConcern, которой дальше надо обучать).
и там ещё сразу несколько шкал: насколько вы “в моде” (то есть не развиваете умения динозавров в мире победивших млекопитающих – адекватны эволюционной ситуации), насколько у вас рабочий инструментарий (тело, способное согнуться, быстро двинуться, в случае “просто работы” – хорошие очки, чтобы видеть, слуховой аппарат, чтобы слышать, мозг на ноотропах, чтобы думать), насколько вы вмазали в свою нейросетку “текущую ситуацию” с координацией всего этого инструментария (и вот там нужно оптимальное разделение следования правилам и исключений – всё это сплавляется в рамках работы нейросети в одно неразделимое целое, “распределённое представление”).
и ещё задача постоянного развития (ибо “выучиться мастерству” нельзя, оно ж эволюционирует – вы хорошо владеете предыдущей версией каждый раз, а не текущей, если “выучились”), ибо текущая ваша оптимизация – ничто по сравнению с нужной для следующей поставленной проблемой. Нет новых решаемых проблем – привет динозаврам, вы где-то среди них.

Бодро идём по плану: “от принципов к работе” (P2W) уже в FPF (E.18.1). Use this when там – чистая поэзия, ответ на вопрос “что делать, если у нас есть проблема или даже мы что-то уже с ней сделали”:

an accepted ProblemCard@Context names a working problem and the team needs a disciplined next move toward method, planning, performed work, or result interpretation;
a first-principles, U.Signature(profile=FormalSubstrate), PrincipleFrame, mechanism, method, WorkPlanning, performed-work, result-record, or source-currentness cue is present, but the FPF kind or relation to use next is still unsettled;
a TGA graph, P2W path, flow diagram, principle scheme, scenario, functional description, or source publication helps the team think, while the next move must still be recovered as an accepted FPF kind or relation;
a result artifact, telemetry line, acceptance record, quality-evaluation record, done-state update, feedback pin, or integration claim needs to be unpacked before it can guide the next move.

Довольно долго улучшал сами паттерны улучшений и шкалы для улучшений – не столько содержание, сколько точность языка: добивался, чтобы они реально исполнялись AI-агентом. Главная проблема была в онтологическом (а не лексическом) уходе от канцелярита, но при этом в plain language должно было удерживаться точное различение типов/kinds. И ещё чтобы удалялись “отрицательные каталоги” (“картошка – это не яблоко, не вишня, не пирожное, не нос” и так на пару страниц в каждом паттерне). Ещё добавился паттерн F.19 для починки точности языка на уровне фраз, а не слов – для канцелярита надо не менять одни слова на другие, а чистить целые фразы (чаще всего вообще удалять слова, например, всякие exact, live, current и прочее такое, что используется как своеобразный “артикль” для подчёркивания какого-то термина без добавления нового понятия: не просто “изменяемый паттерн”, но “текущий именно этот изменяемый прямо сейчас нами вот тут паттерн” – и никак не короче).

Надо, конечно, будет потом делать большой проход чистки канцелярита по всему FPF, но пока прошёлся по архитектурным паттернам и P2W – там ещё не прямо-таки “нормальные технические регламенты”, но стало сильно получше. Проблема только в одном: 20 паттернов “улучшаются” с оценки “все шкалы на четвёрку” до “все шкалы на пятёрку” за чуть ли не полный день жужжания Codex App – всё это происходит крайне медленно, ибо требуется как-то удерживать пошаговую работу агентов, а это трудно. Если делать записи прохождения чеклистов куда угодно, кроме чата, скрытно происходит чекание всего “в общем и целом”, AI-агенты тут ничем не отличаются от людей. “Сначала мы на этом самолёте взлетим, а потом задним числом проставим все птички в чеклисте по взлёту” – все наблюдали такое в своих подразделениях, а также сами такое неоднократно делали. Поэтому заставляем после каждой операции писать в чат – это дико затратно по токенам и времени, зато агент не теряет внимания и результаты работы более-менее надёжны: никаких “в общем и целом”.

Поправлен также паттерн E.11, который заведует отслеживанием понятности первых ходов для паттернов, а также поправлена понятность readme.md в GitHub (он теперь входит первым разделом и в FPF). Теперь там “входами в FPF” будут типовые сценарии использования, рассказанные простым языком, а не техническим сленгом FPF. И ещё переписано предисловие, там теперь даны основные идеи решений, которые работают в этих входных сценариях. Вот этот список “первых входов в FPF”:
Взял из текущего readme; даю без номеров паттернов и по возможности внутреннего FPF-жаргона, но довольно близко к тому, как это выдано на английском в readme.md:

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

Думаю, не провести ли мне не просто один обзорный трёхчасовой семинар “Итоги первого года разработки FPF как языка паттернов для смешанной работы людей и AI над проблемами в рабочих проектах” 28 июня, но и затем серию более подробных трёхчасовых семинаров по отдельным направлениям – всё на основе той онтологии, которая в FPF. Раньше я так и делал: когда результаты исследований у меня уже были готовы, но ещё не успевали попасть в руководства, я читал по слайдам. Сейчас это будет ещё более оправдано, ибо, кроме слайдов, можно будет сразу пробовать этот материал применять с AI-агентами. Это же поддерживается FPF. Вот прямо “интенсив”, где-нибудь раз в неделю:
— От системного мышления к архитектурному мышлению. Я думаю, что “холоническое мышление” вместо “системного мышления” не взлетит, но можно этот набор идей про различия систем и эпистем, а также про работу со структурами, которые интересны разным ролям, назвать “архитектурным мышлением”. Недаром системная архитектура – это ключевая дисциплина системной инженерии, системный подход как раз тут, если учитывать многоуровневые архитектуры. Вот и оформить эту тему как связный кусок с выходом на архитектурную работу и архитектурные решения.
— Рабочие процессы: от проблем через принципы к работе (TGA и P2W). Тут плотный клубок тем: с одной стороны, это самые разные потоки и тем самым функциональные архитектуры (помним, что в “принципиальных схемах” обязательно что-то течёт: или электроток, или жидкость, или ещё что), с другой стороны – движение сначала мысли, а затем и действий от проблемы к работам (через выбор матаппарата и постулатных теорий для описаний, выбор метода, планирование работ и даже телеметрия итогов работ).
— Как хватать за язык себя и других (управление точностью языка). Это как раз то, на чём спотыкаются почти все: удержание типов/kinds в тексте. И там – от понятизации (“не знаю, как назвать, но ощущение понятия есть”) до искоренения канцелярита в рабочих документах. И отдельно тут: как хватать за язык (которого у них нет) AI-агентов, FPF тут просто кладовая опыта.
— Как сделать технический регламент для AI в форме языка паттернов для вашей предметной области (SPF на основе FPF). Это говорили уже много раз: общего мышления для решения проблем проекта не хватает, хотя без него нельзя. Но ещё надо знать SoTA вашей предметной дисциплины, и вот расширение FPF для предметной области вашего проекта уже по факту возможно. Вот и рассказать, как это делать, дать примеры.

А пока идёт текущая кампания – седьмая из четырнадцати: “SEMIO-05 operational publication, record, cue, and authority-bearing-record map”. Она нужна, чтобы двинуть дальше и TGA, и архитектуру: TGA queue number 7 and architecture decision/candidate-set uses need accepted operational publication/record/cue admissibility when proof, gate passage, work authority, promise, or release reliance is live. И сразу после неё (возможно, уже сегодня вечером, но более вероятно – завтра) очередная кампания по архитектуре, восьмая из четырнадцати: “Architecture queue number 3 scale amenability and coarse-graining support”. Архитектурные уровни (не только системные) с их размером/масштабом, межуровневые конфликты и следующие из них неустроенности, многоуровневая оптимизация этих конфликтов, выходящая на архитектурные решения по удержанию приемлемых архитектурных характеристик (в их различении от характеристик архитектуры) – они все как раз тут. А девятая кампания – это TGA и бесконечное развитие: “TGA queue number 7 decision, NQD, OEE, and Q-front docking”. И после неё – архитектурный модульный синтез как результат этой эволюции. Так что архитектурное мышление у нас – самое современное, архитектурное мышление в проектах развития.