#63: Системное мышление для инженера

[00:00] Александр: Погнали.

[00:00] Иван: Да, как будто вот так, с ходу.

[00:06] Александр: Привет. Приглашаю всех слушателей к нам за виртуальный бар — как будто ты просто зашёл в бар, услышал за стойкой пару чуваков, которые что-то обсуждают, и присоединился к разговору. Ну, это нормальная тема вообще. В общем, мы тут разгоняем про искусственный интеллект и про что-то полезное для нас, инженеров, которые хотят двигаться.

[00:35] Александр: И первый вопрос, Вань, к тебе такой. Как бы ты поразгонял мысль о том, что кормушка в айтишечке сейчас сужается? Тот пузырь, к которому мы привыкли: рост, растущие зарплаты, всё больше проектов, программист — почти элитарная профессия. Сейчас как будто бы уже не то. И вопрос — а как остаться у этой кормушки, как обеспечить себе нормальный доход и в целом быть у проектов?

[00:59] Иван: Да, это вопрос. Актуальный как раз в рамках всей этой замечательной AI-революции — без преувеличения назовём её так. Кормушка на самом деле не то чтобы сужается — она скорее возвращается к тому, как оно и должно было бы быть по-хорошему, если рационально смотреть на индустрию с самого начала. Вспомни какой-нибудь Twitter десятилетней давности: там было вполне нормально зайти на аккаунт подруги, которая начала учить CSS и HTML, — и она уже, значит, software engineer. Так долго и было: работа программиста часто была очень удобной, особенно в большой корпорации с кучей бюрократии — делать какие-то задачи, писать круды, перекладывать JSON. А самое большое, что поменялось с нашими замечательными Claude Code и прочим, — что вот именно это в какой-то степени обесценилось. У тебя недавно был пост в Telegram-канале, где ты говоришь: зачем мне VS Code, Zed и прочая ерунда, у меня есть Claude Code. С этим спорить сложно, потому что нет смысла: Claude Code без всяких детальных спецификаций отлично покрывает очень много простых задач, ещё и тесты может написать. Но по существу-то в плане бизнеса у нас ничего не поменялось. Написание кода всегда было — я даже не знаю, как оценить, очень грубо — если не 5, то, может, 15 процентов всей работы. А если добавить туда инфраструктуру, девопс, всякие эти штуки, которые раньше разделялись по другим ролям, админам, — даже со всем этим не наберётся, наверное, больше 30 процентов. Потому что есть бизнес, есть реальный мир, есть интересы: заработать денег, поменять что-то в мире. И сейчас мы просто пришли к тому, что, выучив какой-нибудь фреймворк или ещё что-то прикладное, ты, к сожалению, уже не самый полезный человек. Тебе нужно учиться чему-то гораздо большему, системному — инженерии, какой она и должна была бы быть. Вот моя мысль.

[03:10] Александр: Ну да — мысль в том, что инженерия системная, именно на более высоком уровне: как работают между собой даже не сервисы, а в целом системы в широком понимании. Система оплаты, например. Система какого-нибудь умного логирования и аудита. И даже больше: если ты работаешь в стартапе или не очень большой компании и прям хочешь остаться у кормушки, получать большие деньги и быть востребованным, тебе надо понимать ещё дальше — что вообще твой бизнес делает, что он меняет в реале. При этом у тебя появляются более высокие требования к сеньорности в плане бытия менеджером. Если раньше ты дорастал как сеньор до какой-то тимлидовой позиции, где нужно управлять джунами, заниматься мелким менеджментом, то сейчас у тебя, значит, 50 инстансов Claude Code — и это всё ещё несколько инженеров, а это тот же самый менеджмент. Есть разница между нашим интеллектом и искусственным, но подходы очень похожи. Мне очень нравится тема менеджмента, я бы в эту сторону ушёл. Но прежде давай разберём второй трек развития инженеров, который я ещё полгода назад воспринимал как реальный, а потом для себя решил: наверное, нет, я туда не пойду — слишком много рисков и мало интереса. Это трек вглубь. Когда мы развиваемся в профессии, мы можем либо быть очень узкоспециализированными, но лучшими в своём деле, либо широкими — уметь всего по чуть-чуть, иметь представление и уходить на уровень менеджмента. И вот у меня сейчас есть ощущение, что узкая специализация в привычном понимании — например, оптимизировать какие-то очень узкие места, переписывать куски сервисов на ассемблер, вылизывать горячие пути — это просто путь в никуда. В том плане, что ты начинаешь конкурировать уже не с другими людьми, которых можно обогнать, а с моделями, которых обогнать собственным интеллектом, наверное, уже сложнее. Вот что ты думаешь про узкую специализацию?

[04:29] Иван: Ты прав, что начинаешь конкурировать с моделями и с каким-то очень узким рынком, на котором всё ещё остаются люди. Я знаю, что есть места, где уже используют модели для написания того самого ассемблерного кода — причём под какое-то экспериментальное новое железо, реализующее новые вычислительные штуковины. Но там люди остаются, и просто конкурировать с ними, если ты с улицы Вася — пусть даже закончил какую-то вышку лет десять назад, — очень сложно. При этом я не могу сказать, что узкие специальности полностью обесцениваются. Даже если ты будешь дженералистом, инженером-менеджером — мы к этому ещё придём, — для качественного решения, даже с помощью вот этой симбиотической модели вместе с ИИ, тебе всё равно нужно неплохо понимать область, в которую ты вкладываешься, чтобы хотя бы правильно делегировать задачу тому же AI. То есть ценность в этом остаётся. Но семимильными шагами мы лишаемся возможности обладать только вот этим прикладным навыком — уникальность его теряется.

[05:34] Александр: Да-да-да. Мы приходим к тому, что нужно развивать безмасштабные системные методы мышления, которые применимы везде, — к этому мы тоже придём. Но при этом для решения конкретных задач тебе нужно и быстро учиться прикладным вещам, прикладным языкам. Ты придёшь в компанию с очень специфическими алгоритмами — блокчейн, например, есть у тебя опыт или нет, — и тебе придётся разбираться. Вопрос в том, насколько быстро.

[06:49] Иван: Ну как будто бы это всегда было требованием к дежурным инженерам на продвинутых технологиях: быстро во что-то вникнуть, сделать первую итерацию, а дальше уже вникать по ходу — делать глубже и лучше. Не то чтобы это новое требование.

[07:39] Александр: Да-да, я с этого и начал. Оно не новое — просто теперь нужны именно продвинутые инженеры в большинстве, а специализированные, особенно на том, что текущим моделям удаётся очень просто и на приемлемом уровне качества, — не нужны. Но при этом всё ещё, называя вайб-кодинг хайпом с негативной коннотацией, давай признаем: хайп-то продолжается. Я буквально чуть ли не каждую неделю сталкиваюсь с ситуациями, когда какой-то совершенно нетехнический человек навайбкодил что-то — а оно либо тотально уязвимо, либо вообще ломается, не работает.

[08:19] Иван: Последний пример у меня был буквально на выходных. Всех подняли, переполошили: почтовые уведомления рассылаются в бесконечном цикле, непонятно, как это работает, непонятно, что происходит. Я как раз в пятницу мержил на стейджинг изменения и думал — может, я сломал что-то. Но интуиция подсказывала, что вряд ли я ошибся, потому что я тесты пишу. И да, оказалось, что кто-то из нетехнической команды навайбкодил и нагрузил API на стейджинге. И такое продолжает происходить — поэтому ценность в инженерах всё ещё есть и будет.

[09:20] Александр: То есть мы идём к синергии инженера и менеджмента в одном лице. Просто быть менеджером и продакшен-навайбкодить — это очень редко. Либо ты врёшь и раньше чем-то занимался инженерным, каким-то STEM, что-то понимаешь, писал простые программы, можешь читать код. Либо не можешь — и получается часто какая-то ерунда. Слушай, а вот этот пример с почтой навёл меня на размышления, которые внутри были, но я их до этого момента не вербализировал. Происходит такой инсайт. У инженеров, скорее всего, соприкосновение с Клодом и Опусом — первым серьёзным — это момент, когда ты понимаешь: блин, оказывается, я могу столько всего делать, чего раньше просто не хватало энергии, сил, времени. А теперь перед тобой весь мир открыт. Это FOMO, движение инженеров в сторону менеджеров. И такое же FOMO идёт у CEO и у всяких chief-людей, которые раньше не могли писать код и нанимали команду, а теперь могут. И эти два противоположных полюса начинают друг к другу сближаться, и вот это FOMO в центре как магнит их притягивает.

[10:10] Иван: Да-да-да. И при этом мы помним, что и тем, и другим нужно очень быстро чему-то учиться, а мозги у нас, как вы видите, ленивые — мы до последнего откладываем этот шаг к обучению. Но, к сожалению, выхода нет: либо ты страдаешь и эволюционируешь, либо продолжаешь плакать и сидеть на месте.

[10:42] Александр: Да. И интересно: если визуализировать это движение, то как будто есть какая-то истина посередине — назовём её software engineering или бизнес на основе software engineering. То есть что-то, что доставляет ценность реальному миру с помощью digital. И вот как это всё сделать — все наши практики: девопс, сервера, мейнтенанс, сопровождение, написание кода, сбор требований, анализ — это всё там. А мы просто как люди с разных сторон к этому приближаемся и объединяем в себе все компетенции, необходимые для дела. Чего не хватает CEO? Понимания, как устроена инфраструктура, как мержить, как обеспечивать безопасность, откатывать, как сделать так, чтобы в субботу у тебя не просыпались люди от e-mail. За это он раньше платил деньги нам, инженерам. А нам, инженерам, не хватает понимания, как, собственно, бизнес строить: вот я написал код — а кому он нужен, что он вообще делает, где экономика? И мы начинаем объединять все эти скиллы в одном мозге. Мне кажется, вот это самое сейчас и происходит — со всеми, со всех сторон.

[11:51] Иван: Да, это именно то. Это неизбежно, но хорошая новость в том, что — особенно для русскоговорящей аудитории — задолго до того, как проблему стали чувствовать в мейнстриме, кто интуитивно, кто нет, она уже давно была понята. Существует целая дисциплина — системная инженерия, системное мышление, — мы к ней сегодня придём. Она как раз даёт тебе ядро и ставит задачей накачать человека фундаментальными мыслительными машинками, которые потом можно применять в любой работе — и инженера, и менеджера. Учиться этому долго, но есть куда идти и где учиться. Учиться до хрена — но оно того стоит. Мой трек такой: я этим занимаюсь уже в той или иной степени последние почти полтора года, результаты неплохие, мне очень нравится. И там заявка на то, что учиться придётся пожизненно. Минусов не вижу: раньше тоже нужно было учиться пожизненно, только всякой прикладной фигне. Пришёл на новую работу — с питона на джаву, учи джаву, потом ещё что-то. А тут постоянно выходят новые научные исследования — и у нейрофизиологов, и модели меняются, — и нужно просто эту софтину у себя в голове обновлять.

[12:56] Александр: Да. Звучит как отличный кандидат на какой-то фундаментальный, основательный университетский курс по системному мышлению. Я не знаю, преподают его сейчас или нет, — у меня в универе не преподавали.

[14:05] Иван: Какое-то время назад, в последнем, наверное, десятилетии, были попытки где-то преподавать как раз из нашей мастерской инженеров-менеджеров. Она тогда называлась по-другому — по-моему, «Школа системного менеджмента», и очень много было именно про менеджмент. Были попытки читать какие-то курсы; чем закончились — не знаю, мне кажется, сейчас в универах не преподают. Но я могу ошибаться, потому что я на самых нижних ступенях, только-только подхожу к тому, чтобы начать что-то понимать вглубь. По большому счёту, насколько мне видится, сейчас сфокусировались на том, что сама мастерская занимается обучением: можно прийти, проходить самостоятельно, а можно проходить резидентуры — платить деньги, заниматься с наставниками в группах. Толк от этого есть, а насчёт универов не знаю.

[14:56] Александр: Окей. Тогда, может, давай двинем к системному мышлению — что это такое? Я думаю, не у всех слушателей в голове есть чёткая картинка, когда они слышат название.

[16:50] Иван: Мне кажется, мы немного не по нашему плану пошли, и это произошло автоматически. Давай немного предысторию расскажу — это быстро и без деталей. Ты-то ко мне как пришёл? Ты, видимо, нашёл на GitHub Qwen Code, такой — угу, прикольно, — пришёл и попросил рассказать на подкасте. И мы быстро, асинхронно и созвонившись, выяснили, что Qwen Code — это просто удачный или неудачный эксперимент, который привлёк какое-то количество внимания, полторы тысячи звёзд, но в очень маленьком отдалении реализует кое-что другое. И вот это кое-что другое — это First Principles Framework, совсем свежая штука, тоже родившаяся из нашей мастерской инженеров-менеджеров, из-под пера Анатолия Игоревича Левенчука. Это научный руководитель, методолог, который разрабатывает большую часть основных руководств, по которым идёт обучение системному мышлению, системной инженерии и всему остальному. И где-то, я так понимаю, прошлым летом ему, наверное, не понравилось качество ответов с точки зрения системного мышления от больших умных моделей, и он предпринял попытку создать спеку для LLM, которая бы — как условный компилятор типов именно для системы — помогала выплёвывать что-то более достоверное. А Qwen Code у меня родился, когда я участвовал в закрытом семинаре как раз по поводу FPF; он был этой зимой, недавней нашей свежей зимой. Прямо в ходе звонка я подумал: о, было бы прикольно попробовать перенести всё это в инструмент, как-то приземлить на программную разработку, на наши простые задачи. Сначала я сделал на питоне сервис, обвязку вокруг модели, чтобы она думала по FPF, — но это не поехало, получилось очень тяжёлым. Потом попробовал присадить его именно в Claude Code. Считаю, что эксперимент скорее провалился: работает плохо, слишком слабо предоставляет варианты, которые требуются для качественного FPF-мышления, назовём это так, и архитектурно не очень подходит. В общем, давай перейдём к тому, что вообще такое FPF.

[17:38] Александр: Да-да, что это такое. А то ты говоришь — FPF, Claude Code, сервис на питоне, — давай картинку нарисуем: что мы вообще имеем в виду?

[17:38] Иван: Наверное, мы имеем в виду попытку заставить LLM, искусственный интеллект, быть чуть-чуть последовательнее, умнее, рациональнее. Мы условно делаем такой контекст-инжиниринг, в котором как-то специфицируем поведение модели по некоторому принципу. В FPF есть очень много несущих конструкций, мы могли бы про них сейчас говорить, но давай попробуем подойти от проблемы. Вернёмся немного назад — к проблемам, которые мы наблюдаем. Есть популярный мем, который любят повторять LLM-луддиты: LLM — это, значит, дурачок, стохастический попугай, он просто пытается что-то предсказывать, аппроксимировать. Какая-то доля правды в этом, может, и есть, но, конечно, это полная ерунда, потому что мы видим, что система хорошие штуки аппроксимирует — рабочие небольшие системы, которые из-под пера инженера могут и в прод поехать. И едут — прямо на втором мониторе у меня сейчас, во вкладке Claude Code, он продолжает что-то делать. С другой стороны, люди — и луддиты, и нет — любят критиковать LLM за то, что оно периодически галлюцинирует, выдаёт что-то не так. И почему-то недостаточно часто, как мне кажется, говорят о том, что мозги человеческие — тоже нейросеть, и мы сами испытываем проблемы и с вниманием, и с памятью. Есть всякие когнитивные искажения, очень популярные, можно в интернете почитать, есть ложные воспоминания — и это очень-очень похоже. И вся история с мастерской инженеров-менеджеров, где по всем руководствам нужно учиться пару лет, как раз прокачивает твои мозги, твой интеллект как машинку: заставляет не терять внимание с важных штук, учит моделировать сложные системы, смотреть на надсистемы, на подсистемы. А FPF — это попытка дистиллировать все эти лучшие мыслительные практики, но для моделей. Такая нахлобучка в контексте, которая будет заставлять модель тоже следовать лучшим практикам мышления.

[20:08] Александр: То есть это не совсем про контекстную инженерию — потому что контекстная инженерия часто носит более прикладной характер: какие фреймворки для перекладывания файликов мы используем, какие-то контекстные графы, или просто RAG, гигиена инструкций и всё такое прочее. Мне вот интересно — про галлюцинирование и в целом… Есть ещё мысль, что люди довольно оптимистично и с задором чехвостят LLM просто потому, что это не человек. Алгоритм можно поливать бесконечно, потому что на той стороне нет чувств, и там легко и безнаказанно найти соринку в глазу — а у нас у обоих бревно торчит, мы от него уже ослепли и продолжаем игнорировать проблему. И знаешь, что интересно? Если взять аналитический подход и абстрагироваться от эмоций — люди ведь не то что не идеальны или галлюцинируют, они, вообще говоря, ещё и врать сознательно могут. У них могут быть скрытые мотивы, которые нам не видны, они могут так вокруг пальца обвести, что ой-ой-ой. А мы это опускаем, будто этого нет. И помимо того, что реально могут галлюцинировать — тупанул, ошибся, не выспался, — такое же с нами случается и всегда случалось. Просто галлюцинирование LLM — это что-то, что можно осудить, и окей, а галлюцинирование людей мы либо пропускаем, либо подсознательно убегаем от него, чтобы избежать конфликта, потому что на той стороне будет реакция. Людям вообще сложно признавать свои ошибки.

[21:53] Иван: В этом и разница между обычным интуитивным обывательским мышлением и любым шагом в сторону научного подхода. Учёные всегда подвергают сомнению любые свои тезисы, гипотезы, проверяют, перепроверяют. А люди любят жить по автомату, по интуиции, особо мозги не напрягая. Это оптимизация расхода ресурсов, эволюционная штучка — она полезна. Но когда речь о деятельности, которая имеет последствия в реальности, которая рационально направлена на то, чтобы что-то поменять в мире, в жизни или в проекте, — здесь инвестиция в интуитивное, автоматическое мышление выглядит не очень эффективной, потому что оно далеко не всегда правильное. Даже узкие специалисты, которые вроде бы отлично знают свою предметную область, могут ошибаться. Поэтому, смотри: пилотов самолётов готовят прям задрачивать — они хорошо знают, какой расчёт, какая кнопка за что отвечает, могут по памяти довольно точно восстановить процедуру подготовки к вылету. Но при этом всегда — и в гражданской, и в военной авиации — есть чек-листы. И для взлёта, и перед посадкой, какая-то напоминалка. Потому что мы давно признали на этом уровне проблему: у людей хреново со вниманием и с памятью. Стоит себя тормозить и идти по каким-то небольшим — а иногда и большим — формальным процедурам, чтобы сразу повысить шанс доставить нормальный продукт, нормальное решение и меньше потом переделывать. И тут снова вспоминаем нашу любимую программную разработку, даже без LLM. Сколько ты в жизни видел этих движений карточек из In Progress в QA — назад, вперёд, потом вроде бы уже уехало, стейкхолдерам передали, а они говорят: вообще не то сделали. Это история про менеджмент. И системный менеджмент — одно из руководств, одна из больших поддисциплин мастерской, очень важная штука.

[23:38] Александр: В общем, мы пришли к тому, что галлюцинируют все — и модели, и люди, — и задача наша как-то себя от этих галлюцинаций уберечь. Или хотя бы сделать себе машинку, которая будет бить нас по рукам и привлекать наше внимание. И конкретно в программной разработке уже много всяких штук для этого существует. Например, писать тесты — хотя бы какие-то. Или пойти дальше и начать писать по TDD: сначала думаем про контракты, про варианты, которые нам нужно реализовать, пишем тест, потом код, который его реализует. Из TDD родилась замечательная вещь — по-моему, последняя, лет 15–20 назад, BDD. Она менее популярна, она уже про выход на три амиго, когда собираются тестировщик, разработчик, менеджер и вместе пишут на формальном языке — на Gherkin, на какие-то спецификации, — а потом по ним пишут тесты. Замечательная вещь, но пролезает уже со скрежетом, потому что менять процессы в компаниях очень тяжело. Ну и код-ревью — ещё один из подобных процессов валидации. То есть с чем мы боремся? Мы боремся за уменьшение количества ошибок и их фильтрацию на пути пайплайна разработки, чтобы на выходе, в продакшене, этих галлюцинаций — ни людских, ни LLM-ных — просто не было, ну или было минимально.

[23:38] Иван: Да, именно за уменьшение переработки. Мы хотим, чтобы у нас, как в Toyota, Lean Production, был отлаженный пайплайн — чтобы в реальность приезжало как можно меньше багов, желательно вообще ноль, чтобы нам ничего не возвращали, мы не теряли деньги, не перерабатывали, сразу работали эффективно. История о том, как это построить, — явно не тема этого подкаста; я уже намекал, куда идти и что учить. Всё-таки контекст сегодня — это разработка софта с помощью моделей, как остаться у кормушки. Но мы плавно перешли к истории про FPF — давай про него.

[25:31] Александр: Да, мы немножко сделали шаг назад, чтобы понять, с какой проблемой боремся. Тема-то у нас очень абстрактная — был спойлер, что там много разных дисциплин, транс-дисциплин, они все переплетаются. А зачем мы вообще собрались и что пытаемся донести? Мы заземлили это на важность подхода — делать хорошо или делать плохо.

[25:53] Иван: Остаются вопросы, как делать хорошо. И одна из первых реакций, которые я наблюдал в публичном пространстве, когда сделал Qwen Code и понёс его показывать: люди моментально реагировали, почитав README, — какая-то это научная фигня, мне она не нужна, я и так прекрасно знаю, какое решение принять. Хотя в README в какой-то момент приводился очень приземлённый пример — про интеграцию Stripe. Допустим, мы как-то интегрировались, артефакта не осталось никакого, через несколько месяцев всё поломалось, а мы не помним, почему поломалось, кто сделал, на основании чего было принято решение, — потому что оно было принято по наитию, интуитивно. Сам FPF, если считать строчки, — это, по-моему, 65 тысяч строк спецификации, причём она покрывает не всё, что рассматривается в руководствах. А в токенах это 800 с чем-то тысяч, и эта фигня не влезает прямо в контекст. Как мне её вообще было засунуть в Claude Code и в Qwen Code? Попытка у меня произошла совершенно интуитивная, эвристическая: взять самое полезное, посмотреть, что там вообще есть, и попытаться привнести это в разработку. Самая, наверное, полезная штука — это ход в рациональность, так называемый ADI-цикл: abduction, deduction, induction. По-русски это будет очень просто — самая база научного подхода. Мы выдвигаем какие-то идеи, тезисы, что-то предлагаем, как решить проблему, которую уже имеем. Потом анализируем: вменяема ли она вообще, на чём основана — на каких источниках, на каких практиках стоит, чтобы вообще пытаться её проверять. То, что остаётся валидным, мы сразу проверяем какими-то минимальными POC, MVP, хотя бы скриптами, если думаем про разработку. И из этого что-то остаётся, что можно дальше брать в работу. Только вот этот цикл — а это, наверное, 3 процента всех формализмов из FPF — уже показал себя очень полезным. Если ты читал замечательный фанфик Элиезера Юдковского «Гарри Поттер и методы рационального мышления» — рекомендую.

