Организовывать AI-агентов должны инженеры-менеджеры (в том числе сами AI-агенты-организаторы)

ailev · 15.Март.2026 14:08:42

AI-агентная коллективная работа – это не замена организаторов программистами, это новая полянка для классического оргразвития: те же проблемы “невладения языком”, те же проблемы мутной неточной речи у AI-агентов, те же эффекты Гудхарта, те же проблемы координации и операционного менеджмента, только агенты не очень живые. Но эти агенты ведут себя точно как люди, и их надо специально организовывать. Это могут, конечно, сделать сами агенты – но в эту сторону их надо специально пнуть – и знать, куда. Я – знаю, но сильно сомневаюсь, что это делают сами программисты, а уж когда AI-агентами займутся машиностроители или строители, то там будет ещё хуже: они отдадут это программистам, а программисты пока отнюдь не все инженеры-менеджеры, они в менеджмент не умеют. А надо уметь.

Codex App у меня уже больше недели (я его как раз 4 марта 2026 и поставил). Я в нём продолжаю обустраиваться – перестал моделировать многоагентную работу “руками” в ChatGPT на web-UI и моделирую её сейчас прямо в Codex App (да, до сих пор пара агентов в Codex App не может вызвать друг друга прямо, поэтому достал уже не сисадминский бубен, а вайбкодерский). И все мои ожидания блестяще подтвердились: в разработке с AI-агентами производительность определяется не только и даже не столько силой модели, сколько всей организацией эээ… труда: интерфейсом AI-агента к среде, внешней и внутрикомандной проверкой, lessons learned и их учётом в рамках PDCA/POOGI, организацией экзокортекса с его zettelkasten и чеклистами, топологией команды и организации (мы заставляем про это прочесть!), жёстким configuration management и формальным hands-off (с оптимизацией до low ceremony и уменьшением числа ролей). Без этого AI-агенты в коллективной разработке воспроизводят типовые ошибки новичков, в том числе типовые ошибки команды, составленной из джунов и даже без тим-лида и продакта (если уж говорить в терминах bloody enterprise software engineering, но выводы верны для всех предметных областей) – и все эти ошибки будут воспроизводиться быстрее! Вам не надо будет ждать пару дней, пока неминуемо обнаружится очередная типовая ошибка. Надо будет ждать совсем немного рабочих циклов, за час вполне можно управиться – и отхватить новичковых ошибок столько, сколько в обычной организации за ту самую пару дней. При этом: на сотрудников вы сердитесь, потому что тупые (нет, у них просто нейросетка такая и мало знаний по организации работы, они не инженеры-менеджеры, поэтому у них “броуновское рабочее движение”), на нейросетки не злитесь (они ж не люди! при этом уже есть понимание, что они не такие тупые – демонстрировали они это уже не раз, и не два. Они новичковые, но не тупые! У них ума хватает, но они не знают, какие знания применить и вы им не организовали подходящую среду, где их ум мог бы развернуться. Впрочем, для сотрудников это тоже верно), а ещё у вас самих во лбу тоже нейросетка, и вы от своего непонимания расстраиваетесь.

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

