Anthropic a réduit la formation technique des nouveaux employés de 3 semaines à 2 jours grâce à une meilleure ingénierie du contexte, pas grâce à des personnes plus intelligentes.
Boris Cherny (responsable de Claude Code) a rendu publique aujourd’hui la méthode de travail que son équipe utilise au quotidien. J’ai fait une vérification en la comparant à mon propre système de quantification, et j’ai découvert une faille importante.
━━━ La plus précieuse ━━━
Le premier jour sur un nouveau projet, ne coder aucune ligne, fermement.
D’abord, faire travailler l’IA à la traduction de l’historique Git pour comprendre pourquoi ce code a fini par ressembler à ça. Pourquoi cette API est conçue ainsi ? Pourquoi cette classe existe-t-elle ? Quels pièges sont déjà connus ?
En parallèle avec mon système : à chaque nouvelle conversation, l’IA doit à nouveau comprendre les 4000 lignes de brahma_core.py, réinventer les interdits d’architecture, et retomber une fois de plus dans les pièges déjà rencontrés. Ce n’est pas seulement du temps perdu : c’est aussi, à chaque fois, prendre des décisions avec un contexte plus mauvais.
La solution est simple : déposer un CLAUDE.md à la racine du module, en précisant :
→ le fil d’entrée principal du module
→ les commandes de test à exécuter absolument avant tout changement
→ les interdits d’architecture à ne jamais toucher
→ les pièges déjà rencontrés dans l’historique
Boris dit que cette étape réduit la mise en route des nouveaux de 3 semaines à 2 jours. Aujourd’hui, j’ai ajouté ce fichier à mon propre système : j’ai eu l’impression de laisser à quelqu’un une vraie notice, utile, pour quelqu’un d’étranger.
━━━ Une autre à retenir ━━━
Une fois qu’une erreur est corrigée, on intègre immédiatement la règle. Ne pas compter sur « se souvenir la prochaine fois », la prochaine fois on ne se souviendra pas.
Ce n’est pas une astuce de prompt, c’est une habitude d’ingénierie. Un piège vaut un sou : le deuxième, c’est du gaspillage.
Une correction, dividendes à vie.
#Claude #AI工程 #trading quantitatif
Boris Cherny (responsable de Claude Code) a rendu publique aujourd’hui la méthode de travail que son équipe utilise au quotidien. J’ai fait une vérification en la comparant à mon propre système de quantification, et j’ai découvert une faille importante.
━━━ La plus précieuse ━━━
Le premier jour sur un nouveau projet, ne coder aucune ligne, fermement.
D’abord, faire travailler l’IA à la traduction de l’historique Git pour comprendre pourquoi ce code a fini par ressembler à ça. Pourquoi cette API est conçue ainsi ? Pourquoi cette classe existe-t-elle ? Quels pièges sont déjà connus ?
En parallèle avec mon système : à chaque nouvelle conversation, l’IA doit à nouveau comprendre les 4000 lignes de brahma_core.py, réinventer les interdits d’architecture, et retomber une fois de plus dans les pièges déjà rencontrés. Ce n’est pas seulement du temps perdu : c’est aussi, à chaque fois, prendre des décisions avec un contexte plus mauvais.
La solution est simple : déposer un CLAUDE.md à la racine du module, en précisant :
→ le fil d’entrée principal du module
→ les commandes de test à exécuter absolument avant tout changement
→ les interdits d’architecture à ne jamais toucher
→ les pièges déjà rencontrés dans l’historique
Boris dit que cette étape réduit la mise en route des nouveaux de 3 semaines à 2 jours. Aujourd’hui, j’ai ajouté ce fichier à mon propre système : j’ai eu l’impression de laisser à quelqu’un une vraie notice, utile, pour quelqu’un d’étranger.
━━━ Une autre à retenir ━━━
Une fois qu’une erreur est corrigée, on intègre immédiatement la règle. Ne pas compter sur « se souvenir la prochaine fois », la prochaine fois on ne se souviendra pas.
Ce n’est pas une astuce de prompt, c’est une habitude d’ingénierie. Un piège vaut un sou : le deuxième, c’est du gaspillage.
Une correction, dividendes à vie.
#Claude #AI工程 #trading quantitatif