Agentes de IA que prueban lo que programan

Cursor, GPT-6.1 Terra (computer use a la mitad de precio que GPT-5.6 Terra) y Hallmark: los agentes de IA ya prueban lo que programan en la interfaz de verdad.

Que el agente pruebe lo que programa

Cada vez tengo más claro que el cuello de botella de trabajar con agentes de IA no está en escribir código, sino en comprobar que lo escrito hace lo que tiene que hacer. Estos días han coincidido tres novedades que apuntan justo ahí: agentes de IA que prueban lo que programan, en la interfaz de verdad, sin que yo tenga que abrir el simulador y hacer clic por ellos.

No es que antes no hubiera tests. Es que buena parte de lo que se rompe en una app (un botón que no responde, una pantalla que se descuadra en el móvil, un formulario que da las gracias sin enviar nada) no lo ve un test unitario. Lo ve alguien usando la app. Y ese alguien solía ser yo.

Cursor ya maneja apps de escritorio

El 23 de octubre Cursor lo anunció en un post en X bastante escueto: Cursor ya puede controlar tu ordenador, y sus agentes pueden manejar apps de escritorio como el simulador de iOS para probar las funcionalidades que construyen.

Parece poca cosa, pero cambia el bucle. Hasta ahora el agente escribía el código, pasaba los tests y me devolvía el turno para que yo lo viera funcionando. Si el agente puede abrir el simulador, recorrer el flujo y ver qué pasa, esa vuelta la hace él. Yo llego cuando ya hay algo que se ha probado al menos una vez.

GPT-6.1 Terra: el computer use se abarata

La otra pata es el coste. Que un agente use la pantalla gasta muchos tokens: capturas, razonamiento visual, muchos pasos. OpenAI presentó GPT-6.1 Terra como un modelo rápido para computer use y razonamiento visual, a 1 dólar por millón de tokens de entrada, 0,05 en caché y 5 de salida.

Según OpenAI, en Agents’ Last Exam (un benchmark de tareas profesionales con el ordenador) rinde a la par que GPT-6 Astra, a esfuerzo de razonamiento medio, con una décima parte de su precio por token, y termina las tareas más de tres veces más rápido que GPT-6 Astra y GPT-6.1 Sol. También dicen que en Terminal-Bench 4.0 resuelve el 50,3% de las tareas con el razonamiento al máximo, y que para la programación más compleja siguen siendo mejores Sol y Astra.

Son cifras del propio fabricante, así que las tomo con calma hasta probarlo. Pero la dirección me parece la buena. Esto ya es lectura mía, no lo dice OpenAI: si la verificación en pantalla cuesta poco y va rápido, puedes dejar que el agente la haga en cada cambio y no solo cuando te acuerdas.

Hallmark: un revisor que no se fía de la primera versión

La tercera es más pequeña y me ha gustado mucho. Hallmark es una skill de diseño de Together AI para Claude Code, Codex, Cursor y OpenCode. Su objetivo es que la UI que genera un agente no parezca hecha por una IA, y lo interesante para mí es cómo lo comprueba.

Construye primero la cabecera de la página y la revisa sola, antes de seguir. Después pasa un linter en un navegador real (necesita Node, Chrome y puppeteer-core), a ocho anchos de pantalla, buscando los tics típicos de lo generado: la etiqueta pequeña encima de cada título, una palabra coloreada en el titular, el formulario que no envía. Y al final hace una revisión “con ojos frescos”: en Claude Code, según su documentación, la hace un subagente con contexto limpio, mientras que en Codex se hace en el mismo hilo, sin subagente aparte.

Además ordena las reglas por niveles. Hay un suelo que nunca se salta (contraste, foco, movimiento reducido, datos inventados, móvil roto), reglas por defecto que se pueden saltar si dejas escrito el motivo y detalles de acabado que nunca bloquean. Me parece una forma muy sana de escribir criterios de calidad para un agente.

Lo que me llevo para SDD

En Spec-Driven Development la spec no es solo lo que hay que construir; también dice cómo sabremos que está bien. Estas tres novedades hacen que esa segunda parte se pueda delegar mucho más:

  • Los criterios de aceptación pueden ser recorridos de pantalla, no solo tests. “El usuario reserva una cita desde el móvil y le llega la confirmación” es algo que el agente ya puede comprobar abriendo la app.
  • Quien verifica no debería ser el mismo contexto que construyó. Es la misma idea que me gustó del modelo Elephant-Goldfish para revisar specs: el revisor sin contexto ve lo que el autor ya no ve.
  • Las reglas que no se negocian hay que escribirlas aparte de las preferencias. El “suelo” de Hallmark es justo eso, y en una spec funciona igual.

Eso sí, un agente que maneja tu escritorio es un agente con mucho poder. Antes de dejarlo suelto revisaría lo mismo que conté en el post sobre permisos, sandboxes y secretos: qué puede tocar, con qué credenciales y dónde corre. Y cuidado con instalar skills de terceros sin leerlas. Que sean útiles no las hace inofensivas.

Cerrar el bucle

Para mí el salto no es que el agente escriba más rápido. Es que me devuelva el trabajo ya probado, con la evidencia de cómo lo ha comprobado. Eso es lo que deja que un equipo confíe en lo que hacen sus agentes sin revisar cada línea a mano.

En onext ayudamos a equipos a adoptar agentes de IA y a trabajar con SDD, y esta parte de la verificación es donde más se nota la diferencia. Si estás pensando cómo hacer que tus agentes prueben lo que programan, escríbenos y lo vemos juntos.

Fuentes

  1. Cursor (@cursor_ai) en X (se abre en una pestaña nueva)
  2. openai.com (se abre en una pestaña nueva)
  3. GitHub - Nutlope/hallmark: Anti-AI-slop design skill for Claude Code, Cursor, and Codex. (se abre en una pestaña nueva)

Etiquetas

Más artículos de Spec-Driven Development