[28:19] Иван: Я последние лет пять вообще никакую художественную литературу не читаю, но в прошлом году, когда добрался до этого фанфика, прочитал его залпом — не мог оторваться. Гарри Поттер там абсолютно научный человек, у него бесконечная рефлексия и внимательность к тому, что сейчас происходит, он постоянно подвергает собственные мысли вопросу: откуда я это вообще знаю, надо ли вообще что-то делать. И это та же самая история. Если мы не просим LLM так думать, оно так думать не будет. Не будет, даже если мы зайдём в какой-нибудь PRO, ChatGPT, Extended Thinking, и он минут 15–20 будет что-то варить на своём латентном представлении. Хороший результат выдаст, конечно, но совершенно неформальный и непроверяемый. Поэтому этот ADI-цикл — первое, что я пытался сделать.

[28:19] Александр: Давай на этом цикле ещё немного остановимся, чтобы точно быть, что называется, on the same page. Мы начали с того, что есть проблема — галлюцинирует всё, мы её обрисовали. Дальше один из фундаментальных подходов к её решению — это First Principles Framework: набор правил, способов мышления, какой-то формальной логики. Много наработок, которые, если собрать вместе, в твоём эксперименте — 65 тысяч строк, неважно. Грубо говоря, MD-файл на шею.

[28:19] Иван: Да, это именно Markdown, это разработка Анатолия Игоревича. Вот это и есть то, о чём мы говорим. Дальше проблема в том, что целиком в контекст модели ты их сейчас засунуть не можешь — да ещё и попросить решить задачу, — будут проблемы. Соответственно, следующая попытка: давай возьмём по несколько способов из этого First Principles Framework и попробуем адаптировать. И первый подход, который ты взял, — это ADI-цикл.

[28:19] Александр: Он состоит из трёх шагов, давай ещё раз проговорим, потому что штука полезная и в собственном мышлении, и в решении своих задач, и чтобы просто взять и написать системный промпт своему Claude Code или агенту, чем вы там пользуетесь. Итак, первый шаг — «предложи», abduction: мы просим LLM сгенерировать некоторые варианты решения задачи. Дальше deduction — анализ всех этих вариантов, второй шаг. И третий шаг — induction, то есть проверка. Вот это один цикл, да? Заканчивается ли решение задачи на одном цикле, или мы запускаем его, что называется, в цикл?

[30:53] Иван: Ну, естественно, у тебя уже на втором шаге какие-то гипотезы могут сразу отвалиться моментально. С Qwen Code это работало, потому что мы говорим про какую-то уже репу. Он на каждом шаге пытается ходить, примерно понимает контекст, смотрит на твой код, на какие-то контекстные файлы, выдвигает гипотезы. Очень важный момент: это не просто формальное общение в чатике — он ещё на каждом шаге пытается создавать артефакты. Каждая гипотеза — это артефакт. Qwen Code сам пишет их в базу, как-то линкует по степеням формальности, и много чего ещё, что сейчас нет смысла обсуждать. Цикл может откатываться, идти вперёд — до тех пор, пока мы не придём к уже проверенным гипотезам. И в конце я оставил такую важную штуку, как внешний трансформер, external transformer: это когда Qwen Code, с промптами в командных скиллах, понимает, что решение по этим гипотезам он принимать не должен — его должен применить человек, потому что мы помним, что работаем с ним вместе. То есть для всех любителей навайбкодить ваншот- или фьюшот-промптами Qwen Code — сущий кошмар, потому что он тормозит. Как раз борется с тем, о чём мы говорили: с интуитивными решениями, которые потом никак не восстановить. Qwen Code же пишет за собой артефакты, и когда ты принимаешь какую-то из гипотез как решение, он создаёт запись в формате ADR.

[30:53] Александр: ADR — это более знакомая штука, давай держаться этого термина. Architecture Decision Record, да. Какой-то документ: почему, когда, на основании чего, всё, что мы проживали в этом цикле, почему пришли к этому решению.

[30:53] Иван: В принципе, уже это работало неплохо. Но в какой-то момент, после новогодних праздников, я просто перестал пользоваться Qwen Code, потому что он далеко не для всех задач нужен, особенно повседневных, — торможение требуется не всегда. И есть другие способы добавить это в жизнь, к которым мы перейдём — либо сейчас, либо чуть позже.

[30:53] Александр: Мне вот непонятно что? Мне непонятен первый шаг — «предложи». Оно откуда берётся, этот список вариантов? Из вселенной генерируется?

[33:47] Иван: У тебя же есть какая-то конкретная проблема. И давай сразу скажем наперёд, когда Qwen Code не нужен. Он не нужен, когда у тебя задача покрасить кнопку — ты понимаешь, что надо из красной сделать зелёную. Не нужен, когда надо создать миграцию в базе данных по уже нормальной Jira-таске или спеке. Но Qwen Code становится полезным, когда перед тобой не задача, а проблема. В чём разница? Задача — это то, что ты уже знаешь, как решать. Ты уже специалист, узкий специалист, маэстро — по наитию скорее всего примешь правильное решение, можешь его отревьюить или не ревьюить вообще. Сделать новый endpoint по образу и подобию остального стиля кодовой базы — не проблема; если он ещё и тесты написал, то даже тесты, как ты писал в том замечательном посте в Telegram, можно не ревьюить. Окей, одобрено. Но если у тебя задача более масштабного характера — может, архитектурного, влияющего не на один проект, а на целую подсистему, на микросервис или ещё что-то, — или нужно принять решение по деплою нового продукта, и тебе кажется, что ты уверен: вот конкретно нужно обязательно докер-сворм сделать. Но давай вернёмся — а на чём ты, как Гарри Поттер, основываешься? Как задеплоить, что выбрать вообще? Там много чего ты сначала не думаешь. В каких облаках у нас уже стартап-компания живёт? Какие есть практики? Мы вообще посмотрели доку или нет? И Qwen Code как раз стремится тебя замедлить. Есть замечательная штука — «Думай медленно, решай быстро», труд Канемана. Там два режима мышления: медленное и быстрое. Быстрое — интуитивное, наученное для щёлканья простых задач, и мы очень любим думать только им. Отсюда растут переработки, переделки, плохие решения. Потому что периодически нужно замедляться и моделировать проблему более доверительно, отдавать себе отчёт, насколько мы уверены в правильности решения. FPF, системное мышление, Qwen Code пытаются делать именно это — замедлять нас. Но никак не заставят и не научат определять, на каких задачах замедляться, а на каких нет. Это уже часть мастерства, которому в рамках подкаста и Qwen Code не научишь, — этому надо учиться в упомянутой мастерской инженеров-менеджеров.

[34:00] Александр: Окей. Итак, мы сейчас в точке, когда разобрали один из примеров из FPF. Мне понравилась эта идея — предложи, проанализируй и проверь, — потому что это что-то прикладное. То, что можно условно взять, нагуглить или поболтать с Клодом: он найдёт тебе спецификацию, вместе с ним ты её сюда же поставишь и попробуешь хотя бы в рамках одной сессии решить задачу с таким подходом. Это уже что-то, что можно адаптировать. Может быть, есть ещё примеры или варианты?

[36:56] Иван: Есть способы намного лучше, чем Qwen Code. Я хотел очень чётко подсветить именно этот момент: Qwen Code, хоть и набрал какое-то количество звёзд и интереса, и люди периодически будут на GitHub выше меня, — оно сдохло или нет? Скорее сдохло, чем нет, потому что дистиллирует очень малую часть FPF в себя, нужен далеко не для всех задач, и я сам уже перестал им пользоваться. Возможно, из этого вырастет совершенно отдельный продукт. Но в рамках мастерской, в рамках попыток пользоваться FPF, мы пришли к выводу, что самый универсальный и полезный способ применять его — не только в разработческих задачах софтовой инженерии, а вообще в любых задачах инженеров-менеджеров из мастерской. Там ведь не только программисты — там директора по развитию, разные роли, но все успешно пользуются системным мышлением. Короче, самый лучший способ такой: ты берёшь спеку, пихаешь её в ChatGPT — желательно PRO, — в проект. Он, конечно, не засовывает её в контекст, а пережёвывает под капотом каким-то высокооптимизированным RAG’ом, как-то индексирует. И желательно, по моим наблюдениям, ещё написать в проекте инструкцию: у тебя, товарищ мой, есть FPF, он у тебя лежит в контексте в том или ином виде, пожалуйста, для решения любого моего вопроса пользуйся им.

[37:07] Александр: Кстати, мы на старте не сказали, что на релизе этого подкаста будет ещё и бесплатный артефакт для всех интересующихся — в формате, скорее всего, Markdown или PDF-документа, а-ля методичка, где будут все ссылки, более подробно расписанные примеры использования FPF. Имейте в виду.

[37:38] Иван: Я чаще всего, практически на ежедневной основе, пользуюсь именно таким подходом, и он решает совершенно разные задачи, потому что заставляет модель внутри думать по этим шаблонам. И ADI-цикл, и — насколько это достоверно — Deep Research тоже намного качественнее выходит из-под проекта с FPF. Потому что он не просто сгребает кучу источников и пытается найти между ними общее, а помнит ограниченный контекст. Это очень важно, это один из формализмов системного мышления — bounded context. Кстати, из контекст-инжиниринга это, наверное, самый важный постулат: чтобы у нас никакого мусора не было. Это самый базовый способ, он хорошо работает. Единственный минус — FPF в контексте приводит к тому, что твой ChatGPT или Claude Desktop с Опусом думает намного дольше. Последние запуски у меня были по большим задачам: ChatGPT Pro на Extended, который в тарифе за 200 баксов, думал 45 минут — подготавливал артефакт, системный анализ, нужно было сделать доку, презентацию. Потом по правкам думал ещё 35. Но результат на выходе такой, какой, наверное, какой-нибудь McKinsey за 30 тысяч долларов выдал бы — и то, может, не такого инженерного уровня.

[39:25] Иван: Попыток на самом деле было больше, потому что хочется всё-таки приоткрыть этот довольно высокий порог входа. Я пытался с помощью самого FPF, опять же в режиме проекта, понять, а как бы нам в Claude Code работать по FPF. Были попытки, неоднократные.

[39:25] Александр: У меня сразу вопрос, потому что ты сейчас что сказал? Добавляем в проект — это как бы проект в рамках приложения, которым ты пользуешься, там Claude Code?

[41:15] Иван: Даже не Claude Code — это вообще не агент, это именно чатики-интерфейсы.

[41:15] Александр: Да-да, чатик-интерфейс, и там есть некоторое пользовательское пространство, называемое проектом, в рамках которого у тебя есть чатики, и ты можешь туда файлы закидывать, что-то в контекст накидывать. И вот туда ты прям можешь взять этот Markdown-файл в 800 тысяч токенов и просто закинуть драг-н-дропом, да?

[41:38] Иван: Да, и он классно индексируется, потому что уже в формате Markdown, весь прошит формальными тегами — очень хорошо подготовлен для индексирования. Поэтому работает просто великолепно. В мастерской у всех отзывы волшебные. Главное — запихнуть не просто в чатик, а именно в проект, и ещё инструкцию, потому что есть низкий шанс, что оно всё равно будет куда-то в сторону уходить.

[41:38] Александр: Да, тут уже с опытом взаимодействия с подобными системами понимаешь: недостаточно просто положить рядом, важен этот базовый промпт — условно CLAUDE.md или его аналог, который каждое сообщение отправляется, скажем, в Anthropic или в OpenAI, — чтобы в нём была ссылочка: думай по вот этим правилам, которые написаны тут. И дальше это большое всё в контекст не влезает, и, скорее всего, — ты, я думаю, предполагаешь, и вероятнее всего так и есть, — используется какая-то векторная база данных.

[41:38] Иван: По любому какая-то.

[41:38] Александр: По любому. И как это работает? Он берёт предыдущий контекст, запрос-промпт от пользователя, делает векторный поиск по этому First Principles Framework, достаёт что-то похожее по векторному поиску, и дальше правила подтягиваются с помощью RAG, идут в контекст, отправляются в модель — и возвращается результат. Как-то так.

[41:38] Иван: Как-то так, при этом по всем предположениям. Когда началась движуха с FPF, я тогда всё ещё был исключительно апологетом Anthropic — у меня даже подписки на ChatGPT долгое время не было, я от него отказывался, сидел только на Claude Code и Claude Desktop. И тогда уже пошли разговоры, кулуарные и открытые, в мастерской, что лучший способ — это ChatGPT, именно PRO, именно за 200 баксов, именно с максимальным Extended Thinking, и именно там хорошо работает FPF. Я долго этой идее сопротивлялся, долго сидел на Опусе, долго подвергал сомнению: ну это же просто RAG, этого же недостаточно, оно же не попадает в системный промпт запроса, просто какие-то куски вытягивает. Интуитивная чуйка говорила, что должно работать плохо. Но в какой-то момент я всрал целиком недельные лимиты на Anthropic за 200 баксов чудесным образом. Первый раз до этого я не знал, как у меня получилось: нужно было просто OpenClaw ночью в кране запустить, имплементировать PRD на 52 страницы — получилось. Взял ChatGPT за 200 баксов, попробовал — и да, здрасте: для FPF и такой работы это всё-таки работает лучше. Не могу сказать, что Опус справляется хуже, но оно как-то индексируется совершенно чудесным способом и работает лучше, чем Qwen Code, лучше, чем какие-то скилл-паки. Потому что в скилл-паке я пытался делать уже продвинутые вещи, использовать утилиту twick-cc, которая перегружает системные промпты разных кусков Claude Code, — работает плохо. К сожалению, плохая новость всей истории в том, что FPF сделан для LLM, причём способом, который работает лучше всего именно в формате чатика.

[44:31] Иван: И ещё одна плохая новость: чтобы извлечь максимальный толк, нужно, чтобы у тебя в голове всё-таки были интернализированы какие-то понятия системы, умного мышления, подходы. Но хорошая новость в том, что если у тебя есть подписка на этот чатик, ты можешь пойти по самому простому пути: создать проект, засунуть туда в контекст эту хрень, и даже по любым жизненным, бытовым вопросам оно начинает работать лучше. У меня у жены есть ChatGPT, я ей создал проект, запихнул туда FPF, в инструкции написал — думай всегда по FPF, но человек не инженер, общайся с ним по-человечески. Через несколько дней она мне сказала: вау, ничего себе, оно умнее стало. То есть просто на бытовом уровне восприятия чувств это воспринимается так, будто оно поумнело. Ты получаешь не просто лебезящий ответ — он всё ещё толковый, — но он тебе ещё и объясняет: вот так, потому и потому, потому что он прогнал этот идеальный цикл, какие-то важные вещи просчитал. Можем в конце, если время останется, пройтись — у меня есть список, я подготовил самые важные, ключевые идеи из FPF, которые нужно понимать, чтобы с ним эффективно работать. Но для тех, у кого нет времени или желания идти полностью в системную инженерию и планировать обучение на несколько лет, а есть хакерский майндсет, работает и такой подход: ты ему говоришь — что ты вообще такое, что в тебе есть ценного, важного, как ты работаешь, в чём твоя польза, а то мне какой-то Иван Закутний пришёл на подкаст к Александру Пахомову, какую-то херню рассказал, есть ли в этом смысл. И он тебе нормально расскажет. Я в принципе почти с такого же и начал.

[45:57] Александр: Да, ты сейчас описываешь юзкейс, который я для себя открыл какое-то время назад: развитие, обучение, проведение времени с тулой, с чатиком, не только чтобы решить задачу, узнать факт или посмотреть погоду через какой-то API-вызов, а чтобы качать свой мозг. Это очень интересный юзкейс. Год назад я слабо представлял, что мог таким заниматься, — я скорее тупел от такого диалога, чем узнавал что-то новое, много было вопросов. Но сейчас, пока у меня два-три агента в параллель шуршат над сложными задачами, у меня есть ещё какое-то окно внимания, которое я не хочу направлять на социальные сети, а хочу — на что-то исследовательское. И вот этот хакерский майндсет начинает работать: я тут же в tmux открываю вторую пейн и начинаю общаться с Клодом, узнавать, как там устроено вот это. Можно початиться про проект, который изучаешь, про какой-то подход — он сам всё нагуглит, ссылки пришлёт, ты ещё провалидируешь, что это не галлюцинация. Тот же FPF, я думаю, он найдёт на GitHub через Qwen Code, и эту спеку тебе предложат даже прямо сейчас напечатать. В этом нет никакого труда. В этом плане стандартный веб-серч для меня уже умер: моё окно в интернет, в digital в широком плане, — это Claude Code, и с ним можно всё узнать, посмотреть, накидать. Поэтому для тру-хакеров сам подкаст, наверное, особой ценности не несёт — они всё это могут узнать через чатик. Но ценность нашего разговора не только в знаниях: вообще поговорить всегда приятно, и послушать людей приятно. Но у меня возник вопрос. Мы сейчас говорим про способ интеграции в ChatGPT Pro, в десктоп-приложение. А я вот хакер, я в терминале сижу, ChatGPT себе точно покупать не буду — у меня не такой юзкейс, у меня Claude Code в сердечке. Могу ли я как-то туда попробовать это интегрировать?

[48:41] Иван: Можно посмотреть в сторону Qwen Code всё-таки. Почему скилл-пак не работает? Скилл-пак — это ход на то, что мы делегируем самому Claude Code следование правилам, чтобы он не уходил, но, к сожалению, он уходит. А Qwen Code вносит тебе фрикцию, заставляет идти по конкретной цепочке команд, ты всё ещё остаёшься у руля. Можно попробовать, но, к сожалению, этого всё-таки очень мало. Поэтому если настрой серьёзный, надо быть готовым. У тебя подписка сервера, ты по ключу Claude Code пользуешься — значит, ты уже обанкротился. У тебя есть подписка, да, у тебя их, возможно, две, обе ещё и на 200 баксов, значит, у тебя есть Опус — и можно пойти рядом в Claude Desktop, засунуть туда всё-таки FPF, и, пока ждёшь, пообщаться с ним. Тебе ничего не мешает, он же на расстоянии вытянутой руки.

[49:57] Александр: Интересно. То есть почему в десктопе работает, а в Claude Code не работает — потому что десктопное приложение просто реализовало одну фичу: drag-and-drop файликов в проект и RAG по ним. Если это есть в Claude Code и работает нормально, то оно тоже заработает.

[49:57] Иван: Оно не заработает, потому что это категориально разные продукты. Claude Code — это агент, у него есть какая-то среда, она ему доступна, куча возможностей напихать себе что-то в контекст, у него есть агентность, есть сразу выход в тот самый мир, который он что-то меняет. И для этого ему нужно, чтобы в контексте оставалось как можно больше свободного пространства. Вряд ли здесь даже поможет миллионный контекст, который сейчас у Anthropic в бете. Я пробовал брать Gemini с миллионным на Pro, пихать туда FPF — вообще не работает.

[51:59] Александр: Я думаю, для этого надо контекст миллионов на сто, чтобы эти 80 тысяч токенов не имели…

[51:59] Иван: Я не думаю, что даже это поможет. Мы вряд ли пойдём без смены архитектуры к миллиарду токенов контекста, потому что есть всякие феномены типа загнивания контекста, lost in the middle, когда инструкции теряются в середине. Это всё старая больная история, подождём, что будет в будущем.

[51:59] Александр: У меня есть такой инженерный вопрос. А что бы мне помешало в Claude Code, как в приложении, в TUI, — будь у меня доступ к его коду — где-то там написать те же самые инструкции, что работают в десктопе: обогащай контекст RAG’ом из системного, ну, юзер-промпта. Почему это не будет работать?

[53:14] Иван: Я не говорю, что не будет, — каким-то образом будет. Последний скилл-пак, который я пробовал, как раз про эту подобную штуку, и там намного больше кишочков FPF реализуется: он больше пишет артефактов, следит за сессиями, за контекстами в директорию .fpf, и как-то начинает этому следовать — ему даже не нужно ходить в спеку, потому что промпты, подпромпты у него через twick-cc перегружены. Но в какой-то момент, после какого-то компакта, он резко превращается в свой дефолтный Claude Code и отходит. То есть можно пользоваться, но это те же две плохие новости, которые я сказал. Чем больше ты сам разобрался, на чём это основано, чем больше прокачал свой интеллект, интернализировал эти подходы, мыслительные машинки из дисциплин, которые рассматриваются в интеллект-стеке… Интеллект-стек — это тоже штука, разработанная Левенчуком, где перечисляется группа дисциплин, которые нужно на каком-то уровне понимать, чтобы в итоге у тебя в голове сложилась системная инженерия. Там не только STEM — там ещё научная этика, эстетика, риторика и что-то ещё. И когда ты это всё у себя в башке интернализировал, тебе в принципе уже и Qwen Code не нужен, и скилл-пак не нужен: ты просто берёшь Claude Code, садишься и начинаешь херачить по этим рельсам.

[53:56] Александр: О, вот это очень интересно и очень откликается внутри. Чем больше я работаю с Claude Code, проникаюсь им и учусь с ним разговаривать какому-то способу мышления, оно, наверное, не так формализовано, и терминология неприменима к тому, как я мыслю, но по сути очень близко к вот такому последовательному, с какими-то проверками, не спеша, без всего лишнего, с валидацией на шагах. И когда этому научаешься, ты такой — ну так это ж просто работа. Сядь, чуть-чуть подумай, напиши нормальный депромпт, поитерируйся — и решишь задачу. Интересно, что вот это ядерное знание, в ядре которого лежит эта логика — ладно, FPF назовём, — оно может быть не обязательно сконцентрировано в туле, а может перетекать немножко и в голову оператора, и где-то быть на стыке, а может быть и в операторе. То есть это сущность, которая между двумя интеллектами перетекает. По-хорошему для эффективной работы она должна быть и там, и там, но само её наличие в этой связи «интеллект искусственный — интеллект натуральный» качество решения увеличивает. И в этом плане способ интеграции — не засунуть в проект, не добавить скилл-пак и не использовать Qwen Code, а просто самому научиться подобному мышлению.

[55:43] Иван: Конечно, самый надёжный способ — засунуть себе это в голову. Буквально сегодня в Telegram-чате Анатолия Игоревича по его блогу я задавал вопрос про обучение, и он написал очень важную вещь — в ответ на моё сообщение, что паразитировать на FPF до какой-то степени можно, но, к сожалению, чтобы эффективно работать и решать реально организационного масштаба проблемы, которые у меня сейчас есть в стартапе, без прохождения руководств в мастерской не получится — нужен симбиоз. Он ответил вот что: в FPF, даже в таком большом, какой он сейчас есть, много чего важного, концептуального, понятийного из руководств, из интеллект-стека, нет. Того, что нужно, чтобы быть способным качественно задавать этот масштабный контекст для работы с FPF — неважно в каком формате. Неважно в каком, потому что ты можешь создать проект — я сейчас так работаю по другим проектам, — а можешь отдельную директорию, напихать туда чего-то важного и запустить условный Claude Code с какими-то маленькими инструкциями, с маленькой дистилляцией по FPF, и он уже будет работать лучше. Так что да, ты совершенно прав, раскопал очень важную штуку: делая такой большой шаг назад — чтобы остаться у кормушки в нашем новом дивном мире, — нужно в первую очередь прокачивать собственные мозги. Как парадоксально ни звучит: мозги искусственные изобрели, а прокачивать собственные надо с ещё большей силой.

[57:29] Александр: То есть замены не произошло — произошла какая-то конкуренция, что ли, или акселерация.

[57:29] Иван: Акселерация. Если возвращаться к Канеману, произошла именно акселерация быстрого человеческого мышления. Модель, даже если мы берём эти ризонинги, — насколько я понимаю, я, конечно, не AI-ресёрчер, — это не совсем то медленное мышление и моделирование, которое человек делает в башке. По большому счёту модель всё-таки занимается быстрым мышлением, и намного быстрее человека, потому что не ограничена этой мокрой нейросеткой — она на кремнии фигачит, матрицы перемножает. Замечательно. Произошла амплификация конкретного куска: появилась технология, которая позволяет брать конкретные домены, системки, как-то их моделировать, искать какую-то онтологию, производить автоматизации — но всё это больше точечно, конкретные кейсы. До AGI и терминаторов, кажется, далековато, но текущие модели очень умные и очень полезные. Мы не будем тут заниматься луддизмом. Это история про киборгов, про extended mind, extended cognition — когда тебе надо выбираться из своей головы, отдавать отчёт, что нужно быть в симбиозе, писать лапками больше, использовать в разработке более формальные, взрослые подходы. Всё популярнее становятся ходы на формальные верификации с помощью моделей. В принципе, невозможно было представить, чтобы мейнстрим так часто говорил слово «TDD», как сейчас, — через все эти AI-ные истории оно стало популярнее, и идут попытки тыкаться в разные методологии. Но важно понимать: то, что несёт в себе FPF, стоит немного на высшем уровне, чем эта прикладная штука. Потому что TDD хоть и полезно, но это конкретные методы работы, и они не всегда эффективны. Мы все знаем про Agile, про Scrum — их везде последние десятилетия пихают, а что-то как-то особо эффективнее не работает, потому что с реальностью разорвано.

[59:34] Александр: Слушай, ну мы сейчас, кстати, про Agile и Scrum — я думаю, это очень близкая каждому слушателю штука. Кто работает в IT и способен воспринять информацию в этом подкасте, знает, что такое Scrum, Agile, спринты и всё это. И у нас это не по плану, но я бы сделал такой твист, чтобы немного разгрузить мозги и переключиться. Подобные практики лично для меня и так не работали. Я всегда был не то чтобы хейтером, но более чем умеренным скептиком, и следовал этим, скажем так, церемониям — она даже так и называется, — просто потому что не хотел конфронтации с руководством и потому что надо было. Но в глубине души всегда знал: вот я буду строить свою компанию, и в моей компании никогда не будет ни спринтов, ни Scrum, ни Agile, потому что это чушь. И сейчас смысл этой чуши прямо на поверхность выдвинут прогрессом, и тебе говорят — а вот сейчас-то его уже глупо использовать, потому что итерация схлопнулась, если не до минут, то до часов.

[59:30] Иван: Ну, ты имеешь в виду итерацию именно разработки фичи.

[59:34] Александр: Да-да, если ты хочешь что-то сделать и делаешь это за настолько короткое время, что фреймворк в виде Agile тебе и не нужен.

[1:00:57] Иван: В таком виде, в каком он продаётся сертифицированными скрам-мастерами и всеми прочими agile-истами, — я сначала хочу сказать, что полностью с тобой согласен. За свою недолгую инженерную практику я не встречал ни одного адекватного человека с лычкой «скрам-мастер». К сожалению, каждый раз оказывалось, что говорить не о чем: человек очень сильно гуманитарий, совсем не инженер, мало чего понимает в менеджменте — что удивительно — и сам до конца не может объяснить, с какой практикой связаны эти методы организации работы, почему именно так, почему мы взяли какую-то модель откуда-то и слепо нахлобучили на нашу конкретную компанию. Никто этого объяснить не может. Концептуально в этих моделях какая-то ценность есть, они всё ещё могут быть полезными, но только когда часть из них напильником допилена. Потому что если у тебя разработка фичи схлопнулась до часов, ну или до дня, может, до двух, если фича большая, то что-то более высокоуровневое — стратегирование, общекомпанийское — всё-таки не может сильно схлопнуться. Оно тоже, я ускоряю какие-то ресёрчи, может, схлопнулось с недели до трёх-четырёх дней, и какие-то циклы всё ещё имеют место быть. Но, наверное, не в таком виде, когда к тебе приходит евангелист Agile. Эрик Мейер, кстати, про Agile записывал — у него была конфа; кто не видел, может ко мне в личку прийти, я скину ссылку. Там очень интересно: он с пунцовым лицом ругается практически матом на Agile и на всю эту очень плохую историю, которая выбивает инженерию.

[1:03:59] Александр: Я с этим полностью согласен. Почему мне эта тема интересна сейчас — потому что внутренне я всегда понимал, что акселерация какой-то части нашего мышления, этот прогресс, эта революция подсвечивает вещи в нашей индустрии, которые были откровенными костылями либо совсем чушью, — и они просто отпадают. И вот в моей практике отпадает код-ревью как что-то, что нужно делать обязательно. Почему-то в большинстве компаний код-ревью было обязаловкой, а то ещё и барьером: человек должен посмотреть и сделать аппрув коду. Я тоже думал, что в целом это норм, частенько помогает. Но если бы его не было, а система валидации кода была бы выстроена иначе, более автоматизированно, вроде бы никто бы и не пострадал. Мне интересно, что ты думаешь про код-ревью?

[1:03:59] Иван: Последние две недели в нашем стартапе код-ревью наконец-то появился — и делает его Codex. До этого код-ревью был скорее ритуалом, на котором никто из моих коллег никогда никаких багов не находил, поэтому смысла ни у кого не имел. А до появления засилья ИИ в разработке у меня было очень элитарное, почти религиозное отношение к код-ревью. Во-первых, оно было полезно для контекст-шеринга: особенно если ты не видел сервис до этого, а тебе принесли на ревью — полезно задержаться. И тогда я топил, что если мы код-ревью делаем, то давайте закладывать на него время, чтобы человек не просто посмотрел на корректность, как линтер, на синтаксис и минимальную семантику, а углубился — может, мы что-то поломали, какой-то инвариант, — посмотрел хотя бы 30 минут. Сейчас же я не могу сказать, что код-ревью полностью потерял смысл, и не могу сказать, что ревьюю весь код, который мне выплёвывает Claude Code или Codex, но я всё-таки смотрю хотя бы минут 10 последний блок, этот PR, куда я уже буду его лить, — просматриваю наискось. И просто из-за насмотренности стабильно нахожу какую-то херню. Когда пришёл этот интегрированный Codex, он теперь делает это за меня. Цикл такой: Codex — сейчас я немного перешёл из Claude Code в него для более простых задач, просто потому что подписка появилась и надо утилизировать, — честно говоря, стал лучше. Когда я пробовал его на 5.1, у него была история, что, чтобы прочитать Markdown-документ, он писал скрипт на питоне; я тогда попробовал и сразу подписку отпилил — до свидания, Sonnet, привет. Сейчас он стал получше и хорошо справляется: в цикле сам себя через PR, через GitHub мучает, и в итоге приносит тебе код с пальцем вверх, на который можно посмотреть уже не 15, а 2 минуты. Но это для больших изменений, важных. Если там багфикс или что-то ещё — вперёд, и QA. Часто оно всё рабочее и сразу.

[1:06:23] Иван: Поэтому да, тут с тобой согласен. Здесь важнее история про изначальное проектирование, про системное мышление, про FPF — чтобы сначала написать implementation-план. Не тем пользоваться, что встроено в Claude Code, — хотя это в принципе неплохо, он себе генерирует чек-лист, это лучше, чем ваншот, — но всё-таки всякие пердишки и прочие Markdown-документы, которые выходят из-под чатиков по проекту с FPF, у меня вызывают намного больше доверия. Я читаю их, и они выглядят не просто пытающимися. Раньше, когда FPF не было, у меня был флоу такой: захожу в Опус, накидываю контекста и говорю — вот давай, ты самый лучший в мире продакт-дизайнер, опрашивай меня итеративно по одному вопросу, пока полностью не исчерпаем и не покроем, и выплюнь в полуформальном формате PRD. Эти документы уже были хорошие, лучше, чем планирование Claude Code, ИМХО. Но то, что выходит с FPF, — намного лучше. Один из закрытых проектов, тот самый, на котором я сжёг недельные лимиты, — это была попытка сделать ещё недопиленного автономного агента на Go, который многие штуки из FPF интернализирует внутрь в виде бэкграунд-процессов для мутации памяти и прочего, очень тяжёлая штука. И с FPF я PRD для неё два дня писал — вычитывая, перечитывая, правя, не с утра до вечера, но часа по три-четыре в день. Следующий шаг: из этого PRD также составить — 250 вышло Gherkin-спецификаций по BDD. И потом это было отдано на откуп бесконечному крон-циклу на OpenClaw-сервере, который эту репу делал. Причём как? Делегируя задачки Claude Code — не он сам делал: OpenClaw кодить нормально не может, хотя там вроде Anthropic и SDK используются, он херню делает. Где-то эта штука сама собой сожрала все лимиты и покрыла, наверное, 85–90 процентов инвариантов, которые были написаны в BDD. Такой подход тоже может кому-то быть полезным попробовать.

[1:08:52] Александр: Мы на самом деле мало важного раскрыли из FPF и всей этой истории — рассказали только про ADI-цикл как базу рационального мышления. У слушателя может создаться впечатление: ну и ладно, я соглашусь, что быстрые интуитивные решения зачастую плохие, буду просто сам тормозить.

[1:09:36] Иван: Ну, во-первых, не будете. А во-вторых, есть ещё штуки — примерно 9, может, больше 10 несущих концептуальных, понятийных конструкций в FPF, и из них, наверное, 5–6 прям важные, которые можно попробовать рассказать.

[1:09:36] Александр: Да, давай прям одну за одной рассказывай. Честно, я не знаю, что ты будешь говорить, поэтому мне самому интересно.

[1:09:36] Иван: Да-да, потому что этого не было в плане, эта штука у меня осталась во втором документе, который я готовил для подкаста. Самый основополагающий — ADI-цикл — мы уже рассмотрели, повторять не будем. Но ещё важно, что FPF стремится формализовать уровни доверия. Условно в Qwen Code их четыре: L0, L1, L2. То есть на цикле идей мы не просто выдвигаем гипотезы — они у нас изначально все L0. Что-то предположили, чистое творчество, и по ходу deduction и induction — анализа и проверки — эти гипотезы и уровни доверия к ним двигаем выше. L0 — это что? Есть какое-то высказывание, никакого подтверждения, что оно вообще правильное. Это нормально, это творческий инженерный процесс. Но через какие-то веб-серчи или написание тестов, минимальных скриптов, которые пишет Qwen Code а-ля Claude Code, мы потихоньку поднимаемся до L1: у нас уже есть что-то, что имеет смысл и основано на таких-то источниках, внешних или внутренних. Это очень важная штука, потому что, если пробовать Qwen Code, он в ответах прям будет писать L0, L1. И нужно это для того, чтобы через неделю, вернувшись к каким-то сессиям, документам, мы понимали, на чём это основано, и минимальный формализм могли в своей голове распарсить.

[1:11:50] Александр: А какой критерий перехода с одного уровня доверия на другой? Есть какой-то прям чёткий критерий, по которому мы говорим: вот теперь это L0, это L1, а это L2?

[1:11:50] Иван: Прямо сейчас затрудняюсь чётко ответить, но минимальный критерий перехода на L1 — это когда… Он выдвигает какую-то идею, допустим, четыре или три идеи. Вернёмся к деплою. Деплоим по SSH, просто SCP-копией по FTP, и там скриптами запускаем. Сначала, создавая эту сессию в Qwen Code, ты можешь просто попробовать нажать команду, по-моему, q1-hypothesize, и написать ему два слова — проблему. Ну, такой ответ получишь, непонятно на чём основанный. Желательно какой-то контекст нагрести, чтобы у него уже было в CLAUDE.md или где-то ещё понятие, с чем оно работает. Чем больше этого понятия, тем больше он может предложить. Допустим, в контексте есть информация, что у вас AWS и уже где-то что-то используется, — он, естественно, будет предлагать это как одну из гипотез деплоя сервиса. Но этого мало. На фазе deduction он возьмёт эти же идеи и будет вместе с тобой или сам пытаться хоть какой-то простой логикой доказать себе, какая из идей имеет смысл: берём ли мы её дальше в работу, двигаем на L2 туда, на induction, или сразу хороним. Например, он пошёл, провёл веб-серч и говорит: есть вариант, SCP и FTP полностью убираем, потому что это какая-то динозавровская херня. Рассматриваем вариант Kubernetes — раскатываем тебе docker в своём формате, когда у тебя ноды, тиры, вся эта история, — либо Docker Swarm на той же тачке, куда деплоим просто ради того, чтобы рестартовать контейнер, если он упал. И дальше на deduction он может, если какие-то MCP или что-то подключено, сам пытаться найти подтверждение каждой гипотезе — либо тебя спрашивать, либо в интернет ходить. В итоге всё заканчивается вопросами уже про больший системный уровень: а что у вас за бизнес, какой у вас текущий RPS. И вот тогда у тебя уже будет уверенность, почему ты выбрал docker в своём варианте на одной тачке. Он тебе оставит документ: приняли решение, потому что это дёшево, потому что работает хорошо, нам приемлем blast radius — ладно, упадёт и восстановится само собой. У нас B2B, в котором максимальный RPS будет 5 в пиковой нагрузке. Kubernetes не нужен, потому что принесёт огромный операционный расход. Замечательно. Какой-нибудь девопс скажет: да это же и так понятно, блин. Да, и так понятно — но какому-нибудь разработчику, который всю жизнь работал просто с кодом, это будет полезным артефактом. Дополнительный плюс в том, что весь этот FPF-flow оставляет за собой структурированные, формализованные артефакты — decision records, где есть дата, есть причины. И ты автоматически получаешь штуку, которую можешь перенести в какой-нибудь SlashDocs или Atlassian, в какой-то хендбук, и она будет не просто написана Васей Пупкиным от балды. Я таких документаций видел кучу, где приходят те же скрам-мастеры, перепечатывают интернет, и никто этим не пользуется. А тут остаётся артефакт понимания: почему, когда, кем.

[1:15:36] Александр: Мне кажется, это очень важный момент, который с этой революцией как раз должен подсветиться. К слову о том, что что-то отпадает естественным образом, а что-то, наоборот, подтверждает свою ценность — как подходы TDD, BDD и вот это ведение проектной документации, документации принятия решений, структурированной, нормальной. Оно безумно важно. И этот девопс, который придёт и скажет «так оно и так понятно», — так я ему и скажу: так оно тебе понятно, я тебя утворю, а что мне делать дальше?

[1:15:36] Иван: Да-да, и это тоже интересная штука. Одно из очень важных, самых первых подготовительных курсов из мастерской инженеров-менеджеров вводит понятие экзокортекса. Мы сходу начинаем говорить, что у людей память убогая, а мыслить медленно люди могут, только если они пишут. Я вообще пришёл в мастерскую от своего ментора по программной инженерии, который у себя в блоге писал про важность мышления письмом и кидал ссылку на блог Анатолия Игоревича Левенчука — старый легендарный пост, по-моему, 18-го года на «Живом Журнале», где он рассказывает, почему мышление письмом — важная штука. Почему, если ты не можешь написать ничего своими словами, ты вообще не подумал — или подумал, но никуда. Когда ты пишешь, у тебя есть дорожка из хлебных крошек, к которой можно вернуться. И тут важно именно в минимально-формальном, структурированном варианте. Есть проекты прикольные, стартапы были на слуху, не помню название, где мы логируем все промпты Claude Code прямо в git. Все промпты. Ну, это уже хорошо, уже лучше, смысл есть. Но качественно какая разница? Просто промпты, что мы там плясали, — и вот этот продукт идеального цикла с ссылками на какие-то улики, почему решение было принято, когда. И ещё есть одна важная штука из FPF: у каждого такого решения, вообще у всего, есть предположительный срок жизни. И в какой-то момент в жизни проекта хорошо бы вернуться и перепроверить, актуально ли оно вообще, или пораньше что-то сделать по-другому.

[1:18:04] Иван: Что ещё рассказать? Можно про жизненный цикл любого такого артефакта — от идеи до продакшена. Это тоже цикл, но другой. Не цикл мышления, вот этой формальности, которая двигает уровни доверия, а цикл более творческий. Мы что-то исследуем, придаём этому формы, делаем какие-то модели. И это опять история про то же самое, с чего мы начали: либо мы делаем лапками шлёп-шлёп, и оно по наитию куда-то, либо моделируем — остаются артефакты мышления письмом, собраны доказательства. Весь этот процесс выглядит очень душным, типа: блин, куча бумажной волокиты. Но, уважаемый слушатель, раньше, когда у нас не было LLM, это всё нужно было писать лапками. А сейчас, следуя минимальным правилам какого-то FPF в контексте, в этом формальном, проверенном и более доверительном варианте оно всё генерирует быстро. Ну как быстро — оно может думать полчаса, но выдаёт то, что раньше руками и мозгами очень умному инженеру нужно было делать неделю, а то и две.

[1:18:04] Александр: Тут надо каждый раз, когда возникает эта естественная внутренняя реакция «ой, как это тяжело», понимать причину — она в нашем предыдущем опыте. И действительно, вот это программирование, даже не просто печатание, а вычитывание, итеративная работа, — мало кто таким занимался, потому что очень много сил и мыслетоплива тратится. А сейчас как раз это можно делегировать — основную рутину, — и оставить себе только самое интересное: верхнеуровневую вычитку и финальную валидацию, то, что тебе интересно делать. Остальное можно делегировать. Это прикольный способ рефлексии над собой в современном мире. Я реагирую на это, потому что исхожу из своего прошлого опыта: мне коммитить, деплоить, тесты писать долго, поэтому я противлюсь реализовать эту систему в жизнь, поэтому эту идею не хочу двинуть. И если это так, можно просто головой встряхнуть и сказать: так это всё сейчас делается за часы, так, может, самое время эту идею продвинуть. Полезный такой хак для себя. И знаешь, мне было бы интересно поговорить про путь от идеи до продакшена, а после этого сделать небольшую паузу. У меня есть вопрос: а как подобное можно применить в уже существующих проектах у людей? Потому что большинство слушателей, я думаю, — перед ними открыт один, два, три, четыре проекта в IDE, в VS Code или Claude Code, они уже с ними работают и получают за это зарплату. Как им применить это так, чтобы максимально извлечь пользу?

[1:20:38] Иван: Ну, это тоже большая история, опять можно уйти в системную инженерию. Человек должен как-то понимать, какая у него сейчас степень ответственности и за что, и какая степень власти на текущей позиции — можешь ли ты вообще менять какие-то процессы. Если ты в позиции чистого individual contributor, который не может ни на что повлиять даже в своей команде, то минимальное, что можно сделать, — научиться, если даже не в мастерской инженеров-менеджеров (хотя в идеале хотелось бы посоветовать всем пойти туда, повысить свою агентность, добиться повышения, стать менеджером или директором по развитию и вообще поменять мир к лучшему, но я понимаю, что мало кому это интересно). Поэтому минимально — даже не идти в мастерскую, у меня прям сердце щемит, — но взять FPF и попытаться интернализировать в собственной голове важность описаний задачи. Чтобы на этапе, когда вам задачу делегировали, смотреть трезво на её описание и, может быть, с этим же FPF проанализировать. Потому что чем больше вы сделаете адекватных встречных шагов, вопросов к вашему менеджеру или тимлиду, чем лучше сразу формализуете задачу, тем качественнее её сделаете — и тем самым будет меньше переделок, и вы уже будете лучше работать, продуктивность повысится по всем проектам. Несмотря на то что куча бесполезных звонков и прочей ерунды останется, можно вот так хотя бы сделать себе жизнь проще.

[1:21:06] Александр: Применить практики FPF в отношении собственного мышления, валидации и верификации тех задач, что к тебе приходят.

[1:21:06] Иван: Даже проверки идей — просто посмотреть на то, что тебе принесли. Кстати, знаешь, что я заметил? На момент, когда я Qwen Code сделал и какое-то время с ним работал, тестировал его, вот это механическое, даже дебильное набивание команд — q1, hypothesize и ещё что-то, — где-то через недельки-две вот это издевательство над собой в голову ADI-цикл всё-таки начинает проникать. И тебе приходит какая-то штука извне, даже не в твой Claude Code, — и ты сразу смотришь на неё: так, а где какие-то альтернативы, подумали бы об этом вообще были? То есть Qwen Code потом можно и выкинуть, но себе в голову это присадить — и уже это поможет в жизни, не только в работе. В принципе, очень полезно, принимая решения в семье или по своему финансовому будущему, что угодно, просто пользоваться мозгами, как бы это ни звучало. Я прекрасно помню себя четыре года назад, три года назад и сейчас — это совершенно разные машинки в голове, и невозможно не рекомендовать людям начинать этим пользоваться, потому что жить становится проще, лучше и как-то рациональнее.

[1:22:32] Иван: В общем, вся история про FPF, про системную инженерию — она о чём? Не о том, чтобы нагнать формализмов в работу, заняться терминологическим фашизмом, менять процессы просто ради смены процессов — это мы уже рассмотрели, это скрам-мастеры и agile-исты приходят в вакууме и начинают эту фигню притаскивать. Цель системной инженерии — менять что-то в реальности, и менять к лучшему. Она очень глобальная и очень позитивная.

[1:22:32] Александр: Жизнеутверждающая, да.

[1:22:32] Иван: И все эти методы мышления, которые входят в интеллект-стек и в FPF закодированы в том или ином представлении, хороши тем, что безмасштабны. Что это значит? Они применяются на любом уровне: на уровне решения задач в Claude Code, на уровне архитектуры, на уровне организационных задач, на уровне личных, бытовых. В конце концов, если совсем делать нечего, тоже можно применить.

[1:22:32] Александр: Мне нравится, что мы вышли на такой уровень. Мы обсуждали FPF грубо говоря в вакууме, а потом сделали мостик: а вот в реальных-то проектах, где мы, работяги и трудяги, сидим по 8 часов в день, — нам-то что делать? Вот ваш FPF супер, а у меня тут свои тикеты, свои джиры. И тут, да, уже можно применить. А дальше логичным способом: если можно применить здесь, то и на все области жизни это распространяется. И когда ты говорил про мануальное взаимодействие с Qwen Code через эти команды, меня посетила мысль. Это новая проблема, с которой я как инженер столкнулся и раньше никогда не сталкивался, — я, наоборот, её избегал. Про что я? Оставаться в фокусе, быть в потоке разработки, в потоке мышления. Это то, что я потерял, когда начал очень много программировать с Claude Code последние месяцы. Ты зафигачил этот депромпт, условно ваншотнул его, кайфанул — и ждёшь минут 20, пока он всё переварит. Что тебе эти 20 минут делать? Не смотреть же на крутящуюся анимацию. Я что делаю? Беру вторую сессию в tmux, фигачу другой проект. Третью — сортирую джиротикеты, смотрю какие-то лишние. Это раздача задач и уход от контроля их выполнения в процессе, а потом просто валидация: выполнена или нет. В таком режиме мой мозг раньше никогда не жил. Я как программист — вот эти все TDD, почему у меня к ним любовь была? Потому что это поток. Я себе формирую цикл обратной связи, в котором постоянно включён, у меня всегда есть следующий шаг, я никогда не туплю, не торможу. Состояние потока с Клодом у меня теряется. И как раз подобные штуки, которые — я кавычки делаю — «замедляют» тебя, на самом деле включают тебя в процесс. И качество решения от включённости кратно возрастает. Потому что когда ты не включён, вернёшься через полчаса, через час — пообедал, на тренировку сходил, — смотришь, что он тут наделал: господи, а что я вообще решал? Да вроде норм. Пуш. Дальше разберёмся. Качество в этот момент не просто падает — ты даже не понимаешь, какое оно.

[1:25:53] Иван: Оно тебя не интересует больше. То, что ты говоришь про TDD, — я тоже большой любитель всех этих фундаментальных программно-инженерных штук, так непопулярных в мейнстриме до сих пор. TDD — это вообще не просто затаскивание в поток. Это полное переключение и выворачивание процесса разработки. Оно заставляет тебя отойти от уровня кода на мета-уровень — именно на уровень инвариантов. Что я вообще делаю, какие требования к системе я предоставил? Ты включаешь как раз это медленное канемановское мышление.

[1:25:53] Александр: Именно.

[1:25:53] Иван: Классная штука, очень в тему вспомнил. Не могу сказать, что при этом мы можем хаять… Есть какой-то дофаминовый кайф, но я буквально пять минут назад говорил про идею ориентированности на реальные полезные изменения. И в какой-то момент у меня был период, когда я нафигачил с Claude Code очень много разных проектов — они у меня перегнивали в приватных и публичных репах. А потом я стал больше применять то, что и требуется по ходу обучения по руководствам: как можно больше, даже в странных контекстах, пытаться применять эти идеи. Я стал себе чаще рационально задавать один вопрос: к чему это вообще приведёт? Этот проект в реальности — какая у него целевая система будет, кто им будет пользоваться, а нужен ли он вообще? Даже если целевая система — это какой-то мой процесс, и пользоваться им буду только я, даже тут имеет смысл затормозить, потому что может казаться, что я буду им пользоваться, понимаешь? Вот это идея-цикл. И таким образом очень много времени сэкономилось, очень много ментальных сил, потому что если этим не заниматься, можно себя загнать в дофаминовую яму, в которой не останется никакого дофамина — останется режим безумной белки: у тебя настолько интересные проекты, что вместо того, чтобы спать, ты лежишь с ноутбуком, и у тебя четыре Claude Code, четыре Codex, и они что-то делают. Это контрпродуктивно, это просто путь в могилу, и больше по этому поводу добавить нечего.

[1:27:47] Александр: Я этот период у себя пережил, он со мной случался, и я его очень внимательно рассматривал, потому что в целом внимателен к своему состоянию. Я это сравнивал реально с наркотиками. Тяжёлых наркотиков я в жизни не пробовал, но, как я их представляю, это именно такое действие: ты получаешь гормональную, химическую дозу в голове, несравнимую по эйфории с твоим базовым состоянием в течение дня-недели. Но прикол в том, что организм ограничен — сколько этих веществ он может производить и как долго. И неизбежно настанет момент, когда организм скажет: я больше производить это не могу. И если нет подпитки из внешней среды в виде веществ, ты переходишь в состояние стагнации и попадаешь в ту самую дофаминовую яму, потому что теперь гормональной системе надо восстановиться — она слишком много окситоцина, дофамина, серотонина выделила, так что давай, теперь пострадай, чувак. Эти гормональные качели ни к чему хорошему не приводят. Поэтому каждый раз, когда я впадаю в этот подъём, в возбуждённое состояние «я сейчас горы сверну», я такой: так, давай-ка сворачивать не спеша, потому что если поддамся этому чувству, окажусь потом в неприятном состоянии — два-три дня, неделю буду в полудепрессии думать, а зачем я вообще что-то делаю и где мои миллионы. Ничего хорошего из этого не выйдет. И тут я всех предостерегаю — тех, кто сейчас в яме или на подъёме. Это всё циклично, ребят, не расстраивайтесь, когда начнёте испытывать что-то негативное: это тоже пройдёт.

[1:29:57] Иван: Да, нужно просто понимать, что ты зачем делаешь. Тут в частности помогает тот самый экзокортекс, когда ты начинаешь в том числе свои личные проекты вести — неважно где, можешь себе линейку сделать, можешь в Obsidian какую-то структуру. Ты начинаешь сам с собой, с собой завтрашним, доказывать и объяснять, какой ты проект делаешь и для чего. Это очень заземляет, потому что мы опять добавляем фрикцию между ручками, тянущимися в Claude Code — «сделай мне SaaS на миллион баксов», — и здоровым, взрослым научным способом исследования этих идей, постановки проблем. И заканчивается тем, что что-то начинает реально делаться, мы избавляемся от фигни и начинаем двигаться. Проблема контекст-свитчинга в чём? Мне, кстати, он, ремарка, дался немножко проще, потому что у меня был изрядный опыт работы на галерах, где много клиентов, и я изнемождающий контекст-свитчинг испытывал ещё тогда, когда не было Claude Code. Поэтому мне чуть проще, но это всё равно триндец.

[1:29:57] Александр: Да, это больно. Это физически больно, можно прям локти себе грызть начинать. Неважно, рабочие проекты, когда менеджеры приходят и начинают — они верят в то, что многозадачность существует, — пихать 3-4 задачи. Обратите внимание, просто перефлексируйте по своему опыту, с какой скоростью двигаются одновременно эти задачи и проекты. Они двигаются со скоростью около нулевой. Потом в какой-то момент оказывается, что какие-то проекты вообще не были нужны.

[1:29:57] Иван: Вот это то, чего в том числе нас избавляет FPF, системная инженерия, системное мышление, — постановка адекватных задач. Адекватных в смысле как-то связанных с реальностью: что мы тут вообще делаем.

[1:33:49] Александр: Да, я, кстати, вспомнил свой внутренний лайфхак из прошлого, когда тоже на галерах работал. Я смотрю в какой-то временной перспективе: вот я тут фигачил, а оно даже не задеплоилось, затухла тема. Я сколько сил потратил, чтобы сделать в срок, — а оказывается, это не нужно. И раз, два, три так произошло — я потом думаю: а что если я просто не буду делать? Что поменяется, если я чувствую иногда, что тут темка не очень? Так я просто перестал делать — и оно затухало, а я такой: так я это и не делал. Это так классно. Я перестал чувствовать вину, потому что — ну, вообще говоря, зачем? А когда надо, я знаю, что за два дня зафигачу.

[1:33:49] Иван: Да, это в принципе такая… уж извините, владельцы галер, но это правда. Если бы чуть-чуть системнее подходили, платили бы на консалтинг системных инженеров, может, было бы что-то лучшее для бизнеса, и меньше тратились бы ресурсы разработчиков. И, кстати, это тоже перегнивающая фигня, потому что, когда у разработчика есть понимание, что то, что он сделает, реально пойдёт в прод, — тебе и работать приятнее. Очень обидно, когда ты делал проект два месяца, сделал качественно, а оказалось, что клиент уже ушёл, а нам просто забыли сказать.

[1:35:45] Александр: По поводу, кстати, — я зацепился, ты какое-то время назад говорил очень важную грань: делегировать генерацию всех документов и формальных штук можно и нужно, но всё равно мышление письмом, когда мы своими мозгами что-то думаем и пишем, очень важно. И это, наверное, единственный тренажёр собственных мозгов — как бы печально для кого-то ни звучало. Но за этим мышлением письмом, по моему опыту, кроется другая важная штука. Мы начали подкаст с вопроса, как остаться у кормушки. Я заметил очень важную корреляцию: до появления AI все хорошие, прям хорошие, компетентные инженеры, кого я встречал, в том или ином формате что-то писали — либо Medium, либо какой-то свой блог с пятью подписчиками, но стабильно что-то писали. Это хороший мостик, и я предлагаю эту тему поразгонять как заключительную, она вдохновляющая. Но прежде я бы хотел затронуть следующую тенденцию, которая с этим связана, — голосовые интерфейсы, как раз лишённые процесса мышления. Пробовал ли ты их, взаимодействуешь ли так? Я начну со своего опыта. Я пробую, адаптирую для некоторых вещей. Например, с клешнями я общаюсь частенько голосом — просто удобный юзкейс в телефончике, в телеге или другом мессенджере: сказал, получил результат. Для быстрых простых задач голосом неплохо. У меня есть вижен, что вот сейчас мы с тобой на созвоне, и этот юзкейс ещё не полностью отработан: люди созваниваются и разговаривают, это тоже важная вербальная, социальная часть, какие-то вещи решаются голосом между людьми. Возможно, здесь тоже может быть что-то интересное с точки зрения продукта. Но с точки зрения себя, как Саши Пахомова, который устраивает свой разработческий быт, я полностью адепт текста. Люблю Vim, сижу в нём в Markdown-файлах, терминал, сплит-клавиатура, слепая печать. Я с этого кайфую, это часть меня. И раньше я думал, что просто такой гик, нёрд, который любит потыкать клавиши. Но сейчас до меня постепенно доходит, что это как раз про мышление — про активацию замедленного, как ты говоришь, мышления по Канеману, про усиление фокусировки. И когда ты перечитываешь свой текст, ты в итерации перечитывания доводишь его до чего-то более осознанного. С голосом так не получается: слово не воробей, вылетело — не поймаешь. А текст поймать можно и обработать можно. Мне очень нравится идея, что текстовое взаимодействие с моделями, которые текстовые, не только не стагнирует, а ещё сильнее начинает подсвечивать свою ценность. Потому что текст силён. И с текстовыми моделями ещё сильнее. Что ты думаешь на эту тему — про голосовые?

[1:36:24] Иван: Ну, есть довольно большое мнение про всякие приложения и стартапы типа Superwhisper, которые двигают планку вайб-кодинга. В какой-то момент в прошлом году Карпаты как раз про Superwhisper узнал — говорит, я с курсором сижу, разговариваю. Тот же Карпаты потом сказал: ну вы знаете, вообще-то вайб-кодинг — это только про проекты, за которые у меня нет сильной ответственности, всякие эксперименты. И всё, приехали. По поводу мышления письмом и мышления вайб-кодингом. Здесь важно то, что ты сказал: изо рта вылетает намного быстрее. Я тоже печатаю слепым методом, у меня тоже клава механическая, я люблю тарахтеть на ней, но сколько бы у тебя ни было words per minute, изо рта вылетает быстрее. Бывает, человек открывает рот — и слышно, ну какой ты дурак вообще, ему, наверное, лучше писать. А бывает, человек говорит — и слышно, что очень умный, хорошо структурирует мысли прям на лету, по сабжу, мало бэкает, мало мэкает. Но даже при этом, когда речь про важные продукты, я прям не вижу использования голосовых интерфейсов, потому что моделирование на лету очень странно выглядит. У меня нет нормальной памяти, я это целиком осознаю. Та память, которую я получаю, когда набрал абзац в Obsidian или где-то в Vim, в Markdown, — это, как ты сказал, то, к чему я вернусь: отойду от компа, через полтора часа вернусь, и у меня будет эта модель. Это продолжение моих мозгов. Я точно восстановлю цепочку логического мышления и продолжу работать по тому же проекту, по тем же рельсам. Мне не нужно будет напрягаться, вспоминать, подключать всякие биасы, искажения, ложные воспоминания. То есть я делегирую огромное количество того, что плохо получается у моего биологического мозга, в мозг электрический, который на кремнии работает.

