Research Insights Made Simple

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

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

Для меня это разговор не о том, заменит ли 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.   А в этом выпуске мы обсудили следующие темы

Разбор отчета 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 мы разбирали саму методологию, а теперь решили поговорить про результаты.

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

Этот выпуск продолжает обсуждение whitepaper "What goes around comes around ... and around" от Michael Stonebraker и Andrew Pavlo про развитие баз данных за последние 20 лет. Здесь мы поговорили о том, как менялись архитектуры баз данных и почему, а также обсудили выводы авторов исследования о будущем баз данных. Разбору статьи помогает мне Алексей Светличный, мой коллега, что руководит развитием отдела баз данных в Т-Банке. Алексей работает с базами данных более 15 лет, где он прошел путь от небольших систем, до крупных Enterprise решений. Сейчас руководит командой, которая разрабатывает DBaaS и развивает экспертизу по базам данных в компании.

За час общения с Лешей мы обсудили вторую половину статьи, куда входили следующие темы

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

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

Выпуск посвящен разбору "Measuring developer productivity with the DX Core 4" от ребят из DX, которые активно развивают тему developer productivity. Для разбора этой статьи ко мне пришел гость, Евгений Сергеев, engineering director в Flo Health.