Research Insights Made Simple

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

Research Insights Made Simple is a general podcast hosted by Unknown Host, with 0 episodes on record and a Required Pod Score of 80. PitchCentric scores this show on Booking Probability, Listen Score, and live audience signals refreshed every 24 hours.

Unknown Host hosts Research Insights Made Simple, a general show with 0 episodes published.

Our AI reads these to draft pitches. Use them as grounding for a pitch that cites a real guest and a specific topic.

• 

  Episode #29

  Разбор плейбука «The AI-Native SDLC playbook» с Антоном Костериным

  Aug 27, 20261h 7mS0

  <p>Кодинговые агенты уже пишут код гораздо быстрее. Но если планирование, архитектурное ревью, безопасность, тестирование и деплой остаются на «человеческой скорости», ускоряется ли delivery — или очередь просто переезжает в соседний этап?</p> <p>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)</p> <p>С Антоном мы уже говорили об architecture governance, RFC/ADR и архитектурных ревью (https://youtu.be/CEii3K0hAUw). Теперь вопрос шире: как перестроить под агентов не только написание кода, но весь SDLC.</p> <p>Тезис playbook: после ускорения Build bottleneck смещается в Plan, Test/Review и Deploy. Anthropic предлагает замкнуть шесть стадий, от Plan до Maintain, в цикл. intent.md, spec.md, plan.md, diff с тестами, результаты review и записи об инцидентах образуют цепочку версионируемых артефактов и одновременно audit trail. Человек остаётся ответственным, но подключается в точках, где действительно требуется суждение.</p> <p>Обсудим:</p> Действительно ли код перестал быть узким местом и где теперь скапливается очередь; Зачем нужны markdown-артефакты, если уже есть Jira, wiki и архитектурные процессы; Как превратить знания компании в CLAUDE.md, skills и проверяемые политики, не законсервировав ошибки; Как связать continuous evals, hooks, агентное и человеческое review с production monitoring; С какого участка SDLC начинать и какими метриками доказывать эффект. <p>Это практическое руководство команды Claude, а не исследование со сравнительным экспериментом. Поэтому отдельно проверим, где здесь переносимый инженерный подход, а где пока видение поставщика — особенно для большой регулируемой организации.</p> <p>#AI4SDLC #AI #Agents #Engineering #Architecture #DevOps #Research</p>

  ListenShow Notes
• 

  Episode #28

  Дата-платформа в 2026 году — от DWH к Lakehouse и AI-агентам

  Aug 24, 20261h 37mS0

  <p>В шестом выпуске (https://t.me/book_cube/2874) Research Insights Made Simple мы с Николаем Головым разбирали, как строить дата-платформы в 2025 году. В 28 выпуске мы возвращаемся к теме с вопросом посложнее: что происходит, когда аккуратная схема из storage, compute, catalog и orchestration встречается с legacy, стоимостью миграции и реальными аналитическими запросами?</p> <p>В гостях Николай Голов (https://harbour.space/faculty/Nikolay-Golov) и Александр Филатов. Николай — директор по продукту Tengri Data, в прошлом руководитель дата-платформ в Avito и ManyChat и преподаватель Harbour.Space. Александр пришёл в DWH из backend-разработки: до этого писал инструменты обработки данных на Python и C++. Почти десять лет он развивал хранилище данных Авито, в 2022–2025 годах занимался переходом с Vertica на Trino/Iceberg/S3, а теперь возглавляет разработку Tengri Data.</p> <p>Поговорим о том:</p> <p>- Где проходит граница между OLTP и OLAP, почему аналитика на реплике быстро упирается в потолок и отчего «давайте просто прикрутим ClickHouse» — ещё не архитектура;<br />- Как профиль чтения и записи меняет устройство системы и почему инженеру важно отличать то, что аналитик просит, от того, что ему действительно нужно;<br />- Когда классическое MPP-хранилище становится тормозом и что на практике даёт разделение storage и compute в Lakehouse;<br />- Как переехать на новый стек, не остановив аналитику: параллельные контуры, проверка результатов, стоимость и эксплуатационные риски;<br />- Что AI-агенты меняют в требованиях к платформе — от метаданных и прав доступа до прозрачности действий и контроля ресурсов;<br />- Нужна ли в итоге отдельная AI-native дата-платформа или хороший фундамент остаётся тем же.</p> <p>Хочется уйти от каталога модных технологий и разобрать инженерные компромиссы: когда миграция действительно нужна, чем за неё придётся заплатить и какие решения выдерживают не только презентацию, но и production.</p> <p>Прямой эфир пройдет сегодня (24 августа) в 16:00.</p>

  ListenShow Notes
• 

  Episode #27

  AI-разработка как эволюционирующий стек

  Aug 7, 202658 minS0

  <p>Почему одна и та же модель в двух кодинговых агентах даёт настолько разный результат? И что компании действительно стоит считать своим AI-стеком: модель, обвязку, инструменты, данные или право агента менять внутренние системы?</p> <p>В пятницу, 7 августа, в 27-м выпуске "Research Insights Made Simple" разберу AI-разработку как совместно эволюционирующую производственную систему. В этот раз без гостя: хочу собрать в одну картину выводы из последних исследований и инженерных разборов — от hardware-software co-design до agent harness, MCP, evals и production traces.</p> <p>Главная идея выпуска: преимущество всё реже живёт в одном компоненте. Сильная модель становится продуктом только внутри конкретной среды - с контекстом, примитивами действий, identity, policy и доказательствами результата. А сбой превращается в улучшение, только если команда умеет воспроизвести его, изменить нужный слой и заново пройти проверку.</p> <p>Поговорим о том:</p> <p>- Почему не каждый сбой требует новой модели и чем быстрый цикл настройки tools и harness отличается от медленного цикла model и hardware;<br />- Почему API-совместимость и MCP ещё не дают поведенческой совместимости, корректных полномочий и безопасного эффекта;<br />- Чем telemetry отличается от evals и training data — и почему production traces не улучшают модель автоматически;<br />- Где провести границу между арендой, адаптацией и созданием своего: что разумно арендовать у провайдера, что адаптировать, а чем компания должна владеть сама;<br />- Когда собственная обвязка действительно оправдана, а когда она превращается в дорогую попытку повторить общий агентный цикл.</p> <p>Для меня главный вывод такой: возможности компании не в модели и не количество MCP-серверов, а скорость доказанного изменения. Увидеть реальный сбой, сохранить эпизод, воспроизвести его, поправить один слой, пройти release gate и безопасно вернуть улучшение в production.</p> <p>Материалы выпуска и полный разбор:<br />https://polomodov.tech/2026-08-07-ai-development-stack-codesign/</p> <p>#AI4SDLC #AI #Agents #Architecture #PlatformEngineering #Evals #Engineering</p>

  ListenShow Notes
• 

  Episode #26

  Как строить работающие evals для AI-агентов

  Jul 31, 20261 hourS0

  <p>Как понять, что AI-агент действительно готов к production? Красивый ответ и даже высокий "pass rate" показывают только финал одного запуска. Агент мог подсмотреть решение, выбрать опасный путь, нарушить права или рассыпаться при повторном прогоне.</p> <p>Обсудили это вместе с Евгением Сергеевым - Engineering Director в Flow Health с двадцатилетним опытом разработки и управления инженерными командами. Мы разбирали как превратить evals из разовой проверки ответа в воспроизводимую инженерную систему.</p> <p>Минимальная единица такой системы - воспроизводимый эпизод (`replayable episode`): замороженное исходное состояние, входные данные, контракт агента, скрытая проверка, трасса действий и критерий выпуска. Для кода это может быть commit до PR и `hidden tests`; для архитектуры - требования, ограничения и проверка исполнимости решения; для data platform - snapshot данных, lineage и инварианты.</p> <p>Обсудили</p> Почему оценивать нужно всю агентную систему, а не только модель; Как заморозить исходное состояние и не дать агенту подсмотреть будущее решение; Что фиксировать в контракте: инструменты, права, сеть, время и бюджет; Зачем проверять не только результат, но и траекторию действий; Почему одного успешного запуска недостаточно и нужны повторные прогоны; Как собрать `production scorecard` из результата, траектории, стоимости, безопасности и принятия человеком; Как связать offline-evals с реальными production outcomes и превратить их в `release gates`. <p>Для меня главный вывод такой: устойчивое качество создаёт не одна метрика и не конкретная модель. Нужен собственный каталог реальных задач, воспроизводимые проверки и понятный критерий, после которого новой версии агента действительно можно доверить работу.</p>

  ListenShow Notes
• 

  Episode #25

  Моделируем надёжность по графу зависимостей

  Jul 30, 202658 minS0

  <p>Можно ли понять, где распределённая система сломается, ещё до дорогого эксперимента со сбоями?</p> <p>В этом выпуске мы вместе с Анатолием Красновским разберём его работу "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.</p> <p>Анатолий — инженер, который пошёл в науку, чтобы спасти IT от шаманства. За 10+ лет в разработке он устал от того, что сложные системы строятся на интуиции и слепом копировании «лучших практик». Сейчас он пишет кандидатскую по матмоделированию в Иннополисе, чтобы научиться доказывать их устойчивость математически, а не надеяться на эмпирический авось, а также ведет свой канал о том, как на самом деле работают сложные системы: https://t.me/mb3rlab</p> <p>Идея подхода Анатолия из этой статьи проста: автоматически извлечь из распределённых трасс граф обязательных вызовов, добавить число реплик и с помощью Monte Carlo оценить доступность системы при отказах. Получается не замена chaos engineering, а дешёвый фильтр перед ним: модель помогает найти подозрительные цепочки, единичные точки отказа и сценарии, которые стоит проверить на живой системе в первую очередь.</p> <p>С автором обсудим:</p> Почему для первого приближения может хватить топологии и числа реплик; Как автоматически обнаруживать модель из Jaeger и поддерживать её актуальной вместе с системой; Что означает высокая корреляция с живым fault injection и почему один benchmark ещё не доказывает универсальность метода; Где заканчиваются возможности модели: gray failures, коррелированные сбои, очереди, retries и асинхронные потоки; Как встроить такой анализ в CI/CD, связать его с SLO и превратить в приоритизацию chaos-экспериментов; Где проходит граница между полезным упрощением и опасной ложной уверенностью. <p>Для меня главный вопрос выпуска практический: можем ли мы превратить наблюдаемость из способа расследовать уже случившийся инцидент в исполняемую модель надёжности — и использовать её, чтобы ломать систему реже, но точнее?</p>

  ListenShow Notes

Based on semantic analysis of episode topics and host coverage, this show is a strong guest fit for executives in:

Industry fit is computed by PitchCentric using vector embeddings of the show's episode catalog.