20 записей с тегом "research"

VP of Engineering в компании на 300 человек задал прямой вопрос: «Мы обсуждаем sabbatical-политику. HR говорит, что она бустит retention. Финансы говорят, что это 2 месяца потерянного output на каждого взявшего. Кто прав?» Данные, которые мы смогли вытащить, ответили: оба, но величины эффектов разные. Вернувшиеся разработчики достигают полного output за 4-6 недель (не за 8-12 как часто предполагают), и 90-дневный retention для post-sabbatical инженеров измеримо выше, чем у их pre-sabbatical когорты. Сюрприз — качество коммитов на ramp-up неделях выше baseline, не ниже.

Employee Benefits Survey 2023 от SHRM показывает: 22% работодателей в США теперь предлагают формальные sabbatical-программы, против 13% в 2018. Среди техкомпаний цифра прыгает до ~34% — частично конкуренция за retention, частично постпандемийный разбор burnout'а. Но большинство опубликованных данных по ROI sabbatical идут из self-report опросов. Наша IDE-телеметрия даёт то, что опросы не могут: что реально происходит на клавиатуре неделя-за-неделей, когда человек возвращается.

Спросите 100 инженеров про rubber duck debugging — 98 кивнут с видом знающих. Спросите доказательства, что это работает, и большинство сошлётся на The Pragmatic Programmer (1999). Мы можем лучше, чем 26-летний фольклор. На 2100 debugging-сессиях, которые мы инструментировали в 2025-м, инженеры, которые вербализовали баг коллеге, неодушевлённому предмету или диктофону, решали его за 31 минуту медианы — против 48 минут при silent debugging. Сокращение на 35%. Психология называет это self-explanation effect (Chi et al., 1989), и у него 30+ лет репликаций в педагогическом исследовании.

Но эффект не равномерен по типам багов. Для некоторых классов вербализация помогает 42% случаев и не помогает 58%. В статье — что говорит наша IDE-дата о том, когда уточка отрабатывает, а когда — ритуал под видом техники.

Команды с 2 днями без митингов в неделю показывают медиану 2ч 34м ежедневного coding-time — против 1ч 12м у команд без политики. Это +114%, замеренное через IDE heartbeat-телеметрию по 100+ B2B-компаниям нашего датасета. Тот же анализ обнаруживает менее маркетабельное: прирост выходит на плато на 2 днях. Команды с 3 meeting-free-днями не видят значимо больше coding-time, чем команды с 2. Третий день создаёт coordination-долг, компенсирующий focus-выгоду.

Meeting-free-дни — самое популярное focus-time-вмешательство 2020-2026. Раскатка Shopify в 2023 «no-meeting Wednesdays» широко скопирована; исследование MIT Sloan 2024 сообщает, что 39% опрошенных tech-компаний имеют какую-то форму meeting-free-политики. Чего в этих отчётах нет: behavioral-данных на уровне IDE, показывающих, что реально меняется при удалении митингов. Эта статья — есть.

Техника Pomodoro предписывает работать 25 минут, 5 — перерыв, повторить. Франческо Чирилло придумал её в конце 1980-х для учёбы. Не для кода. Не для flow-работы, которой занимаются инженеры. Мы сравнили IDE heartbeat-паттерны инженеров, называющих себя пользователями Pomodoro, и тех, кто его игнорирует. Результаты для метода неудобные: строгие пользователи 25/5 Pomodoro в среднем кодили по-настоящему 42 минуты в день. Инженеры, игнорирующие таймер, — 2 часа 12 минут. Для большинства таймер был планово-прерывающей машиной.

Это не статья против Pomodoro. Это data-driven взгляд на то, почему 25 минут — неправильный интервал для кода, и какие интервалы совпадают с тем, как инженеры текут. Cal Newport в Deep Work уже аргументировал это концептуально. Что добавим мы — телеметрия: IDE-данные показывают конкретные breakpoints, где coding-сессии восстанавливаются или не восстанавливаются после прерывания. Формат Pomodoro прерывает ровно не в то место.

