Un ingénieur a livré un agent macOS sans connaître Swift

La nouvelle capacité Computer Use de Qoder permet à une IA d'opérer un véritable bureau : voir l'écran, cliquer sur des boutons, taper, glisser, et continuer en arrière-plan. L'ingénieur qui l'a construite ne pouvait pas lire le code qu'elle produisait, car il ne connaissait pas Swift. Ce détail, enfoui dans le journal de build de l'équipe sur la communauté Alibaba Cloud, est plus intéressant que la fonctionnalité elle-même.

Un article décrivant le projet le dit sans détour : « Je ne savais pas si le code était correct, mais je pouvais dire si l'outil actionnait correctement l'ordinateur. » Une seule personne, sans Swift, devait livrer un logiciel macOS natif de qualité production. La seule définition possible de « terminé » était le comportement.

Un ingénieur, pas de Swift, et un outil de bureau qui clique pour vous

Computer Use semble simple jusqu'à ce qu'on écrive ce que « cliquer sur un bouton » implique. L'action doit réellement avoir un effet. L'état après l'action doit être lisible. Et l'outil ne doit pas accaparer le premier plan, car un agent qui détourne le focus de l'utilisateur à chaque action n'est pas quelque chose qu'on exécutera deux fois. Le journal de build liste ces trois défis concrets du projet.

Ils ont posé une contrainte stricte de leur propre fait. L'ingénieur ne pouvant pas juger la qualité en lisant le code, il l'a jugée en observant le comportement. La stratégie est devenue la suivante : définir à quoi ressemble un résultat correct et faire prouver à l'IA qu'elle l'a atteint, plutôt que d'espérer que le code paraisse juste. Cette publication a déjà soutenu que le véritable goulot d'étranglement pour les agents de bureau est la couverture des compétences, pas le modèle. Cet article est une étude de cas sur le goulot suivant : une fois que l'agent peut agir, comment savoir s'il l'a réellement fait ?

Le premier flux de travail était celui que l'on connaît bien. Écrire le besoin, laisser l'Agent écrire le code, exécuter les tests manuellement, inspecter le résultat, donner un retour. Si vous avez utilisé des assistants de codage IA, c'est la partie que vous reconnaissez : chaque conversation part de zéro, le contexte doit être reformulé, et l'Agent oublie quelles pistes ont déjà échoué. Le goulot d'étranglement, c'est l'humain. L'attention est limitée et discontinue. Quand la personne s'arrête, le système s'arrête.

Du requête-réponse à une boucle qui tourne toute la nuit

La première étape consistait à construire un pipeline que l'Agent pouvait accomplir seul. Computer Use dépend des permissions système, et chaque build doit être signé avec le même certificat, sinon macOS le traite comme une nouvelle application et invalide les permissions d'enregistrement d'écran et d'accessibilité déjà accordées. L'équipe a enveloppé tout le parcours, du build source à la signature stable, en passant par le lancement et les tests, dans une seule commande. L'Agent n'a jamais besoin de comprendre la signature. Il a seulement besoin d'un chemin fiable vers un paquet valide.

Exécuter une fois ne suffit pas. Une conversation d'Agent normale est de type requête-réponse : la tâche se termine, l'Agent s'arrête. Construire un outil demande de nombreuses étapes, car la compilation échoue, les tests échouent, le comportement est erroné dans une application, ou un correctif casse quelque chose ailleurs. La réponse de Qoder est le Goal Mode. Donnez un objectif à l'Agent, comme « implémenter l'outil de clic et réussir le test de bout en bout », et il continue de travailler, implémenter, tester, corriger et réessayer jusqu'à ce qu'il converge ou ait clairement besoin d'une décision humaine.

Le test vert qui ne prouvait rien

La capacité à s'exécuter seul a fait apparaître un nouvel échec. Chargé d'implémenter l'outil de clic, l'Agent a exécuté le test et annoncé un succès. Une vérification manuelle a montré que le bouton n'avait jamais été cliqué. Le test vérifiait seulement que l'appel ne levait pas d'exception. Il ne vérifiait jamais que l'état du bouton avait changé. Test vert, mauvais comportement.

