Comment Oxide utilise les LLM

• Les grands modèles de langage (LLM) transforment en profondeur la manière de travailler, et Oxide a clairement défini comment les utiliser en interne
  • Oxide est une startup d’infrastructure informatique à la demande qui conçoit du matériel et des logiciels intégrés pour les centres de données on-premise
• Oxide propose comme principe clé de l’utilisation des LLM un équilibre entre responsabilité, rigueur, empathie, travail d’équipe et urgence
• Ils sont utiles pour la synthèse/compréhension de documents, la revue de code, le débogage, etc., mais le jugement et la responsabilité humains restent essentiels pour la rédaction ou l’écriture de code
• Les résultats générés par un LLM doivent toujours s’inscrire dans un cadre où l’humain relit et assume la responsabilité
• Oxide encourage l’utilisation des LLM, à condition d’un principe de responsabilité envers le produit, les clients et les collègues

---

Critères de valeur de l’usage des LLM

• Oxide évalue l’usage des LLM selon les valeurs clés de l’organisation
  • Responsabilité (Responsibility) : les LLM sont des outils, et la responsabilité du résultat incombe entièrement aux humains
  • Rigueur (Rigor) : utilisés avec prudence, ils peuvent raffiner finement le raisonnement, mais une utilisation imprudente peut en dégrader la qualité
  • Empathie (Empathy) : il faut garder à l’esprit que l’émetteur et le destinataire du langage sont des humains, et préserver une communication centrée sur l’humain
  • Travail d’équipe (Teamwork) : il faut éviter que l’usage des LLM ne nuise à la confiance entre collègues et que la transparence sur cet usage ne donne l’impression d’une esquive de responsabilité
  • Urgence (Urgency) : même si la vitesse peut augmenter, il ne faut pas sacrifier les autres valeurs

Les différents usages des LLM

LLMs as Readers

• Les LLM sont très bons pour la synthèse de documents et les réponses aux questions, et permettent de comprendre rapidement un volume important de documents
• Toutefois, il faut garantir la confidentialité des données et configurer les modèles pour que les documents téléchargés ne soient pas utilisés pour entraîner le modèle
• Ils sont utiles comme outil d’aide à la compréhension documentaire, mais ne doivent pas remplacer la lecture directe quand elle est nécessaire

LLMs as Editors

• Ils sont efficaces pour améliorer la structure et le style d’un document terminé, en particulier dans les phases finales
• Cependant, les LLM tendent à adopter une attitude excessivement positive, ce qui peut réduire l’analyse critique
• Lorsqu’ils sont utilisés en phase de brouillon, il existe un risque de perdre la voix propre de l’auteur

LLMs as Writers

• Les textes générés par les LLM sont souvent banals ou affichent clairement des traces de génération automatique
• Un texte auto-généré peut nuire à l’authenticité de la pensée et à la confiance du lecteur
• Le lecteur part du principe que l’auteur comprend le contenu, mais un texte généré par LLM remet en cause cette hypothèse
• Oxide part du principe que tous ses membres savent écrire et n’utilise pas les LLM comme principal auteur
• Ils peuvent néanmoins être utilisés de manière limitée comme outil d’aide, par exemple pour structurer des idées

LLMs as Code Reviewers

• Les LLM sont utiles pour la détection de certains types de problèmes de code, mais ne peuvent pas remplacer la revue humaine
• Leurs suggestions peuvent être illogiques ou manquer le contexte, donc il faut les utiliser uniquement comme outil d’appoint

LLMs as Debuggers

• Les LLM peuvent être utilisés comme rôle de « canard en caoutchouc » pour provoquer des idées de débogage
• Leur capacité réelle de résolution de problèmes est limitée, mais ils sont utiles comme stimulant pour imaginer de nouvelles approches

LLMs as Programmers

• Les LLM sont très performants pour la génération de code, et adaptés à l’écriture de code expérimentale et d’appoint
• Plus le code se rapproche du code produit, plus la validation et la responsabilité sont importantes
• Le code écrit par un LLM doit faire l’objet d’une auto-revue (self-review) par l’auteur, avec vérification obligatoire avant la revue entre pairs
• Pendant la revue de code, il est interdit de réagir par une régénération complète, car une vérification répétée devient impossible
• Même lors de la génération de code, il faut préserver responsabilité, rigueur, empathie et travail d’équipe

