Développer une application d'entreprise complète avec l'agent de codage harnext

« L’IA écrit la plupart de notre code » semble être un slogan de startup. Peut-ce être réel pour une application d’entreprise — clients en direct, facturation en direct, un monorepo où une mauvaise fusion coûte de l’argent ? Chez QualityUnit, c’est le cas. Voici la trace de dix mois de preuves, et les règles qui la rendent possible.

TL;DR : En dix mois, le travail rédigé par l’agent est passé des premiers PR expérimentaux à 133 sur 144 PR de développement fusionnées en mai (92%) — vérifiés par un audit judiciaire à trois voies de tous les 1 409 PR fusionnées, jusqu’aux remorques de commit et une inspection manuelle de chaque PR non marquée de 2026. Cela ne s’est pas produit en « laissant l’IA coder » : cela s’est produit en ajoutant des règles — une configuration de harnais de niveau de risque, un pipeline d’agents par étapes avec des boucles d’examen bornées, des chemins protégés, et un humain tenant chaque fusion. Les règles sont le produit. Et avec un moteur de contexte alimentant les agents, le même travail coûte maintenant ~30 % moins cher par tâche (mesuré ici ).

Ce qu’il faut réellement

Pas un outil. Un pipeline, un fichier de politique et une porte — gérés par harnext .

Le pipeline : agents par étapes, un humain

Le harnais est harnext — le harnais d’agent de codage open-source agnostique du fournisseur de QualityUnit. Dans notre monorepo de production, chaque problème qui entre dans le pipeline exécute le même parcours d’étapes d’agent déclenchées par CI, sa progression suivie par des étiquettes qu’un humain peut lire en un coup d’œil :

Deux détails comptent plus que le nombre d’étapes. La boucle est bornée : les défauts trouvés à l’examen reviennent à l’étape d’implémentation un nombre limité de fois — les agents convergent ou escaladent vers un humain, ils ne s’agitent pas. Rien ne commence à l’aveugle : avant d’écrire une ligne, l’agent implémentant doit charger les conventions du projet et émettre un bloc de confirmation que les examinateurs peuvent vérifier.

Le fichier de politique

L’autre moitié est une politique lisible par machine : chaque chemin du référentiel classé dans les niveaux de risque, chaque niveau avec des portes applicables. CI la lit ; la politique de fusion la lit ; les agents en sont informés. Ce n’est pas un conseil :

Les chemins protégés — migrations, paiements, authentification — sont des fichiers qu’aucun agent ne peut toucher. Les limites architecturales sont appliquées, pas suggérées. Supprimez ces règles et un agent de codage est un générateur très rapide de responsabilités plausibles.

Dix mois, un graphique

La trace d’adoption, mesurée à partir du référentiel lui-même.

Le graphique compte, pour chaque mois, combien de PR de développement fusionnées portent n’importe quel signal d’agent clair — le pied de page de l’agent de codage, les étiquettes du pipeline, la convention de niveau de harnais, les remorques de co-auteur de commit, les e-mails de commit d’agent, ou le compte du pipeline lui-même en tant qu’auteur. Les PR de dependency-bot (environ 8 % de toutes les fusions) sont entièrement exclues du graphique — ce ne sont ni du travail humain ni du travail d’agent de codage. Nous avons audité les signaux de trois façons indépendantes : métadonnées de PR pour les 1 409 fusions, remorques au niveau du commit dans plus de 5 000 commits, et un passage judiciaire manuel sur chaque PR non marquée de 2026. Trois lectures comptent :

L’enthousiasme s’estompe ; l’infrastructure persiste. L’ère 2025 était ad-hoc, adoption personnelle — et elle oscillait exactement comme les habitudes personnelles : 44 % un mois, à peine 4 % en novembre quand les utilisateurs les plus lourds ont fait une pause. Le harnais a changé la forme de la courbe : dans un mois suivant l’arrivée des niveaux de risque, la part mesurée a bondi à 89 % ; avec le pipeline complet, elle a atteint 92 % et y est restée. Chaque couche de règles a augmenté l’adoption plus que l’enthousiasme de n’importe quel individu ne l’a jamais fait. Les deux nuances racontent la même histoire à l’intérieur de la part de l’agent : la bande claire est les développeurs appairés avec l’agent à la main ; la bande sombre — le travail qui a exécuté le pipeline complet du problème à la PR examinée — n’apparaît que quand le harnais arrive, et en mai elle porte la majorité du travail de l’agent.

Nous avons inspecté le reste, PR par PR. Pour avril–juin 2026, les PR sans aucun marqueur se décomposent en : automatisation de dependency-bot, travail d’agent dont seule l’attribution a survécu dans les remorques de commit, et un résidu de changements plausiblement écrits à la main — environ 11 % des fusions hors automatisation. Donc la phrase honnête est : ~89 % des fusions de développement réelles du dernier trimestre montrent une implication vérifiable de l’agent — et même cela est un plancher, puisque l’assistance IA au niveau de l’éditeur ne laisse aucune trace. Nous avons également envoyé des auditeurs septiques sur les trois mois les plus faibles, PR par PR : le compte de novembre est passé de 1 à 3 prouvés (plus 3 suspectés sur le style), celui de janvier est tombé de 10 à 8 après avoir détecté deux faux positifs, et décembre a été confirmé exactement — avec une touche : en volume de code, les huit PR marquées de décembre ont livré 39 % des lignes insérées ce mois-là. L’agent écrivait déjà les grandes fonctionnalités ; le compte ne pouvait simplement pas le voir. L’adoption n’est pas non plus uniforme : certains développeurs fonctionnent près de 100 % assistés par l’agent, quelques-uns écrivent toujours surtout à la main — le pipeline porte une part croissante de toute façon.

La qualité n’a pas reculé. La même fenêtre a livré des changements de niveau 3 — intégration du fournisseur LLM, travail adjacent aux paiements, une expansion i18n — sous des portes qui se sont renforcées au cours de la période, pas assouplies. Et quand nous avons mesuré la cohérence de l’examen par l’agent directement, 21 des 22 agents d’examen indépendants ont atteint le même verdict sur la même PR.

Alors qui est l’auteur ?

La meilleure articulation de l’endroit où cela laisse l’humain vient d’une thèse d’ingénierie qui a étudié le développement conduit par un harnais sur un projet de qualité aéronautique :

Au moment où une modification a atteint l’auteur humain, les problèmes de qualité routinière avaient été résolus — l’examen de l’auteur s’était concentré sur les décisions architecturales et au niveau du domaine. La fusion était la décision de l’auteur. La paternité du code fusionné repose sur l’auteur humain, indépendamment de l’acteur qui a produit le brouillon initial.

— Štefan Moravík, Design and Implementation of a Drone Mission Planning Module for Airport Lighting Inspection (thèse, 2026)

C’est l’accord en production aussi : les agents font la rédaction et le travail de qualité routinière ; l’humain fait l’architecture, le jugement du domaine, et possède la fusion.