🛠 Как идет работа/дебаг теперь 🍆

📐 [SOTA 2026 Founder Mode] Категориально-Алгебраический Протокол AI-Агента (Categorical Algebra Explained) Объяснение алгебраической математической структуры нашей автономной агентской системы: 1️⃣ Monoid (associative_state_merge): Ассоциативное объединение состояний памяти. Позволяет сливать контексты сессий в любом порядке (A + B) + C = A + (B + C) с нейтральным элементом (пустая память) без потери целостности. 2️⃣ Semigroup (streaming_diff_channel): Полугруппа потоковых изменений. Задает математическое правило склейки изменений в коде/базе: Diff(A) · Diff(B) = Diff(A · B). Гарантирует, что пошаговые правки всегда корректно суммируются. 3️⃣ Homomorphism (dev_to_ciso_audit_transformation): Гомоморфизм безопасности. Преобразование из пространства разработки в пространство CISO-аудита: f(x · y) = f(x) · f(y). Сохраняет структуру безопасности при переходе от кода к OWASP-проверкам. 4️⃣ Endofunctor (monadic_isolation_fmap): Эндофунктор изолированного контекста. Отображает категорию агентов в саму себя (F: C → C). Позволяет применять функции fmap внутри защищенного изолированного контекста (brain) без утечки наружу. 5️⃣ Coalgebra (infinite_autonomous_observation_thought_action_loop): Коалгебра разворачивания автономии. Задает динамику бесконечного цикла наблюдения и действий: unfold: State → Output × State. Разворачивает текущее состояние в бесконечную автономную работу 24/7. 6️⃣ Catamorphism (deterministic_fold_log_reduction): Катаморфизм (Fold / Сжатие логирования). Математическая операция свертки рекурсивных логов и шагов (100k шагов → сжатый отчет): fold: Tree(Log) → Summary. Базис работы нашего демона сжатия!

Почему монолиту приписывают одну базу данных (БД)? Нет такого требования, что если монолит, то должна быть одна БД. Но любители микросервисов часто приписывают монолитам недостаток в виде одной базы. Монолит может работать с несколькими БД и хранить данные в отдельных базах на одном сервере или даже на разных серверах. У меня в SonyRewards было несколько баз данных: основная пользовательская, банковская, почтовая с маркетингом, сессии, каталог и база для контроля отгрузок. Каждая база может быть настроена по разному на производительность, разные стратегии резервного копирования и безопасности в зависимости от данных, которые там хранятся.

Iron Core. Часть четвёртая. Путь от GDS до выхода на посадку 5:30 утра, аэропорт Нагпура. Пассажир кладёт паспорт на стойку Air India, сотрудница что-то вводит, бросает взгляд на экран и клеит бирку на багаж. Всё привычно, кроме одной детали. Система, которая ещё в декабре создала бронь и выпустила электронный билет, к этому моменту уже выбыла из игры. За стойкой смотрят не на неё, а на отдельное приложение с собственным слоем данных. Где-то за сутки до вылета управление тихо переходит от коммерческой системы к операционной, и прежняя главная база превращается в справочник только для чтения. Тот же принцип объясняет, почему один из рейсов сдвинулся на 75 минут, а уведомление так и не пришло.

Все там будем, или Почему игровые движки всегда заканчивают одинаково В движке «Блицкрига» нейтральные свиньи по недосмотру отнаследовались от боевого юнита. Завидев врага, они патриотично лезли за оружием, которого у них не было, зато патроны находились сами собой из неинициализированной переменной. Стрелять нечем, а боезапас есть, и свиньи дружно валили игру нулпоинтером. Починили изящно, выдав свиньям парабеллум, но обнулив патроны. Вся прелесть в том, что это не курьёз одной студии, а закономерная стадия, через которую проходит любой движок. Сначала весь код держится на наследовании от одного всемогущего класса, и баги в нём лечатся тем же наследованием, пока команда не упрётся в стену. Дальше по замкнутому кругу через компоненты, конфиги и собственный язык, и снова к началу. Посмотрим, какие четыре стадии проходит каждый движок и почему круг так тянет замкнуться: https://u.habr.com/elBSf