попытка по-быстрому сработать “как с чатом” – всё плохо, ибо GPT-5.4 на уровне “очень высокий” глупа как пробка. Ещё бы! Раньше у меня ход занимал как минимум 20 минут, Pro-версия успевала подумать, поэтому очевидные глупости отсекались. Тут – две минуты, и готово, но готово с дикими ошибками! Зато быстро.
агенты знают об организации процесса работ ровно столько же, сколько средний программист. То есть работы организуются ad hoc, вообще без процесса, если этот процесс не задать или не попросить наладить.
агенты сами не заботятся о tooling, пришлось их заставить сделать skills и даже скрипты правки тяжёлого Markdown (ибо apply_patch с Markdown не работает, PowerShell работает не всегда, зато ещё требует подтверждения от пользователя каждый раз), отдельно пришлось заставлять их этим пользоваться, не забывая. Самообучение тут на нуле: если есть какие-то грабли, то на них наступается каждый раз – если в процесс не вставить lessons learned специальной просьбой.
дальше я попытался давить все эти ошибки, заставляя проверять за собой и наращивая lessons learned. Бесполезно, ибо младшие модели своих ошибок не видят, это вам не Pro-версия. Всё как у людей! А ещё типичный способ исправления ошибки уже классический: если у вас на светофоре вместо зелёного вдруг загорается красный и вы хотите починить светофор, то всё, каюк. Для исправления ошибок сносится весь светофор, “нет светофора – нет ошибки”, хотя всё вокруг в руинах, закон Гудхарта работает и для агентов.
тогда я затеял тяжёлый процесс с внешним reviewer на ChatGPT с web-UI, и там уже Pro-модель. Всё немедленно улучшилось (ещё бы!), ибо глупому исполнителю начали давать умное review.
Проблемы: я сдуру говорил “architectural review” – и получил в итоге полную содержательную бессмыслицу, зато шикарно разложенную по разным паттернам, которые были разложены по разным кластерам, были обсуждены тонкие вопросы взаимодействия совсем уж содержательно незначительных паттернов. Гудхарт опять!
Но руками носить туда-сюда файлы между разными агентами тяжело. Причём эти review bundles ещё и собираются ой-ой как тяжело и медленно. Я тогда сделал dual role автоматизацию между двумя агентами – один executor и другой reviewer. У них есть план, и по плану они ползут – каждый шаг требует review, чтобы быть пройденным. Git, общение через reviewer inbox и executor hands-off на диске – как Машенька с Дубровским общались письмами в дупле. Всё сильно наладилось: глупого компьюта на один шаг стало вдвое больше (2 минуты executor делает содержательный шаг, но ещё 2 минуты этот шаг проверяет reviewer – и очень часто возвращает на доработку с конкретными замечаниями), дело как-то пошло более надёжно.
дальше восстановили архитектуру – функциональную часть, часть с именами, часть с учётом пользования, часть учёта, для этого мне надо было руками переходить из одного чата в другой и писать промпт: “Continue the dual-agent cycle for your role”. И тут же проблемы: все отчёты выглядят абсолютно одинаковыми и всё время забывается – чей же сейчас ход. У reviewer там “вернул, вернул, принял, вернул, принял, принял”, а у executor “пофиксил, пофиксил, продвинулся, пофиксил, сделал, пофиксил”. Ну, и чей сейчас ход? К тому же работа недостаточно обезьяная: надо перещёлкивать окна и постить промпт.
тогда я решил сделать диспетчер для двух агентов в форме Windows widget. Обозвал двух агентов reviewer и executor, а также запустил третьего агента-на-подхвате (обозвал его круто: superviser) и схватил с ним два дня вайбкодинга как его описывают с плохой стороны: этот “superviser” и отлаживался не в песочнице, а на живых ходах агентов, и забывал про UX вообще, и не вёл регрессионных тестов и списка lessons learned. Конечно, он знает слово harness, но пока я ему чего-то не говорил – он и не делал, а работал ad hoc, демонстрируя не разработку, а броуновское движение. Ошибки всё-таки приходится замечать мне, делать репорты об ошибках и даже говорить, какие там гипотезы. То есть статистически отладка обычно идёт в верном направлении – но дико медленно, ибо движение более-менее броуновское (но методологически правильное: гипотеза-проверка, а там уж для глупого больше времени надо, для умного чуток поменьше, но царских путей тут нет). С другой стороны, у меня сейчас есть приложение, которое мониторит происходящее в Codex и дальше само жмёт там нужные кнопки – и агенты передают работу друг другу уже без моего участия. Сейчас у меня в Codex три чата с тремя агентами в разных контекстах, но над общим экзокортексом (их репо проекта в Git, их zettelkasten проекта в файлах, их tools с разными handmade скриптами и скиллами), а ещё рядом висит приложение диспетчера. Почему диспетчер при многоагентности Codex? Потому как штатными средствами управление из чата в чат не передашь, увы. Хотя в какой-нибудь следующей версии – наверняка уже будет.
на разворачивание проектных документов, на прогон всяческих fit functions, на планирование очередных ходов, скажем, трёхуровневого плана, составляемого “на лету” в полном agile, и на прочее администрирование и проверки уходит дикое количество времени. И после каждой поправки надо “переинициализироваться”. И разгрести состояние, доставшееся от предыдущего сбоя рабочего процесса. Оргизменения для AI-агентов похожи на обычный менеджмент, хотя в астрономическом времени и занимают совсем немного. Но по содержанию – всё то же самое. Кремниевым работничкам тоже ведь недостаточно один раз сказать. Они могут разработать себе таблички вроде моих табличек из руководства по методологии, это не вопрос. Таблички будут с ошибками! И вот отладка занимает много времени. Зато потом всё идёт как надо. Конечно, у меня есть там много интересных особенностей: вроде использования свежеразработанных паттернов FPF в ходе разработки новых паттернов – ибо я работаю сейчас как раз с паттернами, которые чистят язык.
основной вывод: закон Amdahl работает и с двумя агентами (хоть людьми, хоть не очень) – трудно снизить дикий накладной расход на hands-off (у меня на каком-то этапе сложилось впечатление, что оформление результата и его передача, чтение ответов и прочие организационные действия занимают примерно столько же времени, сколько содержательные действия – ровно как теория и говорит: для двух агентов всё уже плохо, а три агента уже вообще не работают).
что тут очевидный next step? Конечно, оптимизация, “бесконечные улучшения”. Какие проблемы видны уже сейчас? Ресурсы: если у тебя всего двое разработчиков, то “оптимизатор” (организатор) тут или я сам (об этом пишут изо всех утюгов, “человек должен организовать всех этих агентов, он должен уметь это делать”), и у меня квалификации вполне хватит. Ну, или у меня хватит квалификации сделать агента-организатора – и это тоже проблема, поскольку это ещё сразу два агента по текущей схеме, дополнительное программирование, разворачивание песочницы и ещё примерно столько же токенов, а ещё и замедление хода разработки на постоянное изменение процесса. Ну, и вся эта организация – там уровень FPF на описание того, о чём вообще думать, но затем нужно же SoTA конкретного процесса, а это уже SPF и TPF, так что я пока ad hoc пойду. Всё одно у меня при текущих недельных лимитах на “ходы в Codex” их не совсем хватает (и это тоже надо оптимизировать, там по доллару за ход, насколько я помню, если вылетаешь за пределы flat rate у Pro).
а пока я пишу эту строку, два агента что-то там дорабатывают в SurfacePrecisionRestoration, это уже следующий паттерн.
а когда я пишу эту строку, то там уже три агента – двое за delivery team, один за Platform Engineering, и договариваемся, кто там будет за архитектора и визионера. Вот один из моих промптов в разговоре: “У нас какой-то дикий hands-off. С одной стороны, это безопасно – если каждый чих передаётся на review. Работа идёт дробными шагами, локальные правки, простые откаты, легко определять состояние. Но 50% уходит на high ceremony hands-off и только 50% на содержательную работу. Как бы это оптимизировать? У тебя часто роль супервайзера, может это ему надо поручить как-то организовать? Сейчас reviewer работает примерно 2 минуты, из них старт-стоп операции по формированию отчётов занимают 1 минуту. У тебя примерно 4 минуты, из них старт-стоп занимают примерно 2 минуты. Насколько можно увеличивать шаги, чтобы доля hands-off между агентами падала, но процесс оставался надёжным, управляемым, безопасным? Спланируй какие-то оптимизационные изменения для процесса, пусть reviewer их проверит – и пойдём по оптимизированной процедуре.”. Уже сгенерировано предложение, где “зафиксированы live-метрики цикла и предложены rule changes: укрупнить default macro-step, сделать continue-step нормальным исходом для obvious same-goal follow-through, сократить standalone PLAN-* passes, батчить low-risk control-plane fixes внутри того же macro-step, сохранить R1-EXEC-06 как deferred next content step, а не выбрасывать его”. Дальше это пошло на проверку, было принято (с маленькими поправками) и пошло на исполнение. Поглядим на результат. Потом поставим там внутри PDCA и POOGI, всё как обычно. Я не хочу работать надсмотрщиком за агентами, я всю жизнь был консультантом по оргразвитию. Я буду их оргразвивать, как бы смешно это ни звучало.
мне было любопытно, как это сработает. Конечно, никак! Пошёл на lessons learned – и получил “до первой оптимизации accepted content step в среднем занимал 4.31 событий цикла и 1.56 relay в review; после неё по живой выборке это стало примерно 4.0 и 1.5, то есть почти без эффекта;”. Ну, и дальше там ужесточение правил, уменьшение hands-off и через пару часов опять глядим на эффект. Нет, ужесточение правил не повлияло на эффект, поэтому переписываем тамошнее планирование почти вручную – под диктовку разделение ролей, снятие конфликта интересов и т.д. Конечно, GPT-5.4 всё это знает! Но в этом и проблема: пока не скажешь, какое знание она должна применить – не делает, хорошо выдрессирована. А вдруг пользователь любитель Адизеса? А вдруг про TameFlow не знает, зато уважает Голдратта? А вдруг он хочет Шухарта, считая, что Дёминг его исказил? Лучше сделать “как обычный человек” – тогда пользователь точно согласится, ибо узнает себя, как в зеркале! Поэтому явно говорю: учитываем конфликты интересов ролей, явно разделяем работу над FPF от работы над организацией его разработки – и всё сразу отличненько! Дальше документация переписывается, меняются скрипты, меняется тот самый диспетчер (ибо диспетчер знает про роли, но чтобы его не забыть мы делаем “документальный твин” для диспетчера, напоминающий, что он где-то там висит, и его тоже надо пропатчить и перезапустить при смене процесса).
с fit functions я, конечно, тоже разберусь. Как съесть слона? Сегодня ответ – “по одному промпту за раз”.
местный не очень живой вайбкодер у меня уже вайбкодит с FPF и DDD – и это сразу помогло перестать пользовательский интерфейс делать не в терминах пользователя, а на внутреннем жаргоне программных объектов (у программистов это обычно практически невозможно включить, они думают reference frame состояний программы, а не состояний мира и возможных действий оператора). И FPF уже использован для приведения в порядок местных протоколов работы, в которых было “всё как всегда”, а стало сильно получше – без ручной правки.
операционные метрики уже считаются, скорость работы в рамках POOGI поднимается (мантра элегантности – убирается лишняя работа, прежде всего high ceremony hands-off вроде “один баг – одна передача на проверку”, и “баг” тут обобщённое понятие, у меня в разработке FPF не software engineering, на выходе паттерны – но это не значит, что там не надо проверять ошибки!)
… и так далее, ибо “непрерывное совершенствование” и даже “бесконечное развитие” (ибо кроме совершенствования я ещё и регулярно ищу себе и этой живущей в Codex команде новые проблемы).

