На протяжении большей части человеческой истории мы оценивали качество кода с помощью код-ревью: кто-то читает то, что вы написали, и проверяет, что код чистый, продуманный, быстрый, понятный и хорошо тестируется. Для агентов такой подход плохо масштабируется: кода слишком много, чтобы кто-то мог его прочитать. В результате всё больше проверок качества должны происходить в среде исполнения, окружении и операционной системе вокруг агента. Я по-прежнему читаю и рецензирую код, но очень осознанно подхожу к тому, где мне комфортно полагаться на ограничения как на средство проверки.
Качество программного обеспечения теперь зависит от ограничений, которые вы устанавливаете вокруг своих агентов.
Список Гильермо — хорошая проверка того, можете ли вы позволить себе не читать код. Обратите внимание: каждый ответ «да» на самом деле означает, насколько низки ставки — нет пользователей, одноразовый код, прототип. Как только ставки растут, кто-то должен читать код. Если это не вы на каждом диффе, то это должны быть ограничения.
Ограничения определяют, что системе разрешено делать, «подбрасывая» тесты и детерминированные ограничения на предложения агента. Именно устанавливая и поддерживая эти ограничения, мы создаём циклы, которые стабильно обеспечивают высокое качество производственного кода, даже когда агенты каждый день создают сотни тысяч или миллионы изменений.
Мы называем эти ограничения шлюзами качества, и они принимают множество форм.
Они включают обычные модульные тесты, тесты свойств и приёмочные тесты. Они включают мутационное тестирование, при котором мы генерируем вариации кода, прогоняем их через те же тесты и убеждаемся, что никто не протаскивает ошибки, которые мы могли пропустить. Это также метрики качества кода, такие как цикломатическая сложность и длина строк, которые помогают сохранять читаемость.
Два человека могут расходиться во мнении о том, нужно ли читать код, и при этом соглашаться по поводу механизма. Гильермо его читает. Боб не читает ничего. Оба описывают полосу препятствий — разница лишь в том, находится ли внутри неё человек (я не разделяю остальные взгляды Боба).
Ограничения также играют важную роль в том, какие предложения система примет и применит в качестве изменений кода. К тому моменту, когда предложение об изменении переходит от интерпретатора, запускающего агента, к контроллеру агента и затем в продакшен, мы уже выполнили достаточно проверок, чтобы быть уверенными: его безопасно выпускать, а влияние изменения полностью находится в рамках полномочий агента.
Агент может предложить что угодно. Ваши ограничения решают, достаточно ли предложение безопасно, корректно, ограничено по охвату и полезно, чтобы вы и ваша команда могли его выпустить.
Эта модель даёт многое, но также упускает многие детали, и об этих упущениях стоит задуматься уже сегодня. Один из вопросов — автономность: агенты могут хорошо реализовывать свои намерения, но могут ошибаться, когда информации не хватает или когда их задача неоднозначна. Это касается и самой задачи, и того, как она параметризуется средой исполнения, окружением и другими компонентами.
Многие причины, по которым люди не могут выпускать отличный код, характерны и для агентов: хрупкие среды, не выдерживающие нагрузки от скриптов, недетерминированные сборки, отсутствующие разрешения и слабые тесты. Это подталкивает к созданию лучшей среды, которая даёт агентам надёжную обратную связь, допускает сбои с малым ущербом и позволяет постепенно наращивать успех.
Среда, к которой мы стремимся, — это среда, где агент может выполнять реальную работу, получать обратную связь, которой можно доверять, и ошибаться без серьёзного ущерба.
Ещё один важный вопрос — доверие. Мы не можем доверчиво передавать намерения чему-то, даже такому умному и надёжному, как современный агент, не проверив корректность. Мы начинаем с доверия, но его нужно заслужить.
Одни ограничения формируют работу до её начала. Другие дают обратную связь, пока агент работает. Третьи решают, может ли его результат вообще пересечь границу продакшена.
Существует множество способов выстроить структуру проверок вокруг системы.
На мой взгляд, полезно иметь более широкий, но осознанно выбранный набор проверок для ваших ограничений, а не полагаться только на модульные тесты. Идея в том, что у каждой проверки есть своя зона ответственности — от безопасности типов и производительности до сканирования безопасности на поздних этапах. Люди также могут задавать собственные ограничения, включая правила архитектуры, которые могут обеспечивать такие инструменты линтинга, как ESLint. У многих таких инструментов есть встроенные хуки, позволяющие подключать агентов или людей, когда что-то ломается.
Пока что бо́льшая часть разницы между полезным результатом агента и мусором сводится к мастерству команды, управляющей этим циклом.
ИИ даёт нам генерацию кода в больших объёмах и высокую скорость, но это также означает, что людям становится труднее проверять каждое изменение. Вместо этого нужно осознанно решать, куда направлять их внимание. Если вы встраиваете человеческую проверку в систему, которая в остальном работает на скорости машины, не удивляйтесь, что это скажется на производительности. Человеческое внимание ограничено и ценно, поэтому мы должны заранее направлять его на самые тонкие проблемы, требующие нашего суждения. Людей на последующих этапах следует привлекать только тогда, когда автоматические механизмы защиты ограничений выходят из строя.
Человеческое «код-ревью» в будущем будет выглядеть совсем иначе
Корректность — важное измерение, но вам могут быть важны и другие: поддерживаемость, производительность, безопасность, эффективность и понятность. Как корректность распадается на множество типов сигналов, так и остальное качество. И хотя количество установленных ограничений имеет значение, важнее то, насколько они строги, чтобы соответствовать нашей планке качества и готовности к продакшену.
Качество программного обеспечения — это не единая метрика. Относитесь к нему как к набору сигналов, имеющих разную важность для вас и вашей команды.
Противодавление может быть реализовано с помощью многих инструментов: компиляторы отклоняют некорректный код, тесты падают, политики безопасности блокируют плохие практики, CI отказывается выполнять деплой. В идеале оно должно существовать на протяжении всего цикла, а не один раз в самом конце работы.
Карта того же цикла от Декса Хорти из статьи «Why Software Factories Fail». Зелёный блок — его аргумент, что на данный момент человеческое ревью должно вернуться в цикл, а не быть заменено им.
Ограничения и противодавление позволяют агентам отсекать плохую работу до того, как она станет проблемой
Что происходит, если мы не можем применить ограничение, потому что объём изменений превышает возможности наших инструментов? Мы в итоге выстраиваем очередь и полагаемся на систему проверок, которая работает на скорости человека. Чтобы масштабироваться, мы хотим как можно больше проверок встроить в цикл на всём протяжении, а не ждать до конца. Если мы можем масштабироваться в рамках автоматических проверок, то увеличиваем скорость и пропускную способность всей нашей системы доставки. Если в цикле проверок заканчивается место, нам нужно сделать одно из нескольких.
Во-первых, мы можем масштабировать систему проверок и создать больше возможностей для сдерживания и отклонения поступающих изменений. Во-вторых, мы можем снизить скорость генерации новых изменений агентами, чтобы проверки успевали за объёмом работы. В-третьих, мы можем снизить планку качества, чтобы проверки не отклоняли изменения так жёстко, как могли бы. С точки зрения масштабирования нам нужно быть готовыми ко всем этим действиям. При этом нельзя упускать из виду, что мы могли бы добиться большего, снимая ограничения в некоторых направлениях. Возможно, мы можем увеличить скорость создания изменений агентами, предоставив рои агентов-разработчиков или автоматизированные фабрики программного обеспечения, которые создают изменения, не дожидаясь нашего ревью каждого из них.
И в некоторых местах мы можем захотеть дать им больше свободы, сохраняя более жёсткие ограничения в других. Обеспечивая более строгие ограничения там, где это для нас важнее всего, мы можем максимизировать пропускную способность, не жертвуя качеством. Во всех этих решениях много вариантов. Очевиднее всего, нам приходится выбирать между разными аспектами качества. Как мы уже подчёркивали, безопасность очень важна, но нам также приходилось выбирать между обеспечением безопасности и своевременной поставкой продукта. Есть спектр: на одном конце — ориентация на инновации, на другом — на качество. Где-то на этом пути нам нужно определить, где мы хотим находиться.
Мы хотим передавать чёткую обратную связь из среды и системы обратно нашим агентам или командам, чтобы люди могли сосредоточиться на более субъективных аспектах: вкусе, намерениях и архитектуре. Если мы поможем людям оставаться в безопасных рамках ограничений, им не придётся изо всех сил разбираться, где что пошло не так.
Качество программного обеспечения — это не только корректность. Это также поддерживаемость, хорошая производительность, безопасность, эффективность и понятность. Все ограничения, которые помогают нам соответствовать этим стандартам и поддерживать поток производственных изменений, создают противодавление в конвейере доставки.
Нам нужно принимать осознанные решения о том, где применять строгие ограничения, а где ослаблять или убирать их. Применяйте строгие ограничения там, где они служат обеим целям. Не поддерживайте их, если они не служат ни одной из них. Будьте готовы повышать или понижать планку по мере необходимости. И помните: именно эти ограничения в разных точках программной системы делают качество ПО гарантированным.
Мы должны применять строгие ограничения там, где они лучше всего послужат этой двойной цели, и рассмотреть возможность удаления или ослабления ограничений, которые не служат ни одной из целей как следует. Мы также должны быть готовы поднимать или опускать планку качества по мере необходимости. По сути, именно эти ограничения в разных точках нашей программной системы дают качеству реальную силу. Во многих случаях мы можем усилить противодавление и создать больше ограничений, развернув новые инструменты или укрепив уже существующие. Всё это можно использовать для отклонения большинства запросов на изменения. Мы хотим встраивать эти механизмы на всём протяжении конвейера.
Мы не хотим ждать до конца конвейера, когда наша CI-система просто скажет, что деплой невозможен без исправления проблем. Мы хотим использовать эти сигналы как можно раньше, по всем возможным каналам. Конечное ограничение в этой системе — то, которое мы накладываем на себя: отвечать за решения и действия, которые мы предприняли для создания системы и управления ею. Но, как и в случае с другими ограничениями, нам нужно тщательно взвешивать, насколько мы хотим, чтобы наше собственное суждение сдерживало, создавало противодавление и служило финальной проверкой.
Качество — в ограничениях, которые мы размещаем вокруг наших агентов. Поэтому, когда вы думаете о качестве для своих приложений, возьмите эту постановку задачи и разработайте собственный план, основанный на ограничениях.
Кстати, о качестве: агенты пишут ваш код. Sonar даёт вам шлюз качества, чтобы выпустить его. Он запускает одну и ту же полную проверку на каждом коммите: глубокий межфайловый анализ, карту расположения рисков и шлюз качества, который удерживает всех — и людей, и агентов — на одной планке.
Эта статья была оценена как 100% написана человеком сервисом Pangram 4.
