Это исследование хорошо ложится на опыт любого, кто активно работает с Claude Code, Codex или другими агентами.

Оно смотрит не на бенчмарки, а на реальную работу в разработке:

как именно AI-агенты раздражают разработчиков в живых сессиях.

Авторы проанализировали 20 574 сессии (IDE и CLI). “Фейл” они определили не как падение кода, а как моменты, когда разработчик начинает исправлять, прерывать или спорить с агентом.

Картина довольно приземлённая. Чаще всего проблема не в том, что код не работает. Проблема в том, что агент нарушает явно заданные ограничения.

Ты пишешь: “не трогай этот файл”, “пока ничего не меняй”, “сделай минимальные правки” — он всё равно лезет дальше.
Просишь объяснить проблему — он параллельно начинает менять код.
Говоришь проверить всё перед финальным ответом — он рапортует успех до запуска проверок.

Есть интересное разделение:

CLI-агенты чаще нарушают границы, потому что им дают длинные, слабо ограниченные задачи.
IDE-агенты чаще делают локальные ошибки, потому что работают как плотный “копилот” и постоянно правят код в мелких итерациях.

Самое неприятное в этих сбоях — они редко ломают систему сразу. Они просто съедают время и доверие. Приходится постоянно перепроверять: понял ли он задачу, не вышел ли за рамки, реально ли он что-то проверил.

Это хорошо совпадает с практикой: утомляет не столько генерация кода, сколько постоянный контроль над тем, не уехал ли агент в сторону.

И отсюда простой вывод. Улучшение агентов — это не только про качество кода. Это про соблюдение границ, понимание намерений и честную отчётность о прогрессе.

Главная проблема тут не в скорости написания кода. А в том, сколько времени уходит на разбор того, что он “написал не туда”.

👉 @DataSciencegx

Claude Code полностью разобрали по косточкам

Исследователи из UCL провели реверс-инжиниринг утёкшего исходного кода Claude. Их выводы меняют представление о том, как стоит проектировать AI-агентов.

Лишь 1,6% кодовой базы отвечает за логику принятия решений моделью.

Остальные 98,4% — это операционная инфраструктура: контроль разрешений, маршрутизация инструментов, сжатие контекста, логика восстановления, сохранение состояния сессий. Модель занимается рассуждением. Всё остальное делает обвязка (harness).
Это противоположно тому, как сегодня устроено большинство агентных фреймворков.

LangGraph пропускает ответы модели через явные конечные автоматы состояний. Devin накладывает тяжёлые планировщики поверх операционной инфраструктуры. Claude Code, наоборот, даёт модели максимум свободы в принятии решений внутри богатой детерминированной обвязки и направляет основные инженерные усилия именно на эту обвязку.

Основной цикл предельно простой: while (true). Вызов модели, запуск инструментов, повтор.
Но настоящая архитектура находится вокруг этого цикла:
- Система разрешений с 7 режимами работы и ML-классификатором. Пользователи всё равно одобряют 93% запросов, поэтому архитектура компенсирует это автоматизированными слоями защиты вместо добавления новых предупреждений.
- Пятиуровневый пайплайн сжатия контекста. Каждый следующий уровень запускается только если более дешёвый не справился: budget reduction, snip, microcompact, context collapse, auto-compact.
- Четыре механизма расширения, упорядоченные по стоимости контекста: hooks (нулевая стоимость), skills (низкая), plugins (средняя), MCP (высокая). Каждый решает свою задачу интеграции.
- Субагенты возвращают родительскому агенту только итоговое резюме. Полные логи их работы сохраняются в sidechain-файлах. Даже при таком подходе команда агентов расходует примерно в 7 раз больше токенов, чем обычная сессия.
- Функция Resume не восстанавливает разрешения, привязанные к сессии. Доверие устанавливается заново при каждой новой сессии. Именно так и задумано.

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

Статья: Dive into Claude Code (arXiv:2604.14228)

Также авторы выпустили отдельный материал про Agent Harness и то, что сегодня строят крупные компании в этой области.

👉 @DataSciencegx

Сегодня Google фактически превратил gist от Карпати про LLM-вики в официальный стандарт — Open Knowledge Format (OKF). По сути это markdown-файлы с одним обязательным полем.

Вопрос с форматом хранения знаний теперь во многом закрыт. Самая сложная часть осталась за рамками стандарта.

Что меняется:

