Developer Tools

Demandez à un modèle de répondre en JSON, et la plupart du temps json.loads() fonctionne sans problème. Les échecs sont ceux qui vous coûtent une session de débogage : un commentaire sur une ligne à l’intérieur de l’objet, un code fence markdown qui l’entoure, une clé écrite userEmail quand votre code attend user_email. Un prompt plus strict (“répondez UNIQUEMENT avec l’objet JSON, aucun autre texte”) rend ces cas plus rares. Il ne les rend pas impossibles, car le modèle peut quand même ignorer la consigne. La sortie structurée n’a plus besoin de cette consigne : vous donnez à l’API un JSON Schema, qui contraint l’échantillonnage des tokens du modèle pour que la réponse doive s’y conformer. ...

Vous enregistrez un fichier, Prettier le reformate, et ESLint signale immédiatement une erreur sur la ligne que Prettier vient de toucher. Les deux outils sont configurés, les deux tournent, et au lieu de vous aider, ils se bloquent l’un l’autre. Les deux outils ne font pas le même travail. Le problème, c’est qu’ils ont tous les deux un avis sur une seule chose : l’apparence du code à l’écran. Ce qu’ESLint vérifie réellement ESLint transforme votre code en arbre de syntaxe abstraite et exécute des règles sur sa structure. Son intérêt principal vient des règles qui détectent de vrais bugs : une variable jamais définie, un return inaccessible après un autre return, un import resté inutilisé après un refactoring, une clé d’objet dupliquée qui écrase silencieusement la première. Ce sont des vérifications sémantiques : ESLint lit ce que le code fait. ...

Pourquoi “ça a l’air juste” n’est pas un test pour un prompt Vous resserrez la formulation d’un prompt qui route des tickets, vous le testez sur les trois exemples ouverts dans votre notebook improvisé, et vous le déployez. Une semaine plus tard, les réclamations de facturation qui finissaient dans la bonne file commencent à finir dans “question”. Pas les trois cas que vous avez vérifiés : les quatre cents autres que vous n’avez pas vérifiés. Rien ne plante. Il n’y a pas de stack trace. Le prompt, lu à voix haute, sonne toujours bien. ...

Ce que fait réellement le function calling dans un LLM Demandez à un modèle « quel temps fait-il à Austin en ce moment » sans aucune connexion au monde extérieur, et il n’a que deux options : dire qu’il ne sait pas, ou inventer quelque chose. Le function calling lui offre une troisième option. Il décrit ce dont il a besoin, transmet cette description à votre code et attend une vraie réponse avant de répondre à son tour. ...

Lancez npm install sur un projet, puis pnpm install sur le même package.json : vous obtenez deux arborescences node_modules différentes et deux lockfiles différents. Ajoutez un collègue qui utilise Yarn, et le dépôt finit avec trois lockfiles dans son historique, chacun décrivant une arborescence de dépendances légèrement différente. Les trois lisent le même package.json et téléchargent depuis le même registre npm. Ce sur quoi ils ne sont pas d’accord, c’est ce qu’il faut écrire sur le disque. ...

Ce qu’un décorateur fait vraiment à votre fonction Vous voulez mesurer le temps de chaque fonction qui appelle une API externe lente. Vous pouvez coller des appels à time.perf_counter() dans chacune, ou écrire la mesure une seule fois et l’appliquer partout. Un décorateur est la deuxième option : c’est une fonction qui prend une autre fonction, l’enveloppe dans un comportement supplémentaire et renvoie la version enveloppée sous le même nom. ...

Installez deux projets Python sur la même machine et le second peut casser le premier. L’un a besoin de requests==2.28, l’autre de requests==2.32, et pip n’a qu’un seul répertoire site-packages global dans lequel écrire. La dernière installation gagne, silencieusement. Vous le découvrez quand l’autre projet commence à lever des erreurs qui n’ont rien à voir avec le code que vous venez de modifier. Un environnement virtuel donne à chaque projet son propre site-packages. Rien de global n’est touché, et deux projets peuvent dépendre de versions incompatibles de la même bibliothèque sans que l’un remarque l’autre. ...

Ce qui différencie un agent CLI de code d’un autre Demandez à un agent CLI de code de corriger un test qui échoue, et il ne répondra pas par une suggestion. Il lit la sortie du test, ouvre le fichier, modifie une ligne, relance le test, et revient vers vous une fois qu’il passe. Cette boucle, c’est le produit, pas la fenêtre de chat. Le modèle à l’intérieur de la boucle capte la majeure partie de l’attention, et c’est aussi la partie qui change le plus vite : les éditeurs en changent tous les quelques mois, et plusieurs agents vous laissent choisir. Ce qui reste en place, c’est le harnais qui entoure le modèle — quels outils il peut atteindre, comment il gère le contexte, ce qu’il peut exécuter sans demander, et où ces commandes s’exécutent. Deux agents qui tournent avec le même modèle peuvent se comporter très différemment à cause de ça. Le harnais, c’est ce que vous choisissez réellement. ...