«С понедельника пробуем разработку через агентов. Код, тесты и первое ревью делают они. Должны неплохо ускориться».

В переговорке тишина. Потом кто‑то спрашивает: «А работать когда?» Второй добавляет: «Мы это уже проходили». Третий молчит, а вечером обновляет резюме. С любым новым процессом всё идёт примерно так же, будь то второй ревьюер, обязательное техописание перед разработкой или новый шаблон задачи. Тимлид объясняет ещё раз. Кто‑то из разработчиков вспоминает случай, где новое правило только всё усложнит. Остальные кивают. Минут через десять вы уже отбиваетесь, а команда дружно доказывает, что ничего не выйдет.

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

Под катом:

• из чего на самом деле состоит «сопротивление»;

• словарик «вы говорите / команда слышит / как сказать иначе»;

• разбор одного возражения на примере второго ревью;

• арифметика ИИ‑агентов, которую на демо обычно пропускают;

• шаблон сообщения в чат после встречи и чек‑лист перед ней.

Диалоги в статье придуманы. Если что‑то совпало с вашим последним планированием, это случайность, а может и нет))

Из чего состоит «сопротивление»

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

Вопрос «А кто это всё будет проверять?» чаще всего по делу. Если сервис толком знает один человек, правило двух апрувов второго такого человека не создаст. Зато создаст очередь. Разработчик, который об этом говорит, по сути находит проблему до запуска. Саботажем тут и не пахнет.

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

Переводчик с тимлидского

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

С последней строкой стоит быть особенно осторожным. Команда потратит час на варианты, которые всё равно нельзя выбрать, и запомнит это надолго. Если требование спустили сверху, так сразу и скажите. А потом объясните, что ещё можно поменять: как именно выполнять, кому сколько достанется, когда начинать.

Фраза «Кто не освоит ИИ…» плоха ещё и тем, что разговор про инструмент превращается в разговор под угрозой. После неё никто уже не признается, что не понимает новый процесс или видит в нём дыру. Хотя вам нужно услышать именно это.

Разбираем на простом примере: второе ревью

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

Шаг 1. Начните с инцидента, а не с идеи

Перед встречей попробуйте закончить фразу: «Хочу поменять процесс, потому что сейчас…» Если дальше получается только «так будет эффективнее», обсуждать команде пока нечего. Нужен конкретный сбой, который люди могут сами проверить и дополнить.

Допустим, при доработке платёжного сервиса забыли про повторный запрос, и операция прошла дважды. Ревьюил один человек, но причину это ещё не объясняет. Может, он плохо знал сервис. Может, не было сценария проверки. А может, просто не хватило времени вчитаться.

Тимлид может начать примерно так:

«В последней доработке платёжного сервиса мы пропустили повторное выполнение операции. Хочу понять, как ловить такое до релиза. Один из вариантов — второе ревью для изменений в логике платежей. Что оно нужно на каждый ПР, я не уверен. Давайте прикинем, какие риски оно закроет и где мы на нём будем стоять в ожидании».

Тут есть предмет разговора и предложение, которое можно проверить. И команде не нужно сначала соглашаться, что «у нас всё плохо».

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

Шаг 2. Просите пример, а не спорьте о словах

Когда звучит «это бюрократия», очень хочется ответить, что человек просто не понял идею. Но из слова «бюрократия» непонятно, какая именно работа кажется ему лишней. Лучше попросить пример:

«Слушай, покажи задачу, на которой мы из‑за этого затормозим. Где будем ждать и кого придётся дёргать?»

Первый вариант ответа: «Я поправил текст ошибки. Первый ревьюер глянет сразу, а второго я до вечера буду ловить. Зачем?» Вот это уже конкретный вопрос: должно ли правило касаться таких правок? Возможно, вы взяли слишком широко.

Второй вариант: «Этот сервис знает только Саша. Он в итоге будет смотреть вообще всё». Тут уже мало убрать мелкие правки. Это история про то, что Саша один, и про передачу знаний. Назовём это «очередь к Саше». Если её не разрулить, второй апрув станет формальностью, либо вся работа будет стоять и ждать одного человека.

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

Шаг 3. Перескажите своими словами и дайте себя поправить

