AI-native first-principles-driven development
Чем я занимаюсь, если говорить “на попсовом”? AI-native first-principles-driven development (а с FPF это будет FPF-driven), и у этого высказывания есть некоторая история. Впервые FPF-driven сказал Telegram: Contact @exocortexssm Dmitry Nick, затем на четвёртом семинаре была реплика A G – Telegram (всех по ссылке не пустят, но больше ста человек участников – пустят), в ответ я пишу Telegram “AI-native FPF-driven development”. Хорошо звучит, попсово! Пятый семинар, уже Айрат Бурганов Telegram “я понимаю DPF и LPF как специфические форматы представления знаний для AI-native FPF-driven разработки каких-то продуктов. Если это не AI-native и не FPF-driven разработка, то, кажется, это overkill. Под разработкой, понятно, речь не только и не столько про софт. … Но, с другой стороны, если это не AI-native и не FPF-driven, то не очень понятно, как использовать всё это. Ибо без AI-агентов читать всё это сложновато, а без FPF это останется просто артефактом без развития”. Да, как-то так, я с Айратом согласен.
Столько всего происходит, что просто не успеваю даже записывать: когда у тебя работает десяток агентов в параллель по разным тесно связанным темам и идёт архитектурная работа, то пишешь много – но в чаты этим агентам. Я тут пишу время от времени про планы, так вот они исполняются потихоньку. Ну, или не потихоньку: недельный кредит Pro-аккаунта (который x20 к Plus) на 6 Astra Max улетает примерно за полсуток, держусь только на том, что OpenAI выдала на этой неделе по парочке banked-кредитов на аккаунт, так что до конца недели дотяну, а там посмотрим.
Общее ощущение, что прошёл какую-то tipping point, всё резко ускорилось: у агентов есть связное представление о мире, и они быстро понимают, как его наращивать без потери связности. А при генерации каких-то идей (паттернов! и языков паттернов! формат идей тоже предопределён, не надо тратить силы на выбор формы, надо только содержанием идей заниматься) можно полагаться на огромное число формальных проверок: отсекать ошибки теми самыми “первыми принципами”. Это работает!
Мои заметки по планов громадью (и кое-что заготовленное раньше) превратились в план на 100К знаков, в этом плане 13 продуктных линий и множество запланированных кампаний в этих линиях. Продолжаю думать, как это планов громадьё лучше выполнять. И кое-что даже сразу выполняю. Даже в GTD была такая рекомендация: когда разгребаете свой inbox, не откладывайте дела, которые идут меньше двух минут, не делайте по таким делам записи, просто делайте их немедленно! Вот и делаю, хотя эти дела оказываются иногда не две минуты, а два дня. В книжке Варшавского “Оркестр играет без дирижёра” такое описывалось как “очередь со встраиванием”: общая проходимость очереди выше, если короткие дела не ждут ограничения, а проходят вне очереди.
FPF должен удешевить выращивание следующей AI-организации
Как выглядит эта разработка? Роман Левентов указал на статью Fences, not Sandboxes — Steve Yegge – и там более-менее интересное описание, как оно. Всё ровно так: просыпаешься утром, три агента “ай, молдца”, а один “о, чёрт!” – но мечты и впрямь сбываются. То, что среда разработки (у меня это LPF) занимает кучу времени, – чистая правда. Вроде бы всё с этой “оркестрацией поверх harness от производителя” банально. Понятно, так и должно быть, – но не часто так делают, ибо “токенов не хватает”: быстро замечаешь, что “или продукт, или завод по производству продукта”.
Элон Маск говорил, что выпустить прототип автомобиля или даже ракеты – дело нехитрое, куча стартапов так делает. А вот сделать завод, который серийно выпускает такие автомобили или ракеты, – вот это сложно. Но если построил завод, то ты эти автомобили или ракеты дальше выпускаешь на потоке. Так что и автор статьи, и я занимаемся оркестрацией агентов чуть ли не больше, чем самой работой – это правильно. “30% времени вы занимаетесь инструментами для выпуска вашего продукта, 30% времени выпускаете продукт и 30% времени используете продукт. 1% времени остаётся, чтобы сходить в туалет” – это обсуждалось программистами ещё в 80-е прошлого века, я это застал. Скажем, “писать компилятор, на нём делать программу, потом считать данные экспериментов этой программой” – как раз такая схема. Вот это занятие оркестрацией и harness прямо сейчас, DevOps или platform engineering чуть раньше – это как раз тоже оно. Разница только в том, что в малых проектах делаешь это сам для себя, а в фирме с учётом разделения труда будет делать какой-то DevOps или platform engineer. Про “пятиклассника” и “шестиклассника” – да, именно такое ощущение. Следующая модель будет “семиклассник по жизни”, но ещё более гениальный в прикладных проблемах.
Но у меня есть и замечания к статье:
- в статье объявляются важными “средневековые конституции”. Конечно, я тоже пишу эти “конституции”, но вытравливаю “юридичность” и “бизнесовость” из текстов FPF и DPF. Там не деонтика и феодализм, а рациональная допустимость: грубо говоря, не “по законам физики”, а “допустимо современными представлениями о физике”. Но рациональная допустимость не заменяет полномочия. Хорошо обоснованный выпуск новой версии может оставаться неразрешённым выпуском – в статье как раз есть такой случай. Поэтому LPF всё равно должен различать содержательную обоснованность, разрешение на действие и фактическое действие;
- harness (упряжь, инструментарий вокруг LLM в таких средах, как Codex App, Cursor и т. д.) уже более-менее отлажен производителем, хотя OpenAI утверждает, что через два-три месяца текущий Codex будет казаться примитивным. Но вот оркестрирующая добавочка LPF – она большая. При объёме FPF 13M и 105K lines в нём (при этом мои lines много длиннее, чем строки кода программ, думаю, сопоставимо с масштабами кода игры автора статьи) моя парочка LPF в части только текстов, без кода хелперов и тестов, занимает: общий процессный LPF – 483K знаков, Learning Product LPF – 351K знаков. Это очень немало! Но там только то, чего нет в FPF, – а ведь материал FPF очень сильно задействован. И ещё готовятся DPF, там тоже много текста. Объёмы вполне велики. И это всё строится не с нуля, конечно, и не по образцам средневековых игр. И не за такие дикие деньги. Хотя три подписки – это $600 в месяц, производитель игр вполне может потратить x10, у него это окупится;
- автор пишет, что такая AI-организация растёт как плющ и её нельзя пересадить: каждую надо выращивать на месте. Вот тут у FPF может быть главное проверяемое притязание. Местные правила, инструменты и факты действительно придётся выращивать в местном LPF, но известные методы инженерии и организации работы незачем каждый раз заново открывать на ошибках проекта. Вторую AI-организацию должно быть дешевле вырастить благодаря FPF, DPF и опыту выращивания первой. Проверять надо не перенос файлов, а снижение расхода человеческого внимания и числа циклов исправлений до способности решать тот же класс задач в новых условиях;
- то, что автор пишет как “я живу там, где вы все будете жить через год”, – хороший пункт. Я надеюсь, что смогу это и через год сказать, хотя у меня всё другое будет в этот момент. Очень хочется всегда жить там, где вы все будете жить через год!
Экспертные системы вернулись, но экономика стала другой
Процитированный момент статьи про “всё письменно, если могут” – да-да, это известно как knowledge acquisition времён экспертных систем, где из subject matter expert вынимали всё, что можно и нельзя, и пытались засунуть в экспертные системы, представлявшие собой ровно вот эти наборы правил, чаще всего “продукций” на каком-нибудь логическом языке. Можно долго рассказывать, почему FPF по своим принципам и похож, и не похож на такие системы (движок не логический, а нейросетевой, и язык представления знаний акаузальный/декларативный – но вроде языка представления фреймов, начинается там всё с Problem Frame). Более того, это “письменно” ещё и означает “мышление письмом” – ещё и диалог с собой. Конечно, появляются и новые ходы (я много раз об этом писал, обмен векторами в latent space, все эти DroidSpeak, последняя нашумевшая инициатива – https://mostik.ai/, по-русски в Telegram: Contact @data_secrets, очередное “первое место на ARC-AGI”).
Провал в интеграции знаний самых разных предметных областей ввиду несовместимости логических теорий/алгебр, выведенных из разных посылок, провал в логическом выводе – это даже не главный провал. Микротеории Cyc придуманы были на самом закате эпохи экспертных систем: работа Guha по контекстам была в 1991 году (Guha, R. V.: Contexts: A Formalization and Some Applications, Stanford PhD Thesis, 1991). Естественный язык у современных LLM сам по себе тоже не устраняет несовместимость онтологий: иногда он просто лучше её прячет. Всё равно нужны явные проблемные контексты, восстановление понятий и отношений, источники и правила перехода между представлениями – с какой-то оценкой неопределённости отождествлений при переходе (кстати, в FPF переход между смысловыми контекстами – тоже Bridge, от этих “мостиков” никуда не денешься).
Но это только одна из проблем экспертных систем: логика первого порядка как язык представления знаний явно недостаточна. Поздний CYC решал её через множество “ускорителей” и самых разных представлений, и “general resolution theorem prover” (чистый логический движок) был в конечном итоге выкинут: другие 1100 “ускорителей” (иных движков, менее общих) давали хоть что-то, а этот – всегда вылетал по таймауту ([2308.04445] Getting from Generative AI to Trustworthy AI: What LLMs might learn from Cyc), банально не справлялся с объёмом вычислений за приемлемое время.
Вторая проблема – это классика от MYCIN, которая назначала антибиотики лучше любого врача, целых два месяца. Отладка после добавления знаний по новым антибиотикам и результатам экспериментов была дико дорогой, даже с учётом акаузальности логических языков. Через полгода знания отстали от жизни, через пару лет – MYCIN была анахронизмом с медицинской точки зрения, не знала новых антибиотиков! Пополнение было дорогим, столь же дорогим, как и разработка. И тогда, в 70-х прошлого века, было жёстко: знания кодировались в строгом логическом формате, а современных методов agile-разработки с непрерывным обновлением не было, обновления выпускать быстро, доводя их до пользователей, не получалось, да ещё и пользовательский интерфейс был такой, что не подразумевал какую-то быструю работу (Mycin - Wikipedia).
Переход к AI-native разработке эти проблемы не закрывает: ночная работа огромного числа агентов ещё не означает, что переработанное ими за ночь знание (в форме “конституции” из упомянутой статьи или в форме паттернов в случае FPF) стало актуальным. Агенты должны заметить изменение источников и практики (а это всегда “в жизни” – вовне, нужно обратить внимание, найти, где и что смотреть для этого), понять, что именно затронуто, исправить зависимые от этих новинок фрагменты имеющегося знания и потом ещё и отладиться: проверить их на реальной работе, исправить ошибки.
Но AI-native может резко уронить цены на решение всех этих вопросов. Вот ровно как современные нейросети стали экономически выгодными и вообще доступными при задействовании аппаратуры GPU (знаменитый AlexNet moment), так современные AI-агенты на их аппаратуре в дата-центрах могут сделать экономически выгодными и вообще доступными экспертные системы: работу с хорошо отжатым экспертным знанием.
AI и естественный язык могут резко снизить стоимость knowledge acquisition (ровно как и предлагал Lenat для CYC: начиная с какого-то момента AI-агент сможет читать, чтобы пополнять базу хорошо отжатых знаний), согласования и непрерывного обновления знания. То, что раньше после окончания финансирования за пару месяцев превращалось в музей (таких завядших в силу непоспевания за жизнью проектов, как MYCIN, была тьма), теперь можно поддерживать как живой FPF+DPF (и, конечно, ещё и LPF – но это у каждого своё).
Ещё интересный момент про конституции и agile-разработку по строгим регламентам, где “разрешено всё, что не запрещено” (“прецедентное право”), но вот чего надо при этом добиваться – это интересный вопрос. Функция цели тут требует особого внимания. Я думаю, что весь просвещённый мир (а AI-агенты как раз тут – просвещённый мир, если уж они попали к кому-то в производство) таким занимается: пишут свои “конституции” и пытаются работать поэффективней, при этом каждый по-своему понимает, что такое “поэффективней”. По мне, так надо сразу помнить про закон Amdahl, а также начинать с опыта обычного человеческого менеджмента. Смешно видеть, как программисты заново и заново открывают его закономерности, а сейчас ещё и дают открывать эти закономерности AI-агентам – задорого добывая опыт сотен лет экспериментов людей над тем, как получше организоваться.
Новости экосистемы FPF
Поменялось Readme в GitHub (GitHub - ailev/FPF: FPF Core, Engineering DPF Suite, and Narrativization DPF: declarative pattern languages for AI-native engineering, shared human–AI reasoning, evidence, and decisions. · GitHub), оно стало короче и более “попсовым”, но главное – отражает публикацию Engineering DPF Suite. В этом Engineering DPF Suite опубликовано уже 7 полных DPF и 2 неполных DPF.
Я сделал предложения по концептуальному синтезу ситуационной инженерии методов и языков паттернов. Так что готовим профиль языков паттернов для уже опубликованного DPF методологии, агенты выбрали поэтическое название PLUS-ME (Pattern-Language Unfolding Situational Method Engineering).
Прямо сейчас обсуждается (уже с GPT-6 Astra) переформатирование DPF, чтобы отражать все эти концептуальные синтезы и прочую архитектурную информацию про DPF в целом, профили (инженерное слово для “специализаций”) DPF, паттерны. Одна из идей тут – DPF – это такой “большой паттерн”, поэтому банально берём разделы по E.8 – и там для понятности ещё и переименовываем Rationale в Architectural Rationale. И структура этих “масштабов применимости” выражается решёткой, где какой-то узкий паттерн может входить в широкий паттерн, а вот публикация их в форме FPF, DPF, LPF – это отдельный вопрос. Дальше надо будет перетряхнуть все DPF, дополнить их объяснениями, что там и как.
Выпущено руководство “Развитие для развитых” по материалам семинара 1 февраля: там получилось 145 страниц текста A4 в .pdf (впрочем, в .docx) и 28 картинок. Это не “нарратив от третьего лица”, это изложение от первого лица, хотя мои байки там больше пересказаны, чем процитированы. И нарратив исчез, просто “справочник с объяснениями, примерами и байками”. Зато содержание приведено к текущим версиям FPF и DPF, а не к версии FPF от 1 февраля 2026, на дату семинара. И там новые красивые картинки. Руководство это я пока отдал участникам семинара. А ещё читать его будут не люди, оно пошло как R11 в общий набор исходного материала для проекта пополнения FPF и DPF по материалам R0-R11.
Ещё один результат – более-менее модульный генератор подобных руководств, Learning Products LPF. Последнее, что я туда вставил, – это сохранение нарративизации, которая может исчезать из-за многочисленных правок содержания (актуализации, правок языка, добавления самой разной другой информации, ибо на входе необязательно транскрипт, слайдомент и FPF+DPF, может быть и много чего ещё). И ещё вставил контроль когнитивной нагрузки.
Поскольку у меня теперь есть шкалы оценки руководств (там штук десять этих шкал плюс ещё шкалы из DPF нарративистики про качество нарратива), то запустил проход оценки R1, R5, R11 – руководств от трёх разных авторов, всего 2,4 млн знаков.
Есть регистр примерно 1000 идей, которые были взяты из R0, R5-R10 и старой версии R11. Запустил вытаскивание в него недублирующихся идей из R1-R3, при этом использованы были новые уточнённые критерии. Проверил: для R5-R11 вытаскивание идей в этот регистр было грубым, поэтому запланировал повторный проход и для них. Там всё очень медленно: сутки работы агента на одно руководство. Зато потом – пополнение DPF.
Самими DPF практически не занимаюсь, там всё пока идёт по плану, но их число уже 16 и там внутри начали появляться профили. Скажем, в DPF по системной инженерии появилась часть по инженерии платформы, а в ней – профиль для платформы в software engineering. Я больше делаю упор на то, чтобы работала машинка по производству и обновлению этих DPF, отладке их формата, стандартизации, оценке. А потом? Потом можно делать обновления для появляющихся SoTA, можно крутить циклы улучшений – дорабатывать, бесконечно развивать. Так что упор пока на общую архитектуру экосистемы FPF и на платформу по её развитию, а содержание пока берём примерно как в наших руководствах, хотя там много и совсем нового содержания, например, про эти самые решётки методов в методологии или рекомендации по развитию агентов (предложение следующих шагов развития для людей и компаний).
Вообще, языки паттернов мне напоминают фреймовые системы, когда ещё не было засилья knowledge graphs и формальных онтологий – и даже говорили о разнообразии языков представления знаний и разнообразии форм представления знаний. Чего не хватило тогда? Понятно было, как декларативно работать со знаниями в логике первого порядка. Но вот в паттернах навести CGUS – это в FPF, ситуационная инженерия методов тоже туда шла, но не очень дошла (литература будет у меня в DPF методологии). Но главное – это вычислитель: solver в экосистеме FPF как экспертной системе вроде CYC (помним, что это от enCYClopaedia) не логический движок, а AI-агент, обложенный самым разным инструментарием, а хоть и логическим движком, если очень надо.
Развиваем людей, развиваем компании
Ещё разбираюсь с тем, что я собираюсь делать с резидентурами и учебными программами.
Испробовал генератор учебных программ на прототипной версии Рекомендателя, получил программу с подробными комментариями на 340 часов (2x4 месяца по 10 часов в неделю). Вроде всё работает: в программе список паттернов FPF+Engineering DPF Suite в порядке предлагаемого их освоения. Дальше можно включать генератор руководств, на встречах резидентуры добавлять, как обычно, мои байки и активно использовать AI-агентов с этой самой экосистемой FPF. И всё должно полететь. Это чистый эксперимент, поделился с потенциальными B2B-клиентами (часть из них в нашем чате методсовета). Руководств по этой программе я делать не буду: уже после этого вышла модель GPT-6 Astra Pro, и я бы генерировал такую программу с её помощью, а не на GPT-5.6 Sol Max. Но даже не это важно: важно, что экосистема FPF ещё не была нужного качества, интересно будет сгенерировать такую программу по полному множеству всех DPF после начальной публикации, когда утрясётся архитектура.
На методсовете обсудили другой вариант: входом у нас будут отлаженные 4 месяца R1-R4, а вот дальше я в середине октября возьму группу освоивших R1-R4 – и сделаю вторые четыре месяца, развернув их в инженерию: и вот тут уже будет последовательность паттернов, генерация руководств, личные встречи – всё как полагается. Но это не будет R5-R10, ибо они в четыре месяца точно не влезут. Это будет другая программа, чуть более продвинутая по содержанию, но обрезанная доступным к освоению за 4 месяца по 10 часов в неделю на пятидневке (где-то 170 часов, это очень немало!).
И ещё мы начали обсуждать варианты программы B2B для МИМ. Идея в том, чтобы помогать делать офис рабочего развития в компании, для директора по развитию – а офис ставит те же задачи, что и любой офис, начиная со времён TCM (total cost management), TQM (total quality management), офисов проектного управления и прочих “офисов” – помощь сотрудникам фирмы в освоении каких-то методов работы. В данном случае помощь в развитии сотрудников. Но МИМ мог бы не столько сам вести там программы рабочего развития, сколько помогать развернуть подобный офис и сделать работу этой “качалки для мозгов” сотрудников успешной. “Качалка для мозгов” – это образная метафора, можно сразу давать пример https://www.gymlaunch.com/. Правда, этот пример быстро заканчивается, ибо всё остальное там не совпадает. Но общий смысл остаётся: МИМ не даёт своих наставников для ведения резидентур, МИМ помогает какой-то компании развернуть машинку по проведению этих резидентур у себя – предоставляя начальное обучение наставников самой компании, поставляя кастомные руководства, генерацию кастомных программ, курирование свежести экосистемы FPF, общение инженеров-менеджеров и помогая поддерживать культуру развития компании. Так что начали первые разговоры на эту тему, есть какие-то развёрнутые тексты.
