Perspectives sur le développement IA après deux mois dans une Big Tech

Contexte

Tout est parti de plusieurs entretiens individuels avec mon lead technique. Il s'intéressait à ma façon d'utiliser les outils d'IA, de construire mes propres Harnesses et de structurer mon workflow d'AI Coding. Principalement parce que je livre rapidement et efficacement les exigences, au point d'être déjà le référent principal sur certains projets. J'ai donc saisi cette occasion pour mettre à plat mon workflow IA quotidien. Actuellement, je fais surtout du développement d'Agents dans mon équipe, tout en maintenant la logique métier backend existante.

J'avais déjà partagé des workflows similaires sur Xiaohongshu. À l'époque, le constat était que GPT-5.4 et Opus 4.6 parvenaient déjà à mener à bien leurs tâches si on leur fournissait un contexte précis et des contraintes raisonnables. L'essor du Harness Engineering a fait comprendre à tout le monde une chose : on peut mieux maîtriser des modèles puissants en y ajoutant des contraintes.

Par exemple, des Skills comme Superpowers proposent une implémentation relativement lourde, principalement axée sur les Specs et le TDD, pour aider à organiser et faire avancer les tâches plus facilement.

Mais cette approche a ses limites. Le ressenti le plus évident : la consommation de Tokens explose. Des Skills comme Superpowers embarquent de nombreux Workflows destinés à contraindre la prochaine action du modèle. Même si, d'un point de vue global, une étape n'est plus nécessaire — par exemple, quand le contexte est suffisant pour passer directement à l'implémentation —, le modèle risque de continuer à dérouler le processus prédéfini.

Avec la sortie des nouveaux modèles, j'ai vu beaucoup de développeurs expliquer qu'ils n'utilisaient quasiment plus ces Skills très lourds. La raison principale : depuis que les capacités des modèles se sont renforcées, certaines contraintes et processus que nous jugions utiles deviennent du bruit pour eux. Par exemple, lors de la sortie d'Astra, OpenAI a publié un article de blog expliquant précisément comment nettoyer les Skills et les prompts système superflus pour améliorer l'expérience d'utilisation.

Cet article s'appuie donc sur ma pratique de ces derniers mois pour partager les méthodes qui fonctionnent vraiment pour moi aujourd'hui, et expliquer comment mieux exploiter les différents Agents pour gagner en efficacité au quotidien.

1. Les Skills et Prompts que j'utilise le plus

Ma répartition actuelle des outils :

Pour l'implémentation, j'utilise principalement Codex + GPT-5.6 Sol, et Astra pour la planification. Avant la sortie d'Astra, je confiais ce travail de planification à GPT-5.6 Sol Max.

Pour les besoins simples, j'utilise pi + DeepSeek V4 Flash ; la revue contradictoire des solutions et la Code Review sont gérées par Claude 5 Fable. Sur mes projets personnels, je passe aussi par la version web de GPT-6 Pro pour concevoir les solutions principales.

Mes Skills les plus utilisés

1. think : le Skill de tw93, utilisé surtout pour aligner les solutions et faire du brainstorming.
2. grill me / grill with docs : sert principalement à clarifier les exigences. À force de questions, il précise les objectifs, les contraintes et les compromis, puis les consigne dans un ADR ou un CONTEXT.md selon les besoins du processus de développement. Il m'aide à déterrer les points oubliés lors des premiers alignements.
3. implement : utilisé conjointement avec grill, issu de la suite de Skills de Matt Pocock, pour implémenter des plans ou des Issues clairement définis.
4. ponytail : permet de nettoyer le sur-engineering de l'IA pour faciliter la Review. Je m'en sers souvent car GPT-5.6 Sol a tendance à en faire trop.
5. handoff : synthétise le contexte actuel dans des fichiers pour reprendre facilement une tâche dans une nouvelle session. Je l'utilise généralement pour passer le relais de Codex à Claude Code ou à l'agent pi.
6. check : dédié à la revue de code, je m'en sers surtout lors de la soumission des MRs.
7. Les Skills issus de mon travail et de mes projets perso : principalement des SOP de processus réutilisables, comme les tests end-to-end. Mon conseil : au quotidien, si vous répétez un processus plus de trois fois, demandez à Codex de le transformer en Skill pour le réutiliser directement ensuite.

Mes Prompts les plus utilisés

Je rédige rarement de longs blocs de Prompt moi-même aujourd'hui. Quand c'est nécessaire, je laisse généralement Codex s'en charger. Par exemple, après plusieurs allers-retours, si je veux transmettre le contexte actuel à GPT Pro pour la conception de la solution, je demande d'abord à Codex de générer un Prompt de handoff complet.

En dehors de cela, j'utilise très fréquemment les types de Prompts ultra-courts suivants.

Ils produisent parfois l'effet d'une formule magique où « une phrase vaut mille mots ». Je les vois comme des « raccourcis de pensée » pour le modèle.

Ce ne sont pas des incantations, mais des méthodologies hautement standardisées dans les connaissances humaines. Pendant son entraînement, le modèle a ingurgité une quantité astronomique d'articles, de code, de documents de conception et de discussions sur le sujet. Inutile donc de rédiger à la main des centaines de lignes de Workflow : il suffit de lui indiquer quelle méthode de réflexion adopter. Voici quelques prompts qui se sont révélés redoutables à l'usage :

• Premiers principes (First Principles) : Ne continue pas à optimiser la solution existante, repense fondamentalement la façon dont ce problème devrait être résolu. Par exemple, si une interface est lente, vous pouvez dire :

Ne poursuis pas la conception en te basant sur la solution établie consistant à "ajouter un cache Redis". Analyse selon les premiers principes pourquoi cette interface est lente, et quelle est la solution strictement nécessaire.

L'attention du modèle passe alors de « comment concevoir le Redis ? » à :

Le goulot d'étranglement se situe-t-il dans le SQL, le réseau, la sérialisation, la contention de verrous ou les calculs répétés ? Si l'ajout d'un index SQL suffit, pourquoi introduire Redis ?

Ce type de Prompt est idéal lorsque vous soupçonnez que « la question de départ est peut-être mal posée ».

• Revue contradictoire (Adversarial Review) : Ne cherche pas à justifier ma solution, essaie de prouver qu'elle est fausse.

La formulation classique serait :

Aide-moi à vérifier s'il y a des problèmes dans cette solution technique.

On peut la remplacer par :

Mène une revue contradictoire de cette solution, en cherchant en priorité des contre-exemples capables de renverser les hypothèses centrales.

Si votre solution consiste à « introduire des verrous distribués pour éviter les requêtes en double », le modèle ne se contentera plus de vous expliquer comment configurer le timeout du verrou, mais commencera à demander :

Les requêtes en double ont-elles vraiment besoin d'exclusion mutuelle ? L'idempotence de l'interface ne suffirait-elle pas ? Que se passe-t-il si le service de verrouillage plante ? Et si le verrou expire avant la fin de l'exécution métier ? N'avons-nous pas introduit un nouveau point de défaillance distribué pour résoudre un problème local ?

Ce type de Prompt est particulièrement adapté aux revues de solutions et aux Code Reviews.

• Expériences d'ablation : Ce n'est pas parce que le système s'améliore que chaque élément ajouté est utile.

Imaginons que vous ayez appliqué trois optimisations d'un coup :

Après l'ajout d'index, d'un cache Redis et de requêtes par lots, la latence de l'interface est passée de 800ms à 100ms.

À ce stade, vous pouvez simplement demander :

Conçois des expériences d'ablation pour ces trois optimisations afin de déterminer d'où proviennent réellement les gains.

Le modèle va créer des groupes de contrôle autour de différentes combinaisons, en partant de la Baseline, pour comparer : index seuls, index + cache, index + cache + requêtes par lots, etc.

Il pourrait finalement découvrir que :

L'ajout des index seuls faisait déjà chuter la latence de 800ms à 120ms, les deux autres solutions complexes n'apportant que 20ms supplémentaires.

Vous savez ainsi beaucoup plus clairement quel code mérite d'être conservé et quelle complexité est probablement superflue.

• Rasoir d'Ockham : À résultats équivalents, privilégie les solutions reposant sur le moins d'hypothèses et la plus faible complexité.

Par exemple, si l'Agent conçoit une solution de ce genre :

Kafka + Redis + Verrou distribué + Machine à états + Compensation planifiée.

Vous pouvez ajouter une phrase :

Réexamine cette conception à travers le prisme du rasoir d'Ockham, en supprimant tous les mécanismes non essentiels tout en répondant aux exigences.

Bien souvent, il conclura que :

Le scénario actuel n'implique que des écritures sur une seule base de données : une transaction couplée à un index unique suffit amplement.

Cette phrase est extrêmement utile avec les Coding Agents actuels, car les modèles ont vite fait de sur-concevoir par souci d'« exhaustivité ».

• Forte cohésion, faible couplage : Réexamine les responsabilités et les limites du code.

Si vous remarquez qu'un OrderService atteint déjà 2000 lignes, vous pouvez demander :

Passe en revue les limites de responsabilité d'OrderService selon les principes de forte cohésion et de faible couplage, sans diviser juste pour le plaisir de diviser.

Le modèle va généralement commencer à vérifier :

Pourquoi le service de commande gère-t-il simultanément les stocks, les coupons, les SMS, les paiements et les rapports ? Quelle logique appartient réellement au domaine de la commande, et laquelle devrait être déléguée à d'autres modules via des interfaces stables ?

Cela déclenche bien plus qu'un simple « découpage de fichiers » : toute une série de réflexions sur la modularisation, le masquage de l'information, le sens des dépendances et la répartition des responsabilités.

C'est pourquoi je n'écris presque plus :

Étape 1 analyser les exigences, Étape 2 vérifier les hypothèses, Étape 3 chercher des alternatives, Étape 4...

Le modèle a déjà assimilé de nombreuses méthodologies éprouvées. Je préfère lui dire directement :

Réanalyse la situation selon les premiers principes et mène une revue contradictoire de la solution actuelle ; les mécanismes centraux doivent être validés par des expériences d'ablation ; la solution doit suivre le rasoir d'Ockham, et le code maintenir une forte cohésion avec un faible couplage.

Derrière cette trentaine de mots, cinq actions cognitives distinctes sont en réalité spécifiées :

Redéfinir le problème → Attaquer les hypothèses → Vérifier les contributions → Supprimer la complexité → Organiser les limites du système.

Voilà, selon moi, comment le Prompt Engineering évolue à l'ère des nouveaux modèles : plutôt que de dicter au modèle un processus de réflexion figé de bout en bout, mieux vaut utiliser des méthodologies précises pour lui indiquer « comment penser », puis ajouter uniquement les contraintes véritablement nécessaires à la tâche en cours.

2. Mon workflow de développement quotidien

Quand je reçois une exigence, je commence généralement par fournir le contexte pertinent à l'Agent (PRD, comptes rendus de réunion, historiques de discussion, retours utilisateurs), puis j'utilise grill pour aligner les besoins avec lui.

Ces documents forment rarement une exigence complète et cohérente. Le PRD n'est peut-être pas à jour, certaines restrictions ont pu être ajoutées en réunion, les priorités ajustées dans les discussions. Ma propre compréhension des besoins comporte aussi des implicites.

Je laisse l'Agent analyser ces éléments en les croisant avec le Wiki de l'équipe et le code existant, puis clarifier les objectifs, les limites et les compromis impactant l'implémentation grâce à une série de questions. Certaines trouvent une réponse immédiate, d'autres nécessitent de retourner voir le Product Manager ou les collègues concernés.

Je respecte ici une règle simple : dès que les questions restantes ne risquent plus de modifier significativement la direction de l'implémentation ni les critères de recette, on peut lancer le développement.

Je ne lui demande pas de planifier tous les détails d'implémentation à l'avance, sinon l'alignement des exigences devient lui-même un processus extrêmement lourd.

Les conclusions de cet alignement sont consignées dans un Spec ou un CONTEXT.md, qui documente principalement le problème à résoudre, le périmètre, les décisions clés et les critères de recette. Cela permet aussi aux Agents chargés ensuite de l'implémentation et de la revue de partager le même contexte, sans avoir à relire toutes les conversations précédentes.

Une fois la solution arrêtée, je laisse l'Agent principal décider de la marche à suivre selon la complexité de la tâche. Les exigences simples sont implémentées directement ; les plus complexes sont découpées en Issues aux limites claires, testables indépendamment. Seules les parties pouvant avancer de manière autonome sont confiées à des subagents pour un développement en parallèle dans différents worktrees, avant d'être intégrées par l'Agent principal.

L'Agent de code termine d'abord les tests. Quand il estime être prêt à livrer, je fais intervenir d'autres Agents pour une revue contradictoire croisée, selon la complexité de la tâche. Les problèmes détectés sont remontés en bloc à l'Agent de code principal (Codex), qui corrige et revérifie.

Avant ma propre Review, je lance également des tests end-to-end.

Je ne lis plus le code généré ligne par ligne : je me concentre sur les résultats des tests et la logique métier centrale. Un prérequis essentiel à cela : chaque MR doit avoir un périmètre suffisamment restreint, et les parcours métier complets doivent être validés progressivement au fil du développement.

Des MR réduits maintiennent les changements à analyser et à valider dans des proportions gérables ; les tests end-to-end permettent de vérifier si ces modifications tiennent la route une fois intégrées aux vrais processus métier. Lors de ma Review manuelle, je me concentre sur la validation de la logique métier et sur la capacité des tests existants à garantir cette livraison.

3. Comment mettre en place des tests end-to-end adaptés aux Agents

L'IA excelle déjà dans l'écriture de cas de test, générant souvent des centaines de lignes de tests pour un simple Bugfix (particulièrement 5.6 sol). Écrire plus de tests n'est généralement pas un problème en soi, mais après le déploiement et la mise en production, on tombe encore sur des erreurs inattendues.

Dans ma pratique, le problème central est le suivant : on ne fournit pas à l'Agent un environnement de test end-to-end qui lui donnerait l'occasion de détecter ces problèmes pendant les phases de codage et d'auto-test.

Si l'on parvient à construire un tel environnement, permettant à l'Agent d'exécuter facilement les tâches depuis le véritable point d'entrée de l'environnement de test jusqu'à la vérification des résultats attendus par l'utilisateur, on peut alors laisser le code écrit par l'IA tourner en production en toute confiance.

Concrètement, j'ai mis en place un environnement de test end-to-end dédié à notre activité. L'Agent peut facilement interroger les tables de la base de données, consulter les logs et se connecter aux machines pour diagnostiquer les problèmes.

Ce processus de construction revient essentiellement à laisser l'Agent extraire mes routines d'auto-test quotidiennes pour intégrer des outils et capacités disparates : ce qui peut devenir un outil est transformé en MCP ou en CLI ; les processus réutilisables sont convertis en Skills.

Cela demande effectivement un effort initial, mais ne craignez pas la charge de travail. Une fois en place, le développement s'accélère considérablement, les reprises et les incidents en production diminuent, et vous n'avez plus à stresser toute la journée en vous demandant si le code écrit par l'IA va provoquer une catastrophe.

Autour de ces tests end-to-end pensés pour les Agents, j'ai principalement travaillé sur quatre axes :

