Что приятно: наши реформаторы никуда не делись, они с нами!
Вчера провёл семинар “Развитие для развитых”, а сегодня ещё и полдня чатился с участниками в чате семинара – написал в чат много страниц ответов на вопросы.
Удивила большая активность наших реформаторов (и они же – собственники предприятий), их оказалось добрый десяток среди более чем 60 участников семинара. Они проходили у меня какие-то ранние версии “Системного менеджмента и стратегирования” ещё в виде курсов, часто даже делали пару проходов. Какая там причинность – самые успешные инженеры-менеджеры делают больше проходов по резидентурам, чем не самые успешные? Или наоборот, кто делает больше проходов по нашим резидентурам, те и становятся самыми успешными? Мне это неведомо, но корреляция есть!
Вячеслав Кунин даже сделал для лучшего усвоения материала семинара пересказ его основных положений, проиллюстрировав несколькими картинками из слайдов: https://medium.com/@veaceslavcunev/инженерия-в-2026-когда-решения-дешевы-а-проблемы-бесценны-05c5d0a6ffbd. Слайды про “оргразвитие”, когда “развиваем уже развитое предприятие и уже развитых сотрудников” – это же как раз для них! Выбор целевой системы – это же как раз для них!
Новый вид продукта: слайдомент семинара. Использовать как LLM+FPF+слайдомент.
Участники семинара унесли не только видео, но и слайдомент, который надо грузить в LLM вместе с FPF (они согласованы!) – и затем материал семинара оказывается поддержанным неестественным интеллектом, который можно просить выполнить шаги описанных в семинаре рабочих процессов развития в целом, проблематизации в ходе развития, характеризации в ходе проблематизации. Опыт нового типа продукта – и он вполне успешен! В чате уже была демонстрация “ответ vanilla LLM” против “ответ LLM+FPF+слайдомент семинара” с указанием проблем от использования AHP (Метод анализа иерархий — Википедия ) вместо работы с Парето-фронтом и novelty-quality-diversity. Так что теперь у меня два типа LLM-ориентированных продуктов, которые также могут читаться людьми:
– First principle framework (FPF, GitHub - ailev/FPF: First Principle Framework), и тут вроде всё ясно.
– MVP по некоторым совсем свежим темам в формате слайдомента для моего семинара. Удивительно, но это работает! Но доступно только участникам семинара (перевожу: оплатившим за попадание в чат семинара). А что будет не MVP? Ну, потом я просто включу это в состав FPF, планы на эту тему были в Начинаем февраль 2026: громадьё планов по FPF: ailev — ЖЖ
Например, мы поглядели в чате пример (один из участников использовал этот метод, подтвердил, что были все указанные проблемы) такого промпта: “У тебя спецификация FPF в файле, а также слайды семинара по развитию для развитых. Там описана многокритериальная оптимизация с учётом novelty, diversity и quality для портфеля индикаторов - с тем, чтобы выбирать какие-то точки на Парето-фронте. Объясни, какие достоинства и недостатки использования в качестве selector метода Метод анализа иерархий — Википедия. Скажем, мы берём четыре критерия и применяем AHP, не обсуждая Парето-фронт, доминирование и всё остальное из алгоритмов open-ended evolution. Какие могут быть проблемы?”
Конечно, это “человекочитаемый слайдомент”, и в этом слайдоменте очень много красивых картинок. Но это не слайды, ибо слайды – не конспект, а у меня слайдомент – это ещё и подробный конспект. А также учебник. А также может использоваться в работе вот прямо сразу, в первый же день.
Как использовать в работе LLM+FPF+слайдомент семинара? Например, поручать адаптировать и заполнять концептуальные шаблоны, которые были в материалах семинара. Обычный аргумент против системной инженерии: “да, проблем вроде должно быть меньше, но эта ваша системная инженерия – это огромный накладной расход, вместо того чтобы принимать инженерные решения мы занимаемся этим вашим управлением конфигурацией, инженерными обоснованиями с разработкой программ испытаний. Нет, мы не будем всего этого делать!”. Мой ответ на это – вот эту рутинную часть можно (и нужно!) сдвигать на неестественный интеллект. Если надо адаптировать какой-то концептуальный шаблон (карточку, табличку) к вашей ситуации – можно просить неестественный интеллект помочь это сделать. Более того, можно просить этот неестественный интеллект помогать заполнять! И тут, конечно, нужен глаз да глаз.
Развитие для развитых: проблемы, решения, архивы, портфели
Нет пророка в своём отечестве, но по теме семинара отписалось множество AI-блогеров (они с этим столкнулись первыми, а до остальных очень быстро докатится). Писали вот прямо вчера-сегодня. Но у них конкретизации нет, что дальше, а у нас на семинаре она была! Надо стать не просто “менеджерами агентов”, а “инженерами-менеджерами”, подойти к менеджерским задачам инженерно – и учиться работать с проблемами, которые надо решать, как first class сущностью, перестать возиться только с решениями проблем. Например:
– “человек с идеями теряется – у него впервые в истории ИТ развязаны руки, он перепробовав всё, не знает из чего выбрать, потому что идей, впервые, не больше чем ресурсов”, это вчера в Telegram: View @denissexy
– “Теперь, вместо инженеров, все мы будем скорее решателями вопросиков, менеджерами, если хотите, для своего кодингового агента”, это сегодня в Telegram: View @knowledge_accumulator.
– если раньше бутылочное горлышко в разработке новых продуктов (в том числе с LLM под капотом) было в разработчиках, то сейчас оно в product managers и engineering leads (не путаем их с бесполезным middle-management в корпорациях). Первые могут нащупать “Что нам нужно делать следующим шагом”, а вторые “Как это реализовать эффективнее всего”, это три дня назад в Telegram: View @llm_under_hood.
– “прожив два месяца с claude code на opus4.5 могу сказать что это ощущается как реальный мидл mle(хороший) причем готовый в три ночи идти писать и ставить метод который я придумал и к утру получить результат”, это пару дней назад Telegram: View @lovedeathtransformers
– … и такого много. Это докатится до других инженерных специальностей очень быстро. Экспоненты, они такие. Всё-таки мы вот прямо сейчас наблюдаем всполохи технологической сингулярности во всех возможных разных трактовках того, что это такое. Восторг.
На семинаре стало понятно, что именно вызывает трудности, что является контринтуитивным. К этим мыслям надо “привыкать”, ибо язык и привычки мышления долго ещё не будут отпускать:
– если у вас один вариант чего бы то ни было, то это неправильно. Мышление по умолчанию должно быть архивами-портфелями, а “один вариант” должен восприниматься как исключение, а не норма. Архив – это всё, что рассматривали, проверяли, видели (память + следы причин). Портфель – это выбранное на период (ставки/фокус/бюджет/ответственные). Откуда “период”? Так цикл же! См. например, материал по ссылке на руководство по системному менеджменту, там про цели, стратегирование и циклы (я приводил эту ссылку в чате семинара: Aisystant), там сразу начинается: “Вся деятельность организации глубоко ритмична. Если вы не замечаете повторения у себя каких-то действий во времени (паттернов во времени/ритмов/циклов/cadence), вы что-то делаете не так. Есть два основных метода планирования неожиданных работ:” и дальше про “по прерыванию” и “по опросу”, и вот в “по опросу” важно иметь small batch size для того, чтобы успевать, и короткий цикл. И вот на этот короткий цикл должен быть “портфель”, а не какой-то скаляр. Мы, кстати, говорили о том, что цикл ускоряется – и в алгоритмическом трейдинге это уже не трейдер принимает решение, а программа, ибо трейдер с миллисекундными скоростями не работает. Понятно, что так быстро крутить цикл проблем-решений довольно быстро будет уже не человек, человек не справится.
– если у вас задача выбора, то надо думать о Парето-фронте, а не о скаляре-рейтинге
– чтобы думать о Парето-фронте, надо думать об индикаторизации (и портфеле характеристик-индикаторов), запрет иметь какой-нибудь скаляр-рейтинг (ладно, не запрет – но это должен быть явный шаг, и его надо обосновать, ибо проблемы этого шага хорошо известны).
– Нельзя думать только об индикаторах (оптимизируемых величинах), ибо у вас всё развалится на чём-нибудь ещё. И помнить о законе Гудхарта, Goodhart's law - Wikipedia
– характеризация, индикаторизация, нормализация, скоринг, свёртка (агрегация разных показателей в один), сравнение, выбор. Если “выбрать лучшее” – это конец очень длинной цепочки.
– novelty – это tie-breaker, а на stepping stone с этой novelty закладываем долю бюджета: нужно для выхода из локального минимума.
– надо выбирать goldilock проблемы, а ещё профи-глаз видит проблемы там, где новичок никаких проблем не видит (подумалось, что это что-то типа “А чо такова?” Пока слышим "а чо такова?", обучения практикам мышления не будет: ailev — ЖЖ. Но тут немного другой вариант. Как-то университет снял ростовский ледовый дворец для университетского фестиваля. И я там был среди участников, принёс качественную фонограмму на магнитной ленте. Местный звукооператор послушал её – и сказал, что ставить её не будет, ибо там проблемы с качеством. И для любительства в университетской художественной самодеятельности это качество сойдёт, а у него много тысяч человек и профессионализм не позволяет ему такое качество лить в уши тысячам людей. А я, студент, тогда даже понять не мог – что ему не понравилось то? Фонограмма была очень высокого качества, не пятая или седьмая перезапись, а всего третья! Вот это оно и есть: вам говорят, что “вашим интерфейсом невозможно пользоваться”, а вы говорите, “да шикарный интерфейс!”, глаз не замечает проблем).
– проблемы тоже надо как-то выражать: это делается через портфель индикаторов и критерии приёмки, которые задают “как мы узнаем, что проблема решена”. Сказать “решил проблему” или “не решил проблему” – это результат “измерения решения”, а измерение – это ведь “сравнение”, приёмка делается сравнением по набору характеристик.
– если ты занимаешься инженерным процессом, то включи в него то, с чего там раньше всё начиналось: откуда взялись проблемы, которые решают разработчики. Втащи генерацию проблем внутрь процесса, поддержи инструментально, без этого у тебя не развитие, а “решение кем-то поставленных проблем” (то есть ты чей-то агент, а не принципал).
– … и тут я понимаю, что в наших руководствах всего этого очень не хватает. В FPF это есть, но не подробно. В слайдоменте семинара есть, но чтобы научиться надо взять LLM+FPF+слайдомент семинара и попросить научить до такой степени, чтобы самому всё вот это отслеживать. Дальше я это засуну в FPF в более чётком виде, дальше я сделаю новый набор руководств, чтобы перепрошивать мозг инженеров-менеджеров на это новое мышление о проблемах и характеризации. И когда-нибудь будет клипса-наушник с LLM+FPF в ухе, которая будет шептать тебе на ухо про то, что “что же ты опять взял первый пришедший в голову вариант, что же ты не подумал, какие там вообще характеристики нужны”.
Последний текст, который я закинул в чат семинара – это текст про NQD-генерирование шуток, я писал об этом в lytdybr: ailev — ЖЖ (после семинара этот пример смотрится совсем другими глазами. Но в этом-то и задумка, чтобы поменять мышление, выработать другой взгляд на мир!).
Новая компьютерная грамотность: какие кнопки нажимать в интерфейсе AI-ассистента
Но неожиданно на семинаре было то, что я для себя назвал “проблемой новой компьютерной грамотности”. На предыдущих двух семинарах с LLM все как-то умели работать, а тут пришло больше “просто инженеров и просто собственников предприятий” – и выяснилось, что понимание фразы “загрузите файлы FPF+слайдомент семинара” отсутствует у очень и очень многих, причём на уровне компьютерной грамотности: “не понимаю, какие кнопочки в каком приложении нажимать, чтобы загрузить файл правильно”. Обычно проблемами вроде “ой, я ничего не делала, а файл исчез” занимаются в офисах эникейщики, квалификация, когда такого не происходит и эникейщик не нужен – “продвинутый пользователь” (то есть “могу поменять стиль абзаца в Ворде и написать формулу для Excel”). Но тут появился новый класс приложений – и всё, “продвинутый пользователь LLM” оказалось вполне себе навыком. Проблема тут в том, что кнопочки для Linux, Windows, iOS, Android все разные – и если вместо семинара по развитию отвечать, что “открыть файл в RAG в вашей системе делается вот так, а в вашем приложении вот сяк”, то “продвинутые пользователи” будут бузить “где тут тема развития? зачем мы обсуждаем, как работать с LLM?”, а непонимающие им будут отвечать “так нам говорят использовать AI, но почему не учат сразу? Непонятно, объясните!”. А я как хотел? Я хотел (и продолжаю хотеть) независимости изложения содержания от конкретной операционной системы и выбранного там приложения. Но для этого надо, чтобы участники семинара все понимали “загрузить файл в RAG” против “загрузить текст в контекст”. Обидно тратить каждый раз время на объяснение, что не надо упихивать 4MB файл FPF, а ещё и слайдомент семинара в контекст! Их надо грузить как файлы! И проблема в том, что кнопочки для этого у каждого участника свои, и их надо знать! Компьютерная грамотность, дьявол побери! Она сегодня включает умение подгрузить файл в AI-ассистента!
Скажем, вот этот фрагмент был крайне труден в понимании, если нет опыта пользователя чатбота вроде ChatGPT, Gemini или Claude. Я работаю через многократный цикл edit-regenerate первого сообщения, поэтому у меня очень короткие чаты (и их много), а не длинные чаты, которых мало. В web-интерфейсе есть “поле промпта”, и у меня чаще всего чат состоит из всего двух реплик “моя реплика” (в поле промпта) и “ответ сетки”. И я просто редактирую текущее содержание “моей реплики” (затирая старое и помещая новое) на основе предыдущего “ответа сетки” (а не веду длинный разговор на много реплик). Например, после ответа сетки в ответ на мой промпт “сгенерируй A” я просто беру этот ответ и редактирую свой этот промпт “сгенерируй A”, заменяя на “я сгенерировал A, он в тексте ниже. Проверь, по итогам проверки выдай правки на английском в unified diff в code block в четырёх backticks. Вот A: [и дальше просто копия того, что выдала сетка в предыдущем такте]”. Пока сетка думает, я копирую этот свой промпт “я написал A, проверь, выдай diff, вот A” в редактор. Сетка в ответ выдаёт diff, и я его накатываю в редакторе на этот A, получив следующую версию. И тут же заменяю промпт на текст из редактора (с уже накаченным diff от предыдущих исправлений, а промпт “я сгенерировал, проверь, выдай дифф” не трогаю вообще). В результате у меня в любой момент времени “один промпт” и “один ответ сетки”, один рабочий текст в редакторе, при этом генерация идёт один раз, а затем три раза (или десять раз, по вкусу) идут уточнения при проверке — но результат накапливается в редакторе, в ответах сети только diff-файлы, а не “переписанный текст после правок”. Засада в том, что кнопочки у каждого провайдера по смыслу те же, а места кнопочек и особенности поведения — разные, поэтому скриншоты моей работы с одним из приложений не помогут справиться с другим приложением.
Развитие — это циклы постановки проблемы и непрерывных улучшений найденных решений. Я описываю в своей работе, что генерирую текст паттерна FPF, а затем три раза подряд прошу исправить в нём ошибки. Получается текст паттерна, в котором три раза проверены возможные ошибки — и исправлены. Если ошибка в том, что что-то важное недосказано, это ведь тоже “исправление ошибки”. В итоге паттерн часто из 20К знаков после исправления ошибок становится 30К знаков. И если там были какие-то “галлюцинации нейросети” в свежесгенерированной версии, то многие из них будут исправлены. Что тут необычного:
— не увеличивается длина диалога (грубо говоря, в чате всегда один ход диалога, ибо я переписываю первый же промпт), поэтому не растёт контекст. Это достигается сменой промпта с “сгенерируй” на “я сгенерировал, проверь и предложи правки”
— нейросеть не накатывает правки сама (не переписывает текст), что много точнее и удобней. Сеть делает только правки в формате diff.
— не “сгенерировал — проверил и исправил”, а “сгенерировал — проверил и исправил, проверил и исправил, проверил и исправил” (мало кто догадывается делать проверку и исправление несколько раз).
Вот и всё, ничего больше. Но вот эти шаги “сгенерировал, затем проверил и исправил, затем проверил и исправил, затем проверил и исправил” оказываются почему-то труднопонимаемыми – и почему я так делаю, и какие кнопки нажимаю, и как можно это всё адаптировать, и в очередной раз – почему я не пишу сборник промптов для FPF (почему для разговоров с начальником или разговоров с супругой нет сборника промптов понятно, а почему для разговора о мышлении нужен сборник промптов? Сборник промптов по управлению крупным предприятием? Сборник промптов “как стать миллионером”? Откуда вообще идея?!).
На картинке часть собравшихся в нашем офисе на Таганке в Москве:
