Deja de buscar el prompt perfecto: enséñale a Loom qué debe cambiar
Record for agent de Loom convierte una grabación breve de pantalla en instrucciones para un agente de IA. Qué cambia su beta abierta en los informes de errores, los comentarios de diseño y la revisión previa a una acción.
El problema salta a la vista. En el prototipo, el botón está debajo del formulario; en la aplicación aparece a su lado, y el mensaje de error desplaza ambos fuera de la pantalla del móvil. Explicárselo con suficiente claridad a un agente de programación puede llevar más tiempo que enseñárselo a otra persona.
El 22 de octubre de 2026, Atlassian presentó varias novedades de Loom, entre ellas Record for agent, un modo de grabación que transforma un recorrido narrado por la pantalla en instrucciones para un agente de IA. Loom, la herramienta de vídeo asíncrono que permite mostrar a los compañeros cómo se ve el trabajo, extiende esa costumbre al software capaz de ejecutar la siguiente tarea. Su documentación identifica la función como una beta abierta para los planes Business + AI y Enterprise, con un límite de cinco minutos por grabación. Anuncio; requisitos actuales.
La novedad interesante es que un proceso de grabación conocido ahora genera unas instrucciones que puedes inspeccionar, editar y entregar a un agente. La calidad de ese traspaso se convierte así en una cuestión práctica, en lugar de una competición por escribir el prompt más largo.
Logotipo oficial de Loom utilizado para identificar el producto. Es una marca gráfica, no una captura de Record for agent. Logotipo: Loom / Atlassian; política de uso de marcas.
Una grabación conserva lo que tu descripción deja fuera
Un informe de error útil necesita algo más que «el formulario no funciona». Debe mostrar el estado inicial, la acción que provoca el problema, el resultado esperado y el que realmente apareció. Cuando estos detalles se reparten entre capturas, URL copiadas y mensajes de chat, alguien debe reconstruir su relación antes de poder arreglar nada.
El proceso documentado de Loom combina instrucciones habladas con fotogramas clave de la pantalla, eventos de interacción y enlaces visitados. En la extensión de Chrome también puede recoger mensajes de consola y metadatos de solicitudes o respuestas de red. La versión de escritorio ofrece herramientas de selección y dibujo para dirigir la atención a la parte pertinente. Todo ello alimenta las instrucciones generadas; no demuestra que una corrección propuesta vaya a funcionar. Detalles de captura.
A nuestro juicio, esto cambia la unidad de comunicación más útil. Una captura muestra un estado; una frase describe una intención; un recorrido breve puede explicar cómo un estado debería convertirse en otro. Las instrucciones generadas sirven de puente entre esa explicación y una tarea ejecutable.
Conviene pensar en la grabación como un paquete de contexto. Debería contener lo necesario para el cambio solicitado y poco más. Un límite de cinco minutos puede favorecer esa disciplina: mostrar un problema, explicar su consecuencia e identificar una meta clara.
Explicación original del traspaso. Revisar las instrucciones es un paso distinto de la ejecución del trabajo por parte del agente.
Los comentarios de diseño mejoran cuando el comportamiento deseado se ve
Pensemos en un equipo que ajusta una pantalla de pago. En un recorrido ilustrativo, el diseñador podría abrir el diseño aprobado, mostrar la aplicación actual y señalar tres diferencias: la opción de entrega desaparece en una ventana estrecha, el total se actualiza demasiado tarde y el mensaje de confirmación resalta la información equivocada. El valor está en la relación entre ambas pantallas, no solo en su aspecto.
Quien revise el prompt generado debe convertir cada observación en un comportamiento. «Mueve esto» resulta ambiguo cuando el agente ya no está viendo el mismo instante. «Mantén visible el total del pedido cuando cambie la opción de entrega en una ventana estrecha» proporciona un resultado comprobable.
Esto resulta especialmente útil cuando un cambio abarca un archivo de diseño y una página en funcionamiento. El propio ejemplo de soporte de Loom describe cómo alternar entre Figma y un sitio web mientras se explica un cambio de interfaz. La función ayuda a capturar la referencia visible, pero decidir cuál tiene autoridad sigue correspondiendo al equipo. Un prototipo pulido puede omitir los estados de carga, error y permisos. Proceso compatible.
Por eso conviene añadir una frase que indique qué debe seguir siendo cierto. En el ejemplo del pago, podría ser que el total coincida con el método de entrega seleccionado o que el foco del teclado permanezca en el campo modificado. Estas condiciones suelen faltar en las maquetas visuales y pueden importar más que la posición de un borde.
El mismo enfoque sirve para los textos del producto. Muestra la frase en su contexto real, explica quién la lee e indica qué decisión debe facilitar. Una grabación del proceso de incorporación puede comunicar una transición confusa que un fragmento de texto aislado ocultaría.
Un informe de error necesita un inicio reproducible y un final observable
Otro caso útil es una incidencia de soporte recurrente. Imagina que un cliente puede subir un documento desde el ordenador, pero ve un indicador de progreso vacío en una pantalla pequeña. Una grabación breve puede mostrar el tipo de archivo, la acción seleccionada, la transición y el punto en que desaparece la información de progreso.
La tarea generada sigue necesitando una definición de finalización. «Arregla la subida» no dice si el problema es un archivo rechazado, una respuesta de red ausente o una interfaz que no mostró un resultado correcto. Unas instrucciones más útiles separan el síntoma observado de la causa sospechada.
Mantendríamos acotado el encargo inicial: reproducir la falta de información, identificar la capa responsable y proponer un cambio con una comprobación de regresión. Si el agente descubre después un error del servidor, esa evidencia puede ampliar la investigación. Una queja de presentación no debería transformarse silenciosamente en una reescritura general del sistema de subida.
Esto ofrece una ventaja práctica a quienes no se sienten cómodos leyendo registros. Pueden enseñar la secuencia defectuosa sin diagnosticarla primero. El ingeniero o el agente puede investigar con el contexto capturado, mientras la observación original sigue disponible para compararla después de la corrección.
La grabación no sustituye a un caso de prueba. Cada uno cumple una función distinta. La primera conserva lo que alguien encontró; la prueba describe el comportamiento que el software debe seguir cumpliendo. Un buen proceso convierte la primera en una versión adecuada de la segunda.
Copiar un prompt y crear una tarea de Jira son puntos de entrada distintos
La beta abierta de Loom puede utilizarse desde la extensión de Chrome o desde la aplicación de escritorio, versión 2.0 o posterior. La documentación también distingue el proceso básico con prompts de la creación de elementos de trabajo en Jira, que requiere una cuenta gestionada por Atlassian y una suscripción activa a Jira. Esta diferencia importa a un equipo pequeño que quiere probar el traspaso sin reorganizar la gestión de proyectos. Disponibilidad y configuración.
La prueba más sencilla consiste en una tarea de bajo impacto dentro de un proyecto que ya conozcas:
- Abre el diseño pertinente, una página pública de prueba o un entorno de desarrollo y prepara un estado inicial que puedas explicar.
- Selecciona Record for agent en una grabadora de Loom compatible y describe un cambio mientras muestras las interacciones pertinentes.
- Detente antes del límite de cinco minutos y lee de principio a fin el plan de acción generado.
- Corrige las referencias ambiguas, elimina el material ajeno y añade una condición concreta de aceptación.
- Copia el prompt como Markdown en el agente elegido o utiliza el traspaso compatible o el proceso de Jira disponible para tu cuenta.
- Revisa el resultado del agente frente al escenario original antes de aceptar el cambio.
Esta secuencia mantiene comprensible el primer experimento. También permite decidir con claridad si la función ayuda: compara el tiempo necesario para preparar un encargo claro y las preguntas de aclaración que genera.
Que el agente termine deprisa no basta. Si un compañero no puede explicar qué cambió o por qué resuelve la observación original, el traspaso aún necesita trabajo. La mejora más útil es reducir la reconstrucción del contexto, no la revisión.
Un contexto más rico exige decidir mejor qué compartir
El contexto técnico adicional es valioso porque la pantalla puede no explicar lo ocurrido. Una solicitud fallida, una redirección inesperada o un error de consola pueden señalar una causa distinta de la que sugiere el síntoma visible. Esos mismos detalles pueden contener información que no deseas enviar a otra herramienta.
Antes de grabar, usa una página de prueba pertinente y mantén visible el alcance de la tarea. Después, revisa las instrucciones generadas en busca de URL específicas de una cuenta, identificadores de clientes y registros innecesarios. La lista de datos capturados que ofrece la documentación justifica una comprobación concreta, en lugar de tratar la grabación como una imagen adjunta cualquiera.
La idea es conservar la información necesaria para resolver la incidencia. Un identificador de solicitud puede ser útil si permite a un compañero localizar una traza de servidor a la que tiene acceso autorizado. Una lista completa de URL ajenas o una notificación personal que apareció durante la grabación aporta poco a una tarea de interfaz.
| Entrada del traspaso | Qué puede explicar | Qué debe decidir quien revisa |
|---|---|---|
| Instrucción hablada | El cambio deseado y por qué importa | Si la petición es suficientemente concreta para implementarla |
| Fotograma clave o elemento seleccionado | El estado de pantalla o componente afectado | Si la imagen muestra contexto pertinente y autorizado |
| Clics y enlaces visitados | El recorrido por el proceso | Si puede reproducirse fuera de la sesión original |
| Metadatos técnicos de Chrome | Una pista sobre el fallo detrás de la interfaz | Si el detalle es necesario y apropiado para compartir |
Estas son preguntas de revisión editorial, no permisos adicionales del producto ni una promesa de que cada detalle capturado aparezca en todas las tareas generadas. Su objetivo es ayudar al equipo a decidir qué debe incluir el encargo que realmente envía.
Una revisión útil comprueba qué puede cambiar el agente, qué información recibe y cómo se juzgará el resultado.
La primera medida útil es cuánta explicación se conserva
Esta función podría ahorrar trabajo de al menos tres maneras. Un diseñador puede comunicar una diferencia visual sin redactar una descripción compleja. Un especialista de soporte puede conservar una secuencia mientras la recuerda. Un desarrollador puede encargar al agente una tarea con una referencia más clara y un resultado esperado más específico.
Cada uso tiene su propio modo de fallar. Los comentarios de diseño pueden omitir comportamientos fuera del recorrido ideal. Un ejemplo de soporte puede depender de un estado de cuenta que nadie más logra reproducir. La grabación de un desarrollador puede contener tantos detalles que cueste identificar la petición real.
Para una primera evaluación, elige varias tareas conocidas y mantén sin cambios el agente y el repositorio. Registra cuánto debes editar las instrucciones generadas, con qué frecuencia alguien pide aclaraciones y si el cambio final cumple la condición establecida. Estas medidas dicen más sobre la calidad de la comunicación que una demostración aislada de un cursor en movimiento.
También conviene distinguir la calidad del resultado de la dificultad de la tarea. Un cambio de texto sencillo puede salir bien con casi cualquier instrucción. Una prueba más reveladora es una tarea pequeña donde el contexto importe: un estado de carga, un diseño para pantallas estrechas o una transición entre herramientas. El encargo debe seguir siendo reversible y fácil de revisar para su responsable.
Loom está bien situado para familiarizar a los usuarios con esta costumbre, porque ya utilizan grabaciones para explicar su trabajo a otras personas. La oportunidad consiste en trasladar esa claridad al proceso de un agente. El riesgo es asumir que una entrada más rica elimina la necesidad de explicar qué debe conseguir.
Las mejores instrucciones siguen siendo comprensibles para otra persona
Record for agent hace una apuesta razonable: mostrar puede ser un punto de partida más eficiente que describir cada píxel. Su mejor resultado sería una tarea más fácil de entender tanto para el agente como para un compañero, con una conexión visible entre la observación original y el cambio aceptado.
Antes de enviar la próxima grabación, plantéate una pregunta: ¿alguien que no te vio hacerla podría explicar en qué consiste el éxito? Si la respuesta es sí, tienes unas instrucciones útiles. Si no, la siguiente mejora debe hacerse en las instrucciones antes que en el código.
Fuentes
- Atlassian: Mostrar lo que quieres decir en la era de la IA, 22 de octubre de 2026.
- Loom: Record for AI agents, documentación de disponibilidad, captura y procesos consultada el 26 de octubre de 2026.
Conserva juntas la fuente y las notas revisadas
Para tus grabaciones autorizadas, Telli.sh ofrece un espacio separado donde conservar las fuentes junto a las notas revisadas. Empieza con una nota de audio.