1. Familiariser l'Agent avec l'environnement : démarrage en un clic des environnements de test, création de données de test, clarification des versions actuelles, des comptes et des permissions, ainsi que des capacités de nettoyage et de réinitialisation.
2. Permettre à l'Agent d'opérer sur les systèmes métier : exécuter de vrais processus métier via des navigateurs, des API ou des CLI.
3. Faciliter l'interrogation des bases de données et des logs par l'Agent : confirmation des résultats de stockage via un MCP de base de données en lecture seule, localisation des problèmes via les Skills du système de logs et les requêtes de Traces.
4. Automatiser les processus fastidieux mais stables : scripter les opérations fiables, regrouper les points d'entrée et les méthodes de diagnostic dans des Skills, afin de réduire les interventions manuelles répétitives et les échanges superflus.

Sur cette base, voici quelques méthodes qui me semblent actuellement efficaces :

1. Automatisation navigateur : quand les systèmes métier nécessitent des interactions navigateur, je recommande le navigateur open source ego lite. Pratique et rapide. Couplé à l'agent pi + DeepSeek V4 Flash, les tests sont bouclés beaucoup plus vite, ce qui réduit le temps de test global.
2. Centraliser les opérations dans une CLI : intégrez les Skills réutilisables, les MCP configurés et les scripts rédigés dans une CLI de test unifiée, offrant des capacités de vérification d'environnement, de préparation de données, d'exécution de scénarios, d'interrogation de résultats et de nettoyage. Cela peut aussi devenir un outil d'efficacité interne. J'ai personnellement regroupé tout ça dans une CLI, ce qui facilite grandement le diagnostic en cas de problème.
3. Mettre les outils au service direct de la recette : les requêtes DB servent à confirmer un état, les logs et Traces à expliquer un échec, mais les résultats attendus doivent toujours découler des contrats métier. Ne laissez pas l'Agent supposer ce qui est correct simplement parce qu'il voit ce que le système a retourné. Avec une logique métier complexe, le système peut tout à fait renvoyer un résultat apparemment cohérent mais non conforme. Les outils nous aident à obtenir des preuves, pas à définir la bonne réponse à notre place.
4. Si le produit est lui-même un Agent, contrôlez aussi la qualité des réponses : si le produit testé est un Agent, outre le bon déroulement des processus métier, la qualité des réponses doit être évaluée. C'est ce qu'on appelle généralement l'Agent Eval, un sujet que je ne développerai pas ici.

4. Comment revoir le code écrit par l'IA

Les sections précédentes expliquaient comment amener l'IA à produire du code de qualité, mais au final, le développeur reste le responsable principal des exigences métier.

Sans Review, les gros systèmes dérapent vite.

Et personne n'a envie d'être réveillé en pleine nuit pour un On-call, pour découvrir que c'est du code généré par l'IA qui a mis le feu.

Concernant la Review, voici mes pratiques actuelles :

1. D'abord les critères de recette, ensuite les résultats des tests : je vérifie d'abord les critères fournis par l'Agent, puis je les compare aux résultats des tests end-to-end précédents pour m'assurer que tout est couvert et que rien n'a été oublié. Il ne s'agit pas seulement de compter les tests réussis, mais de vérifier s'ils valident bien ce qui compte vraiment pour cette exigence.
2. Suivre les parcours métier pour examiner l'implémentation, en concentrant l'énergie sur les zones à risque : je vérifie principalement les permissions, les changements d'état, la concurrence, les tentatives (retries), la cohérence des données, ainsi que les parties critiques comme les migrations et les rollbacks. Pour le CRUD classique et stable, j'y passe moins de temps — je ne regarde même plus certaines parties aujourd'hui.
3. Examiner spécifiquement les nouvelles abstractions et mécanismes : pour les ajouts architecturaux, je réutilise des concepts comme le rasoir d'Ockham pour demander à l'IA une seconde passe : sont-ils vraiment nécessaires ? Existe-t-il une implémentation plus simple ? A-t-on introduit trop de complexité pour un problème purement local ?
4. Envisager des Bots de Review dédiés si les MRs sont nombreux : si l'équipe génère beaucoup de MRs, il peut être pertinent de concevoir un Bot de Review dédié aux revues croisées. Contrairement à l'appel direct à l'agent pi / Claude Code pour une revue contradictoire évoqué plus haut, l'idée est de combiner les informations de modification Git avec des processus de revue prédéfinis, pour créer une capacité de revue reproductible dédiée aux MRs.

