What your CEO must know about AI (Рубрика #AI)

Посмотрел интересное выступление Хьюберта Мистела, Senior AI Researcher в компании Novartis. Хьюберт руководит командой исследователей искусственного интеллекта в области разработки лекарств, а также преподает машинное обучение и науку о данных в Dublin Business School. Это выступление состоялось на конференции AI Engineer World's Fair 2025 — крупнейшем техническом ИИ-событии года, которое прошло 3-5 июня 2025 года в Сан-Франциско. Ниже представлены ключевые идеи выступления в моей интерпретации

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

2. Трансформация рабочих процессов
Агентные рабочие процессы — главное отличие от традиционной автоматизации. Если раньше машинное обучение могло автоматизировать отдельные шаги, то ИИ-агенты способны:
- Автоматизировать и делегировать несколько шагов одновременно
- Действовать как связующее звено между задачами
- Работать без человеческого вмешательства, запрашивая обратную связь только при необходимости

Дальше автор размышляет об архетипах сотрудников, среди которых он выделяет следующих
- Молчаливые исполнители — низкая коммуникация, высокая производительность
- Индивидуальные исполнители — сбалансированный профиль
- Связующие звенья — соединяют разные команды
- Умножители — усиливают работу других участников команды
- Центры знаний — предоставляют экспертизу

3. Новая реальность рынка труда
Доменные знания и интеллект становятся дешевыми и легкодоступными, а это значит, что
- Компаниям и сотрудникам стоит стремиться к мультидисциплинарным знаниям
- Появятся новые роли: "майнеры рабочих процессов", "люди-оркестраторы ИИ"
- ИИ ускоряет "деятелей" — разница в производительности может достигать не 10x, а 100x (похоже на отсылку к 10x инженерам)

4. Демократизация создания агентов
Критически важно дать возможность сотрудникам самостоятельно создавать агентов с помощью no-code/low-code инструментов, для этого нужно следующее
- Когнитивная самоосознанность — понимание собственных мыслительных процессов
- Способность переводить ментальные шаги в конкретные инструкции
- Доступ к инструментам быстрого создания агентов

5. Этические вопросы
Есть два критических вопроса, которые надо решить для дальнейшего распространения агентов:
- Готовы ли мы не просто делегировать задачи, а позволить ИИ-агентам управлять процессами?
- Какие ценности заложить в агентов и как разрешать конфликты между человеком и ИИ?

6. Практические рекомендации для руководителей
- Аудит стратегии: если ваша AI-стратегия остается актуальной при замене "AI-агент" на "ML" — она устарела
- Картирование рабочих процессов: детальное понимание workflows критично для получения максимальной выгоды
- Готовность к трансформации: организационная структура компании может кардинально измениться
- Инвестиции в контекст: контекст становится новой нефтью, важнее самих данных

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

#AI #ML #Software #Engineering #Development #Agents #Architecture

Интервью с Максимом Евдокимовым про современных CPO, крутые продукты и сложные решения (Рубрика #Management)

Посмотрел с большим интересом интервью с Максимом Евдокимовым, бышим коллегой, который когда-то был CPO в Т-Банке, CPO в hh.ru, большим директором в Сбере, гендиром Okko, а сейчас занимает должность CPMO (Chief Product and Marketing Officer) в Bir Bank, крупнейшем розничном банке Азербайджана. Ниже я выделил основные моменты интервью с моей точки зрения

1. Начало карьеры и опыт в телекоме
Максим рассказал о своем первом заработке в качестве дворника еще в школьные годы. Профессионально он начал работать в 1995 году в торговой компании, для работы хватило знания английского языка и компьютера. Позже, в 2001 году, он попал в финскую компанию Sonera, что стало началом его карьеры в телекоме. По словам Максима, телеком-компании в начале 2000-х были главными драйверами развития цифровых технологий, хотя тогда еще не существовало многих современных терминов и фреймворков. Работа в Мегафоне научила его фокусироваться на клиенте и его потребностях, а также формировать пользовательскую потребность, а не просто отвечать на существующие запросы. Интересно, что сейчас телеком компании - это скорее консерваторы:)
2. Опыт в Тинькофф Банке
В Тинькофф Банк (ныне Т-Банк) Максим пришел в 2013 году после 12 лет работы в телекоме. Первым его проектом был "Тинькофф Wallet" — мобильный кошелек с входом по номеру телефона, который был запущен в декабре 2013 года. Из-за регуляторных изменений проект пришлось трансформировать, и Максим перешел к управлению клиентской частью мобильной платформы банка. Одним из значимых достижений Максима в Тинькофф было внедрение концепции лайфстайл-банкинга и запуск сторис в банковском приложении. Тинькофф стал первым банком на европейском рынке, использовавшим формат сторис для персонализированных предложений клиентам.
3. Продуктовый подход и управление
Максим поделился своим видением продуктового подхода, который он называет "продакт-менеджмент от Евдокимова". Его ключевой принцип: лучше сделать продукт на "твердую четверку" и потом довести до "пятерки", чем выпустить "тройку с минусом" и никогда к ней не вернуться. Он выступает против использования термина MVP (Minimum Viable Product) и предпочитает концепцию MLP (Minimum Lovable Product) — ограниченного, но очень хорошего продукта. По его мнению, для крупной компании неприемлемо делать некачественные продукты, так как это создает репутационные и конкурентные риски.
4. Текущая роль в Bir Bank
В Bir Bank Максим отвечает за продукты и маркетинг. Он рассказал о двух основных задачах в своей текущей роли:
- Построение эффективных продуктовых процессов, так как банк переживает "болезнь роста"
- Развитие экосистемной повестки, чтобы клиенты банка могли увидеть ценностное предложение от других активов экосистемы
По оценке Евдокимова, финтех и банкинг в Азербайджане отстают от российского рынка примерно на 5-7 лет, но в некоторых аспектах, например, в цифровом правительстве и связке бизнеса с государством, некоторые вещи сделаны даже лучше.
5. Ключевые выводы и идеи
Максим подчеркивает важность "ownership" (чувства собственности) в продуктовых командах. По его мнению, идеальная команда — это единомышленники, где каждый отвечает за весь продукт, а не только за свою зону ответственности. Он считает, что в организации нужно развивать культуру доверия и ответственности, чтобы люди могли проявлять инициативу. Причины неудач в продуктовом подходе часто кроются в головах менеджмента, включая акционеров. Для разных стадий развития организации нужны разные управленческие лидеры, и важно вовремя принимать решения о смене руководства.

В общем, подкаст получился достаточно интересным:)

