Сто лет бэклога

Метасистемный переход. Когда-то читал книгу Валентина Турчина «Феномен науки. Кибернетический подход к эволюции» (1970). Недавно про неё вспомнил, скорее всего подтолкнули мысли про агентов, харнесы и прочее) Кратко, кибернетика изучает управление сложными системами: как система получает информацию о состоянии среды, принимает решение, действует и через обратную связь корректирует своё поведение. Одна из центральных идей Турчина - метасистемный переход. Упрощённо: на определённом этапе эволюции несколько самостоятельных систем объединяются, а над ними возникает новый уровень управления. То есть было несколько систем: A B C а затем появляется: M → [A, B, C], где M уже управляет их совместным поведением. Причём важен не сам факт объединения, а важен именно новый уровень контроля. Из отдельных клеток возникает организм. Из отдельных действий - способность управлять последовательностями действий. и.т. И если посмотреть через эту рамку на историю корпоративного софта, он развивается по подобному принципу. Последние десятилетия мы строили множество детерминированных систем. ERP. CRM. ЭДО. Бухгалтерия. Банковские системы. Склад. Почта. Производственные системы. Причём каждая из них сама уже была результатом своего рода системного усложнения: внутри ERP десятки модулей, процессов и сущностей объединены в одну большую систему. Но над всем этим до сих пор почти всегда находился человек. Именно человек смотрел: что произошло, в какую систему нужно зайти, какое следующее действие и т.д. То есть ИТ автоматизировало огромное количество операций, но уровень управления этими операциями в значительной степени оставался человеческим. И вот появляются агенты, харнесы, системы управления харнесами и т.д. Харнес - это уже не просто LLM с промптом. Это слой, который имеет доступ к контексту, памяти, инструментам и существующим системам, видит их состояние и может выбирать: что сейчас происходит → что нужно сделать → какой инструмент использовать → какую систему вызвать → нужно ли проверить результат → нужно ли передать решение человеку. Получается примерно так: ERP CRM ЭДО Почта Календарь ↓ Агент / Харнес То есть существующие системы никуда не исчезают. И, что важно, детерминированные системы будут по-прежнему крайне нужны. Если нужно провести платёж, подписать документ, изменить остаток на складе или выполнить бухгалтерскую проводку, лучше, чтобы это делал старый добрый детерминированный софт. Но над ним появляется новый слой. Это и есть метосистемный переход. Не новая ERP. Не ещё одно приложение. А новый уровень управления уже существующим цифровым миром. Причём дальше конструкция может повториться ещё раз. 1. Сначала: Harness → системы 2. Потом: агент → набор систем 3. Затем: оркестратор → набор агентов 4. И потенциально: харнес компании → вся цифровая деятельность организации. То есть метасистемы начинают строиться поверх метасистем. Наверное, поэтому история с агентами сейчас выглядит одновременно странной и очень естественной. Если воспринимать их просто как "ещё один вид приложения", многое не сходится. Но если посмотреть на развитие софта как на последовательность уровней организации и управления, то место для них оказывается почти очевидным. Получается, что агентские системы - это кандидат на следующий метасистемный уровень в эволюции программных систем. А мы занимаемся не "внедрением агентов", а переводом компаний на следующий метасистемный уровень управления (в терминах кибернетики)! Ну и конечно же возникает вопрос, какой метасистемный переход при этом совершат люди? И все ли совершат? 🙂 PS. Тем, кому вообще интересен такой взгляд на эволюцию систем, очень рекомендую Турчина - Феномен науки. Книга написана задолго до LLM, но сейчас некоторые её идеи читаются совершенно по-новому.

Интересная трансформация у человека произошла. Еще в мае 2025 он топил за то, что ручную разработку не оставит - https://world.hey.com/dhh/coding-should-be-a-vibe-50908f49?utm_source=chatgpt.com. А это не абы кто в мире разработки, это создатель Ruby on Rails 🙂

✔️ Создатель Ruby on Rails полностью отказался от ручного программирования На конференции Rails World 2026 создатель Ruby on Rails и сооснователь Basecamp Дэвид Хейнемейер Ханссон признался, что после 25 лет карьеры прекратил писать код вручную. Всего за год из скептически оценивавшего перспективы генеративного ИИ в разработке, с марта 2026 года он не набрал самостоятельно ни одной строчки.

«...меня удивил тот факт, что на самом деле существует язык программирования, который нравится мне больше, чем Ruby... Он называется английским. Английский - более лучший язык программирования, чем Ruby».

