По мере того, как кодирование с помощью искусственного интеллекта переходит от промптов к циклам, верификация становится главной задачей для нативно-облачных команд разработчиков, пишет на портале The New Stack Арджун Айер, генеральный директор Signadot.
Недавно в дискуссии об ИИ-кодировании произошли перемены. Спор больше не о том, могут ли агенты писать производственный код или какая модель лучше. Он теперь о том, кто или что должен им подсказывать.
Теперь на слуху идея «проектировать циклы, которые выдают промпты вашим агентам». Становится ясно: формируется третья эра агентной разработки, и она поднимает важные вопросы о том, что делают инженеры, каковы затраты на доставку ПО и какая инфраструктура должна ее обеспечивать.
Для команд, создающих нативно-облачные приложения на Kubernetes, ответы на эти три вопроса вскоре будут иметь огромное значение.
Три эры, одно направление
Агентная разработка на каждом этапе эволюции продвигает человека на один уровень абстракции вверх.
Первая эпоха была ориентирована на промпты. Разработчик находился внутри цикла, набирая инструкции, читая вывод, внося исправления. Пропускная способность ограничивалась вниманием одного разработчика.
Вторая эпоха ориентирована на спецификации, и именно на этом этапе сегодня находится большинство команд, внедряющих подобные подходы. Разработчик инвестирует на начальном этапе: подробные спецификации, контекстные документы, соглашения, закодированные в репозитории. Агент выполняет действия в соответствии со спецификацией, а человек проверяет выполненную работу. Единица работы выросла из промпта в задачу.
Третья эпоха делает сам цикл единицей работы. Цикл — это небольшая программа, которая выдает агенту промпт, оценивает ответ, решает, достигнута ли цель, и, если нет, снова выдает промпт, используя полученные данные. Она работает по расписанию, а не зависит от внимания человека. Циклы запускают другие циклы.
Разработчик больше не пишет код и все чаще не пишет задачи. Он пишет систему, которая генерирует, оценивает и повторяет работу.
Скептики называют это «cron job (индивидуальное задание, которое выполняется согласно заданному расписанию) с улучшенным маркетингом», и это сравнение полезно для понимания того, где здесь возникают проблемы. Cron job выполняет фиксированный скрипт. В цикле же присутствует лицо, принимающее решения: модель, которая считывает состояние работы и выбирает следующее действие. Инженерная задача состоит в том, чтобы всё, что окружает это решение, сходилось к правильному результату, а не блуждало.
Кем становится разработчик
В мире, управляемом промптами, сила разработчика заключалась в умении управлять процессом. В мире, управляемом спецификациями, она заключается в ясности намерений.
В мире, управляемом циклами, сила — в качестве системы, окружающей агента. Важный инженерный вопрос сводится к следующему: что проверяет этот цикл, прежде чем объявить об успехе? Какую обратную связь он получает при сбое? Когда он останавливается?
Эти вопросы разделяют инженерную роль на две части. Разработчики приложений становятся авторами намерений и циклов: они решают, что создавать, и кодируют цель. Платформенные инженеры становятся владельцами того, что означает «сделано».
Проверки, выполняемые циклом, среды, в которых он выполняется, бюджет, в рамках которого он работает, и доказательства, прилагаемые к его результатам, — все это должно быть согласовано во всех циклах в организации, а не импровизироваться каждым из них.
Это знакомая схема, но с новой темой. Десять лет назад платформенные команды превратили CI/CD из чего-то, что каждая команда создавала на скорую руку, в мощеную дорогу. Уровень верификации для агентных циклов — это тот же переход, за исключением того, что он находится во внутреннем цикле, до появления каких-либо запросов на изменения (PR), независимо от параллелизма, который генерируют циклы.
Экономика: циклы сходятся или сгорают
Заманчиво предположить, что агенты сделали генерацию кода дешевой, поэтому все это не имеет значения. Это не совсем так.
Благодаря агентам генерация стала быстрой и дешевле, чем затраты на рабочее время разработчиков, но токены — это реальная и растущая статья расходов. Работа агента в течение нескольких часов — это решение о расходах, а цикл — это бесконечная работа агента по задумке. Бюджеты, сохранившиеся после интерактивных сессий, не обязательно сохранятся после циклов.
Первоочередная мера реагирования — это ограничители: лимиты итераций, обнаружение отсутствия прогресса и потолки затрат. Они необходимы, но они только ограничивают ущерб от неэффективного цикла. Они не делают его эффективным.
Эффективность цикла сводится к двум измерениям, и они перемножаются.
Первое — это качество обратной связи, которое определяет, сколько итераций требуется циклу. Цикл, получающий нечеткий сигнал об ошибке, пытается угадать причину и делает это снова. Цикл, получающий реальную ошибку от реальной системы с достаточным контекстом для локализации причины, исправляет фактическую проблему и переходит к следующему шагу. Качество обратной связи также определяет то, насколько правильным может быть цикл: он может сходиться только к тому, что видит его обратная связь.
Второе — это момент завершения цикла, который определяет стоимость каждой итерации. Если цикл завершается в CI или после PR, каждый цикл оплачивает выполнение конвейера плюс время ожидания в очереди, а частота выполнения составляет от минут до часов. Если же завершение происходит во внутреннем цикле, то при условии прямого доступа агента к среде выполнения частота составляет секунды.
Общая стоимость цикла — это произведение: количество итераций до проверки, умноженное на стоимость одной итерации.
Эти измерения также подпитывают друг друга. Если передавать достоверную обратную связь в CI, каждый цикл замедляется, пока агент обрабатывает частичные сигналы между ними. Если же включить её во внутренний цикл, то оба параметра сжимаются одновременно.
Нативные облачные системы поднимают планку качества «сделано»
Для изолированной программы оба измерения практически бесплатны. Набор тестов выполняется локально за секунды и сообщает всю правду, потому что вся правда локальна.
В распределенной системе правда не локальна. Изменение считается правильным или неправильным в зависимости от того, как оно взаимодействует с вызываемыми им сервисами, хранилищами данных и очередями, которые оно затрагивает, а также уровнями маршрутизации и политик, под которыми оно работает.
Обратная связь, которую агент может получить быстро, — локальные тесты и заглушки — является частичной. Обратная связь, которая сообщает правду, традиционно находится в CI и общей среде тестирования, где циклы медленные и конфликтные. Нативно-облачные команды вынуждены выбирать между быстрым циклом, который сходится к неправильной цели, и циклом, содержащим достоверную информацию, который итерируется со скоростью конвейера.
Традиционные варианты окружения неэффективны в масштабе агентов. Здесь важно следующее: в нативно-облачных системах обратная связь цикла должна поступать из среды выполнения, и эта среда должна быть доступна из внутреннего цикла. Архитектура нативно-облачного агентного цикла — это, по большей части, архитектура поверхности проверки, которую вы ему предоставляете.
Четыре уровня нативно-облачного агентного цикла
Полная система имеет четыре уровня. Сам цикл — это самая маленькая часть.
Уровень среды выполнения. Циклу требуется среда для каждой итерации, которая ведет себя как производственная среда, но не требует таких же затрат. Решение — легковесные временные среды на общем кластере: развертывайте только те сервисы, которые затрагиваются изменением, и используйте маршрутизацию запросов на одном общем кластере, чтобы направлять трафик цикла через них и через общую базовую конфигурацию для всего остального.
Среды материализуются за секунды, предельные затраты отслеживают измененные поды, а не весь стек, и обратная связь поступает из реальных зависимостей и реальных путей передачи данных. Именно это приводит к завершению цикла во внутренний цикл.
Интерфейс проверки. Агенты не просматривают панели мониторинга и не должны придумывать собственное определение завершения. Проверки, которые должно пройти изменение, должны быть частью декларативных рабочих процессов, которые платформенные команды определяют, версионируют и предоставляют агентам в качестве утвержденного способа подтверждения изменения.
Организация, а не агент, решает, что означает «прохождение». Доказательства, связанные с изменением, поступают из процесса, который могут проверять люди, и человеческая проверка может сосредоточиться на намерениях и дизайне.
Слой обратной связи. Это механизм сходимости. Бит «пройдено» или «не пройдено» указывает циклу на необходимость повторной попытки, но не на то, что нужно изменить. Среда выполнения должна возвращать структурированные результаты: какая проверка не удалась, журналы и трассировки, относящиеся к собственным запросам цикла, разница в поведении на границе, которая нарушилась.
Каждое увеличение точности обратной связи исключает догадки, а устранение догадок означает устранение затрат.
Слой управления. Бюджеты, потолки итераций, обнаружение отсутствия прогресса и надежная запись того, что было выполнено и доказано в каждом цикле. Это то, что позволяет организации уверенно выполнять множество циклов вместо одного, вызывающего беспокойство.
Когда расходы ограничены, а сходимость измеряется, агентная разработка становится возможностью, которую можно планировать, а не неожиданной статьей расходов.
«Пишите циклы, а не промпты» — это видимая вершина более масштабного заявления: теперь сила команды заключается в системе проверки, которую используют циклы, а эта система принадлежит организации, предоставляющей платформу.
С чего начать?
Переход к разработке на основе циклов не произойдет в результате какого-то одного решения. Он произойдет в результате сравнения эксперимента одной команды, который быстро сходится, и эксперимента другой, который сжигает квартальный бюджет, создавая изменения, которым никто не доверяет. Разница будет заключаться в четырех уровнях, а не в продуманности циклов.
Нативно-облачным командам следует начать с уровня среды выполнения, потому что от него зависит каждый другой уровень. Рабочие процессы верификации имеют смысл только в той мере, в какой и среда, в которой они выполняются, а обратная связь правдива только в той мере, в какой правдива система, которая ее генерирует.
Если ваши агенты пишут код быстрее, чем ваша команда может ему доверять, цикл наверняка подскажет вам, какого слоя не хватает.






