Один AI-агент — Cursor Composer, Claude Code, GPT-4 с тулами — решает примерно 38% задач SWE-Bench Verified. Поставьте рядом critic-агента, и число вырастает до 62%. Swarm из трёх (planner + coder + critic) бьёт 71%. Swarm из семи падает обратно до 54%. Форма кривой воспроизводится по пяти публичным бенчмаркам, которые мы просмотрели: больше агентов помогает, пока не перестаёт.

Этот пост — взгляд на реальные данные о мульти-агентных workflow для разработки: что работает, что разваливается и что это значит для того, как разработчики должны использовать агент-swarms в 2026. Наша позиция уже хайпа: swarms реальны, прирост реален, failure mode тоже реален и предсказуем.

Распределённая команда с 5 часами разницы в тайм-зонах имеет медианный lead time 6.8 дней на изменение. Локализованная команда на той же кодовой базе — тот же язык, тот же размер, тот же размер PR — имеет медианный lead time 3.2 дня. Это не погрешность. Это timezone-налог, и он примерно удваивается на каждые дополнительные 3-4 часа разницы. GitLab Remote Work Report 2023 назвал «3-5 часов overlap» sweet spot'ом для async-команд, и наши IDE-heartbeat данные по 100+ B2B-компаниям говорят то же — с дополнительной детализацией, куда именно уходит время.

Это не статья о том, хороша ли удалёнка (да, для многих команд). Это про конкретные механизмы, которыми разница тайм-зон замедляет доставку, и про измерения, которые скажут, платит ли ваша распределённая команда 2×-штраф по lead-time или научилась с ним жить.

Две инженерные организации одинакового размера шипят одним темпом. Организация A: у каждого файла есть владелец, PR требуют его аппрува. Организация B: любой может смержить любую часть кода после peer review. У A на 40% меньше багов на KLOC. B восстанавливается после ухода senior-инженера в 3× быстрее. Microsoft Research (Bird et al., 2011, Don't Touch My Code) провели этот эксперимент на 3000+ файлах в Windows Vista/7 и показали: файлы с чётким владельцем имеют значительно меньше post-release отказов — но также чаще становятся бутылочным горлом.

Эта статья сравнивает три реальные модели владения — strong, collective, hybrid — по данным Microsoft, Google 2018 по code review и 100+ компаниям из нашего IDE-датасета. Цель — выбрать модель под этап и работу команды, а не ту, что была в блогпосте на прошлой неделе.

Медианный срок работы инженера в B2B-компании — 2.3 года (Stack Overflow Developer Survey 2025). Медианная неожиданность менеджера этого инженера при увольнении — тоже высокая. Мы сопоставили IDE heartbeat, Git-активность и сигналы из таск-трекера с 43 подтверждёнными увольнениями в 11 командах клиентов PanDev Metrics за 2025. Семь поведенческих паттернов проявились в данных за 30-90 дней до письма об увольнении.

Один из них почти никогда не попадает в стандартный список "сигналов выгорания". Из-за него этот пост и существует.

Copilot написал 420 тестов для модуля платежей за два дня. Coverage прыгнул с 58% до 84%. Уверенность в релизе? Без изменений, а то и хуже. Исследование 2024 IEEE (An Empirical Study on the Usage of Transformer Models for Code Completion, Ciniselli et al.) показало: LLM-сгенерированные тесты компилируются в 92% случаев, но ловят лишь 58-62% инъектированных мутаций — стандартный исследовательский тест на «этот тест вообще что-то проверяет». Человеческие тесты в том же исследовании — 78%. Разрыв ~20 процентных пунктов в mutation score — реальная история качества AI-тестов, а не цифра coverage, которую все репортят.

Эта статья измеряет, в чём AI-тесты хороши, что они пропускают, и как выстроить pipeline, чтобы AI давал throughput, не разъедая уверенность в релизе.

Рынок 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-зрелости" команды.