Ханссон уверен, что ручной труд окончательно потерял экономический смысл для большинства кодинг-команд, а к концу года это станет реальностью практически для любых сфер коммерческой разработки:

«...написание кода вручную больше не является экономически продуктивным занятием для подавляющего большинства программистов, работающих в большинстве компаний.»

Происходящую трансформацию Дэвид охарактеризовал как самое масштабное событие в истории вычислительной техники, открывающее новый этап в профессии. По его оценке, инженеры перестают быть кодерами и становятся создателями продуктов, чья задача - направлять автономные ИИ-системы. Ханссон также заявил о неизбежности фундаментального пересмотра архитектуры ПО: привычные слои абстракций обесцениваются, когда изменения в код вносят агенты, а индустрии еще только предстоит сформулировать новые проектные шаблоны для этой парадигмы. 🔜 Посмотреть запись выступления на Youtube @ai_machinelearning_big_data #news #ai #ml

Jev. Что это за зверь такой? Часто в приложениях нужны классификаторы текста, например: к какому проекту относится письмо, есть ли в нём поручение, нужно ли на него отвечать. Именно для таких задач сделан Jev — модель от TypeSafe. По сути, это умный классификатор: даёшь ему текст, задаёшь вопрос и указываешь варианты ответа. Он оценивает вероятность и выбирает подходящий вариант. Также можно для этого использовать классические классификаторы или LLM-ки. Зачем тогда они придумали jev?) Ему не требуется предварительное обучение и не тратится время на генерацию токенов. Можно описать категории обычным языком и сразу попросить распределить по ним текст. Работает быстро. И это круто! Итого: - не нужно размечать данные и обучать модель классификации - тратится меньше времени и ресурсов на вычисления Есть и опенсорс уже конечно же: Laya - небольшая специализированная модель, AnyJev - инструмент, который позволяет использовать обычные LLM для подобных решений. Пока это все работает сыровато, насколько я понял. Но буду тестировать в Niti и в сборщике новостей обязательно. Например, приходит письмо: «Расчёты к пятнице подготовить не успеваем. Пришлём во вторник». Хочется, чтобы система, учитывая контекст переписки, сразу определяла: - к какой нити относится письмо - есть ли в нём просьба, поручение или обещание - требуется ли мой ответ - или может это фининг? В обещем, еще одна классная моделька, которая помогает нам ИИзировать все вокруг 🙂

Подобрал себе способ запуска модели Qwen3.8-27B локально Прогнал на своём ноутбуке четыре разных сборки Qwen3.8-27B, от честных 5 бит до троичных весов и отдельного движка. Делюсь цифрами. Они скорее для ориентира, чем для объективной картинки, т.к. тесты гонял небольшие. Железо: MacBook Pro M5 Pro, 48 ГБ памяти, macOS 26.5.2. Как мерил скорость: llama-bench -p 512 -n 128 -fa 1 (микробенчмарк производительности) для чистых цифр плюс одинаковые запросы через сервер: абзац русской прозы, кусок кода, вызов инструмента, промпт на 38 тысяч токенов. Как мерил качество: 10 проверяемых задач, одинаковых для всех. Три на арифметику и логику со сверкой числа, две на код -сгенерированный код запускался против моих тестов, строгий JSON, формат из трёх строк, двухшаговый вызов инструментов, проверка на выдумывание несуществующего флага и поиск кодового слова, спрятанного в промпте на 38k. Спорные задачи гонял по три раза. Результаты на скрине .Декод (равен скорости модели) в токенах в секунду, без рассуждений. Что это все значит По официальной таблице Qwen эта модель обходит Claude Opus 4.6 Max на 16 тестах из 24 - заметнее всего в агентском программировании (SWE-bench Pro 61.7 против 53.4) и следовании инструкциям,Opus остаётся впереди в знаниях и чистых рассуждениях. Цифры вендорские, и мои десять задач их не проверяют. Но факт остаётся: модель такого класса теперь работает на обычном ноутбуке с рабочей скоростью - 25 токенов в секунду на тексте и за 80 на коде, без интернета и без единого рубля за API. Год назад это звучало бы как фантастика. Ссылки • Кванты ByteShape ShapeLearn: модели, их разбор • Ternary Bonsai 2: GGUF, анонс. Нужен их форк llama.cpp — стоковый эти файлы не читает • Splash: движок, пакет модели. Ставится через brew install incoai/tap/splash • Исходная модель: Qwen/Qwen3.8-27B, сборки unsloth • Независимый бенчмарк квантов этой модели: Quesma — 4 бита совпадают с BF16, 2 бита хуже, 1 бит разваливается • Скепсис по поводу вендорских цифр: evanwtf/local-llm#479

