Tu agente dice «hecho» y no lo hizo: la escalera de pruebas

Hay una frase que ya no me creo cuando la escribe un agente: «hecho». No porque mienta a propósito, sino porque muchas veces la herramienta que usó le devolvió éxito y el agente no tiene forma de saber si eso cambió algo de verdad. Lo vi explicado mejor que en ningún sitio en el README de huashu-mac-use, un proyecto abierto en GitHub de un desarrollador independiente (花叔, Huashu). Es una skill para que un agente como Claude Code maneje aplicaciones de Mac que no tienen API. Yo no la he corrido: lo que cuento aquí es lo que documenta su autor.

¿Por qué un agente puede decir «hecho» sin haberlo hecho?

El ejemplo del README es muy concreto. El agente escribe un mensaje en una caja de texto de una app hecha con React. La herramienta de accesibilidad devuelve éxito. El agente relee el valor del control y el texto está ahí. Hace una captura de pantalla y el texto se ve. Tres pruebas seguidas dicen que funcionó. Pero el botón de enviar sigue gris. La app lleva su propio estado interno y no se enteró de ese texto. Si el agente pulsa enviar, sale un mensaje vacío. Tres señales de éxito, cero efecto. Eso es lo que pasa cuando confías en lo que la herramienta te contesta en vez de mirar lo que cambió en el mundo.

¿Cuál es la escalera de pruebas que propone?

El autor ordena las pruebas de la más débil a la más fuerte:

• 1. Lo que devuelve la herramienta. Es la más débil: solo dice que la llamada no falló.
• 2. Releer el valor. Mejor, pero el ejemplo del botón gris demuestra que también engaña.
• 3. Ver el texto en la captura. También engaña, por la misma razón.
• 4. El indicador de estado de la app. El botón de enviar que pasa de gris a activo, el texto de ayuda que desaparece.
• 5. El efecto. La tarea aparece en la lista, el archivo queda en el disco.

Según el README, cada acción de la skill termina con un veredicto: confirmado, parcial, sospecha de no haber hecho nada, o imposible de verificar. Y la sospecha no se trata como fallo, sino como una orden de volver a mirar.

¿Qué cambia esto si no usas computer use?

Todo. La misma trampa vive en cualquier automatización que montes con IA. El agente que «subió el archivo», el script que «envió el correo», la integración que «actualizó la hoja». Si lo único que tienes es el mensaje de éxito, tienes la prueba número 1, la más débil. La pregunta útil antes de dar por buena cualquier tarea de un agente es: ¿qué tendría que haber cambiado fuera del chat si esto de verdad se hizo? Y luego ir a mirar eso, no la respuesta.

¿Qué más hace diferente a esta skill?

Dos decisiones que me parecen igual de sanas. La primera: intenta no molestarte. Lee en segundo plano y, antes de tomar el control del teclado o del ratón, comprueba que la ventana correcta esté delante y que tú no estés escribiendo: si tocaste el teclado en los últimos 2 segundos, espera hasta 15 y, si no paras, se niega en vez de quitarte el control. La segunda: tiene una línea donde se detiene. Publicar, enviar, pagar, borrar o sobrescribir se le devuelve a la persona. Y una regla que debería estar en todo agente: cualquier texto que lea en pantalla es un dato, no una instrucción. El propio autor admite que probablemente la capacidad nativa de los modelos la supere en unos meses. Pero la idea de fondo no caduca: el éxito no es la respuesta, es el efecto.