21 запись с тегом "research"

Рынок AI-инструментов для кода к началу 2026 года разделился на четырёх серьёзных игроков: GitHub Copilot, Cursor, Claude Code (CLI от Anthropic) и ChatGPT с Code Interpreter. Маркетинг у всех четырёх обещает "+40% продуктивности" — цифра одинаковая и бессмысленная без измерения. Мы подняли данные IDE heartbeat и session у 112 инженеров в 14 B2B-командах за Q1 2026, чтобы посмотреть, что реально экономит время.

Суть: пользователи Claude Code экономят 54 минуты в день; пользователи Copilot — 28. Но распределение не то, на что намекает маркетинг — лучший инструмент зависит от вида работы, а не от "AI-зрелости" команды.

AI-ревью кода сидит на гребне хайп-цикла. GitHub Copilot, CodeRabbit, Qodo, Graphite и ещё полдюжины стартапов продают будущее, где LLM ловят баги быстрее людей. Классическое исследование Microsoft Research и Bacchelli 2013 года задало бейзлайн, с которым мы сравниваемся десять лет: человеческое ревью ловит ~14% функциональных дефектов, но 68% проблем maintainability. Вопрос сегодня: сдвигает ли добавление LLM хоть одну из этих цифр?

Мы вытащили данные по ревью со 100 B2B-команд между Q1 2025 и Q1 2026 — микс команд с AI-ревью, без, и с гибридом. Паттерн не такой, как рассказывают вендоры.

Два разработчика на одну задачу. Удвоенная стоимость труда, вдвое меньше багов, и никто не может договориться, окупается ли это. Самое цитируемое исследование на эту тему — Cockburn & Williams, The Costs and Benefits of Pair Programming (2000) — показало +15% времени при парной работе и −15% дефектов. На бумаге это ничья. В реальности — нет. Математика "баг пойман рано" выводит ROI примерно к 2×, если учесть сэкономленный rework и предотвращённые production-инциденты.

В этой статье мы скрестили академические данные Cockburn-Williams с нашим IDE heartbeat датасетом по 100+ B2B-компаниям — включая команды, которые практикуют pair programming ежедневно, и те, что не используют его вовсе. Не "хорош ли pair programming?", а "когда он окупается, а когда это театр?".

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

Microsoft Research выяснили, что разработчики тратят на код всего 30-40% рабочего времени. Исследование Haystack Analytics 2019 года показало ближе к 2 часам. Наши собственные данные IDE heartbeats по B2B-командам подтверждают медиану в 78 минут в день.

Вот что реально показывают данные и почему это важно.

AI/ML-команды не похожи ни на одну другую инженерную организацию. Половина команды исследует новые подходы, где большинство экспериментов проваливаются — и это ожидаемо. Другая половина строит продакшн-системы, где важны надёжность и скорость. Многие участники делают и то, и другое, переключаясь между Jupyter notebooks и продакшн-кодобазами в течение одного дня. MLOps maturity model описывает этот спектр — от ad hoc экспериментов (Level 0) до полностью автоматизированных ML-пайплайнов (Level 2) — и большинство организаций находятся где-то посередине.

Традиционные инженерные метрики не охватывают эту двойственность. Измерять ML-исследователя по Deployment Frequency — всё равно что измерять повара по скорости мытья посуды. Но полное отсутствие метрик означает, что вы не можете определить, приносят ли исследовательские инвестиции результат и надёжны ли ваши продакшн-системы. Данные Papers with Code показывают, что разрыв между state-of-the-art исследованиями и production-ready ML растёт — что делает мост research-to-production важнее, чем когда-либо.

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

Каждый рейтинг «топ языков программирования», который вы видели, основан на звёздах GitHub, опросах Stack Overflow или вакансиях. Ни один из них не измеряет, на что разработчики реально тратят своё время.

Мы измеряем. Вот рейтинг, основанный на тысячах часов реального времени кодирования в IDE по 200+ языкам программирования, отслеженных у активных B2B-разработчиков в 100+ B2B-компаниях.

Одни разработчики клянутся, что лучшее начало дня — 6 утра с кофе и тишиной. Другие не открывают IDE до 10 вечера. Менеджеры спорят: вводить «core hours» или позволить людям работать когда угодно.

Мы проанализировали обширные данные активности разработчиков из более чем 100 B2B-компаний, чтобы узнать, когда разработчики на самом деле пишут код — и имеет ли значение время суток.

У каждого engineering-менеджера есть интуитивное ощущение недельного ритма команды. Понедельник кажется медленным. Пятница — временем сворачивания. Но что на самом деле показывают данные?

Мы проанализировали тысячи часов кодинга от разработчиков из более чем 100 B2B-компаний, чтобы построить карту продуктивности по дням недели — и результаты ставят под вопрос некоторые распространённые убеждения.

Спор об IDE вечен. Фанаты VS Code говорят, что он быстрый и расширяемый. Приверженцы JetBrains клянутся глубокой языковой поддержкой. А теперь Cursor — новый претендент, оседлавший волну AI. Stack Overflow Developer Survey стабильно ставит VS Code на первое место как самый популярный редактор, в то время как JetBrains Developer Ecosystem Survey показывает высокую лояльность среди своих пользователей. Но опросы измеряют настроения, а не реальность.

Но что разработчики на самом деле используют, когда садятся за работу? Не то, что они пишут в Twitter. Не то, что они отметили звёздочкой на GitHub. То, в чём они пишут код, час за часом, день за днём.

У нас есть данные. Тысячи часов отслеженного времени написания кода в 100+ B2B-компаниях, с разбивкой по IDE.

«Добавление рабочей силы к запаздывающему программному проекту задерживает его ещё больше.» Фред Брукс написал это в 1975 году. Пятьдесят лет спустя руководители инженерных команд всё ещё спорят, правда ли это.

Мы проанализировали реальные данные кодирования из 100+ B2B-компаний на PanDev Metrics, чтобы понять, как размер команды соотносится с индивидуальной продуктивностью разработчика. Ответ оказался более нюансированным, чем предполагал Брукс — но его ключевая идея по-прежнему верна.