BIRDRINGS

https://ailev.livejournal.com/1796405.html

Чем я занят сегодня (и вчера, и позавчера): все побежали, и я побежал
Текст этот мой, но чтобы вы оценили его предмет, я предложил GPT-5.4 дать ему заголовок с основной мыслью. Вот: "Artifact-centric, precision-governed, review-diversified process for evolving low-testability normative corpora", демонстрация той самой точности языка, с которой тексты читать противно, но возразить нечего. Вам как надо с вашими рабочими документами -- чтобы читать их было приятно или чтобы возражений к ним не было?

Сегодня я занят тем же, чем всегда в последнюю пару недель: меняю рабочий процесс создания FPF в Codex App. В этом рабочем процессе четыре агента в ключевых операционных ролях:
* executor -- исполнитель;
* reviewer -- проверяющий, у которого широкие права по блокированию процесса;
* platform engineer -- инженер платформы, отвечающий за процесс (ага, "управление жизненным циклом FPF", как сказали бы раньше. Он правит всю организационную документацию, сдвигает цикл при зависаниях, крутит цикл POOGI, ведёт журналы телеметрии по индикаторам процесса);
* product steward -- это я, ибо время от времени надо принимать судьбоносные решения вроде "готово, выносим на внешнее review" или "а ну-ка проверь ещё раз файл FPF, вы там случайно выкосили пару паттернов" (было и такое). Это я делаю сам, это не доверяется сейчас AI-агентам, я (пока!) умнее их.

И ещё там по цепочке создания "организатор организаторов": я как benevolent dictator для "процесса разработки процессом", а ещё у меня там собственный помощник -- Service Chat (который, например, независимо может проверить работу platform engineer или соответствие моего поста реальным документам процесса).

