Le code produit par un LLM pourra entrer chez KDE, mais son auteur devra le comprendre et l’assumer intégralement. Le projet veut éviter que les mainteneurs deviennent le service après-vente de contributions générées à la hâte.
Cette ligne apparaît dans un projet de recommandations soumis à la discussion par Nate Graham, responsable du projet. Le document reste provisoire et doit encore évoluer avant d’intégrer la documentation officielle de KDE.
KDE encadre l’IA autour d’un principe simple
La règle centrale tient en trois mots : « Don’t be lazy », autrement dit ne soyez pas paresseux. Un LLM ne doit remplacer ni le jugement du contributeur, ni les échanges humains, ni l’apprentissage nécessaire pour intervenir sur le projet.
KDE estime que personne ne devrait pouvoir détecter l’usage d’un LLM dans une contribution. Il ne s’agit pas de le dissimuler, mais d’obtenir un résultat impossible à distinguer de ce que l’auteur aurait produit seul. Les propositions révélant un usage manifestement négligent pourront être ignorées ou fermées.
Le développeur doit rester dans la boucle
Le texte retient le principe du « human in the loop » : le contributeur doit prendre des décisions et modifier le résultat, au-delà d’une simple requête envoyée au modèle. KDE demande explicitement de ne pas devenir un « meat proxy », soit un intermédiaire humain transmettant mécaniquement la sortie d’une IA.
Les changements issus du « vibe coding » sont donc exclus lorsque leur auteur ne les comprend pas ou serait incapable de les réaliser lui-même. Même refus pour les brouillons et preuves de concept jetables, proposés dans l’espoir que les mainteneurs les corrigent et les finalisent.
Signaler l’emploi d’un LLM ne pourra pas servir à excuser des erreurs ou une contribution bâclée. Le projet veut également bannir les mentions du type « Assisted-by: [nom du LLM] » dans les commits, considérées comme de la publicité gratuite pour le fournisseur concerné.
Des textes rédigés par les contributeurs
Pour la production de texte, la consigne proposée est plus restrictive : en règle générale, KDE demande de ne pas utiliser de LLM. Le document vise notamment les formulations longues, impersonnelles ou inutilement corporate, qui alourdissent la lecture et les échanges.
Les contributeurs devront organiser eux-mêmes leurs idées, rédiger leurs messages de commit et leurs descriptions de demandes de fusion. Copier une réponse générée à une question ou à un commentaire sera également proscrit : son auteur devra comprendre l’échange et répondre directement.
Une exception est prévue pour la traduction automatique vers l’anglais d’un texte rédigé dans la langue maternelle du contributeur. Cette opération devra conserver le style et le ton d’origine.
Vérification obligatoire pour le débogage et la recherche
Un LLM pourra servir à rechercher un bug ou à déboguer, à condition de vérifier ses conclusions. La même exigence s’appliquera aux recherches et aux réponses obtenues en remplacement de la lecture directe d’une documentation d’API.
Cette approche place KDE entre le rejet total de l’IA adopté par certains projets comme GIMP et son intégration plus large observée chez Nobara Linux ou Omarchy. Elle se rapproche davantage de la position du noyau Linux, qui accepte le code assisté ou généré sous réserve d’une revue humaine et d’une demande de fusion démontrant sa compréhension.
Le projet répond surtout à un problème de charge : une contribution facile à générer peut demander beaucoup plus de temps à examiner, corriger ou rejeter. Godot avait déjà été confronté à cet afflux de code de faible qualité. En rendant l’auteur pleinement responsable du résultat, KDE tente de conserver les gains ponctuels des LLM sans transférer leur coût aux mainteneurs.
Source : KDE Invent
