La précision du vibe coding est une mesure, pas une propriété du modèle
Deux équipes qui utilisent le même modèle obtiennent des résultats très différents, parce que la précision, au niveau qui vous intéresse, se joue après la génération. Quelqu'un a-t-il vérifié ? Par rapport à quoi ? En combien de temps un résultat erroné est-il revenu pour être corrigé ?
Posée ainsi, la question n'est plus « quel modèle est le plus précis » mais « quelle est ma boucle de retour », et cela, vous le maîtrisez.
Ce qui mérite d'être mesuré
Le comportement décrit se produit-il
La seule définition de « correct » qui survive au contact d'un utilisateur.
Mesuré en exécutant le parcours, pas en lisant le code.
Ce qui marchait hier marche-t-il encore
Passé la première semaine, le taux de régression compte plus que la précision au premier essai.
Environ une modification de fonctionnalité sur cinq casse quelque chose qui fonctionnait auparavant.
Le temps nécessaire pour obtenir un résultat correct
Le nombre de tentatives avant le vert est plus utile que le succès ou l'échec au premier essai.
C'est ce qui traduit ce que vous ressentez vraiment : la durée de la boucle.
Le piège : des tests écrits par le même auteur
La façon évidente de mesurer la précision consiste à faire écrire les tests par l'agent et à voir s'ils passent. On obtient un chiffre presque toujours élevé et qui ne veut pas dire grand-chose. Un test généré à partir des mêmes hypothèses que l'implémentation lui donne raison par construction, y compris là où les deux se trompent.
Une mesure de la précision exige une vérification indépendante. Quelque chose qui éprouve le produit par rapport au comportement attendu, et non par rapport à l'idée que le code se fait de lui-même.
Mettre la mesure en place
Décrivez en langage courant les parcours qui définissent ce qui est correct pour votre produit, avant la prochaine série de modifications. Exécutez-les sur l'application déployée. La première exécution vous donne une référence, et chacune des suivantes vous donne un signal de régression.
Rien de tout cela ne demande un terminal. Créez un projet dans le tableau de bord TestSprite, décrivez la vérification en langage courant et pointez-la vers votre application. Les développeurs de votre équipe peuvent piloter la même chose en ligne de commande s'ils le préfèrent, ce qui se trouve dans le dépôt CLI.
Une donnée qui mérite d'être connue
Sur un classement public où des agents de code construisaient la même application, le modèle le moins cher du lot a produit l'application la plus correcte dès lors qu'une boucle de vérification était en place, pour la moitié du coût de la solution la plus onéreuse. L'intéressant n'est pas le classement. C'est que la boucle a compté davantage que le modèle, soit l'inverse de la façon dont on parle habituellement de précision.
À quoi sert vraiment ce chiffre
On collecte généralement des chiffres de précision pour répondre à une question que personne n'a posée, du type « le modèle est-il bon ». La question utile est plus étroite : puis-je fusionner ce changement.
Cela change le cadrage de la mesure. Vous n'avez pas besoin d'un score sur l'ensemble de votre produit, vous avez besoin de savoir si ce changement a cassé quelque chose qui fonctionnait avant lui. Une poignée de vérifications couvrant les parcours qui comptent, exécutées sur la version déployée, y répondent en quelques minutes. Un benchmark exhaustif répond à une autre question, en une semaine.
Cela change aussi le sens d'un mauvais chiffre. Un taux de précision en baisse sur un benchmark, c'est intéressant. Un parcours précis qui fonctionnait hier et qui ne fonctionne plus aujourd'hui, c'est exploitable, et c'est le second qui empêche les problèmes d'atteindre les utilisateurs.
Rendre la mesure continue
Une mesure ponctuelle ne renseigne que sur un instant. La précision est une propriété d'un processus continu : les vérifications ont donc leur place à chaque modification.
Deux voies, et le choix porte en réalité sur qui détient le pipeline. Connecter la GitHub App depuis le tableau de bord ne demande aucune modification de votre dépôt, car elle réagit au déploiement que votre build produit déjà. Ajouter une étape GitHub Actions place la vérification dans le dépôt, où elle est relue comme le reste du build.
Faire de la précision quelque chose que vous mesurez
TestSprite est la vérification indépendante dont cette mesure a besoin. Il éprouve votre produit déployé par rapport au comportement que vous avez décrit, et non par rapport à l'idée que le code se fait de lui-même, ce qui donne un sens au chiffre quand l'implémentation et ses tests proviennent du même agent.
En pratique, vous décrivez une seule fois les parcours qui définissent ce qui est correct pour votre produit, et ils s'exécutent à chaque modification. La première exécution constitue votre référence. Chacune des suivantes répond à la question que vous vous posez vraiment : ce changement a-t-il cassé quelque chose qui fonctionnait hier ?
Vous obtenez ainsi les deux chiffres qui méritent d'être suivis : le taux de régression par modification, et le nombre de tentatives nécessaires pour revenir au vert. Les deux évoluent quand la boucle se resserre, et aucun ne peut être gonflé en écrivant davantage de tests.
Quel modèle est le plus précis pour le vibe coding ?
Ce n'est pas la bonne question pour la plupart des équipes. L'écart introduit par le fait de vérifier ou non est plus grand que l'écart entre les modèles de pointe actuels.
Puis-je mesurer la précision sans écrire de tests ?
Oui. Décrivez les parcours en langage courant et faites-les exécuter sur l'application. Vous mesurez un comportement, et observer un comportement n'exige pas de code de test.
Qu'est-ce qu'un bon chiffre de précision ?
Il n'existe pas de référence utile d'un produit à l'autre. Suivez plutôt votre propre tendance : le taux de régression par modification et le nombre de tentatives avant un résultat correct. Les deux devraient baisser à mesure que la boucle se resserre.
Une couverture plus élevée signifie-t-elle une meilleure précision ?
Pas de façon fiable. La couverture comptabilise ce qui a été exercé, pas la justesse des attentes. Une vaste suite de tests générés peut afficher une couverture élevée sur de mauvaises hypothèses.
À quelle fréquence dois-je refaire la mesure ?
À chaque modification, automatiquement. Une précision mesurée selon un calendrier vous renseigne sur le calendrier plutôt que sur la modification qui a cassé quelque chose.
La précision, c'est votre boucle, pas votre modèle.
La précision du vibe coding est quelque chose que vous mesurez sur votre propre produit : le comportement décrit se produit-il, ce qui marchait hier marche-t-il encore, combien de temps pour obtenir un résultat correct. Utilisez une vérification indépendante plutôt que des tests écrits par le même auteur, et mesurez à chaque modification.