Развитие для развитых -- это SoTA инженерии личности

ailev · 16.Январь.2026 10:52:11

Как я понял, что шедевры создаются множеством мелких изменений
Идея, что “расстояние в тысячу ли покрывается крошечными шагами, если ты их делаешь и не слишком плутаешь” – она контринтуитивна. Я своим постом хочу показать, когда и как я осознал, что шедевры делаются как сумма микропоправок, каждая из которых кажется незначительной, а вовсе не “чётких нескольких крупных действий”, с “драматически заметными” результатами каждого действия. Затем я покажу, что AI-агенты идут ровно по этому маршруту: каждое их действие тупое, маленькое, сомнительное – но если этих действий много, то в результате тоже будет шедевр, что тоже контринтуитивно, как и в случае людей. Это можно считать “внутренним циклом бесконечных улучшений”, это “база”, а не SoTA. Затем я покажу, что “просто много пилить в цикле” недостаточно – и появятся новые слова про open-endedness, Парето-фронт и характеризацию как внешний цикл пересборки целей и отслеживания результатов “непрерывного пиления по чуть-чуть”, а также изменения способов этого непрерывного улучшения. Это всё приложимо и к людям: если взять инженерию личности, то такой подход и будет “развитием для развитых”.

Для себя я рецепт создания шедевра (во всех смыслах этого слова, начиная с “выпускной работы мастера” и заканчивая “SoTA среди подобных”) в явном виде отмоделировал, когда смотрел за работой режиссёра. В 1982 году по приглашению Юрия Попова я поставил танцы в спектакле ростовского ТЮЗа “451° по Фаренгейту” (https://ru.wikipedia.org/wiki/Попов,_Юрий_Борисович ). Спектакль получился весёлый, жанр был заявлен как “фантазия в стиле диско” – поэтому и танцы. Но там кроме режиссёра Попова был ещё и режиссёр Вячеслав Гвоздков (Гвоздков, Вячеслав Алексеевич — Википедия ), на примере которого я наблюдал, как создаётся хороший театральный спектакль.

Тут, конечно, сыграло ещё и то, что у меня был опыт собственной постановки небольших спектаклей – я поставил парочку 20-минутных студенческих рок-балетов на музыку произведений Deep Purple с симфоническим оркестром на университетских фестивалях. Там я делал по факту то же самое, но я ведь не считал это “методом работы”! До понимания понятия “метод” в полной мере у меня было ещё много десятков лет. Так что я в своих режиссёрских работах не видел никакого метода, а я ведь уже работал в ВЦ РГУ и уже очень интересовался методологией, у меня рабочим заданием было как раз “описать деятельность”.

От “маститого приезжего режиссёра” я ожидал метода – что-то типа “системы Станиславского”, и это должно было быть видным. Но нет, ничего такого: после выучивания ролей шёл многократный прогон (так и называлось, от “повторение” – репетиция) на сцене. Режиссёр сидел в пустом зале и выдавал по ходу прогона замечания: вот тут у тебя интонация должна быть другой, вот тут надо для усиления эффекта оказаться вот в этом месте сцены и многозначительно подержать паузу, вот тут надо обязательно уходить за кулисы быстро, вот тут … это было бесконечно, неделя за неделей, месяц за месяцем. Это было главным отличием от моей любительщины: я правил только самое ужасное, а прогонов было немного. Тут прогонов было до чёртиков, правилось вообще всё, даже не самое ужасное, правилось даже вполне приличное – но приличное на мой непросвещённый взгляд. Для Гвоздкова это было “неприличное”, по его стандартам качества было – “надо менять”!

Мне казалось, что работал генератор случайных режиссёрских действий: несколько раз в неделю шла репетиция, мне было любопытно, пропуск в театр у меня был, и я наблюдал за там происходящим в самое интересное время: смотрел на то, как спектакли не играются, а делаются, недоступное обычным зрителям! На выпуске к зрителю получался спектакль, который отличался от начального прогона как небо от земли: не было ни одной секунды, которая не была бы “сделана”, а не случайно получилась из взаимодействия из самих по себе хороших актёров. И тут я и впрямь смекнул, что это и есть метод: пилить рашпилем, а потом надфилем, потом полировать, а потом опять рашпилем – и это бесконечно. Размер имеет значение, и это – размер деятельности, число сделанных улучшений! Через некоторое (большое!) время, если у тебя хватает терпения пилить-полировать, ты получаешь шикарный результат. Качество – это покрытие вниманием: в хорошем спектакле нет ничего непродуманного! Каждая секунда улучшена, нет никакого “так уж получилось”!

Другие способов получить высокое качество нет: только быть внимательным к проблемам (даже таким, которые другие люди не замечают) и делать множество мелких улучшений для решения этих проблем. Например, “продумать и собрать по продуманному в несколько шагов” – качества не будет. С запуска свежесобранного вот эта “доработка по месту напильником” только начинается! Более того: проектировать – это так же, “пилить рашпилем, затем надфилем, затем полировать”, и так до бесконечности.

Это всё я понял задолго до победы agile сначала в программировании, а потом и везде, ибо там была примерно та же идеология: заменить пошаговый инженерный процесс бесконечным циклом. И старался часто применять в жизни. Например, в 1987 году я придумал турнир по брейк-дансу для юга СССР (нет, не России, тогда принадлежность республикам мало кого интересовала, национализмом и не пахло). Первый же турнир прошёл плохо: оказалось, что этих брейк-дансов множество подстилей (мы насчитали тогда четыре) и судьям было невозможно работать, ибо в одном заходе встречались в сравнении танцоры разных стилей. Поскольку в этот момент я уже осознанно понимал этот “метод бесконечного улучшения”, то я просто записал на бумажке основные проблемы. И мы объявили проведение следующего турнира, в котором эти проблемы были учтены. Всё прошло много лучше! Таких турниров я провёл четыре подряд, на четвёртом турнире уже был оглушительный успех, приехало больше сотни тогдашних брейкеров, было множество зрителей, был и финансовый успех – метод “бесконечного развития” работал. И всё это прекратилось, потому что именно в 1987 году я переехал в Москву и мне стало совсем не до танцев: уже полным ходом шла перестройка.

В Москве в 1991 году я начал проводить тусовки тогдашнего финтеха (“инфраструктура рынка ценных бумаг”: депозитарии и регистраторы) в пансионате “Юность” – тем же методом: совершенствуем сначала крупное, затем всё более и более мелкое, причём не останавливаемся. И провёл их раз в полгода 11 штук, удерживая каждый раз некоторый чеклист – и улучшая его положения. Этот чеклист в варианте на начало 1994 года даже сохранился – Заметки по организации рабочих встреч (или "О душевных обсуждениях") - Часть III. Немного проектов и ноу-хау - Как это делается: финансовые, социальные и информационные технологии (сборник статей) - Книги и сборники - Библиотечка Либертариума - Московский Либертариум (и в этом же сборнике есть и моя вторая методологическая работа, “Как сделать модель полезной пользователю?” – Как сделать модель полезной пользователю? - Часть III. Немного проектов и ноу-хау - Как это делается: финансовые, социальные и информационные технологии (сборник статей) - Книги и сборники - Библиотечка Либертариума - Московский Либертариум, “в данной статье описывается технология создания учебных курсов на базе имитационных программных моделей предметных областей. Впрочем, большая часть того, что будет сказано, относится и к созданию обычных руководств пользователя”. И там дальше про роли, а также понятизацию. Это к вопросу об удерживании некоторой тематики в деятельности десятки лет, при этом мастерство растёт, но проекты всё время менялись, это не было “меднолобым фанатизмом удержания мечты”!).

Современный инженерный процесс – это много-много мелких улучшений, непрерывное совершенствование
Сегодня ничего не изменилось: я пилю FPF, имея некоторый длинный список того, что я считаю недостатком – и делаю это крайне нудно, рутинно, надеясь получить тот самый шедевр. Летом там всё было ужас-ужас-ужас, осенью ужас-ужас и началось использование, сейчас просто ужас – и мне уже шлют благодарности. Вот GitHub этого проекта: GitHub - ailev/FPF: First Principle Framework – и обратите внимание, что большинство проектов в GitHub ровно так и делают: непрерывно улучшают выложенные туда коды. У кого хватает сил и умения сохранить evolvability, терпения вести проект десяток лет – тот добивается результатов. У кого не хватает такого умения – ну штош.

Дальше всё зависит от того, сколько времени вы можете продержаться в этом цикле:
– насколько полезен ваш продукт и хороша бизнес-модель (монетизация), чтобы оплачивать этот цикл долго
– насколько у вас хватает терпения “пилить” (удерживать себя в этом цикле годы и годы) и умения “пилить” (умения найти проблемы, умения решить проблемы, умения удержать архитектуру evolvable)

Сегодня такой способ разработки отслежен и описан, а также стандартизован в его разнообразии. Он называется “инженерный процесс”, и никакого тебе “жизненного цикла”, но бесконечная эволюция продукта, ведомая а) текущим кумулятивным результатом решения предыдущих проблем (проектом, чеклистом) и б) после каждого запуска списком обнаруживаемых новых проблем, “телеметрия” (сбор данных об использовании) и анализ проблем, даже если эти проблемы труднозаметны. Найти новую проблему (даже когда всё хорошо), отразить в продукте – выдать в пользование, вернуться в цикл. Репетиционная доводка спектакля до выпуска, PDCA, kaizen, POOGI, ATDD, continuous improvement. Это “база”, это не SoTA. Это то, что надо осознать, и не откатываться в прошлое.

