От vibe-coding к делегированию: LLM сейчас учится быть агентом, а ты учись быть

ailev — 19.09.2025 Я вчерне закончил писать восемь паттернов части G, посвящённые генерации SoTA архитеорий для дисциплин (паттерны G.0-7), осталось ещё шесть (G.8-13), но я посчитал, что пока хватит -- и веду весь день задушевные онтологические разговоры с GPT-5 Pro. Обсуждается очень компактный набор понятий, позволяющий обсуждать важное в "железной" инженерии, инженерии знаний (в том числе науке), инженерии сообществ, инженерии методов и т.д. Грубо говоря, сделан механизм science-of-science, который позволяет подбирать метод к задаче, вот теперь надо как-то это обобщить на все вообще холоны: подбирать конструктивы к ролям, описывать семейства реализаций для каких-то сигнатур и т.д. Вот только часть для такого подхода:
-- есть холоны, у которых есть мета-холонный переход через границы каких-то "уровней". К ним относятся эпистемы, дисциплины, системы, сообщества и прочие объекты, которые можно собирать-разбирать, причём фишка в том, что там есть некоторая "сигнатура" на границе, задающая интерфейс, а у холона есть характеристики. И это принципиально многоуровнево. И да, entity of interest из ISO 42010:2022 -- это holon-of-interest.
-- есть предметные области (сеть bounded contexts), они -- нормативные единицы смысла и значения. В основе там boundedContexts из DDD, и там локальные инварианты, а также задание эквивалентности понятий через "мосты" разрешённых проекций из одного контекста в другой. И domains -- это не дисциплины, а дисциплины как раз -- холоны.
-- есть разные другие интенсиональные объекты, вроде роли, архитектуры, метода, работы. У них тоже есть свои "внутри-снаружи" и тем самым интерфейсы-сигнатуры, а также варианты "внутри" для реализации какой-то сигнатуры как контракта. Но это всегда на один уровень, а многоуровневость "кажущаяся", ибо это всё про холоны -- а они многоуровневы. То есть архитектура холона одноуровнева, но поскольку у холона много уровней, то выглядит это многоуровнево. Похоже, надо разводить понятия "сигнатуры" для реализаций-задействований (role/method enactment в ходе работы) и реализаций холонных (организация/структура на каком-то мереологическом уровне).
-- разные варианты для одной сигнатуры -- семейства, в том числе, например, семейства традиций/"научных или инженерных школ" внутри какой-то дисциплины, семейства систем и даже семейства методов, семейства характеризаций (определения пространства важных характеристик).
-- и ещё есть чёткое разделение "мир -- концепт -- эпистема" (планов реальности, описания, описания описаний и т.д., тут живёт aboutness, переведите на русский сами). И да, сигнатур два типа: для enactment с ролями и холонная для структурной организации (и надо бы как-то их ещё именами развести).
-- ... и всё в таком же духе, с этим буду работать до конца недели минимум. Ибо надо опять переделывать ядро FPF. Тест, который хочу пройти: гладкое моделирование "методологии" как дисциплины. Для начала -- всего того, что описано в первой части руководства по методологии (напомню, что там речь шла о вариантах разложения метода, но по факту -- о вариантах описания реализации метода для какой-то сигнатуры: иерархиями, алгоритмами, спектрами и т.д.). Пока с таким уровнем универсальности в FPF есть проблемы, с ними и разбираюсь.