#ProductManagement #Management #Leadership #Software #Engineering #Career

[1/3] What's DAT? Three Case Studies of Measuring Software Development Productivity at Meta With Diff Authoring Time (Рубрика #Productivity)

На эту интересную статью 2025 года от компании "Meta" я наткнулся во время подготовки обзора статьи "Enabling the Study of Software Development Behavior With Cross-Tool Logs" (мой обзор: 1, 2 и 3). И хоть деятельность организации "Meta" запрещена на территории РФ, но читать их инженерный whitepaper достаточно интересно. Основная идея этого исследования - это измерение продуктивности разработки софта через метрику Diff Authoring Time (DAT), которая представляет собой активное время разработчика на создание изменений в коде (диффов), которые по сути своей напоминают MR (merge requests). Это время собирается при помощи системы телеметрии, интегрированной с системой контроля версий, IDE и операционной системой .

Ключевая ценность этого исследования для Meta это
- Переход от интуитивных оценок к научному подходу измерения продуктивности на основе DAT
- Измерения DAT направлены не на оценку performance конкретных разработчиков, а на оценку эффекта инструментов и процессов на продуктивность
- Этот подход дает возможность проведения a/b экспериментов изменения тулинга и процессов - по утверждению авторов они уже ее обкатали на 20 проектах, про три из которых они рассказывают в статье
- Важно, что часть экспериментов можно катать с гранулярностью на уровне diffs (эксперименты, что прозрачны для инженеров), а часть на уровне когорт инженеров (те, где изменения явно видны и не позволяют менять подход для разных diffs - например, переключение между версиями IDE)

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

