Agent Experience es la nueva DX

Developer Experience (DX) pregunta qué tan bien las personas pueden usar tus herramientas. Agent Experience plantea la misma pregunta sobre las máquinas.

Esta página se centra en agentes de codificación con IA: herramientas como Claude Code, Cursor y flujos de trabajo agénticos personalizados que escriben, ejecutan e iteran código con distintos niveles de supervisión humana. Los mismos principios se aplican dondequiera que un modelo interactúe con software o infraestructura en nombre de alguien.

Agent Experience es una disciplina de diseño, no una categoría de producto. Se manifiesta en las API, las herramientas de línea de comandos, la documentación, los permisos, los entornos, los mensajes de error, los registros y los sistemas de feedback. La mayoría de esas superficies se diseñaron originalmente para personas.

Una buena Developer Experience (DX) acorta la distancia entre la intención y un resultado útil. Las personas se benefician de la jerarquía visual, la divulgación progresiva de la información, explicaciones claras e interfaces que favorecen la exploración.

Los agentes interactúan con los mismos sistemas de forma distinta. Un panel diseñado para el escaneo visual puede exponer poca información utilizable para una máquina. Un mensaje de error extenso puede ayudar a una persona a entender el contexto, pero obliga a un agente a gastar tokens separando la señal del ruido. Un prompt interactivo puede hacer que una CLI sea más fácil para una persona mientras detiene por completo un flujo de trabajo automatizado.

Diseñar para ambos tipos de usuarios

Agent Experience no sustituye a Developer Experience. Los sistemas de software cada vez sirven a ambos.

Un desarrollador puede revisar un pull request en una interfaz visual mientras un agente recupera el mismo cambio a través de una API. Un desarrollador puede inspeccionar un registro de compilación completo mientras un agente solo solicita el paso fallido y el error relevante. Una persona puede preferir un flujo de configuración guiado mientras un agente necesita un comando no interactivo con una salida predecible.

Un buen tooling expone las mismas capacidades subyacentes en formas adecuadas para cada tipo de usuario.

Las herramientas para desarrolladores llevan décadas asumiendo que hay una persona frente al teclado: alguien capaz de revisar un panel, detectar algo inesperado, buscar más información y resolver la ambigüedad usando su criterio.

Los agentes cambian esa suposición. Los sistemas de control de versiones, la infraestructura de compilación, los registros de paquetes, las plataformas en la nube, las API internas y las herramientas para desarrolladores reciben cada vez más solicitudes de software que actúa en nombre de alguien.

Los agentes se están convirtiendo en usuarios del software

Los agentes interactúan cada vez más directamente con los sistemas que antes operaban manualmente los desarrolladores.

Leen documentación, llaman a las API, ejecutan comandos, modifican repositorios, inspeccionan registros, consultan infraestructura y activan flujos de trabajo. Cada interfaz a lo largo del camino influye en si el agente puede completar la tarea de forma fiable.

Una AX deficiente se convierte en trabajo humano

Un agente que recibe un muro de salida sin estructurar tiene que gastar tiempo y tokens averiguando qué es relevante. Una respuesta ambigua de una API puede provocar un reintento innecesario o la acción siguiente equivocada. Un prompt interactivo puede detener una tarea automatizada y devolverla a una persona.

Los problemas se acumulan a lo largo de un flujo de trabajo. Una pequeña dosis de ambigüedad en cada paso puede convertir una tarea autónoma en aclaraciones, revisiones y limpiezas repetidas.

Modelos mejores no eliminan el diseño de interfaces

Las capacidades de los modelos seguirán mejorando. Los equipos tienen un control mucho más directo sobre los sistemas con los que interactúan los modelos: esquemas de API, documentación, comportamiento de la CLI, registros, permisos, entornos y feedback.

Los modelos mejores pueden razonar con más eficacia sobre interfaces deficientes, pero unas interfaces más sólidas reducen desde el principio cuánto razonamiento se necesita.

Los equipos de plataforma ya hacen un trabajo similar para los desarrolladores al crear caminos allanados (paved paths) mediante infraestructura compartida. El desarrollo agéntico añade otro usuario para el que diseñar.

Agent Experience es una propiedad de cada superficie que un agente utiliza para completar una tarea.

En el caso de un agente de codificación, un solo cambio puede requerir leer documentación, consultar un repositorio, ejecutar comandos, modificar archivos, llamar a herramientas externas, interpretar la salida de las pruebas, comprobar el estado de la CI y actualizar un pull request.

Obtener el contexto adecuado

Los agentes necesitan acceso a la información en formas que puedan recuperar e interpretar de forma predecible.

