Провёл вчера бесплатный полуторачасовой семинар “Ошибка – не вариант!” про то, что три прототипа – ОК, а вот три ошибки – это именно три ошибки. Главные тезисы: необходимость вариантов (нет вариантов – нет свободы!), справедливое сравнение (parity), различие между eval (для вариантов – индикаторы и Парето-фронт, exploration) и test (для ошибок), меры по снижению числа ошибок (у меня ответ тут понятный: руководства, резидентуры и FPF). Видео семинара опубликовано в канале поддержки рабочего развития (Telegram: View @mim_workdev), слайды тут: ТриПрототипаТриОшибки_22mar26.pptx — Яндекс Диск. Уложились в полтора часа, даже ответы на вопросы поместились.
Кстати, ещё
- три месяца назад был опубликован 13-минутный фрагмент видео с предыдущего (декабрьского) семинара по FPF – https://www.youtube.com/watch?v=lrRSe0Zwo10,
- затем два месяца назад ещё 16-минутный – https://www.youtube.com/watch?v=XrPhFRWbyKU,
- ещё одно 9-минутное видео оттуда опубликовано месяц назад (про граф трансдукций) – https://www.youtube.com/watch?v=G2IQ-0v_OGY,
- месяц назад 17-минутное видео из семинара “Развитие для развитых” – https://www.youtube.com/watch?v=IVkpfEx4PXI,
- три недели назад – ещё 15-минутное из семинара “Развитие для развитых” – https://www.youtube.com/watch?v=uLmmSlbBc_Q.
Я писал о том, что довольно много разных попыток подключить FPF к AI-агентам через skills. Вот два проекта, в которых произошли какие-то движения в этом направлении в последние дни:
- GitHub - CodeAlive-AI/fpf-problem-solving-skill: FPF (First Principles Framework) skill for AI coding agents. Based on https://github.com/ailev/FPF by Anatoly Levenchuk. · GitHub – FPF is a transdisciplinary reasoning architecture for systems engineering, knowledge coordination, and mixed human/AI teams. FPF is a thinking amplifier — it helps you plan deeper and make better decisions by systematically exploring relevant alternatives instead of anchoring on the first idea. How it works: This skill functions as agentic RAG — retrieval-augmented generation driven by the agent itself, with no external vector database or embedding pipeline. The 59,000-line FPF specification is split into a two-level hierarchy (20 directories, 230 files). SKILL.md provides a thinking-verb router that maps the user’s intent to the right section. The agent then navigates _index.md files to pick the narrowest sub-section (~300 lines) and loads only that into context. The agent is the retriever, the router, and the reasoner — all in one loop.
- GitHub - m0n0x41d/quint-code: Engineering decisions engine that know when they're stale. Frame, compare, decide — with evidence decay and parity enforcement. For Claude Code, Cursor, Gemini CLI, Codex and more. · GitHub – ‘/q-reason’ gives your AI agent an FPF-native operating system for engineering decisions: problem framing before solutions, characterization before comparison, parity enforcement, evidence with congruence penalties, weakest-link assurance, and the lemniscate cycle that closes itself when evidence ages or measurements fail. ‘quint-code fpf search’ gives you access to 4243 indexed sections from the FPF specification — the agent can look up any concept on demand.
Всё чаще встречаю отсылки к FPF в разных местах, например (https://www.linkedin.com/feed/update/urn:li:activity:7441842411212980224/), Николай Судников пишет про семантическую модель бизнес-анализа Александра Белина как Second Principles Framework: “у меня есть сильная гипотеза: связка FPF + SPF + модель предметной области способна заметно повысить качество AI-assisted анализа и проектирования”. Конечно! Только я бы заметил, что SPF тут – как раз модель предметной области, и для меня тут показано, что надо просто брать FPF+SPF1+SPF2+SPF3 (сколько предметных областей затрагиваем, столько и добавлять. Причём бизнес-анализ – это просто одна из предметных областей).
Самая приятная рецензия на FPF появилась в Telegram: View @systemsthinking_course, и она тоже про связку с предметными областями, но в этот раз отсылка к собственному знанию предметной области: “Когда знаешь предметную область и используешь FPF, восприятие меняется, как будто ты вместо обычного зрения получил в дополнение ещё и рентген, и зум ×100 :))”
Сейчас у меня по факту два проекта: работа над FPF и работа над упряжью (операционные документы, хелперы и диспетчер) для работы над FPF. Сама работа над FPF подкидывает проблемы, а FPF Platform Engineer эти проблемы решает. Моё время пока распределяется так: 80% я работаю над процессом разработки, а 20% работаю над semio-содержанием FPF.
Интересно, сколько русскоязычных разработчиков понимают, что harness – это упряжь, а поговорка “долго запрягает, да быстро едет” тем самым относится и к коллективным системам агентов? Запрячь тройку агентов надо тщательно, это будет медленно – а потом, конечно, классика: “какой же русский не любит быстрой езды!” (как будто быстрой езды не любит такой же американский или бразильский). Другая метафора из этой же серии – “Лучше один день потерять, чтобы потом за пять минут долететь”. Основной тут вывод – ничего нового тут нет, всё это было в наших руководствах по методологии, системной инженерии, системному менеджменту. От замены белкового агента кремниевым ничего по сути не меняется. Так что я поставил цель POOGI (ничто не ново под луной) – и уже пару дней потихоньку разгоняю цикл. Агенты быстро соображают, что делать, когда ты им указываешь на проблему: это же алгоритмика, программирование, а также архитектура – то, что там объекты непривычны программистам, не меняет способа мышления. Заодно пишем lessons learned и пополняем бэклог оптимизаций. И это – работает! По всем метрикам содержательный процесс пошёл довольно быстро, дальше будем “за пять минут долетать”. Но вот организация идёт туго: делаем двадцать маленьких патчей, потом архитектурное review, потом рефакторим по нему, потом продолжаем патчить – и вот так медленно, но верно наращиваем автоматизацию. И да, “организацию держат не люди, а софт и базы данных” – в случае агентов всё то же самое. Мою “организацию по написанию FPF” держат хелперы на Питоне, которые работают с кучей файлов состояния разработки, и ещё диспетчер, реализующий RPA. Более того, я прямо сейчас пытаюсь перейти с Codex App на CodexSublime – вот сегодня весь день буду экспериментировать, для моего процесса это может помочь наладить автоматизацию покруче, чем нынешнюю с RPA. Всё требует времени – но зато потом за пять минут долетим!
Тут ничего нового, это всё сейчас программисты пишут во всех блогах (и я тут действую как программист, “бывших программистов не бывает”), но они это изобретают для AI-агентов и слова у них вроде harness, а не “кровавый энтерпрайз” как софт-harness для мясных агентов, а мы просто говорим, что это “обычный менеджмент, ничего нового”. Инженеры-менеджеры всё это у нас узнают из руководств. Просто надо рассматривать руководства как описание принципов коллективной работы агентов, а не как набор лайфхаков про “инженерию человеками и менеджмент человеков”.
Ещё один интересный результат этих двух недель – это огромные затраты времени на присмотр за агентами. Это только кажется, что каждого хода агента надо долго ждать. Я уже перешёл из режима fast (где агенты работают чуть быстрее, но потраченные токены кушаются вдвое быстрее, и вы гарантированно вылетаете за недельный лимит. Я вот вылетал уже) в режим standard – и даже сейчас не всегда у меня работает хотя бы один агент. Агенты часто простаивают, ибо я не успеваю хоть как-то разобраться с тем, что они там наворотили за предыдущие такты. И я более чем регулярно пишу им вдогонку, в работающие чаты – ибо читаю их рассуждения и пытаюсь тут же править ход этих рассуждений. Увлекательнейшее занятие! Но дико времязатратное. Главный вывод: если вы считаете, и это написано во всех описаниях “в этих ваших интернетах”, что агенты работают асинхронно и вы спокойно поручаете им работу, а потом утром принимаете результат, то это похоже на откровенное враньё: возможно, это работает в ситуациях “вот тебе набор тестов и долбись, пока не пройдёшь”, но мой опыт другой – это чистый синхрон, непрерывно идущее совещание, непрерывная работа в какой-то авиадиспетчерской, где всё очень быстро, в реальном времени и надо как-то успевать воткнуться. Хотя да, можно всегда выключить агентский цикл – и идти пить чай. Но чувство простаивающей производственной линии не даёт это сделать! Очень интересное наблюдение. Я думаю, что новый сленг про “выгорание” и “потогонную систему” и “кровавый энтерпрайз” пойдёт вот отсюда – от несоответствия между ожидаемым асинхроном с агентами, когда “всё в удобное время” и неожиданной запаркой от мелкого диспетчирования, “руководства” (руками водства, микроменеджмента), прямое несоответствие BLP (bitter lesson preference): залить умного агента бюджетом и не трогать его мелкими указаниями по выбору метода, как это делается с более глупыми агентами, для которых метод надо указывать очень точно, буквально программировать. Почему есть ощущение, что у начальников много времени? Потому что ты посылаешь работника с заданием на неделю – и он исчезает, хотя хорошо бы проверять его работу. Тут ты посылаешь агента с заданием на неделю – он возвращается через двадцать минут, ты кофе попить не успел. И это “уже проверено, начальника! Ты нужен не для проверки, а для принятия решения, вот тебе три возможных варианта, жду ответа!”. А рядом заканчивает работу очередной агент, и там тоже надо что-то делать. Очень интересное ощущение.
Главное тут – это можно смело разбираться с лексическими долгами. Так, в новом наборе паттернов я заметил, что surface имеет значение совсем не такое, как в FPF. F.18 показал, что лучше бы это назвать AuthoredUnit. Ага, знакомый запах – это ж любимое наше слово-зонтик, слово-триггер! Смотрим: в FPF этого слова около 2000 вхождений! Каких они kinds, кроме AuthoredUnit? Шести разных! Например, note. Прошлый раз мы разбирались с таким для слова “gauge”, и там было под 1000 вхождений gauge в FPF и их разбор занял несколько дней работы. Сейчас смело идём в этот проект и исправляем – всё, уже опубликовано! Убрали примерно 700 двусмысленных использований, а ещё вставили общие замечания по тому, как работать с зонтичными словами-триггерами в FPF (чтобы в следующие разы не так долго размышлять, как в этот раз).
Попортилось ли что-то в FPF от такого вмешательства? Будем честны: что-то попортилось наверняка, хотя “простым глазом” это сразу не видно. Но много больше – поправилось, а не попортилось. А затем и попорченное тоже в какой-то момент поправится. Главное, что вот такие рефакторинги перестают держать проект, ибо я застревал раньше больше на них: на перетряхивании старых паттернов и выплате архитектурных долгов по плохим решениям, накопленным ещё со времён первых дней FPF, когда разработка велась слабыми LLM. А сейчас на все 700 раскладываний по шести значениям и, соответственно, 700 переименований был потрачен примерно день – больше на принятие решений о том, как такие правки делать в общем случае, чем на собственно правку этого конкретного surface.
При работе с Web-UI чатом состояние процесса – управление конфигурацией и всякое такое – было в основном “в чертогах разума”, держалось на мне и моих заметках. А сейчас – “все ходы записаны”, и это реально длинные ходы: реализация большого числа паттернов и правка по пути довольно большого вхождений терминов – а я не делаю никаких cut/paste (вот это действительно неинтеллектуальный труд!) в чат, только пишу комментарии-указания агентам. И всё работает – быстрее и быстрее, надёжнее и надёжнее с каждым днём. И ведь не только у меня, у всех так!
Ну и заодно – у меня тут два результата: поправленный FPF и поправленный процесс по его написанию, и сам процесс тоже довольно интересен как потенциально полезный продукт “минимальной производственной ячейки”. Вот сегодня появился новый сюжет: хочется перейти с RPA на полноценный программный интерфейс, но пока не получается: OpenAI либо предлагают чистое программирование, либо чистую пользовательскую работу, но не поддерживают сценарий “люди и роботы работают над проектом в едином интерфейсе приложения”. Ничего, и тут прорвёмся, ситуация с инструментарием меняется ежедневно. Пока же – работаем через RPA и тестируем CodexSublime.
Если теперь посмотреть за окошко, то там настоящий киберпанк: на всё интересное и приятное своя доза перехода к каменному веку. “Бомбить Воронеж” – помните такое? Основной мессенджер, на который пересаживаются сейчас в России, это электронная почта. Забыли про такое? А она есть, и она работает! Если у вас, конечно, не выключен интернет, чтобы быть ещё ближе к каменному веку. Вчера я слышал жалобу, что надо было отправить картинку в центре Москвы, и был вспомнен MMS (multimedia messaging service – помните такой?). Картинку таки удалось отправить, и она была получена! Я оцениваю это разрушение технологического уклада “ради безопасности” сугубо отрицательно. Кто-нибудь считал масштабы этого бедствия? Я сам консеквенциалист: опасность, от которой спасаются, должна стоить дороже, чем опасность, привносимая спасением – головную боль нельзя лечить усекновением головы. Если опасность “развалить нормальную жизнь 1000 человек”, то нельзя лечить её разваливанием нормальной жизни 1000000 человек. Если этот развал – “выполнение требований законодательства”, то святая обязанность – изменить это законодательство, а не требовать исполнения его любой ценой. Я слишком много провёл времени в Думе, чтобы не помнить ровно вот это: если надо выполнять закон, но это разрушительно и нелогично, то надо не выполнять закон – надо срочно и пожарно менять закон, сразу в трёх чтениях принимать патч к закону. Хотя о каком правовом государстве мы говорим? Деонтика – она не про право, она про выполнение догматов веры, даже ценой развала нормальной жизни миллиона человек, сотни миллионов человек, да хоть всей планеты! Разруха прежде всего в головах – а потом ты вдруг обнаруживаешь, что у тебя в центре Москвы нет нормальной связи, разве что SMS и телефон, и современную связную инфраструктуру не разбомбили враги, а вроде как для твоего же счастья хладнокровно выключили “наши”. Ещё обсуждается регулирование AI, где всё то же самое: “только на отечественных серверах и после проверок нашими уполномоченными сотрудниками на верность текущей партии и текущему правительству”, но я очень надеюсь на доступ к самым сильным на планете AI-агентам, а не к самым импортзамещённым. Я ведь космополит, для меня Родина – планета Земля, а если обнаружат ещё и братьев по разуму-инопланетян, то Родиной будет какой-нибудь галактический кластер – ничего святого. И да, я ещё и трансгуманист – люди являются случайными носителями мышления. И либертарианец, тоже небольшой секрет. Какой мой совет в текущей ситуации? Он всё тот же, шифропанковский (о, я действительно такой древний): “не пишите законы, пишите код”, и как я заметил ещё 10 лет назад – “и обучайте код” (Не пишите законы, пишите код. И обучайте код.: ailev — ЖЖ, там прямо в заголовке). Там был прогноз: “Года через три машинный интеллект будет находить проблемы в текущем корпусе законов не хуже, чем студент-первокурсник юрфака, а лет через пять это будет уже третьекурсник. Через десять лет машинный интеллект с этой кодификацией и сам справится”. Да, я думаю, что сейчас как раз прошло 10 лет и машинный интеллект вполне с этой кодификацией и сам справится, ровно поэтому его и хотят сделать строго лицензируемым, чтобы кодификация была не рациональной, а лояльной. Но нет, этого джинна в бутылке не упрячешь. Так что – не пишите законы, пишите код. И обучайте код. Пожелаем творческих успехов команде Telegram: они один раз уже выиграли у разрушителей коммуникации, и я очень надеюсь, что и сейчас выиграют. Разрушение линий связи “дружественным огнём” не пройдёт! Заодно – я не возражаю, чтобы мои персональные данные хранились хоть на серверах другой страны, хоть в космосе на нейтральной Луне. При этом я верю далёким партиям и правительствам ровно настолько же, насколько местным, московским, то есть не верю: они разрушают линии связи со своей стороны точно так же, и цензура у них тоже будь здоров. Поэтому повторюсь: не пишите законы, от страны это не зависит, пишите код – это надёжней. И обучайте код.
Пока же мой узкий участок нанесения непоправимой пользы человечеству – вот этот самый FPF, GitHub - ailev/FPF: First Principle Framework · GitHub, где сейчас 271 stars и 47 forks. Я пишу код, уж как могу. Следующий семинар на базе FPF я буду делать 12 апреля 2026. Посвящу его управлению точностью языка в рабочих проектах. Ведь одна из задач инженера-менеджера – договорить всех вокруг себя. Как раз я эту semio-часть планирую к семинару закончить, расскажу про всё новое, что там появилось.
