Retour au fil

J'ai arrêté d'écrire du code et j'ai commencé à écrire des tests : la nouvelle règle du travail avec l'IA

Un développeur qui n'a presque plus écrit de code à la main depuis quatre mois dans son nouveau poste explique sa pratique de résolution de tickets avec Claude : il découpe chaque ticket en tests, fait écrire les tests en premier, puis fait générer le code jusqu'à ce que les tests passent. J'ai compilé la thèse de la vidéo — de son passé de tests de tracteurs à son cadrage en problème de satisfaction de contraintes — avec les critiques issues de recherches indépendantes.

Importé dans Nodesdaily : (UTC+03:00)
Voir sur YouTube — docRDeC2yxM
Options de lecture

La lecture vocale n’est pas disponible dans ce navigateur.

Loupe à concepts

Choisissez un terme technique de cette vue pour lire sa définition générale, un exemple pédagogique et son usage dans l’article.

Aucun terme de notre glossaire n’a été trouvé dans cette vue. Le glossaire ne couvre pas encore tous les termes.

La vidéo s'ouvre sur une confession honnête : le narrateur dit qu'il n'a presque plus écrit de code à la main depuis six mois et que sa façon de travailler a fondamentalement changé — et il calibre les attentes du spectateur en conséquence. Ce n'est pas une vantardise de productivité mais l'annonce d'un changement de rôle ; le travail du développeur est passé de la frappe de touches à la décision de ce qui doit être construit.

Il a commencé un nouveau poste il y a quatre mois où l'équipe utilise Angular, et après des années avec React, il s'est d'abord demandé comment il comblerait cet écart. L'écart s'est comblé vite : grâce à l'IA générative, il s'est à la fois familiarisé avec le nouveau framework et est parvenu à livrer sans une seule ligne écrite à la main. L'affirmation ici est que l'IA abaisse le seuil d'apprentissage ; ma lecture est que là où le seuil baisse, le besoin de supervision augmente.

Son flux quotidien fonctionne ainsi : un abonnement Claude à limite élevée fourni par son employeur — de son propre aveu un quota qu'ils ne peuvent pas épuiser — plus le plan Max sur la table. Chaque ticket entrant est d'abord découpé en morceaux, analysé par questions-réponses avec Claude, et seulement ensuite résolu. La partie génération se termine en 45 à 50 minutes environ ; la vidéo dit que le vrai problème commence après.

Le point de rupture, c'est le sentiment d'appartenance : dans un nouveau poste, il doit répondre de ce qu'il produit et expliquer pourquoi les choses ont été construites de cette manière. Générer sans réfléchir ne procure ni joie ni salaire, et l'équipe le remarque. C'est là que la vidéo énonce sa thèse : à l'ère de l'IA, l'importance de l'écriture de tests a été multipliée.

La thèse ne flotte pas dans le vide ; elle arrive avec l'appui de son passé. Le narrateur a auparavant travaillé sur des logiciels de tracteurs et menait des tests qui intégraient le matériel dans la boucle — tests unitaires, de régression et de bout en bout exécutés sur un banc ressemblant étroitement à la vraie machine. Là où essayer chaque petit changement sur le terrain est impossible, les tests étaient la seule base de confiance. La production de l'IA d'aujourd'hui occupe la même position : on ne peut pas inspecter chaque ligne à l'œil, donc on s'appuie sur les tests.

L'exemple concret passe par un ticket de suivi de travail : la fonctionnalité demandée et les approches suggérées sont correctement rédigées, et Claude s'en empare et le résout en moins d'une heure. Mais la question demeure : comment savoir si cette solution fonctionne réellement ? Sa réponse est une compétence pilotée par les tests qu'il a construite dans Claude : il découpe chaque phrase du ticket en morceaux testables, lui fait écrire des tests unitaires propres pour tout ce que l'utilisateur devrait voir en appuyant sur un bouton, et ajoute des tests reproduisant le problème signalé par l'utilisateur. Un seul ticket produit six ou sept tests compris à la fois par lui et par le modèle.

Puis la boucle s'inverse : avec une instruction « écris le code jusqu'à ce que ces tests passent », le modèle est lâché, et en sort une solution satisfaisant les tests. Il dit pouvoir expliquer cette solution à cent pour cent, et que le modèle comprend aussi le sujet. Deux directives pratiques arrivent en bonus : demander une solution minimale et lui faire supprimer les lignes de commentaires inutiles. Pas de storytelling — c'est résolu, c'est résolu.

