Управление инженерами с ИИ-ассистентами после исчезновения шаблонной работы

Что меняется, когда исчезает мелкая рутинная работа

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

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

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

Давление на ревью тоже меняется. Код попадает на ревью быстрее, поэтому узкое место смещается с написания на проверку. Один инженер может открыть больше pull request за день, но у ревьюеров, QA и продуктовых лидов не появляется дополнительных часов. Если сохранить прежние привычки ревью, очереди быстро разрастутся.

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

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

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

Что теперь должно покрывать планирование

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

Начните с результата. Скажите, что должно работать, кто будет пользоваться, какие входы важны и что нельзя нарушать. «Добавить экспорт» слишком расплывчато. «Экспортировать заказы в CSV, включить эти шесть полей, сохранить текущие фильтры и укладываться в пять секунд» даёт инженеру конкретику для разработки и проверки.

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

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

Полезный бриф задачи покрывает пять вещей:

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

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

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

Как планировать работу шаг за шагом

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

Короткий поток планирования работает так:

1. Опишите пользовательскую проблему в одном ясном предложении, затем добавьте одну цифру, которая покажет, помогла ли работа. Это может быть просто: сократить время отчёта с двадцати минут до пяти.
2. Выделите части, где решение должен принять человек. Обычно это продуктовые компромиссы, безопасность, правила работы с данными, нейминг и всё, что пользователи заметят сразу.
3. Назначьте одного инженера владельцем финального результата. Другие люди и ассистент могут помогать, но один человек должен отвечать за то, что уйдёт в прод.
4. Поставьте промежуточную проверку в календаре до полного ревью. Попросите демо, короткий дифф или пример вывода, чтобы ловить неверное направление рано.
5. В конце сравните результат с изначальной проблемой и выбранной вами метрикой. Если команда выпустила больше кода, но не добилась цели — скажите об этом прямо.

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

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

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

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

Как меняется ревью, когда код приходит быстрее

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

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

Хорошее ревью теперь начинается с нескольких прямых вопросов:

• Какую проблему решает это изменение?
• Какие части написал ассистент?
• Где инженер принял подсказки без существенных правок?
• Какие допущения могут быть неверны?
• Какие крайние случаи всё ещё нужно проверить вручную?

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

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

Pull request тоже должны становиться меньше. Когда код появляется быстро, инженеры склонны сваливать больше изменений в одну ветку. Это кажется эффективным, но обычно ухудшает качество ревью. Pull request на 600 строк, написанный за один день, может занять больше времени на грамотное ревью, чем три меньших, отправленных в тот же день.

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

Если одни и те же комментарии повторяются, не переписывайте их вручную. Превратите их в командные правила, чеклисты, линтеры или подсказки для ассистента. Если ревьюеры часто пишут «покрой пустой ввод» или «используйте доменные имена, а не общие helper-имена», добавьте это в prompt и шаблон pull request.

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

Как выглядит хорошая обратная связь по эффективности теперь

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

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

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

В каждом цикле ревью обсуждайте всю работу, а не только дифф. Тесты, короткие документы и заметки для передачи считаются, потому что они показывают, взял ли инженер владение над результатом после того, как ассистент сгенерировал первую версию. На 1:1 спрашивайте, как люди реально используют ассистентов в повседневке. Один инженер может применять ИИ для настройки тестов и рефакторов. Другой может опираться на него слишком рано и пропускать явные ошибки. На бумаге они могут выглядеть одинаково быстрыми, но им нужна совершенно разная обратная связь.

Разделяйте скорость и владение при обратной связи. «Ты двигался быстро» — не то же самое, что «ты сделал это безопасным для релиза». Когда оба верны, скажите оба. Когда верно только одно — говорите прямо.

Хорошая заметка звучит так: «Ты быстро обновил API, но первый черновик от ИИ пропускал крайние случаи, и ты обнаружил их поздно. В следующий раз проверяй пути падения раньше и оставляй короткую заметку для передачи». Такая обратная связь конкретна, справедлива и выполнима.

Простой командный пример

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

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

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

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

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

Менеджер не считает этот баг доказательством того, что ассистент провалился. Он видит это как пробел в планировании. В следующем спринте команда добавляет четыре небольшие привычки: пятнадцатиминутная проверка в середине недели, чеклист ревью для рискованных пользовательских потоков, один ручной тест на мобильном перед началом QA и заметка с шагами отката для изменений в signup.

Эти изменения почти не замедляют команду. Зато они экономят переработку и делают ревью спокойнее, потому что все знают, что проверять.

Ошибки менеджеров в начале

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

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

Ещё одна ловушка — переоценка лучшего промптера в команде. Навык составления prompt полезен, но суждение по-прежнему решает, кому можно доверять. Если кто-то получает быстрые черновики, но упускает крайние случаи, не может объяснить компромиссы или постоянно загружает неряшливые изменения в ревью, то скорость — скорее театральность.

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

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

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

Еженедельные проверки, которые действительно помогают

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

Начните с того, как началась работа. Солидная задача называет результат, лимит и линию финиша. «Добавить OAuth для админов, сохранить текущий вход и добавить тесты для основного пути» даёт ясную цель. «Улучшить auth flow» — не даёт.

К концу недели смотрите на несколько паттернов:

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

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

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

Ещё одна проверка полезна: спросите команду, какую повторяющуюся рутину они сократили или убрали на этой неделе. Если ответ постоянно меняется — от подготовки тестов до заметок релиза или генерации API-stub — выгоды, вероятно, реальные. Если никто не может назвать ни одной — команда, возможно, просто генерирует больше вывода и называет это прогрессом.

Что делать дальше

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

Простой эксперимент достаточен:

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

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

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

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

Если команда стала быстрее, но менее предсказуемой, второй взгляд со стороны поможет. Oleg Sotnikov на oleg.is работает со стартапами и малыми компаниями как Fractional CTO и советник, с практическим опытом в разработке ПО, управляемой ИИ. Он помогает командам просматривать архитектуру, привычки доставки, инфраструктуру и переход на рабочие процессы с ИИ.

Сделайте одно изменение, прогоните его месяц и посмотрите, что стало спокойнее, яснее и более надёжным.