ScienceNatural SciencesTechnologyBusinessManagement

Research Insights Made Simple

Alexander Polomodov

Подкаст от Александра Поломодова, технического директора и Fellow, с обсуждением научных статей из области computer science и engineering. Каждый эпизод подкаста посвящен одной статье и в каждом эпизоде есть приглашенный гость-эксперт, который собаку съел в этой теме. Обычно эпизод длится час-полтора и может сопровождаться схемами из статьи или быть чисто в разговорном жанре.

Play

Open in

35 episodes
Avg 1 hr 2 min
Russian

Episodes 35

Newest Oldest Longest

All20 Unplayed20 In progress0 Played0

Counted on this page — what you have heard stays on this device, so it is not something the list can be paged by.

#44
Monday · 57 min
Случайность в оценках агентов: улучшение или шум?
Агент стал решать на два процентных пункта больше задач после изменения промпта или обвязки. Это настоящее улучшение — или просто удачный прогон? 2 ноября в 10:00 МСК в Research Insights Made Simple разберём исследование "On Randomness in Agentic Evals". Его авторы повторили одинаковые запуски агентов на SWE-bench Verified и изучили, насколько результаты зависят от случайности. Поговорим о том: почему результаты неизменного агента могут заметно различаться от прогона к прогону; помогает ли нулевая температура добиться повторяемости; чем отличаются pass@1, pass@k и pass^k; сколько прогонов может понадобиться, чтобы заметить улучшение; как учитывать разброс при сравнении моделей, промптов и обвязок. Исследование рассматривает конкретные модели и задачи, поэтому отдельно обсудим, какие выводы можно перенести на собственные оценки агента.
#43
October 22 · 1 hr 31 min
Agent Skills и Open Knowledge Format (OKF): скиллы, знания и доверие
Агент умеет писать код и вызывать инструменты. Но как передать ему рабочую процедуру команды? Где хранить знания о системе, которые меняются независимо от этой процедуры? И чем подтвердить, что агент выполнил задачу правильно? 22 октября в 43 выпуске подкаста Research Insights Made Simple проведу прямой эфир с Максимом Смирновым, с которым мы летом обсуждали Loop Engineering https://www.youtube.com/watch?v=hnFLfiJOtQE о том, как проектировать циклы, которые запускают агентов, проверяют результат и возвращают работу на доработку. Теперь продолжим разговор — через Agent Skills и Open Knowledge Format (OKF). Максим — ИТ-архитектор, автор Telegram-канала «Архитектура ИТ-решений» https://t.me/it_arch. В прошлом — руководитель департамента ИТ-архитектуры «Билайн» и главный архитектор информационных систем Банка России; спикер, автор и преподаватель курсов по ИТ-архитектуре. В новом выпуске мы разберём, из чего состоит навык: SKILL.md, описание, инструкции, вспомогательные файлы и скрипты. Посмотрим, как агент выбирает подходящий навык, когда подгружает подробности и почему успешная загрузка файла ещё не означает успешного выполнения задачи. В программе: Чем отличаются инструкции проекта в AGENTS.md, навыки, инструменты MCP и обработчики событий. Как проверять не только результат навыка, но и то, вызывается ли он в нужной ситуации. Что появилось вокруг Agent Skills: каталоги, установка, автоматические проверки и оценка качества. Как OKF связывает Markdown-файлы в граф знаний и описывает происхождение и актуальность сведений. Почему отметка времени или подтверждение в метаданных сами по себе не гарантируют истинность. Что означает квитанция выполнения вычисления, кто её проверяет и где остаётся ответственность команды. Сквозной пример — утренний разбор упавшего CI: какие инструкции нужны агенту, откуда он узнаёт правила проекта и как мы проверяем предложенное исправление. Сопоставим Agent Skills, OKF v0.2 и предложение Knowledge-as-Skill. Опираемся на спецификации, документацию и примеры по состоянию на конец октября 2026 года. Отделим свойства форматов от возможностей конкретных реализаций. Приходите с кейсами: какие процедуры вы уже передаёте агентам и какие знания они регулярно теряют?
#42
October 21 · 1 hr 8 min
Оценки агентов: как понять, что агент справился
Агент написал «готово». Но изменился ли нужный файл, появилась ли бронь в базе и выполнены ли условия задачи? Красивый ответ ещё не означает, что работа сделана. А низкий балл иногда говорит о сломанной проверке, а не о слабом агенте. В этом выпуске разбираем руководство Anthropic «Demystifying evals for AI agents» и продолжаем серию об обвязках агентов. После разговора об их устройстве переходим к вопросу: как доказать, что система работает и очередная правка действительно её улучшила? Обсудим: Чем итог работы отличается от траектории: что агент оставил в среде и как к этому пришёл. Почему оценивается модель вместе с обвязкой, инструментами и настройками среды. Как устроены набор задач, отдельная задача и повторные попытки — и почему у процентов успеха бывают разные знаменатели. Когда подходят программные проверки, модельные судьи и оценка человека; как проверять самих проверяющих. Чем pass@k отличается от pass^k: хотя бы один успех и стабильный успех во всех попытках отвечают на разные вопросы. Зачем изолировать прогоны, читать траектории и превращать реальные сбои в тестовые задачи. Отдельно поговорим о доверии к оценкам: как отличить регрессию от случайного разброса, заметить неверные критерии и не принять рост балла за улучшение продукта. В эпилоге обратимся к более поздним материалам Anthropic — Petri v2, измерению автономности агентов и разбору апрельских регрессий. Это практическое руководство, основанное на опыте команды и клиентов Anthropic. Разделим рекомендации авторов, результаты отдельных работ и наши выводы для разработки собственных агентов. Эфир для разработчиков, технических руководителей и всех, кто хочет проверять AI-агентов на реальных задачах. Приходите с примерами: что в вашей системе считается доказательством успеха?
#41
October 20 · 1 hr 7 min
Анатомия агента: семь обязанностей обвязки
Почему одной языковой модели недостаточно, чтобы получить работающего агента для разработки? Кто решает, какие инструменты ему доступны, что попадёт в контекст, когда спросить разрешение и как продолжить работу после сбоя? На эфире разберём препринт «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-инструментов разработки. Приходите с вопросами и примерами из практики.
#40
October 19 · 58 min
Anthropic: что остаётся человеку в компании агентов
Агенты пишут всё больше кода, сотрудники собирают инструменты для управления ими, а доля джунов в техническом найме снижается. Anthropic выпустила исследование о том, как AI меняет работу внутри самой компании. И один из самых интересных вопросов здесь — что происходит с человеком, когда исполнение задач становится всё дешевле, а его внимание остаётся ограниченным. В выпуске разберу "How employment is changing at Anthropic" и продолжу разговор, который мы начали в Developer Productivity for Humans: как понять, что рост активности помогает людям получать полезный результат? Сначала посмотрим на саму статью: что авторы узнали о найме, продуктивности, рабочих процессах и изменении ролей; как устроено исследование: внутренние данные, интервью и сравнение сотрудников до и после внедрения агентов; что показывают графики агентских часов, объёма кода и качества — и какие выводы из них делать рано; почему возникает всё больше работы по организации работы агентов и куда уходит человеческое внимание. А дальше вернусь к вопросам из моих пометок на полях. Как устроить рабочий цикл, чтобы не проверять вручную каждый шаг агента? Где будущий самостоятельный инженер получит опыт, если простые задачи уже автоматизированы? И на каких условиях сотруднику выгодно автоматизировать собственную работу — что он получает взамен и есть ли для него следующая роль? Это исследование одной быстро растущей компании, которая сама создаёт AI. Его данные интересны именно в деталях; переносить их на весь рынок труда будем осторожно. Приходите с вопросами и примерами из своих команд. Особенно интересно, какая работа появилась у вас после внедрения агентов, хотя её не было в первоначальном обещании «сэкономить время». Предыдущие разговоры: Developer Productivity for Humans — выпуск #30 AI-native компания — что это значит на практике Джун без простых задач — как входить в IT в эпоху AI
#39
October 15 · 32 min
Scion - замена git внутри Anthropic для агентной разработки
Агенты пишут код, а инфраструктура разработки начинает захлёбываться. В Anthropic дошли до собственной системы контроля версий — Scion. И агенты же помогли её построить. 15 октября 2026 года в сольном выпуске Research Insights Made Simple #39 разберу «Redesigning source control at Anthropic». Это инженерный отчёт команды о том, как меняется работа с кодом, когда основными клиентами репозитория становятся постоянно подключённые агенты и CI. Меня здесь особенно интересуют две вещи: знакомые идеи баз данных в устройстве Scion и изменение гарантий вокруг merge. Что мы выигрываем, если быстрее принимаем изменения в общую историю? И что после этого обязаны проверить до деплоя? В выпуске: почему Anthropic перенесла операции с историей, merge и rebase на сервер; как устроены журнал изменений, производные структуры чтения и кеширование неизменяемых объектов; что именно ускорилось на итоговом графике и почему эти числа нельзя переносить на всю разработку; какие гарантии меняются при переходе к post-merge проверкам и как связать допуск к релизу с конкретным проверенным артефактом; как дать агенту стабильную базу и при этом раньше замечать конфликты с движущимся main. Разбор для инженеров, архитекторов и платформенных команд, которые внедряют кодинговых агентов и хотят понять, что придётся менять вокруг них. Автор и ведущий — Александр Поломодов. Статья Anthropic: https://www.anthropic.com/engineering/redesigning-source-control Все выпуски Research Insights Made Simple: https://polomodov.tech/research-insights/ 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 - Что остаётся узнать о полном цикле разработки
#38
October 13 · 46 min
Проектирование обвязки для кодинговых агентов: что даёт обвязка
В очередном эпизоде из серии об обвязках агентов 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. Обсудим Когда управление контекстом спасает задачу от переполнения окна. Почему сокращение старых ответов инструментов перед пересказом может снизить стоимость. Как план помогает слабой модели продолжать работу, а сильной — вовремя остановиться. Когда нужны готовые инструменты, а когда достаточно bash. Как по траектории агента найти причину сбоя и проверить пользу изменения на своих задачах. Выводы относятся к моделям, задачам и реализациям из исследования. Разберём, что стоит проверить перед переносом этих результатов в собственную систему. Все выпуски 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 - Выводы, ограничения бенчмарка и свои эксперименты
#37
October 12 · 1 hr 12 min
AI и платформа данных / Как подключить AI ко всей совокупности данных организации
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. У кого-то объединение происходит на уровне хранения, у кого-то через репликацию и общие запросы, а кто-то собирает всё внутри одной СУБД. За похожими словами про единую платформу скрываются разные архитектуры и разные ограничения. Поговорим о том Где проходят границы между OLTP, аналитикой и агентным бэкендом; Что на практике означают «одна копия данных» и zero-ETL; Когда CDC и Lakehouse упрощают жизнь, а когда добавляют ещё одну систему, за которой надо следить; Какую роль могут играть PostgreSQL, DuckLake и S3 в собственной платформе; Что нужно агенту помимо доступа к таблицам: определения показателей, права, контекст и возможность проверить результат. Хочется понять, какую сложность эти подходы действительно убирают и какая просто переезжает в другое место. Выпуск будет полезен архитекторам, инженерам данных и руководителям, которые выбирают платформу или подключают 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 - Собственная платформа и открытые форматы
#36
October 9 · 41 min
Проектирование обвязки для длительной (автономной) разработки приложений
Как организовать работу кодингового агента, чтобы он мог несколько часов создавать приложение, проверять результат и исправлять ошибки? Продолжаем серию про инженерную обвязку агентов. И здесь мы разберём статью 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 - Журнал событий и дальнейшая эволюция обвязки
#35
October 8 · 42 min
Инженерия обвязки: среда для агентов
В четверг, 8 октября, в прямом эфире разберу статью OpenAI «Harness engineering: leveraging Codex in an agent-first world» ( https://openai.com/index/harness-engineering/ ) В предыдущем выпуске (https://www.youtube.com/watch?v=qVXELX0j6dY) говорили о передаче работы между сессиями агента. Теперь посмотрим на всю среду разработки: как устроить репозиторий, знания, инструменты и проверки, чтобы агент мог самостоятельно двигать проект вперёд. Обсудим: Как меняется работа инженера, когда код пишет агент. Зачем агенту видеть приложение, логи и результаты проверок. Как сохранять архитектурные ограничения и качество кода. Что можно перенести из опыта OpenAI в свою команду и как проверить пользу этих изменений. Статья описывает опыт одной команды. Отдельно поговорим о границах её выводов и о том, какие данные нужны для оценки результата. 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: от управления сессиями к задачам
#34
October 7 · 41 min
Долгоживущие агенты: передача работы
Агент написал часть приложения, контекст закончился — и следующая сессия начинает разбираться заново. Код сохранился, но замысел, незавершённые изменения и результаты проверок остались в прошлой беседе. После 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
#33
October 5 · 40 min
SWE-agent или как интерфейс меняет результат
5 октября в 12:00 МСК — прямой эфир Research Insights Made Simple. Сольный выпуск с Александром Поломодовым: разбираем статью «SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering» с NeurIPS 2024. Что меняется, если дать той же языковой модели более удобный интерфейс для работы с репозиторием? Вместо разговора только о моделях и промптах посмотрим на действия агента и обратную связь, которую он получает. В программе Поиск по коду и чтение файлов: как агент находит нужное и сохраняет ориентиры. Многострочные правки и проверка синтаксиса: как предотвращать ошибки и восстанавливаться после них. Управление контекстом: что показывать модели, что сокращать и что сохранять. Результаты SWE-bench и SWE-bench Lite: с чем сравнивают SWE-agent и что показывают абляции. Выводы для современных агентов: какие принципы стоит перенести в свою систему, а какие настройки остались частью эксперимента 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
#32
September 28 · 46 min
vLLM и PagedAttention / виртуальная память для инференса LLM
Модель поместилась в 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 - Инженерные выводы и границы применимости
#31
September 23 · 1 hr 27 min
AI4SDLC / что бы я делал по-другому
В этом выпуске разберу, как провести границу владения AI-стеком и связать модель, агентную обвязку, инструменты, контекст и проверки результата в работающую систему. Поговорим о том: Когда использовать готовый цикл агента и где оправдана собственная обвязка; Почему способности модели, полномочия агента и выполненная задача — три разных вещи; Какие проблемы можно исправить маршрутизацией, контекстом и контрактами инструментов, а какие требуют изменений модели или инфраструктуры; Чем телеметрия отличается от evals и данных для обучения; Как сохранить эпизод, воспроизвести его, изменить один слой и проверить результат повторным прогоном; Когда повторяемую задачу можно передать меньшей модели и при каких условиях возвращать её большой. Выпуск для инженеров, архитекторов, руководителей разработки и платформенных команд, которые выбирают или строят AI-инструменты для SDLC. Слайды доклада на Deep Tech Night: https://polomodov.tech/2026-09-05-deep-tech-night-ai-development-stack-codesign/ Все выпуски Research Insights Made Simple: https://polomodov.tech/research-insights/ Напишите в комментариях, какую часть AI-стека вы уже делаете сами и почему. Это как раз те решения, на которых хочется проверить предложенную рамку. Timeline 00:00 - Зачем понадобилась режиссёрская версия 02:42 - Что арендовать, дорабатывать и чем владеть 14:15 - Маршрутизация, контекст и внутренние адаптеры 18:15 - Полномочия агента и границы делегирования 22:39 - Трассировка, проверки качества и переносимость 26:04 - Почему модель — только часть системы 33:10 - Как начать собирать проверочные случаи 39:20 - Быстрый и медленный циклы улучшений 45:58 - Как проверить полезность контекста 48:37 - Разные способы связать слои AI-стека 1:02:27 - Инструменты: MCP, ошибки и конечное состояние 1:06:40 - Почему демонстраций и телеметрии недостаточно 1:13:28 - Каталог проверяемых инженерных эпизодов 1:19:30 - Меньшие модели и разделение планирования и исполнения 1:21:50 - Что стоило изменить во внедрении и безопасности
#30
September 22 · 1 hr 37 min
Продуктивность разработки / человеческий взгляд Google
Представим, что сборки стали быстрее, AI помогает писать код, а графики активности растут. Как понять, что команде стало легче достигать полезного результата? Кто тратит время на проверку, объяснение и сопровождение того, что удалось быстрее создать? В Research Insights Made Simple #30 соберу исследования и мои разборы серии в общую картину: от целей инженера и методов измерения до качества, совместной работы и последствий использования AI. Посмотрим, как скорость, удобство работы и качество результата связаны между собой и какие вопросы стоит задавать перед выбором метрик. В выпуске: Цели разработчиков: что именно человек пытается сделать и где заканчивается задача; Измерения: как сопоставлять логи, опросы и наблюдения и что делать, когда они дают разную картину; Рабочая среда: ожидание сборок, предсказуемость, сосредоточенность и переключения; Адаптация новичков: как учитывать обучение, самостоятельность и время наставника; Качество и технический долг: процесс, код, система, продукт и цена будущих изменений; Командная работа: помощь коллегам, передача контекста и перенос нагрузки между командами; AI-инструменты: потребности разработчика, доверие, проверка результата и сохранение возможностей учиться. В конце предложу практический план первого месяца для вашей команды: выбрать одну инженерную цель, собрать исходную картину, попробовать одно ограниченное изменение и вместе с командой оценить последствия. Это отправная точка для вашей программы улучшений. Выпуск для руководителей разработки, тимлидов, платформенных команд и инженеров, которые хотят понять, какие изменения действительно помогают в работе. Timeline 00:00 - Почему активность не равна результату 07:56 - Скорость, простота и качество 13:50 - Цели инженеров вместо отдельных инструментов 21:16 - Опросы, интервью и эксперименты 25:18 - Какая метрика помогает принимать решения 29:24 - Сборки: ожидание, предсказуемость и адаптация 36:55 - Сосредоточенность, гибридная работа и новички 43:12 - Четыре уровня качества и роль архитектуры 56:38 - Что изменится, если технический долг исчезнет 1:03:56 - Командная работа и цена локального ускорения 1:08:26 - Творчество и переиспользование решений 1:13:43 - Какую помощь инженеры хотят от ИИ 1:16:52 - Место человека в агентном процессе 1:19:14 - Четыре противоречия ИИ и долг понимания 1:27:36 - Первый месяц улучшений и доверие команды
#29
August 27 · 1 hr 6 min
AI-native SDLC / код ускорился, а поставка — нет
Кодинговые агенты уже пишут код гораздо быстрее. Но если планирование, архитектурное ревью, безопасность, тестирование и деплой остаются на «человеческой скорости», ускоряется ли delivery — или очередь просто переезжает в соседний этап? 27 августа в 14:00 в прямом эфире Research Insights Made Simple вместе с Антоном Костериным, principal engineer RnD-центра Т-Банка, разбирали свежий материал Anthropic — "The AI-Native SDLC playbook" (https://claude.com/blog/the-ai-native-sdlc-playbook) С Антоном мы уже говорили об architecture governance, RFC/ADR и архитектурных ревью (https://youtu.be/CEii3K0hAUw). Теперь вопрос шире: как перестроить под агентов не только написание кода, но весь SDLC. Тезис playbook: после ускорения Build bottleneck смещается в Plan, Test/Review и Deploy. Anthropic предлагает замкнуть шесть стадий, от Plan до Maintain, в цикл. intent.md, spec.md, plan.md, diff с тестами, результаты review и записи об инцидентах образуют цепочку версионируемых артефактов и одновременно audit trail. Человек остаётся ответственным, но подключается в точках, где действительно требуется суждение. Обсудим: Действительно ли код перестал быть узким местом и где теперь скапливается очередь; Зачем нужны markdown-артефакты, если уже есть Jira, wiki и архитектурные процессы; Как превратить знания компании в CLAUDE.md, skills и проверяемые политики, не законсервировав ошибки; Как связать continuous evals, hooks, агентное и человеческое review с production monitoring; С какого участка SDLC начинать и какими метриками доказывать эффект. Это практическое руководство команды Claude, а не исследование со сравнительным экспериментом. Поэтому отдельно проверим, где здесь переносимый инженерный подход, а где пока видение поставщика — особенно для большой регулируемой организации. Timeline 00:00 - Антон Костерин: как устроен AI-native SDLC 03:59 - Чем полезен playbook и почему знакомые практики снова актуальны 08:22 - Планирование: превращаем идею в intent.md 13:26 - Проектирование: spec.md и ограничения организации 16:57 - Skills как способ задать правила работы агента 20:04 - Разработка начинается с проверенного человеком plan.md 24:22 - CLAUDE.md, hooks, команды и агенты в рабочем цикле 29:21 - Первоначальные вложения, доверие и принятие нового процесса 35:35 - Тестирование: детерминированные проверки в CI/CD 38:20 - Непрерывные evals для проверки работы агентов 40:54 - Развёртывание: знакомые механики и практический рецепт 44:54 - Проверка кода как новое узкое место 48:23 - Эксплуатация: инцидент запускает новый цикл разработки 53:37 - От инструкций по восстановлению к самостоятельной работе агента 1:03:44 - Как применять playbook на практике #AI4SDLC #AI #Agents #Engineering #Architecture #DevOps #Research
#28
August 24 · 1 hr 37 min
Дата-платформа в 2026 году / от DWH к Lakehouse и AI-агентам
В шестом выпуске (https://t.me/book_cube/2874) Research Insights Made Simple мы с Николаем Головым разбирали, как строить дата-платформы в 2025 году. В 28 выпуске мы возвращаемся к теме с вопросом посложнее: что происходит, когда аккуратная схема из storage, compute, catalog и orchestration встречается с legacy, стоимостью миграции и реальными аналитическими запросами? В гостях Николай Голов (https://harbour.space/faculty/Nikolay-Golov) и Александр Филатов. Николай — директор по продукту Tengri Data, в прошлом руководитель дата-платформ в Avito и ManyChat и преподаватель Harbour.Space. Александр пришёл в DWH из backend-разработки: до этого писал инструменты обработки данных на Python и C++. Почти десять лет он развивал хранилище данных Авито, в 2022–2025 годах занимался переходом с Vertica на Trino/Iceberg/S3, а теперь возглавляет разработку Tengri Data. Поговорим о том: - Где проходит граница между OLTP и OLAP, почему аналитика на реплике быстро упирается в потолок и отчего «давайте просто прикрутим ClickHouse» — ещё не архитектура; - Как профиль чтения и записи меняет устройство системы и почему инженеру важно отличать то, что аналитик просит, от того, что ему действительно нужно; - Когда классическое MPP-хранилище становится тормозом и что на практике даёт разделение storage и compute в Lakehouse; - Как переехать на новый стек, не остановив аналитику: параллельные контуры, проверка результатов, стоимость и эксплуатационные риски; - Что AI-агенты меняют в требованиях к платформе — от метаданных и прав доступа до прозрачности действий и контроля ресурсов; - Нужна ли в итоге отдельная AI-native дата-платформа или хороший фундамент остаётся тем же. Хочется уйти от каталога модных технологий и разобрать инженерные компромиссы: когда миграция действительно нужна, чем за неё придётся заплатить и какие решения выдерживают не только презентацию, но и production. Прямой эфир пройдет сегодня (24 августа) в 16:00.
#27
August 7 · 58 min
AI-разработка как совместно эволюционирующий стек
Почему одна и та же модель в двух кодинговых агентах даёт настолько разный результат? И что компании действительно стоит считать своим AI-стеком: модель, обвязку, инструменты, данные или право агента менять внутренние системы? В пятницу, 7 августа, в 27-м выпуске "Research Insights Made Simple" разберу AI-разработку как совместно эволюционирующую производственную систему. В этот раз без гостя: хочу собрать в одну картину выводы из последних исследований и инженерных разборов — от hardware-software co-design до agent harness, MCP, evals и production traces. Главная идея выпуска: преимущество всё реже живёт в одном компоненте. Сильная модель становится продуктом только внутри конкретной среды - с контекстом, примитивами действий, identity, policy и доказательствами результата. А сбой превращается в улучшение, только если команда умеет воспроизвести его, изменить нужный слой и заново пройти проверку. Поговорим о том: - Почему не каждый сбой требует новой модели и чем быстрый цикл настройки tools и harness отличается от медленного цикла model и hardware; - Почему API-совместимость и MCP ещё не дают поведенческой совместимости, корректных полномочий и безопасного эффекта; - Чем telemetry отличается от evals и training data — и почему production traces не улучшают модель автоматически; - Где провести границу между арендой, адаптацией и созданием своего: что разумно арендовать у провайдера, что адаптировать, а чем компания должна владеть сама; - Когда собственная обвязка действительно оправдана, а когда она превращается в дорогую попытку повторить общий агентный цикл. Для меня главный вывод такой: возможности компании не в модели и не количество MCP-серверов, а скорость доказанного изменения. Увидеть реальный сбой, сохранить эпизод, воспроизвести его, поправить один слой, пройти release gate и безопасно вернуть улучшение в production. Материалы выпуска и полный разбор: https://polomodov.tech/2026-08-07-ai-development-stack-codesign/ #AI4SDLC #AI #Agents #Architecture #PlatformEngineering #Evals #Engineering
#26
July 31 · 59 min
Разбираем построение работающих evals
Как понять, что AI-агент действительно готов к production? Красивый ответ и даже высокий "pass rate" показывают только финал одного запуска. Агент мог подсмотреть решение, выбрать опасный путь, нарушить права или рассыпаться при повторном прогоне. Обсудили это вместе с Евгением Сергеевым - Engineering Director в Flow Health с двадцатилетним опытом разработки и управления инженерными командами. Мы разбирали как превратить evals из разовой проверки ответа в воспроизводимую инженерную систему. Минимальная единица такой системы - воспроизводимый эпизод (`replayable episode`): замороженное исходное состояние, входные данные, контракт агента, скрытая проверка, трасса действий и критерий выпуска. Для кода это может быть commit до PR и `hidden tests`; для архитектуры - требования, ограничения и проверка исполнимости решения; для data platform - snapshot данных, lineage и инварианты. Обсудили Почему оценивать нужно всю агентную систему, а не только модель; Как заморозить исходное состояние и не дать агенту подсмотреть будущее решение; Что фиксировать в контракте: инструменты, права, сеть, время и бюджет; Зачем проверять не только результат, но и траекторию действий; Почему одного успешного запуска недостаточно и нужны повторные прогоны; Как собрать `production scorecard` из результата, траектории, стоимости, безопасности и принятия человеком; Как связать offline-evals с реальными production outcomes и превратить их в `release gates`. Для меня главный вывод такой: устойчивое качество создаёт не одна метрика и не конкретная модель. Нужен собственный каталог реальных задач, воспроизводимые проверки и понятный критерий, после которого новой версии агента действительно можно доверить работу.
#25
July 30 · 58 min
Моделируем надёжность по графу зависимостей
Можно ли понять, где распределённая система сломается, ещё до дорогого эксперимента со сбоями? В этом выпуске мы вместе с Анатолием Красновским разберём его работу "Model Discovery and Graph Simulation: A Lightweight Gateway to Chaos Engineering"(https://dl.acm.org/doi/10.1145/3786582.3786823), отмеченную `Distinguished Paper Award` на ICSE-NIER 2026. Анатолий — инженер, который пошёл в науку, чтобы спасти IT от шаманства. За 10+ лет в разработке он устал от того, что сложные системы строятся на интуиции и слепом копировании «лучших практик». Сейчас он пишет кандидатскую по матмоделированию в Иннополисе, чтобы научиться доказывать их устойчивость математически, а не надеяться на эмпирический авось, а также ведет свой канал о том, как на самом деле работают сложные системы: https://t.me/mb3rlab Идея подхода Анатолия из этой статьи проста: автоматически извлечь из распределённых трасс граф обязательных вызовов, добавить число реплик и с помощью Monte Carlo оценить доступность системы при отказах. Получается не замена chaos engineering, а дешёвый фильтр перед ним: модель помогает найти подозрительные цепочки, единичные точки отказа и сценарии, которые стоит проверить на живой системе в первую очередь. С автором обсудим: Почему для первого приближения может хватить топологии и числа реплик; Как автоматически обнаруживать модель из Jaeger и поддерживать её актуальной вместе с системой; Что означает высокая корреляция с живым fault injection и почему один benchmark ещё не доказывает универсальность метода; Где заканчиваются возможности модели: gray failures, коррелированные сбои, очереди, retries и асинхронные потоки; Как встроить такой анализ в CI/CD, связать его с SLO и превратить в приоритизацию chaos-экспериментов; Где проходит граница между полезным упрощением и опасной ложной уверенностью. Для меня главный вопрос выпуска практический: можем ли мы превратить наблюдаемость из способа расследовать уже случившийся инцидент в исполняемую модель надёжности — и использовать её, чтобы ломать систему реже, но точнее?

Showing 1–20 of 35 episodes