Ложное ожидание: “Вкалывают роботы, а не человек”
«Вкалывают роботы, а не человек» — это из песни «До чего дошёл прогресс» (авторы Ю. Энтин, Е. Крылатов), звучащей в фильме «Приключения Электроника». Мы до этого дожили? Не совсем. Как мы помним из стахановского движения (началось оно с разделения труда в добыче угля, а там пошло-поехало), ткачи следили за несколькими станками (где-то там обрыв нити, где-то катушку переставить, где-то стартовать новую ткань). И стахановцы увеличивали число станков, за которыми они успевали следить. Та история была не очень приглядная, ибо если рядом с вами кто-то демонстрирует высокую производительность, то вы быстро понимаете, что вам на следующей неделе повысят норму. И дальше этот стахановец получает мешком по голове в тёмном коридоре, чтобы не подводил коллектив. AI-агенты, конечно, не ткацкие станки, но тоже требуют пригляда в ходе работы. Говорят, в OpenAI тамошние стахановцы работают над десятком проектов сразу, приглядывая за своими ткацкими станками, которые ткут софт в автоматическом режиме. Вроде вкалывают роботы, вкалывают станки, но мешком по голове получают таки люди – и за слишком малую выработку, и за слишком большую. ОК, в капиталистическом обществе за слишком большую выработку получают не мешком по голове, а опцион на акции компании. Но эту большую выработку надо ещё уметь продемонстрировать.
Вайб-работа (вайб - это “по наитию”, подробно я писал о ней во вчерашнем посте “Профессиональное кодирование и моделирование против вайб-кодирования и вайб-моделирования”, Профессиональное кодирование и моделирование против вайб-кодирования и вайб-моделирования: ailev — ЖЖ) даёт ложное чувство, что можно быть “общеумным” и не разбираться в предметной области, чтобы хорошо работать: просто сдвинуть всё разбирательство на AI-агента, пусть там себе крутит свои циклы. Особенно смущают статьи вроде рекламы Codex с описанием кейса разработки, где ноль строк кода было написано людьми – https://openai.com/index/harness-engineering/ (11 февраля 2026) или My AI Adoption Journey – Mitchell Hashimoto (5 февраля 2026, приходится уже указывать не только год публикации, но и конкретный день, всё ведь подобное быстроскисающее – со скоростью продуктов в молочном отделе супермаркета).
Там (и не только там! это носится в воздухе) чётко написано: отдаём свою работу AI-агентам, а сами только приглядываем (делаем harness, “упряжь” – всё быстро, prompt engineering поглотилось context engineering, а тот теперь всё съел harness engineering, “медленно запрягаем людьми, затем быстро едем”, при этом по возможности быстро (но медленно, ибо это же люди!) рулим AI-агентами при их быстрой езде). В статье чётко: Humans steer. Agents execute.
В этом-то и фишка: “сами только рулим”, и в этом “рулении/steer” довольно много умений. Это даже не governance, сводящийся к “направлению и надзору” за автономной работой, язык правил и ответственности. Это именно “руление”, управление с учётом обратной связи из control theory – и вряд ли это слово в статье выбрано случайно. Steering/руление – это в условиях дрейфа целей, результатов, окружения отслеживать постановку целей, снабжать нужным контекстом и инструментами, уточнять инженерный процесс, задавать ограничения, проверять инженерные обоснования того, что всё в порядке – и следить, что эти обоснования на основе данных эксплуатации, а не нафантазированы, и всё это в цикле, вернее, во многих слоях цикличности – если у вас сложная система, то вы рано или поздно придёте к многослойной архитектуре руления, вспомните работы Matni и Doyle со товарищи, “Towards a Theory of Control Architecture: A quantitative framework for layered multi-rate control” ([2401.15185] Towards a Theory of Control Architecture: A quantitative framework for layered multi-rate control). Управление всегда дорого, а сейчас исполнение ускорилось и подешевело, руление стало узким местом.
Но рулить надо уметь! К статье надо было обязательно делать дисклеймер: “эти трюки выполняют хорошо обученные люди, не пытайтесь повторить их сами без тренировки”. Но какие тут могут быть тренировки?! Более того, “тренировки” и “обучение” тут плохие слова, ибо речь идёт о непрерывном развитии у инженеров-менеджеров довольно большого числа умений, и развитие их до уровня, когда можно будет говорить не о “любительстве” и “пет-проектах”, а о нормальной рабочей квалификации и развитие в этих умениях – выплачиваемый вами целевой налог на автономию ваших AI-агентов:
- формулирование целей: проблематизация верхнего уровня, задание на стратегирование как характеризация проблемы (все эти “проблематизации” и “характеризации” я объяснял на семинаре “Развитие для развитых”)
- предоставление доступа к контексту и уменьшение нерелевантного контекста (это же шум!)
- организация инженерного процесса: как он будет идти, как устроен “бесконечный цикл развития продукта”
- проверка результатов работы и правка постановки задачи
- добавление проверок в ходе получения опыта работы, ибо “только бледнолицый наступает два раза на одни и те же грабли”
- … и это не полный список, что надо уметь выполнять не любительски или ученически, а профессионально. Например, операционный менеджмент, чтобы планировать свою беготню по 10 разным проектам, которые требуют “руления”.
Ничего нового, обычное инженерное мастерство (у меня в руководстве по системной инженерии большинство из упомянутых методов, мастерство в которых надо иметь, расписаны, хотя и на довольно высоком уровне абстракции, и язык немного другой – меньше акцента на “контекст”, но достаточно про визионерство и проблематизацию). Сегодня, когда на вас сваливается стахановство с десятком проектов, вам придётся заземлять их на огромное число разных ситуаций: “запрягать/harness” придётся AI-агентов и людей (вместе!), а также быстро-быстро перепрягать, ибо инженерные процессы только-только начали стремительно изменяться. Новизна в том, что эти “тренды” развиваются уже не годами, а месяцами, скоро будут развиваться днями, а там и на секунды счёт пойдёт – какая-нибудь гипотеза будет проверяться за пару секунд: спроектировали, изготовили (необязательно же речь идёт о программировании! Машиностроение тоже в деле!), испытали, по итогам испытаний решили всё переделать. Ну, в машиностроении это будут вряд ли секунды, но уж точно не текущие месяцы. Пример того, как биржевой рынок перешёл к электронной торговле и появился высокочастотный трейдинг, я уже приводил. Это будет во всех областях, не только в трейдинге. И часто даже не потому, что люди работают недостаточно быстро и требуют ночного сна, но потому, что люди работают недостаточно точно и воспроизводимо.
И ещё важнейший пункт: если вы работаете сам-один, то вы вполне можете сдвинуть довольно много работы на AI-агентов, но если у вас коллективная разработка, то вам неминуемо придётся заниматься менеджментом, много разговаривать с людьми, чтобы вписать эту работу агентов в работу организации (подробней о разнице этой работы-в-малом “на одного” и работы-в-большом “в организации” как один из важных факторов разделения вайб-работы и работы “по-взрослому” с помощью AI-агентов написано всё в том же вчерашнем моём посте). А ещё у вас может быть не “один человек-стахановец”, а бригада – и вам надо будет разобраться, как выстроить работу этой бригаде. В статье про Codex они там начинали с бригады из трёх инженеров, а текущее состояние – бригада из семерых инженеров. Конечно, это инженеры-менеджеры, которые понимают не только в том, как выполнить собственно инженерную часть работы и поделить её грамотно, но и как договорить на эту тему всех вокруг себя – типовая задача менеджера-организатора.
Новая характеристика – время внимания инженера-менеджера на единицу полезности (например, минуты руления на один принятый инкремент, или доля времени одну правку постановки задачи). У OpenAI в статье про harness engineering – “scarce resource: human time and attention”, bottleneck – human QA capacity.
Сильный интеллект и мышление из первых принципов
Умение мыслить “из первых принципов”, быть готовым к постоянной перекройке буквально всего, к дрейфу реальности. Руление идёт в ходе бега по тонкому льду: вы пересобираете модели мира на лету, и делаете ставки на промежуточные версии, которые могут вывести вас в новые пространства решений – stepping stones (подробности того, как это происходит, я давал на семинаре “Развитие для развитых”). Чтобы жонглировать быстро меняющимися моделями мира, надо иметь высокий интеллект. Именно интеллект позволяет ускоренно разбираться с новым и неожиданным, именно этим человек отличается от кошечки, а AI-агент соревнуется в этом с человеком. Надо владеть весьма особыми дисциплинами вроде системного мышления, методологии, эволюционной эпистемологии, семантики и всякого такого, что позволяет о совсем новом знать уже хоть что-то общее, но “из коробки”. Вот если вы хорошо знакомы с системным менеджментом, вы приходите на какое-то предприятие и уже что-то знаете о нём: оно же как-то управляется! Если знакомы с системной инженерией – вы на этом предприятии уже что-то знаете про то, как там устроена разработка. Это знание, конечно, надо будет конкретизировать для каждого отдельного предприятия и даже для каждого конкретного момента времени и части предприятия, но у вас хотя бы есть, что конкретизировать. Если контекст – не предприятие, а софт, то там всё то же самое: надо разбираться в “инженерном процессе как таковом”. А поскольку сам инженерный процесс тоже меняется, то это “общее знание” отползает до первых принципов, но не сдаётся.
Вы слышали про эти “первые принципы”? Это самые общие приёмы мышления, которые вы используете, чтобы создать что-то совсем новое, когда у вас нет предметной области. Скажем, новая физика – квантовая или теория относительности, когда все примеры вокруг вас ньютоновской физики. Или новое ракетостроение, новое автомобилестроение, когда все примеры вокруг вас – старые, и надо переизобретать всё почти с самого нуля. Вот это и есть “мышление из первых принципов”, самых общих принципов мышления, когда никаких ограничений ещё нет. Чаще всего про первые принципы говорят в применении к физике, математике, computer science, и там уже есть специфика этих предметных областей.
Есть и нулевые принципы, ещё более общие – самые базовые принципы мышления, когда ещё непонятно, мышление у вас будет про математику, физику, computer science или что-то ещё. Пример нулевого принципа: “строить теории по жёстким правилам (аксиомы, постулаты, законы, строгий вывод, доказательства, допустимость)”. “Думать структурно (операции, связи, ограничения) и через симметрии (что можно преобразовать, не меняя сути), инварианты (что сохраняется в преобразованиях) вместо «просто объектов, на что взгляд упал». «Почтитожесамность» (эквивалентность) объектов по подходящим отношениям” – вот ещё один. “Многомасштабные описания (интегрировать мелкое, усреднить, взять предел, выйти на универсальность для всех масштабов)” – за этим нулевым принципом спрятано системное мышление с его рекурсивностью на каждом системном уровне. Дальше вопрос о том, основываете ли вы ваше мышление на этих принципах, или просто “читали где-то, это банально, всегда так делаю”. Скажем, когда формулировали инвариант последний раз? Когда выходили на универсальность по всем масштабам? если это реально “мышление”, то вы должны это делать по многу раз в день, если не выключаете голову! И это только тройка этих принципов, но их ведь больше!
А ещё нужно разбираться с семантикой и управлять точностью языка, ибо гипотезы можно ставить вполне метафорическим языком, но потом надо уметь говорить на строгом языке, допускающем проверки и ведущем к инженерной воспроизводимости, а не художественной красочности. Агентам нужна не красочность, а точность.
Все эти “инженерные процессы” и “коллективная работа” – это вторые принципы, “прикладные знания”. Но они формулируются (особенно, когда они совсем ещё новые и свежие) как раз на языке первых принципов, опираются на эти первые принципы. И ровно поэтому в момент появления новых инженерных процессов, новых методов коллективной работы они так плохо понимаются. Ибо мышление на основе первых принципов надо осваивать, свой интеллект надо усиливать, его надо бесконечно развивать, хотя вы (кто ж сомневается!) уже вполне развитый.
И дальше вспоминается мой пост “Никто не хочет учиться играть на XYZ” (Никто не хочет учиться играть на XYZ.: ailev — ЖЖ, январь 2015 года). Там начинается так: “Сегодня я некоторое время размышлял про одну и ту же проблему усиления человеческого интеллекта, обсуждаемую самыми разными людьми в самых разных формулировках. Суть проблемы в том, что усиливать человеческий интеллект оказывается невыгодно и это развлечение для немногих эээ… пассионариев интеллекта, человеческий интеллект выгодно разгружать и это даёт массовость, что понимается как “успех”. Наиболее часто обсуждается это в программистских кругах – ибо в случае софта это наиболее очевидно”. Один из тезисов этого поста – не надо “усиливать человеческий интеллект, делать людей умнее, ибо это никто не купит. Купят исключение человеческого интеллекта из производственного процесса”.
Обобщать и заземлять (мета-модели, вторые и третьи принципы)
В школе и вузе всех учат обобщать, “находить закономерности”. Не менее важно и обратное умение, о котором говорят мало: заземлять закономерности более общего характера на конкретные ситуации. Скажем, вы умеете считать – но когда вас спрашивают, сколько будет два яблока и три яблока, ответ оказывается неведом: общий принцип счёта работает со “счётными объектами”, а вас спрашивают про фрукты, которые едят. Отождествить абстрактный “счётный объект” и “конкретный фрукт” – это только кажется, что легко. Вот вы знаете из руководства по системному мышлению, что в вашем проекте должна быть целевая система (system-of-interest). В руководстве по системной инженерии тоже говорится про целевую систему. А теперь вы смотрите на множество предметов окружающего мира и пытаетесь сказать, что у вас целевая система. А вы, например, работаете в телеком-компании, где “доступ в интернет”, или в игровой компании, где “игровой сеанс”, или в юридической фирме, где “банкротство” – что делать тут с целевой системой, она ж должна быть материальна? Это не “умозрительные примеры”, это как раз примеры из моего февральского 2026 разбора по первому шагу системного мышления (подробности см. в Разбор по первому шагу системного мышления, февраль 2026: ailev — ЖЖ).
А не сделаешь первого шага системного мышления (подвесишь вопрос “что там у вас за целевая система в проекте” на “когда-нибудь, потом, не сейчас, это трудно”), то сразу будет непонятно, к какой именно системе применять весь материал руководств по системному мышлению, системному моделированию, системной инженерии, все эти огромные знания оказываются неприменимыми в жизни. AI-агенты тоже тупят в этой части, если ими не “порулить” в правильном направлении их неестественно интеллектуальной мысли. Не заземлишь понятие “целевой системы” – не сможешь быть умным, не сможешь применять лучшие методы мышления, известные человечеству, никакой “системности” дальше у тебя не будет. А свалить определение целевой системы на AI-агента тоже не получится, ибо агенту надо объяснить, над каким проектом он работает и что именно ему в этом проекте надо оптимизировать. Объяснить не на общем уровне “мы тут делаем систему”, а конкретно – “мы должны ускорить предоставление доступа” или что-то типа того.
Занятие каким-то делом требует владения как мета-мета-моделью (наши руководства, или FPF с его первыми принципами), чтобы догадаться, что именно нужно искать на уровень ниже, в мета-модели — и надо хорошо разбираться с предметной областью, ибо в текущей мета-модели нужного может не быть, а нужное может быть в соседней мета-модели (другой предмет), более новой мета-модели (что-то очень современное, до вас ещё не докатилось), вообще в мета-модели не учтено и вам надо расширить мета-модель (это ровно то, что называют “мышлением из первых принципов”, когда вы можете шевелить мета-модель, а то и полностью заменять одну мета-модель другой, которая решает проблемы текущей мета-модели). То, что надо кроме знания мета-мета-модели знать ещё и мета-модель (как уровня учебника, так и уровня стандарта предприятия, хоть писаного, хоть неписанного), и что нужна адаптация всего этого мета-знания к конкретной проектной ситуации, НАПИСАНО КРУПНЫМИ БУКВАМИ ВО ВСЕХ РУКОВОДСТВАХ. Вайбкодирование и вайбмоделирование обманчивы в том, что можно избежать всего этого погружения в мета-мета-моделирование, мета-моделирование и выискивание фактов и проблем в контексте проекта. Просто попросить одной строчкой покодировать и помоделировать LLM — и на выходе получить приличный код, приличную модель в предметной области, в которой не соображаешь. Нет, не получится, увы.
Если инженер-менеджер, например, хорошо владеющий мета-мета-моделью, но плохо применяющий другие знания руководств (об уровнях мета-моделирования, о необходимости адаптации по контексту) пойдёт вайбмоделировать в авиацию, то может получиться конфуз с его моделями — самолёт по этим моделям летать не будет, хотя софт у него может навайбкодиться просто огонь. К софту претензий не будет: он будет компилироваться, с хорошей модульностью, но он не факт, что будет решать проблемы. В софте вайб-модельер и профи-программист вовремя заметит проблемы, но в авиационной модели (это та часть, которая в софте обсуждается как product management и отчасти DDD) может несоответствия не заметить.
AI-агент поступает так же, как человек-новичок (знания у которого часто есть, но он не догадывается их задействовать): если на входе есть контекст и выходные тесты, то умная LLM его учитывает, даже сложный контекст. Если на входе контекста нет и выходных тестов нет, то умная LLM его предполагает “наиболее вероятные”, а если у вас не прямо вот “наиболее вероятная” ситуация, а чуть-чуть отличающаяся — всё, модель и жизнь разошлись, а вы этого не заметите, ибо не научены обращать внимание на эти объекты. Я всё время сейчас пишу про это: проблематизация интересна тем, что новичок в предметной области проблемы не видит, а профи — видит там, где у новичка “всё в порядке”. Если у разных проектных ролей интересы разные, то не факт, что LLM сейчас будет это учитывать в контексте, а в тесты это не попадёт: некому будет вносить это в тесты. Скажем, по Голдратту прибыль можно поделить между клиентом, дав ему меньшую цену, сотрудниками, дав им зарплату побольше, и инвесторами, заплатив дивиденд побольше – и всё это даже будет выгодно, ибо на более дешёвую цену придёт больше клиентов, на большую зарплату можно иметь сотрудников получше, а дивиденд – это святое, это же ровно то, зачем вообще затевалось предприятие, без ожидания дивиденда его бы не было! Ну, и какие LLM вот это всё начнут учитывать, если их не ткнуть носом явно в необходимость учёта? Пока же – кто первым встал, того и тапки. Кто первым дал промпт, в ту сторону прибыль и поделят. Системные промпты, а затем “системный промпт уровня предприятия”? Жизнь покажет, как с этим справляться.
Поэтому некоторое время назад обсуждалась разница между профессиональным кодированием с помощью AI-агентов на работе и вайб-кодированием в pet-projects дома. И то же самое — с моделированием. Тимур Батыршин в чате поддержки рабочего развития писал (Telegram: View @systemsthinking_course) “Вот моделирование я надеюсь у резидентов не вайбовое, а по методам из руководств — без нормального моделирования получится грустно” и далее уточнял: “В моей личной терминологии (не претендую на истинность или общепринятость) есть “моделирование при помощи LLM”, когда FPF-нормативным или классическим SDLC-подобным способом строим граф трансдукций большей или меньшей формальности и строгости, и гоняем по нему промты и их рабочие продукты. А есть вайбкодинг, когда мы пишем промт, нам агент выдает какой-то слоп, и мы сразу такие “вроде работает, срочно в продакшн!” невзирая на последствия. (я так тоже делаю для каких-то одноразовых вещей, которые мне не важно как работают и быстрее проверить результаты глазами насколько верно — типа конвертации логов LLM из JSON в маркдаун)”.
Вайб-кодирование с изучением AI-агентом огромной базы кода тут даёт какой-то ответ на вопрос. Но не даёт ответа на вопрос про то, что это кодирование меняет к лучшему в окружающем мире, ибо вот этот контекст оказывается недоступен. Если вы рулите AI-агентами, то вам придётся “разрулить” и вот этот выход в окружение, организовать вашим агентам глаза и уши, дать руки и ноги – а пока не организовали, вам надо уметь быть самому этими глазами-ушами, руками-ногами и послами в рабочие команды “от имени и по поручению моей команды AI-агентов”. Но на что вы будете смотреть и что вы будете говорить вашему AI-агенту и вашим коллегам? На каком уровне абстракции, как будете убеждаться, что вас поняли правильно? У вас большой опыт говорить так, чтобы вас понимал и AI-агент, и сотрудники? Или есть какие-то проблемы с тем, что вас понимают так, как вы ожидаете? Точность языка существенно связана с осознанным использованием принципов и моделей самого разного уровня абстракции. А ещё с системным мышлением, ибо “система в глазах смотрящего” (инженеры знают про viewpoint и view, а также интересы разных проектных ролей, которые заставляют один и тот же объект описывать для исполнителей разных ролей очень по-разному). Точности языка тоже надо учиться, и точное говорение на одном из уровней абстракции абсолютно не означает, что вы сможете говорить на другом уровне. Скажем, вы разобрались с первыми принципами, а теперь вам надо прорулить роботом, который организует какой-то концерт. Ну, что там надо писать в райдере, и вообще, что такое райдер? Писать не вам, но вы будете долго удивляться, откуда такое внимание к какому-то райдеру. Если вы программист, то чем райдер отличается от SLI/SLO/SLA, сходу скажете? Знание принципов освобождает от знания фактов, но не освобождает от знания предметной области и изучения конкретных ситуаций в этой предметной области.
Разбираться в ограничениях, отделяя возможное от невозможного
У нас в МИМ в руководствах по рабочему развитию вводятся уровни общности/приложимости говорения о мире как классические онтологические уровни (мета-мета-модель, метаУ-модель, метаС-модель, это во всех руководствах, но ещё много разъяснений на эту тему было в семинаре по мантрам/памяткам/промптам/канвам). Я склоняюсь к мнению, что вот эти нулевые-первые принципы примерно соответствуют мета-мета-модели, вторые – метаУ-модели, третьи – метаС-модели. “Вертикаль нулевых-первых-вторых-третьих принципов” – это я жёстко огрубляю/сжимаю, там ведь lattice этих принципов (множественное наследование), а не стек, и уровней отнюдь не четыре – но я просто свожу это к традиционному стеку онтологических уровней, в руководствах у нас обычно говорится о L0-L4. Нет, это тянет не legacy руководств, это legacy культуры онтологического мышления. Прыжком от неё отойти вряд ли получится.
В классических языках мета-моделирования (чаще всего по онтологической традиции базирующихся на логике) ограниченную их выразительность часто снимают языком ограничений (pun intended). Откуда этот pun? Если брать какое-то пространство всех ситуаций, то значительные области этого пространства соответствуют невозможным ситуациям. Так, изо всех функций только некоторое число функций являются вычислимыми. Изо всех методов только некоторые оказываются работающими. Есть 100500 (на самом деле – много больше) способов что-то сделать неправильно на один правильный способ. И хорошо бы как-то выгородить заборчиками ту область, где описываются потенциально пригодные для вас ситуации. Ограничения – они именно про это. “Делить на ноль нельзя” – ограничение, забор, “не влезай – убьёт!”. Тут важна форма заповеди: “не убий”, “не укради”. Ограничения, запреты, заборы. Когда я был молодым я страшно возмущался: что это там в заповедях не говорится, что надо, только говорится, чего нельзя? Сказали бы сразу какой-нибудь KPI – все бы и выполняли. Я был молодым программистом, ничего не знал о законе Гудхарта и хотел скаляра, чтобы к нему оптимизироваться (ошибка!), я не понимал ответа “вот этого что в заповедях – нельзя, а остальное всё можно”, приставал с вопросом – “что именно можно!?”, а сейчас у меня метанойя, я только помню, что мне с этой “заповедной формой” представления знания было некомфортно довольно долго. Но оказалось, что это общемыслительный приём, и так работают физики, математики, computer scientists и теперь так работают даже AI-агенты (лучшие из них, и если им дать достаточно компьюта, а не самые лучшие и самые дешёвые работают так, как я в молодости – и это тоже надо уметь различать!).
Вот нулевые-первые-вторые-третьи принципы (или мета-мета-модели, метаУ-модели, метаС-модели) и играют роль высказываний-ограничений. Из бесконечно большого набора возможных объектов они выбирают важные и дают их отношения, вырезают из бесконечного мира фантазий какой-то потенциально полезный кусок.
Мне кажется, говорение о мета-моделировании (где моделирование оказывается не просто указанием одинаково понимаемых всеми важных для каких-то ролевых viewpoints объектов, но и указанием ограничений в отношениях этих объектов) более жизненно и инженерно, чем говорение об “уровнях онтологии как таксономии” (или даже не таксономии-иерархии, а lattice со множественным наследованием), ибо в жизни редко говорят о занятиях “онтологической инженерией” (кроме ситуаций моделирования данных для целей интеграции данных), тем более что это просто “нарезка мира на типы объектов, впрок”, академическая постановка вопроса “что есть в мире”. Моделирование тут явно выигрывает у чистой онтологической инженерии, ибо онтология там только маленькая часть: онтология + принципы + ограничения + спецификации обмена моделями и результатами моделирования. В онтологии (даже навороченном knowledge graph) это просто “вот так”, а в моделях ещё и правила проверки соответствия предсказаний модели и жизни. Модель прикладная, то есть для проектной ситуации, модель конкретизируется, калибруется, используется и отвечает не только на вопрос “что есть в мире”, но и разные другие вопросы (как оно себя ведёт, чего можно от него ожидать – работа с ограничениями как раз ход на ответы на дополнительные вопросы). Инженеры продуктивно работают с моделями, а с онтологиями – ну, классификационные схемы бывают разные, с ними мало что можно сделать (разве что хранить что-то “в супер-пупер рубрикаторе на стероидах”, но можно и без рубрикатора хранить, роза ведь пахнет розой, хоть розой назови её и положи в таксон роз, хоть нет).
И вот если вы пытаетесь использовать AI-агента, не разбираясь в предметной области, а также ситуации на предприятии, то вы будете не понимать, какие ограничения этому агенту ставить и как обсуждать те ограничения, которые агент выдвигает сам. Парламент за пять минут принял решение выделить $5 млрд. на строительство правительственного датацентра (потому как никто из депутатов в этом не разбирается) и три часа потратил на дебаты и затем отложил решение о том, в какой цвет покрасить забор вокруг здания парламента (ровно потому, что все депутаты в этом разбираются). Вот ваши агенты работают – на что вы будете тратить время для этого steering?
Знание развивается прежде всего в терминах ограничений. Скажем, constructor theory как раз про “науку льзя и нельзя”, про ограничения. И Theory of Constraints тоже про ограничения (Элияху Голдратт вполне физик по образованию). В какой-то мере FPF как first principles framework – тоже про ограничения: убирает фантазии, отсекает иллюзии, самоуверенность и фальсифицированные уже теории. Вот это “отсечение ненужного” вполне можно рассматривать и как “сдвиг к нужному”. Да, знание теории освобождает от знания фактов (бесконечного списка “вот тут почему-то не работает” и короткого списка “вот тут работает”). Можно тем самым существенно компактифицировать знание. Но в целом надо уметь работать не только с классической теорией (чистые функции, “программа и доказательства эквивалентны” по Curry-Howard), но и с механизмами с эффектами (ввод-вывод у программ, и там сразу другая математика). И неизбежно специализироваться. Даже нейросети специализируются, это тот же inductive bias в их мышлении (“What LLMs Think When You Don’t Tell Them What to Think About?”, [2602.01689] What LLMs Think When You Don't Tell Them What to Think About?), если их мышление оставить дрейфовать, то разные нейросети дрейфуют в разные предметные области, для которых можно ожидать их специализацию: GPT-OSS favors programming and math, Llama leans literary, DeepSeek often produces religious content, and Qwen tends toward multiple-choice questions. Полезно ли это знание для того, чтобы вы выбрали одну из этих сеток? Если вы отвечаете “да”, то у вас в лбу тоже есть нейросетка, и вас могут выбирать по этому же принципу. В какую предметную область дрейфуют ваши мысли, если вам задать невинный вопрос, не подразумевающий какой-то предметности? Как бороться с таким дрейфом? Если речь о специализации, то никак! Это даже полезно. Если хочется “предметной нейтральности”, то это может оказаться “дрейф в сторону эпистемологии, онтологии, методологии” (специализации на разбирательстве с предметными областями). Если дрейф явно вреден, то вставляем контуры обратной связи в обучение – инструктаж, системный промпт, RLHF (обучение с подкреплением по предпочтениям людей-наставников).
Срок годности этого поста (небольшой) и что я буду делать со всем этим знанием
Если вы знакомы с материалом семинара по “Развитию для развитых”, то там довольно чёткое указание на все результаты работы ставить срок годности, чтобы вовремя пересматривать. Мне надо ставить срок годности и на мои посты, если следовать этому инженерному процессу. Я не думаю, что этот пост будет актуален долго: всё-таки мы находимся вблизи сингулярности, и хоть Sam Altman пишет, что неизвестно с какой стороны (https://x.com/sama/status/1875603249472139576), я думаю, что во многом уже по ту сторону. Это означает, что AI-агенты быстро-быстро будут получать и доступ к реальному миру (ибо “не дашь доступ, не вложишься, не рискнёшь – конкуренты прокрутят цикл Бойда быстрее тебя ровно за счёт того, что у них будут AI-агенты с таким доступом”), а ещё они быстро-быстро будут осваивать вот этот новый инженерный процесс. И быстро-быстро будут его улучшать, на базе тех же первых принципов.
Так что я продолжу свои текущие проекты, которые десяток лет назад были направлены на смычку инженеров и менеджеров (эх, ностальгия! но теперь я просто говорю инженер-менеджер, смычка состоялась), а теперь на смычку инженеров-менеджеров живых и не очень живых (причём первые умнеют очень медленно, а вторые – крайне быстро).
Сейчас содержание руководств МИМ по рабочему развитию (мета-мета-модели) и FPF (первые принципы) совместимы на 80%, при этом отнюдь не всегда FPF лучше и подробней, а руководства отнюдь не всегда точнее онтологически. Моя стратегия сейчас – сначала докрутить FPF так, чтобы в нём было понятие архитектуры, затем разобраться с принципы-ориентированной-архитектурой (и тем самым модульностью и evolvability) самого FPF, стыком FPF с SPF и даже TPF, и вот тогда уже поработать с доводкой руководств и FPF. Так что я потихоньку описываю МИМ (ибо если не я, то никто), но голова думает про вот эту связку FPF-SPF-TPF. Ибо всё, что я пишу тут про вайб-работу надо как-то сообщить AI-агенту. FPF как раз этим и занимается. Люди вряд ли будут читать FPF (хотя такие отчаянные есть, я точно знаю, они мне пишут про своё чтение время от времени). Инженеры-менеджеры в массе своей будут читать руководства и мои посты и пробовать им следовать. А вот AI-агенты будут читать спецификацию FPF. Одно и то же знание, но другая форма представления, оптимизированная для неестественного интеллекта.
