Patterns for Reducing Friction in AI-Assisted Development

Quand je fais du pair programming avec un collègue, certains rituels se mettent en place naturellement. Je lui fais visiter le codebase avant de lui demander de contribuer. On sketche au tableau blanc avant de plonger dans l'implémentation. J'explique nos conventions, nos contraintes, le raisonnement derrière les décisions passées. On relit le travail face à nos standards d'équipe.

Avec les assistants de code IA, j'ai remarqué que la plupart des devs — moi y compris au début — sautent toutes ces étapes. On tape un prompt, on attend un output aligné, et on s'étonne du résultat.

La promesse était séduisante : développement dramatiquement plus rapide, génération instantanée, un pair programmer infatigable disponible 24/7. L'adoption a été massive — la majorité des devs pro utilisent désormais Copilot, Cursor ou Claude au quotidien.

Pourtant, une frustration cohérente émerge. Le temps gagné par le code généré est souvent consommé par l'effort de correction. J'ai vécu — et entendu d'autres décrire — un cycle que j'appelle la « Frustration Loop » : générer, relire, ça ne fit pas, régénérer avec des corrections, relire, et finalement soit accepter un output lourdement modifié, soit abandonner.

Mon hypothèse : ce n'est pas un échec de capacité — les modèles modernes sont remarquablement sophistiqués. La friction vient de notre manière de collaborer avec eux.

La Frustration Loop

Un dev demande à l'IA de créer un service. L'IA répond rapidement avec du code syntaxiquement correct, qui suit des patterns courants de son training data. Mais elle utilise Express.js là où le projet utilise Fastify. Elle place des fichiers dans utils/ alors que la convention est lib/services/. Elle génère du code orienté classes alors que le codebase est fonctionnel. Chaque correction nécessite un autre cycle de génération, et avec chaque cycle, l'avantage de temps s'érode.

Ce cycle persiste parce que les assistants IA, par défaut, puisent dans leur training data — une agrégation de patterns issus de millions de repos. Ils produisent ce qu'on pourrait appeler « la moyenne d'Internet » plutôt que du code qui fit l'architecture et les conventions d'une équipe spécifique.

Le shift Tool → Teammate

Un reframe utile : arrêter de traiter l'IA comme un outil et la traiter comme un teammate — une distinction qui sonne sémantique mais a des implications pratiques.

AI assistants are like junior developers with infinite energy but zero context.

Ils peuvent travailler plus vite que n'importe quel humain, ne se fatiguent jamais, ne se plaignent jamais. Mais ils ne savent rien sur les conventions, contraintes ou historique d'un projet spécifique. Sans le même échafaudage qu'une équipe fournirait à un collaborateur humain, ils retombent sur des patterns génériques.

Pair programming humain	Équivalent collaboration IA
« Laisse-moi te montrer les docs d'abord »	Partager le contexte architectural avant de demander du code
« Sketchons ça au tableau »	Discussion design structurée avant l'implémentation
« Voilà comment fonctionnent les reviews ici »	Encoder les standards dans des prompts ou commandes réutilisables
« Je mets à jour le doc avec la décision »	Persister les décisions pour qu'elles survivent aux sessions
« Qu'est-ce que ça nous a appris ? »	Capturer systématiquement ce qui a marché ou non

L'IA est rapide — incroyablement rapide. Mais elle a besoin des mêmes choses qu'un pair humain : onboarding (contexte avant contribution), whiteboarding (design avant implémentation), guardrails (standards appliqués de manière cohérente).

Cinq patterns pour la collaboration IA

Knowledge Priming — parallèle humain : l'onboarding d'un nouveau. Avant de demander à l'IA de générer du code, partager un contexte curé : stack avec versions, structure des répertoires, conventions de nommage, exemples de patterns existants. C'est essentiellement du RAG manuel — remplir le contexte avec des informations spécifiques au projet qui supplantent le training data générique.

Design-First Collaboration — parallèle humain : whiteboarding avant de coder. Plutôt que de demander à l'IA de produire immédiatement du code, parcourir des niveaux progressifs de design : capabilities, components, interactions, contracts, et seulement après, implementation.

Encoding Team Standards — parallèle humain : ce qu'un senior fait instinctivement. Chaque équipe a des seniors qui savent quand un code est juste — ils repèrent les dérives architecturales, les gaps de sécurité, les violations de convention. Cette intuition est précieuse mais vit dans leurs têtes. Elle ne scale pas. La solution est de rendre explicite la connaissance tacite, de la stocker dans des prompts, des skills, ou des règles partagées.

Repenser les métriques

Métrique trompeuse	Alternative plus utile
Time to first output	First-pass acceptance rate
Lines of code generated	Iteration cycles per task
Tasks completed	Post-merge rework required
Vitesse de génération	Charge de revue vs écriture manuelle

Pour les équipes qui suivent DORA, le first-pass acceptance rate sert d'indicateur leading pour le change failure rate. Un code qui nécessite une correction lourde avant d'être utilisable est un signal de désalignement, et un code désaligné qui ship devient de la dette technique.