Что мне нравится прямо сейчас: фразы в thinking AI-агента с говорящим именем Platform Engineer вроде таких: “Сужаю сейчас до самых явных Conway leaks. По FPF-критерию это места, где transition labels и delivery traces заняли место state/architecture owners: если документ должен описывать текущую semio posture или semantic companion burden, а вместо этого несёт R*-EXEC-/PLAN-EXEC- историю, это уже смешение kinds.”. Это я его отправил аудировать архитектурные документы ровно на предмет не “давайте делать вот это и это” а “готовьте приказ на это и это” (классическая подмена! Меня она всегда удивляла, но и у AI-агентов она тоже есть!). Дальше не “работы по”, а “исполнение приказа номер” – и всё, предметная область работ оказывается надёжно отделена от обсуждающих “исполнение приказа номер”, в речи она больше не проявляется. FPF такое помогает ловить, он уже работает в проекте по собственному созданию! Маленький кусочек сингулярности с её lift-off и уменя тоже! Я заставил сказать потом, в чём именно при аудите процесса и его связки с архитектурными документами помог FPF. Вот что написал мой Platform Engineer (“орфограция и пунктуация авторские”): "Where FPF Helped

FPF helped separate state from transition. semioarchitecture-work-status-memo should own current package state, not the chronology of accepted delivery steps.
FPF helped separate activation record from one historical opening move. The readiness note is a retained justification surface; R2-OPEN-01 was only one transition that consumed it.
FPF helped separate release group from bounded move label. R2 is a package-sequencing object; R2-DRAFT-02 was a trace label, not part of the semantic architecture.
FPF also prevented over-cleaning: I left legitimate semio uses of handoff, boundary, and reviewer in pattern/law texts when they clearly name semantic reroutes or authority seams, not delivery-loop choreography.

