L’IA code, l’humain sature : le nouveau mur du software engineering.

+70% de code push en prod avec l’IA, quelles conclusions?

Au cours du mois dernier notre team à push +70% du code avec l’IA, c’est factuel et c’est un marqueur car c’est la 1ère fois qu’on utilise l’IA à ce niveau.

Le gain de productivité… est absorbé ailleurs.

Oui l’IA nous rend plus productifs c’est indéniable, il n’y a qu’a observer le changelog d’Anthropic 😅, tous les jours ils shippent une feature “game changer”, une manière de montrer qu’ils pratiquent le dogfooding à fond.

L’IA est simplement un accélérateur, nous lui confions aucune decision et nous lui faisons nullement confiance au risque d’introduire des bugs aux conséquences catastrophiques comme celui-ci ou bien de celui-ci.

Le bottleneck est humain et l’impact est cognitif.

Certaines fonctionnalités qui nous prenaient deux semaines à développer sont désormais développées en une semaine 💥.

Cette accélération de production a déplacé le gain de temps vers de la review, de la QA, plus de coordination et une pression sur les PMs pour fournir des specifications de plus en plus rapidement…

Si on considère qu’un.e Dev qui vibe code, avec Claude Code ou Codex, gagne au minimum 25% de productivité, alors si vous êtes 4 devs dans votre équipe, vous passez virtuellement à 5 devs avec l’impact que cela peut avoir.

Le bottleneck n’est plus la production de code mais l’organisation, quand la production s’accélère, le reste du système doit suivre sinon les gains de productivité s’évaporent.

Alors nous sommes passés d’une utilisation ponctuelle de l’IA à une utilisation quasi industrielle.

Comment Scale ?

👀 Le Code Review

Les demandes de code review sont de plus en plus fréquentes. Et cette étape a toujours été un goulot d’étranglement dans les équipes de développement.

C’est logique : c’est la dernière étape avant la mise en production 🚀.

🛩️ Un peu comme les contrôles de sécurité avant d’embarquer dans un avion.

🧵Quelques pistes qui peuvent aider :

• S’appuyer sur l’IA pour reviewer une première fois le code produit. Cela permet d’attraper rapidement les problèmes évidents, de pré-mâcher le travail des reviewers humains. Ce système nous a permis d’économiser 33 heures sur une période d’observation de 5 semaines.
• S’autoriser à merger des PRs sans reviews humaines. Inutile de defocus toute une équipe pour relire un changement mineur ou sur lequel le design est déjà validé, les commentaires de notre outil de code review sont suffisants. J’ai monitoré ce process dans notre équipe et j’ai observé un gain d’une heure par PR.
• Créer un Design document avant de coder. Si l’architecture et les choix techniques ont été discutés en amont, la code review devient presque une formalité : on vérifie simplement que le plan est respecté et que rien n’a été oublié. Tu peux en savoir plus dans cet article que j’ai écrit sur le sujet.
• Avoir des règles d’architecture claires et documentées. Les agents IA qui génèrent le code pourront s’appuyer dessus pour produire du code cohérent dès le départ.
• Faire des sessions de Pair review, certaines PRs sont complexes à appréhender et vont créer beaucoup d’aller-retour, le meilleur moyen d’éviter cela et de faire une session de Pair-review

Avec la hausse de production de code, cette étape devient encore plus cruciale et si tu veux aller plus loin sur ce sujet j’ai donné une conférence sur ce thème il y a quelques années.

🥼 La phase de QA

Dans notre équipe, la phase de review signifie que le code est prêt à être review par les devs et testable fonctionnellement. Nous avons volontairement fusionné les étapes de code review et de QA pour réduire la feedback loop et éviter que les tickets stagnent d’une colonne à l’autre.

Les développeurs sont les premiers QA. Ils testent leurs développements de deux manières via des tests automatisés mais aussi via des tests fonctionnels dans un environnement dédié. Le temps économisé permet aux Devs de passer plus de temps dans la phase de QA.

Selon la taille de la feature, nous mettons en place un “battle test” : une liste de scénarios à tester de manière asynchrone, partagée entre les membres de l’équipe pour couvrir différents cas d’usage.

L’IA peut également aider à automatiser certains contrôles. Par exemple, nos API peuvent être testées à l’aide de collections Postman générées automatiquement par l’IA : “Génère moi une collection postman pour tester le flow API suivant…”.

