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