Основная мысль тут простая, и этому мы учим – от смены агента с живого на не очень живого ничего не меняется. Есть инженерия, есть менеджмент, есть инженеры-менеджеры, которым это было бы неплохо знать. И, конечно, системное мышление, которое говорит, что цели всегда внешние, создание системы и создание системы создания отличаются, а у системы в целом есть эмерджентность, поэтому хорошо организованные тупые агенты и инструменты могут показать результаты лучше, чем плохо организованные супер-пупер Pro-агенты. Как говорится, “из той же мучки, да не те ручки”. Голенький AI-агент без правильно спроектированной вокруг него системы проверки, инструментов и форматов передачи дел другому AI-агенту или человеку не является единицей производительности. Ровно как не является единицей производительности любой очень умный человек, не окружённый довольно развитой системой, использующей все его возможности и корректирующей все его недостатки (и то и другое – весьма неполно, агенты всегда имеют недоиспользованные возможности и прорывающиеся через все защиты недостатки).

Что меня тут восхищает – это один из самых быстрых проектов оргразвития, которые я проводил. Пишешь задание на доработку организационных документов (для не очень живой организации, ага) – и через 11 минут шипения вентиляторов получаешь “Изменено 17 файлов, вставлено 368 строчек, удалено 3” (и там такие интересные “документы” как AGENTS.md и measury-dual-agent-cycle.py, ну а остальные – как обычно, вроде working-conventions-semioarchitecture.md или platform-engineer-protocol.md). Вот так надо работать! Я долго хотел быть артигогом (вот, ещё в 2012 году писал). Проект самого FPF требует мастерства “мышления по первым принципам”, мета-мета-моделирования мира. Это в нашей программе рабочего развития – резидентуры R1-R7. Какие там агенты, если в AI-чатах вроде ChatGPT только LLM без особых возможностей планирования и без доступа к внешней памяти на запись для удержания длинного планирования? Но с Codex App я могу применить уже и свои знания по организации коллективного труда, это у нас резидентуры R8-R10, системная инженерия и системный менеджмент как раз там. С этими AI-агентами в Codex я при деле не только по линии самого FPF! И там всё, как в обычной инженерии, в том числе системном менеджменте как инженерии организации:

управление конфигурацией сначала, всё остальное – только после него. И главное тут – hands-off, конфигурация ломается на передачах из рук в руки.
чётко различать работу с организацией процесса от содержательной работы. Иначе что-то из них точно страдает. Грубо говоря, не путать главного инженера предприятия и главного инженера проекта, они про разное.
всё писать, управление ведётся через записи (иначе не отладишься, кто там кому что когда передал и зачем). Записи нужны не только содержательные “про продукт”, но и организационные “про проект”, ничего “с голоса” и “в уме, в чертогах разума”.
выделять достаточные ресурсы на организацию, сами инженеры знаний по организации обычно не имеют, а менеджеры необоснованно считают, что они эти знания имеют – поэтому инженеры-менеджеры (чтобы могли разобраться). В случае AI-агентов тут полное счастье, они “из коробки” инженеры-менеджеры, с ними легко поэтому договориться, хотя они и туповаты, про своё инженерство-менеджерство не знают, о нём без отдельного приглашения не вспоминают. С людьми тут – засада, просто напомнить – не поможет, потому как человеку сначала надо этот материал освоить. Если человек не знает, что такое POOGI и PDCA, то ему не скажешь – “делай”, а AI-агенту можно сказать – он знает, просто надо сказать “делай”.
если у вас программисты, сразу говорите про DDD, иначе вы с их софтом не разберётесь. И заставляйте пользоваться FPF, иначе отлаживаться с организационным софтом будете до морковкина заговенья (агент сообщает об этом просто: “я тут написал вот так, а этот гад в соседнем чате протрактовал это вот так, но не волнуйся, хозяин, сейчас ужесточу формулировку” – не верьте: “ужесточу” тут обычно не помогает, помогает только разобраться и правильно отмоделировать. Агент сможет это сделать, если вы его пнёте в правильном направлении)
организация держится не людьми или даже не AI-агентами, а коллективным экзокортексом. Поэтому уговаривать людей надо один раз – пользоваться экзокортексом в обязательном порядке, а внимание уделять этому экзокортексу – базам и банкам данных, софту. Вот я диспетчер наваял, в самом Codex этого не хватало.
разделение ролей надо блюсти. Архитектор и разработчик, визионер, инженер платформы, операционный менеджер – вот всё это должно присутствовать. И кто-то должен вести нормальные циклы PDCA, POOGI – и для этого нужно иметь индикаторы, и всё это должно быть. AI-агенты это сделают на раз-два, но вы должны знать, что об этом их надо просить.
… тут я могу пересказывать дальше все руководства, а это довольно много текста, остановлюсь. Но вы уже поняли: пока AI-агентов организуют программисты, хорошо не будет. Их должны организовывать инженеры-менеджеры.