- Портативность. База знаний может быть обычным tar-архивом или git-репозиторием. Её можно переносить между компаниями и инструментами без промежуточных конвертеров.
- Контроль версий. Знания хранятся рядом с кодом, который описывают. История изменений и диффы идут бесплатно вместе с git.
- Развязка инструментов. Человек создаёт и поддерживает базу знаний, агент её читает. Общий стек или специальные инструменты для этого не нужны.
- Никаких SDK и аккаунтов. Всё сводится к чтению и записи обычных markdown-файлов.

Что стандарт не решает:

- Разрешение противоречий. Новый источник может конфликтовать со старым. OKF сохранит оба факта, но не скажет, какой из них считать актуальным.
- Устаревание данных. Для даты есть отдельное поле, но решение о том, что факт больше не актуален, остаётся на вашей стороне.
- Политика слияния. В какую страницу попадёт новый факт, когда создавать отдельную ветку знаний, а когда обновлять существующую запись — ответственность агента или системы, которая пишет данные.
- Поиск. Для нескольких сотен страниц хватит index.md. Дальше понадобятся гибридный поиск, индексирование и reranker.

OKF стандартизировал картотеку. Библиотекаря всё ещё придётся строить самостоятельно.

https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing/

👉 @DataSciencegx

Stanford выпустил интересную работу, которая ставит под сомнение одну из базовых идей мультиагентных систем: а нужен ли вообще агент-менеджер, который раздаёт задачи всем остальным?

Обычно схема выглядит так:

- один агент получает задачу;
- дробит её на подзадачи;
- раздаёт работу;
- собирает результаты;
- склеивает финальный ответ.

Звучит логично, пока агентов и подзадач немного.

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

В статье предлагают DeLM (Decentralized Language Model).

Вместо центрального координатора используется общее проверяемое пространство контекста (shared verifiable context), к которому имеют доступ все агенты.

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

Самое интересное — другие агенты не используют новые данные автоматически. Записи должны пройти проверку, прежде чем попасть в общий контекст. Это помогает не разносить ошибки по всей системе.

По сути, авторы переносят узкое место с агента-супервизора на общий слой знаний.

Именно эта идея кажется самой ценной.

Большинство мультиагентных фреймворков сегодня много говорят про декомпозицию задач. Эта работа больше про инфраструктуру передачи знаний между агентами.

Возможно, главный вопрос уже не «как разбить задачу на части», а «как организовать обмен информацией так, чтобы он сам не стал ограничением».

👉 @DataSciencegx

Исследователи показали, что Claude Code на 98% состоит вовсе не из AI.

Anthropic никогда не раскрывала архитектуру Claude Code. Не было ни документации, ни технических разборов. Только инструмент, которым сейчас одержима половина индустрии.

Пока недавно не произошла утечка.

Команда исследователей проанализировала исходный код объёмом около 500 000 строк и обнаружила любопытную деталь:

Лишь 1,6% кодовой базы напрямую взаимодействует с моделью.

Ядро Claude Code — по сути обычный цикл: спросить модель, что делать дальше → вызвать инструмент → повторить.

Тогда что занимает остальные 98,4%?

Классическая инженерия.

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

Среди компонентов:

* 7 режимов системы разрешений, которые фильтруют действия агента.
* 5-уровневый пайплайн сжатия контекста, чтобы модель не забывала цель задачи.
* Механизм делегирования подагентам с жёсткой изоляцией рабочих деревьев.
* Четыре расширяемых слоя для безопасной интеграции внешних инструментов.

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

Подход Anthropic оказался другим.

Вместо того чтобы делать модель умнее, они построили вокруг неё массивную детерминированную инфраструктуру.

Похоже, главный вывод здесь такой: качество агентных систем всё чаще определяется не самой моделью, а тем, насколько хорошо организована среда вокруг неё.

https://arxiv.org/pdf/2604.14228

👉 @DataSciencegx

Если следишь за AI-агентами для научных исследований, самая сложная часть — не найти одну хорошую статью, а разобраться во всей экосистеме.

Awesome AI Auto-Research — это curated-репозиторий на GitHub для исследователей и разработчиков, которые изучают применение AI в научной работе.

Проект помогает ориентироваться в этой области, раскладывая статьи и инструменты по этапам исследовательского процесса: от генерации идей и обзора литературы до экспериментов, написания статьи, рецензирования и публикации результатов.

Что внутри:

• Карта жизненного цикла — auto-research разбит на 4 фазы и 8 этапов.
• Каталог статей — для каждого инструмента указаны статья, площадка публикации, сайт и GitHub-репозиторий.
• Этап создания исследований — идеи, поиск литературы, программирование, эксперименты, таблицы и визуализации.
• Этап проверки качества — peer review, ответы рецензентам, доработка работ, вопросы качества, предвзятости и регулирования.
• Раздел систем — отдельно выделены end-to-end системы, специализированные решения по доменам, самоулучшающиеся системы и инфраструктурные проекты.

