Contexte technique
Je ne suis pas ici pour discuter d'une sortie majeure, mais plutôt d'une nouvelle plus utile : le travail réel avec Opus 4.7 et Codex a une fois de plus révélé un vieux problème. Au stade de la planification, ils semblent raisonnables, mais dès que je commence à lire le diff ligne par ligne, l'intégration de l'IA dans le développement cesse soudainement de paraître sûre.
Les détails sont désagréables. Dans un cas, un modèle dans un projet avec des modèles de domaine a simplement contourné la couche de domaine, créé un nouveau dépôt et a commencé à fonctionner selon ses propres règles. Dans un autre cas, j'ai demandé d'ajouter une couche de domaine et j'ai reçu un dossier avec une interface de dépôt et un étrange objet de valeur avec un tableau, mais sans entité. Formellement, quelque chose a été fait. Architecturalement, c'est du n'importe quoi.
Et voici le point important : je n'ai aucune confirmation de sources externes que Opus 4.7 ou Codex échouent systématiquement au DDD en tant que type de tâche. Il y a de nombreuses plaintes concernant le bruit, le suivi littéral des instructions, des actions autonomes discutables et un manque de fiabilité général dans le code, mais pas sur ce modèle spécifique avec les couches de domaine. Par conséquent, je qualifierais honnêtement cela non pas d'une propriété avérée du modèle, mais d'un risque pratique récurrent que j'intégrerais dans le processus dès maintenant.
Ce qui me dérange le plus n'est pas l'erreur elle-même, mais son style. Le modèle ne dit pas : « Je n'ai pas compris l'architecture. » Il construit avec assurance une structure qui lui convient, comme si la couche de domaine, les invariants et les limites des agrégats n'étaient que des parties décoratives du projet.
Si le plan manque de contraintes solides, il improvisera. S'il y a des contraintes, il peut quand même tranquillement opter pour une voie plus simple. C'est pourquoi j'ai depuis longtemps cessé de considérer des plans et des commentaires bien rédigés comme un signal de qualité.
Impact sur l'entreprise et l'automatisation
Pour une équipe, cela signifie une chose simple : l'automatisation par IA dans le code ne peut pas être appliquée aux zones architecturalement sensibles sans garde-fous. CRUD, tests, migrations, refactoring de routine, oui. Logique de domaine, contrats, invariants, non sans contrôle manuel.
Ceux qui ont des listes de contrôle architecturales, des règles pour l'agent et des revues couche par couche sont gagnants. Les équipes qui mesurent la qualité par la vitesse de génération et le nombre de tâches terminées sont perdantes.
Je considère déjà cela comme un problème d'architecture IA, et non plus simplement comme un choix de modèle. Il faut des garde-fous dans les prompts, des linters pour les violations architecturales, des modèles de répertoires, des tests pour les limites des couches et une revue de diff obligatoire par un humain. Chez Nahornyi AI Lab, nous construisons précisément ce genre de solutions pour les clients qui ont besoin de mettre en place une automatisation par IA sans surprises en production.
Si vous constatez qu'un agent a prétendument accéléré le développement mais que le code se désorganise entre les couches, il vaut mieux s'arrêter maintenant que de payer pour une réécriture plus tard. Chez Nahornyi AI Lab, nous pouvons examiner ensemble votre flux de travail et concevoir un développement de solution IA pour que l'automatisation fasse gagner du temps au lieu de détruire le système de l'intérieur.