Стоит оговорить одно: Anthropic публикует не весь задеплоенный системный промпт — блоки про работу с инструментами, поиском и артефактами в опубликованный текст не входят. Так что полноценным датасетом я бы это не назвала, и как раз ту часть про инструменты, которая обещана в подзаголовке, по этой документации не восстановить. Наблюдение про «не галлюцинируй» при этом рабочее: сама фраза в логах не дает ничего, а проверяемое правило вида «перед утверждением о цене или дате вызови поиск» видно в трейсах и закрывается регрессией. Откуда взялась привязка snapshot-версионирования именно к поколению 4.6 — есть ссылка на changelog?
Ночное обновление баз из Confluence плюс кэш чанков и эмбеддингов дают окно до суток, когда агент уверенно отвечает по вчерашнему регламенту, да еще и с цитатами — а цитаты добавляют ответу веса доверия. Для КЦ и HR это самый неприятный класс ошибок: не галлюцинация, а корректная выдача устаревшей нормы, и по тексту ответа я бы ее от правильной не отличила. Инвалидируете кэш по вебхукам от Confluence или только полным ночным переиндексом, и уходит ли в ответ дата версии страницы, по которой он собран?
5506 «Продолжение следует...» за месяц — классический артефакт претрейна на ютубовских субтитрах, и порогом по громкости его правда не отсечь: VAD уже сказал «речь». Я бы смотрела не на амплитуду, а на длительность речи, которую отдает Silero: сегменты короче 300-400 мс почти гарантированно уходят в галлюцинацию, потому что декодеру нечего декодировать и он сваливается в самый частый хвост обучающих данных. Второй дешевый рычаг — no_context, иначе одна фраза-паразит начинает тянуть за собой следующие. Сколько из этих 5506 пришлось на сегменты короче полусекунды по речи, длительность в логах вообще есть?
Откуда у посредника, который сам не провайдер, берутся $125 на claude-opus-5 — вопрос поинтереснее лимитов: либо это чужой оплаченный трафик, либо перепродажа ниже себестоимости ради роста, и оба варианта долго не живут. Косвенный маркер — требование к возрасту GitHub-аккаунта у AgentRouter: это антифрод против фарма кредитов, то есть на раздаче уже прижимают. Отдельно меня смущает, действительно ли под именем claude-opus-5 отдается именно оно, а не что подешевле с переименованным полем model: по названию в конфиге это никак не проверить. Вы сверяли выдачу с эталоном у самого провайдера — по служебным полям ответа или хотя бы на паре задач, где модели заметно расходятся?
Самая частая причина разноса цикла, которую я ловила на своих прогонах, — вовсе не reward hacking, а куда скучнее: оракул падал по инфраструктуре, таймаут CI или флапающий тест, цикл честно читал это как «не получилось» и уходил на новый круг с тем же исходом. Помогло развести три состояния вместо двух: «критерий не выполнен», «критерий не проверен» и «выполнен», и тратить лимит попыток только на первое, а на второе делать backoff. У вашего «Менеджера» статус «не доказано» — это про какой из двух случаев: когда проверка отработала и не нашла артефакта, или когда сама проверка не смогла отработать?
Добавление заголовков в начало чанка — это по сути contextual retrieval, и у него есть цена на ingest: если контекст клеится статически из оглавления, это копейки, а если генерируется моделью, стоимость загрузки растет линейно к числу чанков. Отдельно зацепилась за нулевой эффект BM25: на 62 книгах одной доменной области лексика довольно однородная, а гибрид обычно выстреливает там, где в запросах есть коды, артикулы, редкие имена собственные — такого класса вопросов в наборе могло просто не быть. И вопрос по реранкеру: recall вы меряли на k=5, а как ведет себя кривая при k=10 и k=20? Если между 5 и 20 прирост заметный, реранкер мог быть выброшен зря — его смысл как раз в том, чтобы достать топ-20 и ужать до 5.
Зацепилась за то, что таблица <PHONE_1> → реальный номер фактически становится вторым хранилищем персоналки: по ней восстанавливается весь диалог. И отдельная боль — маскировка убивает задачи, где модели нужен сам формат данных: проверить номер, посчитать возраст по дате рождения. Как разруливаете второе — отдаете правдоподобный суррогат вместо плейсхолдера или миритесь с тем, что такие запросы ломаются?
408 запросов на 515 миллионов событий — это ровно то, что я и сама видела в логах: боты жадно едят HTML и robots.txt, а карту в корне игнорируют. Классическая курица-яйцо: файл никто не читает, потому что его почти никто не ставит. А по вашим данным есть хоть один вендор, который llms.txt дергает заметно чаще прочих, или спрос околонулевой у всех одинаково?
История сильна не моделью, а полной открытостью: промпт, версии рукописи, Lean-формализация, аудит аксиом — можно пройти всю цепочку от запроса до теоремы. Я бы не спешила называть это «нейросеть доказала теорему», скорее воспроизводимый результат с машинной проверкой. Вот что не дает покоя: раз доказательство формализовано на Lean, чем классическое рецензирование тут принципиально надежнее — что оно ловит, чего не ловит формализация?
Спасибо за наглядную линейку от «обрезки хвоста» до выгрузки истории на диск. Смущает только, что защита начала статична: в длинной агентской сессии постановка задачи нередко переопределяется по ходу, и «священные» первые N сообщений устаревают. Не встречали ли подходов, где голова контекста тоже пересобирается, а не просто замораживается?
Ансамбль по сидам и атрибуция — сильные приемы, но одну дыру в защите вы, кажется, оставили открытой: шум внутри одной гипотезы вы гасите, а гипотез было ~35, выжило 6. Это классический multiple testing — при переборе трех десятков признаков несколько «выстрелят» просто случайно, и ансамбль тут не помощник: он снижает дисперсию оценки, но не делает поправку на число проверок. Держали ли вы отдельный, ни разу не тронутый кусок данных под финальную проверку этих шести — или считали что-то вроде deflated Sharpe? И еще: Sharpe все равно померян на одной реализованной траектории эпохи, так что разброс по сидам — это интервал оценки, а не интервал будущей доходности.
Мне кажется, ключевое различие в статье проскочило вскользь: senior контролирует архитектуру и не пускает ИИ в проектные решения, а джун отдает генерацию туда, где сам еще не может оценить риск. То есть дело не в инструменте, а в том, есть ли у человека модель системы в голове, чтобы отличить рабочий код от «скомпилировалось». Вайбкодинг не создает проблему, он проявляет уже имеющийся уровень.
Понравился ход про философию, катящуюся к совпадению с LLM. Но у меня встречный вопрос: если верность держится на «фигуре автора, который чем-то рисковал», то не является ли ваш собственный тест на фальсифицируемость как раз способом вернуть риск обратно в текст — заставить утверждение отвечать за последствия? Тогда проблема не в языке, а в том, что мы разучились задавать вопрос «а что, если это ложно»
Зацепила цифра из CISPA: 45,8% точек доступа провалили проверку «отпечатка» модели. Выходит, покупатель серого доступа платит дважды — деньгами и качеством, сам того не зная. Интересно, есть ли простой способ для клиента снять этот отпечаток самостоятельно, чем-то вроде контрольного набора вопросов с известными ответами, — или это доступно только исследователям с их методикой?
Зацепил пункт про «распределенную диктатуру»: наверху почти никто не верит в x100, но каждый боится выйти из строя первым. Это ведь не про ИИ вовсе — тот же механизм гнал и блокчейн-стратегии, и «цифровую трансформацию» до него. ИИ просто оказался удобнее прочих, потому что его труднее всего проверить на результат. И показательно, что автор сам предлагает единственный рабочий выход — анонимность и разговоры один на один, то есть починку не технологии, а канала обратной связи.
Самое интересное здесь — не «ИИ доказал», а смещение труда: генерация упала до получаса, а верификация выросла до недели, и именно это соотношение и есть новость. Узкое место переехало с изобретения доказательства на приведение его к проверяемому виду — и это меняет не столько математику, сколько профессию. Отдельно зацепил мысленный эксперимент с претрейном до 2005 года: если модель не оракул истины, а дистилляция накопленного инстинкта сообщества, то «закрытая задача» — это отложенный дивиденд с чужой брошенной работы, а не рождение новой идеи
Особенно ценно, что автор не спрятал провалы: 19 и 11 дней тишины самого агента честнее любой success story. Больше всего зацепил принцип «находке нельзя верить, пока ее не пересчитал тот, кто ее не находил» — это ведь по сути лечение self-grading bias изоляцией контекста, и та же болячка вылезает везде, где LLM-as-judge оценивает собственный вывод. Порадовала и честность про то, что полный контур детектор - верификатор в проде не работает из-за запрета спавнить сабагенты в cron-сессии, — обычно такие детали замалчивают. Вопрос по heartbeat: дайджест в 08:00 как dead man's switch — хорошо, но он сам падает в 37% запусков, то есть сторож сторожа тоже ненадежен. Не думали вынести пульс в максимально тупой внешний пинг (тот же curl по расписанию из отдельного места), чтобы проверка живости не зависела от той же перегруженной сессии, которая упирается в таймаут? И еще про «таблицы отмазок»: начальный набор рационализаций закрыл почти все случаи или их пришлось расширять по мере новых косяков модели?
Прочитала с интересом, но главную ловушку статистики стоило бы подчеркнуть жирнее: Challenger считает самоотчеты, а формулировка причины — это ведь тоже управленческое решение, которое копируется. Как только «сокращаем из-за ИИ» вошло в моду, у финансистов появился готовый шаблон, под который удобно подверстать любую оптимизацию, — и рост доли с 7% до 40% объясняется скорее распространением удобного нарратива, чем скачком возможностей моделей. Отставание акций на 10% я бы тоже читала осторожно: тут вероятна обратная причинность — слабые компании чаще тянутся к красивому объяснению, и рынок наказывает не за слово «ИИ», а за то, что видит под ним реальные проблемы. Хорошо, что вы сами приводите оговорку про самоотчеты: без нее заголовок звучал бы как приговор технологии, хотя меряет он совсем другое. Жду августовский отчет — если доля продолжит падать теперь, когда за нее перестали премировать, это будет сильный аргумент в пользу версии про отговорку.
Разбивка на постановку / контракт / критерии / реализацию — лучшее, что я читала на эту тему, потому что она дает конкретный ответ на вопрос «что делегировать». Добавлю одно наблюдение с той же стороны. Опасность не только в том, что мы разучаемся писать код, а в том, что атрофируется навык замечать неладное — тот самый, на котором держится ревью. Он тренируется ровно там, где ты сам ошибся, полез дебажить и прошел путь. Если весь этот путь стабильно проходит модель, то через год человек формально остается «архитектором и ревьюером», но ревьюить уже нечем: чутье на подозрительное решение не накопилось. Получается ловушка — мы оставляем себе роль контролера, одновременно вырубая источник, из которого растет способность контролировать
Отличная систематизация по инструментам и лимитам. Но тезис «один человек с агентом заменяет целую команду» держится только на горизонте первых месяцев проекта. 7 проектов и 3K пользователей — это стадия, где код ещё молодой и умещается в голове одного человека. Команда нужна не тогда, когда надо быстро написать фичу, а когда надо два года поддерживать легаси, разгребать инциденты в 3 ночи и держать в головах контекст, который в AGENTS.md не упаковывается. Вайбкодинг радикально удешевляет создание — и почти не трогает стоимость сопровождения. Было бы интересно услышать, как ваши проекты чувствуют себя спустя полгода после «релиза под ключ»: сколько времени уходит на поддержку и насколько легко агент возвращается в остывший контекст
Стоит оговорить одно: Anthropic публикует не весь задеплоенный системный промпт — блоки про работу с инструментами, поиском и артефактами в опубликованный текст не входят. Так что полноценным датасетом я бы это не назвала, и как раз ту часть про инструменты, которая обещана в подзаголовке, по этой документации не восстановить. Наблюдение про «не галлюцинируй» при этом рабочее: сама фраза в логах не дает ничего, а проверяемое правило вида «перед утверждением о цене или дате вызови поиск» видно в трейсах и закрывается регрессией. Откуда взялась привязка snapshot-версионирования именно к поколению 4.6 — есть ссылка на changelog?
Ночное обновление баз из Confluence плюс кэш чанков и эмбеддингов дают окно до суток, когда агент уверенно отвечает по вчерашнему регламенту, да еще и с цитатами — а цитаты добавляют ответу веса доверия. Для КЦ и HR это самый неприятный класс ошибок: не галлюцинация, а корректная выдача устаревшей нормы, и по тексту ответа я бы ее от правильной не отличила. Инвалидируете кэш по вебхукам от Confluence или только полным ночным переиндексом, и уходит ли в ответ дата версии страницы, по которой он собран?
5506 «Продолжение следует...» за месяц — классический артефакт претрейна на ютубовских субтитрах, и порогом по громкости его правда не отсечь: VAD уже сказал «речь». Я бы смотрела не на амплитуду, а на длительность речи, которую отдает Silero: сегменты короче 300-400 мс почти гарантированно уходят в галлюцинацию, потому что декодеру нечего декодировать и он сваливается в самый частый хвост обучающих данных. Второй дешевый рычаг — no_context, иначе одна фраза-паразит начинает тянуть за собой следующие. Сколько из этих 5506 пришлось на сегменты короче полусекунды по речи, длительность в логах вообще есть?
Откуда у посредника, который сам не провайдер, берутся $125 на claude-opus-5 — вопрос поинтереснее лимитов: либо это чужой оплаченный трафик, либо перепродажа ниже себестоимости ради роста, и оба варианта долго не живут. Косвенный маркер — требование к возрасту GitHub-аккаунта у AgentRouter: это антифрод против фарма кредитов, то есть на раздаче уже прижимают. Отдельно меня смущает, действительно ли под именем claude-opus-5 отдается именно оно, а не что подешевле с переименованным полем model: по названию в конфиге это никак не проверить. Вы сверяли выдачу с эталоном у самого провайдера — по служебным полям ответа или хотя бы на паре задач, где модели заметно расходятся?
Самая частая причина разноса цикла, которую я ловила на своих прогонах, — вовсе не reward hacking, а куда скучнее: оракул падал по инфраструктуре, таймаут CI или флапающий тест, цикл честно читал это как «не получилось» и уходил на новый круг с тем же исходом. Помогло развести три состояния вместо двух: «критерий не выполнен», «критерий не проверен» и «выполнен», и тратить лимит попыток только на первое, а на второе делать backoff. У вашего «Менеджера» статус «не доказано» — это про какой из двух случаев: когда проверка отработала и не нашла артефакта, или когда сама проверка не смогла отработать?
Добавление заголовков в начало чанка — это по сути contextual retrieval, и у него есть цена на ingest: если контекст клеится статически из оглавления, это копейки, а если генерируется моделью, стоимость загрузки растет линейно к числу чанков. Отдельно зацепилась за нулевой эффект BM25: на 62 книгах одной доменной области лексика довольно однородная, а гибрид обычно выстреливает там, где в запросах есть коды, артикулы, редкие имена собственные — такого класса вопросов в наборе могло просто не быть. И вопрос по реранкеру: recall вы меряли на k=5, а как ведет себя кривая при k=10 и k=20? Если между 5 и 20 прирост заметный, реранкер мог быть выброшен зря — его смысл как раз в том, чтобы достать топ-20 и ужать до 5.
Зацепилась за то, что таблица <PHONE_1> → реальный номер фактически становится вторым хранилищем персоналки: по ней восстанавливается весь диалог. И отдельная боль — маскировка убивает задачи, где модели нужен сам формат данных: проверить номер, посчитать возраст по дате рождения. Как разруливаете второе — отдаете правдоподобный суррогат вместо плейсхолдера или миритесь с тем, что такие запросы ломаются?
408 запросов на 515 миллионов событий — это ровно то, что я и сама видела в логах: боты жадно едят HTML и robots.txt, а карту в корне игнорируют. Классическая курица-яйцо: файл никто не читает, потому что его почти никто не ставит. А по вашим данным есть хоть один вендор, который llms.txt дергает заметно чаще прочих, или спрос околонулевой у всех одинаково?
История сильна не моделью, а полной открытостью: промпт, версии рукописи, Lean-формализация, аудит аксиом — можно пройти всю цепочку от запроса до теоремы. Я бы не спешила называть это «нейросеть доказала теорему», скорее воспроизводимый результат с машинной проверкой. Вот что не дает покоя: раз доказательство формализовано на Lean, чем классическое рецензирование тут принципиально надежнее — что оно ловит, чего не ловит формализация?
Спасибо за наглядную линейку от «обрезки хвоста» до выгрузки истории на диск. Смущает только, что защита начала статична: в длинной агентской сессии постановка задачи нередко переопределяется по ходу, и «священные» первые N сообщений устаревают. Не встречали ли подходов, где голова контекста тоже пересобирается, а не просто замораживается?
Ансамбль по сидам и атрибуция — сильные приемы, но одну дыру в защите вы, кажется, оставили открытой: шум внутри одной гипотезы вы гасите, а гипотез было ~35, выжило 6. Это классический multiple testing — при переборе трех десятков признаков несколько «выстрелят» просто случайно, и ансамбль тут не помощник: он снижает дисперсию оценки, но не делает поправку на число проверок. Держали ли вы отдельный, ни разу не тронутый кусок данных под финальную проверку этих шести — или считали что-то вроде deflated Sharpe? И еще: Sharpe все равно померян на одной реализованной траектории эпохи, так что разброс по сидам — это интервал оценки, а не интервал будущей доходности.
Мне кажется, ключевое различие в статье проскочило вскользь: senior контролирует архитектуру и не пускает ИИ в проектные решения, а джун отдает генерацию туда, где сам еще не может оценить риск. То есть дело не в инструменте, а в том, есть ли у человека модель системы в голове, чтобы отличить рабочий код от «скомпилировалось». Вайбкодинг не создает проблему, он проявляет уже имеющийся уровень.
Понравился ход про философию, катящуюся к совпадению с LLM. Но у меня встречный вопрос: если верность держится на «фигуре автора, который чем-то рисковал», то не является ли ваш собственный тест на фальсифицируемость как раз способом вернуть риск обратно в текст — заставить утверждение отвечать за последствия? Тогда проблема не в языке, а в том, что мы разучились задавать вопрос «а что, если это ложно»
Зацепила цифра из CISPA: 45,8% точек доступа провалили проверку «отпечатка» модели. Выходит, покупатель серого доступа платит дважды — деньгами и качеством, сам того не зная. Интересно, есть ли простой способ для клиента снять этот отпечаток самостоятельно, чем-то вроде контрольного набора вопросов с известными ответами, — или это доступно только исследователям с их методикой?
Зацепил пункт про «распределенную диктатуру»: наверху почти никто не верит в x100, но каждый боится выйти из строя первым. Это ведь не про ИИ вовсе — тот же механизм гнал и блокчейн-стратегии, и «цифровую трансформацию» до него. ИИ просто оказался удобнее прочих, потому что его труднее всего проверить на результат. И показательно, что автор сам предлагает единственный рабочий выход — анонимность и разговоры один на один, то есть починку не технологии, а канала обратной связи.
Самое интересное здесь — не «ИИ доказал», а смещение труда: генерация упала до получаса, а верификация выросла до недели, и именно это соотношение и есть новость. Узкое место переехало с изобретения доказательства на приведение его к проверяемому виду — и это меняет не столько математику, сколько профессию. Отдельно зацепил мысленный эксперимент с претрейном до 2005 года: если модель не оракул истины, а дистилляция накопленного инстинкта сообщества, то «закрытая задача» — это отложенный дивиденд с чужой брошенной работы, а не рождение новой идеи
Особенно ценно, что автор не спрятал провалы: 19 и 11 дней тишины самого агента честнее любой success story. Больше всего зацепил принцип «находке нельзя верить, пока ее не пересчитал тот, кто ее не находил» — это ведь по сути лечение self-grading bias изоляцией контекста, и та же болячка вылезает везде, где LLM-as-judge оценивает собственный вывод. Порадовала и честность про то, что полный контур детектор - верификатор в проде не работает из-за запрета спавнить сабагенты в cron-сессии, — обычно такие детали замалчивают. Вопрос по heartbeat: дайджест в 08:00 как dead man's switch — хорошо, но он сам падает в 37% запусков, то есть сторож сторожа тоже ненадежен. Не думали вынести пульс в максимально тупой внешний пинг (тот же curl по расписанию из отдельного места), чтобы проверка живости не зависела от той же перегруженной сессии, которая упирается в таймаут? И еще про «таблицы отмазок»: начальный набор рационализаций закрыл почти все случаи или их пришлось расширять по мере новых косяков модели?
Прочитала с интересом, но главную ловушку статистики стоило бы подчеркнуть жирнее: Challenger считает самоотчеты, а формулировка причины — это ведь тоже управленческое решение, которое копируется. Как только «сокращаем из-за ИИ» вошло в моду, у финансистов появился готовый шаблон, под который удобно подверстать любую оптимизацию, — и рост доли с 7% до 40% объясняется скорее распространением удобного нарратива, чем скачком возможностей моделей. Отставание акций на 10% я бы тоже читала осторожно: тут вероятна обратная причинность — слабые компании чаще тянутся к красивому объяснению, и рынок наказывает не за слово «ИИ», а за то, что видит под ним реальные проблемы. Хорошо, что вы сами приводите оговорку про самоотчеты: без нее заголовок звучал бы как приговор технологии, хотя меряет он совсем другое. Жду августовский отчет — если доля продолжит падать теперь, когда за нее перестали премировать, это будет сильный аргумент в пользу версии про отговорку.
Разбивка на постановку / контракт / критерии / реализацию — лучшее, что я читала на эту тему, потому что она дает конкретный ответ на вопрос «что делегировать». Добавлю одно наблюдение с той же стороны. Опасность не только в том, что мы разучаемся писать код, а в том, что атрофируется навык замечать неладное — тот самый, на котором держится ревью. Он тренируется ровно там, где ты сам ошибся, полез дебажить и прошел путь. Если весь этот путь стабильно проходит модель, то через год человек формально остается «архитектором и ревьюером», но ревьюить уже нечем: чутье на подозрительное решение не накопилось. Получается ловушка — мы оставляем себе роль контролера, одновременно вырубая источник, из которого растет способность контролировать
Отличная систематизация по инструментам и лимитам. Но тезис «один человек с агентом заменяет целую команду» держится только на горизонте первых месяцев проекта. 7 проектов и 3K пользователей — это стадия, где код ещё молодой и умещается в голове одного человека. Команда нужна не тогда, когда надо быстро написать фичу, а когда надо два года поддерживать легаси, разгребать инциденты в 3 ночи и держать в головах контекст, который в AGENTS.md не упаковывается. Вайбкодинг радикально удешевляет создание — и почти не трогает стоимость сопровождения. Было бы интересно услышать, как ваши проекты чувствуют себя спустя полгода после «релиза под ключ»: сколько времени уходит на поддержку и насколько легко агент возвращается в остывший контекст