Если говорить про струткру модели, то она состоит из следующих частей
1. Основной алгоритм точного сопоставления
Отслеживание активности в IDE: Система фиксирует время работы в интегрированной среде разработки
Интеграция с системой контроля версий: Связывает временные сессии с конкретными коммитами через Sapling (система контроля версий Meta)
Алгоритм сдвига влево: Каждый коммит CHx приписывается к IDE-сессии s(x-1), которая предшествует ему
2. Дополнительные эвристики
Anchor Sessions: Захватывает активность, предшествующую точному совпадению, для более полного покрытия времени разработки
Обработка крайних случаев: Автоматическое исключение checkout'ов и фильтрация нерелевантной активности
3. Система телеметрии с защитой приватности
OS-уровневая телеметрия: Отслеживание активности на уровне операционной системы
Интеграция с инструментами: Плагины для VS Code, Sapling и других инструментов разработки
Неперекрывающиеся измерения: DAT гарантирует, что время между различными диффами не пересекается для одного разработчика

В итоге, мы получаем следующие ключевые свойства модели
- Неперекрываемость: DAT(D123) ∩ DAT(D987) = ∅ для одного пользователя, где D123 и D987 - это два разных diffs
- Ограниченность: DAT не может превышать 24 часа в день
- Агрегируемость: В отличие от других метрик, DAT можно корректно суммировать

Продолжение обзора в следующем посте.

#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes

7 Habits of Highly Effective Generative AI Evaluations (Рубрика #AI)

Посмотрел на выходных интересное выступление про evaluations от Джастина Мюллера, Principal Applied AI Architect в Amazon Web Services (AWS). Команда Мюллера в AWS помогает клиентам масштабировать рабочие нагрузки с генеративным ИИ, и за время работы он имел возможность изучить более 100 различных попыток создания фреймворков оценки работы моделей. Это выступление прошло недавно в рамках конференции AI Engineer World's Fair. Ключевой идеей выступление было то, что основная проблема при масштабировани genAI решений в недостаточности оценок (evaluations) качества их работы. Несмотря на то, что многие называют основными проблемами стоимость, галлюцинации, точность и производительность, именно отсутствие подходящих evaluation фреймворков чаще всего препятствует успешному внедрению. Для демонстрации этой идеи Джастин рассказал реальный кейс клиента с проектом обработки документов, где точность составляла всего 22%. После внедрения системы оценки за 6 месяцев удалось достичь 92% точности и запустить проект в массовое производство, сделав его крупнейшим на тот момент по обработке документов на AWS в Северной Америке. Для решения этой проблемы с эффективной оценкой моделей автор предлагает следующие семь привычек высокоэффективных людей высокоэффективных genAI evaluations:

1. Скорость выполения (Fast)
- Целевое время выполнения оценки — 30 секунд
- Возможность делать сотни изменений и тестов ежедневно вместо 4-8 в месяц
2. Количественно измеримый (Quantifiable)
- Оценка должна выражаться в конкретных числовых показателях
- Стоит применять усреднение по множественным тест-кейсам для устранения случайных колебаний
3. Объяснимость (Explainable)
- Анализ не только результатов, но и процесса рассуждений модели
- Важность понимания логики как генерирующей модели, так и оценивающей модели
4. Сегментированность (Segmented)
- Разбиение сложных промптов на последовательность простых шагов
- Возможность оценки каждого этапа отдельно и выбора подходящей модели для каждой задачи
5. Разнообразие (Diverse)
- Покрытие всех сценариев использования
- Эмпирическое правило: ~100 тестовых примеров для основных случаев использования
6. Традиционность (Traditional)
- Сохранение использования проверенных методов оценки (из ML)
- Численные оценки, метрики точности баз данных, измерение стоимости и задержки остаются актуальными
7. Золотые стандарты
- Критическая важность создания качественного набора золотых стандартов
- Избегание использования генеративного ИИ для создания золотых стандартов во избежание воспроизведения ошибок

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

В общем, выступления Мюллера - это сборник практических советов о том, как стоит организовывать свой фреймворк оценки GenAI моделей. Эти советы звучат логично, выглядят доступно, а также проверены на опыте работы с крупнейшими рабочими нагрузками в Северной Америке.

Выступление в Вышке перед студентами ФКН (Рубрика #SystemDesign)

Меня позвали поговорить со студентами про System Design и я не смог отказаться. В итоге, сегодня буду рассказывать истории про то
- Как сейчас выглядят процессы разработки внутри компании - со сложными и большими системами и децентрализацией принятия технических решений
- Как мы набираем людей и зачем нам System Design Interview
- Как дальше выглядят процессы после трудоустройства - расскажу про RFC/ADR, ревью архитектуры, общие инженерные вопросы типа reliability, security и так далее и что не всегда все при проектировании выглядит так просто, как на System Design Interview

А в конце я еще планировал поотвечать на вопросы ребят.

P.S.
До этого я уже рассказывал про процессы найма в большие компании и типы интервью на примере Т-Банка. Про System Design у меня тоже было много материалов. Например можно посмотреть в общем про system design в Tinkoff, больше про то, как мы оцениваем прохождение собеседования и как подготовиться к собеседованию или публичные интервью на ArchDays

#Career #HR #Management #Architecture #Software #Leadership #Processes

[2/3] What's DAT? Three Case Studies of Measuring Software Development Productivity at Meta With Diff Authoring Time (Рубрика #Productivity)

Продолжая рассказ про этот whitepaper от Meta, чья деятельность запрещена на территории РФ, перейдем к валидации подходом с использованием DAT (Diff Authoring Time). Для этого авторы прповели дополнительные исследования

1. Исследование пользовательского опыта
- Создали ground truth датасет через запись реальной работы разработчиков
- Использовали случайную выборку для минимизации предвзятости
- Получили среднюю точность DAT более 90% по сравнению с реальными данными

2. Крупномасштабный опрос
- Сравнили DAT с оценками разработчиков (968 уникальных диффов)
- Встроили опросы в инструмент Phabricator, который используется для код ревью. Опрос стартует сразу после завершения диффа
3. Дескриптивная статистика
- DAT покрывает 87% всех подходящих диффов
- DAT оказалось стабильной метрикой (использовался 99-го перцентиль winsorized mean для отчетности)
- Авторы отвалидировали DAT, проведя сравнение с метрикой Time Spent by Diff, которая определяется как "averages coding time in a given period by the number of diffs published in that period"
4. Визуализация временных рядов
- Сделали детальную визуализацию того, как сырая телеметрия преобразуется в DAT (изображение будет в финальном посте)
- Сделали кросс-валидацию с авторами изменений (с самими разработчиками)

Дальше авторы рассказывают про 3 конкретных эксперимента, которые они проводили

1. Типизированное мокирование в Hack
Суть эксперимента в том, чтобы внедрить типизацию в инструменты мокирования внутри Hack (внутренняя версия доработанного PHP). Для эксперимента авторы мигрировали часть моков на типы, а часть оставили как есть и дальше сравнили DAT при создании diffs в разных частях кодовой базы. Эксперимент показал как языковые возможности с конкретными показателями продуктивности
- 14% улучшение DAT: Первое количественное доказательство влияния типизации на продуктивность в промышленной среде
- Статистическая значимость: p < 0.001 для всех размеров диффов

2. Авто-мемоизация в React компайлере
Авторы дорабатывали фреймворк React для авто-мемоизации и дальше провели эксперимент, где сравнили DAT при создании diffs с ручной и автоматической мемоизацией.
- Они использовали смешанную модель эффектов для учета конфаундеров через регрессионную модель
- Для нерандомизированных данных они использовали Wasserstein distance для измерений истинной разницы между граппуми
- 33% улучшение DAT: Значительное повышение эффективности при использовании автоматической мемоизации

3. Анализ эффективности от переиспользования кода
Это исследование мне показалось самым интересным, так как авторы оценивали эффект применения кросс-платформенных технологий (у ребя это был React). Правда, для анализа пришлось использовать контрфактический анализ для оценки гипотетического времени разработки без переиспользования кода. На выходе получилось, что
- Кроссплатформа дает больше, чем 50% улучшение относительно разработки без переиспользования
- А это тысячи часов ежегодной экономии DAT через фреймворки переиспользования кода

В итоге, этот подход к использованию метрики DAT привел к следующим эффектам
- Переход Infrastructure команд к культуре, ориентированной на a/b эксперименты
- Принятие решений на основе данных - DAT используется для планирования и приоритизации разработки
- DAT и эксперименты выравняли подходов между продуктовыми и инфраструктурными командами

Если говорить про дальнейшие планы авторов исследования, то они планируют расширение
- Горизонтально - добавление кроме diffs и других артефактов разработки (documents and tasks). Это позволит создать общий фреймворка измерения времени активностей для экспериментов
- Вертикально - поддержка большего количества инструментов (разных IDEs и других инструментов). Это позволит меньше ориентироваться на эвристики и больше на точные измерения.

#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes