Разработчики работают не так, как сами считают продуктивным

Мы привыкли обсуждать productivity через результат:

— сколько задач завершили; 
— сколько времени занимает delivery; 
— сколько PR закрыли.

Но в исследовании Time Warp: The Gap Between Developers’ Ideal vs Actual Workweeks in an AI-Driven Era авторы задали другой вопрос:

На что разработчики хотели бы тратить рабочее время — и насколько это отличается от их реальной недели?

В опросе участвовали 484 разработчика Microsoft. Исследователи сравнили фактическое распределение времени с тем, которое сами разработчики считают оптимальным.

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

Это не означает, что любое неприятное занятие нужно немедленно отменить. Поддержка, координация и встречи иногда необходимы.

Но если человек считает важной одну работу, а большую часть недели вынужден делать другую, проблема может быть не в его мотивации. Возможно, система просто расходует его время не там.

Отсюда хороший вопрос для 1:1:

Если бы ты мог перераспределить свою рабочую неделю, чего в ней стало бы меньше, а чего — больше?

Ответ может показать то, чего не видно в отчёте по закрытым задачам:

— слишком много встреч; 
— постоянные переключения контекста; 
— ручные повторяющиеся операции; 
— ожидание решений и доступов; 
— coordination overhead; 
— поддержку, которая незаметно вытеснила основную работу; 
— недостаток времени на проектирование и глубокую работу.

И здесь появляется интересная связь с AI.

Обычно компании выбирают сценарии автоматизации от возможностей инструмента: что модель уже умеет писать, анализировать или генерировать.

Можно развернуть вопрос:

Какую работу люди меньше всего хотят продолжать делать руками?

Тогда приоритетом для AI становятся не самые эффектные демо, а задачи, которые создают наибольший разрыв между реальной и желаемой рабочей неделей.

Не «куда ещё встроить AI».

А «что вернуть людям, убрав из их недели лишнюю механику».

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

«Разработчик ошибся» — это не root cause

Production упал.

Нашли проблемное изменение. Нашли автора. Зафиксировали причину инцидента:

«Разработчик допустил ошибку».

Расследование закончено, можно расходиться.

Только непонятно, зачем тогда вообще нужен postmortem.

Человек действительно мог ошибиться. Но если одной человеческой ошибки достаточно, чтобы положить production, я бы смотрел глубже:

Почему система позволила этой ошибке превратиться в инцидент?

Вместо «Кто виноват?» полезнее задать другие вопросы.

Что произошло?

Нужен timeline: от первого изменения до обнаружения проблемы и восстановления системы.

Почему изменение выглядело безопасным?

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

Какие защиты должны были остановить ошибку?

— тесты;
— review;
— feature flag;
— canary-деплой;
— мониторинг;
— автоматический rollback;
— ограничения доступа.

Почему ни одна из них не сработала?

Как команда обнаружила проблему?

Мониторинг заметил её сам или первым написал пользователь?

Как восстанавливались?

Был ли понятный runbook или решение пришлось собирать по сообщениям, старым тикетам и воспоминаниям коллег?

Blameless-подход не означает, что никто ни за что не отвечает.

Он означает, что команда изучает условия, в которых разумный человек принял решение, приведшее к ошибке.

Иначе каждый postmortem заканчивается одинаково:

— быть внимательнее;
— лучше проверять;
— больше не ошибаться.

Три великолепных action item, которые человечество стабильно не выполняет уже несколько тысяч лет.

Хороший action item меняет систему.

Не «быть внимательнее при деплое», а добавить автоматическую проверку перед deployment.

Не «лучше проверять конфиг», а запретить опасное значение на уровне schema validation.

Не «следить за метрикой», а создать alert с конкретным порогом и понятным получателем.

Цель postmortem не в том, чтобы найти человека, который ошибся.

Цель в том, чтобы такая же ошибка в следующий раз не смогла привести к тем же последствиям.

AI не обесценивает экспертизу. Похоже, он делает её ещё выгоднее

Последние пару лет часто звучит идея: чем лучше становится AI, тем меньшее значение имеет экспертиза разработчика.

Свежие данные Anthropic пока показывают почти обратное.

Исследователи проанализировали около 400 тысяч реальных сессий Claude Code за период с октября 2025-го по апрель 2026-го. В типичной сессии разделение труда выглядит так:

— человек принимает около 70% решений о том, что нужно сделать;
— Claude принимает около 80% решений о том, как это сделать.

То есть AI уже хорошо забирает исполнение. Но постановка задачи, выбор подхода и определение критериев готовности пока в основном остаются за человеком.

