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

Почему хорошие инженеры всё ещё сомневаются в результатах ассистента

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

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

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

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

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

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

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

Выберите узкий тест, прежде чем прививать привычки

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

Начните с одной маленькой задачи, которая часто повторяется и имеет явную точку завершения. Хорошие варианты: написание unit-тестов для существующей функции, небольшой рефактор или превращение отчёта об ошибке в первичную заплатку. Эти задачи достаточно узкие, чтобы быстро их проверить, но при этом они дают достаточно результата, чтобы судить.

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

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

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

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

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

Небольшой пример делает это конкретным. Если команда хочет протестировать помощь ассистента в бекэнд-работе, «помощь в разработке сервиса» слишком широко. Лучше выбрать одну задачу: сгенерировать table-driven тесты для обработчиков в сервисе на Go. Старшие рецензенты уже знают кодовую базу, ожидаемый стиль и случаи отказов. Через неделю команда сможет ответить на конкретные вопросы: сколько черновиков экономило время, сколько требовало существенной переработки и где ассистент постоянно делал одну и ту же ошибку.

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

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

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

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

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

Простой чеклист достаточен:

• Решена ли задача?
• Добавились ли ошибки?
• Делает ли ассистент догадки вместо проверки фактов?
• Пропустил ли он тесты, пограничные случаи или ограничения?
• Сэкономило ли это реальное время?

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

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

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

Простой раскат, который формирует доверие

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

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

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

Короткая карточка оценки держит пилот честным:

• тип задачи
• время до первого черновика
• время ревью
• число исправлений
• отправилась ли правка чистой в релиз

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

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

Базовый контроль:

• Время ревью не растёт или падает.
• Количество ошибок не увеличивается.
• Инженеры могут объяснить итоговый код.
• Обычные правила ревью по-прежнему применяются.

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

Чему должны учить примеры провалов

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

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

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

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

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

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

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

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

Реалистичный пример от небольшой команды

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

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

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

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

Что они меняют дальше

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

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

В следующий раз команда даёт ассистенту лучший шаблон и просит включить SQL для отката прямо в подсказке. Черновик улучшается. Важнее то, что команда теперь больше доверяет процессу, а не самому черновику.

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

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

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

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

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

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

Отслеживайте обе стороны компромисса:

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

Последнее число важнее, чем ожидают многие команды. Если люди тихо переписывают половину вывода, пилот почти ничего не экономит.

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

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

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

Если правило говорит «не использовать вывод ассистента для auth, биллинга или инцидентных исправлений без полного ревью», — соблюдайте его. Пилот заслуживает доверие, когда правила работают в напряжённые дни, а не только в спокойные.

Быстрая проверка перед расширением

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

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

Короткий чеклист честно держит ситуацию:

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

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

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

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

Что делать после первого пилота

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

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

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

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

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

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

Если вашей команде нужен внешний обзор, Oleg Sotnikov на oleg.is может посмотреть пилот, указать слабые предположения и помочь написать практичные правила использования AI в инженерной работе. Такой обзор наиболее полезен после одного узкого пилота, когда у команды есть реальные доказательства, а не только мнения.