De même, nous donnons des scénarios de tests à l’IA qui les jouera avec le MCP Playwright : ”Rends toi sur l’url <environnement>, clique sur le bouton…”

Cela accélère la création et l’exécution des tests.

Aujourd’hui les llms sont suffisament avancés pour comprendre nos intentions, il y a 2 ans, il fallait être prompt engineer, aujourd’hui tu peux prompter en verlan c’est suffisant 🙃.

📚 La documentation

Nous nous appuyons sur l’IA pour générer de la documentation, des diagrammes de séquence, d’UML, d’architecture…

⚠️ Attention au dosage, l’IA est très bavarde, il faut absolument relire ce qu’elle produit et surtout garder la documentation agréable à lire et lisible.

💥 Si tu génères 1 doc avec de l’IA et que tes pairs ont besoin de l’IA pour résumer cette documentation, tu risques de passer à côté d’éléments essentiels et de perdre ton esprit critique.

🐛 You build it, you run it!

Lorsqu’un client nous remonte une anomalie ou que nous apercevons d’une anomalie, nous demandons à l’IA d’analyser la demande, les logs puis de regarder dans la codebase afin d’expliquer d’où peut venir le problème et les différentes pistes à creuser.

🕵Le gain de temps sur l’investigation est colossal, si t’as fixé des bugs tu sais aussi bien que moi que le plus long dans un bug c’est de comprendre la root cause.

À partir de l’analyse nous sommes en mesure de fixer ou d’expliquer que le problème se trouve entre la chaise et le clavier 😅.

💡Aujourd’hui c’est nous qui faisons la démarche d’interroger l’IA, avec un peu de configuration il est possible que l’IA prenne la requête elle-même.

⚡️ D’une discussion Slack à la mise en Production quasiment sans intervention humaine

Dans l’ancien monde : une personne soumet une suggestion sur slack, nous créons le ticket dans le backlog, nous priorisons la demande en fin de sprint. Cette demande ne verra peut-être jamais le jour au regard des autres priorités et la disponibilité de l’équipe de développement.

Aujourd’hui : une personne soumet une suggestion sur Slack :

1. Je crée le ticket via un agent directement depuis Slack, le ticket est donc spécifié depuis la discussion.
2. Je demande à Claude Code de prendre le ticket et d’ouvrir une PR.
3. La PR est ouverte puis reviewée par l’outil de code review. Si les tests sont au vert, je merge.

🤖 L’IA partout…

Si l’impact de l’IA dans le software engineering est surtout sur les Devs, son utilisation à grandement changé mon quotidien.

À chaque fois que j’effectue une tâche, si elle est chronophage ou répétitive, je me demande si l’IA peux effectuer cette tâche.

Au final j’ai intégré l’IA dans mon quotidien pour :

• Créer mes notes de Kick-off hebdomadaire, un agent viens regarder mon board et liste les tickets et objectifs en cours. Je viens simplement ajouter 2,3 informations auxquelles l’IA n’a pas accès (congés, communication internes, rappel des priorités…)
• Créer les post-mortem, je décris ce qu’il s’est passé au cours d’un incident et l’IA reformule en mettant le contenu au bon endroit du template que nous utilisons.
• Analyser les alertes, l’IA me fournis un récapitulatif des alertes que nous avons eu sur une période donnée et me donne des insights, cela m’aide à prioriser.
• Review les tickets que nous avons crées et regarder si ils sont complets et respecte notre nomenclature.
• Demander à un agent de me faire un récapitulatif d’un thread de 150 messages ou m’aider à retrouver une information perdue dans un flood de channel slack.
• Challenger les decisions et choix d’architectures.
• and so on…

Le vrai sujet, ce n’est plus la vitesse de production de code, c’est la solidité de ton organisation.

On arrive à un paradoxe : on est obligés d’utiliser l’IA… pour réussir à suivre la cadence de l’IA. Si tu boostes ta capacité de delivery sans t’adapter, tu ne gagnes pas de temps, tu crées juste un embouteillage géant.

Reste à savoir si l’humain est prêt à suivre la cadence ❓

Moi c’est Smaïne Milianni, j’aime bien l’Engineering et l’Humain, tu peux me retrouver par mes contributions par ici.