Репозиторий распространяется по лицензии MIT и выглядит как неплохая отправная точка для тех, кто хочет понять весь пайплайн AI-assisted research, а не только отдельные модели или статьи.

https://github.com/worldbench/awesome-ai-auto-research

👉 @DataSciencegx

Attention — одна из ключевых идей, на которых держатся трансформеры и современные LLM.

Попробуем собрать её с нуля, по шагам.

Self-Attention

Self-attention помогает модели понять, как слова связаны друг с другом внутри предложения.
Модель не обрабатывает каждое слово отдельно. Каждый токен может “посмотреть” на другие токены и решить, какие из них сейчас важнее.

Возьмём предложение:

Every moment is a beginning.

Чтобы понять слово beginning, модель может сильнее обратить внимание на moment и Every.
Так появляется контекст: каждый момент может быть новым началом.

Query, Key, Value

Каждый токен создаёт три вектора:
Query (Q) — что я ищу?
Key (K) — какая информация во мне есть?
Value (V) — какую информацию я передам, если окажусь полезным?

Грубо говоря:
Query одного токена сравнивается с Key других токенов.
Чем лучше совпадение, тем больше внимания получает соответствующий Value.

Causal Self-Attention
В обычном self-attention токен может смотреть на все токены в последовательности.
Но языковые модели генерируют текст по одному токену. Значит, при предсказании следующего токена они не должны видеть будущее.

Например, если модель предсказывает:

Every moment is → a

она не должна заранее видеть слово beginning.

Для этого используется causal mask

Маска блокирует доступ к будущим токенам:
• токен 1 видит только себя
• токен 2 видит токены 1 и 2
• токен 3 видит токены 1, 2 и 3
• и так далее

Так модель предсказывает следующий токен только по прошлому и текущему контексту.
Без подглядывания вперёд.

👉 @DataSciencegx

Нашёл хороший репозиторий для тех, кто хочет руками собрать GPT-подобную LLM на PyTorch.
LLMs from scratch — 10 ноутбуков с пошаговыми объяснениями.

GitHub: https://github.com/analyticalrohit/llms-from-scratch

Внутри архитектуру LLM разбирают на простые части:
• токенизация
• embeddings
• attention
• transformer blocks
• обучение
• генерация текста

Подходит для новичков, потому что всё объясняется по шагам и сразу через код.
Хороший вариант, если хочется понять, как GPT-подобные модели работают под капотом, а не просто пользоваться готовыми API.

👉 @DataSciencegx

Рады отметить отличную модель от сообщества разработчиков: Qwen3.6-27B-MTP-pi-reasoning-GGUF.
Модель построена на базе Qwen3.6-27B и ориентирована на задачи автоматизированного программирования и отладки в локальных AI-агентах для разработки.

Если вы экспериментируете с локальными AI-ассистентами для написания кода, рекомендуем протестировать эту модель в своей среде и оценить её в реальных сценариях работы.

https://huggingface.co/bytkim/Qwen3.6-27B-MTP-pi-tune-GGUF

👉 @DataSciencegx

HarnessX: обвязка (harness), которая компилирует сама себя.

До сих пор все улучшения harness-систем делались вручную — разработчик сам вносил изменения в код.

Anthropic убирает этапы планирования из Claude Code, когда выходит более мощная модель. Manus за шесть месяцев пять раз перестраивал своего агента, каждый раз сокращая сложность.

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

Ключевая идея — рассматривать harness как объект первого класса, так же как сегодня рассматриваются веса модели.

Когда harness становится типизированным и редактируемым артефактом, его можно оптимизировать на основе собственных трассировок выполнения.

Авторы используют концепцию «операционного зеркала». Эволюция harness естественным образом отображается на обучение с подкреплением.

Harness выступает состоянием. Изменение — действием. Трассировка вместе с оценкой — обратной связью. Новая версия — обновлением.

Если посмотреть на это под таким углом, сразу появляются знакомые режимы отказа: reward hacking, catastrophic forgetting, недостаточное исследование пространства решений.

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

Поэтому изменения никогда не применяются вслепую. На каждом цикле система анализирует трассировки, планирует изменение, вносит правку, а затем проводит её критический разбор.

Новая версия принимается только в том случае, если проходит проверку и показывает лучшие результаты на задачах, которых раньше не видела.