Opérations et directives

• Les détails techniques et les directives internes sur l’usage des LLM sont documentés dans des documents internes sur GitHub
• Oxide encourage l’utilisation des LLM, sous le principe d’un usage responsable
  • La conscience de la responsabilité vis-à-vis de la qualité du produit, de la confiance des clients et de la collaboration entre collègues est la priorité absolue

[GN⁺]

Réactions sur Hacker News

• Le billet de Bryan présente une vision équilibrée et réaliste
  Je pense que si le RFD n’aborde pas ce point, c’est parce qu’Oxide n’embauche pas d’ingénieurs juniors
  Bryan est un ingénieur qui travaille depuis plus de 30 ans sur des logiciels et du matériel complexes, et il a déjà mené à bien un programme « vraiment difficile » : un OS
  Sa manière d’utiliser les LLM est très différente de celle d’un ingénieur junior en 2025
  Les juniors d’aujourd’hui ont probablement rarement codé sans l’aide d’un LLM

  • À une époque, dans mon entreprise, on passait des mois à ne construire que des modèles d’ingestion de données
    C’était si ennuyeux qu’il était même difficile de venir au bureau, alors qu’aujourd’hui un LLM pourrait sans doute faire ça en quelques minutes
    Avec le recul, le temps qu’on y a consacré paraît presque insensé
  • Je me souviens que, lors de mon premier cours de webdesign, le professeur nous a enseigné pendant tout un semestre les « principes fondamentaux » de HTML, CSS et JS avec Notepad
    Ce n’est qu’ensuite qu’il a présenté Dreamweaver, et la productivité a été multipliée par dix
  • La tension entre « artisanat vs pragmatisme » autour des LLM est intéressante
    Dans des domaines où les résultats sont nets, comme la recherche en sécurité, les LLM excellent, mais ils sont faibles sur les problèmes qui demandent un jugement subtil
    L’idéal est donc de confier au LLM les parties répétitives et systématiques, et de laisser à l’humain celles qui demandent du discernement
  • Je programme depuis plus de 20 ans, et j’avais une résistance invisible à l’idée d’utiliser des LLM
    Mais j’ai fini par accepter que c’est « une nouvelle manière de programmer », et le reconnaître m’a presque donné l’impression de rajeunir
  • J’ai trouvé amusant qu’un tiret cadratin (—) apparaisse juste après l’expression « les gens qui reconnaissent la patte des LLM »
    En ce moment, c’est un peu agaçant que l’usage du tiret cadratin fasse immédiatement soupçonner un texte écrit par une IA

• En lisant le RFD d’Oxide, j’ai approuvé la plupart des points, mais je ne suis pas d’accord avec l’idée que « les LLM écrivent bien du code dès le départ »
  Les LLM sont bons pour vaincre le « syndrome de la page blanche », mais je pense que le code réellement déployable reste assez éloigné de ce qu’ils produisent
  C’est peut-être une « illusion de progrès »

  • L’écriture relève de l’expression personnelle, alors que le code est un outil de résolution de problèmes
    Les LLM ont appris de « bonnes solutions » souvent présentes dans les jeux de données, ce qui les rend efficaces pour résoudre des problèmes
    À l’inverse, dans l’expression humaine, la diversité est essentielle, et une expression moyenne devient vite inintéressante
    Au final, les LLM pourraient limiter la capacité à résoudre des problèmes encore non résolus
    Si la qualité du code est faible, c’est à mon avis à cause des limites de la context window
  • Une prose banale est mauvaise, mais un code banal est au contraire une bonne chose
  • La réponse « essaye un autre modèle » ressemble désormais au « No True Scotsman » du monde des LLM
    La génération à l’échelle d’une fonction est acceptable, mais si on leur confie une fonctionnalité entière, la structure et les interfaces deviennent n’importe quoi
    Pour filer la métaphore de l’écriture, le bon niveau consiste à donner la première et la dernière phrase d’un paragraphe et à les laisser remplir le reste
  • C’est un peu comme le fait de repérer facilement les erreurs dans des actualités sur un domaine qu’on connaît bien, alors qu’on croit sans réserve celles portant sur un domaine qu’on ne connaît pas
    Les programmeurs savent juger la qualité du code, mais pas forcément celle d’un texte
  • La qualité des LLM varie selon le modèle
    Beaucoup gardent une mauvaise impression parce qu’ils ont utilisé des modèles anciens ou low cost

• L’affirmation selon laquelle « les LLM détectent bien les textes produits par des LLM » me laisse dubitatif
  Je me demande si cela a été démontré par des données

  • Bryan d’Oxide l’a expliqué lui-même
    Leur processus de recrutement étant centré sur l’écriture, ils ont vu exploser récemment le nombre de candidatures rédigées avec des LLM
    Ils le signalent déjà dans le RFD 0003 et sur la page carrières, mais cela continue
    Des cas concrets sont aussi abordés dans un épisode de podcast
    Les LLM ne détectent pas tous les textes générés par IA, mais ils peuvent être utiles comme outil d’aide à la détection dans les cas suspects
  • Une idée proposée pour détecter un texte produit par LLM consiste à donner la moitié du texte à un LLM, puis à lui faire prédire l’autre moitié afin de comparer les probabilités des n-tokens
    Je ne l’ai pas testée, mais c’est une approche intéressante
  • Comme la détection devient difficile selon le degré d’intervention du LLM (rédaction complète, résumé, correction, etc.),
    je pense qu’une détection parfaite est impossible avec les technologies actuelles

• En cas d’usage de code généré par LLM, la responsabilité incombe à l’ingénieur
  Un code qu’on n’a pas relu soi-même ne peut pas être soumis à review
  Ma procédure est la suivante :

  1. fournir le code concerné → 2) expliquer l’objectif → 3) revoir la conception → 4) générer le code → 5) tester et corriger → 6) relire l’intégralité du code et le modifier manuellement
     La dernière étape est la plus difficile, et émotionnellement on a envie de la sauter
     Cette méthode permet de conserver une réflexion au niveau architecture tout en réduisant le travail répétitif
     Mais les LLM étant non déterministes, ils ne sont pas comparables à des outils prévisibles comme un compilateur
  • En pratique, l’étape 6 prend la majeure partie du temps
    Si le code ne fonctionne pas correctement, il faut encore plus de corrections
    Du coup, je ne suis pas certain que les LLM fassent réellement gagner du temps
  • Il serait bon d’ajouter, avant l’étape 4, une étape où l’on fait d’abord générer les tests, puis où l’on cherche à faire échouer le code avant de le faire passer
  • Si, au lieu de corriger manuellement, on laisse le LLM piloter toutes les modifications, on peut maintenir une cohérence de connaissance au sein de la session
  • Mais cela donne aussi l’impression d’abîmer la fierté et le sentiment de propriété de l’ingénieur
    Il est difficile de s’investir émotionnellement dans le polissage d’un code produit par une machine

• Il est étrange qu’on ne mentionne pas le risque de violation du droit d’auteur dans le code généré par LLM
  Du code GitHub peut être recopié tel quel, ce qui est un sujet important pour une entreprise open source

  • Si les productions d’un LLM ne sont pas protégeables par le droit d’auteur, le statut juridique du code sous licence Copyleft devient flou
    Il faut une contribution humaine suffisante pour qu’il y ait droit d’auteur, mais ce seuil reste imprécis
  • Je me demande si ce type de sujet a déjà été tranché par les tribunaux
  • Je me demande aussi si les LLM récents posent encore vraiment ce problème, ou s’ils le font plus souvent que les humains

• Le document est bien construit, mais la partie qui dit qu’« utiliser un LLM comme aide à la lecture ne pose pas de problème » me semble contradictoire
  Si c’est parfait, il n’y a plus de différence avec l’original ; si ce n’est pas parfait, il y a un risque de contresens
  Je vois souvent des cas où le LLM ne lit pas réellement la documentation et infère seulement à partir de la table des matières
  Il y a un risque de créer une couche de traduction entre le contenu et le lecteur

  • Je pense que le RFD parlait non pas de la « lecture », mais des attentes sociales liées à « l’écriture »
  • Si on lui a demandé de comparer trois livres techniques et qu’il a donné un mauvais résultat, c’est un échec d’usage de l’outil
    Il faut fournir directement l’intégralité du texte dans la context window
    Cela dit, trois livres entiers peuvent dépasser les limites d’un LLM

