- À mesure que les agents IA occupent une place centrale dans l’écriture du code, des bonnes pratiques autrefois « facultatives » comme les tests, la documentation et le typage statique deviennent désormais indispensables
- Une couverture de code à 100 % est exigée, afin que chaque ligne de code soit réellement vérifiée et étayée par des exemples d’exécution
- Une structure de répertoires et un nommage de fichiers clairs facilitent l’exploration de la base de code par les LLM, et favorisent une organisation en petits fichiers
- Des environnements de développement rapides, éphémères et exécutables en parallèle permettent à plusieurs agents de travailler simultanément
- Le maintien d’un écosystème de code fiable pour l’IA repose sur un système de types statiques et des outils automatisés de contrôle qualité
IA et nécessité du « bon code »
- Depuis longtemps, les développeurs considèrent les tests, la documentation, les petits modules et le typage statique comme des critères de bon code, mais dans la pratique ils sont souvent omis
- Or, les agents IA ne sont pas très bons pour remettre eux-mêmes le code en ordre, ce qui rend ces bonnes pratiques indispensables
- Pour empêcher un agent de partir dans la mauvaise direction, il est essentiel de mettre en place des garde-fous clairs et appliqués de façon stricte
- Avec des garde-fous solides, les LLM convergent uniquement vers la bonne trajectoire ; dans un environnement incomplet, ils amplifient les problèmes
Couverture de code à 100 %
- L’équipe impose une couverture de code à 100 %, non seulement pour éviter les bugs, mais surtout pour vérifier le comportement de tout le code écrit par les agents
- Avec 95 % ou 99,99 % de couverture, l’origine du code non testé reste floue, tandis qu’à 100 %, chaque ligne non validée peut être identifiée clairement
- Le rapport de couverture sert de liste des éléments à tester, et le LLM doit impérativement fournir un exemple exécutable lors d’une modification du code
- Cette approche a aussi des effets bénéfiques annexes : suppression du code inatteignable, explicitation des cas limites, amélioration de l’efficacité des revues de code
Espaces de noms et structure des fichiers
- Les agents explorent la base de code via le système de fichiers, si bien que la structure des répertoires et les noms de fichiers jouent un rôle d’interface essentiel
- Un chemin clair comme ./billing/invoices/compute.ts transmet bien plus d’informations que ./utils/helpers.ts
- Il faut privilégier des fichiers petits et bien délimités, afin que le LLM puisse charger l’intégralité du fichier dans son contexte et ainsi éviter une baisse de performance
- Cette structuration permet d’améliorer la vitesse d’exploration et la précision des agents
Des environnements de développement rapides, éphémères et parallélisables
- Au lieu d’un environnement de développement unique, le développement basé sur des agents évolue vers une gestion parallèle de plusieurs processus
- Fast : les procédures de test et de validation doivent s’exécuter rapidement ; l’équipe a optimisé plus de 10 000 assertions pour qu’elles soient terminées en moins d’une minute
- La vitesse est obtenue grâce à une parallélisation poussée, une forte isolation et une couche de cache pour les appels tiers
- Ephemeral : la commande
new-feature <name> permet de créer un nouvel environnement en 1 à 2 secondes, avec configuration automatique et lancement de l’agent
- Si une configuration manuelle est nécessaire, la fréquence d’usage chute fortement ; l’automatisation complète est donc essentielle
- Concurrent : pour exécuter simultanément plusieurs environnements de développement, il faut éviter les conflits liés aux ports, à la base de données, au cache, etc.
- Isolation via Docker ou via une configuration fondée sur des variables d’environnement
Système de types de bout en bout et contrôle qualité automatisé
- Il faut automatiser autant de bonnes pratiques que possible afin de réduire la marge de liberté du LLM et de maintenir une qualité constante
- Configurer des linters et formatters automatiques de manière stricte, afin que des corrections automatiques soient appliquées chaque fois que le LLM termine une tâche
- Il est recommandé d’utiliser un langage à typage statique, en s’appuyant notamment sur TypeScript et son système de types puissant
- Des noms de types porteurs de sens comme
UserId, WorkspaceSlug, SignedWebhookPayload rendent l’intention du code plus explicite
- OpenAPI permet de maintenir la cohérence des types entre le frontend et le backend
- Le système de types et les triggers de Postgres garantissent l’intégrité des données, tandis que Kysely génère un client type-safe
- Tous les clients tiers doivent eux aussi disposer de définitions de types précises, ou être utilisés via des wrappers
Conclusion : redéfinir la qualité du code à l’ère de l’IA
- Les agents sont des codeurs infatigables et performants, mais leur niveau dépend de la qualité de l’environnement
- Le « bon code » n’est plus un choix, mais une condition préalable au bon fonctionnement de l’IA
- La mise en place initiale peut sembler lourde, mais il s’agit d’un investissement indispensable longtemps repoussé
- Avec le soutien du leadership technique, il faut viser la construction d’une base de code adaptée à l’IA
Aucun commentaire pour le moment.