Отделяем текстовый скоринг от продуктового ранжирования Как оказалось, научить поисковый движок находить релевантные документы = только половина задачи. Следующий вопрос в том, какие из найденных совпадений важнее для конкретного продукта. Окей, движок уже умеeт строить индексы по нескольким полям (title, abstract и т.д.) и поддерживает разные типы поиска: например term, phrase, prefix, фразовый поиск. Но после поиска вклад каждого совпадения просто добавлялся в итоговый вес документа. Например, для запроса`title:diabetes abstract:"type 1" abstract:insulin*` мы находили три независимых совпадения: • term - diabetes в title; • phrase - "type 1" в abstract; • prefix - insulin* в abstract. Для каждого совпадения BM25 считал свой вес, после чего все веса просто суммировались: BM25 total doc score = BM25(title:diabetes) + BM25(abstract:"type 1") + BM25(abstract:insulin*) Базово текстовая релевантность оценена за счет частоты термина, его редкости среди всех документов, длине поля. И это ок, но продуктово мы помимо всего знаем, что совпадения в заголовке обычно важнее совпадения в abstract, и что точная фраза часто ценнее совпадения по одному слову (или хотя бы по префиксу). Поэтому я подсмотрела идею с Rank Profiles - добавлением правил ранжирования по заданым критериям, который добавляет веса нужным докам без переиндексации. Пример профиля из конфига: rank_profile: name: debug-weights field_weights: title: 1.5 query_type_weights: term: 1.5 phrase: 1.7 prefix: 0.5 Теперь BM25 по-прежнему считает базовый score каждого совпадения, но перед суммированием вклад умножается на коэффициент: document score = BM25(title:diabetes) × 1.5 × 1.5 + BM25(abstract:"type 1") × 1.0 × 1.7 + BM25(abstract:insulin*) × 1.0 × 0.5 Поскольку индекс уже хранит информацию о каждом найденном совпадении (поле, тип запроса и базовый вес), политику ранжирования теперь можно менять прямо во время поиска - без переиндексации документов с явным разделением ответственности: • основная retrieval часть находит совпадения и сохраняет их контекст; • BM25 считает базовую текстовую релевантность; • Rank Profile задает правила, по которым совпадения влияют на итоговый вес документа; • Explain разбивка помогает понять, почему документ получил именно такой вес. Чтобы было проще отлаживать ранжирование, добавила Explain-панель. Для каждого документа можно посмотреть, из каких вкладов сложился итоговый вес: какое совпадение сработало, в каком поле, какой базовый вес посчитал BM25, какие коэффициенты применились и какой вклад каждое совпадение внесло в итоговый результат. На скрине из TUI (который, кстати, был тщательно причесан и допичкан инфо панельками) как раз видно такую разбивку по весам для каждого найденного документа. Сейчас Rank Profile умеет учитывать поле документа и тип совпадения. В дальнейшем список сигналов можно расширить: например, добавить свежесть документа, популярность или поведенческие сигналы (клики пользователей). Главное, чтобы поисковый движок умел вычислить такой сигнал - тогда его можно включить в ranking pipeline без изменения индекса. В итоге базовый текстовый скоринг остается отдельным слоем, а продуктовая логика ранжирования начинает жить поверх него. Это позволяет менять стратегию ранжирования, не меняя сам индекс.

Развлекаюсь как могу, чуть позже больше конкретики понятной дам, а пока вот это можно отдать ИИ 🤖 на объяснение: Главный тезис: алгебра переводит ваши инварианты из тестов в теоремы

Все три модели пришли к одному выводу, и это самое ценное в ответе: в прошлых раундах ключевые свойства L11 — детерминизм replay, идемпотентность, корректность rollback — проверялись эмпирически (chaos-replay, snapshot-equivalence, rollback drill). Общая алгебра даёт качественно другое: если структуры спроектированы так, что они по определению являются моноидом, полурешёткой и инверсной полугруппой, эти свойства перестают быть тем, что можно случайно сломать — они следуют из типа.

Закончилась эпоха Недавно Дядюшка Боб (автор книг "Чистый код", "Чистая архитектура" и т.д.) заявил, что вообще не читает код, который пишет LLM, вместо этого он использует ограничения в виде автоматизированных тестов и других проверок. Подобных заявлений с каждым днем становится все больше и количество будет только расти. Можно возразить, мол "а как же качество?". На самом деле за последние два года качество генерации сильно возросло, если грамотно гранулировать задачу, можно обойти многие ограничения ИИ (например, дублирование функций и классов, если их нет в контексте, и тому подобные вещи). Фокус ушел на AiSDLC и описание архитектуры проекта. Мне кажется, в моменте мы переживаем этап взросления разработки, когда от написания кода мы уходим к архитектуре и идеям. В этом смысле Роберт Мартин не изменяет своим принципам – он всегда топил за более высокоуровневый взгляд на программирование, и теперь ему стало делать это чуть проще. Но что будет с кодом? Мне кажется, что примерно то же, что произошло с ассемблером: как рабочий инструмент его мало кто использует, но интерес к пониманию того, как все работает, остался, многие смотрят видео по низкому уровню просто из любопытства, из-за того вайба, который дает погружение в инженерию. Поэтому код не исчезнет, просто заниматься им будут по желанию, из любопытства, а не потому что надо.

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

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

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

⚡️ Снизили стоимость AI-оркестрации на -92.5% при росте точности до 97.8%: Разбор Архитектуры Monosnap SOTA v3.3 Пока большинство промптит единичные модели, мы перевели нашу мультиагентную систему на 4-уровневый Гибридный Спекулятивный Роутинг (Tier 0–3) + 5-слойную защиту контекста. 🛠 Как устроена система под капотом: 1️⃣ Черновой слой (Tier 0 SLM): Amazon Nova Micro ($0.035/1M) за 100мс делает триаж и черновой patch. 2️⃣ Кодирующий слой (Tier 1): Claude 3.7 Sonnet на AWS Bedrock. За счет выравнивания промптов по границам 4096t получаем 90% скидку на чтение кэша ($0.30/1M). 3️⃣ Совет Судей (Model Council): OpenAI GPT 5.6 (логика) + Google Gemini 3 Pro (визуальный UI) верифицируют черновик с конформным порогом (>= 0.70). 4️⃣ Защита Контекста: Вынос логов в SQLite FTS5 (SearchOS Lake) + офф-тред субагенты удерживают активное окно контекста на уровне 6–11% (18K-22K токенов) даже после 500+ шагов! 📊 Метрики бэктестов (N=500 прогонов): — Стоимость 500 задач: $0.0185 USD (vs $0.2475 baseline, -92.53% экономии) — Качество кодинга (Pass@1): 97.8% (vs 81.6% baseline, +16.1 п.п.) — Латентность: 2.12s (vs 6.84s baseline, -68.9% ускорения) — Статистическая значимость: Z = 95.70σ 🖼 В аттаче — подробные схемы архитектуры общего оркестратора, кэширующего прунера и би-темпоральной памяти CoALA. #AI Architecture #Agents #LLM #DevOps #SOTA2026

1/ Google Antigravity 2 IDE UI (Control Plane): Человек работает в привычном графическом интерфейсе IDE, ставит задачи, просматривает diffs и дает человеческое одобрение (Human Gatekeeper). Контекстное окно в UI остаётся минимальным, так как тяжелые логи не попадают в чат. 2/ Hybrid Orchestration Bridge (hybrid_orchestration_bridge.py): Запрос из UI транслируется во внешний Headless CLI Work Engine в виде неинтерактивной команды agy -p "task" --sandbox. 3/ Programmatic Context Control Engine (context_pruner_v2.py): Программно обрезает технический шум терминала, выставляет жесткие токеновые бакеты и дополняет префикс промпта до границы 4096 токенов (для >85% попаданий в KV-кэш). 4/ AWS Bedrock Tiered Gateway (aws_bedrock_router.py): • Простые интенты и ранжирование отправляет на копеечную модель Amazon Nova Micro ($0.035 / 1M токенов). • Сложный рефакторинг и кодинг отправляет на Claude Sonnet ($3.00 / 1M токенов) с использованием Bedrock Prompt Caching (90% скидка на чтение из кэша). 5/ 3-Слойная Память + SearchOS Lake + SEED Hindsight: • CoALA Memory: Записи штампуются метками времени (valid_at/invalid_at valid_at/invalid_at), предотвращая использование устаревших фактов. • SearchOS Lake: Перехватывает поисковые запросы субагентов в SQLite WAL mode, экономя 80–90% API расходов. • SEED Hindsight: Подмешивает извлеченные уроки прошлых ошибок, поднимая успешность первично сгенерированного кода до 95.9%. 6/ Возврат в UI: CLI возвращает в IDE UI строго типизированный контракт (CodeChangeV1), не раздувая историю диалога.

