Развитие для развитых -- это SoTA инженерии личности
Как я понял, что шедевры создаются множеством мелких изменений
Идея, что "расстояние в тысячу ли покрывается крошечными шагами, если ты их делаешь и не слишком плутаешь" -- она контринтуитивна. Я своим постом хочу показать, когда и как я осознал, что шедевры делаются как сумма микропоправок, каждая из которых кажется незначительной, а вовсе не "чётких нескольких крупных действий", с "драматически заметными" результатами каждого действия. Затем я покажу, что AI-агенты идут ровно по этому маршруту: каждое их действие тупое, маленькое, сомнительное -- но если этих действий много, то в результате тоже будет шедевр, что тоже контринтуитивно, как и в случае людей. Это можно считать "внутренним циклом бесконечных улучшений", это "база", а не SoTA. Затем я покажу, что "просто много пилить в цикле" недостаточно -- и появятся новые слова про open-endedness, Парето-фронт и характеризацию как внешний цикл пересборки целей и отслеживания результатов "непрерывного пиления по чуть-чуть", а также изменения способов этого непрерывного улучшения. Это всё приложимо и к людям: если взять инженерию личности, то такой подход и будет "развитием для развитых".
Для себя я рецепт создания шедевра (во всех смыслах этого слова, начиная с "выпускной работы мастера" и заканчивая "SoTA среди подобных") в явном виде отмоделировал, когда смотрел за работой режиссёра. В 1982 году по приглашению Юрия Попова я поставил танцы в спектакле ростовского ТЮЗа "451° по Фаренгейту" (https://ru.wikipedia.org/wiki/Попов,_Юрий_Борисович ). Спектакль получился весёлый, жанр был заявлен как "фантазия в стиле диско" -- поэтому и танцы. Но там кроме режиссёра Попова был ещё и режиссёр Вячеслав Гвоздков (https://ru.wikipedia.org/wiki/Гвоздков,_Вячеслав_Алексеевич ), на примере которого я наблюдал, как создаётся хороший театральный спектакль.
Тут, конечно, сыграло ещё и то, что у меня был опыт собственной постановки небольших спектаклей -- я поставил парочку 20-минутных студенческих рок-балетов на музыку произведений Deep Purple с симфоническим оркестром на университетских фестивалях. Там я делал по факту то же самое, но я ведь не считал это "методом работы"! До понимания понятия "метод" в полной мере у меня было ещё много десятков лет. Так что я в своих режиссёрских работах не видел никакого метода, а я ведь уже работал в ВЦ РГУ и уже очень интересовался методологией, у меня рабочим заданием было как раз "описать деятельность".
От "маститого приезжего режиссёра" я ожидал метода -- что-то типа "системы Станиславского", и это должно было быть видным. Но нет, ничего такого: после выучивания ролей шёл многократный прогон (так и называлось, от "повторение" -- репетиция) на сцене. Режиссёр сидел в пустом зале и выдавал по ходу прогона замечания: вот тут у тебя интонация должна быть другой, вот тут надо для усиления эффекта оказаться вот в этом месте сцены и многозначительно подержать паузу, вот тут надо обязательно уходить за кулисы быстро, вот тут ... это было бесконечно, неделя за неделей, месяц за месяцем. Это было главным отличием от моей любительщины: я правил только самое ужасное, а прогонов было немного. Тут прогонов было до чёртиков, правилось вообще всё, даже не самое ужасное, правилось даже вполне приличное -- но приличное на мой непросвещённый взгляд. Для Гвоздкова это было "неприличное", по его стандартам качества было -- "надо менять"!
Мне казалось, что работал генератор случайных режиссёрских действий: несколько раз в неделю шла репетиция, мне было любопытно, пропуск в театр у меня был, и я наблюдал за там происходящим в самое интересное время: смотрел на то, как спектакли не играются, а делаются, недоступное обычным зрителям! На выпуске к зрителю получался спектакль, который отличался от начального прогона как небо от земли: не было ни одной секунды, которая не была бы "сделана", а не случайно получилась из взаимодействия из самих по себе хороших актёров. И тут я и впрямь смекнул, что это и есть метод: пилить рашпилем, а потом надфилем, потом полировать, а потом опять рашпилем -- и это бесконечно. Размер имеет значение, и это -- размер деятельности, число сделанных улучшений! Через некоторое (большое!) время, если у тебя хватает терпения пилить-полировать, ты получаешь шикарный результат. Качество -- это покрытие вниманием: в хорошем спектакле нет ничего непродуманного! Каждая секунда улучшена, нет никакого "так уж получилось"!
Другие способов получить высокое качество нет: только быть внимательным к проблемам (даже таким, которые другие люди не замечают) и делать множество мелких улучшений для решения этих проблем. Например, "продумать и собрать по продуманному в несколько шагов" -- качества не будет. С запуска свежесобранного вот эта "доработка по месту напильником" только начинается! Более того: проектировать -- это так же, "пилить рашпилем, затем надфилем, затем полировать", и так до бесконечности.
Это всё я понял задолго до победы agile сначала в программировании, а потом и везде, ибо там была примерно та же идеология: заменить пошаговый инженерный процесс бесконечным циклом. И старался часто применять в жизни. Например, в 1987 году я придумал турнир по брейк-дансу для юга СССР (нет, не России, тогда принадлежность республикам мало кого интересовала, национализмом и не пахло). Первый же турнир прошёл плохо: оказалось, что этих брейк-дансов множество подстилей (мы насчитали тогда четыре) и судьям было невозможно работать, ибо в одном заходе встречались в сравнении танцоры разных стилей. Поскольку в этот момент я уже осознанно понимал этот "метод бесконечного улучшения", то я просто записал на бумажке основные проблемы. И мы объявили проведение следующего турнира, в котором эти проблемы были учтены. Всё прошло много лучше! Таких турниров я провёл четыре подряд, на четвёртом турнире уже был оглушительный успех, приехало больше сотни тогдашних брейкеров, было множество зрителей, был и финансовый успех -- метод "бесконечного развития" работал. И всё это прекратилось, потому что именно в 1987 году я переехал в Москву и мне стало совсем не до танцев: уже полным ходом шла перестройка.
В Москве в 1991 году я начал проводить тусовки тогдашнего финтеха ("инфраструктура рынка ценных бумаг": депозитарии и регистраторы) в пансионате "Юность" -- тем же методом: совершенствуем сначала крупное, затем всё более и более мелкое, причём не останавливаемся. И провёл их раз в полгода 11 штук, удерживая каждый раз некоторый чеклист -- и улучшая его положения. Этот чеклист в варианте на начало 1994 года даже сохранился -- https://libertarium.ru/l_libsb3_3-4.html (и в этом же сборнике есть и моя вторая методологическая работа, "Как сделать модель полезной пользователю?" -- https://libertarium.ru/l_libsb3_3-5.html, "в данной статье описывается технология создания учебных курсов на базе имитационных программных моделей предметных областей. Впрочем, большая часть того, что будет сказано, относится и к созданию обычных руководств пользователя". И там дальше про роли, а также понятизацию. Это к вопросу об удерживании некоторой тематики в деятельности десятки лет, при этом мастерство растёт, но проекты всё время менялись, это не было "меднолобым фанатизмом удержания мечты"!).
Современный инженерный процесс -- это много-много мелких улучшений, непрерывное совершенствование
Сегодня ничего не изменилось: я пилю FPF, имея некоторый длинный список того, что я считаю недостатком -- и делаю это крайне нудно, рутинно, надеясь получить тот самый шедевр. Летом там всё было ужас-ужас-ужас, осенью ужас-ужас и началось использование, сейчас просто ужас -- и мне уже шлют благодарности. Вот GitHub этого проекта: https://github.com/ailev/FPF/ -- и обратите внимание, что большинство проектов в GitHub ровно так и делают: непрерывно улучшают выложенные туда коды. У кого хватает сил и умения сохранить evolvability, терпения вести проект десяток лет -- тот добивается результатов. У кого не хватает такого умения -- ну штош.
Дальше всё зависит от того, сколько времени вы можете продержаться в этом цикле:
-- насколько полезен ваш продукт и хороша бизнес-модель (монетизация), чтобы оплачивать этот цикл долго
-- насколько у вас хватает терпения "пилить" (удерживать себя в этом цикле годы и годы) и умения "пилить" (умения найти проблемы, умения решить проблемы, умения удержать архитектуру evolvable)
Сегодня такой способ разработки отслежен и описан, а также стандартизован в его разнообразии. Он называется "инженерный процесс", и никакого тебе "жизненного цикла", но бесконечная эволюция продукта, ведомая а) текущим кумулятивным результатом решения предыдущих проблем (проектом, чеклистом) и б) после каждого запуска списком обнаруживаемых новых проблем, "телеметрия" (сбор данных об использовании) и анализ проблем, даже если эти проблемы труднозаметны. Найти новую проблему (даже когда всё хорошо), отразить в продукте -- выдать в пользование, вернуться в цикл. Репетиционная доводка спектакля до выпуска, PDCA, kaizen, POOGI, ATDD, continuous improvement. Это "база", это не SoTA. Это то, что надо осознать, и не откатываться в прошлое.
"База" агентов: автоматизируем "непрерывные улучшения". Удивительно, но это работает!
Современные системы с агентами идут по этому же пути, исключая человека как организатора цикла непрерывного "пиления" маленькими улучшениями. Вот как выглядит "современнейший инженерный процесс" в его описании в форме промпта для LLM-агента (https://t.me/llm_under_hood/731):
(1) запусти скрипт `make test`, оно протестирует твой код, выдаст ошибки и выдаст score (изначально кода нет совсем, поэтому и тестер выдает 0%)
(2) изучи код вдумчиво и найди, чего не хватает
(3) предложи мне минимальное изменение, которое максимально увеличивает score
Это автор промпта описывает как "снова и снова копипастой отправлял с телефона задание". Тест -- это те самые "найденные проблемы", у него было 235 готовых тестов.
Дорого ли это? Да, такие циклы "едят токены как не в себя". Но вопрос: работает ли? Да! Ключевое: "найди, чего не хватает и дай минимальное изменение/diff к текущему описанию системы, которое максимально увеличивает число решённых проблем".
Предыдущий пример с "запусти скрипт `make test`" был попыткой воспроизведения результата Cursor, который сделали конвейер из а) постановщиков задач б) исполнителей. И поручили написать браузер, весьма сложную программу, которую написать не всякая фирма возьмётся. Тут, конечно, та же ситуация: браузер должен пройти чеклист/тесты, который заранее готов и не меняется. Войны браузеров конца 90х на них нет! Вот пост об этом: https://cursor.com/blog/scaling-agents. Почему удалось? Ключевое: потому что агенты продержались аж неделю автономной работы, не теряя цели! Почему раньше не получалось такое сделать? Потому что так долго без потери цели не удавалось продержаться с прежними поколениями моделей (что с них возьмёшь, дети ещё! Хотели получить интеллект "хотя бы ребёнка" -- вот, со всеми недостатками, включая недержание внимания. Ибо внимание удерживают письменно, во внешней памяти!). Итак, добавили память (кодовая база, задания, патчи), а ещё взяли GPT-5.2, которая вот в таких длинных проектах оказывается надёжней, чем варианты Claude (вот комментарий по-русски: https://t.me/seeallochnaya/3287).
И таких примеров тьма:
-- берём набор eval/тестов
-- делаем хоть что-то
-- крутим цикл "проверь, предложи изменения, чтобы поднять скор"
-- когда скор высок, остановись и скажи
Одного цикла непрерывного совершенствования недостаточно, это не передний край
Чего не хватает в этом базовом подходе "пилить, пока не перепилишь"? Очень многого! "Улучшай, пока не пройдёшь тесты" -- это статическая (как будто мир неизменен! никакой эволюции!) локальная оптимизация по одной характеристике -- скор прохождения тестов. Но сведение множества характеристик к одному скору/рейтингу -- это уже не передний край, не SoTA. Вы теряете важнейшую информацию, оптимизация должна быть многокритериальной! Надо рулить постановкой целей, конфликтами значений разных характеристик, популяционными эффектами, измеримостью того, что вы делаете и воспроизводимостью оценок, а ещё самим инженерным процессом.
Вот чего не хватает:
1. Отношения к набору тестов, использованному автором, как к полноценному описанию целевой системы: просто это другой viewpoint, нежели "описание кодом". И понимания, что меняется набор тестов, описывающий проблему, поэтому нет для этого набора "идеального решения", поскольку у нас не "идеальная статичная проблема": она обычно в этом наборе тестов плохо сформулирована (тестируется не то, не тогда), а также изменяется со временем по мере понимания того, что же там не работает. И ещё "разработчики" (живые и не очень) любят закон Гудхарда: оптимизирование чего угодно за счёт проседания важной, но не указанной явно характеристики (reward hacking). В цикле тем самым надо заниматься ещё и постановкой задачи, проблематизацией. Инженерный процесс (алгоритм "цикла разработки") при этом сразу становится более хитрым, примеры смотри в работах вроде Paired Open-Ended Trailblazer (POET) -- https://arxiv.org/abs/1901.01753, Enhanced POET -- https://arxiv.org/abs/2003.08536, LLM-POET https://arxiv.org/abs/2406.04663). Целевая система может тогда отэволюционировать к тем областям пространства решений, куда она иным способом попасть не может. И это -- принципиально. Проблематизация (острый глаз, который замечает проблему и может её описать точным языком, формализация там только один из шагов в повышении точности языка -- https://ailev.livejournal.com/1786844.html), она же в других тусовках "постановка задачи", она же в быту разработчиков "отдадим это аналитикам, маркетологам, кому угодно" (это ведь тоже проблема -- "отдать часть инженерного процесса", вывести за пределы разработки!) оказывается существенной частью инженерного процесса. И вот так мы перешли тут к open-endedness и разным алгоритмам в этой предметной области развития чего бы то ни было (open-endedness -- https://ailev.livejournal.com/1463013.html).
2. Невозможность удержания всех traits/features на максимуме ввиду неизбежных конфликтов: в разработке надо или говорить о портфеле (если у вас хватит ресурсов), или выбирать точку на Парето-фронте -- или сдвигать этот Парето-фронт, если сможете (вот я говорил об этом в "Проблемы пузомерок для AI-болванов" -- https://ailev.livejournal.com/1753048.html). Если все эти слова про Парето-фронт и портфель незнакомы, то всё, приехали -- в конкуренции вы будете участвовать "по наитию", а дальше как у древних инженеров, "иногда срабатывает, а иногда нет -- и чёрт его знает, почему, эту науку ещё не придумали". Вас в конечном итоге интересует не "прохождение тестов/соответствие описанию", а "соответствие/fit окружению", при этом ещё и окружение тоже меняется. Но да, у нас же это проблемы не разработчиков, а аналитиков (они же не инженеры, а "предлагатели инженерам"), менеджеров (они же в разработке ничего не понимают!), маркетологов (вечно хотят невозможного! Хотя у конкурентов почему-то возможного).
3. Современным подходам к эволюции, которые заставляют отслеживать эволюцию популяции (fitness landscape - это про популяцию), а не одного организма, а также отслеживать эволюцию системы разработки в её влиянии на целевую систему (в нашем случае учитывать эволюцию инженерного процесса, эволюцию разработчиков и их знаний), а также Это eco-evo-devo (вот я писал " Как связаны инженерия и теория эволюции: инженерия нейросеток как eco-evo-devo", https://ailev.livejournal.com/1752137.html). Вот эта эволюция от POET к Enhanced POET -- это ведь тоже эволюция! Эволюция эволюции нас тоже интересует, ибо если наша эволюция быстрее, чем эволюция конкурентов -- мы выиграли!
4. Характеризация и воспроизводимая оценка. В исследованиях по 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 и прочими инструментами:
1. Мы имеем какой-то набор проблем, который вот прямо сейчас учимся решать. Дела, которые надо научиться делать, тем самым стать личностью, которой мы хотели бы стать -- иметь соответствующие виды мастерства. Ключевое тут -- обучение. Вот я не умею чего-то делать, вот пошёл на курсы -- освоил! Если нужно уметь проектировать смартфоны -- иду в вуз, там меня учат!
2. Но тут оказывается, что "драмкружок, кружок по фото, а ещё мне петь охота, за кружок по рисованью тоже все голосовали". Научиться всему оказывается нельзя! Если учиться проектировать смартфоны, то ты уже не очень умеешь проектировать мосты, а с мостами -- проблемы в проектировании ракет. Поэтому надо выбирать какую-то точку на Парето, чтобы быть конкурентоспособным в текущем окружении. А самые умные ещё и двигают это Парето. Вот наша Мастерская инженеров-менеджеров (МИМ) -- она двигает Парето, ибо сразу идёт к изменению алгоритма развития, беря его из следующих поколений, которые недоступны пока конкурентам-"соэволюционерам": учиться сразу системной инженерии, а не проектированию конкретных видов систем.
3. Современный подход к эволюции, конечно, заставляет отслеживать эволюцию не отдельной личности (человеческой или не очень человеческой, мастерство ведь решения всяких проблем есть не только у человека), а популяции. Поэтому бежим в будущее популяциями, поглядывая на traits/features друг друга и учитывая ещё и резкое изменение ситуации ввиду прихода AI. Если сосед что-то умеет, то и мне надо уметь -- даже если это означает включения в состав своей личности экзокортекса с AI! А ещё надо отслеживать, что там даёт максимальную эволюционируемость, а для этого выбирать изучение мастерства, или исследование проблем которые потенциально увеличивают возможность последующих траекторий в жизни. Грубо говоря, после пятилетнего изучения системной инженерии не в режиме хобби вы дальше смело можете пойти в поэты, а вот после пятилетнего изучения поэзии не в режиме хобби -- не факт, что смело сможете пойти в инженеры. Нужно уметь выбирать себе новые и новые проблемы для решения, а не долбиться веками в улучшения процесса добычи огня трением.
4. Конечно, хорошо бы ещё уметь обсуждать характеристики личности, что вы там в себе "развиваете", хотя и так уже "развиты". Как вообще измерить "развитость", "интеллект"? Как оценить "калибр личности"? Как перейти от метафор к чему-то более точному, то есть более надёжному и воспроизводимому? Хотя что-то мы на эту тему уже знаем: например, неплохо бы отслеживать свою evolvability/развиваемость. Если утеряли возможность изменяться, то кричать "караул" -- ибо это архитектурная характеристика личности, и развитие в том числе -- это неутеря возможности изменяться, адаптироваться к неизбежным изменениям в окружающем мире.
Весь этот пост -- моё мышление письмом, подготовка к семинару "Развитие для развитых в 2026", он будет уже 1 февраля 2026 (https://ailev.livejournal.com/1787638.html). Понятно, что "надо развиваться, и делать это всё время". Но моя задача -- дать SoTA язык для того, чтобы это "развитие для развитых" обсуждать инженерно, а не "как психологи" или "как педагоги" (психологи и педагоги обо всём этом не знают, а инженеры не догадываются говорить о людях. Правда, семинар общий: развивать можно и вполне развитые системы в рабочих проектах, необязательно этот материал применять только к себе. Но знать SoTA о том, как развивать целевые системы в рабочих проектах -- это тоже "развитие для развитых").
Без обсуждения Парето-фронта, многокритериальной оптимизации сейчас нельзя. Любому инженеру знакомы взаимозависимости, в которых нужны очень крутые решения, чтобы выйти на новый Парето-фронт (как раз это и будут решения "лидеров рынка". А остальные почему не умрут? Они просто максимизируют какую-то одну характеристику, чтобы быть недоминируемыми -- вот эта "недоминируемость" как раз ещё один важный термин, это когда другие решения не оказываются лучше твоего по всем характеристикам, когда у тебя хоть что-то лучше конкурентов):
-- скорость разработки ↔ надёжность ↔ стоимость сопровождения,
-- точность ↔ задержка ↔ интерпретируемость,
-- функциональность ↔ простота ↔ безопасность,
-- ... это можно продолжать и продолжать.
Развитие для развитых -- это SoTA инженерного процесса в приложении к людям
Если считать, что личность -- это "софт организма" как сумма всего мастерства, которым владеет человек (или киборг как гибрид человека и экзокортекса с его AI), то мы быстро приходим к выводу, что для инженерии личности SoTA -- это всё то же самое: много-много мелких улучшений личности, но ещё и непрерывный выбор решаемых задач и поиск методов их решения -- стратегирование, а ещё и "инженерия инженерии личности", а ещё и определение пространства характеристик развития и отслеживания своей траектории в этом пространстве, насколько предсказанная отличается от желаемой и что надо поменять на основе замеренных результатов предыдущих шагов развития.
Да, "развитие для развитых" -- это SoTA open-endedness в приложении к людям в их симбиозе с AI и прочими инструментами:
1. Мы имеем какой-то набор проблем, который вот прямо сейчас учимся решать. Дела, которые надо научиться делать, тем самым стать личностью, которой мы хотели бы стать -- иметь соответствующие виды мастерства. Ключевое тут -- обучение. Вот я не умею чего-то делать, вот пошёл на курсы -- освоил! Если нужно уметь проектировать смартфоны -- иду в вуз, там меня учат!
2. Но тут оказывается, что "драмкружок, кружок по фото, а ещё мне петь охота, за кружок по рисованью тоже все голосовали". Научиться всему оказывается нельзя! Если учиться проектировать смартфоны, то ты уже не очень умеешь проектировать мосты, а с мостами -- проблемы в проектировании ракет. Поэтому надо выбирать какую-то точку на Парето, чтобы быть конкурентоспособным в текущем окружении. А самые умные ещё и двигают это Парето. Вот наша Мастерская инженеров-менеджеров (МИМ) -- она двигает Парето, ибо сразу идёт к изменению алгоритма развития, беря его из следующих поколений, которые недоступны пока конкурентам-"соэволюционерам": учиться сразу системной инженерии, а не проектированию конкретных видов систем.
3. Современный подход к эволюции, конечно, заставляет отслеживать эволюцию не отдельной личности (человеческой или не очень человеческой, мастерство ведь решения всяких проблем есть не только у человека), а популяции. Поэтому бежим в будущее популяциями, поглядывая на traits/features друг друга и учитывая ещё и резкое изменение ситуации ввиду прихода AI. Если сосед что-то умеет, то и мне надо уметь -- даже если это означает включения в состав своей личности экзокортекса с AI! А ещё надо отслеживать, что там даёт максимальную эволюционируемость, а для этого выбирать изучение мастерства, или исследование проблем которые потенциально увеличивают возможность последующих траекторий в жизни. Грубо говоря, после пятилетнего изучения системной инженерии не в режиме хобби вы дальше смело можете пойти в поэты, а вот после пятилетнего изучения поэзии не в режиме хобби -- не факт, что смело сможете пойти в инженеры. Нужно уметь выбирать себе новые и новые проблемы для решения, а не долбиться веками в улучшения процесса добычи огня трением.
4. Конечно, хорошо бы ещё уметь обсуждать характеристики личности, что вы там в себе "развиваете", хотя и так уже "развиты". Как вообще измерить "развитость", "интеллект"? Как оценить "калибр личности"? Как перейти от метафор к чему-то более точному, то есть более надёжному и воспроизводимому? Хотя что-то мы на эту тему уже знаем: например, неплохо бы отслеживать свою evolvability/развиваемость. Если утеряли возможность изменяться, то кричать "караул" -- ибо это архитектурная характеристика личности, и развитие в том числе -- это неутеря возможности изменяться, адаптироваться к неизбежным изменениям в окружающем мире.
Весь этот пост -- моё мышление письмом, подготовка к семинару "Развитие для развитых в 2026", он будет уже 1 февраля 2026 (https://ailev.livejournal.com/1787638.html). Понятно, что "надо развиваться, и делать это всё время". Но моя задача -- дать SoTA язык для того, чтобы это "развитие для развитых" обсуждать инженерно, а не "как психологи" или "как педагоги" (психологи и педагоги обо всём этом не знают, а инженеры не догадываются говорить о людях. Правда, семинар общий: развивать можно и вполне развитые системы в рабочих проектах, необязательно этот материал применять только к себе. Но знать SoTA о том, как развивать целевые системы в рабочих проектах -- это тоже "развитие для развитых").