Skip to content
ScienceNatural SciencesTechnologyBusinessManagement

Research Insights Made Simple

Alexander Polomodov

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

Play
  • 23 episodes
  • Avg 1 hr 6 min
  • Russian
Counted on this page — what you have heard stays on this device, so it is not something the list can be paged by.
  • #32
    Monday · 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/ Напишите в комментариях, во что упирается ваш инференс: память, ожидание первого токена, паузы при генерации или стоимость обслуживания.

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

  • #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

    Как измерять coding agents в диалоге

    Что меняется, если требования к кодинговым агентам приходят не идеальным промптом, а уточняются по ходу? 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 agents не отменяют экспертизу

    Что остаётся человеку, когда 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

    Loop Engineering / как проектировать циклы, которые сами запускают coding agents

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

    AI в SDLC / отчёт IT One и Сколково

    Обсудили исследования от 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

    Как AI влияет на продуктивность опытных разработчиков

    Разбор отчета 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

    Как генеративный AI меняет разработку ПО

    Этот выпуск посвящен обсуждению отчету "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

    Почему идеи в базах данных возвращаются - Часть 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

    Почему идеи в базах данных возвращаются - Часть 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

    Методология DORA / что стоит за метриками

    Этот выпуск посвящен обсуждению методологии "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) Актуальные проблемы и будущее моделирования/отчётов

Showing 1–20 of 23 episodes