Последние несколько дней слушаю с перерывами интервью Ленни Рачицки с Фионой Фанг из Anthropic. Редко советую посмотреть полуторачасовой выпуск целиком, но этот точно стоит времени. Фиона руководит командами Claude Code. До этого были 11 лет в Microsoft, запуск Facebook Marketplace, инфраструктура Instagram. Она прошла несколько технологических эпох и хорошо чувствует, что действительно меняется, а что — просто хайп. Больше всего меня зацепила одна мысль. Правда зацепила, это не клише от чатгпт 😉 Мы уже привыкли говорить, что AI ускоряет разработку. Но почти никто не обсуждает, что происходит дальше. Если команда теперь может писать в несколько раз больше кода, то где становится следующее ограничение? Ответ оказался неожиданно приземлённым. Не в AI. В понимании пользователя, его потребностей и выборе фокуса. И, конечно, в коммуникации между людьми. В том числе, чтобы вся команда одинаково понимала, что вообще нужно строить. И что будет возможно построить с использованием AI нового поколения. Кажется, именно поэтому последние полгода я всё чаще слышу от сильных продуктовых команд одну и ту же мысль: разработка перестаёт быть главным бутылочным горлышком. Да и сам уже вижу на живых примерах — сейчас запускаем систему управления стоками, которую сделали за 3 недели. Ранее это бы заняло минимум 3 месяца. В интервью ещё много интересного: 📌 как Anthropic использует Claude в ежедневной работе; 📌 почему они постепенно уходят от длинных роадмапов; 📌 как меняются требования к инженерам; 📌 какие проблемы AI пока так и не смог решить. Если будете смотреть одно интервью про AI этим летом — я бы выбрал именно это. ▶️ https://youtu.be/Ybrl4FYM57c #videoholidays #claude #aifuture

🏁 Он вам не Сиол Вчера навайбкодил hermes agent на VPS, сделал ему тулс что бы тот читал каналы, и попросил оценить кого больше любит Игорь за последнюю неделю. И вот что агент мне ответил:

🔍 Фанат Claude или OpenAI? Вывод: судя по тону и фокусу постов за неделю — автор явно больше внимания и энтузиазма уделяет Anthropic/Claude, хотя прямых заявлений в духе "я фанат X" в данных нет. Что говорит за Anthropic/Claude - Пост про RLI-бенчмарк — самый развёрнутый и эмоциональный: подробный разбор скачка Fable 5 до 16% (против 6.3% у GPT-5.5 и 8.3% у Opus 4.8), с расчётами потенциального влияния на экономику США. - Анонс возврата Fable 5 в доступ — с 🚨 эмодзи, явный маркер "горячей" новости. - Релиз Sonnet 5 разобран детально — цены, лимиты, сравнение с Opus 4.8, включая честное признание минусов (дороже и хуже на части бенчмарков — 😭). Что говорит про OpenAI - GPT-5.5 и GPT-5.2 Pro упоминаются только как точки сравнения в контексте бенчмарков Anthropic — отдельного разбора релизов OpenAI за неделю нет. - DeepSeek v4 — короткая нейтральная заметка об апдейте и ценах, без эмоциональной окраски.

(Не)много накликбейтил, теперь скажу ему сделать индекс Сиола что бы оценивал кто канат перетягивает больше 😂

Вот и подходят к концу обе мои квоты на Fable (личная и корпоративная). Отличная ли это модель? Да 👍 Как когда-то GPT-4 значительно повысил надёжность языковых моделей, Fable значительно повысила надёжность агентов. В случае Опуса я предполагал по умолчанию, что я не доверяю выхлопу модели. На все нетривиальные изменения прогонял simplify, review, codex:adrversarial-review, qudo и отсматривал результат глазами. Потому что много раз меня Опус подводил, как в макро, так и в микро-решениях. В случае Fable я по привычке это тоже сначала делал, но пользы от этого было уже не так много. Предположение по умолчанию поменялось. Более того, Fable регулярно делала что-то сверх того, о чём я её просил. Например, когда она составляла отчёт в виде HTML странички, она установила playwright, headless chromium, сделал итоговый скриншот странички, загрузила его на закрытый корпоративный paste, чтобы я мог посмотреть на дизайн глазами до развёртывания. Мог ли такое сделать Опус? Мог конечно, но только если бы я описал весь путь. А я даже не знал, что я такое хочу!😜 Означает ли это, что Fable не ошибался? Лол, конечно ошибался, и тоже и в макро, и в микро. Но вот количество ошибок было гораздо меньше, и исправлять их было проще.

