Zeroshot : l'agent qui écrit le code ne l'approuve jamais, grâce à la relecture indépendante et à la réparation bornée
Zeroshot transforme un objectif logiciel en graphe multi-agents explicite : un agent implémente, des agents indépendants relisent, les échecs repartent dans une boucle de réparation bornée, et rien n'est livré avant la réussite de tous les contrôles. L'implémenteur n'approuve jamais son propre travail. L'outil ne remplace pas Claude Code, Codex ou Copilot : il exécute l'un d'eux comme worker et comme relecteurs. On peut apporter sa propre topologie et l'enregistrer comme profil. La version 8 passe à un binaire natif distribué par npm. Le README ne publie aucun benchmark, la valeur repose donc pour l'instant sur la logique de conception et non sur des mesures.
Le problème visé
Le défaut le plus courant des agents de code IA n'est pas leur incapacité à écrire du code. C'est qu'ils terminent, puis déclarent eux-mêmes que le travail est fini.
Quand un même modèle écrit et valide le code, il corrige sa propre copie. Zeroshot repose sur une seule affirmation : l'agent qui écrit le code ne doit pas être celui qui décide qu'il fonctionne. L'équipe explique avoir créé l'outil parce qu'elle en avait assez d'être induite en erreur par des agents qui présentaient du code cassé comme prêt.
Architecture centrale : un graphe multi-agents explicite
Zeroshot transforme un objectif logiciel en graphe multi-agents explicite. Un agent implémente. Des agents indépendants relisent. Quand une relecture échoue, le travail retourne dans une boucle de réparation bornée. Rien n'est livré tant que les contrôles du graphe ne passent pas. L'agent qui implémente n'approuve jamais son propre travail. C'est la contrainte dure de la conception.
Le positionnement compte autant que le mécanisme. Zeroshot ne remplace ni Claude Code, ni Codex, ni GitHub Copilot. Il exécute l'un d'eux comme worker et comme relecteurs. Ce n'est donc pas un énième modèle de code, mais une couche d'orchestration et de responsabilité autour des agents que vous utilisez déjà. On peut employer le graphe intégré ou apporter sa propre topologie : ajouter des relecteurs, des tests et des boucles de réparation, puis enregistrer la configuration comme profil pour la tâche suivante.
Fonctionnement et usage
L'installation tient en une commande : npm install -g @the-open-engine-company/zeroshot. L'installateur exige Node.js 18 ou plus récent. Il installe un binaire natif vérifié pour Linux x64 ou arm64, macOS x64 ou arm64, ou Windows x64. Il installe aussi un skill Zeroshot pour Codex, GitHub Copilot et Claude Code, au niveau utilisateur. Pour une exécution locale, il faut installer et connecter Codex, Claude Code ou GitHub Copilot. Zeroshot peut réutiliser la connexion existante de ce harnais, y compris les sessions adossées à un abonnement. Une exécution demande deux fichiers JSON. input.json décrit la tâche, par exemple : ajouter une sortie JSON à la commande status et la couvrir par des tests ciblés. runtime.json désigne l'environnement d'exécution : le harnais (par exemple codex), le fournisseur (par exemple openai), le modèle et le niveau d'effort (par exemple high). On lance ensuite zeroshot run avec --template software-change et --uniform-runtime-config runtime.json. D'après son nom, cette option applique une même configuration d'exécution à tous les agents du graphe. Avec --validate-only, on vérifie d'abord le graphe, la configuration et l'entrée, sans rien démarrer.
Un fait mérite une mise en garde. Le worker modifie l'arbre de travail Git courant. La documentation recommande donc de commencer dans un arbre propre, réservé à la tâche.
Pourquoi la relecture indépendante est un choix d'ingénierie solide
Cette section est notre analyse, et non une donnée publiée par le projet. Premièrement, séparer l'auteur du vérificateur brise la boucle d'auto-confirmation. Le contexte de l'agent qui implémente est rempli de ses propres raisons de croire que le changement est correct. Un relecteur sans cet historique repère plus facilement ce qui a été oublié. Deuxièmement, la boucle de réparation a une borne.
Un cycle sans limite de relecture, correction et nouvelle relecture peut consommer le quota sans fin. Une borne rend le coût et la durée prévisibles. Troisièmement, une topologie qui est une donnée configurable, et non un pipeline figé, permet d'adapter le graphe au risque. Une correction d'une ligne de documentation peut utiliser un graphe léger. Une modification de paiement peut recevoir plusieurs relecteurs et des tests.
Performance et coût
Soyons clairs. Les documents que nous avons lus ne contiennent aucun chiffre de benchmark publié. Nous ne pouvons citer ni taux de réussite, ni taux de détection de défauts, ni variation de latence. La vidéo du README est présentée comme scénarisée : c'est une illustration, pas une preuve.
La structure des coûts, elle, est claire. Plus d'agents signifie plus d'appels au modèle et un temps réel plus long. Si une exécution locale réutilise une connexion par abonnement, le coût marginal retombe sur le quota de cet abonnement. Pour les tarifs de Zeroshot Cloud, consultez le site zeroshot.sh.
Impact pour les développeurs et les entreprises
Pour un développeur seul, Zeroshot transforme l'habitude manuelle de demander à un autre agent de relire en une commande répétable. Pour une équipe, il offre une couche de vérification qui ne dépend pas d'un fournisseur de modèle. En dessous, on peut trouver Codex, Claude Code ou Copilot.
Le projet est sous licence MIT et distribué via npm. Le dépôt affiche des badges de construction, de couverture et de documentation, ce qui suggère une maintenance de niveau production. Le projet revendique aussi des étoiles d'ingénieurs de grandes entreprises technologiques. C'est sa propre déclaration, et nous ne l'avons pas vérifiée de façon indépendante.
Limites et défis
Premièrement, il n'existe pas de benchmark public : l'argument de valeur repose aujourd'hui sur la logique de conception. Deuxièmement, la relecture indépendante vaut ce que vaut son indépendance. Si les relecteurs et l'implémenteur viennent de la même famille de modèles, ils peuvent partager les mêmes angles morts.
Troisièmement, une boucle de réparation bornée signifie qu'une tâche peut encore échouer dans sa borne, et les utilisateurs doivent prévoir ce cas. Quatrièmement, comme le worker modifie l'arbre de travail courant, lancer l'outil sans point de départ propre est risqué. Cinquièmement, la version 8 est une rupture d'interface assumée : elle remplace le runtime Node.js par un binaire natif, et les utilisateurs des versions antérieures doivent migrer.
Perspectives
Si les mainteneurs publient des benchmarks reproductibles, par exemple des exécutions mono-agent comparées à des exécutions avec graphe de relecture sur les mêmes tâches, avec taux de réussite et coût total, la valeur de ce type d'outil deviendra mesurable. Le partage de profils est une autre piste à suivre.
Les équipes qui enregistrent des graphes réglés par niveau de risque construiront peu à peu une norme interne de livraison. Dans tous les cas, le principe selon lequel l'auteur ne doit pas être celui qui approuve devient difficile à éviter dans la programmation assistée par IA.