Если брать семиотическое содержание FPF, то оно за последнюю пару дней продвинулось немного. То есть оно продвинулось, конечно, но это пока много ниже средней скорости в два паттерна в день, которые я делал ручной работой на Pro. С другой стороны, довольно много всякой архитектурной содержательной работы было сделано, но не отсмотрено, пока я возился с процессом. Из интересного:

проблемы, которые появляются в ходе разработки – это всё те же проблемы с неточным языком. Поэтому их можно сходу брать как примеры. Один из таких примеров – отсутствие слова для какого-то “семиотического объекта”, там в одной фразе его называют text/material/artifact/surface/face/shell/view/document/publication. Ох. Сразу становится понятным, что мои “синонимы с нюансами” – это те самые trigger words. И надо делать на них какой-то аналог “уточнителя языка” A.6.P, который напрягается на эти триггер-слова и дальше вводит для точности какую-то онтологию ситуации и задаёт уточняющий вопрос “а что вы конкретно имеете в виду?!”. Тут всплывает чёткая метафора чего-то сложного многоуровневого, где мы видим только поверхность (surface, которая публикуема). Но вот если этих поверхностей несколько и появляется иногда нумерация, иногда “верхняя, нижняя”, то слово меняется на shell. В итоге этим будет заниматься SurfaceObjectOfTalkDiscipline, а там поглядим, куда и к чему это приведёт.
требуется постоянный пригляд за отсутствием предписанного workflow. Ибо люди склонны путать онтологию и методологию: описание мира и возможных в этом мире операций неминуемо утыкается в “а вот тут у нас lifecycle” – и дальше в текст попадают двусмысленности, даже если в тексте этого lifecycle нет (но торчат уши лексики движения по его шагам). Это приходится контролировать отдельно: “на уровне FPF есть трансдукции и идея графа этих трансдукций в трансдисциплинах, но не конкретные варианты графа трансдукций даже для трансдисциплин. Разве в качестве примеров, но не как норматив. С вариантами трансдукционного workflow, даже типового для каких-то команд, пожалуйста, идите в SPF и даже TPF (вторые и третьи принципы)”. Всё-таки желание иметь волшебные шаги happy path глубоко растворено в культуре, на текстах которой учили LLM в агентах. Мысль о том, что тексты надо уточнять вот такими шагами – она полагается AI-агентами естественной, не подлежащей обсуждению. Надо явно говорить, что у нас абстрактные маршруты в семиотическом пространстве, а на уточнение текста есть пример обратного – объяснение маленькому ребёнку или executive summary. О! Тогда другое дело – и агент быстренько исправляется, на целых пять минут. Потом всё как у людей:
очень интересно было, как агенты протрактовали моё предложение добавить кроме классической модульной архитектуры (они её называли module and packaging, затем перешли на owners and packaging) ещё и функциональную архитектуру и “поглядите, что там ещё нужно”. Они почитали, что там я ещё спрашивал – и изобрели новое слово, “архитектурный оверлей” (как я понимаю, это ещё один синоним для view/surface и всё такое). Теперь у меня в архитектуре (в отдельных файлах! Их агенты плодят сотнями, прямо-таки zettelkasten, “заводят карточки” и часто их апдейтят) есть такие оверлеи: functional, purpose and usability, rationale and competitive positioning, naming ADR and F.18 name cards, packaging decision surface (ага, “оверлей по поводу того, какие у нас решения о surfaces”). Вот этот packaging decision surface – это и есть “как рассовать содержание по модулям-паттернам”. Этот overlay – ещё одно мутное слово типа shell, ибо сами семио-паттерны для FPF иногда называются “семио-оверлей” (поскольку “наложенная на FPF структура из рассованных в разные места логически связных паттернов, а не компактно собранная куда-то в кластер или часть”). Но на список этих “оверлеев архитектуры” (который возник, конечно, не без моего участия, ибо я указывал на дыры – и эти дыры были сочтены “архитектурными”) надо, конечно, долго смотреть и думать. Очень интересно!
Разработка самих паттернов FPF подтверждает необходимость паттернов точности языка в нём самом: процесс постоянно натыкается на trigger words, которые ломают и итоговое содержательное рассуждение внутри FPF до степени невозможности им пользоваться, и организацию шагов разработки FPF.