Вики — это не память (ч.2) Здесь стоит провести одно чёткое различие, потому что терминология в этой области всё ещё расплывчата. Эти системы всё чаще описываются как памят». LangChain называет OpenWiki «слоем вики-памяти для ИИ-агентов», используя маркетинговую формулировку. Слово несёт большой вес, но покрывает две довольно разные вещи. Корпусное знание — это то, что делает вики: компилирует то, что содержится в наборе документов, репозитории или архиве Gmail. Она отвечает на вопрос «что содержит этот материал?» Пользовательская память и опыт — это другая ось: что предпочитает конкретный человек, что они решили на прошлой неделе, какой подход их команда уже отвергла, что агент пробовал в другом приложении вчера и чем это закончилось. Это относится к идентичности, а не корпусу, накапливается из взаимодействий, а не поступления, и должно уметь обрабатывать противоречия, устаревание, происхождение и удаление для каждого пользователя. Вики отлично справляется с первым и не пытается делать второе Компиляция вашего Gmail в страницы говорит агенту, что находится в вашем Gmail. Это не говорит агенту, что вы передумали по поводу решения о вендоре в разговоре во вторник, или что предложенный подход уже однажды не сработал для вас. Эта вторая ось — то, для чего предназначен выделенный слой памяти, такой как Mem0: память, привязанная к user_id, чтобы она следовала за человеком между сессиями, приложениями и агентами, обновляемая на месте при изменении фактов, а не добавляемая навсегда. Эти два подхода дополняют друг друга, и ошибка не в выборе вики. Ошибка в том, чтобы верить, что вы решили проблему памяти, потому что скомпилировали корпус. Вынесите из этого три вещи: 1) Компилируйте ваши документы в поддерживаемые страницы, когда корпус стабилен и часто перечитывается 2) Добавляйте полноценный поиск, когда он вырастает за пределы личного масштаба, как и рекомендует исходная формулировка. 3) И держите различие между компиляцией корпуса и запоминанием пользователя, потому что вики даёт вам первое, а не второе. ИИ Wiki — реальный паттерн с реальной идеей: знание должно быть скомпилировано один раз и поддерживаться, а не перевыводиться на каждый вопрос, и поддержка, отсутствие которой убило человеческие вики, это именно та работа, которую модель выполняет бесплатно.

ИИ-Wiki: Код, продукты, жизнь (ч.1) За последние месяцы четыре разные команды реализовали одну и ту же идею Wiki для ИИ: OpenWiki, DeepWiki, AutoWiki,, GBrain. Работает просто: LLM читает набор источников, компилирует их в поддерживаемый набор markdown-страниц и обновляет эти страницы по мере изменения источников. Агенты читают эти страницы вместо того, чтобы заново выводить всё из сырого материала на каждый вопрос. Паттерн стал категорией, а системы, построенные на его основе, всё чаще называют просто «агентными вики». Вот что это такое на самом деле, что построила каждая команда, где это ломается и с чем это постоянно путают. Идея: компилировать при поступлении, а не при запросе Начнём с проблемы, потому что паттерн — прямой ответ на неё. Стандартный способ передать модели базу знаний — это поиск (retrieval). Вы загружаете документы, разбиваете на чанки и создаёте эмбеддинги, а при запросе извлекаете релевантные фрагменты и отвечаете. Это работает, но имеет структурный изъян: ничего не накапливается. Каждый вопрос начинается с сырых фрагментов, так что модель каждый раз заново выводит одно и то же понимание, и десятый вопрос о кодовой базе не дешевле и не лучше первого. LLM Wiki инвертирует этот порядок: вместо того чтобы собирать знания при запросе из сырых кусков, LLM собирает их один раз при поступлении в долговечные страницы и затем поддерживает их. Когда поступает новый источник, модель читает его, обновляет затронутые страницы, пересматривает и отмечает противоречия с уже написанным, выводя его один раз и затем обновляя. Архитектура состоит из трёх слоёв: 1) Сырые источники неизменяемы: статьи, документы, репозитории, данные. Модель читает их и никогда не редактирует. 2) Вики — это созданный LLM markdown, которым ИИ полностью управляет: резюме, страницы сущностей, концепций, перекрёстные ссылки и т.п. 3) Схема — это конфигурационный файл (CLAUDE.md, AGENTS.md или аналогичный), который сообщает модели, как организована вики и какие рабочие процессы запускать, что превращает её в проводника, а не просто в чат-бота с доступом к файлам. Над всем этим работают три операции: – приём источника и размещение его по затронутым страницам; – запрос к вики с возможностью сохранять хорошие ответы как новые страницы, чтобы исследование тоже накапливалось); – периодическая проверка, выискивающая противоречия, устаревшие утверждения и потерянные страницы. Что на самом деле построили лаборатории и различия между реализациями. DeepWiki — вики как общедоступная утилита. Замените github.com на deepwiki.com в URL любого публичного репозитория, и вы получите сгенерированную, навигабельную вики этой кодовой базы: обзор архитектуры, индекс файлов, граф зависимостей и поиск с ссылками на исходный код. AutoWiki придерживаются подхода, что документация должна быть артефактом сборки, а не побочным проектом. Она строится из исходного кода, организована вокруг того, как кодовая база работает на самом деле, и обновляется при изменении репозитория. AutoWiki выполняет двухпроходный анализ и работа распределяется между специализированными агентами, каждый из которых охватывает один аспект репозитория с достаточным контекстом для создания хорошей страницы. OpenWiki перешли от кода ко всему LangChain открыли исходный код OpenWiki и расширили его до OpenWiki Brains с двумя режимами: Code Brain — исходный вариант для репозиториев, и Personal Brain, который строит вики из ваших собственных подключённых источников. Этот второй режим — самое интересное. Personal Brain принимает данные из Gmail, Notion, git-репозиториев, X, Hacker News и веб-поиска и синтезирует их в локальную markdown-вики, к которой обращается агент. Категория перешла от «документируй мой репозиторий» к «скомпилируй мою рабочую жизнь». GBrain: персональная open-source версия GBrain применяет ту же форму к личной базе знаний, а не к кодовой базе: markdown в git-репозитории, файл схемы и автоматически поддерживаемый граф перекрёстных ссылок сущностей. Никакой векторной базы, никакого сервиса — просто файлы, которые модель и человек могут читать.

Граф: циклы, наблюдающие за циклами (часть 2) Если присмотреться к тому, как Системы на практике реализуют процессы совершенствования, вырисовывается определенная закономерность: они никогда не сводятся к одному циклу.

Системы — это сети циклов, соединённые с другими циклами

Так, грамотно управляемая компания представляет собой граф циклов: быстрые операционные циклы (ежедневный/еженедельные совещания/анализ метрик) встроены в более медленные управленческие циклы (квартальное планирование), те – в циклы аудита (ежегодные и, что важно, независимые, которые проверяют, соответствуют ли реальности цифры, выдаваемые операционными циклами), а все они — в самый медленный цикл уровеня совета директоров, который задаётся вопросом верны ли сами цели. Технологии ИИ пришли к такой архитектуре аналогичным путём. Грамотный конвейер обучения ИИ – это цикл типа «чемпион = претендент», когда модель-кандидат должна превзойти текущую модель, прежде чем заменить её, а также циклы мониторинга дрейфа, отслеживающие, соответствуют ли поступающие данные тем, на которых модель обучалась и механизмы отката (автоматический возврат к предыдущей версии, если показатели после развертывания выходят за допустимые пределы). Сюда же входят отложенные оценочные выборки, недоступные для цикла обучения, своего рода "слепой" цикл, чья единственная задача выявлять случаи, когда оптимизирующий цикл пытается обхитрить свои собственные тесты. Каждый элемент здесь — это цикл. Надёжность системы кроется в связях между ними: какой цикл передает данные другому, какой наблюдает за каким и какой может наложить вето на действия другого. Проблема Гудхарта решается методом парных показателей: каждому оптимизирующему циклу сопоставляется цикл, отслеживающий контрметрику и выявляющий способы "дешёвого" достижения KPI. Проблема "слепоты" по отношению к вышестоящим уровням решается иерархией, в которой более медленный цикл определяет целевые показатели для быстрого, а пересмотр целей сам по себе является регламентированным циклом, а не случайным решением того, кто установил их изначально. Конфликты разрешаются через явный арбитраж: над конфликтующими циклами стоит ещё один цикл, который принимает решение по поводу возникающих компромиссов. Проблему деградации показателей решают с помощью аудиторских контуров, единственная функция которых – периодически проверять, сохраняют ли данные других контуров связь с реальностью.

Иными словами, меняется структура процессов цикла. Цикл больше не изолирован в Системе

