Pattern language Анатолия Левенчука для команд с людьми и AI-агентами - простыми словами с примерами для PM, инженера и обычного человека.
1. Сцена
Вечером команда собирается на два часа обсудить один вопрос: купить ли готовый SaaS, fine-tune’ить открытую модель или строить свой agent stack с нуля. Разговор насыщенный - тридцать аргументов, примеры из практики, кто-то тянет на whiteboard цифры TCO. Расходятся в 22:00 довольные: «Хорошо поговорили, кажется определились».
Утром PM пишет в чат: «Отлично, начинаем смотреть SaaS-варианты». Лид-инженер отвечает: «Подождите, мы же договорились на fine-tune». Директор читает оба сообщения и удивляется: «Какой fine-tune, мы решили строить сами».
У меня такое было дважды. Один раз - почти дословно, другой раз чуть мягче.
Все три человека были на одной встрече. Все три слышали одно и то же. И каждый унёс ровно ту часть разговора, которая совпадала с его картиной мира ещё до начала встречи.
Память тут не виновата. Когда тридцать аргументов летят без общего скелета, каждый строит свой - и три скелета выглядят как три разных решения.
2. Кто такой Левенчук и что такое FPF
Анатолий Левенчук - российский инженер-методолог, преподаватель Школы системного менеджмента, автор нескольких учебников по системному мышлению. Он много лет изучал, почему образованные люди с хорошими намерениями приходят к разным выводам из одних и тех же данных - и что с этим делать.
FPF (First Principles Framework) - его ответ. Не учебник и не методология вроде Agile. Скорее - pattern language в понимании Кристофера Александера, архитектора, который в 1970-х описал принципы строительства через набор именованных паттернов. Идея та же: если у людей есть общий словарь паттернов, они могут говорить об устройстве сложных вещей, не изобретая термины заново каждый раз.
Текущая версия FPF - май 2026. Семь мегабайт нормативной спецификации, примерно 3195 заголовков. Статус - «вечная альфа»: уже применяется в реальных проектах, но эволюционирует.
Чтобы был понятен масштаб разрыва между спекой и обычным чтением - вот один реальный заголовок паттерна:
A.6.3.RT - RepresentationTransduction - same-described-entity representation-scheme transition. Или вот ещё:U.RelationalPrecisionRestorationSuite. Это нормальный язык внутри FPF - точный, согласованный сам с собой. Именно поэтому нужны статьи-переводчики: спека написана для самого фреймворка, а не для тех, кто только знакомится.
3. Главная идея: одно рассуждение - много читателей
Реальная проблема не в том, что у людей мало ума. Проблема в том, что одно и то же решение должно одновременно отвечать на вопросы разных аудиторий.
Инженер видит фичу как API + зависимости + граничные случаи. PM видит срок и бюджет. Аудитору важно одно: как откатить, если пойдёт не так. А клиенту, на самом деле, всё равно - его волнует только то, не вырастет ли тариф. Это не четыре фичи. Это одна, под разными углами.
Если вести четыре документа - один для инженера, один для PM, один для аудитора, один для клиента - они разойдутся через неделю. Обновили один, забыли остальные. Встречается это на каждом проекте.
FPF предлагает другой подход: ведётся одно рассуждение, из которого публикуются проекции для разных читателей. Рассуждение - единый источник. Проекции - срезы под конкретный угол. Если рассуждение изменилось - все проекции меняются автоматически, потому что берутся из одного источника.
Отдельный вопрос - как рассуждение остаётся согласованным с собой, когда его трогают разные люди. FPF называет это «без semantic drift» - слово в одном контексте значит то же, что в другом, и если смысл поменялся, это видно явно. Для этого FPF вводит несколько механизмов, три из которых разберём подробно: холоны, Strict Distinction и Open/Closed World Assumption.
4. Холоны
Холон - термин из биологии и системного мышления. Обозначает то, что одновременно является целым для своих компонентов и частью чего-то большего. Атом - холон: целое для электронов и ядра, часть молекулы. Команда - холон: целое для людей в ней, часть организации. Фича - холон: целое для своих подзадач, часть продуктовой стратегии.
На практике большинство ошибок проектирования - это путаница уровня. Когда команда говорит «давайте оптимизируем оформление заказа» - это про холон-уровень страницы или про холон-уровень всей воронки? Если один понял страницу, а другой - воронку, они два часа будут говорить мимо друг друга и не заметят этого.
Для PM: фича «реферальная программа» - холон. Внутри: приглашение, награда, аналитика. Снаружи: часть продуктовой стратегии роста. Если обсуждать её только как изолированную единицу - теряешь связь со стратегией и неожиданно выясняется, что реферальная программа работает против другого продуктового решения. Если обсуждать только как кусок стратегии - теряешь контроль над реализацией, и реальная фича оказывается не похожа на то, что было задумано.
Для инженера: модуль auth - холон. Внутри: классы, функции, тесты. Снаружи: часть API, которую используют другие сервисы. Рефакторить классы внутри, не зная как их вызывает внешний API - это типичная категорная ошибка. После рефакторинга сигнатуры стали «чище», но все вызывающие сервисы сломались. Разговор шёл на уровне холона-классы, а последствия оказались на уровне холона-API.
Повседневный: ужин «котлеты с пюре» - холон. Внутри котлеты: фарш, лук, яйцо, специи. Снаружи: часть недельного меню. Если жена просит «сделай поужинать» - это холон-уровень ужина, а не холон-уровень котлет. Купить мясо и начать лепить котлеты - правильный ответ на одном уровне, но неправильный, если в холодильнике оказалась готовая еда и просьба была «разогрей что-нибудь». Спор про уровень.
FPF требует явно называть холон, с которым работаешь прямо сейчас. «Обсуждаем фичу как часть стратегии» или «обсуждаем фичу как набор задач». Звучит занудно - но половина споров после этого растворяется. Они были на разных уровнях, а казались о разном.
5. Bounded Context и Strict Distinction
Bounded Context: одно и то же слово в разных контекстах означает разное. «Пользователь» в auth-домене - запись в таблице users с хешем пароля. «Пользователь» в маркетинге - человек со счётом, историей покупок и cookie. «Пользователь» в support - открытый тикет с временем ответа. Если перетащить рассуждение из одного контекста в другой без пометки - получишь баг: маркетинг считает 10 000 пользователей, бэкенд видит 6 000, support обрабатывает 800. Все правы в своём контексте, никто не понимает расхождение.
FPF говорит: у каждого контекста есть локальный смысл. Переход между контекстами нужно делать через явный мост - таблицу соответствия, преобразование, или хотя бы пометку «здесь у этого слова другое значение». Пока моста нет - разговор идёт как будто через стену: слова те же, смыслы разные.
Strict Distinction - отдельный жёсткий закон FPF. Он выделяет шесть вещей, которые постоянно смешивают в одном разговоре:
- Система - то, что существует или будет существовать
- Роль - кто выполняет работу (не конкретный человек, а функция)
- Описание метода - как написано в книге, гайде, стандарте
- Метод - как реально делается на практике
- План - что собираемся делать
- Работа - что действительно произошло
Для PM: «Тестировщик не работает» - про что именно? Может, роль тестировщика никому не назначена (роль). Может, в плане нет времени на тесты (план). Может, тестирование проведено, но результаты не дошли до команды (работа). Может, принятый в команде метод тестирования не подходит для этого типа задач (метод). Четыре разных разговора - одна и та же фраза.
Для инженера: «Микросервисы плохо работают» - про что? Про описание метода (книжное представление о микросервисах не совпадает с реальностью этой команды)? Про метод (как команда реально внедрила, с конкретными решениями по деплою и сети)? Про работу (конкретный сервис в конкретном инциденте)? Про систему (архитектурное решение в целом)? Это четыре разные проблемы, и у каждой - своя диагностика.
Повседневный: «Семья не разговаривает» - про что? Про роль (никто не взял инициативу начать разговор). Про описание метода (нет принятой в семье традиции совместных ужинов). Про метод (традиция есть, но реально все сидят в смартфонах). Про план (не договорились выделить время). Про работу (вчера разговаривали прекрасно, сегодня - нет, нужно разобраться в этом конкретном случае). Пять разных проблем.
Половина «непонимания» в команде происходит именно здесь: один говорит про роль, другой - про план, третий - про метод. Все думают, что говорят об одном. Strict Distinction заставляет указывать, про что именно идёт разговор.
6. Open World и Closed World
Два режима работы с информацией, которые выглядят похоже, но устроены противоположно.
Open World Assumption (OWA): если чего-то нет в известных данных - это не значит, что этого нет. Отсутствие доказательства не равно доказательству отсутствия. Если имени нет в списке гостей - может, забыли записать. Это режим науки, исследования, интернета. Всегда может появиться новый факт, который изменит картину.
Closed World Assumption (CWA): если что-то не известно как истинное - считается ложным. Если имени нет в авиационном манифесте - пассажир в самолёте не летит. Это режим базы данных, юридических контрактов, инженерной безопасности. Что явно не разрешено - запрещено.
FPF не выбирает один режим на всё. Вместо этого он строит гибрид: мир в целом открыт, но для конкретного решения рисуется «остров замкнутости». Внутри контракта, контекста или спецификации - всё определено, двусмысленность запрещена. Снаружи - пусть остаётся открытым. Переход между островом и внешним миром требует явного моста.
Важно: это не про то, какой режим «правильный». Оба режима корректны - в своём месте. Проблема возникает, когда режим не назван явно, и участники разговора работают с разными допущениями. Один считает, что «всё, о чём не договорились - надо уточнить» (OWA), другой - что «всё, о чём не договорились - не делаем» (CWA). Оба будут правы в своей системе, и оба удивятся результату.
Для PM: спринтовый список задач. Внутри спринта - закрытый мир: задачи, которых нет в спринте, не существуют для этих двух недель. Снаружи спринта - открытый мир: список задач бесконечен, может появиться что угодно. PM выбирает, где какой режим. Если перепутать - либо ничего не сделаешь (всё время добавляешь задачи из открытого мира в спринт), либо упустишь критичное (закрытый мир не пустил внутрь реальный приоритет).
Для инженера: HTTP API. Список endpoints - закрытый мир: всё, что не описано - не существует, клиент не должен на это рассчитывать. Но внутри каждого handler - открытый мир: запрос может прийти любой формы, нельзя считать что входные данные гарантированно правильные. Path traversal уязвимости возникают именно потому, что разработчик думал в режиме «закрытого мира» там, где был открытый: считал, что пути будут только «нормальные».
Повседневный: семейный бюджет в таблице. Категория «дети» - закрытый мир: то, что туда не попало, детскими расходами не считается. Но реальные расходы на детей - открытый мир: всегда вылезает что-то новое. Если жить только по таблице - новое не учтёшь. Если только по реальности - месяц никогда не закроется. Умное ведение бюджета - это явное решение: вот мои «острова замкнутости» (фиксированные категории), вот где я оставляю открытость (резервный фонд).
FPF учит говорить явно: «здесь у меня открытый мир, здесь закрытый, вот граница между ними».
Особенно это критично при работе с AI-агентами. Агент, получивший задачу, работает в строгом CWA: «то, что не написано в prompt - не существует». Человек, поставивший задачу, часто мыслит в OWA: «ну понятно же, что надо сделать и то, и другое». Это не баг агента - это несовпадение режимов. FPF даёт язык, чтобы назвать это несовпадение до начала работы, а не после того, как агент сделал ровно то, что было написано - и ровно это оказалось не тем.
7. Trust calculus, Evidence и ADI
У FPF есть собственная арифметика доверия. У утверждения три измерения: формализация (F), область применения (G), надёжность (R). На стыках утверждений - congruence (насколько хорошо они стыкуются). Главное правило: общая надёжность системы утверждений = её слабое звено, не среднее. Усреднять доверие - заведомо завысить оценку.
У каждого факта есть срок годности. Бенчмарк год назад - это уже не доказательство, это история. Архитектурное решение, принятое «пока не появятся лучшие варианты», без явной даты пересмотра - тихо устаревает. FPF делает срок годности явным и обязательным.
Цикл рассуждения: смелая гипотеза (abduction) - оформление в проверяемую форму - сбор доказательств - внедрение в практику. Этот круг работает и для научного исследования, и для продуктовой разработки, и для аудита архитектурного решения.
Подробно про расчёт надёжности и почему среднее обманывает: «Усреднения врут» и методологический документ про evidence. Цикл рассуждения ADI на практике: гайд ADI и методологический документ. Срок годности фактов и decay-механика: гайд evidence-and-decay.
8. Где это работает на практике
До сих пор это могло звучать абстрактно. Несколько конкретных ситуаций для опоры - из разных сфер, не только инжиниринг.
Платёжный API смешивает запреты, обязанности и санкции в одном документе. Интеграторы ломаются на каждой второй интеграции. Помогает паттерн A.6 Boundary Discipline (L/A/D/E) - разнести каждое утверждение по типу: Law / Admissibility / Deontic / Effect. Юрист потом читает только L+D, SRE - только E, тестировщик пишет отдельные suite на запреты и на обязанности.
Радиолог пишет «образование, наиболее вероятно доброкачественное». Клиницист читает как диагноз, наблюдение откладывает. Через год выясняется, что это была одна из трёх гипотез, и не главная. Помогает B.5.2.1 Creative Abduction - возвращать Pareto-front с весами, а не победителя. Заключение содержит три гипотезы с критериями, которые их различают.
Оценка работы «Анна работает хорошо». На калибровке менеджер не может обосновать повышение. Помогает A.15 Role-Method-Work - различать Role / Capability / Work. Шаблон ревью требует: какие новые Capability освоены, какие Work выполнены, какая Role расширилась. «Хорошо работает» больше не валюта.
Семейный совет о переезде в другую страну, обсуждается три месяца. Каждый разговор о разном уровне: дети vs школа, налоги vs визы, климат vs свекровь. Помогает A.1 Holon + A.7 Strict Distinction - выписать 4-5 явных холонов и обсуждать каждый отдельно. Из «бесконечного спора» получается structured decision за выходные.
Полный каталог из 25 ситуаций - в отдельном посте: Где FPF помогает: 25 ситуаций из разных сфер.
9. Когда FPF лишний - когда нужен
Не каждой задаче нужен полный язык паттернов. Вот честное разграничение.
FPF лишний если:
- задача маленькая и изолированная
- словарь стабилен, все понимают термины одинаково
- обратная связь быстрая и дешёвая - ошибся, сразу увидел, исправил
- цена semantic drift низкая: даже если у людей чуть разные картины, это не ломает работу
- нужен быстрый одноразовый ответ, а не переиспользуемое рассуждение
- работаешь один, контекст держишь в голове и не теряешь
FPF нужен если:
- работа размазана по специалистам, командам или AI-агентам - у каждого своя картина
- проверка в реальном мире медленная, дорогая или рискованная - нельзя просто попробовать
- разным аудиториям нужны разные срезы одной и той же работы
- текущий словарь ломается под новыми задачами - старые термины начинают значить разное для разных людей
- нужен переиспользуемый анализ, а не одноразовая рекомендация под конкретный случай
- работа с AI-агентами в одном репозитории: каждый агент знает свой контекст, нужен общий язык
Второй список - это описание большинства продуктовых команд после первых шести месяцев работы.
10. С чего начать
Если хочется попробовать прямо сейчас - короткий протокол на трёх шагах: Как начать пользоваться FPF.
Сам FPF: репозиторий ailev/FPF на GitHub - там README с вводным объяснением и семь мегабайт нормативной спецификации для тех, кто хочет в детали.
Если интересно посмотреть как идеи FPF реализованы в работающем инструменте - наша методология описывает конкретные практики.
Если хочется короткое визуальное введение без погружения в спеку - гайд FPF-overview.