Research Insights Made Simple

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

На эфире разберём препринт «Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents. A Source-Code Study of Eleven Systems». Авторы изучили исходники одиннадцати систем: от Claude Code, Codex CLI и Gemini CLI до Aider, OpenHands и mini-SWE-agent. Получился атлас того, что находится между моделью и рабочей средой.

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

Обсудим:

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

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

Агенты пишут всё больше кода, сотрудники собирают инструменты для управления ими, а доля джунов в техническом найме снижается. Anthropic выпустила исследование о том, как AI меняет работу внутри самой компании. И один из самых интересных вопросов здесь — что происходит с человеком, когда исполнение задач становится всё дешевле, а его внимание остаётся ограниченным.

В выпуске разберу "How employment is changing at Anthropic" и продолжу разговор, который мы начали в Developer Productivity for Humans: как понять, что рост активности помогает людям получать полезный результат?

Сначала посмотрим на саму статью:

А дальше вернусь к вопросам из моих пометок на полях. Как устроить рабочий цикл, чтобы не проверять вручную каждый шаг агента? Где будущий самостоятельный инженер получит опыт, если простые задачи уже автоматизированы? И на каких условиях сотруднику выгодно автоматизировать собственную работу — что он получает взамен и есть ли для него следующая роль?

Это исследование одной быстро растущей компании, которая сама создаёт AI. Его данные интересны именно в деталях; переносить их на весь рынок труда будем осторожно.

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

Предыдущие разговоры:

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

15 октября 2026 года в сольном выпуске Research Insights Made Simple #39 разберу «Redesigning source control at Anthropic». Это инженерный отчёт команды о том, как меняется работа с кодом, когда основными клиентами репозитория становятся постоянно подключённые агенты и CI.

Меня здесь особенно интересуют две вещи: знакомые идеи баз данных в устройстве Scion и изменение гарантий вокруг merge. Что мы выигрываем, если быстрее принимаем изменения в общую историю? И что после этого обязаны проверить до деплоя?

В выпуске:

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

Автор и ведущий — Александр Поломодов.

Timeline
00:00 - Зачем Anthropic своя система контроля версий
03:40 - Рост нагрузки от агентов и CI
04:34 - Онлайн-клиенты и серверные операции
07:10 - Запрос API вместо скачивания репозитория
08:52 - Changeset, Spanner и производные данные
12:37 - Ссылки и кеши неизменяемых объектов
15:26 - Что означает мгновенная доступность
17:34 - Как читать график ускорений
18:21 - Миграция, люди и архитектурные ограничения
20:25 - Ревью намерений и роль инженеров
21:49 - Агенты для наблюдения за компонентами
23:00 - Проверки после слияния и до развёртывания
25:51 - Конфликты поведения и открытые вопросы
27:07 - Границы применимости Scion
30:20 - Что остаётся узнать о полном цикле разработки