Говорить, что ИИ заменит человека, так же как говорить, что калькулятор заменит математика

Суть метафоры понятна, но ирония в том, что сама метафора подтверждает мысль, что придется конкурировать с ИИ на уровне кода, но не архитектуры. 1. Математик не конкурирует с калькулятором, просто потому что математик - это скорее архитектор, а не кодер. Он работает с теоремами, абстракциями, доказательствами, а не считает, что-то на калькуляторе. 2. Была такая профессия "вычислитель", вот у этих ребят как раз возникли проблемы с появлением вычислительной техники, им пришлось конкурировать со способностью быстро и точно считать, и по итогу победили машины. Любые метафоры неточны, важно понимать, что конкуренция возникает когда возникают общие функции, у хороших инженеров много функций, которые не пересекаются с ИИ, а вот у чисто кодеров пересечений много.

На мой взгляд видео уже устарело. Могу согласиться, что большинство моделей не могут в хорошую архитектуру. Но стоит попробовать новейшие модели - GLM-5.2 или топовые Клода, как понимаешь, что архитектуру он делает лучше, чем большинство разработчиков.

Это очень опасное заблуждение, которое возникает из-за того, что на уровне кода (одного приложения) ИИ может выдавать результат, который работатет (проходит тесты). Архитектура системы - это другой разговор. Первое: архитектура оценивается не в моменте, а на дистанции. Хорошая архитектура позволяет сопровождать и развивать систему в течение длительного времени. Проблема в том, что даже самые сильные ИИ-модели принимают решения, которые накапливают техдолг - неверные границы доменов, жесткое зацепление, слабая связность, дублирования и т.д. На дистанции 2–3 месяцев (без человеческих корректировок) внесение изменений в проект порождает эффект домино и кучу побочек. ИИ не "видит", какие части системы меняются синхронно, какие требуют унификации в виде общих интерфейсов и абстракций, часто LLM создаёт распределённый монолит, вместо микросервисов и т.д. Второй момент — есть разница между архитектурой приложения (архитектура на уровне кода) и системной архитектурой. По приложению довольно много типовых схем, которые ИИ может воспроизвести и под контролем человека даже более-менее сопровождать. Системная архитектура - это всегда компромисс между стоимостью, рисками и конкретными ограничениями: бюджетом инфраструктуры, легаси, требованиями регуляторов, реальной командой, которая будет это развивать. ИИ выдаёт архитектуру которая не учитывает нюансов, эта архитектура некая средняя температура по полате, которая получиалась из кучи схем, используемых в обучении, В результате решения не соответствуют конкретной ситуации и не решают проблем системы.

Интересное в мире хай-тек 3 июля 2026 Кратко о событиях за прошедший день 🟢 NVIDIA выпустила прошивку 1.1.8 для игровых мониторов с G-SYNC Pulsar, снизив задержку ввода на 240 Гц и улучшив работу Ultra Low Motion Blur 2. Также обновление частично устраняет проблему, из-за которой G-SYNC мог переставать работать после выхода монитора из спящего режима. 📈 Samsung готовит третье за год повышение цен на память. В III квартале массовая DRAM может подорожать до 20 %, а LPDDR — более чем на 20 %. Это продолжит рост себестоимости смартфонов, ноутбуков и ПК на фоне сохраняющегося дефицита памяти. 👾 Для Sega Mega Drive выпустили первый рабочий порт Linux. Ядро запускается на оригинальном процессоре Motorola 68000 в режиме NOMMU, а для работы использует 4 МБ памяти картриджа Mega EverDrive. 🥬OnePlus и Realme отказываются от OxygenOS и Realme UI в пользу единой ColorOS. Также бренды перестраивают продуктовую и сервисную инфраструктуру под единый стек. 🙂 Sony обсуждает дальнейшее повышение цен на PlayStation Plus после прибыльности сервиса в 2025 финансовом году. В компании заявляют, что продолжат «балансировать ценность и стоимость» за счёт тарифов и монетизации, не уточняя масштабы возможного роста. #хайтекзадень

