Explorez tous les épisodes du podcast Research Insights Made Simple

Агенты пишут всё больше кода, сотрудники собирают инструменты для управления ими, а доля джунов в техническом найме снижается. Anthropic выпустила исследование о том, как AI меняет работу внутри самой компании. И один из самых интересных вопросов здесь — что происходит с человеком, когда исполнение задач становится всё дешевле, а его внимание остаётся ограниченным.

В выпуске разберу "How employment is changing at Anthropic" и продолжу разговор, который мы начали в Developer Productivity for Humans: как понять, что рост активности помогает людям получать полезный результат?

Сначала посмотрим на саму статью:

• что авторы узнали о найме, продуктивности, рабочих процессах и изменении ролей;
• как устроено исследование: внутренние данные, интервью и сравнение сотрудников до и после внедрения агентов;
• что показывают графики агентских часов, объёма кода и качества — и какие выводы из них делать рано;
• почему возникает всё больше работы по организации работы агентов и куда уходит человеческое внимание.

А дальше вернусь к вопросам из моих пометок на полях. Как устроить рабочий цикл, чтобы не проверять вручную каждый шаг агента? Где будущий самостоятельный инженер получит опыт, если простые задачи уже автоматизированы? И на каких условиях сотруднику выгодно автоматизировать собственную работу — что он получает взамен и есть ли для него следующая роль?

Это исследование одной быстро растущей компании, которая сама создаёт AI. Его данные интересны именно в деталях; переносить их на весь рынок труда будем осторожно.

Приходите с вопросами и примерами из своих команд. Особенно интересно, какая работа появилась у вас после внедрения агентов, хотя её не было в первоначальном обещании «сэкономить время».

Предыдущие разговоры:

1. Developer Productivity for Humans — выпуск #30
2. AI-native компания — что это значит на практике
3. Джун без простых задач — как входить в IT в эпоху AI

Агенты пишут код, а инфраструктура разработки начинает захлёбываться. В Anthropic дошли до собственной системы контроля версий — Scion. И агенты же помогли её построить.

15 октября 2026 года в сольном выпуске Research Insights Made Simple #39 разберу «Redesigning source control at Anthropic». Это инженерный отчёт команды о том, как меняется работа с кодом, когда основными клиентами репозитория становятся постоянно подключённые агенты и CI.

Меня здесь особенно интересуют две вещи: знакомые идеи баз данных в устройстве Scion и изменение гарантий вокруг merge. Что мы выигрываем, если быстрее принимаем изменения в общую историю? И что после этого обязаны проверить до деплоя?

В выпуске:

• почему Anthropic перенесла операции с историей, merge и rebase на сервер;
• как устроены журнал изменений, производные структуры чтения и кеширование неизменяемых объектов;
• что именно ускорилось на итоговом графике и почему эти числа нельзя переносить на всю разработку;
• какие гарантии меняются при переходе к post-merge проверкам и как связать допуск к релизу с конкретным проверенным артефактом;
• как дать агенту стабильную базу и при этом раньше замечать конфликты с движущимся main.

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

Автор и ведущий — Александр Поломодов.

• Статья Anthropic: https://www.anthropic.com/engineering/redesigning-source-control
• Все выпуски Research Insights Made Simple: https://polomodov.tech/research-insights/

Timeline
00:00 - Зачем Anthropic своя система контроля версий
03:40 - Рост нагрузки от агентов и CI
04:34 - Онлайн-клиенты и серверные операции
07:10 - Запрос API вместо скачивания репозитория
08:52 - Changeset, Spanner и производные данные
12:37 - Ссылки и кеши неизменяемых объектов
15:26 - Что означает мгновенная доступность
17:34 - Как читать график ускорений
18:21 - Миграция, люди и архитектурные ограничения
20:25 - Ревью намерений и роль инженеров
21:49 - Агенты для наблюдения за компонентами
23:00 - Проверки после слияния и до развёртывания
25:51 - Конфликты поведения и открытые вопросы
27:07 - Границы применимости Scion
30:20 - Что остаётся узнать о полном цикле разработки

