Partie de “Vaincre l'Entropie”

La plupart des problèmes que j'ai avec le code généré par IA sont liés à la confiance. Fais-je confiance à la personne qui a écrit ce ticket ? Fais-je confiance à l'ingénieur qui a ouvert cette PR pour avoir compris le ticket et guidé l'agent de codage pour l'implémenter correctement ? Fais-je confiance à l'implémentation de l'agent de codage ? Fais-je confiance à notre suite de tests pour détecter les régressions avant qu'elles n'atteignent la production ? Fais-je confiance à notre CI/CD pour construire, tester et déployer correctement nos changements ? Fais-je confiance à notre configuration d'observabilité pour nous alerter quand le code généré par IA casse la production ? Fais-je confiance à l'ingénieur SRE IA (Site Reliability Engineer) pour diagnostiquer correctement le problème et nous aider à l'atténuer ? Fais-je confiance à Git Hub pour ne pas avoir d'incident quand nous en avons le plus besoin ? La confiance est difficile à gagner et facile à perdre. Je pense donc qu'il est crucial de favoriser une culture de confiance au sein de l'équipe d'ingénierie. Vous devez faire confiance aux ingénieurs pour faire ce qui est juste.

Encourager la Responsabilisation

Je trouve utile de communiquer clairement quelque chose comme : « Vous êtes responsable de ce que vous livrez. Si cela casse la production et que vous avez rédigé la PR, vous devez être là pour la corriger. »

Si les ingénieurs sont tenus responsables du code qu'ils livrent, ils doivent avoir l'autonomie pour le produire avec leurs méthodes préférées. Même si vous n'êtes pas un adepte de l'IA, vous devez admettre que les agents IA génèrent beaucoup de code très vite. Le code doit encore être généré, et l'attente est qu'il est maintenant bon marché d'en générer beaucoup. Pour faire face à cela, les ingénieurs doivent être autorisés à mettre en place des mesures pour garantir que la qualité de la base de code ne se dégrade pas. Dans une organisation saine, les ingénieurs doivent se faire confiance pour ne pousser que du code de qualité raisonnable. Je dis raisonnable car il n'est pas pragmatique d'obséder sur la qualité et d'essayer de livrer toujours du code 100 % parfait. Même avant les agents de codage, la plupart du code était déjà un gâchis bogué ! Il est donc compréhensible qu'une solution « suffisante » soit livrée. Souvent, nous échangeons la vitesse de livraison contre la qualité, et contractons une dette technique.

Voici quelques pratiques que j'ai trouvées utiles pour faciliter la responsabilisation des ingénieurs dans cette nouvelle ère du codage :

Directives de Codage

Avoir une stratégie technique claire : prenez le temps de décider ce qui compte pour votre base de code et investissez dans des directives claires. Pour les humains et pour les agents de codage. Même si les humains ne lisent pas les directives, leurs agents de codage les liront et les suivront (surtout).

Outils Déterministes

Faire un usage intensif d'outils déterministes pour assurer la qualité du code. Langages typés, linters, détection de code mort, scans de sécurité, CI/CD, etc. Tous ces outils existaient avant les agents de codage et nous aident dans la lutte contre le code de mauvaise qualité. (Restez à l'écoute pour un article de suivi avec des recommandations spécifiques !)

Imposer de Petites PRs

Donner aux ingénieurs le pouvoir de rejeter les PR non révisables. Si possible, codifier ce critère pour que toute PR non révisable soit immédiatement rejetée. Bien sûr, assurez-vous de laisser de la place pour les exceptions.

Posséder les Tests

Écrire les cas de test à la main. Cela ressemble au travail d'un analyste métier. Réfléchissez profondément à la fonctionnalité et définissez des scénarios de test appropriés. Discutez-en au sein de l'équipe. Les agents de codage peuvent implémenter les tests, mais ils doivent être définis par des humains.

Goût pour le Produit

Travailler en tandem avec le produit pour avoir une vision produit cohérente. Il est très facile de devenir fou avec l'IA et d'implémenter n'importe quelle fonctionnalité qui vient à l'esprit. Assurez-vous d'implémenter uniquement des fonctionnalités utiles qui apportent réellement de la valeur aux utilisateurs !

Prototype

Code jetable. Puisque le code est très facile à générer maintenant, c'est une bonne occasion d'essayer différentes approches. Ne laissez pas l'agent de codage générer une seule solution. Par exemple, essayez trois approches radicalement différentes et choisissez celle qui s'adapte le mieux au problème et au système existant.

Se Concentrer sur le Résultat

Soyez pragmatique quant au résultat. Parfois, le code n'est pas le résultat. Le résultat est un rapport, ou un outil qui vous aide à accomplir autre chose. Pour de tels cas, la qualité du code n'est pas si pertinente tant que le résultat est utile.