Publié initialement sur collinwilkins.com
Celui-ci est long et constitue une suite plus détaillée à mon premier article sur le sujet.
Deux choses avant d'entrer dans le vif du sujet : premièrement, vous repartirez avec au moins une chose que vous pourrez appliquer cette semaine pour obtenir des résultats plus cohérents de votre outil de codage d'IA.
Deuxièmement, les exemples utilisent Claude Code - c'est ma pile quotidienne, pas une approbation. Chaque principe ici s'applique au curseur, au copilote ou à tout ce que vous utilisez.
Commençons par un exemple qui vous est probablement arrivé cette semaine...
Vous avez demandé à votre outil de codage d'IA d'ajouter un nouveau point de terminaison d'API. Il a généré exactement ce dont vous avez besoin : convention de dénomination, emplacement de fichier et importations corrects. Vous avez clôturé la tâche en 15 minutes.
Le lendemain matin, vous avez demandé un autre point de terminaison. Il utilisait un modèle de dénomination provenant d'un framework que vous avez abandonné il y a trois mois. Le fichier a atterri dans le mauvais répertoire. Il a importé une bibliothèque qui ne figure plus dans l'arborescence des dépendances. Vous avez passé 40 minutes à le nettoyer.
Ensuite, un coéquipier a essayé le même outil sur la même base de code. Leur résultat ne correspondait à aucun des vôtres.
Le même modèle et la même base de code ont produit trois résultats complètement différents. La variable que personne ne nomme : ce que l'IA pourrait réellement voir. Contrôler cela est une discipline et de nombreux développeurs ne le font pas.
Il y a quelques semaines, un fil de discussion HN du type "Le contexte du curseur est 10 fois meilleur que celui de Claude Code" a fait la une avec plus de 150 points et des centaines de commentaires. Les développeurs échangent des histoires de guerre sur quel outil récupère les bons fichiers, lequel hallucine les conventions du projet, lequel comprend réellement une grande base de code.
Le fil de discussion comparait les fonctionnalités de l'outil : la manière dont Cursor indexe et récupère automatiquement les fichiers par similarité sémantique par rapport à la manière dont Claude Code s'appuie sur des lectures de fichiers explicites et le routage d'instructions. Ça vaut le coup de le savoir.
Mais rien de tout cela n’explique pourquoi le même outil, la même base de code, le même développeur produisent un résultat solide mardi et un résultat non livrable jeudi. Cette lacune est l’ingénierie du contexte.
L'ingénierie contextuelle est la discipline qui consiste à contrôler les informations auxquelles un outil de codage d'IA a accès, la manière dont ces informations sont structurées et les instructions qui régissent son comportement. Cela se distingue de l'ingénierie rapide (ce que vous dites lors d'une session donnée) et de la sélection de modèle (quelle IA vous utilisez). Vous pouvez rédiger des invites parfaites et choisir le modèle le plus performant tout en obtenant des résultats incohérents si le contexte est erroné.
J'ai abordé cela plus en détail ici, cette variabilité est en fait intégrée aux modèles pour les aider à raisonner.
Les développeurs qui comprennent cela produisent un travail plus cohérent que n’importe quelle comparaison d’outils ne le prédirait. Ceux qui débattent encore de Cursor contre Claude Code optimisent la mauvaise variable.
Chaque outil de codage d'IA génère des prédictions à partir de tout ce qui se trouve dans sa fenêtre contextuelle. Ce n'est pas seulement votre dernier message. Il comprend les fichiers que l'outil a lus plus tôt dans la session, les fichiers d'instructions qu'il a chargés au démarrage, la docu...
[Courte citation de 8% de l'article original]