L’ingénierie à l’ère des LLM

• Article qui synthétise un an et demi de réflexion chez Reindeer sur la manière de construire des produits et des organisations de développement à l’ère des LLM, avec une intuition de départ : le contexte humain (human context) est la ressource la plus rare
• La production de contenu a explosé, mais la vitesse de consommation humaine n’a pas bougé ; cet écart devient le nouveau goulot d’étranglement — il faut bloquer le cercle vicieux où le slop nourrit le slop (slop feeds slop)
• Les décisions structurelles comme la modélisation ou la conception d’API restent du domaine humain, et il faut quelqu’un capable de dire « non » aux sorties produites par les LLM
• On ne peut pas battre les LLM avec la seule revue de code, il faut donc mettre en place des couches de défense automatiques et fondées sur la discipline, comme les linters, LLM judges et petites PR
• La compétence centrale d’un développeur n’est plus la profondeur de savoir technique, mais le context switching et la taille de sa propre fenêtre de contexte ; ceux qui s’adaptent deviennent hyperproductifs, ceux qui n’y arrivent pas sont un net negative pour l’équipe

---

Le contexte humain est une ressource rare

• Une constante qui n’a pas changé en 25 ans dans l’industrie : la ressource la plus coûteuse est le contexte humain ; comme les LLM, les humains ont une fenêtre de contexte limitée et un masque d’attention
• Le changement actuel, c’est que du slop généré par les LLM arrive de partout — le rapport entre vitesse de production et vitesse de consommation humaine devient le nouveau goulot d’étranglement
• Le problème, c’est que le slop nourrit le slop
  • Des commentaires de code gonflés par les LLM, des descriptions de PR interminables, une documentation qui déroule l’historique au lieu d’aller droit au résultat
  • Le LLM suivant lit tout cela, remplit son contexte de bruit, puis continue de la même façon
• Le contenu textuel dans l’organisation doit être compressé et ne contenir que ce qui n’est pas déjà clair dans le code et son comportement

Les domaines où l’humain ne peut pas être remplacé

• La modélisation est un travail humain
  • Traduire un CUJ (Critical User Journey) en flux d’API, décider de ce qu’est chaque composant, de ses responsabilités et de ses frontières
  • Comme les LLM produisent du code très vite, une mauvaise modélisation se propage elle aussi très vite, créant des dépendances tordues impossibles à corriger après coup
  • Plus le coût d’exécution baisse, plus le poids des décisions humaines sur la structure augmente dans la valeur finale
  • La modélisation reflète la vérité réelle de l’organisation et doit rester vivante, accessible en un seul endroit
• Définir une API exige une discipline humaine stricte
  • Les LLM ont tendance à ajouter sans cesse des champs pratiques pour une tâche donnée, alors que chacun de ces champs salit l’API de façon permanente
  • Une API est un contrat public (public contract), pas un scratch pad — il faut un humain pour dire « non »

Une défense à grande échelle contre le slop

• Il est impossible de battre les LLM avec des revues de code humaines — cela ne passe pas à l’échelle et finit par mener à une situation où tout le monde approuve les yeux fermés
• Chez Reindeer, la convergence s’est faite vers des couches d’application automatique
  • Linters : règles logiques absolues, comme les dépendances interdites entre services ou les frontières d’architecture
  • LLM judges : pour les éléments difficiles à coder mais que le modèle peut inspecter, par exemple les contrats implicites
• En revanche, dès qu’on touche à une API ou qu’un changement de modélisation intervient, une vraie revue humaine est indispensable
• Au quotidien, la règle est : « ne vous jetez pas du slop les uns aux autres »
  • Petites PR, et stacked PR si nécessaire
  • Il faut résister à la tentation d’envoyer une PR de 2 000 lignes de slop et à la probabilité que le reviewer l’approuve les yeux fermés
  • La PR est l’unité de base de l’attention — si elle dépasse la fenêtre de contexte humaine, elle sera approuvée, mais pas lue

Padded rooms — des zones où laisser les LLM en liberté

• Une fois cette structure en place, on peut identifier des zones où les LLM peuvent agir librement, les « padded rooms » (zones tampon)
  • Elles n’affectent pas la modélisation et n’ont pas de dépendances de long terme
  • Même si du slop y apparaît, il peut être remplacé facilement et ne se propage pas à toute la codebase
  • Cela peut représenter la majorité du code de l’entreprise, mais ce code n’est pas load bearing
• C’est aussi là que se trouve la réponse à la personnalisation client
  • La personnalisation doit vivre à 100 % dans les padded rooms
  • Dès qu’elle fuit dans le cœur, le cœur se fissure et chaque nouveau client ajoute du risque
  • Les padded rooms sont l’infrastructure qui permet de dire rapidement « oui » aux clients sans payer le prix architectural

L’inversion économique de la dette technique

