La newsletter The Pragmatic Engineer a organisé un concours d’essais auprès de ses lecteurs, et le texte gagnant, publié le 3 novembre, est un témoignage de première main sur ce à quoi ressemble le développement avec l’IA à pleine vitesse. Son auteur, Neil Kakkar, a neuf ans d’expérience, notamment chez Bloomberg et PostHog, et il est aujourd’hui le premier ingénieur de Tano, une startup d’une dizaine de personnes.

Les chiffres

Dans ses postes précédents, Kakkar mergeait de 8 à 20 pull requests par mois. Chez Tano, il en livre plus de 200, environ 11 fois sa production chez PostHog. Il fait état d’un taux de revert environ six fois plus faible, surtout parce que les problèmes sont corrigés par un correctif suivant (fix forward), et d’un délai médian de moins d’une heure entre l’ouverture d’une PR et son merge. L’équipe entière merge environ 30 PR par jour.

L’organisation

Tout repose sur Claude Code. Chaque ingénieur dispose d’un abonnement Claude Max 20x ; Kakkar estime que son usage coûterait plus de 8 000 $ par mois aux tarifs de l’API. Il travaille dans l’application de bureau de Claude Code avec son navigateur intégré plutôt qu’en ligne de commande, mène 3 à 5 tâches en parallèle et laisse les agents tourner une à deux heures par fonctionnalité, y compris leurs propres vérifications et captures d’écran. Chaque PR reçoit une review automatique d’un agent Claude Code dans GitHub Actions, avec un agent de review plus approfondi pour les changements risqués. Sur la plupart des PR, cet agent est le seul relecteur. Le contexte de chaque partie du produit est consigné dans des fichiers AGENTS.md pour que les agents puissent le trouver.

Ce qui a mal tourné

Il liste les ratés sans détour. Un agent a multiplié des montants par 100, ce qui est faux pour des devises comme le dinar bahreïni ; l’erreur a été repérée après le déploiement et corrigée dans l’heure. Une migration de base de données bloquante sur une grosse table a stoppé l’ingestion des données. Une autre migration sans garde-fous a payé certains créateurs deux fois. Ce type de règles figure désormais dans les instructions de l’agent de review.

Les coûts humains figurent aussi sur la liste : changements de contexte permanents, moins de personnes qui connaissent un morceau de code donné, un design d’apparence générique et des limites du forfait atteintes quand les agents tournent en boucle. La règle personnelle de Kakkar : s’arrêter à 18 h et laisser ses appareils professionnels au bureau.

La réserve de l’éditeur

Gergely Orosz, qui dirige la newsletter, ajoute qu’à l’échelle du secteur, le volume de PR a à peu près doublé depuis janvier, si bien que ce cas est très au-dessus de la moyenne, et que la vitesse seule ne prouve pas qu’un produit réussit. Les entreprises matures, estime-t-il, devraient faire évoluer leurs processus avec plus de prudence.

Ce que cela signifie si vous choisissez un agent de code

Le gain est venu du processus, pas seulement de l’outil. Un contexte mis par écrit, un relecteur automatique sur chaque PR et des règles tirées des incidents ont compté autant que le modèle.

Prévoyez les limites. Même le forfait Claude le plus élevé s’épuisait quand les agents travaillaient en boucle : vérifiez donc le quota avant de compter sur des exécutions de nuit. Si vous comparez les options, consultez Codex vs Claude Code et notre liste d’outils d’IA pour coder.