Что опыт Skyscanner доказывает в отношении верификации кода, созданного ИИ

В последнем эпизоде The Next Commit главный инженер Skyscanner Майкл Твид поговорил с Томом Хаулеттом из Sonar о внедрении агентов кодирования на базе ИИ в крупной инженерной организации. Разговор постоянно возвращался к одному вопросу, с которым сейчас сталкивается каждая команда, внедряющая агентов: когда инженеры перестанут читать каждую строку кода, кому вы доверите выявление ошибок? Мнение Майкла имеет вес, потому что оно отражает внедрение, которое уже находится в производстве. Некоторые из предположений, лежащих в основе его внедрения, заслуживают более пристального внимания. К концу эпизода стало ясно одно заключение: когда люди перестанут читать каждую строку, проверка кода, сгенерированного ИИ, должна осуществляться независимо от людей и моделей, которые его написали, с использованием детерминированных, автоматизированных проверок.

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

Переосмысление того, как команды проверяют код ИИ

Одна история, которую рассказал Майкл, напрямую указывает на суть проблемы:

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

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

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

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

Майклу не нужно было, чтобы кто-то делал это заключение за него.

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

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

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

Верификация принадлежит циклам

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

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

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

Возможность не всегда означает правильность

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

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

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

Осторожное продвижение верификации к производству

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

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

Вывод

Внедрение ИИ в Skyscanner показывает, как разрыв между успешными проверками и правильным кодом проявляется в производственном масштабе. Зеленый CI и самопроверка агента подтверждают, что проверки были выполнены, но не говорят ничего о том, правильный ли код, и, как показывает тест саморедагирования Майкла, они могут даже сказать вам противоположное от истины.

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

Узнайте, как независимая, нулевой доверия, многослойная верификация кода, сгенерированного ИИ, Sonar работает в цикле агента, цикле верификации CI и цикле поддержки кода.