Même IA, deux issues : une équipe plus rapide ou un projet mort
Tout le monde dit que l'IA accélère les développeurs. Le même agent accélère une équipe et fait presque couler un projet. Le modèle n'y était pour rien.
Tout le monde dit que l'IA rend les développeurs plus rapides. Pourquoi ne le sommes-nous pas ?
La question est légitime.
Cette année, mon équipe n'a pas écrit une seule ligne de code à la main. Ce sont les agents qui l'ont fait, au quotidien, dans des bases de code et React Native sur lesquelles des gens comptent, dans la santé et les médias numériques. Notre métier est devenu la revue : nous sommes devenus des gardiens, des baby-sitters d'agents. C'est ainsi que nous avons vu, plus d'une fois, le même agent accélérer certains projets et en mener d'autres au bord du naufrage. Le modèle était le même. La différence tenait à ce que nous lui avions fourni en premier.
Ce parcours traite des agents qui construisent votre application Angular.
Le projet qui frôle le naufrage
Quelqu'un installe un agent, ouvre le plus gros module fonctionnel et demande une modification. Deux heures et une facture de plus tard, il se retrouve avec un de bien plus de mille lignes. Ce diff touche quatre bibliothèques. Il importe un service directement dans un composant d'interface. Tous les tests sont au vert, puisque l'agent a aussi réécrit les .
Le modèle serait-il bête ? Non. Il a exécuté exactement la tâche qu'on lui a confiée (pourquoi les agents agissent ainsi). Le problème, c'était la tâche. Une consigne du type « convertis ça », sans plan, sans garde-fous et sans limite de taille, donne ce résultat dans la plupart des cas que j'ai vus. Les règles qui maintiennent en vie un vieux sont dans la tête des gens, et l'agent ne lit pas dans les pensées.
Voyons maintenant la situation du côté de la direction, car c'est de là que vient la pression. Les dirigeants entendent « l'IA écrit du code » et s'attendent désormais à un travail rapide. Sous pression, quelqu'un obtient d'un agent, en un après-midi, un écran qui fonctionne et le présente en réunion. Tout le monde voit l'écran, personne ne voit le diff qui se cache derrière. À partir de là, c'est une démo qui fixe les attentes.
Viennent ensuite les ingénieurs responsables de la base de code, qui ouvrent la . Elle est énorme, enfreint des règles que l'équipe respecte depuis des années pour de bonnes raisons, et ses tests ont été réécrits pour passer. Ils ont raison de refuser de la fusionner. Quelqu'un doit alors assumer le décalage entre ce que la direction a vu et ce que la base de code peut absorber, le plus souvent la personne qui fait le travail correctement. Rien n'a été mesuré, il n'y a donc rien à opposer. La démo a pris un après-midi, la revue plusieurs semaines, et seul l'après-midi a été présenté en réunion.
Des juniors plus rapides, des seniors plus lents : le travail n'a pas diminué, il s'est déplacé vers la revue.
Si elle est fusionnée malgré tout, la facture s'alourdit. La dette que vous avez choisie en connaissance de cause, vous savez au moins qu'elle est là. La pire, c'est le code que personne dans l'équipe ne sait expliquer quand la production tombe à deux heures du matin. C'est la . Aucun ne l'affiche, et un agent à qui l'on demande de « convertir ça » est, à ma connaissance, le moyen le plus rapide de la creuser.
La dette technique, vous l'avez choisie. La dette de compréhension vous a choisi.
L'équipe plus rapide
Même agent, même type de base de code, un autre après-midi. L'agent reçoit un court fichier de règles, une architecture qu'il ne peut pas franchir parce qu'une commande échoue dès qu'il essaie, et une tâche avec un périmètre et une limite de taille. Son premier diff reste dans les garde-fous, et le relecteur lit une décision, pas une surprise. Le junior qui lance l'agent livre du code qui respecte des frontières qu'il n'a pas encore apprises, et il les apprend grâce à l'erreur lint.
Une règle sous-tend l'ensemble, et chaque partie de ce parcours y revient : l'agent exécute un périmètre déjà décidé. Il ne le décide jamais. La suite du parcours :
- Les trois fichiers que l'agent doit lire, faire passer au vert et ne jamais quitter.
- Du ticket au fichier de tâche : l'agent rédige le périmètre, une personne tranche.
- Rétrograder, pas supprimer : le plan de migration qui tient en production.
- Figer le comportement d'abord : la première étape de ce plan, des tests sur le code .
- Ce que votre compilateur ne voit pas : le même plan quand le legacy est en .
- Que puis-je supprimer en restant au vert ? : les tests de l'agent, et la migration en chiffres.
Le restyling avec des design tokens et la sécurité ont déjà leurs exercices dans le dépôt de démonstration ; leurs parties écrites arrivent bientôt.
Le jour où l'on vous présente la démo, une seule question règle l'essentiel : voulez-vous que cela fonctionne cette année, ou que ce soit encore sûr et maintenu dans cinq ans ?
Avant de modifier quoi que ce soit, regarde comment ce dépôt est organisé : ses bibliothèques, sa configuration lint et tout fichier de règles écrit pour les agents. Ensuite, dis-moi en une courte liste quelles règles de cette base de code tu risquerais le plus d'enfreindre sur une tâche comme « migrer le module des virements vers les signals », et pourquoi. N'écris pas de code.
Les agents citent en général leurs erreurs probables si on le leur demande avant qu'ils ne commencent. Considérez cette liste comme un brouillon du fichier de règles de la partie suivante.
Dès lundi
- Quand on vous montre une démo IA, demandez le diff avant l'écran.
- À partir de maintenant, suivez un chiffre par changement : les heures de revue par pull request. La démo ne le montre jamais. La partie 7 le met en regard de la taille des diffs du dépôt de démonstration.
- Lisez la partie suivante et consacrez un après-midi aux trois fichiers.
L'application de démonstration de chaque partie est Atlas Bank, une banque marocaine fictive avec deux coins legacy en attente de migration : un écran de virement dans un NgModule et un écran de bénéficiaires en AngularJS. Jamais de code client.
Parcours 1, partie 1 de la série gratuite qui accompagne le Vite et sûr : l'IA dans votre code Angular. En salle, vous le faites sur votre propre base de code.
Vite et sûr : l'IA dans votre code Angular
Laissez des agents écrire de l'Angular sous règles, modernisez le code legacy sans casser la production, et gardez le tout sécurisé, en trois jours, sur un code à l'échelle d'une entreprise.
Voir le programme