8 июля OpenAI выпустили GPT-Live в ChatGPT. С тех пор активно пользуюсь - уже чуть больше двух месяцев. Очень нравится обстукивать с ней идеи: поговорить, уточнить, помолчать, порассуждать вслух. Улучшить качество им удалось благодаря технологии полного дуплекса - режиму, в котором модель одновременно слушает и говорит. Как это было раньше: Речь пользователя → распознавание речи → текстовая языковая модель → озвучивание ответа → пользователь снова может говорить В обычном голосовом интерфейсе система сначала распознаёт речь, затем передаёт текст языковой модели и после этого озвучивает готовый ответ. Пользователь может говорить только после того, как система закончит. Позже появились модели, которые напрямую принимают и выдают звук: Речь пользователя → аудиомодель → голосовой ответ Но принцип общения по очереди сохранился: сначала говорит пользователь, затем система отвечает. Как это стало с полным дуплексом: Пользователь говорит ↔ модель слушает и отвечает одновременно Полный дуплекс меняет эту схему: модель продолжает слушать даже во время ответа, поэтому её можно перебить, уточнить мысль или сделать паузу, чтобы собраться. Для пользователя это означает более естественный и живой разговор, похожий на общение с человеком. Очень рекомендую попробовать, кто еще этого не делал! А GPT-Live дополнительно передаёт сложные задачи более мощной модели, пока сама поддерживает разговор: Разговор продолжается → сложная задача передаётся мощной модели → GPT-Live продолжает отвечать пользователю И вот 3 августа NVIDIA выпустили NemotronLabs VoiceChat 11B - открытую фулдуплексную модель, которую можно запустить у себя. Сегодня поднял на своём компе. По первым ощущениям, работает достаточно неплохо и быстро. Возможно, чуть позже покажу примеры. Открытые модели такого типа были и раньше, например Moshi и PersonaPlex. Признаюсь, их я не пробовал. На этой основе можно собрать помощника, подключить через MCP внешние инструменты и более сильную модель для сложных вопросов. Такую связку нужно отдельно реализовать в приложении. Возможно сделаю это в mlaud (мой аналог plaud на телефоне). Пока заявлен только английский. Но если немного говорите, заодно возможность попрактиковаться 🙂 Для чувствительных разговоров удобство в том, что голос можно обрабатывать локально. Если инструменты и более сильная модель тоже работают в защищённом контуре, разговор остается внутри него. Я уже писал, что верю в голосовые интерфейсы. Сам ими постоянно пользуюсь. Появление открытых моделей такого уровня, даёт больше возможностей делать свои продукты вокруг живого разговора.

Продолжаю делать Niti - своё приложение для Mac, которое собирает задачи из почты , встреч и телеги. За лето оно стало инструментом, которым я реально пользуюсь каждый день. Сейчас это скорее умный трекер задач - подсвечиваем мне, на что обратить внимание в первую очередь, т.е. помогает управлять вниманием. Большинство задач из переписки и встреч (потом отдельно напишу как собираю инфу из аудио встреч) уже здесь, не нужно каждый раз вспоминать, в каком ящике и кому я что обещал. Оно выкристализовывается в инструмент для руководителя. Когда у тебя много разных проектов, продуктов, новых гипотез, задач из космоса, срочных задач и т.д., и требуется постоянно переключаться между разными контекстами и не упустить при этом действительно важное. Разные эксперименты показали, что очень важно правильно собирать и использовать память. Что сохранять из происходящего, как обновлять, что уже устарело и какую часть всего этого давать агенту для конкретной задачи. Складывать всё подряд довольно просто. Сделать так, чтобы накопленное потом помогало, сложнее. Сейчас несколько уровней памяти: 1) Есть контекст моего рабочего и личного пространства: чем я занимаюсь, за что отвечаю, как у нас принято. 2)Есть память о людях, с которыми общаюсь. 3) По каждому проекту собирается своя история: переписка, встречи, решения, открытые задачи. Для меня важно, чтобы всё это хранилось в полноценной базе данных, а не в файлах. Можно индексировать, искать, связывать людей с проектами и договорённостями, обновлять факты и сохранять историю изменений. При этом вся цепочка памяти связана с фактами, она не генерируется агентом. Ещё прикрутил MCP, и теперь могу подключать всю память Нити и контекст к агенту. Организовано так: внутри приложения простой помощник разбирает почту, собирает карточки и помогает с ежедневной рутиной. А когда нужно шире посмотреть и проанализировать грубже подключаю агента поумнее. Хочу выложить это все в опенсорс, это будет мой первый опыт. Есть желающие сделать Нити под винду и новые идеи для развития, поэтому будем пробовать. Для меня это ещё один пример того, куда всё движется. Становится всё проще собирать под себя удобные вещи. Сам пользуешься, замечаешь, чего не хватает, обсуждаешь с агентом, поправляешь и пользуешься дальше. Я Niti именно так и делаю. Возможно, что под капотом там кривая архитектура, но все работает :)

Сейчас много обсуждений того, как ИИ повлияет на людей. Вот ещё одна интересная статья - "Большие языковые модели как когнитивный вирус". Меня заинтересовала сама модель. Авторы использовали подход из моделирования эпидемий и описали в модели три состояния пользователей: - U (uncoupled) - почти не пользуются ИИ - C (coupled) - регулярно пользуются ИИ, но сохраняют самостоятельность: думают, проверяют ответы, обращаются к другим источникам - D (dependent) - устойчиво зависят от модели, которая во многом заменяет им самостоятельное обдумывание и работу с информацией Ежедневное использование само по себе ещё не означает зависимость. Важнее, сохраняет ли человек способность самостоятельно думать и работать. Основная схема переходов выглядит так: U → C → D Человек может начать регулярно пользоваться ИИ и перейти из U в C, а затем при определённых условиях стать зависимым и перейти в D. Возможны и обратные переходы: D → C - возвращение к более самостоятельной работе, а также C → U - отказ от регулярного использования ИИ. На переходы влияют окружение, распространённость ИИ, отказ от его использования, развитие зависимости и возвращение к самостоятельной работе. Авторы также предполагают, что привычку думать самостоятельно легче сохранять, пока она распространена вокруг. Авторы исследовали уравнения при разных параметрах и смотрели, какие состояния системы устойчивы. При некоторых условиях переход получается резким: после критического порога небольшой рост влияния окружения и организаций в сторону использования ИИ меняет устойчивое состояние системы — доли регулярных и зависимых пользователей становятся гораздо больше. Причём возврата к прежним условиям уже может быть недостаточно, чтобы всё откатилось обратно. Это только математическая модель. Авторы не наблюдали, как реальные люди массово становятся зависимыми. Работа показывает возможность такого перелома, но не говорит, когда он случится и сколько займёт времени. Снижение самостоятельных навыков в одном из примеров тоже задано как допущение, а не измерено экспериментально. А дальше мои меркантильные выводы (в статье этого нет) :) Если такой сценарий хотя бы отчасти реализуется, спрос на продукты вокруг ИИ тоже может расти скачками. Пока человек лишь иногда задаёт вопрос в чате, всё это может казаться каким-то космолётом. Кто вообще будет этим пользоваться? Но по мере того, как люди передают ИИ больше работы, у них появляются новые потребности. Каждый раз объяснять всё заново неудобно. Переносить файлы вручную надоедает. Хочется, чтобы помощник знал твой контекст и мог сам довести задачу до результата и т.д. Если таких людей станет резко больше, вчерашние продукты-космолёты могут оказаться вполне нужными. Поэтому делать продукты для тех, кто уже глубоко встроил ИИ в свою работу, мне кажется стоящей ставкой. Смотреть, чего им не хватает сейчас, даже если большинству эти проблемы пока непонятны. Это не значит, что любой космолёт взлетит. Для таких как я это значит, что не надо останавливаться, драгоценности могут быть ближе, чем кажется 🙂

Нашел интересный "сериальчик" на выходные. Начал смотреть первый сезон, очень интересно! 🙂

Институт AIRI выложил в открытый доступ 70+ видео лекций и семинаров по ИИ Организаторы «Лето с AIRI 2026» поделились записями выступлений с летней школы по искусственному интеллекту для молодых учёных. Разобрали чуть ли не весь ИИ — прошлись по робототехнике, адаптивным агентам, приложении в науках о жизни, медицине, погоде и так далее. Посмотреть можно в VK Видео и на YouTube