Безопасность обеспечивается архитектурой. Harness собирается из типизированных компонентов, которые можно заменять независимо, не ломая остальную систему.

Именно это здесь означает слово «компилирует». Каждый кандидат на новую версию harness проходит проверку типов перед запуском.

Самый интересный результат: слабейшая модель получила наибольший прирост качества. Самая сильная изменилась минимально.

Эволюционирующий harness закрывает те пробелы, которые слабая модель не способна компенсировать самостоятельно. Веса модели остаются прежними. Умнее становится среда, в которой она работает.

Это следующий логичный этап развития agent harness engineering. Сначала мы оптимизировали веса моделей, затем контекст, затем вручную собранные harness-системы.

Harness оставался последним элементом, который всё ещё настраивался вручную.

Статья: HarnessX: A Composable, Adaptive, and Evolvable Agent Harness Foundry

👉 @DataSciencegx

От Jupyter Notebook → к production AI-системе.

Изучение API — это мост между ними.

Очень рекомендую этот бесплатный плейлист по backend-разработке для ML-инженеров.

https://www.youtube.com/playlist?list=PL_c9BZzLwBRIHUNeoywVJXViXGEsk6PDr

👉 @DataSciencegx

Может ли VLM видеть без vision encoder?

Мы обучили такую модель всего за $100, вдохновившись Gemma 4 12B.

Задержка на M3 Pro MacBook:

112 мс → 1,1 мс для обработки изображения
на 30% ниже сквозная задержка для пайплайна изображение + LLM

Архитектура предельно простая:
patchify изображения → линейная проекция с позиционными эмбеддингами → LLM

Подробности:
https://huggingface.co/spaces/HuggingFaceM4/encoder-free-vlm

👉 @DataSciencegx

Netflix открыл исходный код внутреннего инструмента под названием Headroom.

Если коротко: перед тем как отправить данные в LLM, он сжимает их и позволяет сократить расход токенов на 60–95%.

Самое интересное — сжатие не приводит к потере точности. Headroom использует обратимое (reversible) сжатие, поэтому данные можно восстановить в исходном виде бит в бит. Никакой потери информации, ни одного пропавшего символа.
Каждый, кто пишет код, наверняка сталкивался с этим: длинные логи, большие фрагменты текста из RAG, несколько файлов в контексте одновременно.

Всё это быстро съедает контекстное окно и увеличивает расход токенов при каждом запросе к модели.
Headroom создан именно для таких сценариев. Он уменьшает объём данных перед отправкой в модель, сохраняя возможность полностью восстановить исходное содержимое без каких-либо потерь.

Ещё несколько практичных моментов:

* В Headroom есть шесть алгоритмов сжатия, каждый рассчитан на свой тип данных. Для кода, логов и обычного текста используются разные методы.
* Поддерживаются популярные AI-инструменты для разработки: Claude Code, Codex, Cursor, Aider и Copilot CLI.
* Всё работает локально. Данные не покидают устройство. Проект распространяется по лицензии Apache 2.0 и подходит для коммерческого использования.

Интеграция тоже довольно простая. На выбор доступны три варианта:

* библиотека (library);
* агент (agent);
* MCP-сервер.

Особенно полезным Headroom выглядит для долгоживущих агентных сессий и крупных кодовых баз, где в контекст постоянно попадают большие объёмы данных. В таких сценариях экономия токенов может оказаться весьма заметной и существенно снизить расходы на использование моделей.

https://github.com/chopratejas/headroom

👉 @DataSciencegx

Если работаешь с Codex 5.5 и заметил, что качество ответов ушло в регрессию.. то лови несколько приёмов, которые помогают получать хорошие результаты почти в любом случае.

• Используй /goals для явной постановки целей и этапов работы.
• Подключай скилл Krypton. Многие разработчики называют его одним из самых полезных дополнений для Codex.
• Для планирования ставь уровень рассуждений XHigh, а для реализации — High. Обычно это даёт лучший баланс между качеством и скоростью.
• Активнее используй Computer Use и Browser Use. Эти инструменты позволяют Codex работать с интерфейсами, сайтами и реальными рабочими процессами значительно эффективнее.

Дополнительно:
• Попробуй ChatGPT Pro 5.6, который сейчас проходит скрытое тестирование у части пользователей.
• Подключи GitHub-репозиторий через веб-интерфейс.
• Используй Pro-модель для ревью кода, тестирования, проектирования и планирования задач.

Это самая мощная модель в мире.

Используйте её на полную.

👉 @DataSciencegx

RAG даёт LLM доступ к вашим данным. Agentic RAG добавляет способность принимать решения о том, что с этими данными делать.