“База” агентов: автоматизируем “непрерывные улучшения”. Удивительно, но это работает!
Современные системы с агентами идут по этому же пути, исключая человека как организатора цикла непрерывного “пиления” маленькими улучшениями. Вот как выглядит “современнейший инженерный процесс” в его описании в форме промпта для LLM-агента (Telegram: View @llm_under_hood):
(1) запусти скрипт make test, оно протестирует твой код, выдаст ошибки и выдаст score (изначально кода нет совсем, поэтому и тестер выдает 0%)
(2) изучи код вдумчиво и найди, чего не хватает
(3) предложи мне минимальное изменение, которое максимально увеличивает score

Это автор промпта описывает как “снова и снова копипастой отправлял с телефона задание”. Тест – это те самые “найденные проблемы”, у него было 235 готовых тестов.

Дорого ли это? Да, такие циклы “едят токены как не в себя”. Но вопрос: работает ли? Да! Ключевое: “найди, чего не хватает и дай минимальное изменение/diff к текущему описанию системы, которое максимально увеличивает число решённых проблем”.

Предыдущий пример с “запусти скрипт make test” был попыткой воспроизведения результата Cursor, который сделали конвейер из а) постановщиков задач б) исполнителей. И поручили написать браузер, весьма сложную программу, которую написать не всякая фирма возьмётся. Тут, конечно, та же ситуация: браузер должен пройти чеклист/тесты, который заранее готов и не меняется. Войны браузеров конца 90х на них нет! Вот пост об этом: https://cursor.com/blog/scaling-agents. Почему удалось? Ключевое: потому что агенты продержались аж неделю автономной работы, не теряя цели! Почему раньше не получалось такое сделать? Потому что так долго без потери цели не удавалось продержаться с прежними поколениями моделей (что с них возьмёшь, дети ещё! Хотели получить интеллект “хотя бы ребёнка” – вот, со всеми недостатками, включая недержание внимания. Ибо внимание удерживают письменно, во внешней памяти!). Итак, добавили память (кодовая база, задания, патчи), а ещё взяли GPT-5.2, которая вот в таких длинных проектах оказывается надёжней, чем варианты Claude (вот комментарий по-русски: Telegram: View @seeallochnaya).

И таких примеров тьма:
– берём набор eval/тестов
– делаем хоть что-то
– крутим цикл “проверь, предложи изменения, чтобы поднять скор”
– когда скор высок, остановись и скажи

Одного цикла непрерывного совершенствования недостаточно, это не передний край
Чего не хватает в этом базовом подходе “пилить, пока не перепилишь”? Очень многого! “Улучшай, пока не пройдёшь тесты” – это статическая (как будто мир неизменен! никакой эволюции!) локальная оптимизация по одной характеристике – скор прохождения тестов. Но сведение множества характеристик к одному скору/рейтингу – это уже не передний край, не SoTA. Вы теряете важнейшую информацию, оптимизация должна быть многокритериальной! Надо рулить постановкой целей, конфликтами значений разных характеристик, популяционными эффектами, измеримостью того, что вы делаете и воспроизводимостью оценок, а ещё самим инженерным процессом.

Вот чего не хватает:

Отношения к набору тестов, использованному автором, как к полноценному описанию целевой системы: просто это другой viewpoint, нежели “описание кодом”. И понимания, что меняется набор тестов, описывающий проблему, поэтому нет для этого набора “идеального решения”, поскольку у нас не “идеальная статичная проблема”: она обычно в этом наборе тестов плохо сформулирована (тестируется не то, не тогда), а также изменяется со временем по мере понимания того, что же там не работает. И ещё “разработчики” (живые и не очень) любят закон Гудхарда: оптимизирование чего угодно за счёт проседания важной, но не указанной явно характеристики (reward hacking). В цикле тем самым надо заниматься ещё и постановкой задачи, проблематизацией. Инженерный процесс (алгоритм “цикла разработки”) при этом сразу становится более хитрым, примеры смотри в работах вроде Paired Open-Ended Trailblazer (POET) – [1901.01753] Paired Open-Ended Trailblazer (POET): Endlessly Generating Increasingly Complex and Diverse Learning Environments and Their Solutions, Enhanced POET – [2003.08536] Enhanced POET: Open-Ended Reinforcement Learning through Unbounded Invention of Learning Challenges and their Solutions, LLM-POET [2406.04663] LLM-POET: Evolving Complex Environments using Large Language Models). Целевая система может тогда отэволюционировать к тем областям пространства решений, куда она иным способом попасть не может. И это – принципиально. Проблематизация (острый глаз, который замечает проблему и может её описать точным языком, формализация там только один из шагов в повышении точности языка – ML.3 - Измеримый порог надёжного вывода для LLM-систем: ailev — ЖЖ), она же в других тусовках “постановка задачи”, она же в быту разработчиков “отдадим это аналитикам, маркетологам, кому угодно” (это ведь тоже проблема – “отдать часть инженерного процесса”, вывести за пределы разработки!) оказывается существенной частью инженерного процесса. И вот так мы перешли тут к open-endedness и разным алгоритмам в этой предметной области развития чего бы то ни было (open-endedness – Открытость (open-endedness): понятие шире, чем эволюция: ailev — ЖЖ).
Невозможность удержания всех traits/features на максимуме ввиду неизбежных конфликтов: в разработке надо или говорить о портфеле (если у вас хватит ресурсов), или выбирать точку на Парето-фронте – или сдвигать этот Парето-фронт, если сможете (вот я говорил об этом в “Проблемы пузомерок для AI-болванов” – Проблемы пузомерок для AI-болванов: ailev — ЖЖ). Если все эти слова про Парето-фронт и портфель незнакомы, то всё, приехали – в конкуренции вы будете участвовать “по наитию”, а дальше как у древних инженеров, “иногда срабатывает, а иногда нет – и чёрт его знает, почему, эту науку ещё не придумали”. Вас в конечном итоге интересует не “прохождение тестов/соответствие описанию”, а “соответствие/fit окружению”, при этом ещё и окружение тоже меняется. Но да, у нас же это проблемы не разработчиков, а аналитиков (они же не инженеры, а “предлагатели инженерам”), менеджеров (они же в разработке ничего не понимают!), маркетологов (вечно хотят невозможного! Хотя у конкурентов почему-то возможного).
Современным подходам к эволюции, которые заставляют отслеживать эволюцию популяции (fitness landscape - это про популяцию), а не одного организма, а также отслеживать эволюцию системы разработки в её влиянии на целевую систему (в нашем случае учитывать эволюцию инженерного процесса, эволюцию разработчиков и их знаний), а также Это eco-evo-devo (вот я писал " Как связаны инженерия и теория эволюции: инженерия нейросеток как eco-evo-devo", Как связаны инженерия и теория эволюции: инженерия нейросеток как eco-evo-devo.: ailev — ЖЖ). Вот эта эволюция от POET к Enhanced POET – это ведь тоже эволюция! Эволюция эволюции нас тоже интересует, ибо если наша эволюция быстрее, чем эволюция конкурентов – мы выиграли!
Характеризация и воспроизводимая оценка. В исследованиях по AI говорится, что наибольший прогресс в AI достигается в областях, где надо долго биться над решением проблемы, при этом проверить решение очень легко: запустить несложный текст. Дальше “долго ищем решение, быстро проверяем, достигнуто ли решение”. В какой-то мере это как криптография, “майнинг” – вы долго ищете ключ, но если уж нашли, то вы сразу об этом узнаете. Математическая задачка: долго ищем решение, но если доказательство есть, то это легко проверить. В жизни большинство проблем вы не можете решить так, чтобы было легко проверить – “вот, задача решена”.

Это всё, конечно, связь визионерства, архитектуры и разработки в инженерии. Только что пообсуждали это с преподами кафедры технологического предпринимательства МФТИ, там мне было предложено рассмотреть историю с размером смартфона, ответ искался в том, что плохо понятна “соразмерность с телом”. В смартфонах их “соразмерность чему-то” вопрос спорный, ибо разные размеры для разных функций, а функций много. Поэтому они обязаны были выйти на Парето-фронт размера-веса-функций, что и произошло (включая такие “смартфоны”, как iPad). Сначала (первый iPhone – 2007 год) никаких Pareto-фронтов, ибо никто о них и не думал в те времена. Телефоны были “чем лучше, тем меньше” (ибо должны были лежать в дамской сумочке, а не быть в руках). Steve Jobs сказал, что “надо, чтобы управлять смартфоном можно было одной рукой!” и поэтому размер был не “удобно для глаз”, а “дотянуться большим пальцем одной руки — и не выронить”. Samsung это просёк, и для недовольных “глаза сломаю, но одной рукой не выроню” начал выпускать “лопаты”, у Apple вышел iPad как “самая большая лопата” (и там была функция звонка!). А потом рынок “порешал” выход на Парето — чуть меньше “лопаты”, но много больше того, что предлагал Jobs, а также некоторое разнообразие других параметров.

Но потом появились статьи вроде “Multidimensional Pareto Optimization of Touchscreen Keyboards for Speed, Familiarity and Improved Spell Checking”: https://dl.acm.org/doi/epdf/10.1145/2207676.2208659, это 2012 год, и там картинки вроде этой:

Без обсуждения Парето-фронта, многокритериальной оптимизации сейчас нельзя. Любому инженеру знакомы взаимозависимости, в которых нужны очень крутые решения, чтобы выйти на новый Парето-фронт (как раз это и будут решения “лидеров рынка”. А остальные почему не умрут? Они просто максимизируют какую-то одну характеристику, чтобы быть недоминируемыми – вот эта “недоминируемость” как раз ещё один важный термин, это когда другие решения не оказываются лучше твоего по всем характеристикам, когда у тебя хоть что-то лучше конкурентов):
– скорость разработки ↔ надёжность ↔ стоимость сопровождения,
– точность ↔ задержка ↔ интерпретируемость,
– функциональность ↔ простота ↔ безопасность,
– … это можно продолжать и продолжать.

Развитие для развитых – это SoTA инженерного процесса в приложении к людям
Если считать, что личность – это “софт организма” как сумма всего мастерства, которым владеет человек (или киборг как гибрид человека и экзокортекса с его AI), то мы быстро приходим к выводу, что для инженерии личности SoTA – это всё то же самое: много-много мелких улучшений личности, но ещё и непрерывный выбор решаемых задач и поиск методов их решения – стратегирование, а ещё и “инженерия инженерии личности”, а ещё и определение пространства характеристик развития и отслеживания своей траектории в этом пространстве, насколько предсказанная отличается от желаемой и что надо поменять на основе замеренных результатов предыдущих шагов развития.

