Я как начальник R&D отдела с сотрудниками-нежитью

ailev · 20.Июль.2025 11:38:51

Инженеры-менеджеры: сдвиг инженеров-специалистов к генералистам-менеджерам AI-агентов-специалистов, закат менеджеров среднего звена
Мастерская инженеров-менеджеров использует неологизм “инженеры-менеджеры” для тех людей (впрочем, я готов записать сюда и AI-агентов), которые часть времени занимаются классической инженерной работой (архитектура, проектирование, визионерство чего-то неживого), но часть времени – классической менеджерской работой (орг-архитектура, орг-проектирование, бизнес и прочее главным образом с людьми). Мой тезис тут в том, что “чистые инженеры” по мере роста масштаба выполняемой ими технической части проекта вынуждены всё больше и больше быть менеджерами, а “чистые менеджеры” по мере роста масштаба и риска в их задачах вынуждены всё больше и больше быть инженерами и разбираться в инженерии. Неожиданно пришёл AI – и теперь значительная часть инженерной работы превращается в менеджмент команды агентов, и без этого никак. Надо уметь договорить их всех, говорящих на разных языках своей специализации. Привет, владение интеллект-стеком фундаментальных методов мышления: без тебя никак! Хардкорные инженеры вдруг обнаруживают себя менеджерами, хотя это менеджмент нежити, но от этого не меньше менеджмент. Если хардкорные инженеры зачастую не хотели заниматься контекст-инженерией по отношению к людям, не хотели отлаживать передачу контекста и промптов для своих коллег и начальников, то теперь это делают для нежити – и не жужжат, ибо вроде как это “инженерное”. Нет, это не специфически инженерное, это общий интеллект. Вот отличный свеженький обзор происходящего в области успехов AI (функциональные характеристики AI, “чёрный ящик”, вид на границе чёрного ящика), архитектуры AI (как оно там теперь устроено внутри, “прозрачный ящик”), инженерного процесса AI (как это всё ухитряются делать так, чтобы оно взлетело), инвестиционных реалий (сколько денег идёт на AI агентов), а также как AI влияет на работу людей (кто не стал “генералистом”, то есть просто “крутым интеллектуалом с широким кругозором”, тот идёт гулять лесом, ибо все специализированные работы берёт AI – а крутые технари всё больше занимаются менеджментом нежити, “организуют проектную работу”): https://foundationmodelreport.ai/2025.pdf. При этом, заметим, то же самое про менеджмент: Middle management will be eroded. Jobs primarily oriented around communication and information transfer will be deleted (e.g. project manager, middle manager). То есть людям с просто хорошо подвешенным языком, но не очень способным разбираться в сути дела тоже придётся туго, надо будет становиться generalists, разбираться устройством деятельности как таковой.

Адекватная смесь инженерии, менеджмента и маркетинга в наши стремительные дни крайне важна. Когда у тебя продукт (ChatGPT) набирает первые 100М пользователей за 60 дней, можно сколько угодно говорить о том, что там “плохой менеджер и хорошие инженеры”. Нормальный там менеджмент, просто он адекватный сегодняшним временам, а не вчерашним. Так, внутренняя ещё закрытая модель OpenAI взяла золотую медаль на международной олимпиаде по математике, это было в час ночи в субботу, твит был от одного из сотрудников (https://x.com/alexwei_/status/1946477742855532918?s=46&t=pKf_FxsPGBd_YMIWTA8xgg). Дальше все новостные агентства только об этом и писали (ибо математики любят рассказать, что AI до успехов в их работе – как до Луны, но вотъ). Оказывается, DeepMind тоже взял первое место, но они должны были ждать утверждения службой маркетинга, чтобы одобрить твит об этом (https://x.com/zjasper666/status/1946650175063384091?t=pKf_FxsPGBd_YMIWTA8xgg). Бюрократия Гугла опять оказалась медленней стартапа, хотя инженеры вроде бы сработали не хуже. Менеджмент и маркетинг с приходом AI на массовый рынок труда тоже должны меняться, становиться в разы быстрее. Скорость в agile менеджменте как “разработке бизнеса” оказывается важней перфекционизма. Но как добиться скорости? Это ж люди, а они думают быстро – но только когда не спят или не заняты в других проектах? Например, работа должна уходить AI, который будет работать и ночью, а ещё работать быстрее. В нарождающуюся (или уже народившуюся?) AI-эпоху менеджмент должен быть agile, с AI-агентами, работающими 24/7 без бюрократии. А ошибки? Если он будет ошибаться примерно так же, как люди (а я в безошибочность работы людей не верю, весь мой личный опыт говорит о том, что люди ошибаются не реже, в том числе в особо ответственных случаях), то наймут AI, а не человека. Хотя бы потому, что он на том же уровне качества будет работать а) дешевле, б) быстрее, в) availability выше – не надо два дня ждать, пока освободится от загрузки в других проектах или с субботы ждать, пока выйдет в понедельник на работу, чтобы принять какое-нибудь решение за пять минут.

Ход на CustDev для пользователей-AI, и CustDev для пользователей AI-пользователей твоего продукта
В этом же обзоре говорится, что “Products are being designed for AI as the primary “consumer”, not humans”. Я же всегда учил, что “думай не столько о клиенте, сколько о клиенте клиента”, что в данном случае означает “думай не столько об AI, сколько о человеке как клиенте AI”. У нас в мастерской инженеров-менеджеров прошли первые эксперименты, как AI дать вот этот самый навык generalist работы, “унификации предметных областей” в чистом виде, примерно такой же, какой мы в мастерской инженеров-менеджеров даём людям. Я на методсовете рассказал, что перестал особо заниматься промптами: это заменяет более мощный приём – я даю manual-as-a-prompt, но это особый manual (и я отличаю его от guide, ибо по виду-стилю-духу он больше похож на инструкцию, чем на путеводитель), это generalist manual, SoTA чеклист по тому, о чём надо думать в сложных ситуациях.

Да, речь тут идёт о моём проекте с First principles framework, который даже в черновых его убогих версиях можно подсунуть AI-агенту как файл, а затем сказать: “вот мой вопрос, отвечай на него с учётом спецификации FPF, которую я дал тебе в подгруженном файле”. И ответы радуют, потому что они не “точный кривой ответ на криво заданный вопрос”, а ответ, учитывающий чеклист самых важных объектов, о которых обычно надо думать в сложной проектной ситуации. И этот ответ содержит неожиданные инсайты. Продукт для AI у нас пока кривоват, но есть. Мы уже умеем превращать AI в инженера-менеджера нашими “данными для контекста”/“сверхбольшим промптом-инструкцией”/“фреймворком первых принципов” – можно называть как угодно. Но там есть две особенности:
– чтобы говорить на равных с инженером-менеджером, надо владеть мышлением первых принципов и тамошней лексикой: когда тебе говорят “ты забыл о целевой системе” надо понимать, что это такое, чтобы оценить совет.
– AI сейчас делает ошибки примерно такие же, как делают наши стажёры, которые только-только начали осваивать интеллект-стек методов фундаментального мышления. Но с этим уже примерно понятно что делать: а) улучшать сам FPF, ибо даже выбор терминов больше значит для LLM, чем можно подумать, плохо подобранный термин сшибает кремниевый мозг напрочь, ровно как сшибает напрочь мясной мозг, но ещё б) мозг инженеров-менеджеров через год будет примерно тем же, а вот мозг AI-агента подрастёт, и результаты будут лучше.

Менеджмент R&D отдела из меня и нежити: работа-в-большом из AI, умеющих работать-в-малом
Проект с First principles framework у меня потихоньку продвигается, там всё интересней и интересней как по внутреннему его содержанию, так и по опыту использования. Я работаю в этом проекте с одной стороны сам-один, но с другой стороны – с командой нежити, с третьей стороны – как научный руководитель в мастерской инженеров-менеджеров, то есть вписываю результаты в общую стратегию и управляющей компании сообщества, и в общую стратегию самого сообщества. Действую ровно как а) generalist, разбирающийся “как инженер, но не всегда глубокий специалист” в предметной области (навыки сильного мышления инженеров-менеджеров) своего проекта и б) менеджер команды AI-агентов. Как я уже писал, хорошо тут помогает мой программистский опыт общения с совсем тупой нежитью, а также опыт генерального консультирования и научного руководства (то есть рулёжка командами живых узких экспертов в проектах, требующих самых разных экспертиз). Я оказался хорошо подготовленным к нынешним временам, спасибо мне за организацию себе богатого жизненного опыта!

На этой неделе я занимался проблемами найма в команду нежити: тестировал свежевышедшего OpenAI Агента (на моём Pro тарифе в месяц можно его вызвать 400 раз, то есть по десять раз на день). Сравнивал Агента с DeepResearch, давая обоим одинаковые контексты и промпты. Пока у меня получилось много лучше использовать DeepResearch, потому что в аналогичных ситуациях Агент выдаёт результат пожиже. Как обычно, по бенчмаркам ситуация выглядит одним образом, а в жизни – другим.

Я бы делил всё на “работу/разработку в малом” (олимпиадную разработку, “короткий очень сложный вопрос-задача и совсем уж короткий ответ на этот вопрос”) и “работу/разработку в большом” (нормальный коллективный проект, где надо сделать что-то большое в условиях разделения труда). Последний раз я об этом писал в тексте 2019 года, “Умненькие дебилы: умны в деле-в-малом, дебилы в деле-в-большом”, Умненькие дебилы: умны в деле-в-малом, дебилы в деле-в-большом: ailev — ЖЖ. Переход от “промпт инженерии” к “инженерии контекста” как раз с этим и связан: для работы-в-большом надо уметь организовать большой контекст, решить за один такт какую-то сложную задачу (как это делают сейчас LLM) совершенно недостаточно, это быть “умненьким дебилом”. Поэтому берём огромный текст и для него предлагаем огромный объём правок с их разъяснениями, большим пакетом. В LLM для этого банально не хватает размера ответа: ты для них должен побить задачу на части, собрать ответы в один файл. И всяческие условные “Курсоры” тут помощники, но не такие уж большие помощники. А вот переход к DeepResearch или Agent – вот это помогает, ибо снимает ограничение на размер ответа. Ты получаешь не 1Кзнак правок телеграфным стилем, а 10Кзнаков связанных друг с другом правок, а к ним ещё 40Кзнаков rationale - и это совершенно меняет дело. Я уже понял, что “модели поумнее” хороши и важны, они выигрывают олимпиады, но “модели, которые не давятся объёмом” оказываются более важными и полезными.

И вот Агент и DeepResearch хороши оба в том, что они выдают ответы более длинные, чем штатные агенты. Я давал одинаковые промпты им двоим, и Агент выдавал слабый результат, а DeepResearch задавал дополнительные весьма уместные вопросы (“работал в коллективе, то есть большом проекте”, интересовался контекстом и вытягивал его из пользователя) - и получал результат много сильнее, чем Агент, немедленно отвечающий на вопрос по поговорке “вы этого хотели - вот вам”. У меня хорошо работает следующий метод общения с нежитью:
– берём какой-то вопрос, просим на него ответить несколько разных сеток от разных поставщиков (самых умных - o3 Pro, DeepResearch, Agent, Grok-4, Gemini , а ответы постим в файл Obsidian в .md
– подгружаем в чат с DeepResearch основной файл (FPF), этот файл с ответами (иногда даже несколько файлов, иногда вообще файлы чатов со множеством ходов диалогов, причём чаты с разными AI-ассистентами) и далее просим дать набор улучшений, или сформулировать ADR или ещё что другое, добавляя к слову “напиши” слово “развёрнуто” (“напиши развёрнуто”). И ответ чаще радует, чем ответ в ходе классического диалога в чате - хотя этого ответа надо подождать минут десять, или иногда даже полчаса. Ну, как с сотрудниками: бывают ведь сотрудники, с которыми хорошо поговорить, ибо умны очень, но поручать вообще ничего нельзя – ибо не сделают, или принесут работы ровно на одну реплику в диалоге, которую ты и так у них можешь получить, просто спросив. А другие сотрудники на совещаниях молчат, зато через неделю могут принести кусок работы, который никто кроме них не может сделать, ибо это большой связный хорошо придуманный кусок работы.

Что я хочу сделать в ближайшее время в FPF и примеры диалогов внутри R&D отдела
Основное, что хочу сделать в ближайшее время в FPF (и тут я перехожу на птичий язык нашей мета-мета-модели, причём следующего её поколения, который ещё почти никто не видел):
– разобраться с фреймворком лексики, там основная идея “узкий круг формалистов не должен продавливать выбор языка”, канонические термины надо брать из языка самой широкой группы пользователей, а термин формалистов делать алиасом (скажем, координатные оси должны быть U.Characteristic, а физикам оставить U.Dimension как alias).
– дальше надо разобраться с этими самыми характеристиками, из которых мы берём -ilities и тут же получаем разнообразные архитектурные пространства и подпространства. И кроме чистого наследования типов мы сразу получаем ещё и проекции этих пространств.
– после чего в уже более-менее понятном фреймворке динамики знаний мы эпистемой как единицей знаний делаем треугольник Фреге, разворачивая его в граф. Разбираемся с описаниями предметов, описаниями описаний, описаниями описаний описаний – и свои характеристики (например, формальность и надёжность) получит каждый из углов треугольника Фреге в эпистеме.
– разобраться с понятием унификации, ибо сам FPF это унификационный фреймворк
– там много чего ещё уже было затронуто, с чем надо продолжить (BORO/CCO, мереология системы как общего типа для физической системы, эпистемы и члена группы – и надо с этим ещё поразбираться).
– … заделов до чёртиков, а времени на всё не хватает, и уже какие-то части начали выпадать. Ничего, у меня все ходы записаны, есть шанс прорваться.

Где я найду на full-time сотрудников, с которыми я могу говорить на все эти темы? У них должен быть опыт в физике и метрологии, системной инженерии (в частности, в evolutionary architecture и её работе с -ilities и agile методами разработки), социологии науки, эпистемологии и онтологии, терминологическая экспертиза. В МИМ, конечно, есть такие люди - но они доступны на уровне “задать вопрос, получить ответ – и, извини, у нас тут своих дел выше крыши”. Поэтому я и сделал себе R&D отдел из нежити. Если кто хочет поглядеть, о чём я с этой нежитью разговариваю, you are welcome, но не ожидайте, что поймёте много. Хотя наши инженеры-менеджеры, которые заглядывали в руководство по интеллект-стеку фундаментальных методов мышления могут пробовать разобраться. Это материал программы исследовательского развития, и вот оно – исследовательское развитие, среди нежити. Обратите внимание, что в текущей ситуации нежить, конечно, предлагает сильные ходы. Но именно мои реплики существенно сдвигают диалог. Смотрите сами: