С нейронками невероятно эффективно и удивительно тяжело создавать новое знание Я развиваю несколько продуктовых методологий, так что моя работа — создавать новое знание. Я занимаюсь этим почти каждый день уже 8 лет. До нейронок, один инсайт рождался за несколько часов. Это было медленно, мучительно, захватывающе и невероятно увлекательно. Каждый инсайт ощущался одновременно как подарок на день рождения когда мне было восемь лет и как большое достижение. У меня были рабочие рутины: блокнот A4, я много думал пока рисовал схемы и логические переходы, искал информацию, читал научные статьи, книги по бизнесу, экономике и психологии. Рождение нового инсайта или новой области знания происходило постепенно. Теперь, когда у меня в параллель в нескольких вкладках крутится Claude Code, я могу генерировать ОГРОМНОЕ количество инсайтов в день. В мае я запланировал месячный отпуск, который неожиданно превратился в безумный рабочий спринт. Я подробно расписал около 200 тезисов о своих методологиях, которые раньше были на уровне плохо описанных идей, и нашёл ещё 100+. Это ОЧЕНЬ много. В хороший год я мог найти или описать около 100 тезисов. Спринт начался с идеи: «А что, если валидировать или открывать тезисы методологии с помощью нейронки?». На следующий день я уже работал по 14 часов в сутки. Я был в диком восторге. Но при этом перевозбуждён и фрустрирован. При обычном процессе, инсайты рождались межденно и они рождались в моём мозге и психике. С Claude Code развитие идеи часто происходит мгновенно, а инсайт часто рождается внутри клодика. Я лишь валидирую и дорабатываю его. Объём информации, проходящей через мой мозг во время генерации и валидации с Claude Code, огромен. В итоге я ощущаю себя так: • за день я создаю много инсайтов • я перевозбуждён от объёма мыслей и эмоций • я не чувствую, что они результат МОЕЙ интеллектуальной работы • через неделю я забываю 2/3 этих инсайтов, чего НИКОГДА не случалось, когда инсайты приходили ко мне по-старому Это очень странные ощущения. Но всё равно безумно эффективно. 10/10, хайли рекомендасьён. Думаю, отчасти проблема была в Opus 4.8, тогдашней SOTA-модели, которая выдавала ужасный текст, от которого плавились мозги. Но я также думаю, что нам нужно переосмыслить рутины и психологию творческой работы в эпоху нейронок. [на мой взгляд, модели Anthropic гораздо лучше подходят для творческой работы]

Опросы пользователей Один из способов исследования — это когда пользователей зовут проходить всякие опросы про продукт. Могут письмом зазвать «ответьте на несколько вопросов», а могут в самом приложении сказать «помогите нам стать лучше». Ясно, что сами эти опросы раздражают часть людей, но допустим, что это необходимое зло: как-то же надо изучать наших пользователей! https://ilyabirman.ru/meanwhile/all/somehow/ Вопрос в том, как интерпретировать результаты. Например, если по ответам вы судите о том, чем пользователи довольны, а чем нет, то важно понимать, что вы изучаете не всех пользователей, а только тех, кому настолько нехрен делать, что они пошли отвечать на ваш опрос. Возможно, в ходе опроса вы выясните, что их не бесят всякие попапы, но так их и опрос ваш не особо бесит. Они, похоже, готовы терпеть что угодно! Получается, результаты у вас искажены: вы знаете только ответы самых нетребовательных пользователей. Более того, возможно, что ответы нетребовательных людей сами по себе низкого качества. Вряд ли они особенно старались и вдумчиво отвечали. Знаете же, как оставляют отзывы на маркетплейсах люди, которым нечего делать? «Отличная вещь, рекомендую, сами ещё не распаковывали». Ну вот. Я не к тому, что опросы никогда не надо проводить (хотя я был бы счастлив). Я к тому, что если вы сначала решили использовать этот метод при всех недостатках, потому что лучше ничего не нет, то не стоит потом смотреть на его результаты так, будто они настоящие. Надо так и смотреть: «Ну вот, наш кривой метод дал какие-то такие кривые результаты. И что они значат на самом деле?»

Я начала использовать кодинговых агентов (вроде Codex/Claude Code) в марте 2026 года. Первые 3–4 месяца я применяла их в основном для запуска новых экспериментов на базе уже имевшегося у меня кода рисерч проектов, который я полностью написала сама или с соавторами. Это получалось довольно хорошо: агенты отлично справляются с масштабированием экспериментов, а проверять их работу в таких случаях довольно просто, и это в итоге сэкономило мне массу усилий. Но недавно я начала пробовать использовать Claude Code для новых проектов, попросив его написать много нового кода, используя внешние GitHub репо только как ориентиры, добавив сверху новой логики и датасетов. Агент весьма уверенно заявлял, что написал код и запустил эксперименты. Но когда я решила проверить этот код, то там обнаружились ряд проблем с методологией и выбором гиперпараметров, причем некоторые из них выявились только через некоторое время. Дальше я попросила Claude внимательно перепроверить код. Он действительно нашел несколько ошибок и согласился, что некоторые гиперпараметры были выбраны случайно — он не сумел/не захотел нормально проанализировать внешний GitHub репо и понять, какие гиперпараметры верные. Но один цикл такой проверки и исправления не решил всех проблем. Ради интереса я попросила Claude повторить проверку и исправление еще несколько раз, и в следующих нескольких циклах он находил новые баги, часть из которых влияла на постанову эксперимента, а часть вообще возникала из-за предыдущих исправлений. К чему это я: это явно не сюрприз, что агенты делают ошибки, а я, безусловно, не самый опытный пользователь подобных агентов, и мои конфиги и промпты далеки от идеала. Но беспокоит меня вот что: я вполне могу представить людей, которые используют агентов для запуска экспериментов и написания статей на основе полученных результатов. Но без нормального понимания методологии исследований и тщательной проверки кода такие эксперименты с высокой вероятностью будут содержать ошибки или даже окажутся некорректными. Понятно, что и до появления агентов не было гарантии, что все эксперименты, описанные в статьях, точно верны. Но теперь порог входа стал сильно ниже, и стало гораздо проще получить неверные результаты, даже не подозревая о наличии в них ошибок. Возможно, одним из способов решения этой проблемы могло бы быть обязательное требование прикладывать код проекта к сабмиту статьи. Мы могли бы сделать автоматическую проверку структуры экспериментов для тех статей, которые скорее всего будут приняты, и более внимательно ревьюить те работы, в которых эта проверка выявит что-то подозрительное.

Обновил Next Move Theory до 0.6.18 — большой апдейт скиллов и правки канона. Что изменилось в скиллах 1. Пакет против плохих дорог галлюцинаций во всех скиллах: • Каждое утверждение помечено, откуда оно: подтверждено цитатой или цифрой из источника, выведено из данных (сказано, из чего) или гипотеза модели. • У любого обобщения есть счётчик и ссылки: «сказали 7 из 22 интервью: #3, #7, #9…». Утверждение с одним источником не может стать выводом про сегмент — оно уходит в отдельный список «Single signals». Одна яркая цитата больше не становится «главной болью сегмента». • Цифра, которую сказал респондент («60–70% сделок через тендеры»), помечается как его мнение, а не как факт о рынке. • Идеи, которых нет ни в одном источнике, живут только в разделе «Hypotheses to validate», а не внутри сегментов, сайзинга или вердикта. • Уверенность масштабируется под входные данные: если на входе только описание идеи — в шапке предупреждение «Thin input», все числа диапазонами, сегменты помечены как гипотезы, плюс топ-3 входа, которые сильнее всего улучшат ответ. 2. Защита сегментации. Перед выдачей любого сегмента скилл проверяет три анти-паттерна: канал покупки (тендеры, маркетплейс, реселлер) — не сегмент; отрасль — не сегмент, если Core Jobs и критерии успеха совпадают; сегмент всегда определяется через Core Jobs + критерии успеха + их приоритет. 3. Рынок и язык всегда спрашиваются в начале. Примеры, конкуренты, каналы, ценовые якоря, валюта и тон копирайта берутся из вашего рынка. Больше никаких американских каналов и цен для проекта в Казахстане. Язык аудитории и язык документа — отдельные вопросы. 4. Файлы внутри проекта читаются только с разрешения пользователя. Скилл перечисляет, какие файлы с контекстом нашёл в папке (README, выгрузки опросов, отзывы, транскрипты), говорит, что они обрабатываются локально и никуда не отправляются, и ждёт «да». Секреты и личные заметки не открывает даже при общем «да». 5. nmt-analyze-interviews — самый большой апдейт. Новые разделы отчёта: «Single signals», «Hypotheses to validate», карта источник → сегмент с приложением по каждому интервью, пробелы и кого интервьюировать дальше. Транскрипты обрабатываются волнами по 4–6 штук с записью в файл после каждой волны, поэтому большие наборы интервью не переполняют контекст. 6. Читаемость. В HTML-выводе каждая аббревиатура и термин методологии получает всплывающую подсказку при первом упоминании. Любая строка отчёта должна быть понятна человеку без знания методологии. 7. Проверка обновлений стала прозрачной. Идёт в конце прогона, отправляет только имя скилла и установленную версию, ничего из проекта. Выключается одной строкой update-check: off в файле .nmt-config или переменной DO_NOT_TRACK=1. Установка и обновления идут напрямую с GitHub. 8. /nmt-upgrade переименован в /nmt-update. Инсталлятор сам удаляет старую папку и ставит новую. 9. Блок правил, который инсталлятор вписывает в ваш CLAUDE.md и AGENTS.md, сократился до пяти строк. Ваши собственные правила вне маркеров не трогаются. 10. nmt-chat и nmt-diagnose: предлагают прочитать контекст из папки проекта вместо расспросов, спрашивают рынок один раз перед любым рыночным советом, помечают источник каждого утверждения (в каноне / выведено из сказанного / гипотеза). Что изменилось в каноне • Цепочка к прибыли переписана в две фазы: исследование и проверка (рынок с деньгами → сегмент + Job → три условия сходятся в теории → доказательство ценности, клиенты покупают) и масштабирование (те же три условия сходятся по факту на реальном потоке → целевая прибыль). • Critical Chain of Jobs: узлы цепочки — концы веток на любой глубине, потому что реальный Job Graph несбалансирован. Правило корректности: ни один узел на линии не может быть предком другого. Обновиться: /nmt-update в Claude Code или $nmt-update в Codex. Полный список изменений: https://nextmovetheory.com/changelog

Много лет назад, философ Исайя Берлин написал популярное эссе «Ёж и лиса», навеянное цитатой из древнегреческого поэта Архилоха (поручик, попрошу воздержаться). Википедия сообщает, что Архилох написал: «πόλλ' οἶδ' ἀλώπηξ, ἀλλ' ἐχῖνος ἓν μέγα», что можно, кажется, перевести приблизительно как «лиса знает многие вещи, а ёж знает одну, но важную». В своём эссе Берлин применил эту метафору к писателям и мыслителям, разделяя их на ежей, т.е. тех, кто видел мир через призму одной большой идеи (например, Платон, Достоевский или Пруст) и лис, кто предпочитал воспринимать мир во всём его многообразии (например, Аристотель, Шекспир или Бальзак). С тех пор, эту метафору применили к множеству областей человеческой деятельности; на лис и ежей разделили бизнесменов, политиков, людей вообще и даже классифицировали самого Берлина (как лису). Мне кажется, что в науке это разделение работает особенно хорошо, особенно если слегка уточнить, что такое научная лиса и что такое научный ёж. Так вот, научная лиса специализируется на том, что плохо лежит, а научный ёж — на том, что хорошо закопано.

https://penguinny.livejournal.com/82646.html

Где проходит граница? Посмотрите какая любопытная статья. Посвящённая одному из ключевых вопросов техно-трудовой повестки: на чём должна строиться методология определения границ между автоматическим и человеческим? Авторы предлагают три фактора, почему человек всё ещё важен и нужен в рабочем процессе, даже при таком интенсивном масштабировании возможностей AI: 1. Technical Человек приносит то, чего пока нет у AI: опыт, контекст, физическое восприятие и сложное движение, специфические способы мышления. Но мы также видим, что этот фактор очень подвижный. И напрямую зависит от развития технологии. Если AI научится воспроизводить нужную способность или получать тот же результат другим способом, человеческое участие можно убрать. 2. Normative Деятельность, где участие человека определяется нормативными атрибутами: ответственностью, отношениями, авторством, оценками. То есть здесь важно не то, может ли AI сделать работу, а какой социальный контекст и обязательства вокруг этой работы возникают. Соответственно, для полного цикла подобных задач у технологий должен быть социальный и этический статус. 3. Emergence Есть особый тип работы и задач, где невозможно заранее определить образ результата и критерии оценки. Они раскрываются в процессе, когда человек взаимодействует с промежуточными вариантами, прототипами и альтернативами. Это ключевая концепция статьи — идея Target Emergence. Где у человека ведущая роль. И её пока никак не автоматизировать. Target Emergence состоит из Revelation (определение цели), Refinement (уточнение и операционализация) и Constitution (переформулирование цели и критериев успеха). Вывод такой: машине можно доверить экзекьюшен, но создавать видение и цель — это прерогатива человека. В комментариях аудио-саммари и оригинал статьи. → https://arxiv.org/abs/2607.21547

Вообще забавно, что бенчмарки теперь бывают двух видов: 1. Научная статья, датасет и протокол для сравнения методов. Пир ревью, методология и всё такое. 2. Мы прикольно запромптили модели больших лаб и что-то получилось, вот блог-пост. Второй тип мне по вайбу напоминает социальные науки в 90-х. Например, как знаменитый Стенфордский эксперимент Милграма: мы сделали одних людей надзирателями, вторых заключенными, и ВЫ НЕ ПОВЕРИТЕ ЧТО БЫЛО ДАЛЬШЕ. Опускается, что Милграм показывал надзирателям как лучше бить заключенных дубинкой для большей драматичности. Или множество исследований типа "мы задали три вопроса пяти студентам в коридоре нашего универа и вот что мы узнали про психику людей..." В общем всё то, что привело к кризису репликации. И позволило многим сделать целые карьеры занимаясь какой-то веселой херней. Короче это изначально не про науку и от бенчмарков одно название

LLM придумывают исследования заметно уже людей Исследователи сравнили идеи девяти моделей с идеями из 11 683 реальных научных работ. Условия были одинаковыми: и людям, и LLM давали один набор близких предыдущих исследований и просили найти новый научный вопрос и предложить метод. Разница оказалась не столько в качестве отдельной идеи, сколько в разнообразии подходов. Люди чаще искали причины явлений, проверяли ограничения, меняли отдельные механизмы, создавали инструменты измерения и изучали сбои. Модели в основном выбирали безопасный сценарий: соединить две существующие работы или объединить несколько методов. Такую мотивацию использовали только 12,1% человеческих идей, но от 47,1% до 64,2% идей LLM. Синтез и объединение стали основным методом в 5,1% человеческих работ против 22,5–38,7% у моделей. Показательный результат: более долгое рассуждение не расширило диапазон идей. В некоторых тестах модели ещё сильнее концентрировались на знакомых шаблонах. LLM могут быстро выдать убедительную научную гипотезу. Но при массовом использовании они рискуют снова и снова предлагать одну формулу: возьмём A, соединим с B и назовём это новым методом. Исследование показывает важное ограничение AI Scientist: модель может хорошо развивать найденное направление, но выбор самого направления пока остаётся заметно человеческой задачей. arxiv.org/abs/2607.01233

Истина 1. Поведение Системы возникает из взаимодействия между её частями, а не из отдельных частей Результат системы — это результат того, как компоненты соединяются и взаимодействуют. Можно довести до совершенства каждую отдельную часть и всё равно получить сломанное целое.

Продукт это то, как совершенные части собраны в полезное целое

Системное мышление означает оптимизацию связей-линий между частями-точками. Оптимизация части всегда идёт за счёт целого. Части Системы, оптимизируемые независимо(!) по локальным метрикам, стремятся к своим локальным максимумам, которые являются провалом для целого (прямое следствие декомпозиции цели/фичи/продукта/рынка). Истина 2. Структура, правила и потоки информации обладают большей силой, чем её параметры Точки вмешательства в оптимизацию Системы имеют разную силу. Настройка параметров обладает слабейшей силой, в то время как изменение структуры, правил и информационных потоков большую, а изменение всей парадигмы Системы – максимальную. Эксперименты с версиями фичи это лишь уровень параметров Проектирование базиса механики/архитектуры/сценария, на/по/благодаря которому смогут строить и создавать другие пользователи/команды — правило. Систему можно опознать как ту же самую даже после того, как заменены все её физические носители: люди и код, главное – всё будет работать в новых версиях и компиляциях, если сохранился паттерн связей между ними. Истина 3. Граница Системы очерчена наблюдателем, а не продуктом/рынком Где проводится граница продукта, там же заканчивается его рост и оптимизация, а всё, что снаружи границы, воспринимается как внешняя среда, а не как часть целого. Не бывает объективной границы Системы — есть только граница, которую "выгодно" не видеть. Истина 4. Когда в Систему добавляются что-то "новое" как новый актор, новая ценность переходит к интерфейсу, через который это "новое" взаимодействует с частями Системы. Интерфейс – слой парадигмы. Истина 5. Управлять Системой может только То, что содержит не меньше разнообразия, чем сама Система Регулятор должен обладать вариативностью реакций, равной или превышающей вариативность возмущений, иначе часть возмущений пройдёт через него неотрегулированной (математическое ограничение управления как такового). Истина 6. Иерархия — это замороженная на момент времени искусственная сеть, а формализация и живость Системы это её взаимоисключающие состояния. Система 7. Система не может познать себя изнутри, ибо любое её самоописание есть модель низшего порядка сил. Система существует не ради цели, а ради собственного воспроизводства. Её цель это то, что она рассказывает себе про себя Истина 8. Достигнутая Системой цель — её же новое ограничение. Система, истребившая все ошибки, истребила собственную способность эволюционировать. Значит ли это, что она эволюционировала в Абсолют?