Да, “развитие для развитых” – это SoTA open-endedness в приложении к людям в их симбиозе с AI и прочими инструментами:

Мы имеем какой-то набор проблем, который вот прямо сейчас учимся решать. Дела, которые надо научиться делать, тем самым стать личностью, которой мы хотели бы стать – иметь соответствующие виды мастерства. Ключевое тут – обучение. Вот я не умею чего-то делать, вот пошёл на курсы – освоил! Если нужно уметь проектировать смартфоны – иду в вуз, там меня учат!
Но тут оказывается, что “драмкружок, кружок по фото, а ещё мне петь охота, за кружок по рисованью тоже все голосовали”. Научиться всему оказывается нельзя! Если учиться проектировать смартфоны, то ты уже не очень умеешь проектировать мосты, а с мостами – проблемы в проектировании ракет. Поэтому надо выбирать какую-то точку на Парето, чтобы быть конкурентоспособным в текущем окружении. А самые умные ещё и двигают это Парето. Вот наша Мастерская инженеров-менеджеров (МИМ) – она двигает Парето, ибо сразу идёт к изменению алгоритма развития, беря его из следующих поколений, которые недоступны пока конкурентам-“соэволюционерам”: учиться сразу системной инженерии, а не проектированию конкретных видов систем.
Современный подход к эволюции, конечно, заставляет отслеживать эволюцию не отдельной личности (человеческой или не очень человеческой, мастерство ведь решения всяких проблем есть не только у человека), а популяции. Поэтому бежим в будущее популяциями, поглядывая на traits/features друг друга и учитывая ещё и резкое изменение ситуации ввиду прихода AI. Если сосед что-то умеет, то и мне надо уметь – даже если это означает включения в состав своей личности экзокортекса с AI! А ещё надо отслеживать, что там даёт максимальную эволюционируемость, а для этого выбирать изучение мастерства, или исследование проблем которые потенциально увеличивают возможность последующих траекторий в жизни. Грубо говоря, после пятилетнего изучения системной инженерии не в режиме хобби вы дальше смело можете пойти в поэты, а вот после пятилетнего изучения поэзии не в режиме хобби – не факт, что смело сможете пойти в инженеры. Нужно уметь выбирать себе новые и новые проблемы для решения, а не долбиться веками в улучшения процесса добычи огня трением.
Конечно, хорошо бы ещё уметь обсуждать характеристики личности, что вы там в себе “развиваете”, хотя и так уже “развиты”. Как вообще измерить “развитость”, “интеллект”? Как оценить “калибр личности”? Как перейти от метафор к чему-то более точному, то есть более надёжному и воспроизводимому? Хотя что-то мы на эту тему уже знаем: например, неплохо бы отслеживать свою evolvability/развиваемость. Если утеряли возможность изменяться, то кричать “караул” – ибо это архитектурная характеристика личности, и развитие в том числе – это неутеря возможности изменяться, адаптироваться к неизбежным изменениям в окружающем мире.

Весь этот пост – моё мышление письмом, подготовка к семинару “Развитие для развитых в 2026”, он будет уже 1 февраля 2026 (Семинар "Развитие для развитых в 2026": ailev — ЖЖ). Понятно, что “надо развиваться, и делать это всё время”. Но моя задача – дать SoTA язык для того, чтобы это “развитие для развитых” обсуждать инженерно, а не “как психологи” или “как педагоги” (психологи и педагоги обо всём этом не знают, а инженеры не догадываются говорить о людях. Правда, семинар общий: развивать можно и вполне развитые системы в рабочих проектах, необязательно этот материал применять только к себе. Но знать SoTA о том, как развивать целевые системы в рабочих проектах – это тоже “развитие для развитых”).