• La séparation entre zones porteuses et padded rooms change aussi la relation à la dette technique
• Avant : quand on découvrait un problème de modélisation pendant le développement, on le repoussait à plus tard, car le coût d’une réécriture était élevé ; au milieu d’un gros projet, on absorbait la dette
• Aujourd’hui : le coût de réécriture tend vers zéro
  • Le vrai investissement n’a jamais été la frappe au clavier, mais la modélisation
  • Jeter, corriger la modélisation, puis réécrire ne coûte pas cher
  • Reporter devient en revanche très coûteux — tous les LLM qui passent sur du mauvais code l’adoptent, le slop nourrit le slop, et une erreur de modélisation non corrigée immédiatement devient en peu de temps une dette plusieurs fois plus complexe

Le PM de cette époque

• Le rôle du PM évolue — il doit collaborer étroitement avec les responsables de la modélisation pour garantir qu’un CUJ ne se casse pas lors de sa traduction en API et en composants
• Si le PM et le modélisateur ne sont pas synchronisés :
  • soit on obtient un produit techniquement fonctionnel mais qui ne satisfait pas le CUJ,
  • soit un CUJ propre mais impossible à construire de manière raisonnable
• Chez Reindeer, les PM construisent eux-mêmes directement des MVP dans un dépôt séparé
  • En partant du principe que ce code ne touchera jamais la production
  • Cela leur donne la liberté d’avancer vite avec les LLM et de montrer quelque chose aux clients
  • Ce qui réussit ou doit être présenté à des clients passe ensuite par le processus formel de modélisation et de développement
  • Cela permet de monter rapidement une démo et de valider avec des clients avant d’investir dans le cœur — un équilibre entre la vitesse de test des idées et la rigueur chirurgicale sur ce qui entre dans le produit

Une infrastructure qui libère de la boucle

• La différence entre tenir un agent par la main et lancer plusieurs tâches en parallèle avant d’aller dormir, c’est une bonne reward function
  • Sans elle, le LLM part dans un voyage dont il ne revient pas
  • Avec elle, il peut juger lui-même quand il est proche ou loin du but
• En développement, une bonne reward function se traduit par de bons tests
  • Y compris des tests E2E pour la plateforme
  • Ils éloignent les LLM de la mauvaise habitude de dépendre de mocks qui ne testent rien
  • Des Evals pour les sorties basées sur les LLM
  • Des LLM judges avec un contexte propre assurent la boucle de revue automatique — afin que le juge ne tombe pas dans les mêmes hallucinations que l’agent qui a écrit le code
• À l’échelle de l’organisation, cette infrastructure doit être partagée
  • Reindeer dispose d’un dépôt central de skill marketplace classé par catégories, qui contient toutes les compétences internes
  • Il est pris en charge automatiquement dans tous les harnais comme Claude Code, Codex, et même dans pi.dev pour les profils les plus unhinged
  • Un nouveau développeur récupère immédiatement toutes les compétences de l’organisation, y compris celles qui effectuent l’onboarding et le setup

Le développeur du futur

• La compétence décisive du développeur de cette époque n’est pas la connaissance profonde, mais le context switching et la taille de sa propre fenêtre de contexte / masque d’attention
  • Gagnera celui qui sait maintenir un grand contexte, passer d’une tâche à l’autre sans perdre le focus et piloter plusieurs agents en parallèle
  • La profondeur technique pointue devient moins importante, car les LLM la compensent
• Les compétences complémentaires sont la capacité de modélisation, une bonne compréhension de l’architecture système et l’intuition de ce qu’il faut surveiller au stade de la conception
• Ce nouveau monde divise les développeurs en deux catégories
  • Ceux qui s’adaptent deviennent hyperproductifs (super-productive)
  • Ceux qui ne s’adaptent pas ne sont pas neutres, mais un net negative pour l’équipe
  • Les LLM sont un multiplicateur (multiplier) — ils apportent de la productivité à ceux qui savent les manier, et des dégâts à haute vitesse à ceux qui ne savent pas
  • En termes de rémunération, le salaire du deuxième type de développeur tend vers zéro — il n’y aura pas de travail pour lui
• On peut accomplir beaucoup plus avec beaucoup moins de monde, mais la croissance devient très difficile et il faut être extrêmement sélectif

À propos du coût des tokens

• Question récurrente : que se passe-t-il si le coût des tokens est multiplié par 5 à 10 ?
• Avec le temps, cette inquiétude paraît irréaliste
  • L’IA suit une loi de Moore accélérée, et la qualité par dollar continue de progresser
  • Il existe suffisamment de modèles open pour empêcher la formation d’un cartel
• Si les tokens sont bon marché, c’est parce que si Claudex devenait soudainement déraisonnablement cher, tout le monde migrerait vers le Qwen d’un neocloud quelconque