Работа ведущего инженера с ассистентом без потери суждения

Почему скорость порождает новые ошибки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Окончательное одобрение тоже остаётся за человеком, даже если ассистент сделал большую часть печати. Это одобрение должно значить больше, чем "выглядит нормально". Владелец должен проверить тот компромисс, который важен для задачи. Иногда это задержка (latency). Иногда — нагрузка на поддержку, риск отката или простая читаемость.

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

Как задать защитные рамки до начала работы

Скорость быстро растёт, когда команда начинает пользоваться ассистентом. Дрейф тоже растёт быстро. Исправление простое: установите границы до того, как кто‑то начнёт писать код.

Начните с одного предложения, которое определяет задачу. Держите его простым. "Добавить логику повторных попыток для неудачной доставки webhook без изменения публичного API" куда лучше длинного брифа с кучей примечаний. Короткое заявление даёт инженеру критерий для суждения, когда ассистент начнёт предлагать лишнюю работу.

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

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

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

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

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

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

Обычно это занимает десять минут. Может сэкономить часы переделок.

Как ревьюить работу, не замедляя процесс

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

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

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

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

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

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

Как целенаправленно решать компромиссы

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

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

Экономия времени сейчас всегда появится как стоимость где‑то ещё. Иногда эта цена допустима. Быстрое исправление для внутренней админки может стоить небольшой уборки позже. Тот же самый обход в биллинге — плохая ставка.

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

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

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

Это также тот тип суждения, о котором часто говорит Oleg Sotnikov в своей работе как AI‑first CTO: используйте ассистентов, чтобы убрать рутинную нагрузку, но сохраняйте человеческое ревью за решениями, которые влияют на надёжность, стоимость и будущую сложность. Такое разделение сохраняет пользу от скорости.

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

Команда хочет добавить лимиты использования для платной фичи. На бумаге правило выглядит просто: клиенты на базовом плане могут запускать её 100 раз в месяц, у клиентов на более высоком плане — больше. Ассистент быстро набрасывает первый проход: изменения схемы для месячного учёта использования и проверки в API, которые блокируют запросы после превышения лимита.

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

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

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

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

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

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

Распространённые ошибки, которые ослабляют суждение

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

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

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

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

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

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

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

Ведущие инженеры должны трактовать недостающие правила как открытые вопросы, а не как промпты для кода. Запишите неизвестности. Попросите продукт или операции дать ответы. Код должен следовать правилу, а не создавать его.

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

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

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

Быстрые проверки перед релизом

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

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

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

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

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

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

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

Весь чеклист короткий специально. Он не замедляет команду. Он не даёт скорости превратиться в работу по уборке завтра.

Следующие шаги для небольшой команды

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

Держите рутину скучной две недели. Используйте один стиль промптов, те же шаги ревью и одно правило одобрения. Этот интервал достаточно длинный, чтобы увидеть паттерны, и достаточно короткий, чтобы изменить курс без больших потерь. Цель — не голый объём, а более быстрый вывод, который по‑прежнему проходит человеческое суждение.

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

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

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