La GenAI, c’est fantastique ?

Pas mal de gens ont sorti leur avis sur la Gen AI pour dev en très peu de temps, alors je me rends compte qu’il est plus que temps que je poste ce brouillon commencé il y a plus de deux semaines 🙃.

Pour le travail, j’utilise de plus en plus d’assistants IA pour m’épauler dans mes tâches du quotidien. En 2024, c’était surtout pour automatiser des tâches pénibles (scripter des trucs, faire une liste pénible de tâches répétitives sans coder ça proprement). Courant 2025, j’ai testé plusieurs fois de lui faire faire de l’Ops et, à chaque fois, les résultats étaient moyens, tant pour concevoir une infra cohérente, fiable et efficiente que pour de l’assistance à la résolution d’incident (cf. mon article sur le sujet).

En 2026, sur ce dernier point, je trouve qu’on n’a toujours pas avancé, même si je reconnais qu’il existe des outils spécialisés que je n’ai pas encore suffisamment testés, open source ou non. Je peux citer k8sgpt et HolmesGPT en open source, et Anyshift avec son agent SRE pour la détection de root cause et la résolution d’incident.

Note : fun fact, dans son post “Mon positionnement sur l’Intelligence Artificielle Générative” posté juste avant moi, Alex cite une longue liste de métiers qui vont profiter de l’IA Gen, et les ops ont le droit à rien d’autre qu’un argument de plus pour passer sur Kube 😭.

J’ai en revanche commencé à utiliser la GenAI pour réaliser plusieurs projets de sites web à 100% (vibe coding ?), dont je vous ai d’ailleurs déjà parlé :

• Convertir un blog de Bloggrify à Hugo
• Créer un site “joli” (largement au-delà de mes compétences) pour héberger les recherches que j’ai faites sur les différentes façons de déployer Kubernetes
• Améliorer la sécurité de mon site web en automatisant la modification du thème Hugo que j’utilise, de manière à avoir la meilleure note sur Mozilla HTTP Observatory

Dans les 3 cas, le résultat est là. Ou plutôt, il semble l’être pour le béotien que je suis.

Je n’ai jamais caché que je n’ai aucune compétence en front, et peut-être que pour un expert du domaine, ce que j’ai fait avec l’IA est horrible (ou non ?). Dans tous les cas, ça ne peut pas être pire que les UIs que j’ai faites sans. Petit exemple 😄 :

ou alors : la GêneAI ?

C’est le genre de retours qu’on voit fleurir de la part de toutes les personnes qui sont vraiment expertes d’un domaine quand elles voient des novices s’extasier. On a de bons exemples avec les vidéos générées par IA : si on ne fait pas attention, on a l’impression que c’est incroyable. Mais n’importe qui avec un œil un peu critique voit tout de suite de GROS problèmes de cohérence. Pareil pour la génération d’image, ou de musique.

C’est aussi vrai pour le code, et on a de très bons exemples de projets vibe codés qui sont d’immondes plats de spaghetti, et des passoires en termes de cybersécurité. Bref, vous l’aurez compris, j’ai beau être utilisateur (quotidien), je ne suis pas “incroyablé” (comme disent mes enfants) par les LLMs, même les meilleurs.

Pourtant, j’ai plusieurs copains qui ne jurent que par ça, notamment des gens bien plus brillants / intelligents (appelez ça comme vous voulez) que moi. Donc je me dis “OK, peut-être que je m’y prends mal. Essayons avec ce qui se fait de mieux” : un IDE type “Claude Code” et un modèle Opus.

L’éditeur

Après avoir fait une petite étude de marché rapide, on se rend compte que les options sont pléthoriques : Claude Code, OpenCode, Amp Code, …

Le problème de Claude Code, c’est le ticket d’entrée. Je ne suis pas encore prêt à lâcher 100 ou 200 € par mois pour l’usage que j’en ai aujourd’hui. Je ne sais pas si l’offre à 20€ me suffirait ou non. Au-delà de rares side projects perso que j’ai cités plus haut, je code peu. Le gros de mes geekeries, c’est de l’infra : installer des Kube et des OS de virtualisation. Des trucs difficiles à automatiser avec un LLM.

On (Pierre surtout) m’a conseillé Amp Code pour du perso, notamment parce que de base, il y a un tier gratuit avec un certain nombre de tokens et que si on n’est pas trop gourmand, c’est assez efficace. J’ai préféré n’en faire qu’à ma tête et tester plutôt sur OpenCode, qui a l’avantage d’être plus flexible sur les providers de LLM et la consommation de tokens. Il est d’ailleurs possible de profiter de modèles locaux (gratuits, donc) ou des modèles inclus gratuitement (en tout cas pour l’instant) tels que GLM 5 Free, qui est plutôt bien placé dans les modèles de dev (surtout, c’est gratuit…).

