La démo marche toujours

Chaque démo d’AI coding suit le même arc. Quelqu’un prompte un modèle. Une application qui fonctionne se matérialise. Le public est impressionné.

Et il a raison de l’être. La vitesse est réelle. La capacité est réelle. La version un part réellement plus vite avec l’AI dans la boucle.

Le problème, c’est que la version un n’a jamais été la partie difficile.

Là où le coût se situe réellement

Le coût de l’ingénierie logicielle ne se concentre pas au moment de la création initiale. Il se concentre aux itérations quatre, cinq et six :

  • Le fournisseur d’auth doit changer parce que la tarification a évolué.
  • L’analytics doit migrer parce que le fournisseur a été racheté.
  • Il faut ajouter une fonctionnalité qui touche trois écrans que la génération initiale n’avait jamais anticipés.
  • Il faut remplacer un système de styles parce que la direction visuelle a changé.
  • Il faut échanger une intégration de paiement parce que le produit s’est étendu à un nouveau marché.

Aucune de ces situations n’est un échec de la génération initiale. Toutes relèvent du développement produit normal. La question est de savoir si la codebase rend ces changements peu coûteux ou coûteux.

La codebase générée par AI sous pression de changement

La plupart des codebases générées par AI encaissent bien le premier changement. Le deuxième est inconfortable. Au quatrième, les équipes commencent à rapporter les mêmes symptômes :

  • « On a demandé à l’AI de remplacer le fournisseur d’auth, mais elle a touché 14 fichiers. »
  • « Le refactor a cassé des tests dans des modules qui n’auraient pas dû être liés. »
  • « On n’arrive pas à savoir quelles parties du système dépendent du SDK d’analytics. »
  • « Chaque changement exige de re-comprendre toute la codebase. »

Ces symptômes ne sont pas des échecs du modèle. Ce sont des échecs d’architecture. Le modèle a généré un système sans boundaries, et maintenant chaque changement a un rayon d’impact imprévisible.

Pourquoi les codebases AI se dégradent plus vite

Les codebases traditionnelles se dégradent aussi. Mais les codebases générées par AI se dégradent plus vite pour des raisons précises :

Pas de modèle mental partagé. Une équipe humaine construit une intuition structurelle au fil des mois. Une AI génère du code sans mémoire de la raison pour laquelle les décisions précédentes ont été prises.

Optimisation pour le prompt immédiat. Les modèles résolvent la demande en cours. Ils n’optimisent pas les cinq demandes suivantes. Chaque génération prend des décisions localement correctes mais globalement incohérentes.

Le volume amplifie le couplage. L’AI génère plus de code, plus vite. Plus de code avec des boundaries faibles signifie davantage de couplage, plus vite. L’avantage de vitesse devient un accélérateur de dégradation.

Le refactor exige un contexte global. Les modèles gèrent mal les refactors qui traversent toute la codebase parce que les fenêtres de contexte sont finies et que l’intention architecturale reste implicite.

Le vrai défi d’ingénierie

Le vrai défi d’ingénierie dans le développement AI-native n’est pas « Comment générer un meilleur code ? »

C’est « Comment structurer le système pour que les parties générées par AI puissent changer indépendamment ? »

Cela demande :

  • Des boundaries qui rendent le rayon d’impact prévisible.
  • Des interfaces qui découplent ce qui change de ce qui reste.
  • Des composition roots qui rendent explicites les graphes de dépendances.
  • Des contract tests qui vérifient l’intégration sans exiger le système complet.
  • La capacité à supprimer et régénérer n’importe quel module sans déclencher de pannes en cascade.

La maintenance à long terme est un problème de structure

Aucun niveau supplémentaire de prompting ne répare une codebase dans laquelle chaque module va fouiller dans tous les autres. Vous ne pouvez pas sortir d’un couplage architectural à coups de prompts.

La maintenance à long terme d’une codebase AI exige la même discipline qu’elle a toujours exigée : des boundaries, des contracts et de l’isolation. La différence, c’est que la vitesse de l’AI rend l’absence de ces disciplines visible plus vite. Une équipe qui aurait mis deux ans à créer un monolithe impossible à maintenir peut maintenant le faire en deux mois.

La vitesse est un cadeau et un piège. Sans structure, cela veut seulement dire que vous arrivez plus tôt à la crise de maintenance.

Le lien avec l’architecture AI-native

C’est l’argument central que j’ai développé dans Stanford CS146S a raison sur l’AI coding. Le sujet manquant, c’est l’architecture : l’aisance avec les outils, sans discipline d’architecture, produit des codebases rapides à créer et coûteuses à maintenir.

Le développeur logiciel moderne a besoin des deux. Les outils AI pour livrer vite. La discipline d’architecture pour continuer à livrer vite après la version un.

La version un n’a jamais été le problème. Le problème, c’est de savoir si la version cinq reste peu coûteuse.

FAQ

Pourquoi les codebases générées par AI deviennent-elles difficiles à maintenir ?

Les modèles AI optimisent le prompt immédiat, pas les changements futurs. Cela produit du code qui fonctionne mais qui manque des boundaries nécessaires pour être modifié indépendamment. Sans contraintes d’architecture explicites, le couplage s’accumule plus vite que dans des codebases écrites à la main, parce que l’AI génère plus de code, plus vite.

Comment empêcher une codebase AI de se dégrader avec le temps ?

Trois pratiques structurelles : faire respecter les boundaries de module avec des interfaces possédées par l’application, centraliser le câblage des dépendances dans un composition root, et exécuter des contract tests qui vérifient les points d’intégration indépendamment. Ces pratiques rendent le coût du changement prévisible, quelle que soit la manière dont le code a été généré.

Le code généré par AI est-il plus difficile à refactorer que du code écrit par des humains ?

Pas par nature. Mais le code généré par AI a plus de chances de manquer des boundaries structurelles qui rendent le refactor sûr, parce que les modèles n’optimisent pas spontanément les changements futurs. La correction consiste à imposer ces boundaries avant la génération, pas à espérer que le modèle les produise tout seul.

Quel est le plus grand risque de l’AI coding pour les projets de long terme ?

Le plus grand risque, c’est le piège de la vitesse : livrer si vite dans la phase initiale que la dette d’architecture s’accumule avant même que l’équipe ne s’en rende compte. Au moment où la maintenance devient coûteuse, la codebase est trop couplée pour être réparée de façon incrémentale.