ScienceNatural SciencesTechnologyBusinessManagement

Research Insights Made Simple

Alexander Polomodov

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

Play

Open in

20 episodes
Avg 1 hr 4 min
Russian

Episodes 20

Newest Oldest Longest

All20 Unplayed20 In progress0 Played0

#29
August 27 · 1 hr 6 min
Разбор плейбука «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, а не исследование со сравнительным экспериментом. Поэтому отдельно проверим, где здесь переносимый инженерный подход, а где пока видение поставщика — особенно для большой регулируемой организации. 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-агентов
Как понять, что 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-экспериментов; Где проходит граница между полезным упрощением и опасной ложной уверенностью. Для меня главный вопрос выпуска практический: можем ли мы превратить наблюдаемость из способа расследовать уже случившийся инцидент в исполняемую модель надёжности — и использовать её, чтобы ломать систему реже, но точнее?
#24
July 29 · 1 hr 24 min
Почему 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 сделать что-то большее, чем красивый снимок?
#23
July 23 · 45 min
Экономика 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
#22
July 20 · 1 hr 3 min
Как собрать управляемый агентный стек с Мишей Трифоновым
Что компания делает «своим» в агентной платформе: код клиента, модель, контур исполнения, данные или право агента менять внутренние системы? Эти вещи часто смешивают и сводят выбор к спору между «своим 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
#21
July 17 · 1 hr 4 min
Что меняется, если требования к кодинговым агентам приходят не идеальным промптом, а уточняются по ходу?
Что меняется, если требования к кодинговым агентам приходят не идеальным промптом, а уточняются по ходу? 17 июля в 16:00 МСК обсудим это с Алексеем Литвиновым в выпуске подкаста "Research Insights Made Simple #21". Мы поговорим про новые бенчи SWE-Together и SWE-INTERACT, опубликованные в один день. Оба я уже по отдельности разбирал в этом канале (SWE-Together (https://t.me/book_cube/4670) и SWE-INTERACT (https://t.me/book_cube/4684)). Вместе они показывают одну важную вещь: способность агента автономно выдать код по готовому, исчерпывающему ТЗ (как в классическом SWE-bench) ещё не означает, что он будет полезен в реальной совместной работе. На практике требования редко приходят идеальным промптом - они дорабатываются на лету, и здесь на первый план выходит способность адаптироваться под меняющийся контекст. Алексей Литвинов — Principal Engineer, автор книги и [образовательной программы по AI-Assisted Engineering](https://edu.alekseilitvinau.com/). Он исследует и внедряет способы превратить работу с AI-агентами из набора удачных экспериментов в управляемый, воспроизводимый и проверяемый инженерный процесс на реальных кодовых базах. У Лёши есть и Telegram-канал — @tip_podcast. Если же возвращаться к самим бенчам, то - SWE-Together (от исследователей из запрещенной в России компании Meta) идёт от реальных пользовательских сессий и вводит метрику User Correction - сколько раз человеку пришлось вернуть агента на курс - SWE-INTERACT (от исследователей из Scale.ai) делает обратный эксперимент: берёт те же задачи и те же проверки, но раскрывает требования постепенно. У сильных моделей доля решённых задач в таком режиме падает примерно вдвое, а работа становится длиннее и дороже. Интерес этих исследований не в очередном рейтинге моделей. Они позволяют увидеть цену диалога: корректирующее руление, забытые требования, повторные проверки и зависимость результата от обвязки агента. Multi-turn работа оказывается отдельной инженерной способностью. Мы поговорим о том, какая из двух методик ближе к реальной разработке, можно ли доверять симулятору пользователя, почему агент забывает требования из ранних реплик и как командам строить собственные multi-turn evals. 17 июля, 16:00 МСК. Приходите разбираться и спорить вместе с нами. #AI #AI4SDLC #Agents #Evals #Engineering #Research
#20
July 16 · 1 hr 17 min
Почему кодинговые агенты не отменяют экспертизу с Евгением Сергеевым
Что остаётся человеку, когда coding agent выбирает файлы, запускает команды и пишет реализацию? Мы обсудили это с Евгением Сергеевым в прямом эфире "Research Insights Made Simple - Season 1, Episode 20". Мы разобрали whitepaper Anthropic "Agentic coding and persistent returns to expertise". Евгений Сергеев (https://www.linkedin.com/in/esergueev/) — Director of Engineering в Flo Health. Он развивает продуктовые инженерные команды и занимается практическим внедрением AI в разработку: coding agents, eval-driven development, quality gates и AI-assisted workflows. Женю интересует, как сделать работу с агентами управляемой и проверяемой — и что происходит с инженерной экспертизой, когда код писать становится дешевле, а цена неправильных решений остаётся высокой. Если же возвращаться к папире, то авторы проанализировали 398 198 интерактивных сессий 234 751 пользователя Claude Code и пришли к выводу, что экспертиза пользователей в задаче связана с более глубоким делегированием агенту и более частым успехом сессии. Но это наблюдательная выборка одного продукта, а не эксперимент о производительности всей индустрии. Поэтому обсудили не только цифры, но и границы того, что они доказывают: Почему экспертиза здесь - знание конкретной задачи, а не грейд или стаж; Что означает разделение труда: человек принимает около 70% решений о том, что делать, но лишь 20% - о том, как; Почему экспертные сессии запускают примерно вдвое больше действий агента, но это ещё не означает вдвое большую продуктивность; Можно ли считать рост "verified success" с 14,5% до 32,9% эффектом экспертизы или мы видим только корреляцию; Где граница между успешной сессией, принятым PR, надёжным продакшен кодом и пользой для бизнеса; Как командам измерять время проверки, переделки, дефекты и сохранение знаний, а не только скорость генерации. Отдельно поговорили об организационном парадоксе: опытный инженер способен сильнее разогнать агента, но если всё исполнение отдавать машине, откуда возьмутся следующие опытные инженеры? Для меня это разговор не о том, заменит ли Claude Code разработчика. Вопрос практичнее: какая экспертиза становится дефицитной, когда код дешевеет, а цена неверного решения остаётся у команды. #AI #AI4SDLC #Research #Engineering #Agents #Metrics #DevEx
#19
July 14 · 1 hr 26 min
Разбор whitepaper "Loop Engineering" с Максимом Смирновым
Кто управляет кодинг-агентом: человек или спроектированный им цикл? Мы привыкли обсуждать промпты, контекст и обвязку одного запуска агента. Но когда агент сам возвращается к работе - по расписанию, событию или результату прошлого прохода, - задача становится архитектурной: кто находит работу, проверяет результат, хранит состояние и может остановить цикл. 14 июля в 19-м выпуске подкаста Research Insights Made Simple проведу прямой эфир с Максимом Смирновым. Разберём материал HuaShu «Loop Engineering: The Anthropic Playbook for Designing Systems That Prompt Your Agents». Максим — ИТ-архитектор, автор Telegram-канала «Архитектура ИТ-решений» https://t.me/it_arch. В прошлом — руководитель департамента ИТ-архитектуры «Билайн» и главный архитектор информационных систем Банка России; спикер, автор и преподаватель курсов по ИТ-архитектуре. Формально это не публикация Anthropic и не рецензируемая статья, а независимый рабочий конспект (working note) HuaShu. Сильная сторона этой whitepaper - точная постановка задачи: перестать подталкивать агента очередным промптом и спроектировать ограниченный, наблюдаемый и останавливаемый цикл. Обсудим: - чем проектирование циклов отличается от обвязки одного запуска и почему cron с повторяющимся промптом ещё не цикл; - как связаны поиск работы (discovery), передача (handoff), проверка, сохранение состояния и планирование; - почему агенту опасно доверять проверку своей работы и как разделить исполнителя и проверяющего; - какие долги накапливают автономные циклы — от долга проверки до потери понимания системы; - какие ограничения нужны вокруг LLM: изоляция, лимиты, журнал, откат и аварийная остановка; - где остаются инженерное суждение, ответственность и контрольная точка для человека. Главный вопрос эфира: как отдать агенту повторяемую работу, не позволив ему незаметно накапливать ошибки. #AI4SDLC #Agents #Architecture #Engineering #Research
#18
Oct 23, 2025 · 1 hr 14 min
Review of "AI in SDLC report" by IT One & Skolkovo
Обсудили исследования от IT One и Сколково вместе с Дмитрием Немовым, директором по развитию и продуктам IT ONE. Дима - один из авторов этого исследования, что позволило копнуть в цели исследования, методологию, результаты. В общем, мне было очень интересно общаться с Димой и я надеюсь, что вам тоже понравиться выпуск. И если он вам зайдет, то поучаствуйте в исследовании про влияние AI на SDLC от Т-Банка https://ai4sdlc.tbank.ru/ Кстати, сами результаты исследования от IT One и Сколково доступны по ссылке, плюс есть мой разбор в двух постах: https://t.me/book_cube/3937 и https://t.me/book_cube/3938. А в этом выпуске мы обсудили следующие темы Введение и тема выпуска Предпосылки: зачем это исследование Структура и методология исследования Мировая практика и этапы SDLC Сквозные инструменты и внутренняя платформа Автоматизация задач и роль доменных специалистов Как мерить продуктивность: опросы vs метрики активности Ассистенты и автодополнение - норма в 2025 году Платформенные решения: ИИ как ядро стратегии 2024→2025: адаптация и ожидания vs реальность Российские тренды: централизованный ModelOps и пилоты Агентные и мультиагентные подходы Изменение ролей в командах и доверие к коду Платформа для измерения эффектов (утилизация, impact, cost‑benefit analysis) Переход от пилотов к продукту и выбор кейсов
#17
Sep 7, 2025 · 46 min
Review "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity"
Разбор отчета METR "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity", где показано замедление разработчиков при использовании AI. Методология мне показалось хоть и интересной, но объем выборки аж в 16 инженеров казался мне маловатым для того, чтобы делать громкие заявления о замедлении разработки. Правда, такой размер выборки не помешал многим журналистом активно писать про это исследование. В итоге, я позвл в гости Артема Арюткина, СРО платформы для разработчиков в Городских сервисах Яндекса, вместе с которым мы обсудили все плюсы и минусы этого исследования. Вот примерный список тем, что мы успели обсудить за 40+ минут 00:00 - Введение, анонс METR и бенчмарка 01:37 - Знакомство с гостем 03:29 - Спонсор исследования и возможная предвзятость 04:57 - Как устроен эксперимент 06:29 - Гипотезы о мотивах и дизайне исследования 09:07 - Оценка и самооценка задач участниками 10:28 - Набор участников и требования к ним 12:01 - Ограничения масштаба и методологии 16:11 - Цифры: 246 задачи от 1 до 8 часов по длительности, 16 инженеров в исследовании 17:10 - Пять факторов замедления работы 21:48 - Контекст, интеграция и коммуникации как узкое место 27:06 - Как работать с инструментом по уровням сложности 34:18 - Почему моделям сложно применять изменения в реальном коде 37:47 - Итоги бенчмарков и ограниченность генерализации
#16
Aug 21, 2025 · 1 hr 12 min
Review of " Impact of Generative AI in Software Development"
Этот выпуск посвящен обсуждению отчету "DORA" про влияние AI на разработку софта. DORA является стандартом де-факто в мире опросов по теме devops и developer productivity, а в 2025 году они опубликовали отчет про влияние AI на основе опроса 2024 года. Этот отчет я обсуждаю с Игорем Курочкиным, у которого больше 12 лет опыта в индустрии, из которых 6 лет в консалтинге. Он помогает развивать инженерную культуру, процессы и практики, платформенные и продуктовые команды в больших компаниях. В предыдущем выпуске https://youtu.be/paynIB-5pow мы разбирали саму методологию, а теперь решили поговорить про результаты. За час общения с Игорем мы обсудили много тем, среди которых представленные ниже Введение и обзор отчёта Методика исследования и подход к анализу Результаты о влиянии ИИ на индивидуальную работу Специфика влияния ИИ на стартапы и генерацию идей Toil и автоматизация непродуктивной работы (опыт Google) Влияние ИИ на инженерные процессы и технический долг Изменения в моделях доставки, новые метрики и анализ трендов Ценности разработчиков и психология внедрения ИИ Продуктивность, доверие к ИИ и различие восприятия Внедрение, политика и стимулирование использования ИИ Стратегии масштабирования и связанные метрики Особенности сбора и анализа обратной связи, роль фреймворка Развитие и новые уровни модели и лидерство во времена перемен
#15
Aug 13, 2025 · 1 hr 8 min
Review of"What goes around comes around ... and around" - Part II
Этот выпуск продолжает обсуждение whitepaper "What goes around comes around ... and around" от Michael Stonebraker и Andrew Pavlo про развитие баз данных за последние 20 лет. Здесь мы поговорили о том, как менялись архитектуры баз данных и почему, а также обсудили выводы авторов исследования о будущем баз данных. Разбору статьи помогает мне Алексей Светличный, мой коллега, что руководит развитием отдела баз данных в Т-Банке. Алексей работает с базами данных более 15 лет, где он прошел путь от небольших систем, до крупных Enterprise решений. Сейчас руководит командой, которая разрабатывает DBaaS и развивает экспертизу по базам данных в компании. За час общения с Лешей мы обсудили вторую половину статьи, куда входили следующие темы Введение и план обсудить эволюцию архитектур баз данных за 20 лет. Развитие архитектур реляционных и колоночных БД Появление и развитие облачных БД с разделением хранения и вычислений (масштабирование ресурсов, эластичность вычислений, объектное хранилище) Прорывы в OLTP-масштабировании (пример AWS Aurora) Data Lake House и гибридные движки (Parquet, Iceberg, разделение масштабирования воркеров и хранилища) Качество данных и подходы к хранению разных классов данных Изменение парадигмы ответственности за данные в компаниях (Data Mesh) NoSQL базы, CAP-теорема и консистентность (MongoDB, Cassandra, ACID в NoSQL) NewSQL базы (Google Spanner, CockroachDB, YDB) и сложность их эксплуатации Новые технологии и аппаратная поддержка БД Роль маркетинга в успехе технологий, опенсорс и пользовательский опыт Финальные выводы whitepaper и размышление о будушем баз данных
#14
Aug 11, 2025 · 1 hr 3 min
Review of "What goes around comes around ... and around" - Part I
Этот выпуск посвящен обсуждению whitepaper "What goes around comes around ... and around" от Michael Stonebraker и Andrew Pavlo про развитие баз данных за последние 20 лет. Разбору статьи помогает мне Алексей Светличный, мой коллега, что руководит развитием отдела баз данных в Т-Банке. Алексей работает с базами данных более 15 лет, где он прошел путь от небольших систем, до крупных Enterprise решений. Сейчас руководит командой, которая разрабатывает DBaaS и развивает экспертизу по базам данных в компании. За час общения с Лешей мы обсудили половину статьи, успев разобрать общее впечатление от статьи и часть про модели данных и языки запросов. В итоге, получились следующие темы 00:00:00 - Введение и знакомство с гостей 00:01:48 - Общий обзор статьи 00:03:42 - Отличия российского и мирового контекста развития БД 00:05:08 - Обсуждение авторов статьи и их влияния на индустрию (Майкла Стоунбрейкера и Эндрю Павло) 00:08:00 - Эволюция моделей данных и языков запросов 00:12:08 - MapReduce (аля Hadoop и почему они уже leagcy) 00:14:56 - Системы KV и их ограничения 00:17:48 - Документно-ориентированные базы данных (MongoDB) 00:24:16 - Wide Column Family и Apache Cassandra 00:31:30 - Полнотекстовый поиск - Elasticsearch и встроенные возможности в RDBMS 00:38:28 - Векторные базы данных и семантический поиск 00:49:28 - Многомерные данные и array databases 00:53:19 - Графовые базы данных 01:02:29 - Заключение и анонс следующей темы
#13
Aug 5, 2025 · 1 hr 22 min
Review of DORA Methodology
Этот выпуск посвящен обсуждению методологии "DORA", которая является стандартом де-факто в мире опросов по теме devops и developer productivity. В 2024 году DORA опросам исполнилось 10 лет и за это время было получено много крутых выводов о связи процессов и практик внутри организации и ее эффективности, а это именно те вопросы, которые интересуют менеджмент. В отличие от многих других подходов к опросам здесь утверждения подтверждены систематическими исследованиями. Саму методологию я обсуждаю с Игорем Курочкиным, у которого больше 12 лет опыта в индустрии, из которых 6 лет в консалтинге. Он помогает развивать инженерную культуру, процессы и практики, платформенные и продуктовые команды в больших компаниях. Год назад мы разбирали книгу "Accelerate" в отдельном выпуске подкаста https://www.youtube.com/watch?v=63O0goBmkQw . Интересно, что "Accelerate" была написана по результатам проведения первых пяти лет опросов DORA. За полтора часа общения с Игорем мы обсудили много тем, среди которых представленные ниже. Введение и знакомство с гостем История и эволюция DORA Методология DORA: ключевые аспекты Построение опроса: постановка гипотез, формирование вопросов Структура модели DORA: capability, outcomes, выделение отдельных тем (ИИ, платформы) Сложности проведения опросов и подход к аналитике по ним Репрезентативность и сбор респондентов Проблемы формирования конструктов и их валидности Исследование инженерной культуры - культура по Веструму и ее влияние на процессы Эволюция моделей и статистических методов Проблемы установления причинно-следственных связей Роль скрытых переменных (confound) Актуальные проблемы и будущее моделирования/отчётов
#12
Jul 21, 2025 · 54 min
Review "Measuring developer productivity with the DX Core 4"
Выпуск посвящен разбору "Measuring developer productivity with the DX Core 4" от ребят из DX, которые активно развивают тему developer productivity. Для разбора этой статьи ко мне пришел гость, Евгений Сергеев, engineering director в Flo Health. Введение, история и предпосылки появления DX Core 4 Основые принципы измерения продуктивности, проблемы опросов 4 метрики DORA: deployment frequency, lead time for changes, change failure rate, time to restore service Простота внедрения DORA, интеграция с инструментами и его ограничения Фреймворк SPACE: опросы и системные метрики как фактор эффективности Дизайн фреймворков - разработка для решения конкретных проблем, добавление метрик по необходимости Развитие платформы DX Многомерные измерения внутри фреймворка DX Core 4 (качество, эффективность, скорость и импакт.) Настройка метрик, балансирующие метрики Роль технического директора при анализе метрик Анализ метрик и критерии их оценки Внедрение метрик в организации
#11
Jul 8, 2025 · 33 min
Review "Measuring AI Code Assistants and Agents"
Очередной выпуск подкаста с разбором whitepaper "Measuring AI Code Assistants and Agents" посвящен разбору измерения эффекта от AI в разработке. Этот отчет интересен, так как ребята из DX являются одними из законодателей мод в мире developer productivity. Для разбора этой статьи ко мне пришел гость, Евгений Сергеев, engineering director в Flo Health. За полчаса мы разобрали whitepaper и осудили темы Платформа DX и оценка влияния кодовых ассистентов и агентов на продуктивность инженеров Структура фреймворка DX: этапы зрелости, метрики и риски неправильного внедрения Оценка adoption и утилизации Оценка импакта и метрики Коммуникация внедрения метрик в разработку Обсуждение фреймворков DORA, SPACE, DevEx, DX Core 4 для измерения эффективности продуктивности инженеров в общем
#10
May 30, 2025 · 41 min
Review "Measuring Developer Experience With a Longitudinal Survey"
Очередной выпуск подкаста с разбором whitepapers посвящен разбору темы проведения опросов инженеров "Measuring Developer Experience With a Longitudinal Survey". Для разбора этой статьи ко мне пришел гость, Артем Арюткин, руководитель проектного и продуктового офиса в RideTech & e-com Яндекса. Артем отвечает за развитие платформы для разработчиков, а раньше в Сбере занимался развитие платформы Сбербанк онлайн и рекомендательной платформы. Артем ведет интересный телеграм канал - https://t.me/badTechProject За 40 минут мы успели обсудить следующие темы Опыт Google в проведении опросов Преимущества и процесс проведения опросов Методология и анализ опросов Важность коммуникации и внедрения изменений по итогам опросов Роль менеджера и сменяемость ролей в команде Масштабирование и частота опросов Продуктовый подход и интеграция онлайн-опросов Двухсторонний анализ: опросы и логи P.S. Я разбирал этот whitepaper в своем tg канале в двух частях: 1 и 2

Showing 1–20 of 20 episodes