OK, on a l’éditeur. Maintenant, le code ?

Pour me faire une idée de la pertinence du code généré par mon LLM favori (Sonnet et Opus, depuis un moment), il me faut donc un langage et un cas d’usage que je maîtrise, pour être capable de lui dire “non mais là, c’est n’importe quoi !?”.

Cas d’usage que je maîtrise… vous vous en doutez, il y aura forcément du Kubernetes dedans.

Langage que je maîtrise : j’ai appris Go en 2022 grâce à un collègue de chez Deezer (encore merci Martial !) et j’ai publié quelques outils et fait des contributions mineures. J’ai écrit une grande partie de l’outil GroROTI et aussi commencé (mais jamais terminé) le développement d’un RPG en Go, fortement inspiré de Castle of the Winds, un jeu de mon enfance : gocastle. Et j’ai une capacité professionnelle (même si ce n’est pas le coeur de mon métier) dans mon travail de tous les jours.

Après le contexte, le projet

OK, on a le contexte technique : Kube + Go. Reste donc l’idée à implémenter. Il faut un projet suffisamment volumineux pour que le test soit pertinent, suffisamment rigolo pour que j’aie envie d’y passer du temps perso, mais quand même un peu utile pour que j’aie envie d’en parler et de montrer l’avancement. Et surtout, un projet dont la logique métier reste à ma portée : pour évaluer honnêtement la qualité du code produit par l’IA, il faut que je sois capable de le relire et de le critiquer.

Et là, dans mes tiroirs à idées débiles qui débordent de mon cerveau, je me suis souvenu de ce “pitch” de 2023-2024, que j’avais laissé moisir faute de temps :

PodSweeper : la manière la plus complexe, over-engineerée et chaotique de jouer au démineur.

Partez pas, vous allez voir c’est rigolo. Si !

Au lieu d’une grille visuelle où on clique sur des cases en espérant ne pas tomber sur une “mine”, on a une “grille” virtuelle où chaque case est un Pod et le clic est un kubectl delete.

Oui, c’est débile. Ça me plaît donc beaucoup :).

Au-delà du troll assumé (over-engineering des enfers) de ce jeu, il y a quand même un objectif pédagogique derrière.

Si, si, vraiment.

J’ai pensé le jeu comme une introduction à la sécurité dans Kubernetes, avec des niveaux de difficulté à débloquer, façon CTF de cybersécurité.

Au début, vous pouvez tout faire. Vous pouvez bien sûr jouer normalement (delete un Pod, voir s’il y a des mines à côté) pour vous faire la main. Vous pouvez aussi automatiser les actions (un script qui “clique sur une case” au hasard, récupère les hints de proximité de mines, clique à un endroit safe, …).

Mais vous pouvez aussi tricher.

Et c’est tout l’intérêt du jeu. Dans les premiers niveaux de difficulté, les manifests Kubernetes du jeu sont volontairement vulnérables. On peut donc gagner sans effort, si on sait où chercher.

Cependant, très vite, les niveaux s’enchaînent et les restrictions avec. Assez rapidement, on arrive dans des bonnes pratiques de production qui empêchent toute “triche”. Et si vous trouvez des vulnérabilités non prévues dans le code du jeu lui-même… eh bien, c’est du bonus 😈.

Le processus initial

C’est probablement une erreur, mais j’ai fait toute la phase d’idéation avec Gemini avant de lancer OpenCode. L’expérience aurait probablement été meilleure (a minima plus représentative) si j’avais commencé directement avec OpenCode.

J’ai pondu tout ce que j’avais dans la tête, ainsi qu’un gros pavé informe de dizaines de lignes provenant de mes notes de quand j’ai eu l’idée en 2023, et je lui ai demandé de me sortir un fichier SPECIFICATIONS.md avec toutes les infos importantes, remises dans l’ordre.

Une fois les specs écrites, je lui ai demandé de détailler les différents niveaux et les difficultés que nous allions progressivement ajouter, dans GAMEPLAY.md.

Enfin, j’ai demandé de faire un découpage du projet par “issues” et par priorité, de manière à avoir un MVP rapidement : ISSUES_PRIORITY.md. Mon idée était de donner le plan de bataille très détaillé et découpé finement à OpenCode et de lui laisser dérouler.

