Research Insights Made Simple

В этом выпуске разберу, как провести границу владения 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-стека вы уже делаете сами и почему. Это как раз те решения, на которых хочется проверить предложенную рамку.

#AI4SDLC #ResearchInsights #AI

Представим, что сборки стали быстрее, AI помогает писать код, а графики активности растут. Как понять, что команде стало легче достигать полезного результата? Кто тратит время на проверку, объяснение и сопровождение того, что удалось быстрее создать?

В Research Insights Made Simple #30 соберу исследования и мои разборы серии в общую картину: от целей инженера и методов измерения до качества, совместной работы и последствий использования AI. Посмотрим, как скорость, удобство работы и качество результата связаны между собой и какие вопросы стоит задавать перед выбором метрик.

В выпуске:

Цели разработчиков: что именно человек пытается сделать и где заканчивается задача; Измерения: как сопоставлять логи, опросы и наблюдения и что делать, когда они дают разную картину; Рабочая среда: ожидание сборок, предсказуемость, сосредоточенность и переключения; Адаптация новичков: как учитывать обучение, самостоятельность и время наставника; Качество и технический долг: процесс, код, система, продукт и цена будущих изменений; Командная работа: помощь коллегам, передача контекста и перенос нагрузки между командами; AI-инструменты: потребности разработчика, доверие, проверка результата и сохранение возможностей учиться.

В конце предложу практический план первого месяца для вашей команды: выбрать одну инженерную цель, собрать исходную картину, попробовать одно ограниченное изменение и вместе с командой оценить последствия. Это отправная точка для вашей программы улучшений.

Выпуск для руководителей разработки, тимлидов, платформенных команд и инженеров, которые хотят понять, какие изменения действительно помогают в работе.

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