5. Quelques bilans et réflexions

Mon principal goulot d'étranglement actuel est la vitesse de Review.

Les Agents peuvent faire avancer plusieurs tâches de front, mais ma capacité à comprendre le métier, évaluer les solutions et valider les livrables n'augmente pas proportionnellement. Si vous vous contentez de le laisser écrire davantage, vous ne ferez qu'accumuler du code en attente de revue.

Mon prochain objectif est donc de faire en sorte que les problèmes récurrents soient détectés et corrigés avant même d'arriver entre mes mains.

Les anomalies détectables par vérification de typage, tests et assertions métier doivent autant que possible être traitées par l'Agent lui-même pendant le développement ; mon jugement doit se concentrer sur la bonne compréhension des exigences, la solidité de la logique métier clé et les risques non vérifiés subsistant dans la modification.

Des Bots de Review dédiés peuvent aider en ce sens, mais leur valeur se mesure à leur capacité à réduire les oublis de vrais problèmes et la charge manuelle, et non au simple nombre de commentaires qu'ils génèrent.

Cela rend aussi ma vision du Harness plus concrète : au-delà de fournir le bon contexte aux Agents, il faut leur offrir des environnements capables d'exécuter les tâches et des références pour en juger les résultats.

J'ai transformé les opérations répétitives de mes auto-tests quotidiens en CLIs, scripts et Skills, pour lui permettre d'exécuter les systèmes, de vérifier les résultats et de trouver lui-même les preuves d'échec. Ces capacités pourront être réutilisées pour des tâches similaires à l'avenir, et progressivement partagées avec d'autres collègues.

Parallèlement, ce workflow nécessite un écrémage régulier.

Certaines étapes compensent les lacunes d'une génération spécifique de modèles. Quand les modèles évoluent, l'utilité de ces étapes doit être réévaluée. Les tâches simples sont traitées directement, les complexes nécessitent planification, découpage et revue croisée. Par exemple, après les mises à jour d'Astra, j'ai supprimé certaines contraintes trop strictes dans AGENTS.md. Les modèles itèrent, nos workflows doivent suivre.

Bien sûr, les tests et la Review réduisent l'incertitude, mais l'humain doit toujours fournir les bons critères de recette. Même si le code et les tests concordent parfaitement, ils peuvent très bien s'être trompés ensemble sur les exigences. Les tests end-to-end ne couvrent que les comportements dans les environnements et scénarios sélectionnés ; le trafic, la concurrence et la distribution des données en production peuvent toujours réserver de mauvaises surprises.

En tant que développeur fraîchement arrivé dans le métier, j'espère encore acquérir des connaissances professionnelles pointues par la pratique. Cependant, l'IA réduit indéniablement certaines occasions de tomber soi-même dans les pièges. Des expériences précieuses, autrefois forgées en affrontant des problèmes et en enquêtant sur leurs causes, se résument parfois désormais à une réponse de l'IA :

"Je me suis trompé, je corrige immédiatement."

C'est pourquoi

je réserve désormais une partie de mon temps de développement quotidien à l'apprentissage et à la réflexion, tout en me demandant : quelles sont les compétences véritablement indispensables pour les développeurs à l'ère de l'IA ?

Cet article documente un ensemble de méthodes que j'ai progressivement explorées dans mon domaine lors de mes premiers mois. Son champ d'application et ses limites restent à affiner.

Chacun peut commencer par choisir un parcours d'auto-test habituel, essayer de le laisser exécuter seul par l'Agent, conserver les preuves, puis capitaliser sur les étapes qui fonctionnent.

Pour des raisons de confidentialité liées à mon entreprise, de nombreux détails ne peuvent figurer dans cet article. J'espère que ces réflexions ouvriront la voie à de riches échanges, et je serais ravi de découvrir vos bonnes pratiques de développement !