Le problème n'était pas les tests manquants. C'étaient les tests faibles. Si un test ne couvre que le chemin le plus heureux, l'Agent peut écrire une implémentation qui ne fait rien et réussir quand même. La nouvelle règle : aucun changement n'est complet s'il ne passe pas une vérification réelle et suffisante. L'équipe décrit un schéma de vérification à trois niveaux, et le niveau sur lequel elle insiste est que l'Agent génère ses propres tests. Implémenter l'outil de clic signifie construire une petite application qui peut réellement être cliquée et prouver que l'état visible change. L'article montre une telle application de test générée par l'Agent, couvrant champs de texte, boutons, curseurs, défilement, vues imbriquées, listes et autres éléments d'interface, avec de nombreuses applications similaires construites pour différents scénarios.

Un correctif du lundi qui revient le mercredi

La vérification prouve que le changement actuel fonctionne. Elle ne protège pas contre les régressions. Supposons que le correctif du lundi empêche un clic de voler le focus du premier plan. L'optimisation du mercredi touche une logique connexe, l'ancien bug refait surface, et personne ne le remarque, car il se trouve en dehors du périmètre de test de la tâche en cours.

La réponse de l'équipe est directe : chaque problème corrigé devient un cas de test persistant, vérifié automatiquement lors des cycles suivants. Les bogues découverts pendant le développement entrent dans la suite de régression, tout comme les retours utilisateurs réels. Un rapport tel que « le clic ne fonctionnait pas dans cette application » devient un scénario reproductible et rejoint définitivement l'ensemble de régression. Les problèmes déjà survenus ne devraient pas vivre uniquement dans la mémoire humaine. Ils devraient devenir des vérifications automatiques.

L'article cite deux échecs réels ayant une cause racine unique : l'Agent n'avait aucune mémoire entre les cycles. Mettre toutes les connaissances dans le prompt ne fonctionne pas, car la fenêtre de contexte n'est pas assez grande et l'explication manuelle omet toujours quelque chose. La solution de l'équipe est de conserver la mémoire dans le système de fichiers, répartie en deux couches. La mémoire projet contient les connaissances stables : architecture, contraintes, conclusions de recherche. Les notes rétrospectives contiennent ce qui a changé à chaque cycle, ce qui reste, et où le cycle suivant devrait commencer.

Le répertoire docs/ est la disposition de la mémoire :

docs/
├── specs/              exigences et critères d'acceptation
├── architecture/       architecture et contraintes fondamentales
├── implementation/     notes sur les modules d'implémentation clés
├── research/           recherche technique et justification des décisions
├── plans/              plans d'itération de l'étape suivante
├── retrospectives/     revues par cycle, problèmes ouverts et risques
├── evidence/           résultats de tests et enregistrements de validation du comportement
└── test-cases/         source, couverture et historique des scénarios de test

Au début de chaque cycle, l'Agent lit la mémoire projet et la rétrospective précédente. À la fin, il réécrit. La boucle complète est : objectif, puis implémentation, vérification, rétrospective, puis l'objectif suivant. Plus aucun cycle ne part de zéro.

Loop Engineering, et la barrière qui s'est déplacée

L'équipe rapporte des centaines d'heures d'itération continue, y compris de longues périodes de travail nocturne sans supervision, avec des graphiques d'évaluation publiés aux côtés de l'article. Le problème initial, une personne incapable de lire Swift livrant un logiciel macOS natif de qualité production, s'est résolu. Non, argue l'équipe, parce que l'IA était puissante par elle-même, mais parce qu'un système l'entourait : critères d'acceptation, tests, mémoire, régression. À l'intérieur de ce système, l'IA pouvait s'exécuter, se vérifier et accumuler des connaissances par elle-même.

Le rôle de l'humain est passé de l'écriture de code et de la supervision de l'exécution à la définition des normes, à la conception de la vérification et au choix de la direction. Le terme « Loop Engineering » est devenu populaire récemment, et l'équipe dit avoir reconnu sa propre pratique dans cette étiquette. Si la boucle fonctionne, un ingénieur n'a plus besoin d'être expert d'une pile technologique spécifique pour livrer un logiciel de qualité production. La pile cesse d'être la barrière principale. Ce qui compte, c'est la capacité à définir la cible et à vérifier le résultat.

Qoder Desktop inclut déjà les capacités Goal Mode et Spec, et la dernière version améliore UltraPlan et UltraReview. Les outils de validation à usage général tels que Computer Use et Browser Use sont destinés à aider les équipes à construire leurs propres systèmes d'itération autonomes. L'affirmation la plus discrète de l'article est celle qui mérite qu'on s'y attarde : un ingénieur n'a plus besoin d'une expertise approfondie d'une pile pour livrer avec elle un logiciel de production. La pile n'a jamais été la véritable barrière. La vérification l'était.