Ingénieur AI-native : pourquoi écrire plus de code ne te rend pas plus productif

L’IA génère plus de 75 % du nouveau code chez Google, et Mark Zuckerberg promet des agents au niveau “mid-level engineer” d’ici fin 2026 [1]. Alors pourquoi la plupart des équipes livrent-elles aujourd’hui plus de bugs, plus d’incidents et plus de dette technique qu’il y a deux ans ?

La réponse tient en une distinction que l’industrie brouille dangereusement : produire plus de code n’est pas produire plus de valeur. Et c’est là que se joue tout l’écart entre “ingénieur AI-native” et chaos à grande échelle.

Le coding n’a jamais été le goulot d’étranglement

On adore raconter que l’IA va transformer chaque dev en 10x developer. Sauf que le code n’a jamais représenté l’essentiel du métier.

Une étude Microsoft 2025 sur plus de 450 ingénieurs montre que les développeurs passent environ 14 % de leur temps à écrire du code [2]. Le reste ? Réunions, design, revue de code, collaboration. Si le coding pèse 15 % de ta journée, même un assistant qui double ta vitesse de frappe te rapporte moins de 15 % de productivité globale — et déplace surtout la pression vers la revue, les tests et l’intégration [2].

Shah Rahman, qui pilote l’itération ML autonome des Ads chez Meta, le dit autrement : le coding a toujours été 20 à 30 % du travail d’ingénierie, pas plus [1]. L’IA rend juste cette réalité plus visible, parce qu’elle produit du code à un débit inédit.

Real productivity gains come when engineers decide to make the leap from writing code to orchestrating it.

C’est ça, l’ingénieur AI-native : un orchestrateur, pas un sténographe d’agents.

Quand le code génère du code, le goulot devient la vérification

La recherche est têtue. Environ 45 % du code généré par IA contient des failles de sécurité, et une étude Stanford a montré que les développeurs assistés par IA écrivaient du code moins sûr — tout en étant plus confiants qu’il était sûr [1]. Pire : un essai contrôlé randomisé METR a trouvé que des développeurs open-source expérimentés étaient 19 % plus lents avec un assistant IA sur des bases de code familières [1].

RDEL confirme cette messy reality : reformuler un prompt de façon sémantiquement équivalente change le code généré dans 46 % des cas, et change sa correction dans 28 % des cas [2]. 80 % des développeurs utilisent des outils IA, mais seuls 29 % font confiance à la précision de la sortie [2].

Le verdict de Shah Rahman est limpide : le goulot s’est déplacé de façon permanente, de l’écriture du code à la preuve qu’il fonctionne. Son découpage cible du temps surprend tout le monde : 40 % à poser le contexte, 20 % à générer et itérer, 40 % à revoir et vérifier [1]. La génération est rapide ; la vérification devient le nouveau time sink.

La preuve par l’exemple : un agent trouve un bug vieux de 3 ans

Voilà à quoi ressemble l’orchestration bien faite. Lors d’un offsite à Lisbonne, l’équipe PostHog a pointé un agent sur son moteur de requêtes, lui a donné des requêtes lentes de production, un benchmark et un budget, puis l’a laissé tourner la nuit [3].

Au matin, l’agent avait trouvé une chose embarrassante : depuis presque trois ans, chaque requête avec filtre temporel n’utilisait pas correctement la clé primaire de ClickHouse. Un toTimeZone() ajouté en 2023 empêchait le planificateur de faire son travail. Le correctif a réduit de 62 % le nombre de granules scannés et accéléré la requête de 37 % en moyenne [3].

L’effet de second ordre est le plus intéressant : l’agent ne porte pas le biais de quelqu’un qui vit dans la base de code [3]. Le wrap toTimeZone() avait “toujours été là”. Du code qu’on ne voit plus. L’agent, lui, n’a aucun a priori et traite une expression de trois ans avec la même suspicion que la ligne écrite hier. Cette boucle — proposer, mesurer, garder ou jeter — c’est l’autoresearch packagé par Karpathy en mars 2026 [3]. Un harnais pas cher, qu’on peut “maltraiter”, pointé sur une métrique qu’on tolérait en silence.

La contrepartie : une nouvelle dette technique, plus rapide

Mais cette puissance a un prix, et il s’appelle dette technique d’un nouveau genre. Un agent ne se contente pas d’importer des packages : il lit des instructions de repo, suit des system prompts, choisit des outils, parle à des serveurs MCP, exécute des commandes shell. Chaque capacité est une dépendance de plus — et donc une surface d’attaque de plus [4].

Les chiffres font réfléchir. Sur 117 062 changements de dépendances étudiés par des chercheurs de Purdue, les agents IA ont sélectionné des versions vulnérables connues plus souvent que les humains (2,46 % contre 1,64 %), et leurs mauvais choix étaient plus durs à corriger [4]. Au global, le travail piloté par agents a produit un gain net de 98 vulnérabilités, là où le travail humain en retirait 1 316 [4].

Et la dette ne se cache plus seulement dans le code. Les prompts aussi sont de la dette technique : un CLAUDE.md, un AGENTS.md, des skills, des règles que personne ne teste, ne revoit ni n’élague — un plan de contrôle parallèle de la façon dont ton logiciel est écrit [4]. La règle de fond n’a pas changé : connaître sa surface, la garder petite, et la scorer en continu — parce que maintenant tout le monde le fait.

Ce qui sépare le 10x du “faster failure”

Le fil qui relie tout ça ? La valeur de l’IA vient de comment on la déploie, la mesure et l’encadre — pas de l’accès à l’outil. RDEL est sans appel : les leaders qui traitent l’adoption de l’IA comme une décision d’achat obtiennent des résultats de décision d’achat [2].

Concrètement, ça veut dire auditer les 86 % de la journée avant d’optimiser les 14 % [2]. Travailler en petites boucles avec des points de vérification, plutôt qu’en grands runs autonomes qui produisent du slop bon à jeter [1]. Et traiter chaque serveur MCP, chaque outil d’agent, chaque prompt comme une dépendance de production : versionnée, revue, supprimée quand elle ne sert plus [4].

L’IA n’élimine pas la discipline d’ingénierie. Elle augmente le prix de s’en passer.

Alors la vraie question n’est peut-être pas “combien de code ton équipe génère-t-elle ?”, mais : qui, chez toi, décide encore de ce qui mérite d’exister ?

Sources

Pour aller plus loin

The ACM Queue article on eight GenAI myths — l’étude derrière RDEL #146, pour creuser les huit mythes sur la productivité IA avec les co-auteurs du framework SPACE.
karpathy/autoresearch — le repo de Karpathy, assez petit et concret pour construire ta propre boucle d’autoresearch en une après-midi.
Prompts are technical debt too — Sean Goedecke explique pourquoi tes fichiers de contexte décaient silencieusement d’un modèle à l’autre.
AI code overload (New York Times) — l’article qui a nommé le phénomène : des équipes qui se noient sous leur propre code généré.

Cet article a été rédigé en m’appuyant sur une IA pour m’aider à synthétiser et structurer ma veille. Les idées, le choix des sources et la relecture restent les miens.

Cet article a été rédigé en m'appuyant sur une IA pour m'aider à synthétiser et structurer ma veille. Les idées, le choix des sources et la relecture restent les miens.