Comment j'ai arrêté d'écrire du code et comment j'ai commencé à shipper plus vite

Il y a un mois environ, j'ai regardé une semaine de commits et j'ai réalisé que je n'avais pas écrit la majeure partie du code moi-même.

J'avais délibérément arrêté.

Ce n'était pas alarmant. Ça voulait dire que le système marchait.

Le shift

Je taffe sur une app React Native en production. Des features complexes, des contraintes réelles, une cadence de shipping qui ne pardonne pas les journées gaspillées. À un moment, j'ai commencé à poser une question différente : où est-ce que mon temps crée réellement de la valeur ?

Pas dans l'écriture de code. Dans le choix de ce qu'il faut builder, comment le builder, et si ce qui est shippé est réellement correct.

J'ai donc commencé à traiter Claude Code comme un développeur dont je suis responsable de diriger et de reviewer. Pas un outil que j'attrape de temps en temps quand je suis bloqué.

Ce framing a changé à quoi ressemble le travail au quotidien.

Deux workflows

L'erreur que je vois la plupart des gens faire quand ils parlent de coder avec l'IA, c'est de le traiter comme une seule chose. Ce sont deux modes différents, et les mélanger casse les deux.

Le flow autonome

Une partie du travail, je ne veux y être impliqué du tout. Tâches de routine, features bien scoppées où l'output attendu est vérifiable. J'écris la spec, Claude Code implémente, je check le résultat plus tard.

Je ne lis pas chaque ligne. Si l'outcome est correct, le process m'importe peu.

Le but, c'est que ça tourne sans moi pendant des heures, parfois une journée, et que ça produise quelque chose de prêt à review. Pas quelque chose à moitié fait qui a besoin de mon attention pour avancer.

Ça demande plus de discipline côté spec que ce que je pensais. Un input vague produit un output vague. Si je veux revenir checker et trouver quelque chose de shippable, je dois front-loader la réflexion : à quoi ressemble le done réellement, quels sont les edge cases qui comptent, qu'est-ce que ça ne doit explicitement pas faire.

Quand cette réflexion est en place, ça marche. Quand elle ne l'est pas, j'obtiens quelque chose qui a l'air correct jusqu'à ce qu'il tourne.

Le flow collaboratif

Le deuxième mode est différent. Je reste impliqué, mais pas dans l'implémentation.

J'ai une feature que je veux builder. Je la spec. Puis je traverse l'approche avant de la handed off : quelle est la bonne architecture, quels tradeoffs je fais, y a-t-il une meilleure voie à laquelle je n'ai pas pensé. C'est plus proche de designer avec un collaborateur que de déléguer à un.

Je vais push back sur des suggestions, changer de direction sur la base de quelque chose que le modèle remonte, itérer sur l'approche. Puis je laisse implémenter.

Pour les parties critiques, je lis le code. Pas tout. Les parties où un mauvais appel a de vraies conséquences. Les parties où j'ai besoin d'être confiant.

Ce qui a réellement changé

L'output est en hausse. Mais la forme du travail a bougé.

Je passe plus de temps à réfléchir avant que quoi que ce soit ne soit écrit. Mes specs se sont améliorées parce que les mauvaises specs ont maintenant des conséquences visibles. Le flow autonome produit quelque chose de faux, je trace en arrière, et le problème est toujours de l'ambiguïté que j'ai introduite upstream.

Je passe plus de temps à reviewer. Pas plus d'heures au total, juste une plus grande part de mon temps passée à reviewer plutôt qu'à écrire.

Et je suis plus délibéré sur quel travail va dans quel flow. Se tromper là-dessus coûte plus que ça n'épargne. Certaines tâches ont l'air de bons candidats à l'autonomie complète et ne le sont pas.

Ce qui ne marche pas

Claude Code ne tient pas ta codebase comme tu le fais après des mois dessus. Le contexte que tu fournis, c'est le plafond de ce avec quoi il peut travailler. Les specs qui assument un savoir qu'il n'a pas se manifestent en implémentations fausses, pas en questions.

Il ne catche pas non plus ses propres bugs subtils de façon fiable. Pas les évidents. Les edge cases dans du code stateful complexe, les patterns d'interaction rares, les choses qui ne fail que sous des conditions spécifiques. La review n'est pas optionnelle. Shipper du code généré par IA que tu n'as pas lu, c'est shipper le code d'un collègue sans l'avoir lu. Personne ne devrait faire ça.

Le flow autonome demande aussi une confiance que tu construis incrémentalement. Commence par des tâches à plus bas enjeu. Élargis le scope au fur et à mesure que tu sens où ça tient et où ça demande plus de guidance.

Ce que ça signifie

L'ingénieur senior le plus valuable dans ce modèle n'est pas celui qui écrit le meilleur code. C'est celui qui prend les bonnes décisions avant que le code n'existe, et qui sait faire la différence entre un output correct et un output qui a l'air correct.

Ce jugement vient du fait d'avoir shippé des choses et de les avoir vues casser. Le modèle ne l'a pas.

Je pense à ça quand je vois des ingénieurs traiter les outils de coding IA comme une menace. Ceux qui s'adaptent ne font pas un travail moins qualifié. Ils font un travail qualifié différent. Le shift d'identité est plus dur que le shift technique, et c'est la partie dont personne ne parle clairement.

Dans trois ans, je ne sais pas exactement à quoi ressemble ce job. Là tout de suite, ça ressemble à : posséder les décisions, reviewer ce qui ship, laisser l'implémentation être le problème de quelqu'un d'autre.

C'est un job différent de celui pour lequel je me suis formé. Il se trouve qu'il me va mieux.