Première déconvenue : Gemini 3 Pro est assez mauvais pour ça. Les tâches étaient crédibles(-ish) mais ordonnées n’importe comment (dépendances entre tâches non respectées). J’ai donc lancé pour la première fois OpenCode dans mon repo et je lui ai dit “voilà le contexte, voilà ce qu’on a imaginé comme tâches. Qu’est-ce que tu en penses ?”.

Le bon (open)code…

Dans les trucs assez chouettes : OpenCode + Claude Opus a tout de suite vu que le plan imaginé par Gemini était bancal, et m’a posé des questions et proposé un découpage encore imparfait mais déjà plus cohérent. C’est probablement là le gros de l’intérêt de ces logiciels. Ils embarquent des connaissances pour guider le développement logiciel et surtout (SURTOUT) apportent du cadre.

Assez vite, on finit par se mettre d’accord sur un plan qui me plaît. OpenCode met à jour les documents et se met à développer (scaffolding, création des pipelines, premiers binaires et images Docker vides). On a un projet prêt à développer en un claquement de doigt, c’est assez enthousiasmant, de prime abord.

Les assistants LLMs ont très envie de se jeter dans le code, ça reste vrai avec OpenCode+Opus. Alors même qu’on n’avait pas fini de discuter du plan et des options possibles, il me proposait de lui-même de passer au code. Cela dit, c’était pareil (voire pire) pour Gemini (à qui j’avais dit spécifiquement qu’on n’allait pas faire de code du tout).

Très vite, les créations de fichiers s’enchaînent. J’ai du mal à suivre et à chaque pause (quand le LLM a fini une tâche et qu’il me demande s’il peut passer à la suivante), je prends de longues minutes à lire ce que le LLM a produit. C’est à la fois grisant et épuisant (relire tout ça, c’est dur pour mon cerveau rouillé).

La vitesse brute est impressionnante. En 3 sessions de 1 à 2h, j’ai un MVP fonctionnel. Je comprends qu’on parle régulièrement de 10x engineering quand on parle de génération de code avec les LLMs récents. Si on ne parle pas de génération de code brute (ce qui n’a pas vraiment de sens), à la louche, le code fonctionnel est généré entre 3x et 10x plus rapidement que ce que j’aurais pu faire seul. Des features qui mises bout à bout m’auraient pris des heures à implémenter (génération de la grille, logique de reveal, gestion des états de jeu) tombent en quelques minutes. Vous l’avez déjà lu ailleurs, je dis pareil - le goulot d’étranglement, ce n’est plus le code que je tape : c’est le code que je dois relire.

De ce que j’ai lu, le code est correct, en particulier lors des premières itérations, un peu moins au bout d’un moment. Mais quand je dis “correct”, je sous-vends peut-être le truc : le code produit est du Go idiomatique. Bonne structure en packages, conventions de nommage respectées, gestion d’erreur dans le style Go (quand elle est là…), utilisation appropriée des interfaces. Ce n’est pas juste du code qui compile : c’est du code qu’un reviewer Go ne rejetterait pas d’emblée. On a pour objectif un MVP donc ça reste de la logique “métier” très simple, mais le socle est propre.

Tout est testé, très vite le projet contient une couverture parfaite et 100+ tests alors qu’on ne fait encore rien. Si c’était du code généré par un humain, je ne saurais pas dire si c’est une bonne chose. On est pas du tout dans du TDD, beaucoup de code teste des choses inutiles. Dans le cas du code généré par le LLM, c’est probablement pour le mieux, car le LLM a tendance à ajouter très régulièrement des régressions (on en reparlera). C’est donc intéressant ici, car :

1. ça ne coûte quasiment rien en temps de dev (ça va tellement vite à générer)
2. cela permet au LLM de se rendre compte que son code introduit une régression, et de fixer de lui-même, sans attendre.

… et le mauvais (open)code

Côté outil et modèle d’abord, quelques irritants :

• Par défaut, OpenCode n’incite pas le LLM à lancer golangci-lint à chaque commit. On corrige ça avec un pre-commit hook et/ou les fameux AGENTS.md / skills, mais ça aurait DÛ faire partie du kit de base d’un projet golang (il y a bien les tests…).
• Le LLM (Claude Opus sur OpenCode, mais c’est un biais habituel même en dehors) adore les versions de logiciels qui existaient au moment de son entraînement. Il faut continuellement lui répéter que les versions qu’il suggère sont obsolètes. C’est vrai pour tout : le code Go, les dépendances, les versions des actions GitHub.
• On tombe très souvent dans la limite des 100k tokens. On perd du temps à “compacter” et on perd de la précision. Typiquement : le LLM me demande s’il peut git commit des modifs, le contexte se compacte avant que je réponde, et il commit sans mon autorisation en redéroulant le contexte. Sur du code aussi peu sensible, ça va. Mais sur de la prod, ça serait un vrai problème.
• Le LLM est souvent amnésique : il oublie qu’il a accès à un cluster kind pour faire des tests réels (alors qu’il l’a fait juste avant la précédente compaction, par exemple).

