Le code écrit par des agents reste relu

Hurukan est en grande partie construit par des agents. Ils écrivent le code, génèrent les tests, exécutent la suite, intègrent et soumettent la modification pour mise en production. L’écart entre le moment où l’on repère un problème et celui où il est corrigé dans un déploiement en service passe ainsi de plusieurs semaines à quelques heures, et c’est un réel avantage.

C’est aussi, dans ce domaine, l’argument le plus susceptible d’être gonflé : il vaut donc la peine d’écrire noir sur blanc où s’arrête l’automatisation, et pourquoi ces arrêts ne sont pas provisoires.

Ce qui est réellement automatisé

L’implémentation à partir d’une spécification. À partir d’une description claire de la modification et du code existant, un agent écrit une implémentation plausible plus vite qu’une personne, sans se lasser des parties fastidieuses.

La génération de tests. Y compris les cas qu’un humain fatigué oublie : la liste vide, le doublon, le fuseau horaire, l’écriture concurrente.

L’intégration et la chaîne CI/CD. Compiler, exécuter la suite de tests, vérifier les types, résoudre les conflits courants, et le faire en continu plutôt que par lots.

La maintenance ingrate. Mises à jour des dépendances, migrations liées aux dépréciations, cohérence entre chemins de code similaires. Un vrai travail, historiquement remis à plus tard, et de ceux qui font pourrir un système en silence.

Ce qui ne l’est pas

La décision de ce qu’il faut construire. Une spécification est un jugement sur une activité, pas une tâche de programmation. Les agents ne savent pas lequel de cinq défauts compte pour l’entreprise qui fera tourner le système mardi prochain.

Les choix d’architecture aux conséquences durables. Ceux avec lesquels on vit pendant des années : où passe une frontière, ce qu’affirme le modèle de données, ce qui est délibérément rendu impossible. Faciles à rater vite, coûteux à avoir ratés.

La revue. Chaque modification générée passe par une revue et par les mêmes contrôles que toute autre. Le gain de vitesse vient de contrôles plus rapides, pas moins nombreux, et quiconque propose la seconde option décrit un système qui finira par livrer quelque chose qu’il n’aurait pas dû.

La décision de mise en production. Une personne décide de ce qui parvient à une entreprise qui fonctionne sur ce système. Cela ne sera pas automatisé, non parce que c’est impossible, mais parce que la responsabilité d’une mauvaise mise en production doit reposer sur quelqu’un.

Le mode d’échec qu’il faut nommer

Le volume. Un agent produit vite une modification volumineuse et plausible, et la relire sérieusement prend autant de temps que relire n’importe quoi d’autre. Les équipes qui mesurent la vitesse de génération et non celle de la revue accumulent du code insuffisamment relu à un rythme qu’aucun processus humain ne peut absorber, et la dette arrive d’un seul coup.

La parade : les modifications générées doivent être petites, les tests réellement indépendants de l’implémentation, et la capacité de revue doit être la contrainte sur laquelle tout l’ensemble est dimensionné. Si la revue est le goulet d’étranglement, le système fonctionne correctement.

Pourquoi le dire aussi simplement

Parce qu’une usine logicielle autonome ressemble à une promesse de se passer d’ingénieurs, et ce n’en est pas une. C’est une promesse portant sur le délai entre un défaut et sa correction, et c’est quelque chose qu’un client peut mesurer.

C’est la version sur laquelle nous voulons être jugés, et elle promet moins que ce que les mots laissent entendre. Pour une entreprise à qui l’on demande de faire tourner ses opérations sur ce logiciel, une promesse plus modeste qui résiste à l’examen vaut davantage qu’une promesse plus grande qui n’y résiste pas.