Ещё интереснее связь с предметной экспертизой.

Чем лучше пользователь разбирается в задаче, тем больше работы агент выполняет после одной инструкции. В сессиях новичков один запрос запускал в среднем около пяти действий Claude, а в экспертных — около двенадцати.

Эксперты точнее формулируют задачу, задают осмысленные проверки и замечают, когда агент идёт не туда. А если что-то ломается, чаще возвращают работу на правильный путь.

Важная оговорка: основной прирост исследователи увидели между новичками и пользователями со средним уровнем знаний. Разрыв между уверенным специалистом и глубоким экспертом уже заметно меньше.

Для тимлида здесь важен сам сдвиг.

Раньше senior отличался прежде всего способностью самостоятельно решить сложную задачу. Теперь всё большую ценность получает способность правильно определить задачу, задать ограничения и направить исполнение.

Не обязательно самому писать каждую строчку.

Но нужно понимать, какую систему мы строим, где она может сломаться и чем доказать, что результат действительно работает.

Возможно, AI не уменьшает разрыв между junior и senior.

Он просто переносит этот разрыв с написания кода на качество решений.

Исследование Anthropic: Agentic coding and persistent returns to expertise

Adaptive Management System: управлять не по плану, а по обратной связи

Обычная система управления предполагает, что мы можем заранее определить цель, составить план и затем контролировать его выполнение.

Проблема в том, что среда меняется быстрее, чем обновляется план.

Появляются новые ограничения. Меняются приоритеты. Гипотезы не подтверждаются. Команда узнаёт о продукте и системе то, чего не могла знать в начале квартала.

Но план продолжает жить, как будто ничего не произошло.

В результате управление превращается в попытку заставить реальность соответствовать старым договорённостям.

Под Adaptive Management System я понимаю систему управления с замкнутым контуром обратной связи:

цель → действие → сигнал → решение → корректировка.

В ней план — не контракт с будущим, а текущая гипотеза о пути к цели.

Такая система отвечает на пять вопросов:

— какую наблюдаемую цель мы преследуем;

— какие ограничения нельзя нарушать;

— по каким сигналам поймём, что движемся не туда;

— как часто пересматриваем решение;

— кто может изменить курс и на основании каких данных.

Это похоже на управление технической системой. Недостаточно один раз задать параметры и уйти. Нужно измерять состояние, сравнивать его с ожидаемым и корректировать воздействие.

Для команды разработки это может выглядеть так:

1. Формулируем ожидаемый результат, а не только список задач.

2. Выбираем несколько сигналов: пользовательский эффект, lead time, количество возвратов, ошибки, нагрузку на поддержку.

3. Заранее договариваемся, когда проверим результат.

4. Если факты расходятся с ожиданиями, меняем способ достижения цели — а при необходимости и саму цель.

Важное ограничение: адаптивность — не постоянная смена приоритетов.

Если руководство приносит новую «самую важную» задачу каждый вторник, это не Adaptive Management System. Это отсутствие системы.

Адаптивное управление требует стабильного направления и управляемого способа менять маршрут. Иначе обратная связь превращается в шум, а команда — в сервис срочного реагирования.

Зрелая система управления оценивает не то, насколько точно мы выполнили первоначальный план.

Она оценивает, насколько быстро мы заметили ошибочную гипотезу и приняли более качественное решение.

Безопасность AI-агента определяется не только моделью

Когда обсуждают безопасность AI-агентов, вопрос обычно звучит так:

«Можно ли доверять Claude, GPT или Gemini?»

Но модель — лишь один компонент системы. И для реального уровня риска часто не самый важный.

В материале Trustworthy agents in practice Anthropic предлагает смотреть сразу на четыре слоя:

— Model — сама модель и её поведение.
— Harness — инструкции, ограничения и логика, которая управляет агентом.
— Tools — инструменты и действия, доступные агенту.
— Environment — среда и данные, к которым он получил доступ.

Для тимлида это полезная смена фокуса.

Вопрос не только в том, ошибётся ли модель. Она обязательно когда-нибудь ошибётся.

Гораздо важнее другое:

Что система позволит ей сделать после ошибки?

Одна и та же модель может:

— читать задачи в Jira;
— менять статусы, исполнителей и описания;
— запускать скрипты в production.

Формально модель одна. Фактически это три системы с совершенно разным уровнем риска.

Поэтому безопасность агента я бы проектировал так же, как любую другую критичную систему:

