500 heures de programmation avec l'IA : les habitudes qui séparent les bons résultats des mauvais

La prémisse sonne presque trop simple : un développeur connu sous le nom de The Coding Sloth, après plus de cinq cents heures de codage avec l'aide de l'IA, affirme avoir compris pourquoi les résultats varient tellement d'un utilisateur à l'autre. Certains programmeurs rejettent les assistants comme inutiles tandis que d'autres les encensent, et sa réponse est que la différence vient rarement du modèle. Ce qui décide du résultat, c'est l'opérateur, et surtout la précision avec laquelle il exprime son intention et la solidité de ses habitudes d'ingénierie.

Le premier conseil est délibérément provocateur : apprendre la programmation avant de s'appuyer sur la machine. Dans ce cadre, l'IA multiplie les connaissances existantes au lieu de les remplacer. Une personne incapable de lire le code généré ne peut pas l'évaluer, ne peut pas le déboguer, et ne peut pas distinguer un non-sens assuré d'une réponse correcte. La formule approximative est que déléguer sa réflexion ne fonctionne que s'il existe une réflexion digne d'être déléguée.

Le deuxième conseil prolonge le premier : soyez aussi précis que possible. La plupart des résultats décevants remontent à des requêtes sous-spécifiées, et la vidéo soutient que les programmeurs, rarement réputés pour leurs compétences en communication, ont aujourd'hui plus que jamais besoin de ces compétences. La qualité des réponses suit la qualité du contexte fourni, donc décrire la tâche de manière superficielle garantit presque un résultat générique ou défectueux.

Pour étayer son affirmation, il mène une petite expérience contrôlée, demandant à l'assistant de codage de JetBrains, Junie, de construire un clone de Google Docs trois fois avec un niveau de détail croissant. Niveau un : une exigence de trois mots, sans stack, sans design, sans contraintes. Niveau deux : une description du produit en langage simple, mais sans aspect technique. Niveau trois ressemble à un véritable cahier des charges : stack technique exacte, commandes de terminal, documentation de référence, captures d'écran de l'apparence souhaitée et liens que l'assistant peut consulter.

Les résultats se séparent nettement. La requête minimale ne donne rien d'utilisable, mais Junie gagne du crédit pour avoir pris le temps de demander des clarifications au lieu de deviner et de produire du n'importe quoi. La requête intermédiaire produit une structure où la plupart des fonctionnalités demandées existent mais arrivent défectueuses, avec des erreurs et un écran sans style exigeant des réparations manuelles. La requête détaillée fonctionne du premier coup, fonctionnalités en place et code visuellement plus propre, parce que l'humain avait tranché presque tous les choix d'architecture à l'avance.

Deux tactiques complémentaires accompagnent l'expérience principale. D'abord, cessez de considérer la recherche et l'IA comme des rivales : localisez vous-même la documentation et remettez-la à l'assistant, puisque les assistants actuels peuvent naviguer sur le web et que de nombreux projets publient désormais des docs adaptées aux machines au format llms.txt. Ensuite, un raccourci pour les paresseux avec un vrai levier : rédigez la requête techniquement complète mais approximative, puis demandez au modèle lui-même de la réécrire selon les bonnes règles de prompting.

Le principe suivant est le plus ancien conseil de la vidéo : diviser les grandes tâches en petites. Les assistants excellent sur des travaux au périmètre étroit et échouent sur des missions tentaculaires, ce qui reformule la sagesse classique de l'ingénierie d'avant les modèles de langage. Planifier la solution, la décomposer et confier la frappe à l'assistant garde l'humain au poste de réflexion. La règle tient en une phrase : confiez la frappe, jamais la réflexion.

Réduire les sorties bâclées mérite son propre schéma, une requête en trois parties : la tâche décrite aussi concrètement que possible, du matériel de contexte avec fichiers, documentation et images, plus une section do-not listant tout ce qui doit rester intact. La démonstration ajoute une fonctionnalité de commentaires à la Docs selon exactement ce schéma et y parvient en quelques minutes. Contraindre l'assistant s'avère aussi important que l'instruire.

Les fichiers mémoire et les intégrations d'outils se complètent : un document markdown vivant dans le dépôt enregistre ce qu'est le projet, quelle stack il utilise et quelles commandes comptent, afin que l'assistant le lise à chaque session au lieu de redécouvrir les bases. MCP, le protocole ouvert qui branche des capacités externes dans les assistants, ajoute un récupérateur de documentation pour le travail web, une intégration de framework exposant les erreurs de build, et un pont navigateur faisant remonter les données de console et de performance. Le conseil est d'assembler la combinaison correspondant à votre propre stack plutôt que de copier la liste, avec des modèles prêts à l'emploi pour les stacks populaires rendant le démarrage bon marché.

La dernière règle de travail est la vérification : ne laissez jamais l'assistant se contenter d'écrire du code, donnez-lui toujours un moyen de prouver que le code fonctionne. Tests, exécution de l'application dans un navigateur, vérifications en ligne de commande, pipelines d'intégration, tout ce qui est falsifiable compte, et l'assistant peut rédiger lui-même les vérifications tant qu'un humain confirme qu'elles passent réellement. Les tâches de design se marient naturellement avec les outils navigateur décrits plus tôt.

L'argument final relie tous les fils : les assistants amplifient les habitudes que vous portez déjà. Les développeurs qui spécifient soigneusement, décomposent les problèmes, documentent les projets et testent le code se voient rendre ces vertus au centuple. Les développeurs qui sautent les tests et ignorent les cas limites se voient rendre ces défauts au centuple aussi, c'est pourquoi la vidéo se termine davantage comme un appel à rester préparé que comme un argumentaire de vente.