Рецепт!

Игра в закрытость

Мало кто заметил, но Amazon выиграл дело против Perplexity. Теперь Perplexity не может выбирать товары на Amazon через свой браузер Comet.

Это пример довольно простого тезиса – если игроки хотят закрыться от AI-агентов, они могут это сделать. В крайнем случае – через суд.

Другой хороший пример – доступ к Youtube. Я практически полностью пересел на Claude, но запросы "вот в этом подкасте какие ключевые идеи <link>" отправляю в Gemini. У него дырочка есть в Youtube. Остальным приходится искать транскрипты в интернете.

Мощь агентов – не только крутость мозгов, но и доступ к источникам и тулам. А у кого больше экосистема – у того больше контроль для агентских ручек и ножек.

Иду на Snow BASE от South HUB говорить про то что разработчики больше не нужны 😅

До CTO модели доберутся через пару релизов.

Сооснователь Uber Travis Kalanick вышел из восьмилетнего стелс-режима. Всё это время он строил Atoms – автономный транспорт и промышленность.

Трэвис написал яркий резонансный манифест. Манифест написан как будто это месть для Uber. И это так.

Трэвиса буквально выкинули из Uber в 2017. За год до этого Uber выпустил красивое видео с ребрендингом компании, которое называется Bits and Atoms.

Вы поняли? Uber это только Bits, а Трэвис теперь делает Atoms. Кстати, Uber закрыл направление беспилотных автомобилей в 2020-м году.

Новый рынок такси это рынок беспилотных такси. В Калифорнии скоро останется только Waymo. Если Atoms сможет в беспилотные такси, это будет реальная угроза для Uber. Месть!

When I told my friends, family and colleagues about my plans for what was next, they were really excited that I was “coming back.”

The thing is, I never left.

Кстати, из Uber его выкинули его за sexual harassment. Официально.

Вот так выглядит гитхаб Лёши Миловидова, CTO ClickHouse.
Opus 4.6 release date: Feb 5, 2026

Помните историю когда Anthropic выложил маркетинг булшит статью про невероятные успехи в COBOL и акции IBM упали на 10%?

Так вот, кто-то реально проверил как Claude показывает себя на задачах по COBOL. Показывает плохо )

Особенно паршиво выглядят расчеты произведенные COBOL-правилами написанными Opus 4.6, на картинке.
тудым сюдым семь-восемь 🤡

p.s. акции IBM уже откатились

Anthropic запустили доступ к десктопу через телефон.

Само по себе это оч круто - пдф там доделать или фотки в почту отправить, супер.

Но это все промежуточные шаги. Ноут закрыл и не работает - бред же.

Либо копия десктопа переедет в облако, либо у всех теперь будут домашние Mac mini.

Я бы хотел чтобы победили облака - это безопасней и удобней. Но видя глобальное недоверие и всякие блокировки, получиться может наоборот.

Исторически, тонкие клиенты каждый раз проигрывают битву за пользователя.

Еще есть неожиданный вариант - телефон подтянет всю нужную инфу и станет филиалом десктопа. Пока такого не получилось.

Apple, ау?

LLM-as-a-judge - индустриальный антипаттерн

Есть в AI индустрии две инженерные идеи, которые с распространением ллм-технологий на мой вкус стали антипаттернами. Это LLM-as-a-judge и векторный поиск. Их объединяет то, что они не требуют ментальной нагрузки при внедрении (easy), но при этом непрозрачно прячут под капотом огромную сложность (not simple). Про эмбеддинги поговорим потом, а вот с llm-as-a-judge давайте разбираться.

Казалось бы ну кайф. Вот сделали вы систему (агентскую, разумеется). Надо ее качество замерять на каждом эксперименте. Раньше надо было нанимать разметчиков, обучать их, ждать днями каждую разметку. А тут написал промпт проверки ответа и LLM сама быстро все размечает. Эксперименты ускоряются, ту зэ мун.

Но вот проблема: этот промпт надо написать. А для сложных сценариев надо еще и подложить в этот промпт какие то данные о внешнем состоянии системы в тесткейсе. Уже выглядит как задачка на context engineering. А как из всех возможных промптов выбрать тот, который реально работает? Видимо руками размечать. Кажется, что и ок, руками разметили один раз, а потом у нас автоматический оценщик. Ну так то тоже мимо: дрифт ответов системы (а это буквально задача R&D - сдрифтить ответы системы в сторону правильных), и все, по хорошему надо переразмечать качество джаджа.

Ну ладно, есть задачки где промпты-инструкции простые. Там то все хорошо? Ну вот нет: модели же еще и игнорируют эти инструкции. Опять же в разном проценте случаев на разных распределениях аутпутов системы. Один раз посчитать и забыть не получится.

Че-то нифига не просто да? И без живых разметчиков не обойтись. Вот и получается, что вроде внедрять очень просто, но заставить это стабильно и хорошо работать - очень трудно.

Когда же llm-as-a-judge полезен?

1. Команда относится к джаджу, как к отдельному продукту. Со своими метриками, своим беклогом. И все равно дополняет разметочными метриками.

2. Джадж - это часть композитного реворда для алаймента. Тут все ясно: даже неидеальный рекорд может накинуть метрик.

3. Джадж удешевляет человеческие разметки. Например схема с перекрытиями, где один из размерчиков - это ллм. А лучше ансамбль разных ллм.

4. Вы учитесь строить продукты. Тогда действительно пофиг на финальное качество, главное, чтоб сложилась культура работы с хоть какими то метриками.

В остальных случаях я убежден, что llm-as-a-judge - это бомба замедленного действия, которая дает ложное чувство контроля.

Один из неожиданных индустриальных выводов на текущий момент – llm достаточно плохо проверяет работу llm. Ошибка умножается, поддерживать сложно, и так далее.

Есть несколько областей где полезно, Артём их хорошо описал. Я добавлю еще две:
– если вы оптимизируете и собираете пайплайн на небольших моделях. Тогда проверять умным оракулом - очень ок
– если система это агент про действия а не про интеллект и проверка проще чем сама задача

Стоит использовать llm-as-a-judge только если вы понимаете зачем, а не как дефолтный выбор.

На прошлой неделе выступал на Snow Base в Красной Поляне с вбросом разработчики больше не нужны, и CTO тоже. Крутые ребята собрались там!

Я провёл высокоточную аналитику по бенчмарку METR с использованием карандаша. AI закроет задачи CTO в 2028 году.

Скептики конечно скажут что аналитика фуфло, работа CTO великая и не описана, и вообще ты рассказывал с пивом в руках, не считается. Ну напомню что раньше так говорили про разработчиков, а потом – про архитектуру сервисов. И где мы сейчас?

Разработке в старом виде больше не будет. На всех уровнях. Привыкайте.

Разработчики прошлого это слесари которые лобзиком делали мебель. Роль CTO – собрать лучших слесарей, сделать операционные процессы мастерской, наладить отдел посиделок на стульях для тестирования и так далее.

Мы входим в эпоху фабрик софта. CTO будущего это ребята которые делают заводы. Заводы эти, кстати, довольно лёгкие.

Работа это точно другая. Кто-то перестроится, станет экспертом по заводам, поднимется. Кто-то не сможет и будет ныть о старых добрых временах.

Стульев явно будет больше. Ну, софта. Спрос вырастет, вместе с ним и индустрия. А вот маржинальность этого ремесла скорее всего будет падать.

А вот нужно ли нам много строителей заводов – непонятно. Софт писать всё легче. Возможно, заводы схлопнутся совсем. А может и наоборот – спрос вырастет невероятно.

Точно понятно, что старых слесарей больше не нужно.