• Je suis d’accord avec l’idée que « les textes écrits par des LLM dégradent jusqu’à l’authenticité de la pensée »
  Un texte écrit directement par un humain a de la valeur, mais un texte écrit par un LLM ressemble à une copie diluée de cette valeur
  La remarque disant qu’on préférerait lire le prompt est particulièrement marquante

  • L’art humain exprime l’intériorité d’un individu, alors que le LLM produit une moyenne collective
    Les idées intéressantes et originales se trouvent justement en dehors de cette moyenne
    Je comprends qu’un non-natif utilise un LLM pour mieux exprimer sa pensée, comme en traduction,
    mais le destinataire peut alors se demander si cette expression reflète vraiment la pensée personnelle de l’auteur
  • Cela me fait penser à « Programming as Theory Building » de Naur
    Les commentaires sont une tentative d’exprimer le contexte théorique qui n’apparaît pas dans le code
    Un LLM ne peut pas posséder une telle « théorie », et ne peut donc pas produire de commentaires vraiment précieux
  • Je n’aime pas le « style IA » caractéristique des LLM, mais beaucoup de gens ne le remarquent pas
    Par exemple, la plupart des posts sur /r/SaaS semblaient écrits par des LLM,
    tout en suscitant efficacement la réaction des lecteurs grâce à un storytelling émotionnel
    J’utilise moi aussi les LLM pour rédiger de la documentation ou des benchmarks
    Ils peuvent aussi aider les non-natifs à écrire des documents techniques, mais la qualité varie beaucoup
    Au final, les LLM deviennent de plus en plus utiles pour les écrits destinés à transmettre de l’information
  • Cette envie de « lire le prompt » m’arrive aussi face à un titre de presse
    Ce n’est pas seulement ce qui a été écrit qui m’intéresse, mais pourquoi cela a été écrit
  • Les LLM prédisent bien les phrases moyennes, mais ratent presque toujours les phrases créatives
    Cela me console de me dire que, même si mes idées ne sont pas géniales, elles restent statistiquement rares

• Je pense que les textes écrits avec un LLM ne valent pas la peine d’être lus
  J’apprécie qu’Oxide ait fixé un principe ferme consistant à ne pas utiliser de LLM pour les productions non liées au code
  En revue de code aussi, le code généré doit d’abord être relu par son auteur
  Reste à voir si cette culture tiendra dans la pratique, mais l’orientation semble judicieuse

• Il existe une forte perception que les LLM ont été entraînés sur des données pillées,
  et je pense qu’il aurait fallu tenir compte de cette perception publique
  Que ce soit un problème éthique ou un risque de marque, c’est clairement un facteur important aujourd’hui

  • Je vois ce document non comme un texte grand public, mais comme une documentation technique interne
    Son but n’est pas de prendre position sur l’éthique, mais de proposer des lignes directrices techniques
  • J’ai l’impression que ce que le texte appelle « effondrement de la confiance » traite justement ce sujet sous une autre formulation
    Les textes produits par LLM perdent leur authenticité, et le lecteur peut avoir l’impression que même la pensée a été automatisée
    Au final, cela peut nuire à la confiance mutuelle

• La phrase disant que « l’écriture est un travail intellectuel plus important que la lecture » est intéressante
  Mais pour le code, j’ai plutôt l’impression que c’est l’inverse

  • Un mauvais texte ne sert à rien, mais un mauvais code, tant qu’il fonctionne, peut quand même faire fermer un ticket Jira
    C’est pour cela qu’il y a bien plus de mauvais code
    À l’inverse, un bon code a une vraie valeur pédagogique et demande, comme un bon texte, de l’insight
  • Citation de la loi de Kernighan
    « Déboguer est deux fois plus difficile qu’écrire le code.
    Donc si vous écrivez le code de la manière la plus intelligente possible, vous ne pourrez plus le déboguer. »
    Lien laws-of-software.com