— минимально необходимые права;
— ограниченный blast radius — масштаб возможного ущерба;
— read-only по умолчанию;
— явное подтверждение опасных действий;
— изоляция среды;
— журнал действий и возможность остановить выполнение.

Не нужно начинать с попытки сделать агента безошибочным. Это примерно такой же надёжный план, как запретить разработчикам писать баги.

Лучше исходить из того, что ошибка произойдёт, и заранее ограничить её последствия.

Безопасность агента определяется не только тем, насколько он умный. Она определяется тем, насколько опасную ошибку ему позволили совершить.

Материал: Anthropic — Trustworthy agents in practice

Разработчик всё меньше пишет код. Что он делает вместо этого?

Anthropic описывает переход довольно прямолинейно: от writing code — к orchestrating agents that write code. В отчёте собраны восемь трендов и кейсы Rakuten, CRED, TELUS и Zapier.[1]

Но смена роли разработчика — не самое интересное.

Интереснее другое: если implementation становится дешевле, какие части разработки дорожают?

Раньше дефицитным ресурсом были руки, которые превращали задачу в код. Теперь агент может за несколько минут написать реализацию, тесты и открыть PR. Только это ещё не означает, что команда за несколько минут получила работающую фичу.

Ускорилась одна операция. Весь поток — не обязательно.

Стоимость смещается туда, где нужны контекст и ответственность:

— в постановку задачи: агент очень быстро реализует и хорошее ТЗ, и плохое;

— в архитектуру: дешёвый код позволяет так же дёшево размножать неверные решения;

— в review: проверять нужно не стиль и синтаксис, а допущения, контракты и побочные эффекты;

— в verification: «тесты зелёные» всё чаще означает только то, что зелёные тесты, написанные в том же контексте;

— в интеграцию: десяток быстро созданных изменений всё равно встречается в общей кодовой базе;

— в observability: чем быстрее система меняется, тем раньше команда должна замечать, что изменила не то.

Получается немного странная экономика SDLC. Производство кода дешевеет, а доказательство того, что этот код решает нужную задачу и не ломает соседние системы, дорожает.

Поэтому метрика «сколько кода мы теперь производим» почти наверняка ведёт не туда. Можно увеличить число PR и одновременно увеличить очередь на review, количество переделок и время до безопасного релиза.

В agentic development implementation постепенно становится самой дешёвой частью процесса. Значит, productivity стоит измерять не скоростью генерации кода, а скоростью прохождения проверенного изменения от идеи до production.

И главный вопрос для команды теперь не «насколько быстрее агент пишет код?», а «какое следующее бутылочное горлышко он сделал видимым?»

Источник
Anthropic — 2026 Agentic Coding Trends Report

Сегодня на Avito tech conf

EngThrive: какой ценой команда стала быстрее

В мае 2026 года Microsoft Research опубликовала EngThrive: Make It Fast and Easy to Do Great Work — систему измерения и улучшения инженерной эффективности, которую уже используют внутри Microsoft.

Проблема знакомая.

У нас есть SPACE, DORA и DevEx. Но у руководителя всё равно остаётся практический вопрос:

Что именно смотреть каждую неделю, чтобы понимать состояние разработки?

EngThrive предлагает три основных измерения:

Speed — насколько быстро работа проходит через систему.

Ease — насколько легко разработчику эту работу выполнять.

Quality — насколько качественным получается результат.

А поверх них — Thriving: благополучие разработчиков как защитное ограничение для всей системы.

И это, на мой взгляд, самая интересная часть подхода.

Throughput действительно можно увеличить довольно простым способом: добавить давления.

На некоторое время.

Поэтому Thriving здесь не отдельная HR-метрика про настроение сотрудников. Это guardrail, который помогает отличить устойчивое улучшение от эффективности, взятой в долг у следующего квартала.

Что из этого забрать тимлиду

Нельзя оценивать эффективность разработки по одной метрике.

Lead Time снизился, но количество инцидентов выросло — это не улучшение.

Throughput увеличился, но разработчики стали тратить больше времени на ручную рутину — результат тоже сомнительный.

Velocity растёт, а удовлетворённость работой резко падает — возможно, команда просто обменивает будущую производительность на красивые цифры сегодня.

Хорошая система метрик должна показывать не только, насколько быстрее стала команда.

Она должна помогать вовремя заметить, какой ценой появилось это ускорение.

Как измерять AI-продуктивность без самообмана

AI помог разработчику написать код быстрее. Этого недостаточно, чтобы сказать, что разработка стала продуктивнее.

В работе Microsoft The SPACE of AI: Real-World Lessons on AI’s Impact on Developers исследователи опросили более 500 разработчиков, а также провели интервью и наблюдения.

Влияние AI оценивали через модель SPACE:

— Satisfaction — удовлетворённость работой;
— Performance — качество результата;
— Activity — объём выполненных действий;
— Communication and Collaboration — взаимодействие в команде;
— Efficiency and Flow — эффективность и непрерывность работы.

Результаты показательные.

Разработчики действительно отмечают рост эффективности и удовлетворённости — особенно при выполнении рутинных задач.

Но эффект зависит от сложности задачи, способа использования AI и того, насколько инструмент принят всей командой.

А с совместной работой всё менее однозначно.

Допустим, код теперь пишется быстрее. Но одновременно:

— PR становятся больше;
— ревью занимает больше времени;
— растёт число исправлений после ревью;
— обмен знаниями сокращается;
— разработчики хуже понимают код друг друга.

Получили мы прирост продуктивности?

Не факт. Возможно, мы просто перенесли очередь из разработки в ревью.

Поэтому AI-продуктивность нельзя измерять одной метрикой — количеством строк, закрытых задач или временем написания кода.

Я бы смотрел сразу на несколько уровней:

— сколько времени задача проходит от начала до production;
— как изменились размер PR и время ревью;
— стало ли больше возвратов и исправлений;
— что происходит с качеством и количеством дефектов;
— помогает ли AI делиться знаниями или создаёт код, который понимает только его автор;
— как разработчики оценивают нагрузку и удовлетворённость работой.

AI может ускорить отдельную операцию и одновременно замедлить весь поток.

Поэтому измерять нужно не скорость генерации кода, а способность команды быстрее и стабильнее доставлять работающий результат.

AI adoption нельзя приказать

Почему два разработчика из одной команды совершенно по-разному используют AI?

У них одинаковые инструменты, правила и похожие задачи.

Один обращается к AI постоянно. Второй — почти никогда.

Свежая работа с участием исследователей Microsoft, представленная на ICSE 2026, изучает именно этот вопрос. Авторы провели интервью с 54 разработчиками из 27 команд. В каждой паре был активный и малоактивный пользователь AI.

Разница оказалась не столько в доступе к инструментам, сколько в отношении к ним.

Активные пользователи чаще воспринимают AI как напарника:

— экспериментируют с формулировками и контекстом;
— меняют способ работы после неудачного ответа;
— ищут задачи, где инструмент действительно помогает.

Малоактивные пользователи чаще воспринимают AI как отдельную функцию: попробовал, получил плохой результат, сделал вывод, что функция не работает.

Но для тимлида здесь важнее другой вывод.

Авторы называют его Productivity Pressure Paradox — парадокс давления продуктивности.

Организация ждёт, что AI быстро повысит эффективность. Поэтому у команды нет времени спокойно учиться им пользоваться.

Но без экспериментов, ошибок и обмена практиками инструмент не успевает встроиться в работу. Давление получить быстрый результат мешает освоить то, что должно этот результат обеспечить.

Получается знакомая инженерная история: новую технологию уже включили в план по повышению velocity, но ещё не включили в план время на её освоение.

Мой вывод простой.

Если команда должна стать эффективнее с AI, сначала ей придётся некоторое время быть с AI неэффективной.

Нужен learning budget — время и пространство, чтобы:

— попробовать AI на реальных задачах;
— получить несколько бесполезных результатов;
— найти рабочие сценарии;
— обменяться удачными примерами;
— договориться, как проверять результат.

Не KPI по количеству промптов.

Не обязательное использование AI в каждой задаче.

Не ожидание, что график продуктивности пойдёт вверх со следующего спринта.

AI adoption — это изменение способа работы. А такие изменения требуют не приказа, а обучения.

Что сейчас есть у вашей команды: время на освоение AI или только ожидание быстрого роста продуктивности?

Количество PR никогда не было хорошей метрикой. С AI стало ещё хуже

Раньше объём активности хотя бы был ограничен физически: разработчик не мог за день написать бесконечное количество кода.

Теперь AI-агент вполне способен:

— создать пять PR;
— написать сотни тестов;
— сгенерировать тысячи строк кода;
— обновить десятки файлов.

Если измерять activity, продуктивность выглядит фантастически. Дашборды зеленеют, графики растут, репозиторий кипит жизнью.

Только о ценности для продукта и пользователя это ничего не говорит.

Поэтому здесь снова стоит вернуться к EngThrive. Авторы прямо позиционируют систему как попытку перейти от измерения активности к измерению результата — outcomes.

Я бы смотрел не на количество произведённых артефактов, а на то:

— как быстро изменение доходит до пользователя;
— улучшает ли оно пользовательский результат;
— сколько дефектов и откатов возникает после доставки;
— во сколько обходится изменение;
— насколько легко оно проходит путь от идеи до продакшена.

Важное ограничение: эти показатели тоже нельзя превращать в рейтинг отдельных разработчиков. Их задача — показывать состояние системы доставки, а не искать самого «эффективного» человека.

AI окончательно добивает метрики, которые и раньше были плохими.

Количество строк кода теперь просто особенно наглядный пример: производить их стало почти бесплатно. Разбираться с последствиями — всё ещё нет.

Не учите команду пользоваться AI. Научите команду учиться пользоваться AI

Разница небольшая только на словах.

Плохая стратегия внедрения выглядит так:

Вот Copilot.
Вот инструкция.
Пользуйтесь.

Формально AI внедрён. Фактически каждый разработчик остаётся один на один с новым инструментом: сам ищет подходящие сценарии, повторяет чужие ошибки и часто возвращается к привычному workflow.

Если положить рядом два исследования Microsoft — SPACE of AI и работу про drivers of adoption, — в обоих заметна одна закономерность: на использование AI влияют не только возможности инструмента, но и среда вокруг него. Организационная поддержка и обучение друг у друга имеют значение.

Поэтому нормальная стратегия выглядит иначе:

— регулярный обмен рабочими кейсами;
— короткие демо удачных сценариев;
— общая база промптов и контекста;
— pairing при освоении новых подходов;
— AI Champion, который помогает команде собирать и распространять практики;
— разбор не только успехов, но и неудачных попыток;
— выделенное время на эксперименты.

Важное ограничение: не существует одного AI-workflow, который можно написать в Confluence и раздать всей команде.

Разные задачи, языки, уровни опыта и части системы требуют разных способов взаимодействия с AI.

Где-то полезен агент, который самостоятельно меняет несколько файлов. Где-то — точечная помощь с тестами. А где-то AI только добавляет ещё один слой проверки и ускоряет производство неправильного кода.

Поэтому задача тимлида — не стандартизировать каждый промпт.

Задача — создать learning loop:

попробовали → показали результат → обсудили ограничения → сохранили полезную практику → проверили её на другой задаче.

Не управление AI adoption.

Управление скоростью, с которой команда учится использовать AI осмысленно.

AI приняли. Но junior-разработчикам всё равно доверяют меньше

Microsoft Research опубликовала препринт работы для VL/HCC 2026 с отличным названием: After Organizational AI Acceptance, AI Bias Fades but a Junior Penalty Persists in Code Review.

В эксперименте 447 разработчиков оценивали один и тот же код. Исследователи меняли только контекст: использовал ли автор AI и был ли он junior- или Principal-инженером.

Упоминание AI заметно не повлияло ни на оценку кода, ни на восприятие компетентности автора.

А уровень разработчика повлиял. Тот же код получал более низкие оценки, когда его автором называли junior-инженера. (microsoft.com)

Конечно, из этого не следует, что seniority нужно убрать из процесса.

В реальной работе мы проверяем не только diff. Мы учитываем понимание системы, историю прошлых решений, способность увидеть побочные эффекты и готовность отвечать за результат.

Но исследование поднимает неприятный management-вопрос:

Что именно мы ревьюим — изменение или человека, который его сделал?

Более глубокое ревью может быть оправдано, если:
• изменение затрагивает критичный участок;
• у него большой радиус последствий;
• нет тестов или наблюдаемости;
• автор впервые работает с этой частью системы.

Но «посмотрю внимательнее, потому что это написал junior» — уже другой критерий.

И у него есть зеркальная сторона: «можно не вчитываться, это же senior».

Первое легко превращается в постоянное недоверие. Второе — в пропущенные ошибки с особенно дорогими последствиями.

С AI этот вопрос станет ещё интереснее.

Если значительную часть реализации для junior и senior сделал один и тот же агент, разница в способности сгенерировать код уменьшается. Но ответственность за постановку задачи, проверку допущений, оценку риска и принятие решения никуда не исчезает.

AI постепенно выравнивает способность людей производить код.

Но он не выравнивает доверие к их решениям.

Возможно, seniority всё меньше будет определять, кто способен написать изменение, и всё больше — кому команда готова позволить его принять.

От чего у вас зависит глубина code review: от риска самого изменения или от уровня его автора?