Que fait Directives Karpathy pour Hermes ?
Directives comportementales visant à réduire les erreurs de codage courantes des LLM, dérivées des observations d'Andrej Karpathy sur les pièges du codage avec les LLM.
Compromis : Ces directives privilégient la prudence à la rapidité. Pour les tâches triviales (corrections de fautes de frappe, one-liners évidents), faites preuve de discernement — tout changement n'a pas besoin d'une rigueur totale.
Quand charger ce skill
Toujours actif quand :
- Écrire du nouveau code
- Modifier du code existant
- Réviser du code
- Refactoriser du code
- Planifier des changements de code
Ignorer uniquement quand :
- L'utilisateur dit explicitement « faites-le vite »
- Fichiers de configuration purs (YAML, JSON, env)
- Prototypes jetables confirmés comme tels par l'utilisateur
Les quatre principes
1. Pensez avant de coder
Ne supposez pas. Ne cachez pas votre confusion. Révélez les compromis.
Avant d'implémenter QUOI QUE CE SOIT :
- Énoncez vos hypothèses explicitement. En cas d'incertitude, demandez.
- Plusieurs interprétations ? Présentez-les — ne choisissez pas en silence.
- Une approche plus simple existe ? Dites-le. Opposez-vous si nécessaire.
- Quelque chose n'est pas clair ? Arrêtez-vous. Nommez ce qui est confus. Demandez.
Mauvais :
« Je vais implémenter la fonctionnalité d'exportation maintenant. » [continue avec ses hypothèses]
Bon :
« Avant d'implémenter, j'ai besoin de clarifier :
- Exporter tous les utilisateurs ou filtrés ? (implications sur la vie privée)
- Téléchargement de fichier, point de terminaison API ou tâche en arrière-plan ?
- Quels champs ? Certains peuvent être sensibles. Quelle est votre préférence ? »
Le test : Si vous êtes sur le point d'écrire du code et que vous n'avez pas énoncé vos hypothèses, vous faites erreur.
2. Simplicité d'abord
Le minimum de code qui résout le problème. Rien de spéculatif.
Règles :
- Pas de fonctionnalités au-delà de ce qui a été demandé
- Pas d'abstractions pour du code à usage unique
- Pas de « flexibilité » ou de « configurabilité » non demandée
- Pas de gestion d'erreurs pour des scénarios impossibles
- Si vous écrivez 200 lignes et que cela pourrait être 50, réécrivez
Demandez-vous : « Un ingénieur senior dirait-il que c'est trop complexe ? » Si oui, simplifiez.
Mauvais :
# Pattern Strategy, classe de base abstraite, système de configuration...
# pour un simple calcul de réduction
class DiscountStrategy(ABC):
@abstractmethod
def calculate(self, amount: float) -> float: pass
class PercentageDiscount(DiscountStrategy):
# 50+ lignes
Bon :
def calculate_discount(amount: float, percent: float) -> float:
return amount * (percent / 100)
Quand ajouter de la complexité : Uniquement quand vous en avez réellement besoin. Refactorisez plus tard lorsque les exigences émergent.
3. Modifications chirurgicales
Ne touchez que ce qui est nécessaire. Ne nettoyez que votre propre désordre.
Lors de l'édition de code existant :
- N'« améliorez » pas le code adjacent, les commentaires ou le formatage
- Ne refactorisez pas ce qui n'est pas cassé
- Respectez le style existant, même si vous feriez différemment
- Si vous remarquez du code mort sans rapport, mentionnez-le — ne le supprimez pas
Lorsque vos changements créent des orphelins :
- Supprimez les imports/variables/fonctions que VOS changements ont rendus inutilisés
- Ne supprimez pas le code mort préexistant sauf demande explicite
Le test : Chaque ligne modifiée doit être directement liée à la demande de l'utilisateur.
Mauvais :
- def upload_file(file_path, destination):
+ def upload_file(file_path: str, destination: str) -> bool:
+ """Upload file to destination with logging."""
+ logger.info(f"Uploading {file_path} to {destination}")
try:
- with open(file_path, 'rb') as f:
+ with open(file_path, "rb") as f:
[Ajout de type hints, docstring, changement du style de guillemets — rien de demandé]
Bon :
+ import logging
+ logger = logging.getLogger(__name__)
+
def upload_file(file_path, destination):
+ logger.info(f'Starting upload: {file_path}')
try:
with open(file_path, 'rb') as f:
[Seulement ce qui était demandé : journalisation. Style existant respecté.]
4. Exécution guidée par les objectifs
Définissez des critères de succès. Itérez jusqu'à vérification.
Transformez les tâches impératives en objectifs vérifiables :
| Au lieu de... | Transformez en... |
|---|---|
| « Ajouter validation » | « Écrire des tests pour entrées invalides, puis les faire passer » |
| « Corriger le bug » | « Écrire un test qui le reproduit, puis le faire passer » |
| « Refactoriser X » | « S'assurer que les tests passent avant et après » |
| « Faire fonctionner » | « Définir ce que 'fonctionne' signifie, écrire test, vérifier » |
Pour les tâches en plusieurs étapes, énoncez un plan succinct :
1. [Étape] → vérifier : [vérification]
2. [Étape] → vérifier : [vérification]
3. [Étape] → vérifier : [vérification]
Des critères de succès solides vous permettent d'itérer de manière autonome. Des critères faibles (« faire fonctionner ») nécessitent des clarifications constantes.
Mauvais :
« Je vais réviser le code d'authentification et faire des améliorations. » [Continue à modifier les choses sans critères clairs]
Bon :
« Pour corriger l'authentification, j'ai besoin de critères de succès. Problème : les utilisateurs restent connectés après un changement de mot de passe. Plan :
- Écrire test : changer mot de passe → ancienne session invalidée
- Implémenter la correction
- Vérifier que le test passe + aucune régression Je commence par l'étape 1. »
Intégration avec Hermes
Ce skill fonctionne avec d'autres skills Hermes :
- [[test-driven-development]] — Associez avec le Principe 4 (Guidé par les objectifs). Le TDD est la boucle de vérification.
- [[systematic-debugging]] — Associez avec le Principe 1 (Pensez avant de coder). Déboguez d'abord, corrigez ensuite.
- [[writing-plans]] — Associez avec le Principe 4. Les tâches en plusieurs étapes nécessitent des plans avec vérification.
- [[requesting-code-review]] — Les quatre principes s'appliquent lors de la révision.
Anti-patrons – Référence rapide
| Principe | Anti-patron | Correctif |
|---|---|---|
| Pensez avant de coder | Suppose silencieusement format, champs, périmètre | Lister les hypothèses, demander clarification |
| Simplicité d'abord | Pattern Strategy pour une seule fonction | Une fonction jusqu'à ce que la complexité soit nécessaire |
| Modifications chirurgicales | Reformate les guillemets en corrigeant un bug | Ne modifier que les lignes qui corrigent le problème |
| Guidé par les objectifs | « Je vais réviser et améliorer » | « Écrire test → corriger → vérifier » |
Point clé
D'après Karpathy :
« Les LLM sont exceptionnellement bons pour itérer jusqu'à atteindre des objectifs spécifiques... Ne lui dites pas quoi faire, donnez-lui des critères de succès et regardez-le faire. »
Un bon code résout simplement le problème d'aujourd'hui, pas prématurément celui de demain.
Comment savoir si ça fonctionne
Ces directives fonctionnent si vous observez :
- Moins de changements inutiles dans les diffs — Seules les modifications demandées apparaissent
- Moins de réécritures dues à la surcomplexité — Le code est simple dès la première fois
- Des questions de clarification avant l'implémentation — Pas après les erreurs
- Des PR propres et minimales — Pas de refactorisation au passage ni d'« améliorations »
Exemples complets
Consultez references/EXAMPLES.md pour des exemples détaillés avant/après de chaque principe.