Человеческий организм работает так же: терморегуляция – это не один термостат, а сеть взаимодействующих рефлексов, а иммунная система, по сути, выступает как цикл аудита всего организма, в котором медленные процессы меняют физиологические параметры, которые помогают быстрым циклам его адаптации. Создание одного чётко работающего контура было искусством прошлой эпохи (ещё каких то пару месяцев назад). Мастерство эпохи ИИ — это архитектура контуров Понимание того, что метрика не должна существовать в отрыве от других, что у контрольных точек должны быть ответственные лица, что скорости процессов нужно разграничивать, чтобы быстрые контуры не разрушали то, что поддерживают медленные, и что некий контур в такой Системе должен отвечать за саму реальность.

​​Harness Handbook: Making Evolving Agent Harnesses Readable, Navigable, and Editable Способности агента определяются не только базовой моделью, но и его harness — кодом, который собирает промпты, управляет состоянием, вызывает инструменты и крутит control loop. Под новые модели, API и требования harness приходится постоянно дорабатывать, но перед любой правкой нужно сначала найти все места в коде, реализующие нужное поведение. Авторы называют это behavior localization и считают главным узким местом в эволюции harness: запросы формулируются в терминах поведения, а репозиторий устроен по файлам и функциям, и именно этот разрыв всё усложняет. Решение — Harness Handbook, представление кодовой базы, организованное вокруг поведения, а не структуры файлов. Это трёхуровневое дерево (L1 — обзор системы, L2 — стадии и компоненты, L3 — записи со ссылками на конкретный исходник) плюс state-register view для состояния, разделяемого между стадиями. Строится автоматически: статический анализ через tree-sitter без LLM → раскладка по стадиям через proposer-reviewer loop → синтез дерева. При модификации агент идёт сверху вниз через Behavior-Guided Progressive Disclosure (BGPD): от архитектуры к нужным стадиям и конкретным местам в коде, а потом сверяет кандидатов с текущим исходником. Отдельная полезная деталь — resynchronization: после правок handbook инкрементально обновляет только затронутые части, а ссылки, которые больше не резолвятся, помечает как stale, вместо того чтобы молча указывать на неверный код. Проверяли на двух open-source harness'ах (Terminus-2 и Codex), 60 запросов на модификацию, планировщик — DeepSeek-V4-Pro, качество планов оценивали три LLM-судьи: — win rate по качеству плана: 45.6% против 26.7% на Terminus-2 и 38.3% против 28.3% на Codex — и всё это при меньшем расходе токенов планировщика: −12.7% на Codex и −8.6% на Terminus-2 — по локализации все 24 сравнения recall/precision/F1 в пользу handbook, прирост F1 от +5.0 до +18.8 — слабый планировщик с handbook подбирается к локализации более сильных моделей (GPT-5.5, Claude Opus 4.8) и заметно реже промахивается мимо нужного кода целиком Paper Code Project Мои обзоры: Personal blog Medium Linkedin #paperreview

Иммутабельная денормализация Изучение баз данных всегда сопровождается понятием нормализации, а конкретно первыми тремя формами, которые задают нам ограничения, помогающие правильно разложить все по таблицам. И это действительно база, без которой нормально работать не получится. Но есть, как обычно, нюансы. В реальных проектах выясняется, что нормализованные данные сложно соединять и выбирать. При глубоком уровне зависимостей, чтобы добраться до внешней сущности, нужно либо соединять 5 таблиц, либо делать 5 запросов. Пример из Хекслета. У нас есть программа обучения, которая состоит из модулей, в которые входят темы которые состоят из уроков, которые состоят из юнитов (теория, практика, тесты). На это все накручено много логики по прогрессу и отображению. В такой структуре, вопросы типа "какой урок следующий по порядку?" заставляют поломать голову. В таких ситуациях мы начинаем денормализацию данных. В основном она сводится к добавлению внешних ключей на косвенно связанные сущности, например, урок связан с программой обучения через модуль. Здесь мы добавляем ключ на программу прямо из урока, что позволяет выполнять запросы на уроки одной программы без необходимости соединять таблицы. В принципе это довольно базовая концепция с которой знакомы большинство разработчиков, но дальше начинается самое интересное. Как только мы делаем денормализацию, то сразу упираемся в необходимость синхронизировать данные. Если поменялось в одном месте, надо не забыть поменять и в другом месте. Это цена денормализации и ее надо платить. > Кстати есть такой концепт как синхронизирующие триггеры, которые вешают только для того, чтобы синхронизировать подобные данные. Когда-то я его активно использовал, но сейчас не стал бы Но есть и альтернативный подход, который иногда работает лучше. Вместо того, чтобы синхронизировать денормализованные данные, мы можем пересмотреть саму систему и сделать данные иммутабельными (неизменяемыми), чтобы их не нужно было синхронизировать. Например в том же примере с уроками, мы сделали так, что урок принадлежит одной программе и не может перемещаться между программами. А это значит, что мы можем записать в урок все внешние ключи, которые никогда не поменяются. В таком случае цена денормализации это занятое место ключами, чем обычно можно пренебречь. А что касается бизнес-логики? Да, такой подход работает не всегда, но, как показала практика, его можно использовать намного чаще чем кажется. Например в нашем случае это даже наоборот хорошо, иначе получается ситуация, что при переносе урока нужно переносить прогресс, что значительно усложняет логику и создает странное впечатление, когда в середине программы вдруг появляются пройденные уроки. При этом сама процедура довольно редкая, поэтому если кому-то придется пройти два раза один и тот же урок (перенос в нашем случае это копирование), то ничего страшного не случается. Но есть места где без синхронизации данных не обойтись никак. В основном это касается статусов, они могут меняться и за ними нужно следить. Telegram | YouTube | AI Клуб