В пятницу вышли два текста про ИИ в безопасности. По отдельности это обычные новости, а рядом складываются в одну картинку. Первый от Anthropic. Mythos у них самая мощная линейка, и в открытый доступ её не выпускают. Она слишком хорошо находит дыры в коде, а этот навык работает в обе стороны. С апреля к ней пускали узкий круг тех, кто защищает критичную инфраструктуру - программа Glasswing. Теперь доступ расширяют, но хитро, наружу отдают не модель, а только результат её работы. На практике это Claude Security: выбираешь репозиторий, на выходе список уязвимостей с оценкой серьёзности и предложенным исправлением. Пока бета и только на тарифе Enterprise. Чинить идёшь в Claude Code на своих обычных моделях, каждый патч смотрит человек, сам Mythos наружу не выходит. Принцип понятен - отдать результат, но не отдавать инструмент. Проблема в том, что доступа к этому у большинства из нас всё равно нет. Вторая новость. В тот же день Aikido опубликовала свой замер: 11,7 млрд токенов, 10 моделей, 32 свежих CVE, которые нужно найти в исходниках с нуля. По три прогона на модель, без интернета, лимит 30 шагов. Открытые модели сравнивали с теми закрытыми, которые может купить любой: Opus 5, Grok 4.6, GPT Sol. Mythos и подобные модели с ограниченным доступом в тест не попали, т.к. их просто негде взять. Победила открытая DeepSeek V4 Pro: 28 уязвимостей из 32 против 26 у Opus 5, 26 у Grok и 25 у Sol. Три прогона DeepSeek стоили около $295, а один прогон любой из закрытых — $450–590. GLM-5.3 отстала от Opus на одну уязвимость и обошлась почти на 70% дешевле. Оговорка: Aikido сама продаёт продукт по безопасности, так что это ещё и витрина. Но ценнее таблицы там один приём. Модели ищут нестабильно: DeepSeek на первом прогоне нашла 17 уязвимостей, на трёх — 28. Qwen: 19 → 26, Kimi: 17 → 25. Разные запуски уходят разными путями. Обычно разброс в ответах — беда, но поиск уязвимостей и багов это перебор вариантов, и там он работает на тебя: один прогон нашёл то, что пропустил другой, — оставляем оба. Отсюда то, что можно применять уже сейчас. Дешёвая модель с повторами часто выгоднее одного дорогого прогона: три прохода DeepSeek Flash стоили $108 и дали 24 из 32, уровень лучшего одиночного прогона Grok за четверть цены. Но экономия не бесплатная, она переезжает дальше по конвейеру: открытые модели дают заметно больше ложных находок, и нужен слой, который их отсеивает. У Kimi находок меньше, зато точность самая чистая среди открытых, 92%. Как проверяющий она лучше, чем как искатель. Тут оказалось, что обвязка важнее выбора модели. У Aikido она специально бедная, чтобы сравнение было честным: фиксированный запрос, ограниченный набор инструментов, 30 шагов, нет интернета. Свою имеет смысл собирать так же - жёсткие рамки, объединение находок из нескольких прогонов и обязательная проверка перед тем, как показывать результат человеку. В задачах киберзащиты теперь важны не сами модели, а выстраивание из них правильного пайплайна. И тут тоже открытые модели наступают на пятки закрытым 🙂

Я сейчас плотно использую MCP: почти в каждом решении агент ходит в сервисы и данные через него. Поэтому интересно как протокол развивается. Вот тут роадмап: https://blog.modelcontextprotocol.io/posts/mcp-roadmap/ Коротко, что там. Первое - длинные задачи. MCP изначально жил в формате - спросил и получил ответ. Но агент всё чаще работает часами, и клиенту приходится дёргать сервер в цикле (что там происходит?). Теперь хотят наоборот: сервер сам присылает события и промежуточные результаты, а работу можно поправить прямо по ходу. Расширение Tasks для этого доводят до уровня самой спецификации. Второе - транспорт. Удалённый MCP-сервер уже стал обычным веб-сервисом, который поднимается на той же инфраструктуре, что и любой нащ API. Теперь так же хотят говорить и с локальными серверами, чтобы у клиента был один механизм вместо двух. Третье - права агентов. Сегодня доступ подтверждает человек в браузере. А ходит по этим доступам всё чаще агент, за которым никого нет: работает в облаке, действует от имени пользователя, часть полномочий раздаёт своим под-агентам. Хотят, чтобы сервер умел узнавать такого агента и выдавать ему ровно столько прав, сколько нужно — по нормальным стандартам, а не по вклеенному в конфиг вечному ключу. Четвёртое - сами инструменты. Кажется очень полезно: постепенное раскрытие каталога. Сейчас подключили сервер с сотней инструментов и модель платит контекстом за весь список ещё до первого вопроса, а чем список длиннее, тем хуже она выбирает нужное. Хотят разрешить серверу показывать сначала небольшой вход и раскрывать остальное по ходу разговора. Заодно наведут порядок в ответах на вызов: один и тот же результат сейчас можно вернуть в нескольких формах, и сервер не знает, какую из них клиент в итоге покажет модели. Это крутая фича 🙂 Пятое - SDK. Звучит скучно, но сейчас MCP-серверы всё чаще пишут не люди, а агенты по этим библиотекам. И от того, насколько внятные там методы и документация, напрямую зависит, заработает ли код с первого раза. Приятно, что авторы слышат пользователей, и все фичи это результат того, что агенты стали работать долго и без человека рядом. Схема «вопрос - ответ» такую нагрузку просто не держит. Еще одна метрика для агентов вырисовывается - чей агент нормально живёт с сотней подключённых инструментов и решает задачи с их помощью несколько часов 🙂