С LLM-экосистемами (а дальше то же самое с world-models экосистемами) всё то же самое, что с любыми тяжёлыми инструментами, где долго-долго выбираешь – а потом долго-долго сидишь, игнорируя любые мелкие движения Парето-фронта, ибо в целом непрерывное совершенствование всё одно помогает решать твою проблему. С акциями то же самое: купил большой пакет – ну, сиди на нём, не дёргайся (если, конечно, ты не занят HFT). Поэтому я выбрал “сидеть на экосистеме OpenAI”, несмотря на всю критику. Конечно, все эти экосистемы (одна только LLM тут ничего не решает, рулят эмерджентные свойства – и даже не только AI-агента, но и приложения в целом) непрерывно пытаются двигать Парето-фронт и выбор любой из них тут только выбор точки на этом Парето-фронте. Кто “победит”? Я думаю, что никто – как и на любом рынке, включая рынок труда. Кто-то всегда будет умнее, кто-то зато быстрее, а кто-то педантичней при средней скорости и среднем уме, кто-то банально будет больше знать, кто-то будет больше проявлять инициативу, кто-то будет безопасней. Эти “кто-то” уж непонятно, то ли команды разработчиков я тут имею в виду, то ли их AI-агентов, чьё поведение ну очень живое (“плавает как утка, крякает как утка, выглядит как утка – значит, утка”). Скажем, Anthropic сделал контекст в 1M токенов и хвастается, что это честный миллион. OpenAI заявило тоже, что 1M – но на графиках видно, что это нечестный миллион, “маркетинговый”. Но в целом – все эти модели решают какие-то задачи, лучше, какие-то хуже, ибо кроме контекста там ещё 100500 важных характеристик. Ну, и дальше “хитрые маркетинговые приёмы” вроде уменьшения контекста до 0.258M в Codex App (я раньше думал, что это “чтобы тратить поменьше ресурсов на ответ” и “чтобы регулировать цену в зависимости от дозволенного контекста”, теперь понимаю, что это “чтобы не залезали туда, где контекст вроде есть, но только вредит, ибо врёт”). Но и это пройдёт, в какой-нибудь из следующих версий. А пока осваиваю Codex, делаю его агентов продуктивной организацией.