Глава 7. Требования, понятные агенту

Спецификация из прошлой главы состоит из требований. Эта глава про то, как их формулировать, чтобы агент мог проверить себя сам.

Разница принципиальная. Требование, которое агент не может проверить, это не требование, а пожелание. Он его прочитает, кивнёт и объявит выполненным ровно тогда, когда ему захочется.

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

ОТКУДА ЭТО ВЗЯЛОСЬ Подход называют поведенческим описанием. Он старше агентов лет на двадцать и придуман был совсем для другого: чтобы бизнес и разработчики перестали говорить на разных языках. Идея простая. Вместо технической формулировки пишут сценарий: в такой-то ситуации, при таком-то действии, должен получиться такой-то результат. Три части, никакой реализации. С агентами приём заиграл заново, потому что такой сценарий одновременно и постановка задачи, и готовый тест.

Сравни две формулировки одного требования.

ОПИСАНИЕ РЕАЛИЗАЦИИ ОПИСАНИЕ ПОВЕДЕНИЯ

Добавить проверку в обработчик формы Если пользователь отправил форму с пустым полем адреса

Использовать регулярное выражение для ва- То заявка не создаётся лидации

Вернуть ошибку 400 И пользователь видит объяснение, какое поле не заполнено

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

Второе важное отличие: правое требование проверяется, не заглядывая в код. Левое хуй проверишь, не открыв файлы.

Атомарность Второе свойство хорошего требования: оно про одну вещь.

Требования, понятные агенту

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

Признак неатомарного требования: в нём есть союз и или слово управление, работа, обработка.

Критерии готовности Третье и самое важное. У каждого требования должен быть проверяемый признак выполнения, и лежать он должен прямо в спецификации.

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

ШАБЛОН ТРЕБОВАНИЯ ИЗ ЧЕТЫРЁХ СТРОК Ситуация. Когда происходит вот это. Действие. И пользователь или система делает вот то. Результат. Тогда в системе появляется вот это, наблюдаемое снаружи. Проверка. Проверяется командой, тестом или запросом, вот таким. Пока не проходит, к следующему пункту не переходим.

Четвёртая строка и отличает требование от пожелания. Без неё три первых это просто вежливый текст, который никого ни к чему не обязывает и ни хуя не гарантирует.

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

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

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

ЦИКЛ ОДНОГО ПУНКТА

Проверка План на пункт Тесты Код Следующий пункт критериев

только один до реализации по тестам из спецификации если закрыт

Требования, понятные агенту

Где эта схема ломается Честный разговор, без которого глава была бы рекламой.

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

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

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

НАСКОЛЬКО СТРОГО ФОРМАЛИЗОВАТЬ Максимально. Требования, исполняемые спецификации, тесты до кода. Дольше и дороже по токенам, зато не получишь отчёт о готовности там, где половина не проверена. Умеренно. Интеграционные проверки на главные сценарии, остальное по мере появления проблем. Быстрее, но часть дефектов доедет до пользователя. Что определяет выбор. Цена ошибки и зрелость архитектуры. На неустоявшемся прототипе строгая схема тормозит, на системе с живыми пользователями отсутствие схемы стоит дороже.

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

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

Схема оркестрации, которую описывали практики: на каждую предметную область свой набор агентов, впереди лёгкий классификатор, который решает, куда направить. Новое требование туда, регрессия сюда.

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

Что запомнить Описывай вход и выход, а не реализацию. Такое требование одновременно и задание, и тест.

Одно требование про одну вещь. Союз и это признак, что их два.

Требования, понятные агенту

Без проверяемого критерия требование это пожелание, и агент им воспользуется на всю катушку.

Один пункт за раз, с запретом идти дальше до закрытия критериев. Побочно лечит переусложнение.

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

← Спецификация вместо задания · оглавление · Диалог, который превращается в план →

Спросить книгу может любой, кто вошёл в Neuraldeep Hub: агент ищет ответ по тексту и приводит цитату со ссылкой на главу.