Агенты сделали код доступным в изобилии, но уверенность в дефиците — в частности, уверенность в том, что код корректен, безопасен и готов к релизу. Разработчики говорят нам, что 5% организаций сегодня используют фабрики программного обеспечения с ИИ, а 34% планируют сделать это в течение года. Поскольку фабрики берут на себя все большую часть работы, качество выпускаемого ими продукта будет зависеть не столько от того, какая модель пишет код, сколько от того, насколько качественно каждая фабрика его проверяет. Командам необходимо закладывать уверенность в фабрику программного обеспечения так же, как они закладывают надежность в любую производственную систему, и эта работа начинается с верификации.
Бенедикт Стеммильдт, соучредитель и содиректор hackers&wizards и соавтор (вместе с Алексом Мерседом) книги Building the Agentic Software Factory, ежедневно разрабатывает такие системы вместе с клиентами. В последнем эпизоде подкаста The Next Commit он рассказал ведущему Тому Хаулетту, что «в конечном счете все сводится к доверию». Для Бенедикта создание такого доверия означает проектирование фабрик для работы без участия человека и предоставление им проверок, на которые команда может полагаться вместо чтения каждого изменения.
Превращайте каждый сбой в проверку
Команды совершенствуют фабрику программного обеспечения, превращая каждый сбой в новую проверку, которую фабрика применяет к каждому изменению. В этом смысле верификация — это система обратной связи фабрики. Команды получают от нее максимум пользы, когда запускают проверки внутри циклов разработки, начиная с агентского цикла, чтобы каждая проверка могла влиять на изменения в процессе их написания агентом. Команды, которые строят процесс таким образом, в итоге получают четкие намерения, защитные механизмы, удерживающие агентов в рамках, независимую верификацию и доказательства того, что каждая проверка была выполнена. Фабрика, которая не дотягивает хотя бы до одного из этих пунктов, не дает своим владельцам никаких причин доверять тому, что она выпускает.
Когда Бенедикт находит проблему в продукте фабрики, он не трогает код функции, а меняет саму фабрику. «Я проверяю артефакт, созданный фабрикой, — говорит он. — Если я вижу что-то, чего мы не хотели, я исправляю фабрику». Он также начинает работу с клиентами с узких повторяющихся задач, таких как обновление зависимостей, поскольку команда заранее знает, какие проверки требуются для этого направления до запуска фабрики.
Для уверенности нужны оба вида верификации
Sonar внедряет два вида верификации на каждом этапе. Детерминированная верификация — это повторяемая оценка на основе структурных правил и известных паттернов, которая дает одинаковый результат каждый раз и не меняет его под давлением, что делает ее надежным барьером для стандартов, написанных командой. Агентная верификация применяет осознанные рассуждения с учетом контекста для проверки намерений и обнаружения аномалий, охватывая бизнес-логику, глубокую семантику и другие проблемы, которые не может предусмотреть ни одно правило. Командам нужны оба вида, потому что каждый проверяет то, чего не может другой.
Бенедикт поддерживает такой же баланс на своих фабриках, добавляя правила линтинга и тесты ArchUnit, «чтобы вы могли больше доверять недетерминированности», и решая контекстные проблемы с помощью навыков и инструкций. Он предупреждает, что фабрика, перегруженная слишком большим количеством жестких ограничений, становится «похожей на клетку», которая застопоривается или постоянно требует вмешательства человека, в то время как фабрика с недостаточным их количеством не дает владельцам повода для доверия.
Оба вида также должны работать независимо от агента, модели или разработчика, написавшего код. Sonar выполняет верификацию отдельно от агентов и моделей, используемых командой, поэтому один стандарт действует для всех них, включая код, написанный людьми. Фабрика, которая просит другую модель оценить свой результат, наследует непоследовательность этой модели, и недавние исследования показывают, что передовые языковые модели в роли судей меняют от 7% до 17% своих вердиктов, когда им задают тот же вопрос повторно, даже при полностью отключенной случайности.
Как отмечает Бенедикт, команды доверяют старшим инженерам, несмотря на то, что люди недетерминированы, поскольку старший инженер работает в известных пределах и не сделает ничего безумно неправильного. Агенты не дают таких гарантий, и он описывает результаты, которые заставляют вас задаться вопросом: «какого черта тут происходит?». Командам нужны проверки, которые остаются неизменными независимо от того, какой агент внес изменения.
Единый стандарт, который обучает агента в каждом цикле
Проверка, которая лишь сообщает о проблеме, побуждает агента заставить предупреждение исчезнуть, и пример Бенедикта с линтером наглядно демонстрирует эту стоимость. Линтер отмечает 15-строчный метод как нарушающий лимит в 10 строк, и агент «просто разрезает его пополам», создавая два более коротких метода, которые проходят проверку и ухудшают дизайн. Опытный разработчик воспринял бы предупреждение как повод переосмыслить обязанности метода, но это понимание никогда не появляется в сообщении. Бенедикт утверждает, что большая часть наших инструментов была написана для старших инженеров, в то время как агентам требуется явное руководство, точно так же, как младшим разработчикам.
Продукты Sonar включают описания правил, объясняющие, почему проблема важна, и рекомендации по исправлению, указывающие на надежное решение, что дает агенту контекст для устранения первопричины, а не обхода проверки. Sonar применяет этот стандарт везде, где агенты касаются кода. В агентском цикле Sonar Vortex предоставляет агенту контекст и ограничения перед началом написания, проверяет каждое изменение по тому же профилю качества SonarQube, который служит барьером для слияния, и побуждает агента исправить свой вывод при сбое проверки. В цикле верификации CI SonarQube задает стандарт с помощью профилей качества и шлюзов качества, а Gitar проверяет каждый пул-реквест на логику и намерения и выполняет итерации исправлений до тех пор, пока CI не станет зеленым. SonarQube задает стандарт; Gitar обеспечивает его соблюдение на скорости слияния. В цикле обслуживания кода SonarQube Remediation Agent устраняет проблемы в фоновом режиме и перепроверяет каждое исправление с помощью движка, который его обнаружил, поэтому в релиз попадают только проверенные исправления. Каждая проверка оставляет последовательную, проверяемую запись, которая помогает команде понять кодовую базу, которую она больше не читает строка за строкой.
Бенедикт считает владение этим стандартом самой сложной частью создания фабрик. «Когда мы строим фабрики с нашими клиентами, это вовсе не технологическая проблема, совсем нет», — говорит он. Он описывает фабрику как внутренний продукт, создаваемый инженерами фабрики и подпитываемый продуктовыми инженерами, которые тесно сотрудничают с бизнесом, и отмечает, что команды все еще выясняют, кому принадлежат контекст, навыки и верификация между ними. Общий стандарт верификации дает обеим группам одинаковое определение понятия «хорошо».
Решение о том, что фабрика считает «хорошим»
Команды, создающие фабрики программного обеспечения сегодня, сами будут решать, что их фабрики считают «хорошим». Бенедикт завершил эпизод советом разработчикам, адаптирующимся к изменениям: «Найдите свой новый поток, потому что это никуда не денется».
Listen to the full episode of The Next Commit with Benedikt Stemmildt, а затем изучите, как проверка кода на основе ИИ от Sonar вписывается в вашу фабрику программного обеспечения.