2 пачки новых оптимизаций и SOTA. Много разных направлений, в основном все вокруг контекста / окна контекста / работы с деградацией / работы с мульти агентскими системами фрактальными (оркестраторами и общим контекстом), 3х уровневый слой памяти и оптимизация структуры/алгоритмов. + всякие другие оптимизации / симбионты склеянные из открытых источников. Можете скормить своим LLM/AI/агентам картинки - что-то могут выцепить и улучшить. Собираю дальше архитектуры/blueprints/расширения/модули для AI IDE и собираю на коленке через opensource свой кастомный AI IDE с полный контролем окна контекста и всех уровней памяти. -> какие-то вещи похожие есть в Hermes, но не то.

Сможете ли вы найти пять ошибок в Python-коде, который вызывает LLM Вызов языковой модели давно стал обычной строчкой. Импортировали клиент, отдали промпт, забрали ответ. С обычными ненадёжными зависимостями питонист управляется отлично, ставит таймаут, вешает retry, помнит про идемпотентность. А вызов модели попадает в код так, будто это локальная функция, без оглядки на то, что она платная, медленная и недетерминированная. Дальше всё вылезает по очереди. asyncio.gather запускает десять тысяч корутин разом, провайдер отвечает лавиной отказов, и неудачные запросы тоже съедают лимит. Таймаут срабатывает на клиенте, а модель дописывает ответ до конца, и токены считают все, так что за одну использованную генерацию можно заплатить как за четыре. А тест на равенство строк зеленеет ровно до дня, когда один и тот же промпт с нулевой температурой вдруг отдаёт разные ответы. Разберём пять мест, где поход по сети мстит за отношение к нему как к локальному вызову.

Gemma4 техрепорт и честный omnimodal на 12b от 🕸 Вот ждал 📦, что будет пример в лоб, как кодировать без предобученных бэкбонов аудио, видео и картинок информацию и кидать в модель. Это и есть настоящее omnimodal, тк multimodal работает именно с доп моделями в своих модальностях + слой проекции. 😮‍💨 Ребята из 🏳️‍🌈 с выходом Gemma4 зарепортили инфу о такой модели. Теперь информация с разных модальностей кодируется напрямую в матрицы и проходит всего лишь слой эмбеддингов внутри модели без доп внешних clip'ов и тп. Почитать можно в тех репорте тут. 🤙 Как это работает детально: 1. Изображение. Не используется ни vit, ни clip, ни resnet. Только патчи 48x48х3 (rgb канал 🧠) в нарезке серией. После выпрямляется в flatten и эмбедится в плотном слое (чисто факторизация а-ля как в SVD и als). 2. Аудио. Никаких мелспектров, а только сырой PCM сигнал. Нарезка также по 40мс частотой 16кГц, выпрямление и снова проекция. Все это порождает эмбы токенов звука и аудио, которые кормятся в слои внимания вместе с текст эмбами. Важный нюанс с позицией: Чтобы модель знала, где находится патч, инженеры не используют сложные 2D-RoPE эмбы. Они добавляют факторизованные координатные вложения - отдельные обучаемые векторы для координаты X и координаты Y, которые просто прибавляются к полученному токену картинки или звука. 🧠 В общем, для меня это было самое интересное. Тк в остальном в мире уже видны лучшие практики, которые комбинируй как можешь: и по локально-глобальному вниманию, и по sparsed attention, и хаки с KV, rope, скрытое рассуждение (только тут оно не в латентах, а тупо скрывают тексты от юзера), и обобщенные слои с early exit для MTP (multi token prediction). Итого, читаем. Образовываемся и stay tuned 🦾

