Моё продирание через тернии к звёздам, то есть тому, чтобы третий закон Кларка был применим к FPF (а мне уже знающие люди говорили, что его работа – чистая магия!) продолжается. Весь мир сейчас озабочен harness, и я тоже озабочен, денно и нощно занимаюсь своим harness – просто часто об этом не пишу.
Наверное, надо будет как-нибудь написать (в непубличных чатах и на созвонах я иногда рассказываю, что там и как). Времена нынче такие, что этим harness хвастаются. Личным экзокортексом (обсуждаем вот тут – Telegram: View @exocortexssm и там ссылка на пункт 9 в https://x.com/gregisenberg/status/2059274608759480367) и своим инструментом вайбкодинга (обсуждаем в lytdybr: ailev — ЖЖ и там ссылка на юмореску Telegram: View @lovedeathtransformers). Аккуратно начинают рассуждать про корпоративный экзокортекс: нейросеть из нейросетей (ага, как “интернет – это сеть сетей”) людей и не очень людей, там же корпоративное внимание (чтобы все делали одно дело), корпоративная осознанность (когда всё не в нейросетях, а выложено куда-нибудь во внешнюю память: файлы, записи в базе данных – переход от tacit knowledge к explicit knowledge, ещё и с discoverability, да ещё и “только для своих”, ибо паразитов эволюция пока не отменяла, защищаться надо).
Как к этому относится FPF? Очень просто: SoTA harness для людей, не очень людей, а также организаций я прямо сейчас допаковываю в FPF. В FPF использование других агентов и не слишком умного инструментария в какой-то harness (по-старинке: в каком-то инженерном процессе) обсуждается через bitter-lesson preference (BLP, паттерн C.19.1) – я об этом рассказывал на семинарах по FPF. Смысл BLP в предпочтении масштабируемых автоадаптирующихся под задачу общих методов перед эффективными, но специальными (неадаптирующимися) “при прочих равных”. Конечно, Ralph loop от Ralph Wiggum (с апреля 2026 это в техрадаре стоит на access, Ralph loop | Technology Radar | Thoughtworks) – это как раз “масштабируемый автоадаптирующийся под задачу общий метод”. BLP тут добавляет важное “при прочих равных” и требует оценивать довольно длинную цепочку end-to-end, а не только “сколько стоят сожжённые токены”: цена_принятой_работы = цена_токенов + цена_инструмента (скажем, подписка или покупка) + цена_попыток_адаптации (этот Ralph loop может крутиться довольно долго) + цена_присмотра_людьми + цена_переделок (не всё же получается с первого раза! и это не попытки адаптации, это возвраты) - оцениваемый_риск_убытка (если не получится, и тут минус: если дорого, но предотвратили большой убыток, то это хорошо). И дёргать надо, конечно, за все ручки в этом уравнении, а также для разных задач (“прочих неравных”) тогда будут разные решения: где-то переход на китайские модели похуже для задач попроще, где-то возврат к работе людей, где-то тот самый Ralph loop, где-то “мой шикарный harness, посмотри как он сделал дешёвую локальную модель почти совсем умной”. Улучшение harness за пределы Ralph loop (то есть уход от “проб и ошибок”, уход от просто рандомного tinkering с попытками накопления эволюционного результата) – это с точки зрения BLP самый верный первый ход, поэтому умные люди и начинают этим заниматься, этим хвастаться.
Я, конечно, тоже холю и лелею harness, разве что перестал часто об этом писать. При этом я ещё и пополняю FPF так, что harness у меня получается довольно тонким слоем отсылок к FPF-паттернам. Скажем, “проверь новый паттерн на точность языка” – это не просто промпт с рандомными проверками (тот же Ralph loop), не огромный список конкретных проверок “туманных слов” вроде “качество” или “поддержка” и не уточняющий вопрос. Нет, это звучит в “документах процесса” как “проверь по E.10” (можно даже про точность языка не говорить для краткости, ибо в E.10 много чего написано про то, что проверять, как проверять, как использовать результаты проверки, и там ещё много других паттернов участвует).
Прямо сейчас я вставляю в FPF идею “цикла улучшений” для произвольных шкал (паттерн E.22 для review с eval и предложением недоминируемых улучшений для многокритериальной оптимизации в этом цикле уже написан, хотя я ещё не публиковал его в GitHub, но уже использую для оценки самих паттернов (по 18 шкалам в паттерне E.21) и DRR (по 13 шкалам в паттерне E.9.DA)).
Дальше возвращаемся к посту https://x.com/gregisenberg/status/2059274608759480367, в котором есть занятное обсуждение популярности роли forward-deployed engineer, “инженера последней мили”. Классическая формулировка Palantir очень точная: обычный product/software engineer строит одну capability для многих клиентов, а forward-deployed engineer включает много capabilities для одного клиента (https://blog.palantir.com/a-day-in-the-life-of-a-palantir-forward-deployed-software-engineer-45ef2de257b1).
То, чем я занимаюсь с этим harness по выпуску DRR и паттернов – это существенная часть по подготовке к выпуску SPF (предметно-специфических паттернов, second principles frameworks) и TPF под управлением FPF. Я уже делал прикидки на эту тему, результаты экспериментов публиковал 11 мая в lytdybr: ailev — ЖЖ. Но это всё было “вручную”, практически без harness.
Но прямо сейчас мои агенты (Executor и Reviewer) закончили крутить цикл улучшений для DRR по первой кампании из списка ниже, и вот-вот начнут крутить цикл улучшений для паттерна E.23 с самим описанием этого цикла в самом общем виде (да, обобщение в том числе и для POOGI-PDCA-Boyd). Это типичная “раскрутка” (то бишь bootstrapping), AI с harness предыдущей версии делают harness следующей версии, более продвинутой.
Чтобы стать ближе к клиенту, FPF нуждается в SPF и людях, которые дотянут фундаментальное мышление через SPF к TPF и доведут до клиента множество capabilities, которые вырастают из разных языков паттернов. Наши инженеры-менеджеры станут вот этими “инженерами последней мили”, будут массово заниматься SPF и TPF, им будет нужна сбруя/упряжь/harness для их любимых AI-агентов (ну, или не очень любимых, уж какие им дадут использовать в их компаниях). Но это будет к концу июня, а пока мне надо провести 13 спланированных сегодня (да, очередное перепланирование!) кампаний по написанию новых паттернов FPF. Радость-счастье в том, что постановки задач по ним написаны и надо просто взять и сделать (там разные темы нарезаны вперемешку, ибо паттерны более ранних кампаний нужны для успеха более поздних, очень много взаимозависимостей). Это кратчайший маршрут от FPF harness к SPF, TPF и тем самым поближе к проектам наших инженеров-менеджеров:
1 – Quality improvement loop method stabilization amendment. The governing problem is now the repeated quality-improvement loop method: how FPF improves one declared target through quality review, row-atomic absorption, reviewer re-read, stop/narrow/continue/switch/hold judgement, and BLP-shaped cost/risk discipline.
2 – Precision restoration distribution amendment. E.10 and the precision-restoration branch distribution must be stable before later campaigns keep writing local language-unpacking clauses into thematic patterns.
3 – Architecture engineering and semio-bias control amendment. This campaign keeps non-semio patterns centered on the governed problem and first useful move while semio/I-D-S checks stay auxiliary. It should consume the stabilized quality-review and precision-restoration machinery rather than re-solving those defects locally.
4 – Architecture queue number 2 corrective repair and landing. Queue number 2 repairs architecture goal drift and lands module/interface, modularity, and reusable-structure content after the shared anti-drift and language machinery is stable.
5 – TGA queue number 5 P2W and work-result carry-through. SEMIO-04 is accepted, and TGA P2W may proceed when TGA graphs are used only as descriptions or views about flows. Architecture output is used only where architecture claims are live.
6 – SEMIO-05 operational publication, record, cue, and authority-bearing-record map. TGA queue number 7 and architecture decision/candidate-set uses need accepted operational publication/record/cue admissibility when proof, gate passage, work authority, promise, or release reliance is live.
7 – Architecture queue number 3 scale amenability and coarse-graining support. Scale, coarse-graining, RG/frustration, and source-return decisions depend on architecture kernel plus queue number 2 characteristic discipline.
8 – TGA queue number 7 decision, NQD, OEE, and Q-front docking. Architecture queue number 4 should not invent its own set-return or Q-front ontology before general TGA docking is accepted where the general decision/NQD/OEE relation is live.
9 – Architecture queue number 4 modular architecture synthesis and candidate-set publication. Candidate architecture moves, selected sets, fronts, shortlists, and failure repair should read accepted TGA/general set-return docking rather than local reinvention. Basis: _workstreams/architecture/current/ARCHITECTURE-WORKSTREAM-PLAN.md, then selected architecture child campaign. Required output: accepted source-discharge slice DRR, external review if selected, landing.
10 – Architecture queue number 5 architecture decision object, description, and publication boundary. Architecture decisions and their publications need the accepted architecture synthesis layer and accepted semio operational-publication/record/cue boundary when reliance is live.
11 – Architecture queue number 6 operation source rows, domain examples, SoTA row seeds, and neighbor exits. Domain material should harden already selected general architecture moves instead of driving architecture ontology.
12 – Architecture queue number 7 structural information, equivalence, and synthesis extension. Structural information and equivalence require the architecture kernel, characteristic discipline, candidate-set boundary, and C.29/C.16 fit to be stable first.
13 – Later semio queue entries and semio closeout. Each selected semio campaign follows its launch-plan entry and retires before closeout claims finality.
Утешает только тот факт, что я уже существенно ускорился. Так, архитектурные паттерны первой архитектурной кампании уже в FPF, хотя пользоваться ими рановато: у них получился сильный semio-bias – и вместо архитектурной работы вы от них можете неожиданно получить “хозяин, никакой архитектурной работы не будет, пока ты свою диаграмму не перестанешь называть архитектурой”. Но базовые понятия архитектуры и общий вход в архитектурную работу на базе более-менее строгой теории архитектуры (да, с математикой) там уже есть. Конечно, там ещё много будет дотащено в кампаниях 2, 4 и 5, но умельцы уже могут пробовать доставать архитектурные советы из результатов первой кампании, всё уже в FPF – GitHub - ailev/FPF: First Principles Framework (FPF): Pattern language and core specification for admissible action in problematic engineering, research, and mixed human/AI work. · GitHub