Las API se benefician de esquemas estables y respuestas estructuradas. La documentación se beneficia de ejemplos precisos, un versionado claro e instrucciones canónicas. Las herramientas de CLI se benefician de modos de salida legibles por máquinas. Las descripciones de herramientas se benefician de nombres, entradas, salidas y límites precisos.

Protocolos como MCP hacen que el diseño de interfaces sea especialmente visible. La descripción de una herramienta ayuda a determinar cuándo un agente la elige y cómo construye la solicitud.

Más contexto disponible no crea automáticamente una mejor AX. El contexto relevante sí lo hace.

Actuar de forma segura

Los agentes necesitan formas predecibles de modificar un sistema.

Las herramientas de línea de comandos deberían admitir ejecución no interactiva, códigos de salida significativos y operaciones con resultados claramente definidos. Siempre que sea posible, los comandos repetidos deberían ser seguros o dejar evidentes las acciones duplicadas.

Los permisos determinan cuánta autonomía puede recibir un agente sin aumentar el costo de un error. Los ámbitos acotados, los límites de aprobación, los entornos aislados y la aplicación de políticas permiten que los agentes realicen trabajo útil mientras se limitan los efectos no deseados.

Entender lo que ha ocurrido

Un agente necesita saber si una acción tuvo éxito, falló o produjo un estado inesperado.

Un estado legible por máquinas, errores específicos, registros estructurados y un estado explícito facilitan determinar el siguiente paso. Un error útil le indica al agente qué falló, dónde ocurrió el fallo y qué esperaba el sistema.

El detalle completo debe seguir estando disponible cuando se necesite. No tiene por qué ser la respuesta predeterminada.

Localizar el estado y el historial

Los agentes suelen necesitar información que un desarrollador normalmente obtendría abriendo otra interfaz.

¿Qué despliegue se está ejecutando actualmente? ¿Qué pipeline falló? ¿Qué cambió después del intento anterior? ¿Se completó la llamada a la API? ¿Ya hay un pull request abierto?

Exponer el estado operativo mediante programación permite que un agente responda a esas preguntas sin depender de que una persona traduzca la información de un panel.

Mejorar la Agent Experience rara vez requiere reconstruir toda una plataforma en torno a la IA. Muchos de los cambios de mayor valor simplemente hacen que las interfaces existentes sean más explícitas, estructuradas y predecibles.

1. Devolver información estructurada

Ofrezca salidas legibles por máquina para los flujos de trabajo que un agente usará de forma repetida.

En una CLI, esto puede significar una salida JSON conforme a un esquema documentado. En una API, significa tipos de respuesta estables y estados de error explícitos. En la documentación, significa ejemplos que un agente pueda ejecutar sin tener que reconstruir suposiciones que faltan.

La salida legible para personas puede seguir disponible para los usuarios humanos. Los agentes se benefician, además, de contar con una vía orientada a máquinas hacia la misma información.

2. Depurar el contexto en el origen

Devuelva la información necesaria para la decisión actual, no toda la información disponible.

Si fallan tres pruebas, identifique esos tres fallos y aporte los detalles relevantes en lugar de devolver miles de líneas de salida sin relación. Si una operación falla porque un parámetro no es válido, identifique directamente el parámetro y el valor esperado.

Filtrar en el origen reduce el consumo de tokens y acota el número de interpretaciones plausibles que un agente debe considerar.

3. Hacer que las acciones sean predecibles y repetibles

Los flujos de trabajo agénticos reintentan operaciones con frecuencia, se ramifican hacia enfoques alternativos y vuelven sobre pasos anteriores.

Las operaciones idempotentes hacen que los reintentos sean seguros. Las transiciones de estado claras ayudan a un agente a entender si algo ya ha ocurrido. Los códigos de salida fiables y un estado explícito evitan que el agente tenga que inferir el éxito a partir de texto libre.

Las barreras de protección deben residir en el sistema siempre que sea posible. Los límites de permisos y las verificaciones de políticas son más fiables que confiar en que cada agente descubra y siga una convención escrita.

4. Tratar la latencia como parte de la interfaz

La retroalimentación es más útil mientras el agente sigue trabajando en la tarea que la generó.

La latencia aceptable depende del flujo de trabajo. Una comprobación de sintaxis local puede necesitar responder casi de inmediato. Una prueba de integración completa puede tardar más. Un despliegue puede requerir, por naturaleza, varios minutos.

La pregunta importante es si el tiempo de respuesta encaja con la decisión que el agente debe tomar a continuación.

5. Medir los resultados del agente

Las métricas de UX tradicionales no describen por completo qué tan bien interactúa un agente con un sistema. Defina un pequeño conjunto de tareas representativas y ejecútelas de forma repetida a medida que su producto evoluciona.

Las señales de AX útiles pueden incluir:

• Con qué frecuencia el primer intento se completa con éxito
• Cuántos reintentos o llamadas a herramientas requiere una tarea
• Cuánto tiempo o presupuesto de inferencia se necesita para llegar a una resolución
• Con qué frecuencia una persona tiene que intervenir
• Qué herramientas o interfaces preceden con más frecuencia a los intentos fallidos

Cuando un fallo recurrente revela un problema de interfaz, corríjalo y conserve el caso como una evaluación de regresión. Ejecute esas evaluaciones en la CI junto con las pruebas de los contratos orientados a agentes, como los esquemas de API, las definiciones de herramientas, la salida estructurada, los códigos de salida y los límites de permisos.

Contar con una línea base permite distinguir una mejora real de AX de un cambio que simplemente parece más limpio a ojos de un revisor humano.

Empezar por los fallos recurrentes

Elija una tarea que sus agentes realicen con frecuencia e inspeccione los intentos fallidos de principio a fin.

Busque el primer punto en el que al agente le faltó contexto, malinterpretó el estado, eligió la herramienta equivocada, recibió retroalimentación ambigua o requirió intervención humana.

Las mejoras de AX más útiles suelen comenzar en una interfaz de software conocida, no dentro del propio modelo. En cuanto corrija un fallo recurrente, añádalo a su conjunto de evaluaciones para poder detectar la regresión más adelante.

Los agentes de IA no son deterministas. Dos intentos de la misma tarea pueden producir rutas de razonamiento, secuencias de herramientas y soluciones distintas.

El diseño de la interfaz puede aumentar o reducir la cantidad de variación que introducen esas diferencias.

Un agente al que se le da un registro de trabajo completo tiene muchas señales posibles que seguir. Un agente al que se le da el fallo relevante, el archivo afectado, el comportamiento esperado y el contexto de apoyo parte de una definición del problema mucho más acotada.

La segunda interfaz no hace que el modelo sea determinista. Reduce la ambigüedad innecesaria.

Las descripciones precisas de las herramientas acotan la selección de herramientas. Los esquemas estables reducen la interpretación. El estado explícito reduce las conjeturas. Los límites de permisos bien definidos acotan las acciones disponibles.

Una buena AX diseña el sistema que la rodea de modo que la variabilidad del modelo tenga menos margen para convertirse en un comportamiento incorrecto o costoso.

Los principios anteriores se aplican a toda la pila de software. CircleCI se centra en una parte concreta de la Agent Experience: cómo reciben los agentes una retroalimentación de validación útil mientras desarrollan software, y cómo los equipos validan de forma independiente los cambios generados por agentes antes de que esos cambios se publiquen.

La generación de código es cada vez más rápida y más barata. Cada cambio adicional sigue necesitando evidencia de que cumple los estándares requeridos para el merge y el despliegue.

El enfoque de CircleCI conecta la retroalimentación rápida dentro del ciclo de trabajo del agente con la validación independiente en la CI.

Un agente de codificación puede producir un cambio plausible con rapidez. Evaluar ese cambio puede requerir bastante más trabajo.

Una prueba superada aporta una evidencia útil, pero solo indica que las comprobaciones que se ejecutaron pasaron. Un cambio puede superar una prueba y, aun así, introducir una regresión en otra parte, resolver el problema equivocado o incumplir otro requisito que la suite de pruebas actual no cubre.

El desarrollo agéntico aumenta la importancia tanto de la retroalimentación rápida como de la validación independiente. Los agentes necesitan suficiente señal para iterar de forma eficiente mientras trabajan, y los equipos necesitan una capa de validación más amplia antes de que el código se comparta o se pueda desplegar.

Usamos el concepto de calidad del merge para describir si un cambio cuenta con evidencia suficiente para cumplir los requisitos del equipo a la hora de fusionarlo, en lugar de tratar una única señal en verde como prueba de corrección.

La CI ofrece un lugar independiente donde reunir y hacer cumplir esa evidencia.

El desarrollo de software agéntico funciona a través de dos bucles de feedback.

El bucle interno

El bucle interno es lo que ocurre mientras un agente trabaja activamente en un cambio:

escribir → ejecutar → comprobar → corregir → repetir

El agente todavía tiene el problema, la implementación y la salida reciente de las herramientas en su contexto activo. La validación rápida en este punto ayuda a detectar problemas antes de un push o una pull request.

El bucle externo

El bucle externo comienza cuando el cambio llega a la infraestructura de entrega compartida.

Puede incluir el pipeline de CI/CD, pruebas de integración y de sistema, comprobaciones de seguridad, revisión, despliegue y verificación posterior al despliegue.

El bucle externo tiene un propósito distinto. Sus resultados se comparten entre desarrolladores, agentes, revisores y sistemas posteriores. Aporta evidencia independiente sobre un cambio fuera del entorno donde se creó.

