Comment Claude m'a convaincu

L’an dernier, j’avais exprimé sur Linkedin quelques réserves sur le vibe coding et, plus largement, sur l’usage de l’IA pour coder. Ca se basait sur des experiences bof-bof via Copilot, et un essai de Windsurf, très frustrant. Un an plus tard, les choses ont clairement évolué. Aujourd’hui, j’utilise l'AI quotidiennement et dans un contexte professionnel (nous y sommes encouragés). Je suis tombé dedans, plus de réserves (hors éthiques), plus de frictions.

Qu'est ce qui a changé ?

1. Les modèles d'abord. L'essai de Claude Code avec Opus 4.5 a marqué un vrai tournant : moins d’erreurs, moins d’hallucinations, une experience plus fluide, et surtout un livrable de grande qualité, qu'on hésite pas à livrer en revue de code aux collègues. On aurait fait aussi bien, voire souvent moins bien, en tous cas en bcp moins de temps ca c'est sur.
2. L’usage de modes plus structurés (PLAN, SKILLS, AGENTS) fait toute la différence. Là où soit travailler sur des tout petits bouts de code avec Copilot était décevant, là où à l'inverse des essais plus libres et ouvert avec Windsurf ont tourné au fiasco, l'utilisation des agents et le cadrage en general ont été le vrai game changer comme disent les jeunes.

Je reste pour autant en review systématique de ce qui est produit. Chaque ligne compte. On guide, on demande et on valide chaque proposition de notre nouveau collègue. Mais j’avoue avoir cliqué récemment, un peu fébrilement, sur l’option “accepter et ne plus demander l’autorisation pour la suite”. Et… ça n’a pas été la catastrophe.
Sur des projets perso, pour l'instant. Et sur un truc un peu trivial au boulot, mais le résultat a été au niveau de ce que j'attendais.

Cette montée en puissance pose cependant des questions plus larges, notamment sur l'articulation entre vitesse et productivité.
Dans une industrie où la notion de sprint est parfois prise trop au pied de la lettre, que fait-on d’un monde où quelques développeurs peuvent produire en une journée l’équivalent de semaines de travail ?
Comment absorber des volumes massifs de code à reviewer, de features à tester, à livrer ?
Comment garder du recul, de la digestion, des respirations, quand le flux devient quasi continu ?
Et surtout : une fois livré, sur quoi enchaîne-t-on ?

La question du “grand remplacement” des devs revient souvent aussi. Personnellement, ce n’est pas tant l’idée d’être remplacé qui m’inquiète, c'est ce qu’on va faire de gain de productivité.

• Option 1 : Est-ce qu’on va produire plus et mieux: plus de qualité, plus de détails, plus de sens ?
• Option 2 : Ou est-ce qu’on va surtout chercher à faire des économies de personnel ?

Si on demande aux équipes, évidement tout le monde va voter pour qu'on utilise le gain de productivité pour plus de documentation, de testing, d'attention aux details, d'itération qualité. Qu'on en profite aussi pour plus creuser la conception, l'architecture, la securité... Mais spoiler alert, evidement qu'on choisira à votre place et ca sera souvent l'option numero 2

Malgré tout, je garde plusieurs points d’attention très concrets dans mon usage quotidien.

1. Le coût, très réel.
Claude Code avec Opus 4.5 est impressionnant, mais il consomme facilement deux fois plus de tokens que Sonnet. Là où je peux travailler une journée entière avec Sonnet sans atteindre les limites de session, Opus impose des sessions plus courtes. Cela dit, ca du bon. Les limites de session sont presque devenues une alarme : arrête-toi, lève-toi, fais autre chose, reviens demain. Bon quand ca arrive à 17h30, c'est nickel, si c'est à 09h30, videz vortre contexte

2. Le contrôle du contexte.
Skills, agents, MCP, plugins… tout ce qui est activé consomme du contexte, et donc des tokens — souvent pour peu de valeur ajoutée. Désactiver ce qui ne sert pas est devenu une vraie pratique : moins de bruit, plus de pertinence, plus de rapidité.
Dans le même esprit, certains usages restent décevants. Par exemple, Claude Code dans Chrome consomme énormément pour des résultats très moyens. Dans ces cas-là, un test manuel est souvent plus rapide et plus efficace, ou il vaut mieux basculer vers de vrais outils d’automatisation côté navigateur (Playwright, Cypress).

3. Des pratiques de développement encore plus solides.
L’IA ne remplace pas — et ne doit surtout pas affaiblir — les fondamentaux. Bien au contraire.
Pull requests systématiques, CI/CD stricte, linting, tests automatisés, couverture maximale : ces garde-fous deviennent encore plus critiques quand la production de code s’accélère. La vitesse sans cadre, c’est juste une dette technique qui arrive plus vite.

4. La question des tests, centrale.
Faut-il laisser l’IA écrire le code, en faire la revue et écrire les tests elle-même ?
Ou au contraire se réserver l’écriture des tests pour garder un contrôle fort sur les scénarios, les cas limites, et s’assurer que le code produit répond exactement au besoin sans “tricher” pour faire passer les tests ?
Pour l’instant, je penche clairement pour la seconde option.