Что просить у агента, кроме кода?

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

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

Это в тему размышлений в посте про изобилие кода. В Математике 2.0 есть две схемы: в одной AI получает решения, обходя человеческое понимание; в другой - помогает это понимание развивать.

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

В первом посте был пример одноразового софта —> глубина понимания очевидно зависит от срока жизни продукта, цены ошибки и того, насколько легко всё откатить.

Для игры под один вебинар мне важно понимать правила модели и где она может ввести участников в заблуждение. А масштабирование на миллионы пользователей и архитектура на десять лет ей точно не нужны :)

В CRM, от которой зависят работа команды и данные клиентов, уже важно понимать правила процессов, как обнаружить ошибку и восстановить данные.

На больших задачах я стараюсь получать это понимание по ходу работы агента:

1) Сначала прошу план в виде артефакта, который можно читать и комментировать: варианты, ключевые решения, данные и допущения. Задаю вопросы и оставляю правки до реализации.

2) Проверяю важные допущения. Например, агент с помощью regex-а пытается отлавливать ответы клиента и обновлять CRM.

3) Прошу уменьшить зависимость от неизвестного. Допустим, размер компании не найден: можно оставить «неизвестно», попробовать другой источник или передать человеку. Или вместо regex-ов заюзать jev/decisions api.

4) После реализации прошу отчёт о тесте и прогоне на реальных кейсах: GIF-ки, скриншоты и описание процедуры. Так я вижу, что проверяли и какие сценарии выпали. Например, что сделал агент с лидом, размер компании которого неизвестен? Или «22-го подойдёт?» ещё не значит, что встреча согласована. Разбираем ошибку, уточняем правило, добавляем тест.

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

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

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

А потом задайте себе вопрос: улучшилось ли ваше понимание?