AI-кодер дошёл до развилки: как восстановить контекст и принять решение

Агент ждёт решения, а человек уже забыл задачу. Как decision-mockups помогает сравнить варианты и чего ему не хватает для технических развилок.

Где теряется контекст

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

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

Карпати написал о близкой проблеме: по мере роста автономности моделей больше человеческой работы будет связано с пониманием результатов и контролем. Он предлагает пробовать разные формы объяснения — текст, диаграммы, интерактивные HTML-страницы и видео.

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

Что уже умеет decision-mockups

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

В версии 0.1.9 уже есть адаптация языка для нетехнической и инженерной аудитории, отбраковка мнимых развилок, цена и последствия вариантов, основание рекомендации и условие полезности альтернативы. Видимые изменения показываются CSS-мокапами «до/после». Выбранные ответы можно сохранить и экспортировать, в том числе частично.

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

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

Почему красивой страницы недостаточно

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

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

Объяснять, когда альтернатива лучше рекомендации. Не только «рекомендую A», но и «B стоит выбрать, если…». Например, A быстрее сделать, B проще расширять. Что важнее сейчас — агент может не знать. Мне нужно видеть цену этого выбора, а не угадывать, какие приоритеты он за меня выбрал.

Возвращать ответ вместе с вопросом. В экспорте нужны формулировки решений, а не «A / B / A». И отдельный список вопросов без ответа: не дошёл до развилки — ещё не значит согласился. Выбор варианта тоже не означает, что агент уже выполнил изменение.

Пример: выполнить сразу или через очередь

Возьмём синтетическую задачу: пользователь запускает подготовку отчёта. Агент спрашивает, выполнять работу сразу или отправлять её в очередь. Данных о реальной длительности и нагрузке у нас пока нет. Одного вопроса «синхронно или асинхронно?» недостаточно: сначала надо показать, что изменится для пользователя и где появится ответственность за ошибки.

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

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

Что предлагаю добавить

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

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

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

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

Эти доработки собраны в issue #14 для dz-harness. На 6 октября 2026 года задача открыта: перечисленное здесь — предложение к развитию, а не заявление о реализованных возможностях. Если сталкивались с похожими развилками, можно добавить свой сценарий в issue.

А что с языком объяснения

Карпати предлагает попробовать ASD-STE100 — стандарт контролируемого технического английского для авиационной документации. В своём посте он описывает и менее строгий вариант такого запроса. Это совет о форме объяснения, а не гарантия соблюдения стандарта моделью.

Для русскоязычных объяснений кодера я бы взял прежде всего постоянные названия компонентов, явного исполнителя действия и раздельные шаги. Это мой способ применить идею; я не называю русский текст соответствующим ASD-STE100.

Если один и тот же компонент на схеме называется worker, в тексте agent, а в вариантах executor, приходится сначала выяснять, сколько их вообще. В примере с очередью поэтому одни и те же названия — сервис, очередь, исполнитель и статус задания — используются в тексте, таблице и схеме.

При этом понятность не подтверждает правильность. Красиво нарисованный вариант может держаться на неверном предположении. Основания и ограничения должны быть рядом с рекомендацией — иначе мы просто быстрее примем плохо обоснованное решение.

Что хочу проверить на практике

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

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

А как ваши агенты приносят вопросы-развилки? Что помогает восстановить контекст и сделать осознанный выбор? Сценарии можно обсудить в комментариях к исходному посту в Telegram или добавить в issue. Практику по текущей версии навыка можно начать с курса ниже.

Источники

Исходный авторский пост в Telegram.

Пост Андрея Карпати.

Пакет decision-mockups на npm.

Текущий исходник навыка.

Задача на расширение навыка.

ASD-STE100, выпуск 9.