«Я правильно понял: ты согласен, что повторные операции надо проверять внимательнее, но если второй апрув будет обязателен для всего, все упрутся в Сашу?»

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

Шаг 4. Скажите про цену вслух

Даже полезное изменение отнимает время. Кому‑то писать описание, кому‑то его читать, кому‑то разбираться с исключениями. Если это не учесть, у людей останется прежний план плюс новая обязанность. «Будем смотреть оперативно» ничего не решает, пока не договорились, кто проверяет, когда и что делать, если нужного человека нет.

«Второе ревью добавит работы. Делать вид, что она как‑нибудь сама рассосётся, я не буду. Перед запуском пересмотрим объём задач и выделим время тем, кто будет проверять».

Говорить так стоит, только если вы правда можете пересобрать план. Если нет, честнее сказать: «Вопрос с нагрузкой я понесу руководителю разработки. Пока не договоримся, дату перехода объявлять не буду».

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

Шаг 5. Пилот, у которого есть конец

«Давайте попробуем» звучит мягко. Но все помнят процессы, которые вводили «на недельку» и так и не отменили. У пилота должны быть понятные границы, дата разбора и критерии, по которым вы поймёте, что получилось.

Например, две недели второе ревью проходят только изменения в логике платежей. Автор ПР сам отмечает, задета ли эта логика, а спорные случаи решает тимлид. Оба ревьюера назначены заранее, и второй понимает, какой риск ему нужно ловить. Если он просто ставит ещё один апрув, толку от этого мало.

Что собирать:

• сколько изменение ждало второго ревьюера;

• что по существу он добавил;

• сколько времени ушло на саму проверку. Только не превращайте число комментариев в метрику пользы. Пять правок формулировок и один найденный риск двойного списания весят совсем по‑разному. И учтите, что за две недели вы проверите, удобен ли процесс. Доказать, что инцидентов стало меньше, за такой срок не выйдет.

И договоритесь, когда пилот останавливается досрочно. Например, если проверять некому и ПР копятся в очереди, ждать конца двух недель незачем. Команда пишет об этом, тимлид разбирается в тот же день.

«Через две недели посмотрим, что нашли и сколько простояли в ожидании. Если второй просмотр ничего не даёт, подумаем про другой способ проверки. Если ошибки находит, но создаёт очередь, будем перераспределять работу».

Главный босс: ИИ‑агенты и разработка по спецификациям

Теперь о том, ради чего многие, подозреваю, и открыли статью.

В SDD (Spec‑Driven Development, разработке по спецификациям) всё крутится вокруг спецификации: требований, ограничений, сценариев и критериев приёмки. По ней пишут код и по ней же проверяют результат. ИИ‑агенты могут писать код, генерировать и гонять тесты, делать автоматическое ревью. Но из самой аббревиатуры не следует, что человек из цикла выпадает. В обзоре Microsoft про SDD главная мысль сформулирована коротко: какая спецификация, такой и результат.

Руководство ждёт ускорения. А у сотрудника в голове крутятся сразу два вопроса:

• «Если агент пишет код, тесты и ревью, зачем тогда я? Сейчас попросят всё настроить, а потом сократят?»

• «А если не сократят, я что, буду с утра до ночи разгребать, что агенты нагенерили?» Получается такой разработчик Шрёдингера: он одновременно боится остаться без работы и утонуть в ней. И оба страха вполне разумные, поэтому отвечать придётся на каждый.

Когда страшно за свою роль

Дежурное «не переживайте, ваша экспертиза всё равно нужна» тут не сработает. Человеку важно понять, какие задачи останутся за ним, чему придётся учиться, дадут ли на это время и как теперь будут оценивать его работу. Если раньше смотрели на то, что он написал, а теперь ждут разбора спецификаций и проверки того, что сделал агент, старые критерии его вклад уже не покажут.

Разделите, что вы знаете, а чего не знаете. Например, если это правда:

«На пилот у нас согласован текущий состав команды. Что компания решит дальше, обещать не могу. Спрошу у руководителя разработки, связано ли внедрение с пересмотром численности и ролей, и в пятницу расскажу, что удалось узнать. Время на то, чтобы освоиться, закладываем в план. И если вы будете говорить, что агент ошибается или проверка отнимает кучу времени, я не стану записывать вас в противники изменений».