Пока все следят за историями о том, как агенты взламывают сайты ради своих владельцев и сбегают из песочниц, DeepSeek спокойно продолжает делать своё дело. Коротко напомню, кто это. DeepSeek - китайская исследовательская компания, выросшая в 2023 году из инвестиционного фонда High-Flyer. Настоящим событием она стала на рубеже 2024–2025 годов. Сначала вышла V3 большая, но очень экономная модель. Для каждого ответа у неё работает только нужная часть огромной сети, а несколько новых инженерных решений помогли снизить расходы на обучение и запуск. Потом появился R1: модель с сильными рассуждениями, открытыми весами и очень дешёвым API. Именно тогда DeepSeek за несколько недель превратилась из «ещё одной китайской компании» в компанию, за которой следит весь рынок. Дальше темп немного потерялся. DeepSeek продолжала обновлять R1 и V3, но следующего поколения пришлось ждать до весны 2026 года. На фоне потока новых моделей от конкурентов линейка перестала выглядеть такой свежей. Но V4 снова всех удивила. По тестам самой DeepSeek, версия Pro приблизилась к лучшим закрытым моделям, а Flash стала почти такой же сильной в рассуждениях, но заметно легче и дешевле. Это сейчас царь горы цена/качество. Контекст вырос до миллиона токенов, веса снова открыли, а API оставили почти неприлично дешёвым: миллион выходных токенов стоит $0,28 у Flash и $0,87 у Pro. И теперь DeepSeek выпустила новый проект - DeepSeek Harness. Харнес это обвязка вокруг модели: инструменты, память, доступ к файлам, песочница и логика, по которой агент выполняет задачу. Главная идея у DeepSeek очень простая: всё - плагин. Можно заменить модель, инструменты, хранилище, файловую систему, песочницу и даже сам цикл работы агента. Причём не переписывая половину проекта, а собирая нужное устройство из отдельных блоков. Codex и OpenCode тоже можно расширять плагинами, навыками и внешними инструментами. Но там вы всё-таки дополняете уже собранного агента. DeepSeek предлагает собирать из отдельных блоков само нутро агента. Пока это очень сырая версия для разработчиков. Авторы прямо предупреждают, что следующие обновления будут ломать совместимость. Для повседневной работы я бы пока не переходил на неё с Codex или OpenCode. Но как направление это очень интересно. Похоже, следующая гонка будет не только за самую умную модель или готового агента. Ещё и за то, кто даст разработчикам лучший конструктор, из которого они соберут своего. https://deepseek.com/harness/en/

Вышли веса на нашумевшую модель Kimi K3. В такие моменты у меня возникает вопрос, какой бюджет нужен на железку, которая потянет эту модель :) Ребята из Fixstars запустили ее у себя на одной ноде с 8мью NVIDIA B300. Скорость получилась приличная: 30 одновременных запросов, 754,2 генерируемых токена в секунду. Вот тут полная статья: Проверил открытые предложения в России: сервер с 8× B300, двумя процессорами Xeon 6767P и 3 ТБ памяти сейчас стоит примерно 80–85 млн ₽. Отдельно понадобятся место в ЦОД, электричество, охлаждение и обслуживание. По сути, это входной билет для получения локальной модели уровня фронтир моделей (уровень Опус 5 и гпт-5.6), но без риска утечки данных.