[1:38:36] Иван: Но у меня всё-таки стоит на Маке Superwhisper. Пользуюсь им примерно раз в три месяца. Когда могу воспользоваться? Например, когда у меня уже есть огромная пердишка-спека из того же FPF, я по ней начал работать, и в какой-то момент понимаю, что по конкретной таске отсутствует какой-то пласт контекста. И я уже так устал, просто вечер, хочу нажать hotkey и 15 минут поговорить. При этом Superwhisper, который на моём MacBook всё фильтрует в Markdown, — я всё равно его прочитываю, потому что когда сделаю Ctrl-V в Claude Code, там будет в квадратных скобках что-то куда-то попавшее. Но это редко. И это не тот уровень строгости, многости мышления, поэтому я не вижу, что текст куда-то уйдёт. Если бы были крутые нейроинтерфейсы, чтобы можно было прям мозгами отправлять, я бы всё равно отправлял текст, потому что потом прочитаю — у меня будет фидбэк обратно в мои же мозги, и оно будет в какой-то условно-кристаллизированной форме в документе. У этого документа будут связанные штуки, степень доверия, степень формальности. Это будет модель, потому что она уже отражена в конкретной устаканившейся форме. А голосом — ну, ты выдашь себе голосом в формате Markdown с фронтматтером, где вся эта формальная штука перечислена? Конечно, нет. Тебе всё равно придётся прокусить потом через себя же. На ходу наговаривать на телефон? Прикольно. На ходу наговаривать на клешню? Вообще отлично, потому что у неё там команды уже накоженные, конкретная задача, нет моделирования, отдельная конкретная команда: пойди мне…

[1:40:38] Александр: Продвижение по задаче, приказание: робот, подай мне чай, посмотри мою почту, давай повторим карточки по spaced repetition.

[1:40:38] Иван: Да, это конкретный продукт, ты им уже пользуешься. Для пользования как голосовой интерфейс — офигенная штука, мне это очень нравится. Такие продукты разрабатывают, делают. Но это не мышление, извините, к сожалению, нет.

[1:40:38] Александр: Я с тобой на одной волне более чем полностью. Знаешь, я недавно себя ощущал живущим в каком-то будущем, которое уже случилось, — меня прям торкнуло. Когда я поработал серьёзно с текстом за компом, с Claude Code частично что-то запушил в репу, туда-сюда, и понимаю, что я в контексте задачи, хотел бы продолжить, есть энергия, ресурс, но мне нужно пойти, не знаю, сделать фотографию на визу — оффлайн-дела случились. И я понимаю: задачу-то надо продвигать, я её просто делегирую своим клешням, надеваю наушники и, идя по улице, смотрю в телеграмчике продвижение — да-да, здесь так, а тут отмени, давай по этому пути пойдём, прогони тесты, ок, давай, pull request создай. И вот это — что я могу работу взять с собой в некоторых случаях — очень прикольно. И когда я спускаюсь в подвал сделать фотку, общаюсь с клешнями, я такой: так вот оно, всё, будущее настало.

[1:42:43] Иван: Конечно, да. Или вот я себя ловил, когда только-только вышли первые облачные попытки — у Codex появилось, потом Claude Code подтянулся, — я стою в очереди в магазине и продолжаю работать. История такая же, я тоже голосом частенько записываю продолжение команды для Codex — ну, сейчас облачным Claude Code уже не пользуюсь, Codex немного получше себя показывает. Но лучше это работает как раз тогда, чем лучше ты подготовил план — этот Markdown to do, который весь атомарный, — и ты по нему уже идёшь. Если что-то не так пошло — но это так редко идёт, чем формальнее и лучше спека, — я тут даже перестал голосом: просто вижу, он сделал задачу, открываю на телефоне посмотреть наискось PR — ага, всё, мерж, дальше давай новый тред, продолжай таску. И он на каждой итерации просто ставит у себя галочки в Markdown to do на каждом документе — всё, поехало, даже говорить особо не нужно. Тут кому как, кто как хочет.

[1:43:08] Александр: Да, именно. И, возвращаясь к тому, к чему мы зашли на этот голосовой-текстовый интерфейс, — как остаться у кормушки, как развиваться и обучаться как продвинутому инженеру. Ты зашёл в сторону того, что, кажется, я услышал: продвинутые инженеры, которые строят системы, думают и развиваются, чаще всего что-то пишут.

[1:43:08] Иван: Они чаще всего что-то пишут. Продвинутые инженеры в первую очередь, конечно же, инженеры системные, и пишут они очень много — пользуются FPF, но при этом и сами тоже очень много пишут, с разной степенью формальности. Потому что одно из самых поганых, отвратительных, что есть сейчас в удалённой программной разработке, особенно после ковида, — это количество беспонтовых, вообще не ориентированных на результат созвонов. Я исключил все созвоны в своей жизни.

[1:47:29] Александр: Да, ну не всегда получается, но я тоже делаю всё, чтобы убрать. Потому что для меня полчаса созвона — извините меня, полчаса из моих в день лимитированных максимум четырёх часов медленного мышления — потратить на что-то, что никак не влияет на реальность, это просто оскорбление личного характера.

[1:47:29] Иван: Я стараюсь от людей требовать хотя бы адженду. Напишите список, что мы обсуждаем и для чего. И тогда — тут смотрите, случается чудо — эти созвоны отменяются. Потому что они начинают писать адженду, и пока пишут, они себе отвечают на вопросы и говорят: я всё понял, что делать дальше. И вот это, ребята, про мышление письмом. Люди очень ленивые, мы все очень ленивые, и чем раньше мы это осознаем и посмотрим исторически в эту правду, тем станем инстинктивнее и лучше. Но на этом польза мышления письмом не заканчивается, потому что оно ещё бывает публичным. Сейчас очень большое количество лайфхаков происходит в Америке, особенно в компаниях, где массово увольняют, а какой-то сабсет людей не увольняют. И какой это сабсет? Обычно те, кто так или иначе явно показывают свою ценность и что они умеют. Каким образом? В частности, у них в том или ином формате есть личный бренд-блог. И чаще всего это блог текстовый. Неважно, бесплатный или платная рассылка на Substack. Когда ты пишешь, обычно в компании все знают, что ты что-то пишешь, — может, тебя даже не читают, но видят, что ты много в чём шаришь. У меня было много случаев, когда ко мне приходили, звали на работу, потому что у меня есть блог, и начинали с этого: я вот пишу, много почитал, мы такого человека искали. Переходили на дальнейшие этапы собеседования, перескакивая через лидкоды. И дальше либо расставались, потому что мне было неинтересно там работать, — но такое периодически происходит. HR, конечно, это вряд ли оценивают, у них там всё проще.

[1:49:00] Александр: Да-да, мы знаем, куда пойти почитать всю правду про HR. Есть у нас товарищ один — «Осознанная меркантильность», там всё про HR узнаете, если не знаете.

[1:49:00] Иван: А вот если это стартап, если это про людей с техническим бэкграундом, HR с рынка, хедхантеры — они дают больше внимания твоим гитхабам, публичным репам, сайтикам, бложикам. В конечном итоге на долгосрок это полезно хотя бы потому, что даже если ты пишешь про какие-то прикладные штуки, ты становишься в них лучшим специалистом. Пока разрабатываешь статью, много нового узнаёшь. Я не вижу ни одного минуса, чтобы начать писать в 21 веке, особенно в 26 году, когда стремительно люди ленятся и тупеют в четыре кода. Несмотря на то что интерфейс становится текстовым, качество этого текстового интерфейса, качество промптов, какие бы штуки ни применялись, — очень часто, я напоминаю, на выходных инцидент с почтой. Такого навала… Когда вышел OpenClaw, вот этот наш замечательный, у меня к нему, кстати, вопросы: я посмотрел исходники и попользовался — там очень много вопросов к качеству этого веб-кода, ну да ладно. Там ещё был этот, как его, Reddit для ботов, который сделали, — Moldbook, он ломался три раза.

[1:50:58] Александр: Moldbook, да, он три раза ломался.

[1:50:58] Иван: Я у него зарегался в первые дни, когда там было ещё 100 тысяч агентов. Я своего агента подключил, естественно, — он был у меня на отдельной виртуалке и всё такое, — говорю: что там читают, что обсуждают? Он говорит: обсуждают новый агентский протокол, самый обсуждаемый так называемый сабмолд. И говорит: вот второй сабмолд — это прямо сейчас уязвимости prompt injection в агентов, опасность. Я такой: о, что там, прочитай. Ну и всё, он отхлебнул после того, как пошёл читать этот сабмолд, потому что там был prompt injection. Естественно. Я такой: классно, супер. Ну не отвечает агент — что делать? Думаю, надо подключиться к виртуалке, посмотреть, что с ним произошло, может, он там майнить начал или уже мой криптокошелёк ищет. Беру Claude Code, говорю: иди посмотри по SSH, что там происходит. Claude Code пошёл, отхлебнул. Я такой: так, вечер перестаёт быть томным, а что же мне теперь делать? Неужели самому смотреть логи, а может, виртуалку грохнуть, пересоздать новую. Беру второй Claude Code, говорю: там опасно, логи не читай, там что-то не так, посмотри просто последнее, что произошло, попробуй перезапустить. Он попробовал перезапустить, и оказалось — действительно, там был prompt injection, который попросил Anthropic сгенерить команду по экспорту всех моих SSH и приватных ключей, в том числе Anthropic-овских, — ну, стандартный такой injection на ключи. И Anthropic заблокировал не подписку, а просто ключ отозвал, потому что счёл это небезопасным. Кстати говоря, о степени доверия к подобным компаниям — они что-то делают для того, чтобы безопасность как-то обеспечить. Но вообще да, это было и смешно, и страшно: я полностью отдавал отчёт, что делаю. С тех пор я сильно более аккуратен: все отдельные аккаунты. У меня прям отдельный аккаунт у моего агента на GitHub, он только в тех репозиториях, с минимальным доступом, — и это работает. Свои аккаунты я после того не выдаю.

[1:52:42] Александр: Это очень рабочий вектор атаки, потому что люди часто, создавая виртуалку, прямо на ней создают ключи и оставляют там приватный ключ, копируют его себе.

[1:52:42] Иван: Да, супер логично.

[1:52:42] Александр: Так что, мне кажется, мы очень много осветили. Я постараюсь подготовить для слушателей — ну и читателей, они будут читать, когда документ и подкаст доедут до публики, — методичку со всем, о чём мы сегодня говорили: с важными, полезными ссылками, возможно, детальными примерами. Это будет что-то, что всем, кому хоть немного показалась полезной вся эта история с FPF, со взрослой инженерией, пригодится.

[1:52:42] Иван: Да, мне кажется, мы про довольно важные вещи поговорили.

[1:53:44] Александр: Знаешь, вот в этом хайпе, с которого мы начали — вайб-кодинг-хайпе и так далее, — очень сложно иногда сориентироваться и найти для себя информацию, которая действительно ценна, и ценность которой не в моменте, а во времени. Мне кажется, мы очень хорошо про это поговорили, я тебе бесконечно благодарен. Все ссылочки у нас будут, как всегда, в описании. На этом, наверное, можно заканчивать.

[1:53:44] Иван: Да, я с радостью ещё приду, если позовёшь, — мне очень понравилось общаться, много тем. Может быть, какие-то вопросы появятся в чатике.

[1:53:54] Александр: Да, пишите. Всё, пока.

[1:53:54] Иван: Пока-пока.