Conecta los bucles

Un buen Agent Experience mantiene un flujo de feedback útil entre ambos bucles.

Un fallo detectado durante el bucle interno a menudo puede corregirse de inmediato mientras el agente todavía tiene todo el contexto de trabajo. Un fallo detectado por CI debe volver al agente con información estructurada suficiente para continuar la tarea sin tener que redescubrir todo el problema.

El objetivo no es trasladar cada comprobación del bucle externo al bucle interno. Es hacer que cada bucle haga bien su trabajo y que el traspaso entre ambos sea eficiente.

CircleCI está construyendo interfaces orientadas a agentes en ambos bucles para que los agentes puedan validar el código antes, recibir feedback de mayor calidad desde CI y actuar ante los fallos sin obligar a un desarrollador a traducir los resultados.

1. Validación de nivel CI en el bucle interno

Los sidecars de Chunk ejecutan una validación específica sobre el código afectado en un entorno aislado antes del push.

El agente puede validar los cambios del directorio de trabajo mientras todavía tiene la implementación en su contexto, sin esperar a que se ejecute todo el pipeline de CI. Los sidecars están diseñados para devolver feedback de nivel CI en menos de un minuto para las comprobaciones que pertenecen al bucle interno.

La validación rápida del bucle interno detecta los problemas más sencillos cerca de donde se originan y deja que el bucle externo se centre en comprobaciones compartidas más profundas.

2. Validación de mayor calidad en el bucle externo

Smarter Testing usa el análisis de impacto de pruebas para ejecutar las pruebas afectadas por un cambio, distribuye de forma inteligente la ejecución de pruebas entre el cómputo disponible y puede volver a ejecutar los fallos para identificar tests inestables (flakes).

El desarrollo agéntico puede aumentar el número de cambios y ciclos de validación que pasan por CI. Ejecutar rápidamente las pruebas más relevantes ayuda a mantener un feedback útil a medida que crece el volumen.

Reducir la ejecución de pruebas inestables e innecesarias también le da tanto a los agentes como a los desarrolladores una señal más clara sobre si un cambio requiere atención.

3. Devuelve al contexto los fallos del bucle externo

Un fallo de CI es más útil para un agente cuando la información relevante puede volver directamente a su entorno de trabajo.

La CLI de CircleCI admite un flag --failure-report que reduce un job fallido a la información que un agente necesita para diagnosticarlo sin tener que analizar antes el log completo.

CircleCI también admite Fix with Claude Code, que envía un resumen estructurado del fallo de una ejecución fallida de CircleCI de vuelta a Claude Code en la terminal.

El bucle externo detecta el problema. El agente recibe el contexto relevante, propone una corrección, y CI valida de forma independiente el siguiente cambio.

4. Da a los agentes acceso directo a CircleCI

La CLI de CircleCI ofrece una interfaz orientada a máquinas para CircleCI con salida JSON estructurada, informes de fallos, operaciones de pipeline y herramientas de despliegue.

El servidor MCP de CircleCI expone las herramientas de CircleCI directamente a los agentes compatibles con MCP. Los agentes pueden consultar el estado del pipeline, inspeccionar fallos y resultados de pruebas, volver a ejecutar workflows, disparar pipelines y realizar otras operaciones compatibles sin necesidad de que un desarrollador mueva información manualmente entre sistemas.

Para proyectos nuevos, circleci onboard puede inspeccionar un repositorio, generar una configuración inicial de CircleCI y conectar el proyecto a CircleCI.

En conjunto, estas interfaces permiten que los agentes participen directamente en el flujo de entrega mientras CircleCI sigue siendo una capa de validación independiente alrededor del código que producen.

Un buen Agent Experience empieza por tratar a los agentes como usuarios de tu producto. Dales contexto relevante, formas predecibles de actuar, un estado del sistema explícito y feedback que deje clara la siguiente decisión.

Empieza con un flujo de trabajo de alta frecuencia y hazlo utilizable por un agente de principio a fin. Prueba tareas representativas de forma repetida y convierte los fallos recurrentes en mejoras concretas de la interfaz. Las evaluaciones de agentes y las pruebas de contrato pueden formar parte de tu bucle de feedback de CI, ayudándote a detectar regresiones de AX a medida que tu producto cambia.

Con CircleCI, AX puede extenderse al propio flujo de entrega. Los agentes de codificación pueden acceder a la salida estructurada de la CLI y a las herramientas MCP, validar cambios en el bucle interno y recibir feedback de mayor calidad desde CI en el bucle externo, de modo que puedan seguir trabajando sin depender de que un desarrollador traduzca los resultados.

Incorpora AX a tu producto y conviértelo en algo que pruebas y mejoras continuamente.