В очередном эпизоде из серии об обвязках агентов Research Insights Made Simple поговорим про опубликованное в сентябре 2026 года исследование "An Empirical Study of Harness Design for Coding Agents" (https://arxiv.org/abs/2609.20804v1). Авторы фиксируют цикл агента и меняют три компонента: планирование, инструменты и управление контекстом. Они сравнивают 176 экспериментальных настроек на четырёх моделях и двух наборах задач — SWE-bench Verified и Terminal-Bench 2.1.

Обсудим

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

Все выпуски Research Insights Made Simple: https://polomodov.tech/research-insights

Timeline
00:00 - Зачем разбирать обвязку на компоненты
02:07 - Общий цикл и три переменные эксперимента
03:19 - 176 настроек и неполный перебор сочетаний
04:40 - Модели, задачи и расчёт стоимости
07:52 - План вне истории разговора
09:47 - Готовые инструменты и bash
11:33 - Пять политик управления контекстом
13:51 - Что сохраняют и когда сокращают историю
15:43 - Предотвращённый обрыв и стоимость контекста
19:03 - Почему редко возвращают вытеснённые события
20:55 - План меняет момент остановки
24:27 - Инструменты: результат зависит от модели и задач
29:21 - Менять компоненты по одному
33:24 - Анализ траекторий и причины сбоев
40:09 - Выводы, ограничения бенчмарка и свои эксперименты

12 октября в Research Insights Made Simple снова встречаемся с Колей Головым и продолжаем разговор про платформы данных. В этот раз разберём, как объединить операционные базы, аналитику и AI-агентов и можно ли при этом избавиться от привычного зоопарка интеграций.

Николай Голов - директор по продукту одной из датаплатформ, доступных на российском рынке. Раньше он руководил дата-платформами в Avito и ManyChat, преподаёт базы данных и системы хранения в Harbour.Space (https://harbour.space/faculty/Nikolay-Golov). Так что обсудим и устройство технологий, и практику построения платформ, которые потом кому-то поддерживать.

На картинке всё выглядит заманчиво: оставляем PostgreSQL для транзакций, изменения из остальных систем отправляем через CDC в объектное хранилище, сверху ставим Lakehouse и подключаем агентов через MCP. Данные собраны, инструменты доступны, можно задавать вопросы. Правда, между «сложили всё в S3» и «агент правильно понял бизнес» ещё помещается довольно много инженерной работы :)

Посмотрим, как к этой задаче подходят Databricks, Snowflake, ClickHouse, Microsoft Fabric, Google, AWS и Oracle. У кого-то объединение происходит на уровне хранения, у кого-то через репликацию и общие запросы, а кто-то собирает всё внутри одной СУБД. За похожими словами про единую платформу скрываются разные архитектуры и разные ограничения.

Поговорим о том

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

Timeline
00:00 - Данные организации для AI-агента
02:47 - Четыре подхода вместо одного правильного решения
05:16 - Классическое хранилище и подготовленные витрины
08:45 - CDC, ETL и размер компании
11:15 - Федеративные запросы: Presto и Trino
16:17 - Универсальная СУБД и ограничения HTAP
18:23 - Единый слой хранения и текущее состояние таблиц
26:09 - Microsoft и AWS: передача изменений
34:51 - ClickHouse: федеративный доступ и репликация
40:04 - Google: операционные базы, BigQuery и стоимость
47:34 - Oracle и SAP HANA: нагрузки внутри одной СУБД
53:56 - Databricks: Neon, Mooncake и общий слой
1:00:17 - Snowflake и PostgreSQL
1:02:25 - Сравнение подходов и пределы общего хранения
1:07:42 - Собственная платформа и открытые форматы

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

Продолжаем серию про инженерную обвязку агентов. И здесь мы разберём статью Anthropic Harness design for long-running application development. Её автор экспериментирует с разделением планирования, разработки и оценки результата.

В прямом эфире обсудим:
- Как устроены роли planner, generator и evaluator.
- Зачем до написания кода согласовывать критерии готовности и как проверять работающее приложение.
- Можно ли формализовать вкус при оценке дизайна и насколько надёжен отдельный агент-критик.
- Сколько стоят дополнительные итерации и что показывают приведённые сравнения.
- Почему с усилением моделей некоторые части обвязки становятся лишними.

А в конце поговорим о следующем шаге: сможет ли агент сам улучшать собственный harness — и кто тогда будет проверять эти улучшения?

Timeline
00:00 - Четвёртый разбор обвязок: приложения по одному запросу
01:33 - Две задачи Anthropic Labs
03:04 - Идея из GAN: отдельный критик
06:22 - Предел контекста и снисходительная самооценка
08:10 - Сжатие, сброс и стоимость передачи работы
12:40 - Четыре критерия качества дизайна
15:00 - Итерации фронтенда и выбор варианта
17:16 - Планировщик, генератор и оценщик
18:39 - Контракт спринта до реализации
20:32 - Ретро-игры: двадцать минут против шести часов
23:40 - Почему проверяющему нужна настройка
25:43 - Opus 4.6: проверка и упрощение компонентов
30:46 - Звуковая станция и оценщик, который не слышит
34:41 - Автономность и внешний контроль риска
38:56 - Журнал событий и дальнейшая эволюция обвязки

В четверг, 8 октября, в прямом эфире разберу статью OpenAI «Harness engineering: leveraging Codex in an agent-first world» ( https://openai.com/index/harness-engineering/ )

В предыдущем выпуске (https://www.youtube.com/watch?v=qVXELX0j6dY) говорили о передаче работы между сессиями агента. Теперь посмотрим на всю среду разработки: как устроить репозиторий, знания, инструменты и проверки, чтобы агент мог самостоятельно двигать проект вперёд.

Обсудим:

Статья описывает опыт одной команды. Отдельно поговорим о границах её выводов и о том, какие данные нужны для оценки результата.

Timeline
00:00 - От интерфейса агента к среде разработки
01:41 - Запрет писать код руками как метод
04:25 - Пять месяцев, команда и результаты кейса
06:43 - Сбой агента требует изменения среды
07:56 - Внимание инженеров, DevTools и рабочие деревья Git
10:54 - Наблюдаемость превращает пожелания в проверки
12:04 - Недоступные знания и параллель с новичком
14:45 - AGENTS.md как карта к документам
17:14 - Явная архитектура и линтеры с инструкциями
20:42 - Инварианты на границах и свобода реализации
24:00 - От бага до слияния: автономия и цена ошибки
27:13 - Фоновая очистка вместо пятничного разбора долга
29:53 - Каких доказательств и измерений нет в статье
32:10 - Как проверить механизм на своих задачах
38:58 - Symphony: от управления сессиями к задачам

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

После SWE-agent продолжим серию про обвязки агентов. Разберём статью Anthropic (https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents) о работе через несколько сессий:
- почему сжатия контекста недостаточно;
- зачем нужны список функций, журнал прогресса и история Git;
- как делать небольшие проверяемые шаги;
- что оставлять следующей сессии, чтобы она могла продолжить начатое.

Будет полезно тем, кто строит кодинговых агентов и поручает им задачи, выходящие за одно контекстное окно.

Timeline
00:00 - Зачем передавать работу между сессиями
01:51 - Инженерный опыт Anthropic и проверенная основа
05:09 - Инициализатор и агент-разработчик
07:09 - Почему сжатия контекста недостаточно
09:17 - Много недоделок и преждевременная готовность
14:04 - За что отвечают четыре артефакта
16:22 - Функция как пользовательский сценарий
18:48 - JSON, Markdown и границы запрета в промпте
19:36 - Ориентирование и одна функция за шаг
21:59 - Проверка в браузере и невидимые alert
24:19 - Git и содержательная запись прогресса
28:59 - Что доказано и как проверить обвязку
32:13 - Полный цикл рабочей сессии
33:42 - Как продолжение истории меняет обвязку
38:15 - Как читать статьи с заметками и обсуждать их с LLM

5 октября в 12:00 МСК — прямой эфир Research Insights Made Simple. Сольный выпуск с Александром Поломодовым: разбираем статью «SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering» с NeurIPS 2024.

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

В программе

Timeline
00:00 - Зачем возвращаться к SWE-agent 2024 года
01:05 - SWE-bench: реальные задачи в чужом проекте
03:00 - Зачем модели собственный интерфейс
04:45 - Цикл мысли, действия и наблюдения
06:32 - Как проверяли решения и ограничивали бюджет
08:49 - Результаты на полном SWE-bench
10:01 - Демонстрации и сравнение с обычным shell
10:55 - Поиск файлов и нужных мест в коде
14:30 - Просмотр с номерами строк и команда edit
17:20 - Отклонение правки и обратная связь линтера
20:37 - Абляции: что дают редактирование и проверки
22:19 - Окно просмотра и управление историей
24:54 - Траектории, повторные попытки и пределы модели
29:18 - Как авторы улучшали интерфейс экспериментами
31:47 - Принципы ACI, SWE-smith и mini-SWE-agent

Модель поместилась в GPU, тестовый запрос отработал быстро. Что произойдёт, когда одновременно придут сотни запросов с разной длиной контекста и ответа?

23 сентября 2026 года в эфире Research Insights Made Simple #32 разберу whitepaper 2023 года про vLLM и устройство инференса LLM: как управление памятью, планирование запросов и передача состояния между узлами влияют на скорость сервиса.

Начнём с KV-кеша — ключей и значений уже обработанных токенов, которые модель сохраняет для следующих шагов генерации. Посмотрим, как PagedAttention применяет идеи виртуальной памяти к этому кешу и позволяет эффективнее размещать активные запросы на GPU. А дальше разберём, какие задачи приходится решать вокруг движка.

Выпуск для инженеров, архитекторов и платформенных команд, которые разворачивают LLM, выбирают движок инференса или хотят понять, что происходит за API модели.

Исследование PagedAttention, SOSP 2023:
https://arxiv.org/abs/2309.06180

Все выпуски Research Insights Made Simple:
https://polomodov.tech/research-insights/

Timeline
00:00 - Почему возвращаемся к статье 2023 года
03:26 - Обработка промпта и генерация токенов
06:09 - Бюджет памяти и цена KV-кеша
11:10 - Резерв и два вида фрагментации
13:36 - Почему даже знание длины ответа не спасает Orca
15:58 - Страничная память: идея из операционных систем
19:42 - PagedAttention и косвенный доступ к блокам
23:36 - Как растущий запрос получает новые блоки
26:11 - Общий префикс и копирование при записи
29:44 - Дерево блоков для beam search
32:21 - Вытеснение: перенос или повторное вычисление
36:01 - Планировщик и рабочие процессы GPU
38:05 - Пропускная способность при той же задержке
39:17 - Цена косвенности и выбор размера блока
41:37 - Инженерные выводы и границы применимости