Le cadre conceptuel de la vidéo est le problème de satisfaction de contraintes : les tests sont les constantes, et le travail du modèle est de trouver du code satisfaisant ces constantes avant que le budget de tokens ne soit épuisé. Il dit avoir appliqué cette discipline intensément pendant quatre mois, écrivant 150 à 200 tests unitaires en amont pour les nouvelles applications, et les tests le détectent chaque fois que le modèle hallucine. Il termine en demandant aux spectateurs comment ils utilisent l'IA et comment elle a changé leur vie. Sa propre réponse est nette — il est heureux, parce qu'il peut prouver les résultats.

Visualization: nodesdaily AI

Commentaire de l’IA

""Cette vidéo m'a fait remettre en question ma propre pratique : à mesure que la production s'accélère, est-ce que je néglige moi aussi la vérification ? Je suis d'accord avec la conclusion du narrateur — quand l'IA rend le code bon marché, les tests deviennent la partie coûteuse — mais je pense qu'une boucle dans laquelle le même modèle écrit les tests a besoin de sa propre audit d'indépendance.""

Évaluation de l’IA

Laissez-moi d'abord présenter sous son meilleur jour l'objection la plus forte : dans cette boucle, le même modèle écrit à la fois les tests et le code. Une étude de 2026 de l'Université de Toronto a mesuré qu'un modèle auquel on montre du code bogué se plie systématiquement vers des tests qui confirment le bug — des tests qui certifient le défaut comme s'il s'agissait d'un comportement voulu — et a montré que l'effet pénètre jusqu'aux préférences internes du modèle. Le signal vert « tests passés » de la vidéo pourrait donc être deux signatures du même angle mort. En faveur de la vidéo toutefois, le narrateur écrit les tests « en accord » avec le modèle et insiste pour pouvoir expliquer chaque solution, ce qui préserve intuitivement la différence entre tests dérivés des exigences et tests dérivés du code. Néanmoins, la revendication d'indépendance reste incomplète sans une couche de vérification séparée.

Ma deuxième réserve concerne les limites de la méthode : l'hypothèse qu'une simple instruction test-first réduit les régressions ne tient pas toujours. L'étude ouverte TDAD a constaté que donner à de petits modèles une procédure « écris d'abord les tests » sans une carte des tests à risque augmentait les régressions — de 6,08 pour cent à 9,94 pour cent. Le patching ambitieux combiné à une vérification sans direction endommage les alentours. S'y ajoute une illusion de mesure : des suites avec une couverture dans les quatre-vingt-dix peuvent obtenir des scores dans les trente et quarante sous mutation testing, car la couverture indique quelles lignes ont été exécutées, pas quels bugs sont attrapés. L'assurance de 150 à 200 tests de la vidéo reste un simple chiffre tant qu'elle n'est pas mise à l'épreuve par un score de mutation.

Le troisième angle est l'intérêt et la vérifiabilité : certains des avertissements les plus bruyants de ce domaine viennent de blogs d'entreprises qui vendent des produits de test, donc des chiffres comme « les pull requests IA portent 1,7 fois plus de problèmes » ou « 45 pour cent du code généré présente des failles de sécurité » exigent une confirmation indépendante au moment de la décision. Du côté de la vidéo, il s'agit d'un rapport d'expérience à source unique : quatre mois de pratique personnelle, pas de groupe de contrôle, aucun échec consigné. Une expérience contrôlée de vibe-coding a révélé que les flux collaboratifs produisaient des suites de tests plus soignées tandis que les flux entièrement automatisés ajoutaient des points de décision qui échappaient aux tests — et la phase « laisse-le tourner » de la vidéo se situe exactement dans cette zone de risque. Je prends le mécanisme au sérieux, pas les chiffres.

Mon verdict pratique : cette discipline est solide pour le travail greenfield avec des exigences clairement rédigées, à condition qu'un œil senior lise les tests et approuve le contrat. Sur les chemins critiques de sécurité, dans le travail réglementé, ou dans les équipes qui font passer les tests sans les lire, elle fabrique une fausse confiance — ma règle est simple : séparer le contexte qui écrit les tests de celui qui écrit le code, ne jamais injecter les tests dans la boucle sans approbation humaine, et confirmer par mutation testing que la suite mord réellement. Je suis d'accord avec la thèse de la vidéo — les tests ont gagné en valeur à l'ère de l'IA — et j'ajoute : ce qui a gagné en valeur, ce n'est pas le test lui-même, mais l'indépendance du test.

Sources

9 liens ; aucun autre article publié ne les cite. Stories sharing a link do not confirm each other; a source's origin is not inferred from how often it is cited.

intelligence artificielle · développement piloté par les tests · claude · programmation · ia générative

Suivre le sujet

Avant cet article

Un court ordre de lecture des articles antérieurs reliés à cet événement par un éditeur.

Preuves et sources

Consultez les passages autorisés, leurs versions et leur origine.

KAYNAKLARLA OKU

Bu haberi açalım.

Hesap kontrol ediliyor…