Anthropic утверждает, что написание кода больше не является узким местом. И это так, однако процесс выявления ошибок, допущенных агентом искусственного интеллекта, не может быть универсальным для любых изменений, пишет на портале The New Stack Анирудх Раманатхан, технический директор компании Signadot.

Anthropic недавно опубликовала «плейбук» (стандартизированный сценарий действий) по жизненному разработки ПО (SDLC), ориентированному на ИИ (AI-Native SDLC Playbook). Его ключевой тезис гласит: «Написание кода больше не является узким местом». Когда агенты способны реализовать задачу за считанные минуты, ограничения смещаются на этапы, сопутствующие сборке: планирование, проверку (ревью), верификацию, развертывание и управление процессами.

Если организации выстроят работу неверно, возникнет риск появления в десять раз большего числа изменений при прежнем (или даже худшем) качестве каждого из них, причем без возможности выявить неудачные решения. Традиционный подход предполагает, что каждое изменение проверяет человек, но именно этот метод перестает работать при таких объемах.

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

Волна инструментов разработки на основе спецификаций

Этот плейбук — часть более широкой волны инструментов разработки, опирающихся на спецификации (например, Amazon Kiro и GitHub Spec Kit). Все они имеют схожую структуру. В основе лежат текстовые артефакты: документ с описанием замысла трансформируется в спецификацию, план, diff (разница в коде) и результаты проверки — и всё это фиксируется в системе контроля версий. Соблюдение правил обеспечивается детерминированными механизмами (например, хуками), а не просто инструкциями в промпте. Агенты сами проверяют свою работу, прежде чем ее увидит человек. При этом окончательное решение об утверждении остается за людьми.

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

В одной организации выполняется множество процессов

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

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

Инструмент не должен навязывать процесс. Он должен предоставлять организации возможность определить собственный процесс.

Процессы как автоматы состояний

Более удачная модель — определение каждого процесса как автомата состояний (state machine). Состояния отражают факты, касающиеся изменения: например, «проверено», «проверено на соответствие зависимостям», «одобрено для внедрения в продакшен». Эти факты хранятся в различных системах, не принадлежащих какому-то одному инструменту: в репозитории, системе CI, кластере или системе отслеживания задач. Следовательно, процесс не может быть программой, последовательно выполняющей шаги. Это набор правил, реагирующих на информацию, поступающую из указанных систем. Каждое правило определяет:

1. Факты, необходимые для срабатывания правила.

2. Условие перехода (гейт): автоматическое срабатывание или ожидание одобрения человеком.

3. Разрешение, предоставляемое при срабатывании (например, на слияние веток или развертывание).

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

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

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

Процесс адаптируется к изменениям

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

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

Рассмотрим для примера три изменения в одном и том же сервисе:

• Исправление документации классифицируется на основе затронутых путей. Процесс включает два этапа: успешная сборка и слияние. Участие человека не требуется.

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

• Миграция схемы данных в платежном сервисе классифицируется по затронутому компоненту, независимо от того, как заявлено само изменение. Процесс включает дополнительные этапы, отсутствующие в других случаях: проверку владельцем платежного сервиса, валидацию на данных, имитирующих реальную рабочую среду (production-shaped data), и утверждение выпуска ответственным за данную область специалистом.

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

Принципы

Процессы должны строиться на следующих принципах:

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

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

• Подтверждающие данные поступают извне, а не от самого агента. Отчет, сформированный самим агентом, никогда не служит основанием для продвижения изменения на следующий этап. Переходы инициируются на основе фактов, поступающих из систем, в которые агент не может вносить записи (например, результаты тестирования или данные валидации в реальных условиях эксплуатации).

• Записи о процессе служат журналом аудита. Описание процесса представляет собой зафиксированный регламент, а журнал переходов фиксирует, кто и на основании каких данных утвердил каждый этап, а также какая версия регламента при этом применялась.

Обеспечение качества в масштабе

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