В очередном эпизоде из серии об обвязках агентов Research Insights Made Simple поговорим про опубликованное в сентябре 2026 года исследование "An Empirical Study of Harness Design for Coding Agents" (https://arxiv.org/abs/2609.20804v1). Авторы фиксируют цикл агента и меняют три компонента: планирование, инструменты и управление контекстом. Они сравнивают 176 экспериментальных настроек на четырёх моделях и двух наборах задач — SWE-bench Verified и Terminal-Bench 2.1.

Обсудим

• Когда управление контекстом спасает задачу от переполнения окна.
• Почему сокращение старых ответов инструментов перед пересказом может снизить стоимость.
• Как план помогает слабой модели продолжать работу, а сильной — вовремя остановиться.
• Когда нужны готовые инструменты, а когда достаточно bash.
• Как по траектории агента найти причину сбоя и проверить пользу изменения на своих задачах.

Выводы относятся к моделям, задачам и реализациям из исследования. Разберём, что стоит проверить перед переносом этих результатов в собственную систему.

Все выпуски Research Insights Made Simple: https://polomodov.tech/research-insights

Timeline
00:00 - Зачем разбирать обвязку на компоненты
02:07 - Общий цикл и три переменные эксперимента
03:19 - 176 настроек и неполный перебор сочетаний
04:40 - Модели, задачи и расчёт стоимости
07:52 - План вне истории разговора
09:47 - Готовые инструменты и bash
11:33 - Пять политик управления контекстом
13:51 - Что сохраняют и когда сокращают историю
15:43 - Предотвращённый обрыв и стоимость контекста
19:03 - Почему редко возвращают вытеснённые события
20:55 - План меняет момент остановки
24:27 - Инструменты: результат зависит от модели и задач
29:21 - Менять компоненты по одному
33:24 - Анализ траекторий и причины сбоев
40:09 - Выводы, ограничения бенчмарка и свои эксперименты

12 октября в Research Insights Made Simple снова встречаемся с Колей Головым и продолжаем разговор про платформы данных. В этот раз разберём, как объединить операционные базы, аналитику и AI-агентов и можно ли при этом избавиться от привычного зоопарка интеграций.

Николай Голов - директор по продукту одной из датаплатформ, доступных на российском рынке. Раньше он руководил дата-платформами в Avito и ManyChat, преподаёт базы данных и системы хранения в Harbour.Space (https://harbour.space/faculty/Nikolay-Golov). Так что обсудим и устройство технологий, и практику построения платформ, которые потом кому-то поддерживать.

На картинке всё выглядит заманчиво: оставляем PostgreSQL для транзакций, изменения из остальных систем отправляем через CDC в объектное хранилище, сверху ставим Lakehouse и подключаем агентов через MCP. Данные собраны, инструменты доступны, можно задавать вопросы. Правда, между «сложили всё в S3» и «агент правильно понял бизнес» ещё помещается довольно много инженерной работы :)

Посмотрим, как к этой задаче подходят Databricks, Snowflake, ClickHouse, Microsoft Fabric, Google, AWS и Oracle. У кого-то объединение происходит на уровне хранения, у кого-то через репликацию и общие запросы, а кто-то собирает всё внутри одной СУБД. За похожими словами про единую платформу скрываются разные архитектуры и разные ограничения.

Поговорим о том

• Где проходят границы между OLTP, аналитикой и агентным бэкендом;
• Что на практике означают «одна копия данных» и zero-ETL;
• Когда CDC и Lakehouse упрощают жизнь, а когда добавляют ещё одну систему, за которой надо следить;
• Какую роль могут играть PostgreSQL, DuckLake и S3 в собственной платформе;
• Что нужно агенту помимо доступа к таблицам: определения показателей, права, контекст и возможность проверить результат.

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

Timeline
00:00 - Данные организации для AI-агента
02:47 - Четыре подхода вместо одного правильного решения
05:16 - Классическое хранилище и подготовленные витрины
08:45 - CDC, ETL и размер компании
11:15 - Федеративные запросы: Presto и Trino
16:17 - Универсальная СУБД и ограничения HTAP
18:23 - Единый слой хранения и текущее состояние таблиц
26:09 - Microsoft и AWS: передача изменений
34:51 - ClickHouse: федеративный доступ и репликация
40:04 - Google: операционные базы, BigQuery и стоимость
47:34 - Oracle и SAP HANA: нагрузки внутри одной СУБД
53:56 - Databricks: Neon, Mooncake и общий слой
1:00:17 - Snowflake и PostgreSQL
1:02:25 - Сравнение подходов и пределы общего хранения
1:07:42 - Собственная платформа и открытые форматы

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

Продолжаем серию про инженерную обвязку агентов. И здесь мы разберём статью Anthropic Harness design for long-running application development. Её автор экспериментирует с разделением планирования, разработки и оценки результата.

В прямом эфире обсудим:
- Как устроены роли planner, generator и evaluator.
- Зачем до написания кода согласовывать критерии готовности и как проверять работающее приложение.
- Можно ли формализовать вкус при оценке дизайна и насколько надёжен отдельный агент-критик.
- Сколько стоят дополнительные итерации и что показывают приведённые сравнения.
- Почему с усилением моделей некоторые части обвязки становятся лишними.

А в конце поговорим о следующем шаге: сможет ли агент сам улучшать собственный harness — и кто тогда будет проверять эти улучшения?

Timeline
00:00 - Четвёртый разбор обвязок: приложения по одному запросу
01:33 - Две задачи Anthropic Labs
03:04 - Идея из GAN: отдельный критик
06:22 - Предел контекста и снисходительная самооценка
08:10 - Сжатие, сброс и стоимость передачи работы
12:40 - Четыре критерия качества дизайна
15:00 - Итерации фронтенда и выбор варианта
17:16 - Планировщик, генератор и оценщик
18:39 - Контракт спринта до реализации
20:32 - Ретро-игры: двадцать минут против шести часов
23:40 - Почему проверяющему нужна настройка
25:43 - Opus 4.6: проверка и упрощение компонентов
30:46 - Звуковая станция и оценщик, который не слышит
34:41 - Автономность и внешний контроль риска
38:56 - Журнал событий и дальнейшая эволюция обвязки

В четверг, 8 октября, в прямом эфире разберу статью OpenAI «Harness engineering: leveraging Codex in an agent-first world» ( https://openai.com/index/harness-engineering/ )

В предыдущем выпуске (https://www.youtube.com/watch?v=qVXELX0j6dY) говорили о передаче работы между сессиями агента. Теперь посмотрим на всю среду разработки: как устроить репозиторий, знания, инструменты и проверки, чтобы агент мог самостоятельно двигать проект вперёд.

Обсудим:

• Как меняется работа инженера, когда код пишет агент.
• Зачем агенту видеть приложение, логи и результаты проверок.
• Как сохранять архитектурные ограничения и качество кода.
• Что можно перенести из опыта OpenAI в свою команду и как проверить пользу этих изменений.

Статья описывает опыт одной команды. Отдельно поговорим о границах её выводов и о том, какие данные нужны для оценки результата.

Timeline
00:00 - От интерфейса агента к среде разработки
01:41 - Запрет писать код руками как метод
04:25 - Пять месяцев, команда и результаты кейса
06:43 - Сбой агента требует изменения среды
07:56 - Внимание инженеров, DevTools и рабочие деревья Git
10:54 - Наблюдаемость превращает пожелания в проверки
12:04 - Недоступные знания и параллель с новичком
14:45 - AGENTS.md как карта к документам
17:14 - Явная архитектура и линтеры с инструкциями
20:42 - Инварианты на границах и свобода реализации
24:00 - От бага до слияния: автономия и цена ошибки
27:13 - Фоновая очистка вместо пятничного разбора долга
29:53 - Каких доказательств и измерений нет в статье
32:10 - Как проверить механизм на своих задачах
38:58 - Symphony: от управления сессиями к задачам

Агент написал часть приложения, контекст закончился — и следующая сессия начинает разбираться заново. Код сохранился, но замысел, незавершённые изменения и результаты проверок остались в прошлой беседе.

После SWE-agent продолжим серию про обвязки агентов. Разберём статью Anthropic (https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents) о работе через несколько сессий:
- почему сжатия контекста недостаточно;
- зачем нужны список функций, журнал прогресса и история Git;
- как делать небольшие проверяемые шаги;
- что оставлять следующей сессии, чтобы она могла продолжить начатое.

Будет полезно тем, кто строит кодинговых агентов и поручает им задачи, выходящие за одно контекстное окно.

Timeline
00:00 - Зачем передавать работу между сессиями
01:51 - Инженерный опыт Anthropic и проверенная основа
05:09 - Инициализатор и агент-разработчик
07:09 - Почему сжатия контекста недостаточно
09:17 - Много недоделок и преждевременная готовность
14:04 - За что отвечают четыре артефакта
16:22 - Функция как пользовательский сценарий
18:48 - JSON, Markdown и границы запрета в промпте
19:36 - Ориентирование и одна функция за шаг
21:59 - Проверка в браузере и невидимые alert
24:19 - Git и содержательная запись прогресса
28:59 - Что доказано и как проверить обвязку
32:13 - Полный цикл рабочей сессии
33:42 - Как продолжение истории меняет обвязку
38:15 - Как читать статьи с заметками и обсуждать их с LLM

5 октября в 12:00 МСК — прямой эфир Research Insights Made Simple. Сольный выпуск с Александром Поломодовым: разбираем статью «SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering» с NeurIPS 2024.

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

В программе

• Поиск по коду и чтение файлов: как агент находит нужное и сохраняет ориентиры.
• Многострочные правки и проверка синтаксиса: как предотвращать ошибки и восстанавливаться после них.
• Управление контекстом: что показывать модели, что сокращать и что сохранять.
• Результаты SWE-bench и SWE-bench Lite: с чем сравнивают SWE-agent и что показывают абляции.
• Выводы для современных агентов: какие принципы стоит перенести в свою систему, а какие настройки остались частью эксперимента 2024 года.

Timeline
00:00 - Зачем возвращаться к SWE-agent 2024 года
01:05 - SWE-bench: реальные задачи в чужом проекте
03:00 - Зачем модели собственный интерфейс
04:45 - Цикл мысли, действия и наблюдения
06:32 - Как проверяли решения и ограничивали бюджет
08:49 - Результаты на полном SWE-bench
10:01 - Демонстрации и сравнение с обычным shell
10:55 - Поиск файлов и нужных мест в коде
14:30 - Просмотр с номерами строк и команда edit
17:20 - Отклонение правки и обратная связь линтера
20:37 - Абляции: что дают редактирование и проверки
22:19 - Окно просмотра и управление историей
24:54 - Траектории, повторные попытки и пределы модели
29:18 - Как авторы улучшали интерфейс экспериментами
31:47 - Принципы ACI, SWE-smith и mini-SWE-agent

Модель поместилась в 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/

Timeline
00:00 - Почему возвращаемся к статье 2023 года
03:26 - Обработка промпта и генерация токенов
06:09 - Бюджет памяти и цена KV-кеша
11:10 - Резерв и два вида фрагментации
13:36 - Почему даже знание длины ответа не спасает Orca
15:58 - Страничная память: идея из операционных систем
19:42 - PagedAttention и косвенный доступ к блокам
23:36 - Как растущий запрос получает новые блоки
26:11 - Общий префикс и копирование при записи
29:44 - Дерево блоков для beam search
32:21 - Вытеснение: перенос или повторное вычисление
36:01 - Планировщик и рабочие процессы GPU
38:05 - Пропускная способность при той же задержке
39:17 - Цена косвенности и выбор размера блока
41:37 - Инженерные выводы и границы применимости

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

Представим, что сборки стали быстрее, 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 - Первый месяц улучшений и доверие команды

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