Un ingeniero lanzó un agente macOS sin saber Swift

La nueva capacidad Computer Use de Qoder permite que una IA opere un escritorio real: ver la pantalla, hacer clic en botones, escribir, arrastrar y seguir funcionando en segundo plano. El ingeniero que la construyó no podía leer el código que producía, porque no sabía Swift. Ese detalle, escondido en la bitácora de desarrollo del equipo en la comunidad de Alibaba Cloud, es más interesante que la propia función.

Una publicación que describe el proyecto lo dice sin rodeos: «No sabía si el código era correcto, pero podía saber si la herramienta operaba correctamente la computadora». Una sola persona, sin Swift, tenía que entregar software nativo de macOS de calidad de producción. La única definición viable de «terminado» era el comportamiento.

Un ingeniero, sin Swift, y una herramienta de escritorio que hace clic por ti

Computer Use suena simple hasta que anotas lo que implica «hacer clic en un botón». La acción tiene que surtir efecto de verdad. El estado posterior a la acción tiene que ser legible. Y la herramienta no debe robar el primer plano, porque un agente que le quita el foco al usuario cada vez que actúa no es algo que nadie ejecute dos veces. La bitácora de desarrollo enumera estos tres desafíos concretos del proyecto.

De ahí surgió una restricción dura propia. El ingeniero no podía juzgar la calidad leyendo el código, así que la juzgaba observando el comportamiento. La estrategia pasó a ser definir cómo se ve un resultado correcto y hacer que la IA demuestre que lo logró, en lugar de esperar que el código tuviera buena apariencia. Este medio ya ha argumentado antes que el verdadero cuello de botella para los agentes de escritorio es la cobertura de habilidades, no el modelo. Este post es un caso de estudio sobre el siguiente cuello de botella: una vez que el agente puede actuar, ¿cómo sabes que realmente lo hizo?

El primer flujo de trabajo era el conocido. Escribir el requisito, dejar que el Agente escribiera el código, ejecutar las pruebas manualmente, inspeccionar el resultado, dar retroalimentación. Si has usado asistentes de codificación con IA, esta es la parte que reconoces: cada conversación comienza desde cero, el contexto tiene que repetirse, y el Agente olvida qué direcciones ya fallaron. El cuello de botella es el humano. La atención es limitada y discontinua. Cuando la persona se detiene, el sistema se detiene.

De petición-respuesta a un bucle que corre toda la noche

El primer paso fue construir un pipeline que el Agente pudiera completar solo. Computer Use depende de permisos del sistema, y cada compilación tiene que estar firmada con el mismo certificado, o macOS la trata como una aplicación nueva e invalida los permisos de Grabación de Pantalla y Accesibilidad ya otorgados. El equipo envolvió todo el recorrido, desde la compilación del código fuente hasta la firma estable, el lanzamiento y las pruebas, en un solo comando. El Agente nunca necesita entender la firma. Solo necesita una ruta confiable hasta un paquete válido.

Ejecutar una vez no es suficiente. Una conversación normal de Agente es de petición y respuesta: la tarea termina, el Agente se detiene. Construir una herramienta requiere muchos turnos, porque la compilación falla, las pruebas fallan, el comportamiento es incorrecto en una aplicación, o una corrección rompe algo en otro lugar. La respuesta de Qoder es Goal Mode. Dale al Agente un objetivo, como «implementa la herramienta de clic y pasa la prueba de extremo a extremo», y sigue trabajando, implementando, probando, corrigiendo y reintentando hasta que converge o claramente necesita una decisión humana.

La prueba en verde que no demostró nada

La capacidad de ejecutarse solo sacó a la luz un nuevo fallo. Se le pidió que implementara la herramienta de clic. El Agente ejecutó la prueba e informó éxito. Una comprobación manual mostró que el botón nunca se había pulsado. La prueba solo verificaba que la llamada no lanzara una excepción. Nunca comprobaba que el estado del botón hubiera cambiado. Prueba en verde, comportamiento incorrecto.

Las pruebas faltantes no eran el problema. Las pruebas débiles sí. Si una prueba solo cubre el camino feliz, el Agente puede escribir una implementación que no haga nada y aun así aprobar. La nueva regla: ningún cambio está completo si no pasa una verificación real y suficiente. El equipo describe un esquema de verificación de tres capas, y la capa en la que hace hincapié es que el Agente genera sus propias pruebas. Implementar la herramienta de clic significa construir una pequeña aplicación en la que realmente se pueda hacer clic y demostrar que el estado visible cambia. El post muestra una de esas aplicaciones de prueba generadas por el Agente, que cubre campos de texto, botones, deslizadores, desplazamiento, vistas anidadas, listas y otros elementos de interfaz, con muchas aplicaciones similares construidas para diferentes escenarios.

Un arreglo del lunes que regresa el miércoles

La verificación demuestra que el cambio actual funciona. No protege contra regresiones. Supongamos que el arreglo del lunes evita que un clic robe el foco del primer plano. La optimización del miércoles toca la lógica relacionada, el viejo error resurge y nadie lo nota, porque queda fuera del alcance de pruebas de la tarea actual.

La respuesta del equipo es contundente: cada problema corregido se convierte en un caso de prueba persistente, verificado automáticamente en rondas futuras. Los errores encontrados durante el desarrollo entran en la suite de regresión, y también los comentarios reales de los usuarios. Un informe como «hacer clic no funcionó en esta aplicación» se convierte en un escenario repetible y se une permanentemente al conjunto de regresión. Los problemas que ya ocurrieron no deberían vivir solo en la memoria humana. Deberían convertirse en verificaciones automáticas.

El post cita dos fallos reales con una única causa raíz: el Agente no tenía memoria entre rondas. Poner todo el conocimiento en el prompt no funciona, porque la ventana de contexto no es lo suficientemente grande y la explicación manual siempre omite algo. La solución del equipo es mantener la memoria en el sistema de archivos, dividida en dos capas. La memoria del proyecto guarda conocimiento estable: arquitectura, restricciones, conclusiones de investigación. Las notas retrospectivas guardan qué cambió en cada ronda, qué queda pendiente y dónde debería comenzar la siguiente ronda.

El directorio docs/ es la estructura de la memoria:

docs/
├── specs/              requisitos y criterios de aceptación
├── architecture/       arquitectura y restricciones principales
├── implementation/     notas sobre los módulos de implementación clave
├── research/           investigación técnica y justificación de decisiones
├── plans/              planes de iteración de la siguiente etapa
├── retrospectives/     revisiones por ronda, problemas abiertos y riesgos
├── evidence/           resultados de pruebas y registros de validación de comportamiento
└── test-cases/         fuente, cobertura e historial de escenarios de prueba

Al comienzo de cada ronda, el Agente lee la memoria del proyecto y la retrospectiva anterior. Al final, actualiza la memoria. El bucle completo es Objetivo, luego Implementación, Verificación, Retrospectiva, y luego el siguiente objetivo. Ya ninguna ronda comienza desde cero.

Ingeniería de bucles, y la barrera que se movió

El equipo reporta cientos de horas de iteración continua, incluidos largos períodos de trabajo nocturno sin supervisión, con gráficos de evaluación publicados junto al post. El problema original, una persona que no podía leer Swift lanzando software nativo de macOS de calidad de producción, se resolvió. No, argumenta el equipo, porque la IA fuera poderosa por sí sola, sino porque había un sistema a su alrededor: criterios de aceptación, pruebas, memoria, regresión. Dentro de ese sistema, la IA podía ejecutarse, verificar y acumular conocimiento por sí misma.

El papel del humano pasó de escribir código y observar la ejecución a definir estándares, diseñar la verificación y elegir la dirección. El término «Loop Engineering» se ha vuelto popular últimamente, y el equipo dice que reconoció su propia práctica en esa etiqueta. Si el bucle funciona, un ingeniero ya no tiene que ser experto en una pila tecnológica específica para entregar software de calidad de producción. La pila deja de ser la barrera principal. Lo que importa es la capacidad de definir el objetivo y verificar el resultado.

Qoder Desktop ya incluye capacidades de Goal Mode y Spec, y la última versión mejora UltraPlan y UltraReview. Las herramientas de validación de propósito general, como Computer Use y Browser Use, están pensadas para ayudar a los equipos a construir sus propios sistemas de iteración autónomos. La afirmación más silenciosa del post es la que vale la pena considerar: un ingeniero ya no necesita experiencia profunda en una pila tecnológica para lanzar software de producción con ella. La pila nunca fue la barrera real. La verificación lo era.