Программирующее дерево как однопроходная спецификация для агентаЯ уже писал про
дерево гипотез развития. Всё чаще называю его программирующим деревом. И, чем дальше, тем больше это название кажется мне правильным.
Знаю, как всем надоело слышать про ИИ из-за каждого угла. Мне и самому не по себе. Проходил все эти стадии отвращения, гнева, торга, но последние недели крепко сижу в самой глубокой стадии применения. И я думаю, что с приходом агентов-труженников проектирование должно также измениться.
Меняется место и значение проектировочного артефакта. Он перестаёт быть лишь средством понимания между людьми и становится исполняемым заданием для машины.
Недавно проверил это на небольшой задаче. Вместе с агентом искал текстовый формат описания Карты процесса-опыта. На вход я подавал «дерево» с требованиями к формату, на выходе ожидал кандидатное решение. Вместо отдельных сообщенийй с уточнением в чате с моделью, один запрос со структурированным описанием того, каким должен быть результат.
Вот для примера пара требований из спецификации:
— формат лаконичен и компактен, легко считываем как человеком, так и машиной
— иерархия сущностей-параметров не более одного уровня вложенности
— название точки включает её тип и номер, например «● Добавление темы, КТ-1»
— связывание элементов карты организовано через короткие идентификаторы
— дорожка вторична, является способом организовать пространство карты, иерархия от дорожки неверна
На выходе получилась как схема для будущих документов так и предзаполненный вариант. Кусочек из него:
map:
name: "Подготовка и публикация SMM-постов"
goal: "Зафиксировать точки и барьеры взаимодействия Оператора и воркера для разработки"
position: "Разработчик системы"
mode: "как будет"
nodes:
name: "● Добавление темы, КТ-1"
participants: ["Оператор"]
story: РИ-01
input: "Замысел публикации"
output: "Запись в content-plan.json"
Channel: "Веб-приложение"
barriers:
"Нечёткое название → поверхностный черновик"
Если что-то не нравится, вносим изменение в дерево и просим вырастить нового кандидата. Такой подход получил в мире название разработки, управляемой спецификацией — Specification Driven Development (SDD).
Замена переписки в чате работой со спецификацией — важный сдвиг. Чем точнее у нас описана структура об устройстве будущего артефакта, тем меньше приходится уговаривать модель.
Программирующее дерево становится мостиком между проектированием и исполнением. Дерево ещё не код, в нём на более высоком уровне связно заложены требования и их причины, ограничения и ожидаемые формы результата.
Проектировщику сегодня остаётся всё более высокоуровневая работа: увидеть объект, отсечь лишнее, собрать правильные связи, назвать элементы так, чтобы по ним можно было двигаться дальше. Далее агенты-труженники уже могут довольно бодро перекладывать эту структуру в промежуточные спецификации и исполняемый код.
Раньше я думал, что писать такие деревья — это дело немногих усидчевых. Что ж, по иронии судьбы нас сдувает именно в этом направлении. И чем лучше мы научимся «программировать» смысловые структуры, тем меньше ошибок проектирования будем встречать. А уж какие возможности отрываются перед нами для комбинаторного перебора спецификаций на предмет поиска возможных дыр и говорить не нужно. Все мы понимаем как шустро машина умеет молотить знаки.
