J'ai construit un second cerveau qui rédige mes PRs à ma place

J'ai construit un second cerveau qui rédige mes PRs à ma place

Jeudi dernier, j'ai livré une fonctionnalité qui touchait 14 fichiers répartis sur trois services. La description de la PR faisait deux paragraphes de contexte clair et précis. La mise à jour de statut pour mon équipe était déjà rédigée dans Slack avant que je finisse mon café. Les notes de passation pour le prochain développeur attendaient dans un fichier markdown, parfaitement structurées, prêtes à être partagées.

Je n'ai rien écrit de tout ça.

Pas un seul mot. Et avant que tu assumes que j'utilise un système de templates sophistiqué ou que je copie depuis ChatGPT — non. Mon setup Claude Code a tout écrit parce qu'il savait déjà ce que je construisais, pourquoi j'avais pris certaines décisions architecturales, quels compromis j'avais envisagés, et ce que la prochaine personne reprenant le projet aurait besoin de comprendre. Il savait tout ça parce que j'avais passé les six derniers mois à lui apprendre — pas à coups de prompts élaborés, mais via des mises à jour de 30 secondes à la fin de chaque session de travail.

J'appelle ça mon second cerveau. Ça sonne dramatique jusqu'à ce que tu le voies générer une description de PR meilleure que tout ce que j'écrirais manuellement, en faisant référence à des décisions que j'avais prises trois semaines plus tôt et que j'avais déjà oubliées. L'écart entre "une IA qui aide avec le code" et "une IA qui gère la charge cognitive d'être ingénieur" est énorme — et la plupart des développeurs sont coincés du mauvais côté.

Voilà ce dont personne ne parle quand on s'extasie sur les outils de code IA : écrire du code, c'est peut-être 40 % de ce que les ingénieurs font réellement. Les 60 % restants, c'est de la communication. Des mises à jour de statut. Des descriptions de PR. De la documentation. Des notes de passation. Des rapports d'incident. Des registres de décisions d'architecture. Toute cette rédaction nécessite du contexte — un contexte profond, spécifique et à jour sur ce que tu construis et pourquoi. Et c'est exactement là que tous les outils IA que j'ai essayés avant Claude Code se sont complètement écroulés.

Laisse-moi te montrer comment j'ai résolu ça. Mais d'abord, je dois t'expliquer pourquoi les solutions évidentes ne marchent pas — parce que j'ai perdu des mois dessus avant de trouver ce qui fonctionne.

Pourquoi balancer de l'IA sur les tâches de rédaction ne marche pas (au début)

J'ai été un early adopter de l'utilisation de l'IA pour la communication en ingénierie. Dès que ChatGPT a pu tenir une conversation sur du code, j'ai commencé à coller des diffs en demandant des descriptions de PR. Les résultats étaient... passables. Génériques, globalement corrects, mais il manquait chaque élément de contexte qui rend une description de PR réellement utile.

Le problème est structurel, pas un problème de qualité de l'IA. Quand tu colles un diff dans n'importe quel chatbot, il peut voir ce qui a changé. Il ne peut pas voir pourquoi ça a changé. Il ne sait pas que tu as refactorisé le middleware d'authentification parce que l'audit de sécurité du mois dernier a signalé une vulnérabilité de fixation de session. Il ne sait pas que tu as choisi Redis plutôt que Memcached parce que l'équipe utilise déjà Redis pour la file de jobs. Il ne sait pas que cette PR est la troisième partie d'une migration en cinq étapes qui a commencé il y a deux sprints.

Alors qu'est-ce que tu fais ? Tu expliques le contexte. À chaque fois. Tu tapes trois paragraphes de background, tu colles le diff, et ensuite l'IA te donne une description de PR raisonnable. Félicitations — tu viens de passer cinq minutes à fournir du contexte pour t'économiser trois minutes de rédaction. Gain net : moins deux minutes. Plus la charge cognitive du changement de contexte entre le code et "explique tout mon projet à un chatbot".

J'ai essayé de construire des templates de prompts. "Étant donné que ce projet utilise Laravel 11 avec du cache Redis et Postgres..." — des blocs de contexte pré-remplis que je collais avant chaque requête. Ça a un peu aidé. Mais le contexte devenait obsolète en quelques jours. Les projets évoluent vite. Ce qui était vrai lundi ne l'est plus jeudi. Maintenir ces templates est devenu une corvée en soi.

Ensuite j'ai essayé les outils IA avec mémoire intégrée. La fonctionnalité mémoire de ChatGPT, spécifiquement. Elle se souvenait que je préfère TypeScript et que je travaille sur des applications web. Incroyablement superficiel. C'est comme embaucher un assistant qui se souvient de ton nom mais oublie chaque conversation de projet que tu as eue.

Le problème fondamental de toutes ces approches : le contexte vit dans ta tête, pas dans le système. Chaque fois que tu veux que l'IA fasse quelque chose d'utile, tu dois extraire le contexte pertinent de ton cerveau, le formater pour l'IA, et vérifier la sortie. Cette étape d'extraction est le goulot d'étranglement, et aucun prompt engineering au monde ne l'élimine.

Ce qui l'élimine, c'est de donner à l'IA sa propre base de connaissances persistante, locale et continuellement mise à jour. Un second cerveau qu'elle maintient à tes côtés pendant que tu travailles. C'est ce que j'ai accidentellement construit avec Claude Code — et ça a transformé toute ma relation avec la communication en ingénierie.

Comment fonctionne réellement le système de contexte local de Claude Code

Il y a six mois, j'ai basculé sur Claude Code principalement comme agent de code. Il est vraiment excellent pour écrire et refactoriser du code — mais ce n'est pas ce qui m'a accroché. Ce qui m'a accroché, c'est de découvrir qu'il maintient un contexte local et persistant via des fichiers markdown qui vivent directement dans le répertoire de ton projet.

Le mécanisme est simple. Claude Code lit et écrit des fichiers markdown — typiquement CLAUDE.md à la racine de ton projet et des fichiers de contexte additionnels que tu crées. Ces fichiers persistent entre les sessions. Ils ne disparaissent pas quand tu fermes ton terminal. Ils ne se perdent pas dans un cloud quelque part. Ils sont dans ton repo, versionnés aux côtés de ton code, s'enrichissant à chaque session de travail.

Voici à quoi ressemble mon fichier de contexte projet après six mois de connaissances accumulées :

# Project Context

## Architecture
- Laravel 11 monolith with Vue 3 SPA frontend
- PostgreSQL primary DB, Redis for caching and queues
- Deployed on AWS ECS with Terraform-managed infrastructure
- Auth: Custom JWT implementation (migrated from Sanctum in Sprint 14)

## Current Sprint (Sprint 22)
- Payment processing refactor: Stripe → multi-provider abstraction
- Migrating webhook handlers from sync to async queue processing
- Performance: targeting p99 < 200ms on checkout flow

## Recent Decisions
- Chose adapter pattern over strategy for payment providers (2024-01-15)
  - Reason: Need runtime provider switching per merchant config
- Rejected event sourcing for payment state (too complex for current scale)
- Redis cluster mode enabled for horizontal scaling prep

## Known Tech Debt
- Legacy order model still uses soft deletes (migration planned Sprint 24)
- Test coverage on payment module: 67% (target: 85% before launch)

Ce fichier n'est pas apparu par magie. Je l'ai construit au fil du temps, 30 secondes à la fois. À la fin de chaque session de travail, je dis à Claude Code : "Mets à jour le contexte projet avec ce sur quoi on a travaillé aujourd'hui." Il passe en revue la session — les fichiers qu'on a modifiés, les décisions qu'on a discutées, les problèmes qu'on a résolus — et ajoute les mises à jour pertinentes au fichier de contexte.

Trente secondes. C'est l'investissement. Et le retour se compose massivement.

Parce que la prochaine fois que je m'assois et que je demande à Claude Code de rédiger une description de PR, il n'a pas besoin que je lui explique quoi que ce soit. Il lit le fichier de contexte, voit les objectifs du sprint en cours, comprend les décisions d'architecture, connaît les changements récents, et génère une description qui semble écrite par quelqu'un qui est sur le projet depuis des mois.

La différence est flagrante. Compare ces deux descriptions de PR — l'une d'une interaction IA à froid, l'autre de mon second cerveau :

IA à froid (diff collé, sans contexte) :

"Cette PR met à jour le module de traitement des paiements. Les modifications incluent des changements dans la classe PaymentService, l'ajout de nouvelles interfaces de fournisseurs, et des mises à jour des tests associés."

Second cerveau (avec contexte accumulé) :

"Implémente la couche d'adaptateurs pour l'abstraction multi-fournisseur de paiement (Sprint 22). Introduit l'interface PaymentProviderAdapter avec Stripe comme première implémentation concrète. Les handlers de webhooks restent synchrones dans cette PR — la migration asynchrone suivra dans la prochaine PR selon notre approche queue-first. La configuration par marchand du fournisseur de paiement lit depuis la table de paramètres existante avec une nouvelle colonne payment_provider (migration incluse)."

Même diff. Même modèle d'IA. La seule différence, c'est le contexte — un contexte persistant, accumulé et local que je n'ai pas eu à ré-expliquer.

Ça change tout dans la façon dont j'interagis avec l'IA pour les tâches d'ingénierie. Et ça va devenir encore plus puissant quand tu ajoutes les skills dans l'équation.

Construire ton second cerveau — Le rituel de 30 secondes qui change tout

Allez, laisse-moi te guider pas à pas dans la mise en place, parce que l'implémentation est ridiculement simple. La valeur n'est pas dans la complexité — elle est dans la constance.

Étape 1 : Crée ton fichier de contexte initial.

Au début de n'importe quel projet (ou maintenant, pour les projets existants), passe 10 minutes à faire construire par Claude Code ton contexte de base. Ouvre ton terminal à la racine du projet et dis :

"Regarde la structure du codebase, l'historique git récent, et toute documentation existante. Crée un fichier CLAUDE.md résumant l'architecture du projet, la stack technique, les axes de travail actuels, et tous les patterns que tu peux identifier."

Claude Code va scanner ton projet, lire les fichiers clés, vérifier les logs git, et générer un document de contexte complet. Relis-le, corrige ce qui est faux, et tu as ta fondation.

Étape 2 : La mise à jour de fin de session (30 secondes).

C'est l'habitude qui fait fonctionner le système. À la fin de chaque session de travail — avant de fermer ton terminal — dis :

"Mets à jour le contexte projet avec ce sur quoi on a travaillé aujourd'hui."

C'est tout. Claude Code passe en revue la session, identifie ce qui mérite d'être retenu, et met à jour le fichier de contexte. Les nouvelles décisions sont enregistrées. Les tâches terminées sont marquées. La dette technique est notée. Le fichier de contexte grossit, mais reste concentré parce que Claude Code est bon pour distinguer les "connaissances projet importantes" des "détails de débogage temporaires".

Étape 3 : Condensation périodique.

Toutes les quelques semaines, le fichier de contexte s'allonge. Quand ça arrive, je demande à Claude Code de le condenser : "Le fichier de contexte devient trop long. Consolide-le — garde tout ce qui est encore pertinent, archive ou supprime ce qui est obsolète."

Ça permet de garder le fichier compact et rapide à parser. Mon fichier de contexte actuel fait environ 400 lignes pour un projet sur lequel je travaille depuis six mois. C'est léger. Et chaque ligne est pertinente.

Astuce pro : Je garde un fichier decisions.md séparé pour les décisions architecturales que je veux conserver à long terme, même si elles ne sont plus directement pertinentes pour le sprint en cours. C'est de l'or pour l'onboarding de nouveaux membres d'équipe ou pour se rappeler pourquoi tu as choisi une approche spécifique six mois plus tard.

Le rituel semble trivial. Trente secondes à la fin d'une session. Mais réfléchis à ce qui se passe après un mois. Tu as 20+ mises à jour accumulées. L'IA connaît tes patterns de code, tes préférences architecturales, l'évolution de ton projet, les compromis que tu as envisagés et rejetés. Elle ne sait pas juste ce que fait le code — elle sait pourquoi tu l'as construit comme ça.

Ce n'est pas un chatbot. C'est une mémoire institutionnelle qui n'oublie jamais, ne part jamais en vacances, et n'a jamais besoin d'une réunion de remise à niveau.

Maintenant, c'est là que ça devient vraiment excitant — parce qu'une fois que tu as un contexte riche, tu peux construire des workflows qui seraient impossibles sans lui.

Skills : Apprendre à ton IA à reproduire ton meilleur travail

Un skill dans Claude Code est essentiellement un workflow sauvegardé et reproductible. Imagine un macro, mais intelligent — il s'adapte au contexte actuel au lieu de rejouer aveuglément des étapes.

Le concept est d'une belle simplicité : tu fais une tâche une fois avec Claude Code, et à la fin tu dis : "Transforme ça en skill." Claude Code examine ce que tu as fait — la séquence d'étapes, les décisions que tu as prises, le format de la sortie — et le sauvegarde comme un workflow réutilisable. La prochaine fois que tu dois faire le même type de tâche, tu déclenches le skill et il gère tout.

Créer ton premier skill — descriptions de PR automatisées :

C'était mon premier skill, et c'est toujours celui que j'utilise le plus. Voici comment je l'ai construit :

1. J'ai manuellement guidé Claude Code dans la rédaction d'une description de PR pour un vrai changement que j'avais fait.
2. Pendant le processus, j'ai corrigé sa sortie : "Non, ne liste pas juste les fichiers modifiés — explique le pourquoi derrière chaque groupe de changements."
3. J'ai ajusté le format : "Utilise cette structure : Résumé, Motivation, Changements, Notes de test, Points de suivi."
4. Quand la sortie correspondait à ce que je voudrais soumettre, j'ai dit : "Sauvegarde ça comme un skill appelé 'pr-description'. Chaque fois que je demande une description de PR, suis exactement cette approche."

Maintenant, après avoir commité du code, je déclenche le skill. Il lit le diff, le croise avec le contexte projet, et génère une description de PR dans mon format préféré. La sortie est systématiquement meilleure que ce que j'écrirais manuellement — parce qu'il n'oublie jamais d'inclure les notes de test ou les points de suivi, et il a toujours le contexte projet complet à disposition.

Le skill qui m'a sauvé pendant les astreintes : investigation de SEV.

Celui-ci m'a surpris par sa puissance. J'ai créé un skill qui, étant donné une branche de release ou un timestamp de déploiement, fait ce qui suit :

1. Récupère le git log pour cette période
2. Identifie tous les commits inclus dans la release
3. Les croise avec le contexte projet pour comprendre ce que chaque changement était censé faire
4. Génère une liste classée de "théories" — causes racines potentielles pour le problème qui a déclenché l'alerte

Lors d'un incident de production à 2h du matin le mois dernier, j'ai déclenché ce skill au lieu de défiler manuellement les logs de commits avec les yeux vitreux. En environ 40 secondes, il m'a donné trois théories classées par probabilité. La deuxième théorie était la bonne — une condition de concurrence dans le handler de webhook qu'on avait refactorisé la semaine précédente. Sans le skill, cette investigation m'aurait pris 20-30 minutes de revue manuelle des logs et de reconstruction mentale du contexte. À 2h du matin. À moitié endormi.

Découpage de PR — le skill dont je ne savais pas que j'avais besoin :

Les grosses PRs tuent la revue de code. Tout ingénieur expérimenté sait qu'une PR de 500 lignes reçoit une meilleure attention en revue quand elle est découpée en trois PRs ciblées de 150-200 lignes chacune. Mais concrètement, découper un gros diff en morceaux logiques et indépendamment revuables ? C'est un travail fastidieux.

J'ai construit un skill qui analyse un gros diff et suggère comment le découper. Il considère :

• Les regroupements logiques (tous les changements de migration de base de données ensemble, tous les changements d'endpoints API ensemble)
• L'ordre des dépendances (quels changements doivent atterrir en premier)
• Ma préférence personnelle pour la taille des PR (j'aime 200-300 lignes max)

Le skill ne se contente pas de suggérer le découpage — il génère les commandes git pour créer chaque PR avec les bons commits. Je revois le découpage proposé, j'ajuste si besoin, et j'exécute. Ce qui prenait 30 minutes de travail manuel minutieux prend maintenant environ 3 minutes.

Automatisation des mises à jour de statut — celui que mon manager adore :

En fin de journée, je déclenche un skill qui passe en revue mon activité git, les issues que j'ai mises à jour, et le contexte projet, puis génère une mise à jour de statut dans le format utilisé par mon équipe. Trois bullet points : ce que j'ai fait aujourd'hui, les blocages éventuels, ce que je prévois pour demain. Mon manager a spécifiquement commenté que mes mises à jour sont "vraiment claires ces derniers temps." Il n'a aucune idée qu'une IA les rédige.

Voici l'insight crucial sur les skills que la plupart des gens ratent : les skills s'améliorent à mesure que ton contexte s'enrichit. Un skill de description de PR qui tourne avec une semaine de contexte produit un résultat correct. Le même skill avec six mois de contexte produit un résultat qui comprend véritablement l'historique et la trajectoire du projet. Le second cerveau et le système de skills se nourrissent mutuellement dans un cercle vertueux.

La partie sur le prompt engineering qui est en grande partie fausse

Je dois pousser contre quelque chose que l'espace productivité IA se trompe dangereusement. Tout le monde est obsédé par le prompt engineering. "Utilise ce template de prompt magique." "Voici le system prompt parfait pour la revue de code." "Ajoute ces 47 instructions pour de meilleurs résultats."

Écoute, la qualité des prompts compte. Je ne dis pas le contraire. Mais l'obsession pour les prompts détourne du véritable goulot d'étranglement : la qualité du contexte.

Un prompt médiocre avec un excellent contexte produit un excellent résultat. Un prompt parfait sans contexte produit du générique sans intérêt. J'ai testé ça de manière extensive. Mon skill de description de PR utilise un prompt remarquablement simple — en gros "rédige une description de PR pour ce diff en utilisant le contexte projet." Pas d'instructions élaborées, pas de directives de jeu de rôle, pas d'exemples multi-shot. Le résultat est excellent parce que le contexte est excellent.

Réfléchis-y à travers le prisme de l'onboarding d'un ingénieur junior. Si tu embauchais quelqu'un de nouveau et qu'il demandait : "Tu peux m'expliquer l'architecture du projet, les objectifs du sprint en cours, les décisions récentes, et pourquoi on a choisi ces technologies spécifiques ?" — tu passerais une heure à le mettre à niveau. Mais après cet investissement ponctuel, il serait capable de rédiger des descriptions de PR, des mises à jour de statut et de la documentation compétentes par lui-même. Pas parce que tu lui as appris comment écrire — parce que tu lui as donné le contexte pour bien écrire.

Ton second cerveau IA fonctionne de la même façon. L'investissement ponctuel, c'est construire le contexte. Après ça, c'est juste 30 secondes de maintenance. Les prompts sont quasiment sans importance parce que la partie difficile — avoir une connaissance profonde, actuelle et spécifique du projet — est déjà gérée.

Ce recadrage a changé ma façon d'aborder chaque workflow IA. Au lieu de passer du temps à élaborer des prompts sophistiqués, je passe du temps à gérer le contexte. Au lieu de chercher les instructions parfaites, je m'assure que la base de connaissances est à jour. Les retours sont incomparablement meilleurs.

Mais je vais être honnête sur un point — il y a un piège dans toute cette approche que j'ai survolé jusqu'ici.

Ce que j'ai mal fait et ce qui me frustre encore

Le fichier de contexte peut te mentir. Si tu mets à jour ton contexte après une session où tu as exploré une approche mais que tu l'as finalement abandonnée, tu peux accidentellement enregistrer cette approche abandonnée comme une décision. J'ai vu Claude Code générer des descriptions de PR faisant référence à des choix architecturaux que j'avais envisagés mais pas implémentés. La solution, c'est de relire les mises à jour de contexte avant de les accepter, ce que je zappe parfois quand je suis pressé. La discipline compte ici.

Les skills ne se gèrent pas tout seuls. Mon skill de description de PR a été modifié sept fois depuis que je l'ai créé. À chaque fois, j'ai remarqué un pattern dans la sortie qui ne me plaisait pas — trop verbeux, notes de couverture de test manquantes, mauvais ton pour les PRs internes vs. open-source. Construire le skill initial prend une session. Le raffiner pour correspondre à tes standards demande une itération continue. Pas un gros effort, mais plus que zéro.

Ça ne marche que si tu l'utilises de manière régulière. Je suis parti deux semaines en vacances et je suis revenu à un fichier de contexte périmé. La première description de PR qu'il a générée après mon retour était basée sur des objectifs de sprint obsolètes et des éléments de travail terminés. Il m'a fallu environ 10 minutes pour mettre à jour le contexte et tout remettre à niveau. Pas terrible, mais ça m'a rappelé que le système a besoin d'être alimenté régulièrement.

L'adoption par l'équipe est plus difficile que l'adoption personnelle. J'ai essayé de faire maintenir des fichiers de contexte partagés par mon équipe. Les résultats sont mitigés. Les gens qui prennent déjà des notes s'adaptent vite. Les gens qui ne prennent pas de notes voient ça comme de la charge supplémentaire, même quand ce n'est que 30 secondes. Je travaille encore dessus — peut-être que ça doit être plus automatisé, peut-être que ça doit être présenté différemment. Question ouverte.

Le problème le plus dur que je n'ai pas encore résolu : le contexte à travers plusieurs projets. Mon second cerveau fonctionne magnifiquement au sein d'un seul projet. Mais je travaille sur trois projets simultanément, et le contexte est cloisonné. Quand je bascule entre les projets, chacun a un excellent contexte local — mais les connaissances inter-projets (comme les bibliothèques partagées ou les patterns d'infrastructure) ne se transfèrent pas. J'ai des idées pour résoudre ça avec un fichier de contexte global, mais je ne l'ai pas encore construit.

Ce sont de vraies limitations. Je les mentionne parce que chaque retour d'outil que je lis en ligne fait tout paraître parfait, et ce n'est pas utile. Ce système a des aspérités. La proposition de valeur fondamentale — un contexte persistant qui élimine les explications répétées et permet une automatisation puissante — est authentique et significative. Mais il faut l'entretenir pour qu'il reste utile.

Ce qui a vraiment changé dans mon workflow d'ingénierie

Les chiffres aident. Voici ce que j'ai mesuré sur quatre mois d'utilisation régulière :

Descriptions de PR : Le temps moyen de rédaction est passé de 8 minutes à moins d'1 minute. La qualité — mesurée par le nombre de questions de clarification des relecteurs — s'est améliorée d'environ 60 %. Les relecteurs posent moins de questions parce que les descriptions générées par l'IA incluent le pourquoi derrière les changements, pas juste le quoi.

Mises à jour de statut : De 5 minutes quotidiennes à environ 30 secondes (déclencher le skill, scanner la sortie, envoyer). Sur un mois, ça représente environ 2 heures récupérées. Pas un game-changer en soi, mais ça élimine une tâche que je redoutais activement.

Investigation d'incident : Mon skill de SEV a été déclenché huit fois. Le temps moyen jusqu'à la première théorie est passé de 25 minutes d'investigation manuelle à environ 90 secondes. Trois de ces huit fois, la première théorie était correcte. Les cinq autres fois, les théories générées ont au moins significativement réduit l'espace de recherche.

Documentation : Je documente maintenant des décisions architecturales que je n'aurais pas pris la peine de rédiger avant. Le second cerveau les capture automatiquement pendant les sessions de travail, et un rapide "génère un ADR pour la décision de cache qu'on a prise aujourd'hui" produit un brouillon en 15 secondes. La documentation de mon projet est passée de clairsemée à complète sans que j'aie réellement écrit de la documentation.

Économie de temps totale estimée : 4-6 heures par semaine. Pas grâce à des moments spectaculaires individuels, mais grâce à des centaines de petits points de friction éliminés. La mort par mille coupures, inversée.

Les économies ne sont pas qu'une question de temps, cependant. Il y a une réduction de la charge cognitive qui est plus difficile à quantifier mais tout aussi importante. Je ne porte plus le poids mental de "je dois penser à documenter pourquoi on a choisi Redis" ou "je devrais rédiger les conclusions de l'incident avant d'oublier les détails." Le système capture tout au fur et à mesure. Mon cerveau est libéré pour le travail qui nécessite réellement un jugement humain — les décisions d'architecture, la revue de code, la résolution de problèmes.

C'est ça le vrai déverrouillage, je pense. Pas juste une rédaction plus rapide, mais moins de charge mentale liée à la rédaction que je devrais faire mais que je ne fais pas.

Le virage qui arrive et que la plupart des ingénieurs vont rater

Voici ma prédiction, et je veux bien avoir tort sur le calendrier mais pas sur la direction : d'ici deux ans, les ingénieurs qui maintiennent des systèmes de contexte augmentés par l'IA auront un avantage de productivité mesurable sur ceux qui ne le font pas. Pas parce qu'ils sont de meilleurs ingénieurs, mais parce qu'ils ont éliminé toute une catégorie de charge cognitive.

Les ingénieurs qui rejettent ça comme "juste du hype IA" sont les mêmes qui ont rejeté le contrôle de version, le CI/CD et la conteneurisation. Chacune de ces technologies a éliminé une catégorie de travail que les ingénieurs faisaient manuellement. La gestion du contexte est la suivante.

La partie intéressante, ce n'est pas l'automatisation en elle-même — c'est ce qu'elle te libère pour faire. Quand tu ne dépenses plus d'énergie mentale sur les descriptions de PR, les mises à jour de statut et la documentation, cette énergie va quelque part. Dans mon cas, elle est allée vers une revue de code plus approfondie, des discussions d'architecture plus réfléchies, et — ironiquement — une meilleure rédaction quand l'écriture comptait vraiment (comme ce post).

Mon défi pour toi est spécifique : choisis un projet sur lequel tu travailles activement. Passe 10 minutes aujourd'hui à créer un fichier de contexte. Puis engage-toi à faire la mise à jour de 30 secondes en fin de session pendant deux semaines. Ne construis pas de skills encore. N'optimise rien. Accumule juste du contexte.

Au bout de deux semaines, demande à Claude Code de rédiger une description de PR pour ton prochain changement. Compare-la avec ce que tu aurais écrit manuellement.

Cette comparaison va te dire tout ce que tu as besoin de savoir sur la valeur de cette approche. Et je parie — en me basant sur ce qui s'est passé pour moi et chaque ingénieur à qui j'ai montré ça — que tu ne reviendras pas en arrière.

La question n'est pas de savoir si l'IA va gérer la communication en ingénierie. C'est de savoir si tu vas construire le système de contexte qui la rend réellement bonne, ou si tu vas continuer à coller des diffs dans des chatbots en te demandant pourquoi le résultat sonne creux.

Ton second cerveau attend d'être construit. Il n'a besoin que de 30 secondes par jour.

Travaillons ensemble

Tu cherches à construire des systèmes IA, automatiser des workflows, ou faire monter en charge ton infrastructure tech ? Ce serait un plaisir de t'aider.

• Fiverr (builds personnalisés & intégrations) : fiverr.com/s/EgxYmWD
• Portfolio : mejba.me
• Ramlit Limited (solutions entreprise) : ramlit.com
• ColorPark (design & branding) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io