La semaine dernière, j'ai ouvert mon tableau de bord Wakapi par curiosité et j'ai remarqué quelque chose à quoi je n'avais jamais prêté attention : sur environ 17 heures de code suivies le mois dernier, plus de 16 heures étaient classées dans une catégorie « AI Coding ». La majeure partie de ce temps s'est passée en TSX et TypeScript, à refondre mon portfolio personnel et à faire avancer PromptoShare, une application React/Next.js/Node pour partager des prompts. Ce chiffre m'a assez surpris pour que je me demande vraiment *comment* j'utilisais ces outils, plutôt que de simplement les utiliser. Deux projets très différents, deux usages très différents Côté frontend — la refonte de mon portfolio et PromptoShare — l'assistance IA sert surtout à gagner du temps sur des tâches mécaniquement répétitives mais qui demandent encore mon jugement : générer un nouveau composant TSX, câbler des types de props qui correspondent à un schéma MongoDB, produire un premier brouillon de mise en page Tailwind que je démonte ensuite pour la reconstruire comme je la veux vraiment. C'est rapide, mais c'est rarement « terminé » dès le premier passage. Côté backend, mon plus gros projet est de loin FinancialEvents, un système Java/Spring Boot que je construis depuis plus d'un an (plus de 1 200 commits). Là, je m'appuie beaucoup moins sur l'IA pour l'architecture, et beaucoup plus pour les parties fastidieuses mais nécessaires : DTOs, boilerplate de repositories, jeux de tests pour les cas limites du traitement d'événements. La logique métier elle-même — comment les événements financiers sont validés, transformés et réconciliés — je continue à la concevoir et l'écrire à la main, car c'est précisément là qu'une suggestion qui a l'air juste mais qui est subtilement fausse est la plus dangereuse. **Ce qui a vraiment changé dans mon flux de travail** Quelques habitudes se sont installées une fois que j'y ai fait attention : 1. J'écris d'abord la spec ou le test, même approximatif. Laisser un assistant deviner l'intention à partir de rien produit du code qui compile mais qui ne correspond pas au besoin. Lui donner une structure à remplir produit quelque chose de bien plus utile. 2. Chaque suggestion est lue, jamais survolée. Le vrai risque n'est pas le code manifestement cassé — c'est le code qui a l'air correct, qui passe un coup d'œil rapide, mais qui cache une mauvaise hypothèse sur un cas nul ou une erreur de pagination. 3. Je réserve l'aide de l'IA aux couches que je peux vérifier rapidement. Les composants d'interface et le boilerplate de structures de données se vérifient facilement d'un coup d'œil. Les règles métier d'un système financier, non — donc c'est là que je ralentis volontairement. Le constat honnête Ces outils ne m'ont pas fait coder moins — ils ont changé *le type* de code sur lequel je passe mon temps. Moins de temps à taper du TSX ou du boilerplate Spring Boot répétitif, plus de temps à me demander si la structure d'un composant ou la logique de traitement d'événements a vraiment du sens. C'est un échange que je continuerai à faire, mais les chiffres de Wakapi m'ont utilement rappelé de rester lucide sur les moments où je laisse l'assistant guider, et ceux où je garde les deux mains sur le volant. Si vous construisez quelque chose de similaire — une appli full-stack où le frontend doit avancer vite et le backend doit être prouvablement correct — je serais curieux de savoir où vous placez cette même limite.