Vibe Coding : pourquoi Godot interdit l'IA non maîtrisée dans ses contributions

Le 1er juillet 2026, l'équipe du moteur de jeu open source Godot a annoncé une décision qui fait du bruit dans la communauté des développeurs : l'interdiction quasi-totale de l'usage de l'IA dans les contributions au projet. Une prise de position radicale, mais qui soulève des questions que tout développeur — qu'il travaille sur du PHP, du Symfony ou n'importe quel autre écosystème — devrait se poser.

Le problème du "Vibe Coding" en pratique

Le terme "vibe coding" désigne une pratique de plus en plus répandue : générer du code via un LLM (ChatGPT, Claude, Copilot...), le coller dans un projet, vérifier vaguement que ça compile ou que les tests passent, et soumettre une pull request. L'idée directrice ? "Ça a l'air de marcher, donc c'est bon."

Les mainteneurs de Godot décrivent une situation concrète qui illustre parfaitement le problème : une avalanche de pull requests d'apparence correcte, mais dont les auteurs sont incapables de répondre de manière substantielle aux retours de review. Quand un reviewer demande une explication sur un choix d'implémentation ou suggère une modification, le contributeur est dans l'incapacité de répondre — parce qu'il n'a, en réalité, pas compris ce qu'il a soumis.

La citation des mainteneurs est sans ambiguïté :

"L'IA ne peut pas prendre de responsabilité, et nous ne pouvons pas faire confiance aux gros utilisateurs d'IA pour comprendre leur code."

Cette phrase résume un problème structurel : le code généré par un LLM n'appartient intellectuellement à personne si personne ne l'a compris.

Ce que cela révèle sur la dette technique cachée

Dans un projet open source, la review de code n'est pas une formalité. Elle sert à s'assurer que :

• Le code est maintenable sur le long terme
• L'auteur pourra corriger les régressions qu'il introduit
• L'intention derrière chaque choix technique est documentée, au moins implicitement

Le vibe coding court-circuite entièrement ce processus. Un LLM peut produire du code syntaxiquement correct, qui passe les tests existants, mais qui introduit des edge cases non couverts, des abstractions inadaptées au contexte du projet, ou des dépendances inutiles. Si l'auteur ne comprend pas ce qu'il soumet, aucun de ces problèmes ne sera détecté avant qu'il ne soit trop tard.

Dans l'écosystème PHP/Symfony, le risque est identique. Imaginez une contribution générée par IA qui implémente une couche de cache avec une logique d'invalidation subtile mais incorrecte, ou qui utilise un pattern d'injection de dépendances incompatible avec la configuration du projet. Si le développeur qui l'a soumise ne peut pas expliquer son fonctionnement, le bug vivra en production jusqu'à ce qu'un autre développeur prenne le temps de comprendre — et de corriger — ce qu'il n'a pas écrit.

La règle d'or : comprendre chaque ligne, y compris celles qu'on n'a pas écrites

Cela ne signifie pas qu'il faut rejeter l'IA comme outil de développement. Les LLMs sont utiles pour accélérer l'écriture de code boilerplate, explorer des patterns inconnus, ou générer une première ébauche. Mais utiliser un outil ne dispense pas de comprendre ce qu'il produit.

Dans le cadre d'une contribution à un projet — qu'il soit open source ou interne à votre équipe — voici les questions minimales à pouvoir répondre avant de soumettre du code généré par IA :

• Pourquoi cette approche plutôt qu'une autre ? Si vous ne pouvez pas justifier le choix, c'est que vous n'avez pas évalué les alternatives.
• Quels sont les cas limites ? Un LLM génère souvent du code pour le cas nominal. Les edge cases, les erreurs réseau, les données malformées — avez-vous vérifié ?
• Est-ce cohérent avec l'architecture existante ? Le code généré respecte-t-il les conventions du projet, les patterns déjà en place, les contraintes non écrites ?
• Pouvez-vous le déboguer seul ? Si ce code produit une erreur en production à 3h du matin, êtes-vous en mesure de comprendre ce qui se passe ?

Si la réponse à l'une de ces questions est non, le code n'est pas prêt à être soumis.

Ce que la décision de Godot enseigne aux équipes

L'interdiction de Godot est une réponse pragmatique à un volume de contributions ingérables. Mais au-delà du cas open source, elle pointe vers une responsabilité qui s'applique à toutes les équipes de développement.

Pour les développeurs individuels, la règle est simple : l'IA est un outil d'accélération, pas un substitut à la compréhension. Traiter du code généré comme du code écrit par un junior senior inconnu — en le relisant ligne par ligne, en le testant, en le questionnant — est le minimum syndical.

Pour les équipes et les tech leads, la question se pose différemment : comment intégrer l'IA dans le workflow sans dégrader la qualité collective du code ? Quelques pistes concrètes :

• Exiger que les PR incluent une description technique rédigée par l'humain, pas par l'IA
• Intégrer dans la checklist de review une question explicite : "l'auteur a-t-il démontré qu'il comprend ce code ?"
• Valoriser les revues qui posent des questions de fond plutôt que celles qui se limitent à vérifier le style

Pour les projets open source, la décision de Godot ouvre un débat : faut-il interdire l'IA, ou faut-il renforcer les exigences de review ? La seconde approche est probablement plus durable, mais elle demande davantage de ressources humaines — ce qui est précisément ce que manquent la plupart des projets open source.

Conclusion

Godot dit stop au vibe coding, et on peut les comprendre. Maintenir un projet open source de qualité est déjà difficile sans devoir déchiffrer des contributions que leurs auteurs sont incapables d'expliquer.

Mais la leçon dépasse largement le monde du jeu vidéo ou de l'open source. Dans tout contexte de développement — y compris vos projets PHP et Symfony chez MulerTech — comprendre le code qu'on livre reste une responsabilité professionnelle non négociable. L'IA peut vous aider à aller plus vite. Elle ne peut pas comprendre à votre place.

À l'heure où les LLMs deviennent des outils du quotidien, la compétence la plus précieuse n'est peut-être pas de savoir prompter, mais de savoir évaluer, questionner et assumer ce qu'on produit — qu'on l'ait écrit soi-même ou non.

Source : The Register — Godot says bye bye AI, bans vibe-coded contributions