Côté qualité du code produit, c’est plus préoccupant :

• Gestion d’erreur laxiste. Certaines erreurs qui auraient dû retourner un FATAL (controller qui n’arrive pas à s’initialiser correctement !) sont simplement logguées comme ERROR. On se retrouve à ship des versions qui échouent silencieusement. Là encore, ça doit pouvoir se fine tuner avec un AGENTS.md.
• Race conditions. Je suis tombé très vite sur des race conditions assez bêtes. Dans mon cas, des pods bloqués en terminating impactaient le jeu suivant (graceful shutdown mal géré). Opus est parti en boucle sans comprendre la source du problème. J’ai dû le stopper et lui spécifier qu’il ne fallait jamais lancer une nouvelle partie sans s’être assuré que la précédente était terminée.
• Génération de code en dehors des clous. Parfois, sans crier gare, le LLM ajoute une fonctionnalité qui n’est pas demandée, inutile, voire qui va à l’encontre de la SPECIFICATION écrite précédemment. On est obligé de lui remettre un taquet derrière la tête.

Une fois remis sur les rails, le LLM déroule à nouveau, mais ces épisodes montrent bien que sur du code concurrent ou en dehors de user stories hyper strictes (ce qui sort du workflow de base d’opencode), la supervision humaine reste indispensable.

On me répondra que je débute avec ces outils, et que j’aurais pu éviter certains écueils en configurant mieux mon environnement (AGENTS.md, pre-commit hooks, etc.). C’est vrai.

Mais c’est justement là que le bât blesse : une des promesses vantées de la GenAI appliquée au dev, c’est de permettre à des non-développeurs (ou des débutants) de produire du logiciel de qualité à grande vitesse, de manière à pouvoir ship des logiciels complets. Si pour en tirer le meilleur, il faut déjà être un développeur expérimenté qui sait configurer un environnement complexe (avec les spécificités de ces outils IA), anticiper les race conditions et relire du code concurrent… on n’a pas démocratisé le développement, on a juste donné un outil de plus aux gens qui savaient déjà coder. Mon profil (ops qui code, pas dev pur jus) était précisément le public cible de cette promesse. Et aujourd’hui, “les calculs sont pas bons, Kévin”.

Où j’en suis ?

Depuis tout à l’heure, je vous parle de PodSweeper. Mais il en est où, ce projet ?

Après 3 sessions de 1 à 2h max, sans compter l’idéation, j’ai un MVP fonctionnel. Comme je l’ai dit plus haut, le gain de productivité est indéniable, pour quelqu’un qui n’est pas “dev” de métier.

Le code est probablement “globalement” de meilleure qualité que le code golang que j’aurais pu écrire, mais le LLM laisse passer des trous béants dans la logique métier (tout simplement parce qu’il ne réfléchit pas, alors que moi, oui. Enfin, normalement). Dur pour la confiance… Il faut vraiment rester très méfiant de tout ce qui est produit.

Le code est disponible à l’adresse suivante :

• https://github.com/zwindler/PodSweeper/tree/main

Vous pouvez aller voir le code pour vous faire une idée. Si vous n’avez pas peur de vous spoiler, vous pouvez lire la SPECIFICATION.md (spoilers), voire GAMEPLAY.md (j’y détaille tous les niveaux donc c’est giga spoilers).

Vous pouvez (normalement) jouer aux premiers niveaux de difficulté. Ça reste assez basique, si vous avez déjà manipulé kubectl vous devriez trouver la solution très rapidement. Mon but est de rajouter des niveaux au fur et à mesure, j’en ai déjà imaginé 10, certains bien retors 😈 et d’autres viendront peut-être ensuite.

Le code est en MPL v2.0 parce que c’est une licence copyleft que j’aime bien, car elle est à la fois assez peu restrictive, OSI compliant et oblige quand même à reverser les modifs si on en fait dans son coin.

Voilà :) si vous aussi vous trouvez ça rigolo, n’hésitez pas à tester et/ou à me faire des retours.

$ kubectl apply -k https://github.com/zwindler/podsweeper//deploy/base?ref=v0.1.4
namespace/podsweeper-game created
...

$ kubectl wait --for=condition=ready pod -l app.kubernetes.io/name=podsweeper \
  -n podsweeper-game --timeout=60s
pod/gamemaster-54f4dddcc4-6m88z condition met

Have fun !