Deep Modules : le Claude Code Skill qui sauve ma codebase

Deep Modules : le Claude Code Skill qui sauve ma codebase

J'ai exécuté la skill improve-codebase-architecture sur un projet auquel je participe depuis novembre. Sonnet 4.6 a passé onze minutes à lire mon code, a ouvert un rapport de démarque dans mon éditeur et a répertorié six choses qui, selon lui, pourrissaient tranquillement sous moi.

Le premier que j'ai renvoyé. Le deuxième avec lequel je me suis disputé. Le troisième m'a fait grimacer, me diriger vers la cuisine, me verser du café dont je ne voulais pas et revenir le relire.

Il avait trouvé deux implémentations parallèles du même concept – une dans mon frontend, une dans mon backend – situées dans des dossiers entièrement différents, appartenant à des modèles mentaux entièrement différents, sans aucun lien unifié entre eux. Ils dérivaient. J'avais expédié un bug trois semaines plus tôt dont la cause profonde était exactement cette dérive. Je n'avais pas relié les deux événements. La skill les reliait dans un paragraphe.

C'est à ce moment-là que j'ai arrêté de traiter cette skill comme un autre dépôt GitHub et j'ai commencé à la traiter comme la seule chose qui se dresse entre moi et la base de code vers laquelle je me dirige si je continue à expédier à la vitesse AI sans pression architecturale.

Si vous avez codé en ambiance dans Claude Code jusqu'au premier trimestre 2026 et que votre base de code commence à paraître plus lourde qu'elle ne le devrait – lente à naviguer, effrayante à refactoriser, pleine de petits modules qui semblent tous dépendre les uns des autres d'une manière que vous ne pouvez pas dessiner sur un tableau blanc – cet article est pour vous. Les 4 000 mots suivants expliquent pourquoi cela se produit, ce que John Ousterhout a découvert il y a vingt ans qui rend le problème réparable et comment la skill improve-codebase-architecture de Matt Pocock opérationnalise le correctif dans Claude Code.

Le vrai coût du shipping rapide avec AI

Voici ce que personne ne met sur les pages de marketing de codage AI.

La raison pour laquelle Claude Code semble magique à la deuxième semaine et lourd au quatrième mois n'est pas que le modèle s'aggrave. C'est que votre base de code se détériore, plus vite que votre cerveau ne peut la modéliser. Le logiciel a toujours eu cette propriété – Ousterhout a construit un livre entier autour de cela, A Philosophy of Software Design, sur lequel je reviendrai dans une seconde. Mais le taux a changé. AI n'écrit pas en moyenne du code meilleur ou pire que moi. Il écrit du code cinq à dix fois plus vite que moi. Chaque raccourci architectural que je prends prend quinze minutes au lieu de deux jours, ce qui signifie que l'entropie se compose d'un calendrier sur lequel mon jugement n'a jamais été formé.

Le nom technique de ce qui se passe est l'entropie logicielle. Le nom en forme de code est « boule de boue ». Le sentiment, si vous l'avez vécu, est le moment où vous ouvrez un fichier et réalisez que vous ne savez plus qui appelle cette fonction, ce qu'elle renvoie lorsque l'entrée est mal formée, ou si sa modification interrompra la suite de tests ou la production ou les deux.

J'ai ressenti ce sentiment sur le projet que j'ai mentionné ci-dessus. Non pas parce que le code était mauvais – la plupart avaient été révisés, la plupart avaient des tests, la plupart étaient exécutés en production pour des utilisateurs payants. Le problème était plus fin que le « mauvais code ». Le problème était que j’avais trente modules là où j’en avais besoin de douze. Les concepts qui allaient ensemble avaient été répartis dans les fichiers car au moment où j'écrivais chaque morceau, la séparation me semblait plus propre. Le coût cognitif total de ces scissions était désormais supérieur au coût cognitif de la duplication qu’elles évitaient.

C'est ce que AI accélère. La décision de diviser, d'extraire et d'abstraire est peu coûteuse lorsqu'un agent peut le faire en vingt secondes. La décision est si bon marché que je la prends sans réfléchir. Le résultat est une base de code en forme de fractale de petits modules polis et corrects individuellement, sans centre.

Ousterhout a un mot pour désigner cette forme. Il appelle cela superficiel. Le correctif a également un nom : deep modules. La skill que je vais vous présenter est le premier outil que j'ai utilisé qui opérationnalise le correctif sans m'obliger à relire trois cents pages d'un livre de conception de logiciels tous les vendredis après-midi.

Deep Modules vs Shallow Modules — En anglais simple

Avant de passer en revue la skill, vous avez besoin du vocabulaire. Une fois que vous l'avez, le résultat de la skill se lit comme en anglais. Sans cela, le rapport ressemble à une liste de courses de refactorisation.

Un module est une unité de votre application avec une limite claire. Dans une application React, un module peut être un composant. Dans un service Node, il peut s'agir d'une fonction, d'une classe ou d'un dossier. Ce qui en fait un module n'est pas sa taille, c'est qu'il y a un extérieur et un intérieur, et l'intérieur est caché.

L'interface est ce que quelqu'un doit apprendre pour utiliser le module de l'extérieur. Signatures de fonctions. Accessoires de composants. Méthodes publiques. Documentation. Tapez les définitions. Tout ce qu'un appelant doit charger dans sa tête pour que le module fasse son travail.

La implémentation correspond à tout ce qui se trouve à l'intérieur des limites et que l'appelant n'a pas besoin de connaître. Boucles, assistants, machines à états, requêtes de base de données, tentatives — le travail réel.

Maintenant, la partie qui compte.

Un module profond a une petite interface et une implémentation complexe. Vous en apprenez dix choses et il fait mille choses pour vous. Le ratio de levier – comportement accessible par unité d’interface apprise – est élevé. L'exemple classique d'Ousterhout est le système de fichiers Unix appelé read(fd, buf, n). Trois arguments. Des décennies de complexité du système d’exploitation se cachent derrière cela. Vous ne pensez pas à la géométrie du disque, aux caches de pages ou à l'allocation de blocs. Vous demandez n octets. Vous obtenez n octets.

Un module peu profond a une interface à peu près aussi complexe que l'implémentation qu'elle cache. Vous en apprenez dix choses, et il fait onze choses pour vous. Ou, dans le pire des cas, vous apprenez dix choses à son sujet et il en fait huit pour vous, car l'interface fuit plus que ce que contient l'implémentation. Le ratio de levier est proche de un. Le module paie à peine son loyer.

Voici une paire concrète. Restez avec moi, c'est le moment où le vocabulaire arrive.

// SHALLOW: this module's interface is bigger than what it hides
export class UserAuthHelper {
  hashPassword(password: string, salt: string): Promise<string>;
  generateSalt(): string;
  verifyPasswordAgainstHash(password: string, hash: string, salt: string): Promise<boolean>;
  isPasswordStrongEnough(password: string): boolean;
  getMinimumPasswordLength(): number;
  getMaximumPasswordLength(): number;
  generateSessionToken(userId: string): string;
  validateSessionToken(token: string): { userId: string } | null;
  revokeSessionToken(token: string): Promise<void>;
}

Vous lisez cela et vous le ressentez déjà. Pour utiliser cette chose, je dois connaître les sels, les hachages, les jetons de session, les règles de mot de passe et la révocation, qui sont tous des détails d'implémentation de l'authentification. L'interface fait fuir l'intérieur du module dans le cerveau de chaque appelant.

Maintenant la version profonde de la même chose.

// DEEP: small interface, the complexity is locked inside
export class Auth {
  signIn(email: string, password: string): Promise<Session>;
  signOut(session: Session): Promise<void>;
  currentUser(session: Session): Promise<User | null>;
}

Trois méthodes. Sels, hachages, génération de session, règles de mot de passe, révocation, expiration, jetons d'actualisation — tout cela réside dans signIn, signOut et currentUser. L’appelant n’a pas besoin de savoir quoi que ce soit. Si je souhaite migrer de bcrypt vers argon2 le mois prochain, aucun changement d'appelant. Si je souhaite ajouter une authentification multifacteur, l'interface reste la même : signIn s'enrichit simplement derrière la couture.

C'est le mouvement recherché par la skill. Chaque opportunité d’approfondissement est, à la base, une opportunité de prendre la deuxième forme et de dissimuler la première.

