Вы прочитали гайд по Cursor, посмотрели демку Claude Code, посчитали в голове экономику и решили: пора. Спускаете в команду указание — попробовать на следующей итерации. Через две недели смотрите на цифры и видите, что lead time не сократился, а вырос. Полетели странные инциденты в трекер. Двое лучших разработчиков ходят с лицами «я же говорил». На ретро звучит сдержанное «нам нужно больше времени, чтобы оценить эффект». На самом деле это значит «уберите эту штуку».

Знакомо? Это типичная картина внедрения ИИ в инженерной команде через администрирование. Проблема не в инструменте, не в моделях и не в скептиках. Проблема в том, что push‑модель (принуждение) внедрения системно не работает с разработчиками высоких грейдов — и чем сильнее ваша команда, тем хуже она работает.

В этом гайде — pull‑модель (втягивание, вовлечение). Что нужно построить, чтобы синьоры сами выбрали работать с агентом, а через три месяца стали евангелистами. Это не про мотивационные речи и не про премии за процент кода от ИИ. Это про инженерное решение: workflow, инфраструктура и фазы развёртывания, которые проходят фильтр опытного разработчика.

---

Почему метод принуждения проваливается

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

Дальше начинается то, чего никто не ждал.

Ревью встаёт колом. Объём PR вырос, нагрузка на ревьюера ушла в потолок. Сгенерированный код выглядит правдоподобно, но «тяжелее» и читается медленнее живого: многослойные конструкции, несоответствие конвенциям, неочевидные побочки в местах, где их не ждёшь. Синьоры тратят на ревью больше, чем сэкономили джуны на написании. Чистый минус по балансу.

Релизный цикл удлинняется. Энтропия подходов в кодовой базе растёт — где‑то один стиль, где‑то другой, где‑то третий, и всё в одном репозитории. Архитектурные решения принимаются без сквозного видения, потому что у каждого свой агент и свой контекст. Через пару итераций накапливается техдолг, который никто явно не вкладывал — он просто появился. Параллельно растёт число инцидентов: часть багов проскочила через перегруженное ревью.

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

• Конфликт с профессиональной идентичностью. Синьор — это человек, чья ценность построена на качестве принимаемых решений. Когда ему предлагают режим «опиши задачу — прими сгенерированное», ему отдают роль технического писаки‑ревьюера, а роль автора — модели. Это не повышение в роли, как бы красиво это ни упаковали в слайдах. Это понижение.

• Страх deskilling. Не воображаемый, реальный. Если три года писать код преимущественно через генерацию, что станет с навыком держать архитектуру в голове, чувствовать code smells, отличать правильное решение от похожего на правильное?

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

• Угроза job‑security. Не «меня заменят моделью» — это страх джунов. Синьорский тоньше: «если моя ценность сводится к ревью генераций, я взаимозаменяем». Чем крепче синьор стоит на ногах, тем острее это чувствует.

Push‑модель пытается все четыре пункта проигнорировать и продавить через KPI. Pull‑модель — опирается на них как на дизайн‑требования. В этом вся разница.

Что синьор хочет от ИИ на самом деле

Если развернуть четыре страха из предыдущего раздела на 180 градусов, получится список требований. Не к инструменту — к режиму работы. Это не «фичи», которые можно купить подпиской. Это свойства workflow, которые либо есть, либо нет.

Синьор хочет оставаться автором решений. Не ревьюером, не оператором при модели, не приёмщиком сгенерированного. Автором. Это значит — агент включается до того, как принято архитектурное решение, и помогает его принять, а не реализует уже принятое. Парадоксально, но именно ранний вход агента — на этапе исследования и брейншторма — снимает страх «меня свели к ревью», потому что роль автора при таком раскладе остаётся за человеком. На исследовании агент — собеседник. На имплементации — руки. Не наоборот.

Синьор хочет, чтобы его экспертиза усиливалась, а не атрофировалась. Здесь тонкий момент. Любой сильный инженер знает: навык растёт там, где приходится думать, и атрофируется там, где думать перестаёшь. Если агент берёт на себя «думать», навык уходит. Если агент берёт на себя «искать, проверять, синтезировать рутину», а думать остаётся человеку — навык растёт быстрее, чем без агента. Workflow должен явно разводить эти два режима. Не «агент сам всё сделал, я только нажал ОК», а «я провёл агента через своё мышление, и на выходе получил его в коде».

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

Синьор хочет, чтобы его роль стала менее заменимой, а не более. Это самая контринтуитивная часть. Push‑модель неявно сообщает: «вы все теперь операторы при ИИ, разница между вами размылась». Pull‑модель должна сообщать обратное: «после внедрения вы стали ещё более ценны, потому что качественно работать с агентом — отдельный навык, и у вас он есть, а у джунов нет». Парадоксально, но реальность ровно такая: КПД работы с агентом у сильного инженера на порядок выше, чем у слабого. Сильный задаёт правильные вопросы, видит косяки в выводе, держит границы скоупа, не даёт агенту увести себя в дебри. Слабый — генерирует мусор быстрее, чем раньше.

Эти четыре пункта — не маркетинг. Это ТЗ на остаток статьи. Дальше я разбираю принцип, workflow, инфраструктуру и фазы внедрения — и в каждом разделе явно показываю, какой из пунктов закрывается какой механикой. Если в вашем будущем внедрении один из четырёх не закрыт — оно не пройдёт фильтр синьора, как бы красиво ни было упаковано остальное.

Главный принцип: агент в подчинённой проактивной позиции

Эту формулу я повторяю постоянно, и каждый раз вижу, как у людей в глазах вопрос: «то есть как? проактивный — это же значит сам?». Нет. Это — ключ ко всему.

Большинство демок и блог‑постов про агентную разработку построены на противоположной модели: агенту даётся задача, он сам её декомпозирует, сам имплементирует, сам открывает PR. Человек на входе формулирует, на выходе принимает. Назовём это автономной позицией. Она хорошо смотрится в твиттере, плохо работает на реальной кодовой базе и категорически не проходит фильтр синьора. Потому что она требует доверия, которого у синьора нет — и взяться ему неоткуда.

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

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

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

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

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

Здесь снимается главный страх deskilling. Когда агент в подчинённой позиции, думать продолжает человек. Агент берёт на себя поиск по кодовой базе, проверку гипотез, синтез вариантов — то есть рутину, на которой навык не растёт. А думать — где ставить границу скоупа, какой trade‑off приемлем, какая абстракция правильная — остаётся за инженером. Через полгода такого режима навык не атрофируется, а растёт быстрее, потому что инженер обрабатывает больше задач за то же время, и каждая задача требует от него именно мышления, а не возни с поиском.

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

Если вы включаете агента поздно — на стадии «напиши мне функцию, которая делает X» — вы используете его как генератор. Это и есть тот режим, который вызывает у синьоров отторжение. Потому что в нём агент действительно подменяет автора, а не усиливает.

Подчинённая проактивная позиция — это не настройка. Это конструкция, которая собирается из трёх вещей: workflow, инструкций (контекстный слой) и привычек разработчика. Workflow задаёт ритм — где агент входит и где останавливается. Инструкции задают границы — что он может и чего не должен. Привычки задают качество — насколько вы умеете с ним разговаривать. Дальше разбираем все три по очереди.

Workflow

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

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

Это не просто красивая последовательность. Это три фазы с разной ролью агента в каждой.

Brainstorming. Самая важная фаза. Здесь агент — собеседник, не исполнитель. Получает намерение в виде «работаем над фичей X, вот пользовательские истории, вот критерии приёмки». Дальше — режим вопрос‑ответ. Агент ресерчит кодовую базу, поднимает противоречия, задаёт уточняющие, предлагает альтернативы. На выходе — design document с фиксированной структурой: цель, скоуп, non‑goals, архитектурные принципы, контракты, риски, decision log.

Здесь закрывается страх «меня свели к ревью». Автор всех решений в design document — человек. Агент — инструмент структурирования его мышления, не подмена.

Planning. Когда дизайн зафиксирован, переключаемся на «как». Цель — разбить задачу на спринты, каждый со своим скоупом, критериями приёмки и оценкой blast radius. Спринт = атомарная единица работы, не оставляющая код в нерабочем состоянии. На этой фазе агент ещё раз пробегает по коду, но в фокусе уже не «что построить», а «куда положить и что заденет». Часто на этой стадии всплывают нюансы, пропущенные на брейншторме.

Здесь синьор остаётся архитектором имплементации. Не пишет план самостоятельно — но утверждает каждый поворот. Это и есть та самая автономия, сохранение самоценности через экспертизу и право на принятие решения.

Work cycle. Цикл plan → implement → review → fix → review → commit, повторяемый по спринтам. Внутри каждого спринта — отдельная сессия. Между спринтами — коммит обязателен. Ниже схема.

Здесь, кстати, выкристаллизовывается главный новый навык инженера в эпоху агентной разработки — точность, ясность мысли, системность и терпение. Цикл «human reviews → agent fixes» работает ровно настолько, насколько хорошо вы умеете объяснять, что не так. Будете растекаться по древу — агент уйдёт в дебри. Ответите грубо и не по делу — получите костыль. Всё как с живым человеком, только этого не уволишь.

Скиллы — то, без чего ничего не работает

Описанный workflow невозможен на голой модели. Каждая фаза требует от агента специфического поведения, которое ни одна frontier‑модель сама по себе не демонстрирует. Под обычными инструкциями она будет писать код — а нам нужно, чтобы она сначала задавала вопросы, потом исследовала кодовую базу, потом фиксировала решения в файл, и только потом писала код.

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

Минимально рабочий набор — три скилла:

• brainstorm — переводит агента в режим собеседника. Принимает намерение, ресерчит, челленджит, фиксирует решения, на выходе — design document.

• planner — переводит в режим архитектора имплементации. Принимает design document, проверяет его против реального кода, разбивает на спринты, на выходе — development plan.

• code‑review — переводит в режим ревьюера. В свежей сессии принимает результат имплементации спринта, выдаёт репорт.

Скиллы я выложил в открытый доступ: github.com/pridees/skillforce. Подогнаны на работу друг с другом, протестированы на Claude Code, Codex, Gemini, Open Code и нескольких других harness, на моделях от Anthropic, OpenAI, Kimi и GLM. Гарантий, что у вас заработает идентично, нет — модели разные, harness разные, кодовые базы разные — но как отправная точка вполне годятся. Дальше адаптируете под свою специфику.

Установка (может понадобиться установленный nodejs):

npx skills add pridees/skillforce

Как тимлид, вы не должны заставлять каждого синьора собирать это с нуля. Один из ваших ключевых вкладов — подготовить скиллы и контекстный слой централизованно, в формате, удобном для подключения к репозиторию. Это снимает огромный кусок «налога на вход» для синьоров, которые иначе никогда бы не дошли до настройки самостоятельно. И заодно — снимает разнобой подходов в команде, который мы видели в push‑сценарии.

Что должно появляться в репозитории

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

Design document (после brainstorm). Структура: Understanding Summary, Non‑Goals, Assumptions, Design Principles, Data Model / Contract, Runtime Behavior, Testing Strategy, Decision Log, Acceptance Criteria.

Development plan (после planning). Структура: Overview, Prerequisites, Sprint 1...N (каждый со своей целью, задачами, критериями приёмки, валидацией), Testing Strategy, Risks & Rollback.

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

Подготовка инфраструктуры

Скиллы — половина дела. Вторая половина — то, что лежит в репозитории и подгружается агентом каждый раз при работе. Это harness, на котором всё крутится, и контекстный слой, который определяет, как агент понимает ваш проект.

Harness

Harness — слой между «интеллектом» (моделью) и «исполнением» (вашим кодом и тестами). По сути, это и есть «агент» в обиходном смысле слова — Claude Code, Codex CLI, Cursor agent mode, Open Code. Их задача — не «писать код вместо разработчика», а замыкать управляемый SWE‑цикл: получение задачи, исследование кодовой базы, планирование, внесение изменений, синхронизация инструкций, tool и MCP вызовы.

Главное требование — способность проверять самого себя. Внутри агентского цикла должен быть этап критики и самопроверки: запуск компилятора, линтера, тестов. Либо возможность настроить это вручную через хуки. Без этого harness — не SWE‑tool, а просто красивый чат с автодополнением.

Большого выбора нет. Mainstream‑варианты — Claude Code и Codex CLI, оба умеют переключаться на модели сторонних провайдеров (если это политически приемлемо в вашей компании). Если не приемлемо — мой личный рекомендасьен Pi, крайне расширяемая штука, позволяющая накрутить всё что нужно. По моделям — берите лучшее доступное; если frontier недоступен, в открытых весах сейчас неплохо тянут модели уровня GLM/Kimi/MiniMax.

Как тимлид, вы выбираете harness один раз для всей команды и закрепляете в стандарте. Гетерогенность тут — зло: разные harness читают разные форматы инструкций, и контекстный слой, заточенный под один, не работает с другим.

Контекстный слой

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

Я строю этот слой так:

/
├── .agents/
│   ├── rules/
│   │   ├── coding-guidelines.md
│   │   └── conventions.md
│   ├── skills/
│   │   ├── brainstorm/SKILL.md
│   │   └── code-review/SKILL.md
│   └── AGENTS.md

Дальше — симлинки под конкретный harness: .agents/AGENTS.md → .claude/CLAUDE.md или .agents/AGENTS.md → .codex/AGENTS.md. OSS‑агенты понимают .agents из коробки или позволяют указать имя в конфиге.

AGENTS.md — главная агентская инструкция. Базовая структура: определение проекта, правила разработки (со ссылками на rules/), структура репозитория, гайдлайн по спецификациям, конвенции коммитов, red flags (то, чего никогда не делаем), команды для сборки и тестов, ссылки на документацию. Минимальный универсальный шаблон, с которого можно стартовать, я выложил отдельным гистом — gist.github.com/pridees/82eef0e1710196188492695baef20ee6. Берите, адаптируйте под свой стек.

Содержательно AGENTS.md заполняется не вручную с нуля. Есть способ проще: попросить агента сделай интроспекцию репозитория и его правил и обнови @.agents/AGENTS.md, сохранив структуру. Дальше — ревьюите и правите. Один раз, для всей команды.

Главный принцип: «модель разберётся сама»

Это контринтуитивная вещь, которую обычно понимают только после нескольких итераций.

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

• Раздутый AGENTS.md занимает место в контекстном окне. Каждый токен инструкций — это токен, отнятый у задачи. Чем больше правил, тем хуже агент решает.

• Инструкции вступают в противоречие с реальным кодом. Реальность всегда богаче письменного описания. Агент видит код — и предсказуемо пишет так, как видит. А вас раздражает, что он «не следует правилам».

• Императивные правила хрупкие. «Контроллеры пиши вот так» — а если контроллер не такой? «Не используй X» — а если в одном месте всё‑таки нужно? Каждое исключение требует апдейта инструкций.

Гораздо мощнее работает другой подход: уточняйте детали по ходу работы с агентом, а источником примеров делайте ваш код. Если у вас есть хорошо спроектированный модуль или удачная имплементация фичи — просто опишите случай и сошлитесь на эти файлы. «Когда работаешь с доменным слоем, смотри src/domain/order как образец». Вместо страницы инструкций — одна строка плюс реальный пример из вашей же кодовой базы.

Аналогично с правилами: не пишите для каждого файла в rules/ You MUST read. Инструкции о REST‑контроллерах не нужны для работы с доменным слоем, и наоборот. Просто опишите условие, когда инструкция актуальна — модель разберётся сама.

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

Как тимлид, ваша задача — не написать идеальный AGENTS.md один раз, а создать процесс его эволюции. Кто‑то один (вы или назначенный мейнтейнер) держит контекстный слой в актуальном состоянии, принимает PR на правила и скиллы от команды, отслеживает то, что начало повторяться. Это не разовая активность, это новый ритуал в репозитории — как CODEOWNERS, только для контекста.

Как разворачивать в команде

Harness выбран, контекстный слой собран, скиллы в репо. Дальше — самое сложное. Превратить инфраструктуру в практику без скатывания обратно в push‑модель, которую мы только что разобрали.

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

Фаза 1. Ранние последователи (early adopters)

Найдите 1–2 человек в команде, которые сами хотят с этим работать. Не уговаривайте, не «дайте шанс». Хотят — значит, уже пробовали на стороне, разочаровались в наивных подходах и готовы потратить силы на нормальный workflow. Идеальный кандидат — синьор со зрелым скепсисом, а не джун с горящими глазами.

Их задача на этой фазе — не «перевести команду на ИИ». Их задача — прожить workflow на реальных задачах и произвести видимые артефакты: design documents, development plans, чистые PR, которые ревьюятся быстро и не требуют переписывания. Несколько фич, доведённых до прода. Это и будет ваш proof.

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

Фаза 2. Расширение

Когда у ребят появятся credible results — открываете invitation. Не «теперь все попробуют», а «вот что мы напробовали — теперь доступно всем желающим». Скиллы и контекстный слой в репозитории, документация, может быть один внутренний митап, на котором коллеги на опыте показывают как они работают. Без давления.

Дальше — наблюдаете. Кто‑то подключится сразу, кто‑то через месяц, кто‑то через три. Это нормально. Pull‑модель не в том, что все приходят в один день. Pull в том, что приходят сами.

Скептиков не трогаете вообще. Кто‑то из них присоединится, увидев результаты коллег. Кто‑то — после того, как сам упрётся в стену, которую workflow решает. Кто‑то — никогда. С последним сценарием тоже надо уметь жить: не каждый разработчик должен работать с агентами, и попытка натянуть workflow на всех — та самая push‑модель в новой обёртке.

Фаза 3. Стандарт

Когда 70–80% команды устойчиво использует workflow — формализуете. Не раньше. AGENTS.md в репо обязателен, harness стандартизирован, скиллы централизованы и поддерживаются. На этой фазе — да, можно требовать. Но требование звучит не «использовать ИИ», а «соблюдать конвенции репозитория». Кто пишет руками — пожалуйста, главное — конвенции.

Никогда не вводите KPI «процент кода от ИИ». Это самая популярная и самая разрушительная метрика во всех push‑внедрениях, которые я видел. Она оптимизирует ровно то, что не нужно оптимизировать, и поощряет ровно то поведение, от которого workflow призван защитить.

А что по метрикам:

• Lead time от взятия задачи в работу до мержа PR. Не должна расти. Если с колес видите буст к скорости — команда слишком положилась на ИИ, что тоже не гуд. Улучшение этой метрики должно рассматриваться вкупе с метриками, озвученными ниже.

• Review Throughput на ревьюера — сколько PR в неделю на одного ревьюера и сколько времени тратится. Ваш канарейка против скрытого возврата к push‑модели. Если кто‑то в команде начинает генерировать в режиме «сделал — отправил» (то самое поведение, от которого мы уходили), нагрузка на ревьюеров уйдёт в потолок раньше, чем это поймают другие метрики.

• PR Rework Rate — доля PR, которые после первого ревью требуют существенных изменений (не косметика, не комменты, а переписывание логики). Не должна расти. Если растёт — значит, brainstorm/planning пропускаются, и workflow деградирует в «генерацию по запросу».

• Mean Time to Recovery — время от инцидента до восстановления. Косвенно показывает, насколько команда понимает код, который она производит. Здесь самый коварный риск ИИ‑внедрения: код пишется быстрее, но если автор не до конца его понимает (потому что больше делегировал, чем думал) — на инциденте это вылезает. MTTR растёт = deskilling реализовался, надо пересматривать workflow в сторону большей вовлечённости человека на этапе brainstorm/planning.

• Простой опрос внутри команды раз в спринт‑два. Один вопрос: «насколько workflow помогает или мешает работать?». NPS‑формат. Цифра не важна — важна динамика.

Чего НЕ мерить:

• Процент кода, написанного ИИ. Бессмысленная метрика, оптимизируется тривиально, поощряет вред.

• Скорость генерации. Меряет инструмент, а не продуктивность.

• Объём строк кода в PR. Агент склонен раздувать решения, эта метрика поощряет именно это.

Вредные антипаттерны

Короткий чеклист того, что ломает pull‑модель за один шаг:

• Дедлайн на внедрение. «К концу квартала все используют» = push.

• KPI «процент кода от ИИ». Уже объяснил.

• Публичные сравнения. «Вот Вася сделал в 2 раза быстрее, потому что использует агента» — гарантия того, что Вася станет изгоем, а остальные начнут саботировать осознанно.

• Запрет писать руками. Если задача мелкая или очевидная — workflow избыточен. Запрет = бессмысленная фрустрация.

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

• Принимать метрики снаружи. Если стандарты внедрения приходят с уровня выше вашей команды — у вас не команда, у вас цех. Защищайте автономию.

Ваш вклад как тимлида тут — не в скорости внедрения. Через 3–6 месяцев у вас в команде должна прорасти зрелая инженераная практика, а не подгоревший коллектив в состоянии итальянской забастовки.

Финал

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

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

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

И именно поэтому push‑модель никогда не даст этого результата, сколько KPI ни вводи. Принуждение отбирает у инженера авторство и подменяет мышление генерацией. Вовлечение — заставляет мышление работать жёстче, чем оно работало без агента. Разница не в скорости. Разница в том, что становится с командой через год.

Ваша роль как тимлида — создать пространство, в котором это возможно. Скиллы, контекстный слой, фазы развёртывания, защита автономии команды от внешних метрик. Дальше синьоры справятся сами. На то они и синьоры.

---

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

Удачи и успехов!