В шестом выпуске (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.

Почему одна и та же модель в двух кодинговых агентах даёт настолько разный результат? И что компании действительно стоит считать своим 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-агент действительно готов к 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`.

Для меня главный вывод такой: устойчивое качество создаёт не одна метрика и не конкретная модель. Нужен собственный каталог реальных задач, воспроизводимые проверки и понятный критерий, после которого новой версии агента действительно можно доверить работу.

Можно ли понять, где распределённая система сломается, ещё до дорогого эксперимента со сбоями?

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

Для меня главный вопрос выпуска практический: можем ли мы превратить наблюдаемость из способа расследовать уже случившийся инцидент в исполняемую модель надёжности — и использовать её, чтобы ломать систему реже, но точнее?

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

В прямом эфире разберём экономику 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

Что компания делает «своим» в агентной платформе: код клиента, модель, контур исполнения, данные или право агента менять внутренние системы? Эти вещи часто смешивают и сводят выбор к спору между «своим 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

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

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

Кто управляет кодинг-агентом: человек или спроектированный им цикл?

Мы привыкли обсуждать промпты, контекст и обвязку одного запуска агента. Но когда агент сам возвращается к работе - по расписанию, событию или результату прошлого прохода, - задача становится архитектурной: кто находит работу, проверяет результат, хранит состояние и может остановить цикл.

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

Обсудили исследования от 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) Переход от пилотов к продукту и выбор кейсов

Разбор отчета 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 - Итоги бенчмарков и ограниченность генерализации

Этот выпуск посвящен обсуждению отчету "DORA" про влияние AI на разработку софта. DORA является стандартом де-факто в мире опросов по теме devops и developer productivity, а в 2025 году они опубликовали отчет про влияние AI на основе опроса 2024 года. 

Этот отчет я обсуждаю с Игорем Курочкиным, у которого больше 12 лет опыта в индустрии, из которых 6 лет в консалтинге. Он помогает развивать инженерную культуру, процессы и практики, платформенные и продуктовые команды в больших компаниях. В предыдущем выпуске https://youtu.be/paynIB-5pow мы разбирали саму методологию, а теперь решили поговорить про результаты.

За час общения с Игорем мы обсудили много тем, среди которых представленные ниже

Введение и обзор отчёта Методика исследования и подход к анализу Результаты о влиянии ИИ на индивидуальную работу Специфика влияния ИИ на стартапы и генерацию идей Toil и автоматизация непродуктивной работы (опыт Google) Влияние ИИ на инженерные процессы и технический долг Изменения в моделях доставки, новые метрики и анализ трендов Ценности разработчиков и психология внедрения ИИ Продуктивность, доверие к ИИ и различие восприятия Внедрение, политика и стимулирование использования ИИ Стратегии масштабирования и связанные метрики Особенности сбора и анализа обратной связи, роль фреймворка Развитие и новые уровни модели и лидерство во времена перемен

Этот выпуск продолжает обсуждение 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 и размышление о будушем баз данных

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

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

Выпуск посвящен разбору "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 (качество, эффективность, скорость и импакт.) Настройка метрик, балансирующие метрики Роль технического директора при анализе метрик Анализ метрик и критерии их оценки Внедрение метрик в организации

Очередной выпуск подкаста с разбором 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 для измерения эффективности продуктивности инженеров в общем

Очередной выпуск подкаста с разбором whitepapers посвящен разбору темы проведения опросов инженеров "Measuring Developer Experience With a Longitudinal Survey". Для разбора этой статьи ко мне пришел гость, Артем Арюткин, руководитель проектного и продуктового офиса в RideTech & e-com Яндекса. Артем отвечает за развитие платформы для разработчиков, а раньше в Сбере занимался развитие платформы Сбербанк онлайн и рекомендательной платформы. Артем ведет интересный телеграм канал - https://t.me/badTechProject

За 40 минут мы успели обсудить следующие темы

Опыт Google в проведении опросов Преимущества и процесс проведения опросов Методология и анализ опросов Важность коммуникации и внедрения изменений по итогам опросов Роль менеджера и сменяемость ролей в команде Масштабирование и частота опросов Продуктовый подход и интеграция онлайн-опросов Двухсторонний анализ: опросы и логи

P.S.
Я разбирал этот whitepaper в своем tg канале в двух частях: 1 и 2

В этой серии подкаста речь идет про whitepaper "What Do Developers Want From AI?". Для его обсуждения я позвал в гости Николая Бушкова из RnD центра Т-Банка. Николай занимается исследованиями инженерной продуктивности и глубоко погружен в темы того, как AI может улучшать инженерные процессы. Кстати, подробнее про RnD центр Т-Банка и направлениях исследований можно прочитать здесь https://www.tbank.ru/career/technologies/engineering-productivity/

В этом выпуске мы обсудили следующие темы
1. Введение в тему: AI и разработчики
2. Метафоры технологических изменений (параллели с электрификацией)
3. Три уровня AI-улучшений (параллели с автомобильной промышленностью)
4. Подходы к измерению продуктивности (комбинация опросов и логов)
5. Code review и роль AI (примеры из практики)
6. Проблемы документации и технического долга
7. Платформенный подход к инструментам
8. Агентные системы и метауровень
9. Исследования продуктивности и сотрудничество (примеры из Google и Т-Банка)

В этом выпуске подкаста про инсайты ко мне в гости пришел Александр Кусургашев для того, чтобы поговорить про гугловую статью "Measuring developer goals":) Александр работает в Т-Банке в подразделении Core Tech и занимается развитием нашей внутренней платформы разработки. Он верит в законы физики, платформизацию и пользу от переиспользования. Для него важно, чтобы IT системы Т-Банка работали эффективно - от уровня физической инфраструктуры до конечных сервисов для потребителей. Большую часть своей IT карьеры Саша провел разрабатывая платформенные решения для low latency и ultra low latency electronic trading.

За время подкаста мы обсудили темы:

Опыт работы Саши и его зона ответственности в Т-Банке Обсуждение critical user journeys для определения измеримых и объективных целей инженеров Гранулярность и декомпозиция целей Комплексный подход к оптимизации Важность систематического процесса выделения целей Эволюция обратной связи в опросах Engineering Satisfaction Survey Переход от инструментов к целям Измерение метрик и мониторинг процессов Вариативность инструментов и сложность стандартизации Научный подход к улучшению процессов

В этом выпуске подкаста про инсайты ко мне в гости пришел Павел Лакосников для того, чтобы поговорить про управление архитектурой в крупной компании:) Павел руководит юнитом architecture governance в Авито, распилил один монолит, а также любит метрики. Пришел в Авито 9 лет назад на позицию разработчика.

За время подкаста мы обсудили темы:

Как Павел начал свою карьеру в IT Как дизайн игр связан с архитектурой Как от надежности приложений перейти к их архитектуре Как мерить надежность и архитектуру, какие метрики бывают Зачем нужны процессы и стандарты Как происходит эволюция процессов разработки В чем роль платформ при создании сложных систем Какие советы можно дать инженерам, что хотят прокачивать свои навыки

В этом выпуске подкаста про инсайты ко мне в гости пришел Николай Голов для того, чтобы обсудить то, как строить дата платформы в 2025 году:) Коля исполняет роль head of data engineering at ManyChat, а до этого он был head of data platform в Авито. Коля знает все о том как построить OLAP и OLTP системы, интенсивно работающие с данными.

За время подкаста мы обсудили темы

Как развивалась карьера Коли в разных компаниях и как он стал преподавать базы данных параллельно с основной работой Как можно строить платформы данных (централизованно, гибридно и децентрализованно) Как выглядят принципы федерализации данных (аля data mesh) в теории Во что этот подход превращается на практике Как строить дата платформы в стартапах, средних, а также крупных компаниях в 2025 году Что не так с классическими базами данных (Postgres и иже с ним) Что не так с MPP базами данных (Vertica, Greenplum, ClickHouse, ...) Как data mesh превращается в data mash и как цепочки дата продуктов работают на практике Как выделять базовый домен данных, чтобы уменьшить длину цепочек дата продуктов Почему облачные аналитические базы так быстры: колоночное хранение + разделение storage и compute Что такое medalion architecture Куда дальше будут развиваться технологии обработки данных и почему нельзя полагаться на старые подходы и ограничения

Дополнительные материалы

Статья из периода работы в Avito "Vertica+Anchor Modeling = запусти рост своей грибницы" Статьи из периода работы в Manychat: 1 и 2 Запись "Data Modeling Meetup Munich: From Data Vault to Anchor Modeling with Nikolai Golov" Запись "DataVault / Anchor Modeling / Николай Голов" Научная статья "Golov N., Ronnback L., Big Data Normalization for Massively Parallel Processing Databases" //Computer Standards & Interfaces, 09-May-2017, https://doi.org/10.1016/j.csi.2017.01.009 Научная статья "Golov N., Filatov A., Bruskin S.,Efficient Exact Algorithm for Count Distinct Problem", Computer Algebra in Scientific Computing, July 2019

Очередной выпуск подкаста с разбором whitepapers посвящен разбору темы developer productivity, где мы говорим про DORA метрики, фреймворк SPACE, подход DevEx, а также про human approach от Google к теме developer productivity. Для обсуждения этих тем ко мне пришел гость, Артем Арюткин, руководитель проектного и продуктового офиса в RideTech & e-com Яндекса. Артем отвечает за развитие платформы для разработчиков, а раньше в Сбере занимался развитие платформы Сбербанк онлайн и рекомендательной платформы. Артем ведет интересный телеграм канал "Плохой проджект"

Дополнительная источники информации
1) Мое выступление "Как и зачем измерять инженерную продуктивность в крупной компании" на MTS конференции
2) Обзор книги канонической книги "Accelerate" в трех частях:
-- Общая информация по книге, формат исследования и DORA метрики
-- Технические практики, архитектуру и интеграцию вопросов безопасности в процессы разработки (https://tellmeabout.tech/review-accelerate-part-ii-9dc11986036b)
-- Менеджерские и лидерские практики (https://tellmeabout.tech/review-accelerate-part-iii-533a180327f2)
3) Выпуск подкаста "Code of Leadership" про "Accelerate" с Игорем Курочкиным
4) Разбор темы developer productivity в фреймворках SPACE, DevEx
5) Разбор начальной статьи ребят из Google "A Human-Centered Approach to Developer Productivity" и рассказ про целую колонку в IEEE журнале от этих авторов
6) Разбор статьи "Measuring Developer Goals" от ребят из Google (продолжение серии про Human-Centered Approach)
7) Разбор статьи "Developer productivity for Humans, Part 7: Software Quality" от ребят из Google (продолжение серии про Human-Centered Approach)
8) Разбор выступления моего коллеги Вовы Калугина "Почему DevEx важен при разработке IDP и как его померить", где он рассказывает про нашу платформу Spirit и как мы подходим к вопросам developer experience и developer productivity
9) "Грокаем Continuous Delivery" - отличная книга, которая расскажет о CI CD и проведет вас по всему пути эволюции
10) "Гормоны счастья. Как приучить мозг вырабатывать серотонин, дофамин, эндорфин и окситоцин" - прекрасная книга, раскрывающая многие наши поступки. Мы слегка затронули тему длительного цикла обратной связи для менеджера и эта книга попадает туда, чтобы раскрыть тему. Но желание покрасить все тесты в зеленый простым их перезапуском - это, внезапно, про то, как работает наш мозг и желание получения быстрого дофамина. И когда занимаешься Developer Experience такое нуж

В этом эпизоде мы обсуждаем интересный whitepaper "AI-Enhanced API Design" от ребят из Google, где рассказывалось о том, как подходы к управлению API влияют на продуктивность и usability, где исследователи показали, что общие стандарты вместе с инструментами, которые помогают им следовать, приводят к статистически значимым улучшениям в качестве дизайна API.

В разборе мне помогает крутой гость - Павел Каравашкин, мой коллега. Павел является руководителем разработки платформы T-API, а также лидером профессии системного анализа в Т-Бизнес, соведущим подкаста SA Т-Банка InSAйт. Паша любит велоспорт, Warhammer 40k и читать случайные статьи на Википедии. 

Материалы:

AI-Enhanced API Design: A New Paradigm in Usability and Efficiency Мой обзор этой научной статьи Публичное T-API для партнеров Подкаст InSAйт

Мы обсудили следующие моменты

Обзор статьи и личные впечатления Павла Обсуждение структуры статьи Проблемы и аспекты проектирования API Процесс разработки API в Google Гибкость и стандартизация в разработке API Методология исследований в Google Подходы к исследованием вокруг API в T-банке Проблемы и решения в персонализации Использование линтеров и метрик Анализ логов и задач разработчиков Исследования и метрики в Google Генерация контрактов Проблемы с архитекторами Методология эксперимента в Google и его результаты Ограничения эксперимента В общем про процесс разработки и помощь автоматизированных средств Важность этапа реализации Архитектура и улучшение процессов Измерение эффективности инструментария (отсылка к статье "Measuring developer goals" от ребят из Google) Роли в разработке Автоматизация кибербезопасности (отсылка к предыдущему подкасту)Заключение и планы на будущее

В этом эпизоде мы обсуждаем интересный whitepaper "Secure by Design at Google" от Chirstoph Kern на тему security с человеческим лицом от Google, где рассказывалось о том, как создавать безопасный софт на большом масштабе. В разборе мне помогает крутой гость - Артем Мерец, мой коллега. Артем был разработчиком и 10 лет назад перешел в информационную безопасность. Он активно строил AppSec, когда он начал зарождаться в России как стрим, а затем увлекся атаками и несколько лет ломал инфраструктуру и приложения разных компаний в России и за ее пределами. С 2021 года Артем помогает выстраивать защиту Т-Банка в роли архитектора.

Материалы для изучения

Сама научная статья доступна здесь - https://research.google/pubs/secure-by-design-at-google/ Мой разбор - https://tellmeabout.tech/whitepaper-secure-by-design-at-google-de92d6b23390

В этом выпуске мы обсудили следующие темы

Общие впечатления от статьи Логические уязвимости и подходы Google Сложности безопасной разработки Концепция Security by Design Примеры безопасности из автомобильной индустрии Проблемы аудита кода Принципы безопасного дизайна Проблемы с инвариантами Автоматизация и категоризация инвариантов Применение инвариантов Проблемы безопасности в системах Примеры защиты от злонамеренных действий Дизайн для безопасности Shift left everything в разработке Проблемы и решения в безопасности Проект Yaga в Т-Банке Логические уязвимости Безопасная экосистема разработки Проблемы с памятью и микросервисной архитектурой Проблемы с безопасностью и инфраструктурой История о стажере-саботажнике в ByteDance Контроль артефактов и безопасность Экосистема для разработчиков

Это второй выпуск подкаста с разбором научных статей, которые посвящены разным темам computer science и engineering management. В этом выпуске мне помогает мой коллега, Дмитрий Гаевский, Technical CPO (Chief Product Owner) нашей внутренней платформы разработки Spirit.

Для второго выпуска мы взяли научную статью про технический долг и то, как он влияет на продуктивность инженеров. Эта статья от ребят из Google вышла в 2023 году.

Основные материалы

Whitepaper доступен здесь - https://ieeexplore.ieee.org/document/10109339 Мой разбор whitepaper есть в блоге - https://tellmeabout.tech/review-paper-defining-measuring-and-managing-technical-debt-f8c8342ea954

 

Это первый выпуск подкаста с разбором научных статей, которые посвящены разным темам computer science и engineering management. В этом выпуске мне помогает мой коллега, Даниил Кулешов, Staff Engineer,  который развивает вместе со мной в Т-Банке архитектурную функцию на уровне всей компании.

 

Для первого выпуска мы взяли научную статью про governance, а точнее про API governance от ребят из Google, которая вышла в 2024 году. Сама статья достаточно хорошо раскрывает тему governance, что позволяет закрыв глава подставить на место API слово architecture и многие мысли и выводы авторов останутся корректными.

Основные материалы

Whitepaper доступен на Google Research Мой разбор whitepaper есть в блоге Перечень Google стандартов на API доступен здесь