Вместо идеального промпта покажите экран: как Loom передаёт задачи агенту

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

22 октября 2026 года Atlassian представила несколько обновлений Loom, включая Record for agent — режим, превращающий запись экрана с голосовыми пояснениями в инструкции для ИИ-агента. Loom, инструмент асинхронного видео для объяснения работы коллегам, переносит эту привычку на программы, способные выполнить следующую задачу. Документация обозначает функцию как открытую бету для тарифов Business + AI и Enterprise с ограничением записи в пять минут. Анонс; актуальные требования.

Интересно не само получение видео агентом. Привычная запись теперь создаёт задание, которое можно проверить, отредактировать и передать исполнителю. Качество передачи становится практическим вопросом, а не соревнованием в длине промптов.

Официальный логотип Loom для обозначения продукта. Это фирменный знак, а не снимок интерфейса Record for agent. Логотип: Loom / Atlassian; правила использования товарных знаков.

Запись сохраняет то, что пропускает описание

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

По документации Loom объединяет речь, ключевые кадры, события взаимодействия и посещённые ссылки. Расширение Chrome также может собирать сообщения консоли и метаданные сетевых запросов и ответов. Настольная версия предлагает выделение и рисование для указания нужной области. Это входные данные для задания, а не доказательство работоспособности будущего исправления. Состав записываемых данных.

На наш взгляд, меняется сама полезная единица общения. Снимок показывает состояние, предложение — намерение, а короткая демонстрация объясняет переход между состояниями. Сформированное задание связывает объяснение с исполнимой работой.

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

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

Дизайнерская обратная связь проще, когда нужное поведение видно

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

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

Это особенно полезно для изменений между дизайн-файлом и работающей страницей. В документации Loom есть пример переходов между Figma и сайтом при объяснении правки интерфейса. Функция помогает сохранить визуальный ориентир, но выбор авторитетного источника остаётся за командой. Даже красивый прототип может не учитывать загрузку, ошибки и права доступа. Поддерживаемый сценарий.

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

Так же можно обсуждать тексты продукта. Покажите предложение в интерфейсе, объясните, кто его читает и какое решение оно должно облегчить. Запись знакомства с продуктом передаст непонятный переход, который скрывает отдельный текстовый фрагмент.

Ошибке нужны воспроизводимое начало и наблюдаемый конец

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

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

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

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

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

Копирование промпта и создание задачи Jira требуют разного доступа

Открытая бета работает через расширение Chrome или настольный Loom версии 2.0 и новее. Документация отделяет обычную работу с промптом от создания задач Jira: для последнего нужны управляемая Atlassian учётная запись и действующая подписка Jira. Это важно небольшой команде, желающей попробовать передачу задания без перестройки управления проектами. Доступ и настройка.

Самая простая проба — одна малозначимая задача в знакомом проекте:

1. Откройте нужный макет, публичную тестовую страницу или среду разработки и подготовьте понятное исходное состояние.
2. Выберите Record for agent в поддерживаемом рекордере Loom и объясните одно изменение, показывая нужные взаимодействия.
3. Завершите запись до истечения пяти минут и полностью прочитайте сформированный план.
4. Исправьте неоднозначные ссылки, удалите лишнее и добавьте конкретное условие приёмки.
5. Скопируйте промпт как Markdown в выбранный агент либо воспользуйтесь доступной передачей или Jira.
6. Сопоставьте результат агента с исходным сценарием перед принятием изменения.

Так первая проба останется понятной. Пользу можно оценить по времени подготовки ясного задания и количеству уточняющих вопросов.

Быстрое завершение работы агентом недостаточно. Если коллега не может объяснить изменение и его связь с наблюдением, передачу ещё нужно доработать. Главная выгода — меньше восстановления контекста, а не меньше проверки.

Чем богаче контекст, тем осознаннее выбор передаваемых данных

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

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

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

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

Проверьте, что агент вправе менять, какую информацию получает и по каким критериям оценивается результат.

Сначала измеряйте, сколько смысла дошло до исполнителя

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

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

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

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

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

Хорошее задание понятно и другому человеку

Record for agent опирается на разумную идею: показать часто быстрее, чем описать каждый пиксель. Лучший результат — задача, понятная и агенту, и коллеге, с видимой связью между наблюдением и принятым изменением.

Перед следующей отправкой спросите: сможет ли человек, не наблюдавший за записью, объяснить критерий успеха? Если да, задание полезно. Если нет, сначала нужно улучшить инструкции, а уже потом код.

Источники

• Atlassian: как показывать намерение в эпоху ИИ, 22 октября 2026 года.
• Loom: запись для ИИ-агентов, требования, сбор данных и сценарии; проверено 26 октября 2026 года.

Храните исходник рядом с проверенными заметками

Telli.sh позволяет собрать разрешённые к хранению записи и проверенные заметки в отдельном месте. Начните с аудиозаметки.