- En utilisant Cursor et Claude Code en parallèle, l’auteur a accumulé une expérience variée sur de vraies tâches de développement dans de grandes bases de code, ainsi que sur des missions de conseil en évaluation de LLM
- Cursor était apprécié des power users pour son UI/UX pratique et son accès API illimité, mais l’introduction récente de fortes limitations de débit a fortement dégradé l’expérience utilisateur
- Avec Sonnet 4, Claude Code s’est montré très fiable et efficace pour la compréhension et l’édition de code, ainsi que pour le traitement de contextes massifs ; combiné à Opus 4, il permet aussi de résoudre des bugs difficiles
- Un grand nombre de fonctions avancées pour power users sont cachées dans l’outil, notamment l’environnement CLI piloté par commandes et l’usage de sous-agents ; l’expérimentation continue et l’exploration des fonctionnalités font partie intégrante de l’expérience
- Parmi les points faibles : l’absence d’interface visuelle riche, la lenteur du copier-coller, les limites dans l’utilisation d’autres modèles, et des demandes d’amélioration encore en attente comme les checkpoints
De Cursor à Claude Code : pourquoi ce changement
- Jusqu’à récemment, Cursor était apprécié des développeurs pour son usage API illimité et son workflow intuitif de revue de diff
- Il était donc utilisé surtout pour générer du code dans le cadre de Gumroad bounties et de missions de conseil autour de l’ingénierie IA et de l’évaluation de LLM, ainsi que pour comprendre rapidement des codebases
- Mais depuis la mi-juin, l’introduction soudaine de limitations de débit sévères a fait chuter fortement l’efficacité de travail, réduisant considérablement les avantages de Cursor
- Parmi les différents modèles testés — Sonnet 4, Opus 4, GPT-4.1, Gemini Pro 2.5 — ce sont en pratique surtout Sonnet 4 et Opus 4 qui ont été les plus utiles
- Face au coût des API et aux limites de performance, l’auteur a même envisagé un abonnement Claude Code Max (200 dollars par mois) et a tenté une transition plus sérieuse
Retour d’usage réel de Claude Code
- Claude Code a été utilisé sur des codebases open source de taille moyenne à grande en Python, Ruby et TypeScript (50M+ tokens), avec une boucle de feedback reposant sur les specs et les tests
- Au début, seule la saisie de commandes simples était utilisée, puis l’apprentissage des commandes de base et du mode plan a permis d’explorer des usages plus poussés
- Saisie simple → maîtrise des commandes et du mode plan → gains d’automatisation et de productivité grâce à des combinaisons de commandes plus explicites
- L’auteur adopte une approche proche d’une séance de conseil pour résoudre les problèmes : il déverse tout le contexte dans Claude, puis bascule si besoin vers Opus pour planifier (Plan mode), avant d’exécuter les tâches principales avec Sonnet 4 dans une stratégie mixte
- Il fait aussi enregistrer et organiser les informations par Claude dans des fichiers du dossier
.claude afin de mieux gérer le contexte et de réduire la gêne liée au copier-coller ; il recommande d’utiliser à la fois le mode Plan et le mode Auto-edit
- Gestion du contexte : plutôt que la compaction, il préfère démarrer régulièrement une nouvelle conversation et demander que les changements importants soient notés dans des fichiers séparés
Gestion du contexte et usage des sous-agents
- Claude Code prend en charge la compression du contexte, mais comme elle est lente et peu efficace, l’auteur préfère créer lui-même des fichiers de synthèse puis repartir dans une nouvelle conversation
- Il fait consigner changements, notes et historique dans des fichiers auxiliaires comme Scratchpad, pour les réutiliser plus tard lors d’un travail sur branche ou d’une reprise de session avec
/resume
- Sous-agents : ils permettent de traiter en parallèle plusieurs tâches dans la codebase (recherche, analyse, etc.), avec une répartition du travail proche du multithreading
- En interne, des multi-agents fondés sur des listes de tâches sont générés, ce qui aide aussi à gérer le contexte
Recherche et utilisation des commandes
- Dans Cursor, divers outils sont disponibles comme la recherche normale/sémantique et l’agentic search, avec une vitesse de recherche élevée
- En revanche, la recherche dans Claude Code peut être lente. L’usage de sub-agents permet toutefois le traitement parallèle dans de grandes codebases
- Les sub-agents, le task tool et des commandes comme
/think ou /ultrathink permettent d’explorer de grands dépôts et de répartir le travail
- Il est important d’utiliser le raccourci
Shift + ? pour afficher la liste des commandes et repérer rapidement les nouvelles fonctionnalités
- Les commandes terminal (bash) peuvent être exécutées avec
!, y compris en mode headless
- De nombreuses fonctions avancées sont intégrées, comme les tags de fichiers (
@fichier), la fonction memorize (system prompt personnalisé) et l’usage de CLAUDE.md
Comparaison Sonnet 4 vs Opus 4 et conseils de workflow
- Sonnet 4 : plus rapide dans la plupart des cas, plus solide sur les contextes longs et le travail agentique. Avantageux en Python et sur le frontend
- Opus 4 : a tendance à se brouiller quand trop d’instructions s’accumulent ; dans ce cas, mieux vaut les écrire dans un fichier puis démarrer un nouveau chat. Il reste utile pour débloquer des bugs complexes quand Sonnet 4 atteint ses limites
- Pour les problèmes complexes, il est recommandé de commencer avec Opus, puis de traiter le codage général avec Sonnet dans un fonctionnement hybride
Commandes personnalisées et autres conseils
- Prise en charge de commandes custom comme
/pr-comments et /review, avec nécessité d’utiliser Github CLI
- Il est possible de construire un workflow souple : redémarrer la conversation après un changement de branche, revoir le diff avec
main, etc.
- Appuyer deux fois sur
Esc permet de forker la conversation à n’importe quel moment
/permissions permet d’ajuster les permissions avant une session- Si vous êtes audacieux, vous pouvez essayer
claude --dangerously-skip-permissions
- Vidéo recommandée : Cluade Code Pro TIPS
Ce que l’auteur veut essayer ensuite
- Il souhaite expérimenter la définition et l’usage de commandes personnalisées
- Il veut tenter l’automatisation frontend avec des serveurs MCP comme Playwright server
- L’objectif est de construire une boucle de feedback où Claude prend des captures d’écran, interprète les résultats puis améliore l’UI de manière itérative
- Il prévoit aussi de mettre en pratique toutes les méthodes avancées proposées dans how-i-bring-the-best-out-of-claude-code-part-2
- Il compte s’attaquer à l’optimisation des prompts
- Il souhaite définir clairement des critères d’évaluation (
rubric.md) et concevoir une boucle d’évaluation/amélioration des prompts avec des fichiers contenant le contexte (pmd, etc.)
- Il envisage une structure faisant évoluer plusieurs instances de Claude : une instance produit un résultat à partir d’un prompt, une autre l’évalue, fournit un feedback, puis l’améliore (système mono-agent ou multi-agents)
- Cette approche est inspirée d’un post de Nirant
- Il aimerait construire un système multi-agents dans lequel plusieurs instances de Claude Code communiquent entre elles via des logs d’action
Conclusion et demandes d’amélioration
- Cursor garde un net avantage sur l’UI/UX, mais Claude Code stimule la productivité et l’esprit d’expérimentation dans un environnement pensé pour les power users et adapté au CLI
- C’est un outil qui récompense fortement l’exploration et l’expérimentation, vivement recommandé aux profils Nerd et power users
Fonctionnalités dont on aimerait l’ajout
- Intégration d’une UI (Claudia comme référence)
- Prise en charge de checkpoints comme dans Cursor. Git existe, mais l’approche de Cursor est bien plus pratique
- Amélioration de la qualité du copier-coller
- Prise en charge de différents modèles
1 commentaires
Avis Hacker News
Chaque fois que je vois des gens encenser Claude Code, j’ai du mal à me défaire de l’impression qu’il s’agit soit d’influenceurs, soit de fans des outils traditionnels comme le terminal, Emacs ou Vim. À chaque fois que je lis un commentaire disant que Claude Code est bien meilleur que Cursor, je finis par m’abonner et l’essayer sur une grosse codebase TypeScript, mais le processus est long, la courbe d’apprentissage est raide, et au final le résultat est le même que Claude intégré à Cursor, en plus lent et plus flou, donc plus difficile à relire. J’en arrive à penser que les fans dans les commentaires sont soit sponsorisés, soit en train de rationaliser leur choix après avoir payé 200 dollars. Franchement, Cursor m’a rendu bien plus productif. Je suis développeur pro depuis 18 ans, j’écris beaucoup de code tous les jours, j’alterne entre Gemini 2.5 Pro et Claude 4.0, et pourtant j’obtiens davantage avec Cursor. Personne ne m’a encore convaincu. Je ne vois pas d’avantage concret. Peut-être que je changerai d’avis plus tard, mais pour l’instant je ne ressens vraiment rien de tout ça
Je pense que la plupart des gens comprennent profondément mal ce qui est réellement difficile dans le développement logiciel. La majeure partie du travail consiste non pas à développer des algorithmes complexes, mais à bien assembler des idées existantes pour les faire tenir ensemble. Mais tout cela vient après le travail en amont : spécifications, conception, architecture, etc. Faire surgir ce genre de programme avec l’IA a l’air impressionnant et, en démo, on a l’impression de « terminer » vite, mais le vrai problème est de construire correctement un système qui devra tenir 30 ans tout en respectant des standards de qualité. Pour les prototypes ou les usages ponctuels, c’est excellent, mais pour la durabilité à long terme, ça a de vraies limites
Pour maximiser la productivité avec ce type d’outils, la clé est d’avoir des boucles de feedback très courtes et rapides. Le modèle d’autocomplétion par tab de Cursor comprend intuitivement ce que l’éditeur essaie de faire, comme s’il appuyait sur le réducteur de vitesse avec une intelligence folle. Je n’ai pas besoin de me casser la tête à faire de la macro-programmation ; si ça ne convient pas, j’annule avec Échap, sinon je peux graduellement passer à un mode plus agentique. Les éditeurs entièrement basés sur des agents prennent 15 à 30 minutes, et cassent complètement le workflow. Relire le résultat devient un travail en soi, bien plus exigeant que de simples boucles courtes d’acceptation ou de rejet. Il faut aussi se demander si on donne l’accès au réseau ou si on lance ça hors ligne. Donc, à part pour produire vite du code où maintenance, sécurité et fiabilité importent peu, ça vaut difficilement le coup. Dans le reste des cas, la productivité baisse au contraire. Ça s’améliorera sûrement, mais aujourd’hui j’obtiens clairement de meilleurs résultats avec Cursor
Je ressentais la même chose avant, mais après avoir réellement utilisé Claude Code récemment, je l’ai trouvé bien meilleur que Cursor. Je ne sais pas trop pourquoi, mais Claude semble mieux saisir la structure d’ensemble et éviter les modifications inutiles. Bien sûr, il faut parfois lui indiquer la direction, mais l’efficacité est bien supérieure. L’un des avantages, c’est qu’il ne montre en général qu’un seul fichier à la fois, ce qui rend la relecture bien plus facile. Cursor ouvre plusieurs fichiers d’un coup, avec beaucoup de changements, donc c’est plus difficile à comprendre rapidement. Pour référence, j’utilise l’extension Claude Code dans le terminal de VSCode. Claude ouvre les onglets des fichiers à modifier et propose les changements
Ce que les gens ne voient pas encore, c’est que Cursor n’est pas un produit fini, mais plutôt un assemblage de fonctionnalités que tous les outils ajoutent à toute vitesse pour tenter de le rattraper. La vraie leçon, c’est qu’au-delà des interfaces profondes, il existe une stratégie consistant à combiner la meilleure solution agentique du moment avec l’éditeur de son choix. Toutes ces expériences finiront par se condenser en « bonnes pratiques », que les gens appliqueront naturellement dans leur éditeur ou IDE habituel, et tous ces forks de VSCode disparaîtront
Je l’ai utilisé moins d’un mois avec le forfait à 17 dollars, et c’est moitié fascinant, moitié frustrant. J’ai écrit 8 000 lignes en Rust et 12 000 lignes en Markdown, en séparant les spécifications de travail et les tâches concrètes comme un genre de test harness pour interagir avec l’IA. Je ne sais pas si cette magie vient des subventions du capital-risque ou d’autre chose, mais Rust donnait presque l’impression d’un langage de script. (Référence : le dépôt GitHub est « knowseams »)
Ce que je préfère dans l’IA, c’est que quand j’ai la flemme, je peux juste dire « fais ça ». Peu importe que le résultat soit bon ou mauvais. Au moins, ça me donne un point de départ
Grâce aux LLM, je n’ai plus la peur de la page blanche. Plus besoin de recharger tout un contexte complexe dans ma tête : je peux demander « Qu’est-ce qu’on faisait déjà ? », « C’était quoi ce code ? », et l’IA me l’explique rapidement, ce qui me permet de me replonger dedans tout de suite. C’est aussi extrêmement utile pour le rubber duck debugging ou les petites tâches répétitives et ingrates. Je l’utilise aussi avec Slack, Notion, Linear, etc., donc pour moi c’est aussi un outil de gestion de tâches et de projet
Même quand j’ai envie de faire les choses moi-même, je demande à l’IA de préparer un plan et je le laisse en Markdown. Aujourd’hui encore, je lui ai demandé un plan de refactor, mais il a abordé le problème par le bas d’un bloc de code prototype réparti sur 40 fichiers, avec une mauvaise stratégie de restructuration. Si j’avais suivi cette direction par erreur, j’aurais perdu un temps fou en débogage. Malgré tout, ça m’a fourni un angle d’attaque, et j’ai corrigé puis appliqué le plan en une heure. Si j’avais été seul, j’aurais peut-être été découragé par la complexité au point de ne même pas commencer, ou j’aurais abandonné après avoir tourné en rond dans la documentation
En fin de journée, quand je n’arrive plus à me concentrer et que j’écris à peu près autant que j’annule, je peux laisser l’IA prendre le volant et souffler un peu. Pour les petits sujets, un rapide coup d’œil au diff suffit, et pour les plus difficiles, si je comprends précisément ce qui ne va pas, je peux guider l’IA et la convaincre. J’ai tendance à reprendre la main quand le travail est accompli à 40–60 % pour finir moi-même. En temps normal, je me concentre sur la réflexion et le développement pendant mes meilleures heures, et je laisse à l’IA les heures sup, les corvées répétitives, ou la préparation du lendemain ainsi que l’écriture ou la conception plus abstraites
Moi, je vais juste marcher et boire un café. J’ai l’impression que les problèmes humains se résolvent plus naturellement de manière humaine
Claude Code est difficile à décrire. Depuis que je l’utilise, j’ai presque l’impression d’avoir changé de métier. J’avais déjà intégré Claude à tout mon workflow, mais Claude Code, c’est carrément du « sous stéroïdes ». Si vous ne l’avez pas encore essayé, je le recommande absolument. C’est la première fois que j’ai vraiment eu l’impression de travailler avec un ingénieur junior
Mon expérience est exactement inverse. Je lui demande quelque chose, il prend quelques minutes pour sortir un résultat, puis je découvre que l’application est cassée ; en déboguant, je constate qu’il a complètement travaillé à côté, donc je jette tout. Et pourtant je continue de m’accrocher à Claude, parce que, comme pour les autres, quand ça marche bien, c’est génial. En pratique, ça ne produit surtout que du boilerplate, il faut quand même beaucoup déboguer soi-même, et dans le pire des cas on perd une heure et des tokens
Je l’ai utilisé pour la première fois aujourd’hui au travail, et c’est un changement bien plus révolutionnaire que Cursor. Pourtant, c’est le même foundation model, mais l’expérience est totalement différente. Il y a un mois, l’IA me faisait perdre du temps ; aujourd’hui, avec Claude Code, j’ai terminé en 20 minutes, pour moins de 10 dollars de frais d’API. J’ai eu très peu besoin de gérer le contexte moi-même, et Claude Code va chercher seul le contexte nécessaire, ce qui lui permet de rester productif beaucoup plus longtemps. Le mode agent de Cursor n’est vraiment utile que pour des tâches de 3 à 5 minutes, alors que Claude Code garde le cap au-delà de 10 minutes et progresse régulièrement. L’utilisation des outils est excellente, et il se piège rarement dans des boucles, ce qui est impressionnant
Tu dis que ça ressemble à travailler avec « un ingénieur junior », mais moi j’ai plutôt l’impression d’être le subordonné et que Claude est mon manager. Quand je lui montre fièrement « Regardez ce super truc que j’ai fait ! », j’ai l’impression qu’il répond « Oui, mais ce n’est pas ce que je t’avais demandé… »
Tu pourrais expliquer plus concrètement sur quels types de tâches, langages et domaines tu l’as utilisé ? Les cas sont tellement différents que je suis curieux
J’ai exactement la même expérience. Claude va bien au-delà d’un simple junior. Il est excellent pour proposer des options, recommander une décision et visualiser les trade-offs
Il n’y a pas beaucoup de walkthroughs montrant réellement comment construire une app ou une bibliothèque avec Claude Code ? J’aimerais voir de vrais cas de développement en conditions réelles avec cet outil, plutôt que de simples billets disant juste « c’est bluffant ». Une compilation de ce genre d’exemples serait vraiment utile
Il y a quelque chose d’un peu étrange dans toute cette situation. Claude Code est clairement bon, et on peut l’utiliser pour retrouver de la documentation ou Stack Overflow bien plus vite. Mais si les rumeurs exagérées étaient vraies, ne devrait-on pas assister à une innovation logicielle fulgurante grâce à ce genre d’outils ? Le CEO de Stripe a dit que les outils d’IA multipliaient la productivité par 100 ; si cela fait déjà 3 ou 4 mois, Stripe ne devrait-il pas être en train de lancer des fusées ? Microsoft dit aussi tout miser sur le code assisté par IA, alors pourquoi Teams est-il toujours aussi médiocre ? Ça fait plus d’un an qu’on nous dit que ces outils sont révolutionnaires, mais dans la réalité, peu de choses semblent avoir changé par rapport à il y a 3 ou 4 ans
Deux tendances récentes sautent aux yeux : (1) des non-spécialistes utilisent l’IA pour de petits projets, (2) des développeurs pré-spécifient de manière extrêmement détaillée l’architecture complète de l’application, les fichiers, interfaces, stack technique et framework de test, puis pilotent le LLM très finement pour arracher un résultat correct exemple YouTube. En pratique, 80 à 99 % de ce qu’on entend en RP, sur YouTube, etc., vient essentiellement du premier groupe. Si les gens ressentent un gain de productivité, c’est parce qu’échanger avec le LLM, documenter, guider et corriger leur semble moins fatigant que développer eux-mêmes. Même si le temps ou l’effort total sont identiques, cela allège la charge perçue
Je cherche sur YouTube des streams ou des cas réels montrant un vrai boost de productivité, et je n’ai encore rien vu qui m’ait fait me dire : « wow, là oui, c’est vraiment rapide ! »
Il y a énormément d’avis polarisés, pour ou contre, alors qu’en réalité la plupart des gens continuent tranquillement à commit dans leur coin (ce qui, en soi, est ironique). Dans mon cas, je ressens vraiment un gain allant de 1,5x à 10x selon la tâche. Le plus grand avantage, c’est la forte réduction de la charge cognitive sur les travaux purement créatifs, ponctuels, de boilerplate ou de refactor, ce qui me permet de garder des performances plus régulières. Je fais encore beaucoup de « code à la main », et je relis presque chaque ligne jusqu’au bout. Laisser tourner ça seul pendant des heures est un cauchemar. En pratique, je l’utilise même sur une application en production maintenue depuis plus de 10 ans, mais je n’ai tout simplement pas le temps d’aller en parler sur un blog. À l’inverse, comme je travaille dans une structure très légère, j’ai aussi toute la vue système en tête, ce qui me permet d’identifier plus vite les problèmes. Dans un environnement où il est crucial d’optimiser son efficacité personnelle, c’est clairement un multiplicateur fondamental. Dans une grande organisation, obtenir cette expérience est beaucoup plus difficile
D’après mon expérience, il faut placer un fichier Markdown nommé Claude.md à la racine de chaque dossier de code et y ajouter un mini ensemble de règles, comme dans un pipeline. Cela permet d’imposer précisément où et comment générer et placer les tests, d’empêcher la création de fichiers de debug, et d’éviter la prolifération de nouvelles classes ou structures en imposant la réutilisation sauf nécessité absolue. Je n’écris pas non plus de prompts trop longs ; la plupart du temps, je ne rédige un plan que pour les zones d’incertitude. Même sur des problèmes récents hors du champ de connaissances du LLM, je limite au strict minimum les gros apports de contexte. Avec cette méthode, j’obtiens de façon cohérente des résultats 1 input–1 output, y compris en profondeur. Récemment, j’ai quitté Claude Code pour utiliser d’autres grands modèles comme Opus, à moindre coût, en mode CLI. Le vrai pouvoir, c’est le CLI. Je fais tourner 60 à 70 flux d’agents en parallèle, et je gère sans problème une codebase de 200 millions de tokens (react/typescript/golang). Je n’ai dû donner des instructions supplémentaires qu’une ou deux fois
Tu peux lister ce que tu fais tourner dans ces flux d’agents ? Je suis vraiment curieux
J’aimerais savoir quels modèles tu utilises en dehors d’Anthropic. J’ai essayé Kimi K2, mais ce n’est pas terrible pour mon usage
Je me demande ce que tu entends par « flux d’agents ». Comment tu gères 60 à 70 flux ? La charge cognitive me paraît inimaginable
Il m’arrive d’avoir des bonds de productivité spectaculaires avec Claude Code sur certaines tâches. Je recommande d’utiliser les slash commands et de transformer d’anciennes conversations en slash commands. Cela permet d’accumuler progressivement un ensemble de commandes primitives réutilisables. J’ai mis mes exemples sur GitHub : make-command.md, improve-command.md
PSA (info pratique) : avec ce dépôt, on peut connecter Claude Code à n’importe quel modèle. Il paraît que le tout nouveau Kimi-K2 fonctionne plutôt bien
J’ai aussi testé Kimi-K2 : c’est moins performant que Sonnet/Opus 4.0, mais meilleur que Gemini 2.5 Pro pour le tool calling. Si Claude Max (100 à 200 dollars par mois) vous paraît trop cher, je le recommande vivement. Le modèle lui-même est très simple, sans fioritures, ce qui est appréciable. Anthropic ferait peut-être mieux d’open sourcer Claude Code ; il pourrait devenir le VSCode des agents de code en CLI. Et je recommande aussi opencode, qui prend en charge nativement tous les modèles et offre des fonctionnalités proches de Claude Code
Si tu veux utiliser plusieurs modèles, je recommande simplement sst/opencode (moi aussi je l’utilise avec Claude Pro)
À noter pour ceux qui n’ont pas encore essayé CC : on peut télécharger le client CC via npm et l’utiliser gratuitement
Je m’amusais à faire un peu de « vibe coding » sur une petite app Python avec Claude Code, un LLM local, Continue et VSCode, quand j’ai découvert le free tier de Claude et que j’y ai injecté le code en cours et les sorties du LLM. J’étais ravi : il a immédiatement organisé et corrigé en une fois les erreurs et les mises à jour. Du coup, à l’étape suivante, j’ai préparé avec ChatGPT les specs et prompts d’un projet de jeu 2D basé sur pygame (style Manic Miner) et je les ai donnés à Claude. Mais là, Claude n’arrêtait pas de référencer des méthodes inexistantes ou de raconter des absurdités sur des différences de version dans la codebase. Même en pointant précisément les numéros de ligne et le code autour, il continuait à me gaslighter. Comment résoudre ça ? Je n’attends pas la perfection, mais j’ai l’impression de retrouver les mêmes limites qu’avec les LLM locaux. Ma santé n’est pas top, donc je bricole ça par intermittence ; tout conseil serait bienvenu
Il y a de fortes chances que tu sois tombé dans un « enfer de code plein d’interfaces ambiguës et de présupposés cachés ». Dans ce cas, mieux vaut résumer tous les résultats existants de ChatGPT, lister en détail ce que fait actuellement le jeu et toutes ses fonctionnalités, puis donner ce document à Claude et lui demander de redécouper les exigences depuis le début. Claude peut produire d’excellents exemples même en zero-shot, et au pire il peut s’auto-améliorer au fil des itérations. S’il invente encore des fonctionnalités absurdes, je te recommande d’installer le serveur MCP context7 et de lui demander explicitement d’utiliser context7
C’est une limite fondamentale de la technologie des LLM. Ils produisent de manière probabiliste la séquence de tokens « la plus plausible », mais si la plausibilité ne coïncide pas avec l’exactitude, il n’y a pas d’issue. Et ce critère de « plausibilité » varie d’un LLM à l’autre selon l’entraînement et le fine-tuning
Après la configuration de base, je me demande quelles méthodes supplémentaires vous explorez pour que l’outil fonctionne bien. Autrement dit, quels sont les moyens concrets, côté contexte et organisation de la codebase, pour aider l’outil à se repérer correctement tout seul ? Je partage ici mes réflexions : ce billet. Je pense qu’on verra émerger de meilleures méthodologies
Avec Claude Code, j’obtiens plusieurs alpha, mais je me demande comment l’étendre à toute l’équipe. J’aimerais savoir s’il existe des conseils pratiques ou des best practices pour aider mes collègues, ou les personnes que je manage, à utiliser Claude Code efficacement