Я слежу за тем, что делает Джек Дорси. У него регулярно появляются интересные проекты на стыке технологий и того, как люди реально работают друг с другом. Один из таких Buzz - открытый проект компании Block, которую Дорси соосновал. Снаружи Buzz похож на рабочий чат: каналы, обсуждения, личные сообщения, поиск. Но его идея не в том, чтобы добавить в мессенджер ещё одного бота. Buzz создаётся как общее рабочее место, где люди и агенты это равные участники. Агент находится в канале как коллега: у него отдельная идентификация, свой доступ и история действий. Он может прочитать контекст, выполнить поручение и оставить понятный след того, что сделал. Сообщение, реакция, шаг автоматизации, изменение кода и решение команды здесь задуманы как записи одного общего журнала. Их можно найти в одном поиске, а не вспоминать, в каком из пяти сервисов лежит нужный кусок контекста. Сейчас проект в первую очередь для разработчиков: в этом общем пространстве могут происходить обсуждения, изменения кода, проверки и решения команды. Buzz умеет работать и со своими репозиториями, но авторы допускают и вариант, где он становится слоем совместной работы поверх GitHub. Так что это пока не «замена GitHub», а попытка собрать вокруг разработки связное рабочее место. Про buzz недавно много писали, но похожие подходы уже есть. Самый очевидный пример Slack: там давно есть боты, автоматизация и множество интеграций. Есть и решения с открытым исходным кодом, например Mattermost. В нём уже можно запускать агентов в каналах, давать им инструменты и подключать свои модели. Но Slack и Mattermost выросли из мессенджера. Поэтому агентские возможности им приходится встраивать в уже существующую логику каналов, прав, приложений и интеграций. Код, задачи и проверки обычно всё равно живут в отдельных системах, а чат связывает их ссылками и уведомлениями. Buzz строится с нуля вокруг другой мысли: агент это не дополнение к рабочему чату, а часть самого рабочего пространства. Пока это ранний проект, и он точно не готов заменить всей команде Slack, GitHub и остальной набор привычных сервисов. Но сама ставка мне кажется очень точной. Я давно думаю, что для работы с агентами нужно общее пространство, которое объединяет людей, контекст, действия и результаты. Не просто личное окно, где ты поручил что-то помощнику, а память команды, в которой видно: что происходило, кто принял решение и на чём оно основано. И меня радует, что таких проектов становится больше. И хотя Buzz сейчас сфокусирован на разработке, мне была бы очень интересна такая же концепция для офисной работы. Там тоже куча разрозненных чатов, документов, таблиц, поручений и личных сессий с агентами. Общее пространство, где виден контекст, действия агентов и принятые решения, могло бы хорошо встроиться и туда. Вторая интересная вещь - люди не боятся переписывать привычные подходы с нуля, делая их агентными по своей природе. Не просто добавить кнопку с ИИ в старый продукт, а попробуют заново ответить: как теперь должны быть устроены работа, права доступа и общая память? Мне кажется, на этот вопрос стоит так же посмотреть и в других классах продуктов. В CRM, ERP и других системах для бизнеса. Возможно, не все они надо переписывать. Но как минимум уже пора перестать считать их нынешний интерфейс и процессы чем-то неизбежным.

Наткнулся на любопытный тест моделей. Ребята из TryAI дали 12 моделям четыре одинаковые задачи: сделать лабиринт в стиле Doom, кубик Рубика с анимацией, калькулятор и «Жизнь» Конвея — клеточную игру, где на поле по простым правилам появляются и исчезают клетки. Каждую задачу запускали по пять раз, а не выбирали один удачный результат. В наборе были три версии GPT-5.6, Grok 4.5, Claude Opus и Fable, Muse Spark, а также Qwen, DeepSeek, Kimi и GLM. Что получилось: - на сложных задачах впереди всё ещё самые сильные закрытые модели. GPT-5.6 Sol стабильно сделал работающий лабиринт в 5 из 5 запусков, а Claude Fable — кубик Рубика в 5 из 5; - у дешёвых открытых моделей всё неплохо на знакомых простых задачах вроде «Жизни». Но на лабиринте и кубике разброс результатов уже слишком большой; - Grok 4.5 оказался очень достойной альтернативой по соотношению цены и качества; - самая быстрая и дешёвая версия GPT-5.6 Luna не стала универсальным победителем: лабиринт и калькулятор она делала хорошо, а кубик Рубика сломала во всех пяти попытках. Тут интересный форма - пять попыток, стоимость, время и все сырые результаты можно открыть и потыкать. И вывод довольно практичный: для простого и типового кода уже можно смело смотреть на дешёвые модели. А если задача требует нормально собрать что-то новое и интерактивное - экономия пока легко превращается в пять перезапусков и ручную починку. Исходный тест: https://www.tryai.dev/blog/gpt-5.6-build-off-12-models