Понятий в FPF не так уж много, и они сразу организованы удобно для применения: даются некоторые представления этих понятий для "мышления письмом" (таблички, карточки и т.д.), а что с ними делать описано в языке паттернов, а также там чеклисты. У этих немногих понятий дьявольская выразительная сила, универсальность такого подхода к моделированию мира будет чуть повыше, чем в наших нынешних руководствах. Это именно ход к моделированию через "первые принципы", как в физике (там это те же переменные, пространства и динамика, инварианты, симметрия, информация и прочие базовые понятия для описания мира и мышления об описаниях мира). И тут беда: чтобы обсуждать мышление и первые принципы, надо уже как-то этим мышлением на базе первых принципов владеть. У нас тут есть хак мозга, чтобы пройти это ограничение: надо иметь хоть какое-то беглое владение материалами наших нынешних руководств. Без этого трудно говорить о том, чтобы этим всем овладеть, ибо никаких учебных курсов на тему "как обсуждать мышление, науку, инженерию и AI компактным набором понятий" нет, а мы в мастерской инженеров-менеджеров и сами отказались от разговора про "обучение", ибо тут вопрос не обучения, а вопрос овладения культурой (ну, или наоборот -- "культура тобой овладевает, а не ты культурой"). Если же не обсуждать мир и мышление, то мы можем пролететь мимо обсуждения мира и самого мыслящего вещества в мире -- имеется ввиду LLM, а не "самое мыслящее существо", не человек. Да, мы тут говорим о том, что значительная часть мышления уходит от людей к AI и надо понимать, что там вершки, а что корешки (помните сказку про "тебе вершки, мне корешки. А в следующий раз сделаем наоборот"?). Буду рассказывать об этом на семинаре "First Principles Framework в программе исследовательского развития инженеров-менеджеров" уже через пару недель (4 октября 2025, https://ailev.livejournal.com/1776026.html).

Начнём с вопроса про умственную работу, как её понимали менеджеры (хотя начальная версия анекдота была не про менеджеров, но про делегирование -- это ж любимый вопрос менеджеров, "выход из операционки"). Сидят два менеджера на унитазах и тужатся, дело идёт не слишком хорошо. Один из них говорит другому: "это мы занимаемся умственной работой, или физической?". Другой отвечает: "конечно, умственной. Если бы это была физическая работа, то мы бы её давно кому-нибудь поручили". В связи с приходом AI вопрос стал о поручении умственной работы. И нет языка, чтобы это обсуждать, ибо обсуждению мышления никто не учит. Основной обсуждаемый вопрос сейчас -- это vibe coding. Но вот как там ставится задача для этого vibe coding -- это не обсуждается. И как это обобщается до уровня инженерии в целом (ибо в vibe coding можно говорить что где-то там кто-то занимается DDD и на выходе там очень кучерявые схемы данных, по факту моделирующие предметную область предприятия, но в классической инженерии и менеджменте это уже не так просто сформулировать, что там "переводит use case в конструкцию железа или конструкцию предприятия"). МИМ бьёт именно в эту точку: мастер оргразвития организует работу людей и AI, для этого понимает, что там происходит с AI не в части "как устроено", а в части "что поручить продумать, как поручить-объяснить, как проверить, что результат -- то, что поручали". То есть пишем приказы, читаем ответы, уточняем приказы, проверяем ответы, призываем коллег помочь и т.д. -- ах, это я описываю то, чем занимаются менеджеры, "делегируют работы". Чёрт, опять говорим об инженерах-менеджерах, а не просто инженерах или менеджерах. Только это менеджмент AI, обсуждаем понятия метода работы, собственно работы, стратегирования как выбора метода работы, перевода проблем в задачи (которые можно поставить AI для решения). Где этому учат? Вообще-то тут в центре оказываются визионерство, методология, архитектура из инженерных специальностей, а не проектирование-кодирование-тестирование, то есть "постановка задачи" и "делегирование и приёмка", то есть классика системной инженерии (не путать с "просто инженерией", где центральная дисциплина design и CAD, в системной инженерии всё-таки другие акценты). Но дальше встаёт вопрос про вот это "делегирование" и организация труда (да, "инженерный процесс"), и там уже системноинженерный менеджмент (SEM), что тоже системная инженерия, но и менеджмент. В инженерном образовании тут учат "по наитию", как "пользованию инструментам" (вам покажут Arcadia/Capella и расскажут про ISO 42010 и дадут понюхать SysML, но в жизни-то будет по-другому! И это не поддерживает собственно менеджерской части). Вот мы ровно этим салатом из (системной) инженерии и менеджмента с выходом в R&D (формулирование проекта и его продукта, визионерство) и занимамся в мастерской инженеров-менеджеров. FPF тут -- один из инструментов решения проблемы. И "обучением" тут не отделаешься, это цивилизационный сдвиг, это освоение другой культуры. Это я опять пою песню из предыдущего абзаца про разделение труда между людьми и не очень людьми, а ещё я писал на эту тему вчера в четвёртом абзаце(https://ailev.livejournal.com/1776289.html, про DDD и LLM under the hood, но и первый абзац там в тему: надо научиться разговаривать и обсуждать коммуникацию, а это семантика как связь хоть как-то осмысленной лексики/меток навешанных на эту лексику понятий с одной стороны и логики с другой стороны).

Темы, над которыми надо не забыть подумать:
-- иерархии против генеалогий (это к вопросу о выборе из архитектурных вариантов, по факту это типы против конструкционизма/следов, так вот генеалогия это что-то типа этих конструкционистских traces2logic из FPF, какая-то такая смутная аналогия, при этом "трасса" генезиса, конечно, не совсем трасса сборки, вот и думать).
-- близко к этому статья Stanley про fractured entangled representations из тусовки open-endedness, она про это: https://arxiv.org/abs/2505.11581 (если у тебя трасса обучения как генетическая, то эти представления evolvable, а если "трансформер" или что подобное -- то не evolvable, в этом проблема).
-- архитектура оказывается интересным объектом (см. первый абзац), но дальше не забыть, что планировалось: она должна быть рациональная, внутри рациональности принятие решений в условиях неопределённости, удержание решения на границе Парето пространства архитектурных характеристик (trade-offs) и универсализация самих архитектурных характеристик (они чуть разные для разных холонов, вот и поглядеть, что там уж совсем общее -- типа той же evolvability).
-- физические "первые принципы" против "первых принципов" из FPF и разных других "первых принципов" (опять же, ожидаю унификации)
-- новая раскладка ролей в инженерном процессе (при условии, что часть съезжает на AI). Вот решена какая-то задача: как называется человек, который а) ставил эту задачу и б) понял, что была решена не та задача? Это ж не менеджер (он в задачах обычно не понимает, но распределяет работы вроде он и принимает работы он, "делает выводы" по поводу систематического невыполнения работы "как надо" тоже он), но и не инженер (поскольку инженер решает задачи, принимает решения, а тут вроде это делает LLM). Надо это как-то поточней формулировать, ибо первое что приходит в голову -- это "системный инженер", что сразу сомнительная роль, это широко обсуждалось (как инженер систем против системного инженера, одна только линия обсуждений), или в софте вообще "аналитик", в самом слове только "понимание и указание на ошибки", а вот принять решение и оценить, насколько выполнено решение -- нет такого. Опять же, очень близко тут "визионер" и "архитектор", но визионер -- это по факту "корпоративный предприниматель" (непонятное происхождение), а архитектор -- опять "привет, системная инженерия, это твоя центральная роль".
-- полным ходом обсуждаются принципал-агентские протоколы (вот первый из них, от Гугла, agent payment protocol, AP2 -- https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol, а я ещё поминал принципал-агентские отношения и всякую экзотику вроде некроагентов ещё в 2013, на форсайте нейронета, интересно было перечитать, https://ailev.livejournal.com/1090080.html, но темой когда-то я занимался плотно по линии экономики и даже полит-экономии (вот, например, 2006 год, про принципал-агентские отношения чиновников как "агентов народа-принципала", https://ailev.livejournal.com/345508.html). Тема мутная, но сейчас это мейнстрим. Если уж заниматься "делегированием работ", то это ж оно самое -- что в инженерии, что в коммерции, что в менеджменте, везде где было computer-the-loop, а стало вдруг human-in-the-loop. Надо как-то эту принципал-агентскую тему в голове освежить (и там ключевые слова "конфликт интересов", intent verification, mandates, границы планирования, связь с разделением труда (раскладка по ролям и capability), прозрачность и ой-ой сколько всего. Привет, новая инженерия, где вот это вот всё. Если делегировать что-то нежити, то надо уметь это обсудить профессионально. Далее стыкуем с FPF: агент и принципал это роли, там алгебра ролей, но и role state graph тоже, и ход на подбор конструктива и архитектуру, и много чего ещё есть. Огромная исследовательская полянка, и очень актуальная вот прямо сейчас.
-- в FPF уже есть понятие научной школы (в том числе и как организации, продвигающей какой-то набор теорий), а также понятие SoTA. Так что уже можно начинать осторожно разбираться с понятием культуры, в том числе SoTA культуры. Давно ведь хотелось, можно уже осторожно пробовать.

Как всегда, планов чуть больше, чем можно их реализовать даже с учётом увеличения производительности x10. Тут ещё надо понимать, что если даже скормить этот текст сверхумной GPT-7 и получить в ответ толстую книжку с расчудесными подробными ответами, то выйдет неожиданный тормоз: время на понимание ответа. Раньше ты быстро формулировал вопрос и долго-долго ждал ответа, потом быстро-быстро читал этот ответ. Но на большой вопрос у тебя будет большой ответ -- и тут легко выяснится, что лимитирующий фактор не твоя способность задать правильный вопрос, а твоя способность понять, что же такое тебе ответили. Да, можно попросить AI растолковать, сделать тебе микро-учебный курс. Но, как и любое обучение, это мееееееееедленно. Надо ещё и как-то уметь управлять нужным уровнем своего понимания, нормируя на это время. Это то же "время развития", "время обучения", но в случае рабочего проекта оно таковым не считается. Если вам принёс сотрудник заказанную вами же работу, вы её не "изучаете", не "понимаете", а делаете с ней что-то другое. Но по факту -- именно изучаете, понимаете, проверяете. Вот то же самое в случае LLM. Это немного неожиданный поворот. Конечно, все мы инженеры и программисты, изучали выдачи компьютера часами, чтобы понять, что делать дальше и какие там ошибки надо исправлять. Но тут горшочек варит с такой скоростью и в таких объёмах, что не справляешься с потреблением заказанного. А сказать "горшочек, не вари" -- нельзя, в этой же скорости и объёме варки вся фишка!

Оставить комментарий

Популярные посты:

• Ранее
• Архив