Я – “программист над LLM”
Под Новый Год масса комментариев во всех лентах, что “пошёл take off” (искусственный интеллект начал улучшать сам себя, и сейчас улучшит так, что люди перестанут быть царями природы, одно из определений сингулярности). Это слышно главным образом от программистов, ибо появились прецеденты программистов, которые вроде продолжают быть программистами, но не открывали IDE с кодом: In the last thirty days, I landed 259 PRs – 497 commits, 40k lines added, 38k lines removed. Every single line was written by Claude Code + Opus 4.5. Claude consistently runs for minutes, hours, and days at a time (using Stop hooks). Software engineering is changing, and we are entering a new period in coding history. And we’re still just getting started (https://x.com/bcherny/status/2004887829252317325). А я? У меня 3.5MB FPF (41k lines), который вполне себе инструментальная надстройка над LLM – это тоже код (уровня формальности “псевдокод”, но этого уровня формальности хватает для того, чтобы вытащить из LLM её лучшие черты и слегка придавить в ней её худшие черты). И эти 3.5MB написаны тоже практически не мной, а разными LLM, главным образом GPT-x разных версий. Пост Карпаты, что “вы все устарели, и даже я отстал” я тут не цитирую, он вещается изо всех утюгов, а я ровно то же самое писал несколько последних лет. Какой отсюда вывод? Повторяю на всех своих семинарах и в своих руководствах: прикладные знания становятся менее важными, ибо они сегодня легко порождаются из первых принципов (что бы вы ни понимали под “первыми принципами”, смысл тут – выводятся легко из фундаментального знания, которое, кстати, тоже быстро меняется). Поэтому важно овладеть этими первыми принципами, поднять силу своего мышления, подготовиться к тому, что ежедневно участвовать в техно-эволюции приходится не в разрезе множества поколений, а вот прямо в реальном времени. И самый медленный, консервативный и тормозной элемент тут людские мозги. Поэтому я делаю FPF как ускоритель сильного мышления – и для людей (повторюсь, что мои руководства на 80% совпадают с тем, что говорится в FPF), и непосредственно для LLM.
Я при этом не использую существенно программистский инструментальный стек, который пытался перечислить в своём посте Karpaty (сколько слов вы из него знаете, что они означают и как это устроено? Вот: There’s a new programmable layer of abstraction to master (in addition to the usual layers below) involving agents, subagents, their prompts, contexts, memory, modes, permissions, tools, plugins, skills, hooks, MCP, LSP, slash commands, workflows, IDE integrations, and a need to build an all-encompassing mental model for strengths and pitfalls of fundamentally stochastic, fallible, unintelligible and changing entities suddenly intermingled with what used to be good old fashioned engineering. – https://x.com/karpathy/status/2004607146781278521, именно его вещают сейчас изо всех утюгов), ибо этот стек настроен на “спланируй, напиши тесты, долбись в написание кода, который закроет тесты”, ибо в FPF не так-то просто написать тесты, которые “однозначно прошли” или “однозначно не прошли”. Но toolchain у меня тоже есть, и навайбкодил я в него больше тысячи строк – и тоже не своими силами. Эх, если бы я занимался программированием, я бы был сегодня велик и известен, но нет. У меня идея другая: докрутка LLM и людей огромными промптами размером с “учебное пособие”.
First principles framework у всех работает, и работает хорошо!
За последнюю неделю в чатах моих двух семинаров делятся тем, как используется FPF – хорошо используется, я доволен! Вытащу один утренний коммент из этого чата, от Петра Леонтьева (чат закрытый, только для почти сотни участников последнего моего семинара, поэтому ссылку туда не даю):
Изрядно всё же помогает такой фреймворк:В одном из наших чатов я привёл пример абсолютно рабочего короткого промпта: “В файле у тебя спецификация FPF, а на картинке - архитектура IT в рамках стандарта IT4IT. Откомментируй эту архитектуру с учётом FPF, но не используй специфических понятий FPF, говори на языке IT-менеджера, которому поручили архитектурное review этой картинки”. Review получилось отличным, я бы с такой скоростью сам не смог – и это даже не Pro, а Thinking GPT-5.2.
- Гружу в ChatGPT FPF в качестве общего контекста раздела.
- Гружу в ChatGPT в чат по теме, свои заметки по области знания, которые вёл пока проходил ещё учебники.
- Прошу составить граф трансдукции для работ по проекту в этой области
- Подгружаю контекст текущего проекта, тоже в виде, который получился в моём экзокортексе, тоже с опорой на метамодели из курсов/практик
- Задаю задачу, которая передо мной стоит. И предлагаю задать мне вопросы по теме.
- Отвечаю на вопросы.
- Получаю годный рабочий документ, который можно допиливать.
Терминомика в FPF: границы, межи, интерфейсы, параметры, сигнатуры
За последнюю неделю FPF (брать вот тут: GitHub - ailev/FPF: First Principle Framework, прямо сейчас там уже 144 звезды и 25 форков) пополнился частью про сигнатуры как границы (отношения, сигнатуры, интерфейсы, параметры и всё остальное, что имеет “взгляд снаружи” и “взгляд изнутри”. Всё время вспоминаю “терминомику” Евгения и Надежды Репиных – https://terminomika.ru/, Терминомика — межевая теория права — Terminomika, там так: “Одно из центральных понятий в терминомике — грань. Грань по-латыни terminus, νομος — закон по-гречески. Таким образом, терминомика — наука о гранях. О том, где кончается моё и начинается твоё”. Потом они ушли в довольно специфический словарь (воля, дело, сила, межа), нас интересует Межа — Terminomika – грань, рубеж, граница. Репины пишут так: “Термино́мия или терминомика (от лат. terminus «межа, граница» + др.-греч. νόμος «правило, закон») — наука о межах. Предмет терминомии — люди, конкурирующие за дефицитные силы. В отличие от экономики, предметом которой является эффективность — то есть использование своих сил для достижения максимальной радости, терминомика изучает то, каким образом силы делятся на свои и чужие”.
У меня в FPF, конечно, нет такого обобщения на экономику и правовое размежевание, но граница - это фундаментальное понятие, недаром и bounded context, и граница системы с её окружением, и инкапсуляция модулей. Я сделал A.6 как кластер, посвящённый границе. Туда входят сейчас паттерны определения сигнатуры (он же пригоден для определения интерфейсов, портов для потоков и много чего ещё, это и есть “паттерн границы”), паттерны распаковки смыслов в отношении (ибо слоты, основания, контракты - это всё так или иначе про “у вас тут на границе два разных взгляда: изнутри и снаружи”), а также попутно добавлено немного деонтики, паттерн для commitment – что делает шаг в сторону той самой “терминомики”. В часть D, где будет многоуровневая деонтика, пока не лезу.
Квадрат норм распаковки высказываний о границах
Главное в этом кластере границ - “квадрат” норм распаковки высказываний о границах как каноническая матрица 2x2 разведения этих норм на четыре класса по двум характеристикам, чтобы распаковать всяческие “приграничные” метафоры, скрывающие важные различия в приграничных нормах:
– семейство модальности — по этой стороне квадрата делим “истинностные утверждения” против “надзорных норм” (modality family: truth-conditional vs governance), и
– где решается “выполнено/не выполнено” — по этой стороне делим на нормы об “одном только описании” против норм об “измерении/наблюдении фактической работы и носителей” (adjudication locus: in-description/in-theory vs in-work).
Квадранты норм задают маршрутизацию (routing) каждого атомарного утверждения (atomic claim) в одно из мест стека сигнатур с разными слоями:
– законы, инварианты, определения (Laws & Definitions, L) — в Signature.Laws;
– допустимость и “входные условия” в смысле технической допустимости (Admissibility & Gates, A) — в Mechanism.AdmissibilityConditions;
– долженствование и обязательства/обещания (Deontics & Commitments, D) — к нормам/обязательствам ролей;
– эффекты работы и свидетельства (Work-Effects & Evidence, E) — к наблюдаемым/измеренным носителям/следам/метрикам.
Если удовлетворённость нормы устанавливается только чтением текста и это текст определения или инварианта → L, а если по тексту и это обязанность/разрешение/обязательство → D (но проверять будем не по тексту, а косвенно через свидетельства результатов работы!); по наблюдаемой работе → A или E. Как это понимать? Вспоминаем любимый пример Андрея Родина: отождествить A=A можно в уме, а вот отождествить Утреннюю Звезду и Вечернюю Звезду (в разных странах называется по-разному, находится на небе в разном месте в разное время) как Венеру можно только при помощи наблюдений и теории (модели), по которой надо выполнить какие-то расчёты. Вот это всё надо как-то распаковать, чтобы в инженерии и менеджменте была хоть какая-то воспроизводимость и рассуждений, и результатов.
Важно, что квадрат не задаёт онтологию (не классификатор!), это маршрутизатор. Онтология - это про “что есть в мире”, и тут можно пытаться неверно сказать что-то типа “этот интерфейс - deontic”. Маршрутизатор (“разруливатель”) - это про разруливанию спрессованных в мутную фразу высказываний о мире, у которых есть какие-то свойства, вроде “это предложение по интерфейсу требует назначения исполнителя” – и вот это “требование в предложении по интерфейсу” как раз и будет деонтично. Цель маршрутизатора - предписать обработку/распаковку/размутнение текста для распарсирования на высказывания, которые можно как-то проверить и воспроизводимо (“объективно” как “одинаково разными людьми/LLM”) соотнести друг с другом, а не просто классифицировать объекты, упомянутые в тексте.
Предлагается расщеплять фразы с перемешиванием допущений (не-деонтика, математические и физические допущения), обязанность их соблюдать (деонтика) + требование наблюдаемости (деонтика в связке с реальным миром) на треугольник, triangle decomposition: A формулирует предикат допуска, D закрепляет обязанность роли соблюдать/обеспечивать этот предикат (D→A), E привязывает наблюдаемость/носители к решениям по этому предикату (E→A). Если одна норма смыслово опирается на другую, она должна ссылаться на неё явно по идентификатору (explicit reference by claim ID), а не пересказывать заново. При этом запрещены «восходящие зависимости» (no upward dependencies): L не зависит от A/D/E; A и E не зависят от D; а D может ссылаться на L/A/E по ID (а не повторять их, чтобы не переопределять). И ещё D-претензии авторизуются в тексте; их выполнение часто устанавливается косвенно через E-претензии — и это не меняет маршрутизацию D. И кроме треугольника есть ещё стандартные разрешённые стрелки (D→E, A/E→L, D→L), в целом там небольшой такой “граф разруливания приграничных высказываний” с чёткими запретами:
– L-* не ссылается на A/D/E
– A-* не ссылается на D-* (может на L-)
– E- не ссылается на D-* (может на A-* и L-)
– D- может ссылаться на L/A/E и лучше по ID, а не пересказом (чтобы не было соблазнов поправить “законы неба” в высказываниях о “земных законах” и “земных допустимостях” вроде “в военное время синус рекомендовать больше единицы” и “в литровую бутылку наливать полтора литра”).
Треугольник A + D→A + E→A закрывает самую частую ошибку: “раз A проверяется по наблюдениям, значит это E”. Нет: A — это предикат технического/модельного допуска/применимости, а E — свидетельство о мире, которое может быть входом в решение по A. Если утверждение задаёт предикат, который определяет, имеет ли смысл/право применять описание/обещание → это A. Если утверждение сообщает измеренное/наблюдённое значение или носитель/след → это E. Даже если A проверяется через E, A остаётся A (а E остаётся E). Так сохраняются стабильность смысла математических и физических законов, независимость технических проверок (gates) от надзорной риторики, а также проверяемость по свидетельствам, а не простая “вера обещаниям”.
Конечно, интуитивно это всё понимается, “опытные люди всё это и так делают”. Только опыт у всех разный, реально опытных мало, и ещё даже опытные люди (и даже опытнейшие LLM) любят сокращать или даже намеренно избегать “трудных мест” – их учили “нравиться”, а гонцов, приносящих плохие вести, убивают. Вот об ошибках знают, но ни за что не говорят! Ох, я намучался с этим в реальных производствах. Скажем, технологам запрещено говорить о том, что они что-то делают не по стандарту. Поэтому на твои вопросы “как у вас это устроено” они отвечают фразами из стандарта, но работают ни разу не по стандарту. Я очень надеюсь, что FPF такое будет вскрывать сразу (а мне требовалось окольными путями узнавать, как же они там работают, потом предъявлять, что я уже знаю то, о чём спрашиваю, и только после этого хоть что-то обсуждать про “как оно в жизни, а не в стандарте”). Конечно, там не только “распаковка-разборка”, но и потом сборка. Скажем, можно использовать шаблон (он там есть): “We mean [short label] in the sense of L-…. It’s only meant to be used when A-… holds. [Role] is responsible for maintaining that condition (D-…). Whether it holds is checked using E-…, and the latest recorded status/value is E-….”
Примеры распаковки “приграничных” высказываний в программной инженерии, машиностроении, менеджменте
Пример из программной инженерии: “Этот API гарантирует p95 latency < 200ms”. Фразу поймут гарантированно неверно: “гарантирует” смешивает D (обязательство) и E (как измеряем p95) и часто прячет A (при каких условиях это вообще допускается). В паттерне A.6.B прямо называют такое типовым анти-паттерном: “Evidence-free guarantees” и “Interface-as-promiser”. Если вы пишете такие фразы, FPF вас поймает. Если вам пишут такие фразы, FPF поймает тех, кто пишет. Если вы, конечно, понимаете, что тут плохого. Если не понимаете, читайте про “А чо такова?” - Пока слышим "а чо такова?", обучения практикам мышления не будет: ailev — ЖЖ. API как “границу” определяем сигнатурой (signature-pure) интерфейса – без деонтических “обязанностей”, проверяемых в run-time: что такое “p95 latency” (какие единицы измерения на какой шкале, какие временные окна, как вычисляется), а ещё это же “параметры”, поэтому используем слот-дисциплину из A.6.5 (бывают самые разные варианты подстановки параметров, легко перепутать – что там каких типов, передаём позиционно или по имени, по ссылке или по значению, и т.д.). Дальше проясняем про “обещание” (“гарантирует”, ха-ха): это обещание вообще применимо только если (и дальше что-нибудь вроде “при нагрузке меньше X, и вы в США, и заплатили за Ultra опцию”, мелким шрифтом). Это не MUST/SHALL, не деонтика, это MechanismAdmissibilityConditions, “законы неба”, технические детали. Дальше идём в деонтику, которая предписывает что-то в допуске/admissibility, “SRE-инженер MUST обеспечить допуски, предоставив логи”.
Вот этот обрывок про “гарантирует p95 latency < 200 ms” распаковывается аж вот в такой текст:
L (Laws/Definitions): Latency = время обработки на стороне сервиса (от входного шлюза до отправки ответа), без клиентской сети/DNS. p95 = 95-й перцентиль по успешным ответам (2xx/3xx) в окне 5 минут, при достаточной выборке (например, ≥10k запросов/окно).Пример из машиностроения: “Эта посадка обеспечивает соосность”. “Обеспечивает” может читаться как (L) физический закон, как (A) технологическая применимость “если всё сделано правильно”, как (D) обязанность технолога “обеспечить”, и как (E) “мы измерили и видим соосность”. На заводах это особенно распространено: люди отвечают “словами стандарта”, а реальность абсолютно друга. Распаковываем похожим образом: прежде всего понимаем, что есть граница между валом и втулкой, а поскольку это граница, то там сразу n-арное отношение между осью, валом, втулкой, классом соответствия и диапазоном допуска, температурное окно, схема замера, и вообще “что такое соосность” как характеристика (в FPF огромный блок по характеризации – все эти шкалы, единицы измерения, нормализации/калибровки и т.д.).“Соосность” почти всегда basedness-утверждение: относительно какой базы/основания и как на неё ссылаться? Здесь A.6.6 даёт канонический ход: сделать baseRelation(dependent, base) явным и привязать область применимости, окно времени, а также “как будем свидетельствовать”. И там ещё много чего интересного дальше.A (Admissibility/Gates): Это сравнение вообще имеет смысл только если: prod, регион us-east-1, тариф Ultra, средняя нагрузка ≤500 RPS (пики ≤800), размер запроса ≤64 KB, клиент не нарушает quota/rate-limit. Если A не выполнено — сначала приводим A в норму, потом обсуждаем p95 на предмет выполнения обязанности удержания на меньше 200 ms.
D (Deontics/Commitments): Цель (обязанность удержания): p95 < 200 ms.Ответственный за поддержание A и целевого уровня — дежурный SRE команды Orders; при 2 подряд “плохих окнах” — эскалация тимлиду SRE.
E (Work-Effects/Evidence): Источник p95: Prometheus http_server_request_duration_seconds (service=orders, endpoint∈{GET/POST /v1/orders}, status=2xx|3xx, region=us-east-1). Первичные следы: trace-id (distributed tracing) + raw access-логи шлюза. Фиксация: SLO-дашборд + ежедневный отчёт (90 дней). Пример статуса: p95=178 ms за 2025-12-28 09:00–09:05 CT (ссылка в карточке инцидента/изменения).
Этот обрывок про “посадку обеспечивает соосность” распаковывается (не бойтесь, это не люди будут делать – но лучше бы людям понимать происходящее) так:
L (Laws/Definitions): Для пары вал Ø20 h6 + втулка Ø20 H7 (посадка H7/h6) “соосность” понимается как соосность/биение оси посадочной поверхности относительно базы A (и/или B) по КД.У менеджера примерно так же распаковывается “Проект согласован”. Эта фраза трактуется почти всегда неверно: а) политически ОК, шеф кивнул, б) политически ОК, все кивнули, в) текст описания проекта прошёл какой-то гейт, г) текст описания проекта получил все подписи (но даже непонятно, утверждён - или только подписи визирования), д) можно начинать работу, е) исполнители ролей назначены и они согласны – и это ещё не все варианты интерпретаций, бывает ещё и “я согласовал проект, про остальное не знаю, и я не начальник, я вообще там сбоку – но проект мной согласован!”, бывает “я считаю, что проект согласован” (но не знаю точно, а “согласован” считаю по любому из вышеописанных вариантов).A (Admissibility/Gates): Утверждение применимо только если: детали в допусках КД (размер/форма/шероховатость), сборка при 20±2°C, поверхности очищены, запрессовка прессом 8–12 kN через оправку TOOL-P20, без ударной посадки (молотком), выдержка 10 минут до измерения. Если A не выполнено — не говорим “обеспечивает”: сначала подтверждаем A.
D (Deontics/Commitments): Требование: соосность ≤0,01 mm. За соблюдение условий сборки отвечает технолог участка; за подтверждение результата — ОТК/контроль качества.
E (Work-Effects/Evidence): Измерение по методике MI-COAX-07: индикатор на призмах (или КИМ — если так задано), 60 rpm, 3 повтора, документируем max/mean; точность СИ ≤0,002 mm. Документируем: QC-протокол + запись в SPC-журнал. Пример статуса: 0,008 mm для партии BATCH-2025-12-15 (QC-2417-B15-03).
По итогам распаковки этого “проект согласован” получается (если вам кажется всё это длинным и не нужным, то у вас просто не было опыта заключения больших контрактов в бюрократической структуре крупных компаний, там можно на стадии “проект согласован, но почему-то ничего не происходит” застрять на год или больше, так что лучше бы разобраться сразу), дадим тут без использования формальных маркеров заполнения “квадрата” LADE:
Под фразой “проект согласован” понимается, что согласован документ описания проекта Project-Phoenix-Scope v1.4 от 2025-12-27 (ссылка/место хранения такие-то), в котором согласованы границы работ (что входит/не входит), целевой результат и критерии приёмки, отдельно утверждён бюджет до 2 000 000 ₽ и срок до 2026-03-31, назначен руководитель проекта (ФИО/роль), и дано разрешение начинать выполнение работ по плану Plan v1.2 (а не только обсуждать/переделывать тексты о проекте, поскольку “мы согласовали, что проект будет”). Также получены все обязательные визы/подписи (Спонсор, Финансы, Безопасность, Юристы, ИТ-архитектура), закрыты обязательные предварительные проверки (например: безопасность/риски/закупки), создана бюджетная строка (ID), и подтверждена доступность ключевых ресурсов на стартовую фазу (не “в принципе найдём”, а конкретные исполнители/проценты занятости). Если хоть один пункт не выполнен, вместо “проект согласован” пишем точное состояние: “согласован текст, но бюджет не открыт”, “спонсор одобрил, но безопасность не закрыта”, “визирование не завершено (осталось 2 подписи)”, и т.п. Ответственный за поддержание актуальности статуса — PMO/проектный офис (или руководитель проекта, если PMO нет); ответственный за само решение “можно начинать” — спонсор проекта. Как проверяем: наличие подписанного решения/протокола (ID), статус в системе учёта (например, Jira/портфель) = Approved-to-start, наличие бюджетной строки (ID) и назначений ресурсов (в RACI/план-графике). Где документируется факт согласования: запись в журнале решений + приложенный протокол/письмо/тикет как источник правды. Последний документированный статус “проект согласован” (пример): решение DEC-2025-118 подписано 2025-12-28 16:40 CT, статус Approved-to-start, бюджетная строка FIN-042193, руководитель проекта назначен с 2026-01-02.
Распаковываем оптом: “утверждено”, “согласовано”, “разрешено”, “опубликовано”, “отозвано”.
Слова “утверждено”, “согласовано”, “разрешено”, “опубликовано”, “отозвано” произносятся как название явлений природы, как зимой говорят “всё замёрзло”. Означает это “шеф в коридоре кивнул”, “подписано, но ещё осталось три подписи”, или “подписали, но предыдущую версию, надо повторять”, или “подпись главного начальника есть, но нужно ещё разрешение неглавного начальника на выделение ресурсов и начало работы”. Паттерн A.2.9 (U.SpeechAct) базируется на теории речевых актов, распаковывая эти слова в объекты “работ по коммуникации”: есть речевой акт (что именно сделали, тут “сказали” трактуется как “сделали”, то есть “изменили мир”, а не просто “сказали” - описали мир), есть высказывание (эпистема, содержание высказывания), и есть носитель для этой эпистемы (письмо, протокол, запись в базе данных). И самое важное: у акта есть контекст с правилами интерпретации, есть окно актуальности/свежести, и есть трассируемая “кто-что-когда-по-какому-праву”.
Паттерн помогает не путать “публикацию” с “авторизацией”, “авторизацию” с “обязательством”. В современных инженерных практиках координация работ происходит как раз через вот такие речевые акты, “слова-действия, меняющие состояние мира”. A.2.9 нормирует, как выразить цепочки актов/работ вроде 1. сначала ‘разрешить выполнять проект’, потом 2. ‘назначить ответственного исполнителя’, потом 3. ‘зарегистрировать/опубликовать решение с указанным исполнителем’, и только после этого 4. выполнять уже не координационный, а операционный акт/работу, тратить рабочие ресурсы на собственно работу, а не координацию. Это резко снижает классическую управленческую путаницу “проект согласован” - “значит можно начинать” (ха! там ещё десяток согласований после этого!).
Во всех этих “речевых актах” есть магические деонтические слова: MUST/SHALL/ДОЛЖЕН/ЗАПРЕЩЕНО/РАЗРЕШЕНО. В живых организациях эти слова часто не пишут вот так капсом, как предписано в стандартах вроде BCP 14 (best current practices для выражения требований в RFC как стандартах интернета). Эти слова часто используются в самых разных документах, но каждый раз они меняют смысл: то это “обещание сервиса”, то “техническое условие применимости”, то “политический лозунг”, то “формальное требование проверки, что соблюдено”. Паттерн A.2.8 (U.Commitment - термин почти невозможно перевести на русский, пусть уж будет “обязательство”) переводит подобные деонтические высказывания в явный объект чьего-то обязательства, который можно проверить на формат высказывания, а потом – на реальное выполнение. Обязательство найдут в тексте, и распакуют. BCP-14 ключевые слова — только в D-claims; L/A/E — без них (или пометят как informative, а не норму). Для D- (деонтики) заставят явно указать: к чему относится, в каком контексте действует, в каком окне времени, кем должно исполняться (какая роль), и по каким свидетельствам будет решаться “выполнено/не выполнено”. Бюрократический адъ, но мы понимаем, что выполнять его будут главным образом машины – и в этом месте вместо гуманитарного художественного толкования будет нормальная инженерная не только точность, но и воспроизводимость. Дырки в понимании как “законодателей”, так и “законоисполнителей” будут выявлены – и заткнуты. Если вам пишут “сервис гарантирует p95 < 200ms”, A.2.8 вернёт это автору с предложением выбрать: это обещание наружу (тогда это про сервис), это техническая применимость (тогда это про условия, при которых вообще можно обсуждать цифру), или это обязанность конкретной роли обеспечивать и доказывать, что обеспечил (тогда это обязательство с проверкой и доказательствами). В современных SoTA-подходах к управлению рисками и соответствием (от safety-case мышления до zero-trust по смыслу, не по бренду) ключевым паттерн A.2.8 делает не “красиво написать MUST капсом, соблюдая лексические требования”, а связать MUST с кем-то, кто это должен выполнить (Земля не ДОЛЖНА вращаться! неверный адресат!), “окном” (времени, каких-то других характеристик – когда предписание действует), и доказуемостью (можно ли вообще проверить, что кто-то это выполнил. “НЕ ДОЛЖЕН думать о красном паровозе” - такого не должно появляться, ибо непроверяемо).
Теперь третий ход — связка, которая превращает предыдущие два паттерна в прикладной инструмент для реальных границ/межей “мы против них”, подразумевающих контракт: API, интерфейсы, интеграции, межкомандные соглашения, SLA, “гарантии”, “обеспечивает”, “сертифицировано”, “согласовано”. Паттерн A.6.C (Contract Unpacking for Boundaries) разруливает разговорное слово “контракт”, которым сейчас айтишники разбразываются, не думая (контракт модуля, ага. И высокий суд, который засудит этот модуль за нарушение контракта, ага). Паттерн заставляет слово “контракт” распаковаться – что оно означает, какая это ситуация, ибо разные ситуации описываются по-разному. “Контракт” может означать минимально Service (promise), или Utterance, или Commitment, или Work+Evidence. Поэтому фразу с “контрактом” заставляем разложиться на атомарные утверждения по упомянутому уже квадрату LADE. Этот паттерн специально подчёркивает несколько болезненных мест, в частности “обещание сервиса ≠ фактическая работа”, “MUST/SHALL не должны вводить новые смыслы”, “нельзя давать гарантии без описания свидетельств об их выполнении”.
Зачем это инженеру-менеджеру? Потому что именно на границах рождаются самые дорогие разрывы: “они думали, что мы обещали”, “мы думали, что это просто условие”, “в отчёте такой графы нет, значит всё хорошо”, “в договоре слово ‘гарантируем’, значит можно не проверять”. A.6.C проверяет, что 1. “контракт” распаковывается в рамках объектов какой-то определённой ситуации, также всегда известно кто отвечает за возможные обязательства в ситуации контракта (если это “контракт модуля”, то это не модуль! Это создатель модуля!), чем он доказывает, что обязательство выполнено, 2. все работы по согласованию и заключению контракта - речевые акты, их “работают”, и выполнение этой работы проверяемо. “Контракт” перестаёт быть поэтическим словом, его использование приведёт к инженерной жёсткости в понимании и исполнении. Ещё один бонус: все описания контракта будут только описаниями, а не “вторым контрактом”, они не будут порождать новых обязательств.
Конечно, кластер написан сейчас математико-онтологическим языком, который плохо доступен простому смертному инженеру-менеджеру. Но если попросить LLM разъяснить простым языком инженера-менеджера (если совсем простым – языком менеджера, его FPF считает заведомо несведующим в технических вопросах) – разъяснит и даст примеры, а также вполне будет уже находить граничные объекты и распаковывать смыслы мутных “пограничных” (во всех смыслах этого слова) фраз.
И это ещё не вся работа. В тексте FPF замечено чуть ли не 800 употреблений слова service, и надо теперь проверить, что это не стало синонимом слова “обещание” в значительном числе мест (есть такое подозрение, ибо сервис - это обещание работы, следовательно - эпистема, следовательно, часть утверждений о том, что сервисом можно считать только обещанную работу будет путаться с тем, что “обещаная работа - это обещание”, дальше неизбежно где-нибудь будет “сервис на носителе”, ой).
Моя роль в киберпанке: делать FPF для LLM, а людей дообразовывать до уровня, когда они смогут им нормально пользоваться
В удивительные мы живём времена, прямо внутри фантастического киберпанк романа (это явно не кибер-утопия!). Моя роль в этом всём на ближайшее время – делать first principles framework для LLM, а людей дообразовывать до уровня, когда они будут понимать, как этим всем воспользоваться и почему это важно. Тут, конечно, максимум интеллекта определяется генетикой, как и максимальная скорость бега. Но при неправильной технике мышления никакой интеллект не поможет, в средние века как-то не случилось Эйнштейна, хотя генетически вроде всё было то же самое. С бегом то же самое: при неправильной технике бега не поможет никакая генетика. Машины тут всё меняют: LLM может существенно поднять IQ, равно как велосипед может существенно поднять максимальную скорость бега. Но надо иметь технику и в этом случае: уметь работать с LLM, уметь ездить на велосипеде. Этому надо научить, это точно не “врождённое”. А если ты не обучен технике мышления – то ты средневековый дурак, даже если у тебя запредельно высокий генетический IQ. И техника в руках дурака – кусок железа, а LLM в руках дурака — кусок мудреца, только филейная его часть.