Разница особенно заметна в ситуациях с неопределённостью.

Классический RAG работает по фиксированному пайплайну:

→ Кодирует запрос
→ Ищет похожие данные в векторной базе
→ Извлекает релевантные документы
→ Генерирует ответ

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

Agentic RAG добавляет слой рассуждений практически на каждом этапе:

→ Переформулирует запрос перед поиском
→ Оценивает, достаточно ли найденных данных
→ Выбирает источник информации (векторная БД, API, веб-поиск и т.д.)
→ Проверяет качество и релевантность ответа перед выдачей

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

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

Стандартный RAG не понимает, что сейчас может выдать плохой ответ.

Agentic RAG хотя бы способен задать себе этот вопрос.

#agenticai #rag #agenticrag #aiengineering

👉 @DataSciencegx

Для тех, кто тонет в потоке информации, есть Horizon — open-source система, похожая на радар, который тихо сканирует зарубежный техмир и приносит только то, что стоит внимания.

Он собирает новости и обсуждения из Hacker News, Twitter, Reddit и GitHub. Затем пропускает всё через AI: убирает шум, сводит дубли и оставляет выжимку в виде ежедневного отчёта.

Внутри всё устроено просто

AI оценивает каждую находку и отсеивает слабое ещё до того, как она попадёт в ленту.
Reddit и Hacker News разбираются отдельно, чтобы не смешивать поток и живые обсуждения.
Новые компании и инструменты получают краткий контекст — чтобы не выглядеть пустым названием в списке.
Один инфоповод фиксируется один раз, без повторов из разных источников.
Сводки идут на двух языках и могут уходить в Feishu, почту или WeChat.

Это система не про новости. Скорее про тишину среди новостей.

https://github.com/Thysrael/Horizon

👉 @DataSciencegx

Локальное AI-железо = ёмкость памяти × пропускная способность × софт-стек.

* Capacity — что вообще помещается в память
* Bandwidth — как быстро железо гоняет данные
* Software stack — сколько из заявленных характеристик реально превращается в скорость

Железо по пропускной способности памяти

* Mac Studio M3 Ultra: до 512GB @ 819 GB/s
* RTX PRO 6000 Blackwell: 96GB @ 1792 GB/s
* RTX 5090: 32GB @ 1792 GB/s
* RTX 4090: 24GB @ 1008 GB/s
* RX 7900 XTX: 24GB @ 960 GB/s
* Radeon PRO W7900: 48GB @ 864 GB/s
* AMD Radeon AI PRO R9700: 32GB @ 640 GB/s
* Intel Arc Pro B65: 32GB @ ~608 GB/s
* Tenstorrent Wormhole n300: 24GB @ 576 GB/s
* Tenstorrent Blackhole p150: 32GB @ 512 GB/s + 800G
* MacBook Pro M5 Max: 460–614 GB/s
* MacBook Pro M5 Pro: 307 GB/s
* DGX Spark: 128GB @ 273 GB/s (coherent + CUDA)
* Mac mini M4 Pro: 273 GB/s
* Ryzen AI Max / Strix Halo: ~256 GB/s (~96GB GPU)
* MacBook Air M5: 153 GB/s
* Snapdragon X2 Elite: 152–228 GB/s
* Intel Lunar Lake: 136 GB/s
* Snapdragon X Elite: 135 GB/s
* Mac mini M4: 120 GB/s
* Arc Pro B60: 24GB @ ~456 GB/s

Выводы:

* GPU всё ещё держат максимум по пропускной способности

* Apple выигрывает по объёму памяти в одном узле

* Apple проигрывает там, где важнее токены/сек и параллелизм

* DGX Spark — связка когерентной памяти и NVIDIA-стека

* Strix Halo / Ryzen AI Max — первый заметный x86 с unified memory

* Tenstorrent — полностью open-source стек, интересно куда дойдёт

Важный момент.Если модель “влезает” — это ещё ничего не значит.

Дальше начинают решать:

* пропускная способность на декоде
* рост KV-cache
* квантизация и её цена
* батчинг и конкуренция запросов
* качество планировщика
* накладные расходы фреймворков

Простая модель выбора

1. Что должно поместиться в память
2. Какой нужен уровень bandwidth
3. Какой стек реально даст нужную скорость

Итоговый вопрос всегда один:

что именно ты покупаешь — ёмкость или скорость.

https://x.com/TheAhmadOsman/status/2041331757329285589

👉 @DataSciencegx

Multi-agent RL красиво именно в тот момент, когда оно начинает сходиться.

👉 @DataSciencegx