Скорость сместила узкое место, но не убрала работу

В 5-м эпизоде подкаста The Next Commit Кеша Михайлов (Principal Engineer в Fin) описывает сдвиг, который сегодня замечают большинство инженерных команд. ИИ-агенты для написания кода сделали реализацию практически бесплатной. Тяжелая работа не исчезла. Она переместилась.

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

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

Почему ИИ-агенты для написания кода увеличивают объем работы по проверке вместо того, чтобы сокращать ее?

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

Агенты разрушили этот процесс, и Кеша наблюдал это в Slack-канале, где инженеры Fin делятся техническими планами. «С появлением ИИ и той скоростью, с которой теперь генерируется код, возникает огромный соблазн пропустить этот этап», — говорит он. «Мы видим все меньше и меньше таких техпланов в канале. Они почти исчезли». А вместе с ними исчезли и обсуждения, которые выявляли скрытые ограничения и объясняли новичкам, почему система была спроектирована именно так.

Более широкий спектр последствий мы наблюдаем во всей индустрии:

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

Как проверять созданный ИИ код в масштабе?

Вместо того чтобы читать разработчикам лекции о дисциплине, подход в Fin изменил экономику самого рабочего процесса:

Пул-реквест (pull request) размером выше определенного лимита не может быть одобрен автоматически, в то время как небольшое безопасное изменение — может. Ограничение по размеру работает как предохранитель, а автоодобрение — как награда, поэтому разработчики, выпускающие изменения меньшими порциями, тратят меньше времени на ожидание проверки человеком.

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

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

Переход Fin с Ember.js на React иллюстрирует, что ломается, когда генерация опережает стандарты проверки.

React позволяет командам собирать совершенно разные стеки вокруг одной библиотеки. Эксперты Fin выбрали определенные паттерны для форм, валидации и доступа к API, но ранние агенты выдавали масштабные изменения на React, которые полностью игнорировали эти решения. Небольшая группа старших инженеров превратилась в финальный уровень проверки, приняв на себя непосильный объем ревью пул-реквестов.

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

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

Верификатор полезен только тогда, когда люди могут ему доверять

Разработчики Fin активно полагались на своего кастомного агента проверки по имени Шрек (Shrek). Они добивались зеленого статуса у агента, прежде чем показать изменения человеку, что делало качество верификатора прямым фактором успешности поставки.

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

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

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

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

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

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

Основные выводы

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

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

Послушайте 5-й эпизод подкаста The Next Commit, чтобы узнать, как Кеша и Том обсуждают эту историю целиком.