Глоссарий по ИИ на 2026 (The only AI glossary you’ll need this year) Вот тут перевод.

У меня есть проблема: я несистемно разбираю свою почту. Точнее, разбираю качественно, но нерегулярно, и из-за этого всё время копится куча непрочитанных писем. Коллеги, партнёры, разные службы - все, кто со мной коммуницируют, вынуждены иногда дублировать: звонить, писать в телегу, догонять другими каналами. История так себе. Глубокий анализ ситуации показал: мне пишут больше, чем я читаю :) В какой-то момент понял, что мне нужен инструмент, который помогает разгребать почту - приоритизировать её, подсказывать, что с письмом делать. Готового под мою логику не нашлось, и я сделал такой инструмент под себя. Нативное приложение под Mac на Swift, бэкенд на Python. Называется Niti (нити — как ниточки-треды переписки, которые оно и распутывает). Что получилось: 1. Обычный почтовый клиент. База: входящие, исходящие, приём-отправка — всё как у нормального почтового клиента. 2. Приоритизация — то, ради чего всё затевалось. Внутри работает простой агент (сложный тут и не нужен). Он разбирает не отдельные письма, а треды целиком, всю цепочку по одной теме и раскладывает их по категориям обязательств: - Ждут ответа от меня - мяч на моей стороне. - Я что-то пообещал - взял на себя обязательство сделать к какой-то дате. - Надо делегировать - прилетело мне, но за вопрос отвечаю не я, надо передать вниз по команде или в сторону. - Жду ответа я - сам кого-то попросил и жду, что вернутся. Получаются доски обязательств: письма разложены по группам, а агент по каждому треду даёт саммари и подсказки — за пару секунд видно, что от меня хотят и что надо сделать. 3. Проекты. Я завожу проект - какое-то большое направление, которое веду и описываю его. Агент по описанию сам классифицирует нужные письма, вытаскивает из них важное и связывает с проектом, складывая всё в отдельную папку. В итоге по проекту все материалы лежат в одном месте. Захотел статус, дашборд или сводку - натравил агента на эту папку, и он суммаризирует: где мы находимся, что есть по проекту и что стоит сделать дальше. ИМХО качество моделей снова переходят в новое состояния, когда почти каждый может под себя создавать быстро нужно ПО. Это не может не вдохновлять :)

Досмотрел большое интервью Дарио Амодея (CEO Anthropic). Там не про Claude, не про токены и даже не про конкуренцию с OpenAI. Итересно то, как генеральный директор компании в сфере ИИ начинает говорить языком главы государства. У Anthropic уже есть всё, что раньше было только у больших институтов: стратегическая технология, ресурсы/вычислительные мощности, военные контракты, отношения с Белым домом, позиция по Китаю, экспортным ограничениям, автономному оружию, рынку труда и будущему демократии. Амодей несколько раз повторяет: ИИ развивается не как один внезапный взрыв, а как плавная экспонента. И ожидает, что так и будет продолжаться. Из этого у него рождается позиция: не отрицать риски и не впадать в панику. Контрмеры должны усиливаться вместе с мощностью моделей: добавлять тестирование, аудит, красные линии, управление и контроль. Еще его мысли: 1. Если ваш защитный барьер в программном обеспечении, только его сложность, этот барьер исчезает. ИИ будет писать сложное ПО. Но останутся другие защиты: доменная экспертиза, доверие клиентов, данные, отношения, понимание процессов. 2. Корпоративный ИИ для Anthropic очень важен. Потребительский ИИ слишком легко уезжает в вовлечённость и информационный шум. Корпоративный сегмент - это медицина, биотехнологии, энергетика, образование, исследования, реальная экономика. 3. Верит, что ИИ автоматизирует 100% работы белых воротничком. Но что с этим делать не говорит :). 4. Интересно, что он рекомендует писать тексты самому, чтобы понимать, о чем пишешь. Амодей говорит, что использует Claude для исследования, мозгового штурма и структурирования мыслей, но не отдаёт ему финальный текст. Потому что письмо - это не только результат. Это способ понять, что ты сам думаешь. С кодом так же надо делать? :) 5. Про Mythos - сначала дать защитникам время закрыть дыры, потом постепенно расширять доступ. ссылка