[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