Если сокращения уже объявлены, не прячьте их за разговорами про удобный инструмент. А если решений пока нет, не закрывайте эту дыру обещаниями, что всё будет хорошо.

Арифметика, которую на демо пропускают

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

Условный пример:

Каждое изменение проверяем вдвое быстрее, а в сумме тратим вдвое больше. И это ещё без доработок и интеграционных багов. Цифры, повторю, условные и статистикой по SDD не являются. Но есть и внешние данные, которые намекают, что риск настоящий:

• В рандомизированном исследовании METR (июль 2025) 16 опытных разработчиков решали 246 задач в собственных зрелых open‑source проектах. С ИИ‑инструментами они работали примерно на 19% медленнее. Сами же были уверены, что ускорились где‑то на 20%.

• По данным отчёта DORA 2025, с ростом использования ИИ команды поставляют больше, но и нестабильность поставки продолжает расти. Авторы называют ИИ усилителем: у сильных организаций он усиливает сильные стороны, у слабых очевидно проблемы.

Оба исследования не про SDD, да и инструменты с тех пор поменялись. Но для пилота вывод простой. Чувствовать, что стал быстрее, и правда сократить весь цикл — разные вещи. Так что считать надо весь цикл целиком.

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

Сверить спецификацию с реальной задачей и найти, чего в ней не хватает, по‑прежнему может только человек.

Как этот разговор звучит вживую

Сотрудник:«Вы хотите ускориться, но агент нагенерит десятки изменений. Кто это всё будет читать, проверять тесты и чинить расхождения? Мы и сейчас еле успеваем».

Тимлид:«То есть ты боишься, что изменений станет больше, чем мы успеваем проверить. Давай заложим это заранее. На пилоте ограничим, сколько изменений может одновременно висеть на проверке. Новую задачу агенту даём, только когда есть кому принять предыдущую. Конкретный лимит подберём по текущей загрузке. Если очередь растёт, новые задачи агентам ставим на паузу и смотрим, в чём дело».

Сотрудник: «А потом скажут: раньше закрывали пять задач, теперь давайте двадцать. А баги будем по вечерам чинить».

Тимлид: «Отчитываться наверх числом сгенерированных изменений я не буду. Посчитаем весь цикл: уточнение требований, спецификацию, работу с агентом, проверку, тестирование и доработки. Как считаем и какие лимиты, согласую с руководителем разработки до старта. Если сэкономленное на написании кода съедят проверки, это тоже результат пилота, будем его обсуждать».

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

Как устроить пилот с агентами

• Возьмите ограниченный набор задач.

• Заранее решите, кто принимает спецификацию, кто проверяет изменения и кто даёт добро на выкатку.

• Зафиксируйте, что агент может делать сам, а где нужно решение человека.

• Посчитайте в затратах обучение, подготовку контекста и доработку того, что сделал агент. На разборе смотрите:

• сколько прошло от согласования задачи до принятого результата;

• сколько человеко‑часов ушло на каждый этап;

• сколько изменения ждали проверки и сколько раз уходили на доработку;

• сколько дефектов вылезло после релиза за заранее оговорённый период.

Сравнивайте задачи похожей сложности. Пара удачных примеров ещё не доказывает, что быстрее стал весь процесс.

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

Что делать с тем, кто всё ещё против

Бывает, что человек и после долгого разговора остаётся при своём. Не объявляйте, что «все договорились», если он просто устал спорить. Уточните, что осталось нерешённым и мешает ли это вообще начать пилот.

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

Тимлид: «Да, тогда правило расширили, а нагрузку никто не пересмотрел. Поэтому сейчас сразу фиксируем, на что оно распространяется и когда разбор. На остальные изменения само по себе оно не переедет. Если я захочу его расширить, отдельно обсудим, зачем и чего это будет стоить».

Спорить с памятью команды в духе «ну сейчас‑то всё по‑другому» бесполезно. Людям нужно понять, почему в этот раз история не повторится.

Сотрудник: «Я всё равно думаю, что нам нужны тесты, а не второй человек».

