Если вам важен здравый смысл и продуманность действий, и вы будете в Москве в середине мая, рекомендую посетить конференцию Карты гипотез совместно проводимую с ВШЭ. Сам я не смогу, буду докладываться в Челябинске. Но если бы не выступление, то обязательно был бы там.

Я неоднократно писал в этом канале о Карте гипотез и постоянно использую ее. Эта карта входит у нас в состав обязательных для построения ИТ-систем. можно почитать. С ней люди и агенты получают нужную порцию и фокус внимания в совместной работе.

https://картагипотез.рф/hse_conference_052026

Программирующее дерево как однопроходная спецификация для агента

Я уже писал про дерево гипотез развития. Всё чаще называю его программирующим деревом. И, чем дальше, тем больше это название кажется мне правильным.

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

Меняется место и значение проектировочного артефакта. Он перестаёт быть лишь средством понимания между людьми и становится исполняемым заданием для машины.

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

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

— формат лаконичен и компактен, легко считываем как человеком, так и машиной
— иерархия сущностей-параметров не более одного уровня вложенности
— название точки включает её тип и номер, например «● Добавление темы, КТ-1»
— связывание элементов карты организовано через короткие идентификаторы
— дорожка вторична, является способом организовать пространство карты, иерархия от дорожки неверна

На выходе получилась как схема для будущих документов так и предзаполненный вариант. Кусочек из него:

map:
name: "Подготовка и публикация SMM-постов"
goal: "Зафиксировать точки и барьеры взаимодействия Оператора и воркера для разработки"
position: "Разработчик системы"
mode: "как будет"

nodes:
name: "● Добавление темы, КТ-1"
participants: ["Оператор"]
story: РИ-01
input: "Замысел публикации"
output: "Запись в content-plan.json"
Channel: "Веб-приложение"
barriers:
"Нечёткое название → поверхностный черновик"


Если что-то не нравится, вносим изменение в дерево и просим вырастить нового кандидата. Такой подход получил в мире название разработки, управляемой спецификацией — Specification Driven Development (SDD).

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

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

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

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

Завтра доклад на UWDC

Друзья, если вы в Челябинске, приходите завтра на мой доклад «Техники структурирования беседы с собой, заказчиком, и командой» на конференции UWDC. Вход бесплатный, но нужно получить билет, зарегистрировавшись.

https://uwdc.ru/events/uwdc2026/talks/texniki_strukturirovaniya_besedy_s_zakazchikom_kom

Слайды доклада «Техники структурирования беседы» и ссылки на статьи про сами техники

https://ashapiro.ru/talks/tpost/kyhcxruyo1-tehniki-strukturirovaniya-besedi-ssoboi

Вчера из Твери прислали кусочек процесса печати книжного блока «Рабочих историй»

Социотех теперь умеет сам строить Карты гипотез

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

Сегодня я рад поделиться тем, что мы добавили генерацию в Карту гипотез с Социотехе. Показываю на примере идей по популяризации технологии КРИ

Попробуйте и сами — https://sociotech.center/

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

Не вычитал скилл — нарисовал карту как понял

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

В последнее время я всё чаще провожу рабочее и досужее время с код-агентами. Это большие языковые модели, помещённые в такую обвязку, где у них появляются «глаза» и «руки» на компьютере. Как только у модели возникает возможность не только отвечать, но и действовать, довольно быстро проступают знакомые шаблоны.

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

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

Хорошо, что агент не обижается и не сопротивляется. На его «я не прочитал скилл и сделал карту так, как понял структуру из беглого просмотра» можно ответить не воспитательной беседой, а исправлением среды. Дочитал инструкцию, переделал как следует, получил более жёсткое правило на будущее.

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

Если вокруг агента не спроектирован контур работы, он начинает вести себя как быстрый и самоуверенный новичок. Должно быть ясно. Где лежит инструкция? Когда её надо читать целиком, а не по диагонали? Что считается допустимым упрощением, а что уже искажает метод? Как устроена проверка результата? Как типовая ошибка не просто исправляется один раз, а исключается в будущем. Вот где на самом деле находится управление.

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

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

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

Рабство привычки сегодня стоит дорого

Человек делает что-то каждый день. То, как он что-то делает, оставляет на нём неизгладимый след, вгрызается в него и закрепляется на нём. То, что философы называли modus operandi, или способ действия, буквально прописывается на человеке и становится его привычкой.

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

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

Близкие мне люди, когда я вижу, как они справляются с каким-то действием, и предлагаю альтернативу, почти всегда отказываются от непрошеных идей. С одной стороны, это очень понятно: нужно как-то потакать своему эго. Вот я и отправляюсь с «совет свой себе посоветуй». С другой стороны, я не понимаю, как можно отказываться от новых стратегий выживания.

Чтобы проиллюстрировать, насколько глубоко в нас сидят автоматические процедуры, поделюсь самонаблюдением.

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

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

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

Не стоит и говорить о том, как глубоко прописалась в моих коллегах привычка «нанимать» привычные средства для решения задач в разработке.

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

Здесь я передаю привет всем агентам изменений в ИИ-трансформации. ИИ-трансформация почти никогда не упирается только в качество новых инструментов. Она упирается в старые способы действия, которые прочно «гнездятся» на людях и командах. Можно один раз показать, что новый ход быстрее, дешевле и умнее, и всё равно на следующий день люди вернутся к старому.

Так что задача «внедрить ИИ» это только команда «фас». Настоящее дело будет за тем, как помочь команде несколько раз пройти новым путём, пока он не перестанет быть чужим.

Если вы видите, что команда уже попробовала новые ИИ-средства, но продолжает жить по-старому, значит проблема не в инструменте. Значит, нужно менять способ действия.

Книга «Рабочие истории. Системное проектирование с Картой реализации историй» добралась до Челябинска и сегодня уже уехала на склады OZON. Первая партия появится в продаже через пару дней

О книге