Я тут не одинок, у меня все ленты показывают, что этим занимается сейчас вокруг меня каждый первый. Все уже сообразили, что работать будут не сами -- фразы типа вот этой "If research execution keeps getting cheaper, then the scarce resources move upward: taste, judgment, and attention" (взял из https://x.com/hhexiy/status/2036619809975308344) встречаются в самых разных постах. Ну, я и проявляю свой вкус, умение здраво судить и выделять вниманием что-то важное -- в данном случае в отстройке процесса. В этом процессе бесконечного улучшения FPF отразились три слоя фреймворков:
* сам FPF: у меня же есть часть E, связанная с авторством FPF, вот самые общие нормы про специфику FPF -- там, например, где на Парето-фронте подобных процессов должен бы сидеть наш процесс, чтобы быть успешным. Это самые общие рассуждения. В текущих руководствах -- мета-мета-модель.
* "что-то из менеджмента": это Second Principles Framework (SPF, в руководствах сейчас это метаУ-модель). Про то, как устроены подобного сорта процессы, это знание SoTA текущей организации процесса на агентских командах (даже неважно, людских или не совсем людских). В текущих руководствах -- метаУ-модель.
* Third Principles Framework (TPF) как "детальный регламент" в моей специфичной ситуации, когда я сижу и ваяю этот FPF с задействованием Codex App и ChatGPT Pro для внешнего review. В текущих руководствах -- метаС-модель.

Характеризация и индикаторизация процесса разработки FPF
Сейчас у меня в работе третье поколение процесса (всё быстро!), идут пилотные прогоны. Чтобы не спорить о нашем процессе на уровне вкусов, мы описываем его не как “лёгкий” или “тяжёлый”, а как набор качеств и индикаторов. У нас набор характеристик, позволяющих нашему процессу занять нужное место на Парето-фронте из самых разных процессов, пытающихся быть легкими и одновременно надёжными. Для этого в документах явно выделены такие индикаторы, как:
* целостность владельцев (OwnerIntegrity) -- один факт хорошо бы иметь в одном документе, а не размазывать по всему корпусу, owner тут -- чаще всего файл, паттерн, note. Абсолютно архитектурный сленг.
* независимость review (ReviewIndependence), потому что мы приняли обычный подход к улучшению качества путём не "самопроверки" (собственные ошибки разработчику чаще всего не видны, "глаз замылен" -- он же помнит логику вывода решения и проверяет по ней, а ошибка может быть как раз в этой логике). И тут два уровня: внутренний и внешний reviewer (внутренний -- это GPT-5.4 xhigh тут же в Codex, для банальных ошибок, а вот внешний -- GPT-5.4 Pro, работающая в пять ходов, и там уже находятся серьёзные ошибки и даются серьёзные советы, и для внешнего review специальный хелпер собирает досье по проекту, которое легко перетащить в ChatGPT нажатием на пару кнопок). Значение характеристики пока не такое высокое, как хотелось бы, об этом знаем, работаем над этим.
* возобновляемость длинной работы (Resumability), ибо пара чатов-агентов уже умирали-зависали, но ничего страшного не случилось -- "мышление письмом", а не "в уме" позволило легко перейти на новый чат с новым агентом.
* истинность release-переходов (ReleaseTruth), то есть удержание в одном месте состояния процесса. Мало просто “следить за релизом”, надо в любой момент держать истинными по состоянию на сейчас и записанными на диск (а вдруг потухнет электричество для нашего же блага или защищающие нас друзья вырубят нам связь?) такие вещи, как что именно подготовлено для какой роли и что роль должна с этим делать, что именно уже отправлено или ещё только собирается быть отправленным, какой интегрируемый паттерн (или другой объект, например, часть предисловия или readme.md на GitHub) сейчас "в работе", какие результаты внутреннего и внешнего review уже вернулись после проверки и где они лежат, что уже есть в планах и пока не начало выполняться, а что уже давно выполнено.
* целостность связи "монолита" спецификации FPF и вытащенных для удобства редактирования текстов отдельных паттернов или разделов предисловия (MonolithIntegrity),
* экономичность control plane (ControlPlaneEconomy), то есть насколько обработка информации по процессу меньше, чем содержательная работа на текущем шаге
* отдача от распараллеливания (ParallelizationYield), ибо мы же помним про закон Amdahl и не хотим распараллеливать работу так, что она вообще останавливается.
* управляемость минимального набора передаваемых в ходе объектов (CanonicalOwnerSetManageability)
* сохранение будущих опций интеграции и перегруппировки (FutureOptionValue, сохранение evolvability, но по факту -- "контейнер для всего архитектурно хорошего", тут неплохо бы уточнять и уточнять. Как, впрочем, уточнять и все остальные характеристики и их группы).

Дальше эти характеристики привязываются (ну, сейчас это "почти привязываются", ибо не для всех ещё это сделано) к измеримым индикаторам:
* доле planning/control работы (planning_control_share) во всей работе,
* числу hand-off на содержательный шаг процесса (handoffs_per_content_step),
* числу fix-циклов (fixes_per_content_step) после возвратов reviewer с блокерами, частоте продолжения того же шага "самопродолжением" без передачи хода другой роли (continue_step_rate),
* медиане первого непрерывного содержательного прохода в минутах (first_execution_interval_median),
* административной дороговизне релиза (release_crossing_cost, ибо там отдельная процедура выпуска и всё обычно очень плохо с соотношением церемоний управления конфигурацией по сравнению с содержательными правками текстов),
* и так далее (скажем, число реально обязательных файлов, а после старта параллельной разработки и число инцидентов конкурирующих процессов и издержки на повторное восстановление контекста).

Наше место на Парето-фронте AI-прод-процессов
По состоянию на 26 марта 2026 (в сингулярности счёт идёт на дни, особенно когда речь идёт о фреймворках агентской работы) это даёт нам (пока гипотеза! ещё не можем сказать, что мы туда попали! но хотим попасть!) достаточно уникальную и узнаваемую позицию на Парето-фронте: мы сознательно целимся не в “самый лёгкий” процесс на рынке, а в высокую проверяемость (auditability) "не на тестах" (у нас же не софт!), высокую возобновляемость (resumability, хотя тут мы совсем не одиноки), высокую независимость review и высокую сохранность смысловой целостности при средней пропускной способности (ох, я только что сказал ещё один набор индикаторов как довольно сложных объектов, в FPF это Q-bundles). Но мы готовы не достигать максимальной (Парето-фронт всех остальных процессов тут не обогнать пока, серебряной пули нет) пропускной способности (throughput). У нас административно жёсткий (хотя и контролируемый по бюрократии) процесс с диким количеством проверок, а не "полная гибкость и планирование действий на лету", при которых тестирование и управление конфигурацией могут из процесса вылетать.

Делаем это мы через language precision hardening (ну, или shift, в процессах часто говорят про всякие shifts, вроде "сдвига влево"). Этого в явном виде я не встречал, это не сводится к "добавить тестов", "добавить компьюта и выйти в мета", это другое: ход на то же, что и в системной инженерии: исторически в инженерии уменьшалась доля "доработки по месту напильником" при интеграции каких-то частей в какую-то готовую систему за счёт увеличения точности проектирования, а затем точности изготовления. Грубо говоря, комплект мебельных деталей из мебельного магазина собрать дома мог только мастер, ибо не было никаких совмещаемых друг с другом отверстий, никаких болтов с точной резьбой, на которые бы свободно наворачивались гайки, ни одного прямого угла. А теперь сборку мебели может сделать даже ребёнок, не надо разворачивать мебельную мастерскую на дому: взял инструкцию -- и выполнил. От этой механической аналогии давайте перейдём к текстам. Вот я пишу: все метрики на Парето-фронте. Это точно или нет? Нет, неточно: "метрики" обычно отсылают к очень неточно определённому объекту, связанному со шкалой каких-то характеристик. И в этом месте уже трудно "собрать целый текст" из торчащих во все стороны недоговорённостей. Нам надо собрать огромный FPF-монолит, сейчас там уже больше 5M знаков текста, и всё со всем должно сочетаться. Точность языка становится определяющей, чтобы вставка каждого нового паттерна не превращалась в "доработать по месту семантическим, онтологическим, эпистемологическим, математическим и прочим напильником".

Всё вот это общее для каких угодно "процессов многоагентной разработки", которыми полны сегодня все ленты по AI-агентам, но FPF разрабатывается не как обычное софтверное приложение, а как постоянно растущий корпус стандартоподобных паттернов из языка паттернов сильного мышления и продуктивного действия. Здесь мало быстро нагенерировать черновики и потом долго гонять их на прохождение так же быстро нагенерированных тестов. Нет, тут какой-то другой тип задачи, и ещё надо поразбираться, какой именно. Делать тут эксперименты вроде "у меня Codex продержался целую ночь, разрабатывая паттерны, и я этим похвастаюсь" -- ну, я не очень понимаю, зачем такое. Поэтому упор не просто на language precision, но на расширение вопроса о языке на всю семиотику, удержание semio-governance (не только повышение точности). Летим орлами высоко, видим орлами далеко. Но в этом конкретном случае -- именно language precision hardening, маленькая часть от governance: "орлам случается и ниже кур спускаться, но курицам до облак не добраться".

Матерный, айтишный матерный, dynamic quality, felt sense против language precision hardening
Главное, с чем я борюсь в этой работе -- это coder bias языка у AI-агентов. Они используют сленг молодых программистов, которые говорят "айтишным матом". Мат отличается от обычного языка пониженной точностью: там очень немного корней, которые дают некоторый слой чуть точнее местоимений и междометий ("а он её -- бум, а она ему -- бац, а оно -- шмяк-шмяк!", язык людоедки Эллочки как раз где-то тут), но всё-таки неизмеримо более неточный, "зонтичный". Ну, как и многие другие сленги (скажем, во флоте тадала -- это любой длинный предмет, фенька -- любой маленький предмет). Скажем, hot -- это "любой объект, к которому можно ожидать частого обращения", при этом hot path при ближайшем рассмотрении оказывается не одним таким объектом, а пятью разными. Surface -- это директория, API, файл, набор файлов и ещё много чего (в последней чистке было шесть значений). И вот это дальше идёт через то, что я называю "обратный DDD": язык программистов дальше загрязняет целевой язык предметной области, он становится рассказом на неточном "айтишном мате". Вот эту чистку, восстановление точности языка, надо делать всё время. Интересно, что на каждом проходе такой чистки агенты восклицают в своих рассуждениях: "Ах, тут же мало переименовать, тут же скрывается баг! надо срочно его исправить".

Неточность языка вполне допустима на такте exploration, и в FPF у нас даже уже есть паттерны для "доязыковой мысли", ранних догадок, ещё не выражаемых словами -- dynamic quality от Pirsig, felt sense от Gendlin, в МИМ "онтологический дребез" как раз про это. В руководстве по интеллект-стеку фундаментальных методов мышления я вводил трансдисциплину "понятизации" с ролью "поэт", ибо поэзия как раз про перевод "истинного Дао" (распределённые представления) в слова, "неистинное Дао". Но вот дальше у нас exploitation, и добытое из "истинного Дао" знание надо интегрировать в общее знание. Всё по Маяковскому:
Поэзия – та же добыча радия.
В грамм добыча, в год труды.
Изводишь единого слова ради
Тысячи тонн словесной руды.
Но как испепеляюще слов этих жжение
Рядом с тлением слова-сырца.
Эти слова приводят в движение
Тысячи лет миллионов сердца.

В FPF у нас много есть из понятизации-поэзии, где на входе "незнамо что, многозначное, мычащее", а на выходе -- точный язык. Например, F.18 как паттерн поиска новых точных имён/терминов, A.6.P для уточнения неточных имён/терминов. Эта "поэзия" как раз на выходе должна дать точный язык, пригодный для exploitation. Вообще, вся exploitation, усиление найденного понятийного решения -- это подъём точности языка.

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

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

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

Независимость review, никаких bitter-lesson-preferences с их "самоулучшениями за ночь", необходимость выпуска самых разных объектов
Это важное отличие от многих современных AI-workflows: для разработки софтовых приложений они часто выигрывают за счёт лёгкости процесса и надёжности и детерминичности тестирования, а для разработки большого технического стандарта нам важнее не дешёвое производство черновиков, а чуть менее дешёвое производство труднотестируемого продукта. Почему труднотестируемого? А потому как что именно там проверять? Хотя мы делаем именно нормы проверки. Но эти проверки AI-агенты часто делают "интуитивно", формулировки reviewer часто бывают что-то вроде "quality looks stronger" aka "мы вроде проверили, всё тихо", поэтому хелпер валит работу reviewer (по рубрикам из E.19, рубрики усиливают точность), пока он не укажет, что именно там looks stronger из подразумеваемого, но не называемого явно Q-bundle этого "quality". И ещё внутренние review делаются неоднократно, а с учётом внешних review -- ещё и разными моделями, что тоже усиливает надёжность отлавливания ошибок (хотя тут можно придраться, что GPT-5.4 xhigh и GPT-5.4 Pro -- это одна и та же модель, но по моим ощущениям -- это совсем разные модели, несравнимо разные!).

Пока у нас не самые умные агенты и не самый большой бюджет компьюта, поэтому целюсь я не во все эти open-ended алгоритмы вроде гипер-агентов, мета-агентов и прочих "автоматических эволюционных процессов" (как это называет Григорий Сапунов -- тренд "непрерывной адаптации агентов в проде", и тут можно долго рассуждать, чем эволюция, оптимизация, обучение отличаются от адаптации, даже если добавлять к ним по старой традиции кибернетики оговорку про "второго порядка"). Нет, ход на "залитие бюджетом" с учётом bitter lesson preference (BLP), когда "уважаемые господа агенты, вот вам задача -- и решайте как-нибудь, заодно не забывайте подхакивать и сам процесс решения" -- он пока недоступен по ресурсам.

На третьей большой итерации по процессной архитектуре у нас поддерживается разработка разных типов целевых эпистем: частные архитектуры вроде semio или TGA, DRR для групп паттернов, сами группы паттернов (скажем, вот прямо сейчас разрабатывается паттерн для AuthoredUnitDiscipline -- чтобы всякие файлы, заметки, записи и т.д. имели вполне определённый object-of-talk, а также отвечали на вполне понятные ролевые интересы, чётко определились с их деонтикой -- и не съезжали с них по ходу повествования), отдельные какие-то групповые правки (скажем, хочу вот прямо сейчас поменять даже не FPF, а ReadMe.md в GitHub и ряд паттернов FPF, чтобы лучше отразить новые изменения состава FPF), проходят через разные типы процессов (архитектура идёт не так, как DRR, а DRR не так, как паттерн), а не сваливаются в один бесконечный чат "на все темы" или один общий backlog для всех разрабатываемых объектов.


Архитектура процесса разработки FPF: тематические потоки, кампании изменений, макро-шаги и их досье, наборы файлов для внешней проверки и тому подобное
Самый верхний процессный уровень у нас задаёт тематический поток работ (thematic workstream). Это длинная смысловая линия, внутри которой может жить несколько независимых или слабо связанных кампаний изменений (change campaigns), которые могут выполняться последовательно или параллельно. Сейчас основной живой поток у нас с тематикой `semio`: это семиотическое пополнение FPF -- оно ближайшее по плану. Для следующей большой линии уже зарезервирован отдельный поток `TGA` (transduction graph architecture, там огромное недоделанное задание на доработку -- вот это задание освежим и выполним). Для того, чтобы всё это хранить, в папке Codex были намечены отдельные папки.

Внутри потока мы открываем кампании изменений (change campaign). Скажем, для семиотических пополнений FPF они будут уже не про “всё semio вообще”, но про выпуск группы паттернов с понятной общей целью. В активной `semio`-кампании прямо сейчас у нас идёт разработка паттерна `AuthoredUnits` в кампании со странным исторически получившимся именем `AuthoredUnits three-line landing campaign with aligned E.19 authoring-law refresh`: локальные паттерны делаются по одному, потом проходят групповую сборку в их группу, потом жёстко проверяются согласно E.19 (там сейчас все значимые проверки), затем выносятся во внешний review от Pro-модели (для этого собирается специальный набор файлов, чтобы удобно было задать контекст), потом исправляются замечания, затем ещё раз E.19 и исправления -- и только после этого рассматривается интеграция в файл спецификации.

У нас уже заведены и ждут инициализированные кампании другого типа, где уже выполнена какая-то постановка задачи: `PREFACE-FRONT-MATTER-AMENDMENT`, `NON-SEMIO-PATTERN-AMENDMENT`, `NQD-OEE-ADAPTIVE-SPECIALIZATION-SHIFT-AMENDMENT`, `Q-FRONT-AND-NQD-EXPLORATION-ARCHIVE-SEMANTICS-AMENDMENT`. Я их планирую выполнять последовательно, хотя вот этот front matter выполню вне очереди: это объяснение в readme и предисловии FPF того, как надо читать FPF и где у него "точки входа".

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

Executor разрабатывает и исправляет это досье из нескольких взаимоувязанных файлов, а reviewer проверяет, что в этом досье не в порядке и сообщает executor. Эти ходы executor и reviewer делаются с досье в двухролевом цикле исполнения и проверки (dual-agent cycle): `executor` делает содержательный проход по досье, `reviewer` независимо проверяет "правильность досье", возвращает findings -- или закрывает макро-шаг при отсутствии замечаний. Так мы держим длинную работу на диске (в досье), а не в памяти/контексте чата. Мышление у нас письмом: это снимает и ограничения на длину удерживаемого контекста, и даёт возможность холодного старта, если какой-то из ролевых чатов подвис (такое обязательно бывает раз в неделю: чат уходит в "думаю" -- и не возвращается затем никогда, приходится этот чат прятать в архив).

Когда кампания доходит до конца шага, появляется набор файлов для внешнего review (external-review bundle). Это уже отдельный набор файлов, а не просто “то же досье, только отправляемое наружу”. Так, в semio workstream на review в его кампаниях отправляется набор из текущей спецификации FPF (он может быть ещё не опубликован в GitHub, так что берём прямо с диска), затем набор архитектурных документов, затем набор целевых паттернов. Проверять надо всегда в контексте. Никогда не проверяется целевой объект проверки сам по себе.

Несколько кампаний могут постепенно наращивать объём своих целевых паттернов (это называется pattern hardening). На внешнюю отправку собирается только целевой набор непротиворечивых файлов (external-review bundle), необходимых для проверки.

Когда внешний review вернул замечания (без замечаний тут не бывает!), они идут не в свободный “ещё один проход”, а в отдельный тип процесса: учёт внешних замечаний (returned-findings absorption): ролевой цикл гоняется до тех пор, пока reviewer не признает, что executor поправил все эти замечания. Когда набор изменений действительно готов к посадке (landings) в целевые объекты (чаще всего это спецификация FPF как "монолит", но иногда это и GitHub, например, при правках тамошнего ReadMe.md), то идёт "операция интеграции" -- делается патч.

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

Ещё раз про важные объекты текущего процесса:
- `thematic workstream` держит длинную стратегическую и архитектурную линию;
- `change campaign` держит маршрут изменений в форме ограниченных макро-шагов;
- `macro-step dossier` -- это набор файлов, над которым работают в макро-шаге исполнитель (executor) и проверяющий (reviewer);
- `dual-agent cycle` идёт по шагам через execution и independent review на каждом шаге (иногда выходя и на внешнюю проверку);
- `external-review bundle` обслуживает стык контекстов внутренней папки Codex и внешнего контекста ChatGPT Pro (по-английски тут труднопереводимое outbound review seam);
- `returned-findings absorption` -- это часть макро-шага, которая закрывает замечания от reviewers;
- `development integration operation` вписывает вновь разработанные или поправленные паттерны и иные объекты (части предисловия FPF, файлы вроде ReadMe.md) в их целевые места: "монолит" спецификации FPF, GitHub-репозиторий и т.д.

https://ailev.livejournal.com/1796405.html