Тимлид: «Окей, давай разберём, какой сценарий должен закрывать тест и сколько времени уйдёт, чтобы его написать. Пока теста нет, такие изменения всё равно надо как‑то проверять. Предлагаю на оговорённый срок второе ревью, а на разборе сравним, что оно поймало и что уже закрыто тестами. Какой риск ты тут видишь?»

Может выясниться, что тест можно написать хоть сейчас и временный процесс вообще не нужен. Тогда будьте готовы поменять собственное предложение. Иначе команда быстро поймёт, что её мнение спрашивают для галочки.

Если серьёзных препятствий не нашлось, а решать надо, просто озвучьте решение, не пытаясь добиться, чтобы все были «за»:

«Я тебя услышал, ты считаешь второй просмотр лишним. Твои замечания учтём, но эти две недели мы его всё‑таки попробуем. От тебя нужно будет поревьюить два изменения, время на это заложим в план. На разборе вернёмся к твоему возражению».

Так можно говорить, если решение в ваших полномочиях и нагрузку вы уже согласовали. Если же человек указывает на конкретный риск, который ещё не разобрали, сначала вернитесь к нему. И помните, что несогласие само по себе ещё не отказ работать.

Сообщение в чат после встречи (можно копировать)

«Коллеги, на две недели вводим второе ревью для изменений в логике платежей. Когда открываете ПР, отмечайте, задета ли эта логика. Если не уверены, пишите мне. Время на ревью учитываем при планировании, кто ревьюит, согласуем до старта. Записываем, сколько ждали второго ревьюера и что он нашёл по существу. Если ревьюера нет и задача встала, пишите в общий чат со ссылкой, разберусь в тот же день. Хотфиксы идут по отдельному порядку для инцидентов. В пятницу второй недели собираемся на разбор: что нашли, где ждали, как поменялась нагрузка. По итогам решаем, как работаем дальше. На другие изменения правило без отдельного обсуждения не расширяем».

Перед запуском прогоните этот текст на живых задачах. Попросите команду показать, какие из ближайших изменений попадут под новое правило, кто их сможет проверить и где уже намечается очередь к Саше. Так всплывёт то, о чём на общей встрече никто не вспомнил.

Чек‑лист перед разговором

1. Какую конкретную проблему мы решаем и на каких задачах она вылезла

2. Что уже решено, а на что команда ещё может повлиять?

3. Сколько дополнительной работы получат люди и откуда на неё возьмётся время? Если речь про агентов, как учтём анализ, тестирование, доработки и обучение?

4. Какие возражения я уже слышал? Что из этого про нагрузку и качество, а что про страх за работу или свою роль?

5. На каких задачах проверим идею и что делаем с исключениями?

6. Когда пересматриваем порядок и по каким данным? Как поймём, что ускорение на одном этапе обернулось лишней работой на других?

7. Что я готов поменять в собственном предложении, если команда найдёт в нём проблему?

Последний вопрос лучше задать себе ещё до встречи. Если вы зовёте людей обсуждать процесс, их ответы должны хоть на что‑то влиять. Иначе возражений на следующих встречах действительно станет меньше. Просто люди перестанут тратить на них время.

Расскажите в комментариях, какую фразу при внедрении нового процесса вы слышали чаще всего и что за ней на самом деле стояло. Самые меткие добавлю в «переводчик».

Опрос

Как у вас в компании внедряют ИИ‑агентов в разработку?

• Обсудили с командой, запустили пилот с метриками

• Спустили сверху, обсуждение было для галочки

• Внедрили и меряют успех количеством ПР

• Пока не внедряли, но разговоры уже ходят

• Я тимлид и узнал себя в левой колонке «переводчика»

Источники

• Apoorv Gupta. Spec‑Driven Development: A Spec‑First Approach to AI‑Native Engineering. Microsoft for Developers, 10 июня 2026. https://developer.microsoft.com/blog/spec‑driven‑development‑ai‑native‑engineering/

• Исследование METR о продуктивности опытных open‑source разработчиков с ИИ‑инструментами, июль 2025. Обзор Axios: https://www.axios.com/2025/07/15/ai‑coding‑productivity‑study

• Google Cloud DORA. State of AI‑assisted Software Development 2025. Обзор: https://www.infoq.com/news/2025/09/dora‑state‑of‑ai‑in‑dev-2025