J'ai refactorisé 100 fonctions avec Claude. CI était vert. La production a ralenti à 7 endroits.

DEV - 28/05
Claude a refactorisé 100 fonctions dans mon service Python. CI était vert. Les tests de mutation étaient au vert. Deux semaines plus tard, un appel de garde m'a bipé : 7 fonctions étaient plus lentes en production. Voici ce qu’ils avaient en commun et les quatre contrôles que j’effectue actuellement.

J'ai demandé à Claude Code de refactoriser 100 fonctions sur un service Python que je possédais. Il a fait le travail en deux passes. CI était vert sur les deux. La description du PR était si soignée que je me sentais presque mal de l'expédier un vendredi.

Deux semaines plus tard, un appel m'a appelé car le p95 d'un point final avait dérivé de 180 ms à 240 ms. J'ai commencé à diviser en deux. La bissectrice a atterri sur le refactor PR. J'ai commencé à lire le refactor PR. Sept des 100 fonctions ont été plus lentes à produire. CI ne l'a jamais remarqué car CI ne mesure pas « plus lentement ». Il mesure "renvoie la même valeur".

Cet article explique ce que ces sept fonctions lentes avaient en commun, pourquoi les tests de mutation et les tests unitaires les ont tous deux manqués, et les quatre vérifications que j'effectue maintenant avant de laisser Claude, ou n'importe quelle IA, refactoriser tout ce qui est livré sous charge.

La configuration, pour que vous puissiez savoir si cela se généralise

La base de code : un service Python 3.12 avec environ 18 000 lignes de logique métier, FastAPI en périphérie, asyncpg vers Postgres, un cache Redis et un module de notation lié au processeur qui s'exécute à chaque requête. Les 100 fonctions constituaient un lot organisé : petit à moyen, pur si possible, le tout avec des tests unitaires. J'ai demandé à Claude Code d'appliquer un ensemble standard de nettoyages : retours anticipés, variables extraites pour les nombres magiques, compréhensions où les boucles faisaient une chos...
[Courte citation de 8% de l'article original]