Il y a encore un morceau de vocabulaire dont vous avez besoin avant d'aller plus loin.

La localité correspond à la manière dont les fonctionnalités associées sont regroupées dans la base de code. Une localité élevée signifie que les choses qui changent ensemble vivent les unes à côté des autres. Une faible localité signifie que la modification d'une fonctionnalité nécessite la modification de fichiers dans trois dossiers qui ne se connaissent même pas. Le UserAuthHelper peu profond ci-dessus a une localité moyenne – au moins c'est une classe. Le bogue que j'ai trouvé dans mon projet avait une localité faible - la logique en forme d'authentification était dupliquée dans apps/web/src/lib/session.ts et services/api/src/auth/session.go, sans types partagés ni contrat appliqué entre eux.

L'approfondissement améliore généralement automatiquement la localité. Lorsque vous réduisez trois shallow modules en un seul module profond, le code associé se déplace dans le même fichier, ce qui signifie que la prochaine personne qui le modifiera (probablement dans mon futur, à 23 heures, dans deux mois) pourra tout voir en même temps.

Ce que fait réellement la skill

La skill improve-codebase-architecture, écrite par Matt Pocock et fournie dans le cadre de son [dépôt de skills] open source (https://github.com/mattpocock/skills), est un petit ensemble de démarques qui remodèle la façon dont Claude Code lit votre référentiel. Vous l'installez comme n'importe quelle autre skill - déposez-la dans ~/.claude/skills/ ou utilisez la commande d'installation de README - et à partir de là, lorsque vous demandez à Claude Code de rechercher des opportunités de refactoring, il le fait à travers l'objectif d'Ousterhout au lieu de l'heuristique générique "d'odeur de code".

Mécaniquement, la skill fait trois choses.

Tout d’abord, il analyse le dépôt avec une question spécifique à l’esprit : où sont regroupés les shallow modules ? Il ne recherche pas de fichiers défectueux individuels. Il recherche des groupes de petits modules étroitement couplés, où chacun a une interface presque aussi complexe que son implémentation, et où vous pouvez ressentir la friction du déplacement entre eux lorsque vous lisez le code.

Deuxièmement, il produit une liste d'opportunités d'approfondissement - généralement entre trois et dix, d'après mon expérience - chacune écrite sous la forme d'une courte proposition : quels modules fusionner, à quoi devrait ressembler la nouvelle interface, où se situerait la couture de test et quels risques comporte le refactor. La proposition est destinée à être lue par un humain, argumentée et acceptée, modifiée ou rejetée.

Troisièmement, lorsque vous acceptez une proposition, la skill entre dans une phase de conception interactive. Claude propose la nouvelle interface, vous repoussez les noms et les formes, le modèle est révisé, et une fois l'interface réglée, il propose une stratégie d'implémentation. La stratégie comprend comment migrer les appelants et où placer la limite de test. Lorsque vous donnez le feu vert, la skill dépose un problème GitHub (ou tout autre outil de suivi des problèmes que vous avez connecté) afin que le travail soit suivi même si vous ne le faites pas ce jour-là.

Les deux choses que je veux souligner. La skill ne refactorise pas votre code par elle-même. Il fait apparaître des opportunités et vous aide à réfléchir. Les humains font tous les appels architecturaux. Et la skill est opiniâtre – elle préfère spécifiquement des modules moins nombreux et plus profonds à des modules plus nombreux et plus petits. Si votre équipe a une forte préférence culturelle dans l’autre sens, vous la combattrez.

Le jour où je l'ai exécuté sur mon propre dépôt

Le dépôt sur lequel j'ai testé était un tableau de bord SaaS que j'expédie chaque semaine depuis novembre. Environ 1 500 commits, principalement de ma part, parfois programmés en paire avec Claude Code. TypeScript sur toute la stack, React Router sur le frontend, un service Node à l'arrière, une base de données Postgres en dessous. De vrais utilisateurs. De vrais bugs. Un réel coût cognitif à chaque fois que je l’ouvre.

J'ai nettoyé un dimanche matin, préparé du café et exécuté une invite :

Utilisez la skill improve-codebase-architecture. Scannez ce dépôt et produisez une liste d’opportunités d’approfondissement, classées par impact.

Onze minutes. Six opportunités.

Je vais en parcourir trois, car les trois autres étaient des variations sur les mêmes motifs et vous en obtiendrez la forme.

Opportunité 1 : Le concept de session dupliquée. C'est celui qui m'a fait poser le café. La skill a signalé que apps/web/src/lib/session.ts et services/api/src/middleware/session.go implémentaient tous deux ce qui ressemblait, sémantiquement, au même module : lire la session, la valider, l'actualiser si elle a expiré, renvoyer null si elle n'est pas valide. Ils en avaient différents types. Dénomination différente. Différentes sémantiques d’erreur. Le frontend traitait silencieusement les sessions expirées comme une « déconnexion de l'utilisateur ». Le backend a renvoyé un 401. Il n'y avait pas de contrat partagé entre eux, ce qui signifiait que toute dérive entre les deux se manifesterait par un bug UX. La proposition de la skill : définir un seul module Session avec une interface (saisie dans le schéma partagé), une machine à états canonique (exprimée dans OpenAPI plus un client généré) et un adaptateur de chaque côté qui implémente l'interface dans l'environnement local.

Deux adaptateurs, une interface. Une vraie couture. J'avais expédié un bug lié à la session trois semaines plus tôt. La skill ne le savait pas. La skill a vu l'architecture et a prédit la forme du bug à partir de l'architecture seule.

Opportunity 2: The fragmented logger. I had four logging utilities. Un wrapper console.log dans le frontend. Une configuration pino dans le backend. Un assistant « d'événement structuré » pour l'analyse. Un assistant "télémétrie" pour le traçage. Each one had been added, separately, in response to a real need. Chacun avait l'air propre isolément. Ensemble, ils signifiaient que lorsque je voulais déboguer le flux d'un utilisateur spécifique à travers la stack, je devais lire quatre ensembles de journaux dans quatre formats différents. The skill's proposal: a single Observability module with one interface — event(name, payload), error(err, context), span(name, fn) — and four adapters that fan out to the existing transports. Mêmes sites d'appels. Mêmes sorties. One interface for me to learn, four implementations behind it. This was a pure deepening — no functionality lost, callers' lives meaningfully simplified.

Opportunité 3 : celle avec laquelle j'ai discuté. La skill a signalé mes assistants de validation de formulaire comme une opportunité d'approfondissement. J'avais validateEmail, validatePhone, validateRequired et une demi-douzaine d'autres, chacun étant une petite fonction pure. La proposition : regroupez-les en un seul module Validator avec un API fluide. J'ai repoussé. Les fonctions pures sont généralement plus profondes qu'elles ne le paraissent : validateEmail(email) a une petite interface et une implémentation non triviale (la RFC 5322 n'est pas conviviale), et le ratio de levier est correct. Le contre-argument de la skill concernait la localité : les validateurs étaient utilisés ensemble, en clusters, sur chaque formulaire, et le code environnant devait importer six fonctions différentes au lieu d'une.

Après dix minutes d'échanges dans le chat, j'ai admis que l'argument de localité était réel, mais j'ai proposé un compromis : conserver les fonctions pures, ajouter un module Form avec un API fluide qui les compose. La skill a accepté, a rédigé la nouvelle forme et a déposé le problème. C'est à ce moment-là que j'ai fait confiance à cette chose.

Les trois autres opportunités impliquaient un module d'état de routeur qui avait développé une machine d'état à l'intérieur, une intégration de paiement qui divulguait les détails du webhook dans le code de l'interface utilisateur et un système d'indicateur de fonctionnalité qui s'était discrètement transformé en trois systèmes d'indicateur de fonctionnalité indépendants. Tous les trois ont reçu des propositions. J'en ai accepté deux ; celui que j’ai reporté au trimestre suivant.

Coutures et adaptateurs – Pourquoi l'approfondissement rend les tests possibles

Voici la partie de la skill qui se connecte directement à la question de savoir si votre base de code est testable, et la raison pour laquelle tout cela compte plus que simplement « le code est plus joli ».

Une couture est une limite dans votre code où vous pouvez remplacer un faux par un vrai sans changer le code environnant. Michael Feathers l'appelait ainsi dans Working Effectively With Legacy Code — il y a vingt ans, mais cela n'a jamais été aussi pertinent qu'en 2026. L'interface d'un module est sa couture naturelle. Si le module a une interface petite et propre, vous pouvez mettre un faux de l'autre côté de cette interface pour les tests. Si le module a une interface tentaculaire et peu étanche, chaque test doit prétendre être la réalité de douze manières différentes, et vous arrêtez d'écrire des tests parce qu'ils font mal.

Un adaptateur est l'implémentation concrète qui se trouve de l'autre côté de la couture. Le vrai parle au vrai : Postgres, le réseau, l’horloge système. Le faux renvoie ce que vous voulez pour le test.

L’exemple le plus clair, et celui que j’utilise maintenant pour enseigner cela à mon équipe, est l’horloge système.

// The interface — a one-method module
interface Clock {
  now(): Date;
}

// The real adapter
class SystemClock implements Clock {
  now() { return new Date(); }
}

// The fake adapter, for tests
class FakeClock implements Clock {
  constructor(private current: Date) {}
  now() { return this.current; }
  advance(ms: number) {
    this.current = new Date(this.current.getTime() + ms);
  }
}

Désormais, tout code qui dépend du temps dépend de Clock, et non de Date.now(). En production, il obtient la véritable horloge. Lors des tests, j'obtiens une fausse horloge que je peux avancer d'une heure, d'un jour, d'un an. Tous les tests que j'ai écrits et qui dépendaient du temps étaient instables. Chaque test que j'ai écrit depuis que j'ai extrait l'horloge dans un module profond avec deux adaptateurs est déterministe.

La skill adore ce genre de refactor. Lorsqu'il analyse un dépôt, la question qu'il pose à chaque module est : où irait la couture de test ? Si la réponse est "nulle part évidente : le module communique directement avec la base de données et le réseau, ainsi qu'avec l'horloge et le système de fichiers simultanément", c'est une opportunité d'approfondissement. Le correctif consiste à extraire les dépendances dans des modules avec leurs propres interfaces, puis à placer des adaptateurs de chaque côté. Soudain, chaque épreuve douloureuse devient facile.

C’est la partie qui s’amortit le plus rapidement. Le premier approfondissement que j'ai fait à partir du rapport de skill - le module de session - m'a permis d'économiser un après-midi complet la semaine suivante lorsque j'avais besoin de tester un cas limite d'expiration de session. Avant le refactor, j'aurais créé une base de données de test, me serais moqué d'un appel HTTP et prié. Après le refactor, j'ai instancié un faux adaptateur de session, défini son expiration il y a 30 secondes et exécuté une assertion.

Le piège Legacy-Codebase (et comment l'éviter)

Maintenant l'avertissement, car j'ai failli commettre cette erreur.

Si vous exécutez cette skill sur une base de code existante (avec une couverture de test inégale, une faible localité et shallow modules partout), le premier réflexe est d'examiner le rapport de haut en bas. Saisissez la plus grande opportunité d'approfondissement, refactorisez de manière agressive, expédiez.

Ne le faites pas.

La raison pour laquelle chaque ingénieur senior avec des cicatrices sur les mains a le même conseil — ne refactorisez pas le code non testé — est que shallow modules sans tests sont exactement les modules où l'approfondissement brisera des choses dont vous ignoriez l'existence. Les appelants dépendent d’un comportement sans papiers. Les cas extrêmes se cachent dans les fissures entre les modules. La forme des bugs est exactement ce qui a rendu les modules peu profonds en premier lieu.

Le bon geste est celui qui n’est pas glamour. Avant d'approfondir, écrivez des tests de caractérisation autour du module superficiel existant. Pas de tests unitaires. Des tests pas parfaits. Juste des tests qui identifient le comportement actuel – y compris le comportement bogué – de sorte que lorsque vous approfondissez, vous ayez un moyen de savoir ce qui a changé. Le livre de Feathers est ici la référence canonique. La skill elle-même, dans son README, recommande à peu près le même flux de travail pour le code existant : écrivez des tests qui documentent le comportement actuel du cluster que vous êtes sur le point d'approfondir, exécutez la proposition d'approfondissement de la skill par rapport à ces tests et utilisez les deltas de test comme fonction de forçage pour les décisions de conception.

Je suis maintenant cette règle même sur le code greenfield. Si une proposition d'approfondissement touche un module qui n'a pas de tests, le premier commit dans le refactor est le commit de test. L’engagement d’approfondissement vient en deuxième position. Cela me ralentit d'environ vingt minutes par refactor et m'évite les sessions de débogage « attendez, pourquoi le tableau de bord est-il vide maintenant » une heure plus tard. Commerce que je prendrai à chaque fois.

À quelle fréquence je l'exécute maintenant (et où il trébuche)

J'exécute la skill tous les lundis matin sur mon projet principal et environ tous les cinq jours ouvrables sur des projets parallèles à vitesse de validation élevée. Cette cadence est née d'une observation simple : sur un projet que j'expédie quotidiennement avec Claude Code, l'entropie s'accumule suffisamment rapidement pour qu'un examen architectural hebdomadaire la détecte avant qu'elle ne se fige. Sur un projet globalement stable, une mensualité convient.

Le conseil de cadence de la documentation de la skill est "tous les quelques jours dans des bases de code à évolution rapide" et cela correspond à mon expérience. Si je le laisse passer pendant deux ou trois semaines, le rapport passe de six opportunités à quinze, et à quinze ans, je suis las de prendre des décisions et je commence à ignorer complètement le rapport. Six est le bon chiffre sur lequel agir.

Passons maintenant à la partie honnête : là où la skill trébuche.

C'est mauvais pour les idiomes spécifiques à une langue. Lorsque je l'ai exécuté sur un service Go, il n'arrêtait pas de proposer des conceptions en forme de classe qui ne correspondaient pas au grain de Go. Le vocabulaire des modules, des interfaces et des adaptateurs se traduit, mais la forme des propositions est orientée vers TypeScript et Python. Si vous parlez une langue avec une opinion bien arrêtée – Go, Rust, Elixir – vous passerez les cinq premières minutes de chaque proposition à traduire l’idiome.

Il ne tient pas non plus compte du coût d’exécution. Chaque proposition que j'ai reçue concernait le coût cognitif - la facilité de compréhension du code, la testabilité de la couture - et aucune d'entre elles n'a pris en compte des éléments tels que la disposition de la mémoire, les modèles d'allocation ou les performances du hot-path. Pour la plupart des codes d'application, c'est très bien. Pour tout ce qui est sensible aux performances, vous devez ajouter votre propre jugement.

Et troisième bémol : il propose parfois des approfondissements qui nécessiteraient de réécrire la suite de tests pour valider. La proposition semble belle isolément, mais le coût de la migration — y compris les tests qui dépendent de la forme actuelle — est supérieur à la valeur de la nouvelle forme. La skill ne modélise pas très bien le coût de la migration. Je lis maintenant chaque proposition avec une question en haut : à quoi ressemble la migration et le coût de la migration est-il inférieur à l'effet de levier que j'obtiendrais ? La moitié du temps, la réponse est oui. L’autre moitié, je clôture le sujet.

Si vous avez utilisé les anciennes skills comme l'installation Karpathy CLAUDE.md ou l'un des 32 hacks quotidiens Claude Code que j'ai écrit le mois dernier, cette skill se place clairement au-dessus d'elles. Les hacks accélèrent l’expédition de Claude Code. La skill en architecture est la pression architecturale qui empêche la vitesse de pourrir votre base de code.

La question que je porte avec moi maintenant

Six semaines après avoir commencé à exécuter cette skill chaque semaine, ma base de code est très différente de celle où elle se trouvait. Pas considérablement plus petit – je n’ai pas supprimé beaucoup de code – mais nettement plus navigable. Le module de session est un seul endroit. Le module d'observabilité est un seul endroit. La composition du formulaire comporte une seule porte d’entrée. Lorsque j'ouvre un fichier à 23 heures pour déboguer quelque chose, je peux généralement voir l'ensemble du concept à partir du fichier dans lequel je me trouve, au lieu de rebondir entre quatre fichiers et de reconstruire l'architecture à partir de la mémoire.

Le changement qui compte le plus est celui en amont de la base de code. Lorsque j'invite Claude Code à proposer une nouvelle fonctionnalité maintenant, je pense d'abord aux modules. Où sera la couture ? Quelle est l'interface ? À quoi ressemble la version profonde de ceci ? La skill m'a appris à poser ces questions avant d'écrire l'invite, ce qui signifie que les invites elles-mêmes produisent un code déjà plus proche de ce que proposerait la prochaine analyse de la skill.

L'entropie logicielle est une flèche à sens unique sans pression architecturale. AI vient d'accélérer le déplacement de la flèche. Le correctif n'est pas plus lent AI. La solution consiste à augmenter la pression, appliquée plus tôt, par quelque chose qui évolue avec le tarif d'expédition. La skill improve-codebase-architecture est la chose la plus proche que j'ai trouvée de cette pression, et c'est le seul outil de révision architecturale de mon flux de travail qui a survécu au-delà du premier mois.

Si vous retenez une chose de cet article, répondez à la question que je pose désormais dans chaque session Claude Code : ce module est-il plus profond ou moins profond que ce qu'il remplace ? Posez-le avant d'écrire l'invite. Demandez-le à nouveau lorsque vous lirez la différence. Demandez-le le lundi matin, avec un café, pendant qu'un petit fichier de démarque analyse votre dépôt et vous indique les choses que vous saviez déjà à moitié mais que vous étiez trop fatigué pour y faire face.

Cette question fait plus pour mon code que n'importe quelle skill, framework ou outil de refactoring que j'ai installé au cours des deux dernières années. La base de code vers laquelle vous expédiez en 2027 sera la base de code que la question a construite – ou celle qui n'a pas été créée.

Ouvrez le rapport. Lisez les six choses. Choisissez-en un.

Questions fréquemment posées

Qu'est-ce que la skill improve-codebase-architecture dans Claude Code ?

Il s'agit d'une skill open source de Matt Pocock qui analyse un référentiel pour shallow modules et propose des refactors approfondis. Il s'exécute dans Claude Code, produit une liste d'opportunités d'architecture et vous aide à concevoir de manière interactive les nouvelles interfaces. Pour une présentation complète de ce qu'il a trouvé sur mon dépôt, voir « Le jour où je l'ai exécuté sur mon propre dépôt » ci-dessus.

Qu'est-ce qu'un module approfondi en conception de logiciels ?

Un module approfondi est un module doté d'une interface simple et d'une implémentation complexe, de sorte qu'un appelant apprend très peu de choses sur le module mais obtient beaucoup de comportement en retour. Le terme vient de A Philosophy of Software Design de John Ousterhout. Les modules peu profonds, en revanche, ont des interfaces presque aussi complexes que leurs implémentations et offrent un faible effet de levier.

À quelle fréquence dois-je exécuter la skill d'architecture de base de code ?

Tous les quelques jours sur des bases de code à évolution rapide avec des validations quotidiennes assistées par AI, et hebdomadairement à mensuellement sur des dépôts plus stables. Après trois semaines de silence, le rapport compte plus d'une dizaine d'opportunités et la fatigue décisionnelle s'installe. Six opportunités par semaine constituent le point idéal pour donner suite aux propositions.

La skill refactorise-t-elle automatiquement le code ?

Non, et c'est délibéré. Il fait apparaître des opportunités croissantes et vous aide à concevoir la nouvelle interface et la nouvelle couture, mais les humains effectuent chaque appel architectural et approuvent chaque changement. Une fois que vous avez accepté une proposition, il peut déposer un problème GitHub pour suivre le refactor.

Dois-je approfondir les modules dans une base de code existante sans tests ?

Pas directement. Écrivez d'abord des tests de caractérisation autour du cluster peu profond pour identifier le comportement existant, puis approfondissez-les avec les tests comme filet de sécurité. L'approfondissement de shallow modules non testé est l'un des moyens les plus rapides d'expédier une régression.

Travaillons ensemble

Vous cherchez à créer des systèmes AI, à automatiser les flux de travail ou à faire évoluer votre infrastructure technologique ? J'aimerais aider.

• Fiverr (versions et intégrations personnalisées) : fiverr.com/s/EgxYmWD
• Portefeuille : mejba.me
• Ramlit Limited (solutions d'entreprise) : ramlit.com
• ColorPark (conception et image de marque) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io