🛠 Метод Работа фокусируется на ускорении трех ключевых типов операций в GNN: - 🔹 Разреженные свертки. - 🔹 Редукции на графах (min/max, агрегация). - 🔹 Внимание на графах. Замечают, что распределение вершин графов по степеням обыкновенно имеет тяжелые хвосты. Потому разделяют вершины на две группы по степени — легкие и тяжелые вершины. Для легких вершин используют параллелизм по признакам (один threadblock на вершину). Тяжелые вершины еще разбиваются на чанки по ребрам с промежуточной агрегацией по чанкам. Объем подгружаемых данных не меняется, но ускорение достигается за счет того, что один блок обрабатывает несколько узлов, тем самым повышая memory-level параллелизм. Для слоев внимания реализуют кастомный вариант FlashAttention для CSR-матриц. В наивной реализации материализовали матрицы внимания, а тут оно и не нужно. CSR-кернелы для произвольной sparsity уже неплохи, но не используют ценный ресурс современных GPU — тензорные ядра. Если запаковать окрестности вершин в тайлы 16×16, то можно воспользоваться ими и, даже выполняя некоторые лишние вычисления, выжать ускорение. Кроме того, существующие либы почему-то не используют cuSPARSE — рабочий и мощный инструмент. Одно его накатывание уже дает заметный профит. 📊 Эксперименты Эффективность реализации проверяют на бенчмарке GraphLand — наборе задач с большим разнообразием структур и свойств графов. Удается выжать медианное ускорение порядка 2× (вплоть до 8.5×**) против DGL на GATv2, медианное ускорение **2.6× (вплоть до 10×**) на операциях редукции. Операции разреженных сверток на cuSPARSE дают вплоть до **8× ускорения. Кроме того, пиковое потребление памяти оказывается обычно в разы меньше (а то и в десятки раз) по сравнению с DGL. PyG тоже в среднем ест меньше GPU VRAM, но при этом он куда медленнее. В ablation показывают, что выигрыш от graph reordering и векторизованных загрузок зависит от графа. Для плотных графов с высокой степенью выигрыш значителен, для разреженных и малостепенных — мал. В приложении много внимания уделено исследованию полезности блочной разреженности с тензорными ядрами — где накладные расходы на перестановки окупаются, а где нет. 💡 Выводы Классная и полезная работа, дающая существенный толчок всей области GraphML. Хоть она и довольно нишевая и на любителя, тем не менее импакт более чем серьезный. Интересно, где еще есть низковисящие фрукты для оптимизации?

On Efficient Scaling of GNNs via IO-Aware Layers Implementations 📄 Статья 💻 Код Засветилось уже много где в русскоязычных тг-каналах про ML, но оно заслуживает отдельного разбора. Графовые нейронные сети имеют ряд небесполезных приложений — всякий там дизайн новых молекул, физика, анализ транзакций и социальных сетей. Однако их оптимизации уделялось сравнительно мало внимания по сравнению с LLM, потому существующие реализации в популярных фреймворках (DGL, PyG) далеки от оптимального потребления памяти и вычислительных ресурсов. Существенной сложностью при работе с графами являются нерегулярная/разреженная структура данных и нерегулярные паттерны доступа. И в работе наших соотечественников (Spotlight на ICML, между прочим) сделали куда более эффективную реализацию стандартных графовых операций.