В начале 90-х, когда СССР распадался на части, в советском квартирном дизайне появился один революционный элемент - арочный дверной проём. Для тех, кто тогда делал ремонт, он был символом протеста против унылого советского быта и олицетворением красивой заграничной жизни. Этот элемент даже получил народное название - «Санта-Барбара», по аналогии с невероятно популярным американским сериалом. Строители тогда прямо спрашивали заказчиков - Сантабарбару будем делать? Действие сериала происходило в небольшом калифорнийском городе, где жили миллионеры (такой город действительно существует, и его жители действительно далеко не бедные) А в домах героев сериала арочные проёмы были буквально повсюду. Более того, они были даже в заставке сериала. Я вспомнил про ту самую советскую «Санта-Барбару», потому что недавно в отпуске мы снимали большую квартиру в Италии с необычными арочными проёмами и сводчатыми потолками (фото в шапке ⤴️ ) Такие дома строили в Средиземноморье ещё 300–400 лет назад (и затем дизайн с арками поехал с испанскими колонизаторами в Южную Америку, Мексику, с оттуда и в Калифорнию в дома миллионеров) Такая сложная форма потолков и проёмов появилась вовсе не ради красоты. Причина была чисто практической. Железобетон тогда ещё не изобрели, а древесины в Европе было мало, к тому же её старались не использовать из-за опасности пожаров. Поэтому перекрытия и дверные проёмы выкладывали из кирпича в виде арок и сводов. Такая конструкция отлично распределяет нагрузку, получается очень прочной и способна выдерживать даже небольшие землетрясения. Многие из этих домов прекрасно сохранились до наших дней. Владельцы делают внутри современный ремонт и сдают квартиры туристам. Пожить в такой квартире, это очень необычный эстетический опыт. Если интересно, как такие арки выглядят без штукатурки, загляните в первый комментарий (мы, конечно, стены не вскрывали, а вот в ресторанчике под нами хозяева сняли старую штукатурку) ⤵️ Незаметный бизнес

Mamba: архитектура, которая шла убивать трансформеры В декабре 2023 по ML-тусовке прокатились заголовки в духе «трансформерам конец». Повод дали два исследователя со статьёй про архитектуру Mamba, внутри которой не было того самого attention, на котором держится весь современный тир-лист нейронок. И при этом она жевала длинные тексты в несколько раз быстрее трансформера и на меньшей памяти. Вместо того чтобы сверять каждый токен с каждым за квадратичную цену, она ведёт одно бегущее состояние и на лету решает, что впустить, а что отбросить как шум. Спойлер, который спустя столько времени уже не спойлер: трон трансформеры не потеряли. Но история кончилась не тем, что очередной хайп-трейн не взлетел. Пока все спорили, кто кого, индустрия сделала третий ход, которого никто не ждал.

Время измен — Мы верны Claude, — сказал стартапер — А если завтра Gemini станет лучше? — Не станет Ребята из одного нашего стартапа пол-весны вылизывали промпты под Claude, обвязали их костылями и гордились «глубокой интеграцией». Вышел ChatGPT 5.6 — половина нагороженного стала мешать. Пока отдирали — конкурент обогнал их на голом апи. Сейчас время королевской гонки и корона держится у модели в среднем 41 день. С точки зрения венчурного инвестора, это — катастрофа. А вот создателя продукта — чудо. Каждые полтора месяца ты получаешь либо более умный мозг либо тот же, но дешевле. Ни-фи-га не делая, просто меняя одну строчку в конфиге. Это как если бы ключевой сотрудник каждые 40 дней становился вдвое умнее или соглашался на вдвое меньшую зарплату. А ты бы еще выбирал между тремя такими. Поэтому «жениться» на модели — ошибка. Верность в этом браке наказывается. Лучшая стратегия — чемодан у двери. Вывод прост: не влюбляйся в модель — влюбляйся в возможность её бросить. Архитектура, где мозг меняется одной строчкой, сегодня стоит дороже самого мозга.