Research Insights Made Simple

Alexander Polomodov
  • 0.0 (0)
  • Natural Sciences
  • Updated Daily

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

  1. 6d ago

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

    Кодинговые агенты уже пишут код гораздо быстрее. Но если планирование, архитектурное ревью, безопасность, тестирование и деплой остаются на «человеческой скорости», ускоряется ли 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, а не исследование со сравнительным экспериментом. Поэтому отдельно проверим, где здесь переносимый инженерный подход, а где пока видение поставщика — особенно для большой регулируемой организации. #AI4SDLC #AI #Agents #Engineering #Architecture #DevOps #Research

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

  2. Aug 24

    Дата-платформа в 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.

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

  3. Aug 7

    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

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

  4. Jul 31

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

    Как понять, что 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`. Для меня главный вывод такой: устойчивое качество создаёт не одна метрика и не конкретная модель. Нужен собственный каталог реальных задач, воспроизводимые проверки и понятный критерий, после которого новой версии агента действительно можно доверить работу.

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

  5. Jul 30

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

    Можно ли понять, где распределённая система сломается, ещё до дорогого эксперимента со сбоями? В этом выпуске мы вместе с Анатолием Красновским разберём его работу "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-экспериментов; Где проходит граница между полезным упрощением и опасной ложной уверенностью. Для меня главный вопрос выпуска практический: можем ли мы превратить наблюдаемость из способа расследовать уже случившийся инцидент в исполняемую модель надёжности — и использовать её, чтобы ломать систему реже, но точнее?

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

  6. Jul 29

    Почему AI-copilot архитектора всё ещё не получился

    AI уже умеет предложить архитектурный паттерн, сформировать ADR и нарисовать убедительную диаграмму. Но умеет ли он удерживать историю решений, ограничения и последствия изменений для всей системы? В этом выпуске мы с Сергеем Барановым разберём whitepaper Artificial Intelligence Support for Software Architecture Practice — систематический обзор 51 исследования об AI в работе software-архитектора. Сергей - практикующий архитектор, партнер Скрамтрека и основатель конференции ArchDays, в программный комитет которой я вхожу с первой конференции и до текущего момента. В общем, с Сергеем мы давно знакомы и я знаю, что беседа получится интересной. Также он пишет о технологиях, социотехнической архитектуре и организационном развитии в своём канале https://t.me/blog_sb. Рекомендую подписаться, если вам интересна архитектура не как набор диаграмм, а как работа с системами, организациями и решениями. На самом стриму мы обсудим: Где AI уже полезен и почему лучше всего выглядят узкие задачи с измеримым контуром проверки; Почему диаграмма, ADR или список паттернов ещё не складываются в архитектурное решение; Что benchmark’и 2026 года говорят о способности моделей связывать требования, компоненты и trade-offs; Какой фундамент нужен настоящему copilot архитектора: живая связь требований, решений, кода и телеметрии — и ответственность человека за итоговый выбор. Сегодняшний AI в основном работает со статическим снимком, тогда как архитектура живёт в истории системы. Поэтому поговорим не только о моделях, но и о traceability, архитектурной базе знаний, метриках и роли архитектора. Для меня главный вопрос выпуска практический: если по изменению требования нельзя восстановить затронутые ADR, код и runtime-сигналы, сможет ли AI сделать что-то большее, чем красивый снимок?

    Почему AI-copilot архитектора всё ещё не получился

  7. Jul 23

    Экономика AI в разработке

    Токены дешевеют, модели становятся быстрее, но AI-бюджет компании от этого не обязательно уменьшается. Чем больше появляется рабочих сценариев, тем больше становится задач, агентных цепочек, инфраструктуры, проверок и цены ошибок. В прямом эфире разберём экономику AI в разработке — не как сравнение тарифов моделей, а как задачу управления производственной системой. Поговорим о том: Почему удешевление фиксированного уровня качества расширяет спрос и способно увеличить общий бюджет; Как агентная задача превращается в длинный trace с десятками вызовов, повторами и растущим контекстом — и почему ограничения нужны на весь workflow; Как считать `cost per accepted task`, включая инструменты, инфраструктуру, человеческую проверку, переделки и цену ошибки; Зачем сначала вводить общий quality gate и showback, а уже потом chargeback, роутинг и оптимизацию стоимости; Где возникает vendor lock-in и когда локальная модель действительно выгоднее облачной после учёта качества и эксплуатации. Отдельно покажу рабочий сценарий до 2029 года: цена сегодняшнего уровня качества может снизиться в разы, а бюджет успешного AI-портфеля — вырасти. Это не обещание рынка, а рамка для разговора о том, что именно компания получает за эти деньги. Основной вопрос эфира про то, какая единица связывает качество, стоимость и риск? Токены удобны для счёта поставщика. Для инженерной организации полезнее принятая работа — задача, которая прошла проверку, не потребовала дорогой переделки и дала нужный результат. Материалы к эфиру: https://polomodov.tech/2026-07-21-ai-development-economics/ #AI #AI4SDLC #Engineering #FinOps #Agents #Management #Metrics

    Экономика AI в разработке

  8. Jul 20

    Как собрать управляемый агентный стек с Мишей Трифоновым

    Что компания делает «своим» в агентной платформе: код клиента, модель, контур исполнения, данные или право агента менять внутренние системы? Эти вещи часто смешивают и сводят выбор к спору между «своим OpenCode» и «чужим Claude Code или Codex». В 22-м выпуске Research Insights Made Simple мы с Мишей Трифоновым из Cloud.ru разобрали эту ложную развилку и соберём полное описание агентного стека.  Миша Трифонов - Директор департамента внутренней платформы разработки Cloud.ru Рабочая формула шире привычной пары «модель + обвязка»: агентный стек = обвязка + модель + инструменты + идентичность + технические границы исполнения. Обвязка управляет циклом работы и контекстом, модель предлагает план, инструменты создают реальный эффект. Идентичность, sandbox и policy engine определяют, от чьего имени и в каких границах действует агент. Поговорили о восьми конфигурациях: от автономного стека и локальной модели до внешнего планировщика, корпоративного tool gateway и полного SaaS. У каждой схемы своя цена контроля, скорости, lock-in и эксплуатации. Отдельно обсудили несколько неочевидных следствий: open source ≠ local inference; self-hosted ≠ безопасные действия; доступы сотрудника ≠ доступы агента внутренний MCP ≠ узкие полномочия; внешний API ≠ внешнее право на действие; multi-model router = отдельная платформа. Ключевая идея — разделить два пути. Модельный шлюз контролирует, какие данные и к какой модели уходят. Инструментальный шлюз решает, кто, что и от чьего имени может изменить. Между ними нужны единые identity, policy, trace и evals. И здесь разговор переходит к безопасности. Атакуют не абстрактную модель, а путь от недоверенного README, issue или tool result до действия с реальными полномочиями. Поэтому ограничения должна обеспечивать инфраструктура, а не системный промпт. В общем, мы обсудили не «какой агент лучше», а какую минимальную конфигурацию выбрать для пилота, корпоративной платформы или регулируемого контура — и кто отвечает за фактическое изменение системы. #AI4SDLC #AI #Agents #Architecture #PlatformEngineering #Security #Engineering

    Как собрать управляемый агентный стек с Мишей Трифоновым
See All (29)

About

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

Information