Claude on Zwindler's Reflection

GenAI et développement logiciel, épisode 2 : kubectl-debug-pvc, de l'idée à krew en 2x30 minutes

Tue, 17 Mar 2026 18:00:00 +0100

Précédemment, dans “GenAI et dev”

Dans mon article précédent, je vous parlais de mon retour d’expérience avec PodSweeper, un projet développé avec OpenCode et Claude Opus. Le bilan était nuancé : vitesse brute impressionnante, mais race conditions, gestion d’erreur laxiste, et nécessité constante de supervision humaine (entre autres déconvenues).

Aujourd’hui, je vous parle d’un deuxième projet, bien plus simple, né d’un vrai besoin en production. Et le constat est assez différent.

L’incident qui a tout déclenché

Vous connaissez peut-être cette situation : un pod en production, en état de fonctionnement, qui utilise un PVC en ReadWriteOnce. Vous avez besoin d’aller regarder le contenu de ce volume. Bonne pratique de production : le pod en question ne dispose pas de shell (on réduit la surface d’attaque). Pas de /bin/sh, pas de /bin/bash, rien.

Pas grave, on a kubectl debug pour ça, me direz-vous !

Ok, créons un conteneur éphémère dans le pod et… ah non. kubectl debug ne permet pas de monter les volumes du pod dans le conteneur éphémère. Il n’expose tout simplement pas l’option volumeMounts pour les conteneurs éphémères.

On pourrait couper le pod, ce qui permet de monter le PVC RWO dans un autre pod avec un shell, mais on n’a pas envie, c’est de la prod.

Mon collègue Maxime (encore lui !) me propose une méthode de contournement. La procédure manuelle, c’est :

Créer un conteneur éphémère sur le pod avec kubectl debug
Construire à la main un patch JSON pour ajouter des volumeMounts au conteneur éphémère qu’on vient de créer
Dans un autre terminal, se brancher ~~au cul du camion~~ sur l’API de kube en direct avec kubectl proxy
Appliquer le patch via un curl sur l’API Kubernetes
Attendre que le conteneur soit prêt, s’attacher au conteneur
Se dire qu’il y avait quand même plus simple comme métier que patcheur de container à coup de curl.

Pour ceux qui pensent que c’est jouable, “téma la gueule du patch” comme disent (disaient ?) les jeunes :

curl http://localhost:8001/api/v1/namespaces/<namespace>/pods/<pod>/ephemeralcontainers \
 -X PATCH \
 -H 'Content-Type: application/strategic-merge-patch+json' \
 -d '{
 "spec": {
 "ephemeralContainers": [
 {
 "name": "debugger",
 "image": "ubuntu",
 "command": ["/bin/sh"],
 "targetContainerName": "<target-container>",
 "stdin": true,
 "tty": true,
 "volumeMounts": [
 {
 "name": "<volume-name>",
 "mountPath": "/debug/<volume-name>"
 }
 ]
 }
 ]
 }
 }'

Si vous pensez que c’est error prone, vous avez raison. Et si vous pensez que c’est pénible à faire sous pression pendant un incident de prod, vous avez encore plus raison.

Side note

Les plus aguerri·es d’entre vous dans les versions récentes de Kubernetes ont peut être entendu parler du KEP-2590, qui introduit un (relativement) nouveau flag --subresource de kubectl. En effet, les containers éphémères créés par la commande kubectl debug ne sont pas des resources (un pod, un deployment, …) mais des subresources.

Jusqu’à cette version 1.33, il était littéralement impossible de réaliser des opérations sur les subresources avec kubectl, seulement les resources.

Kubernetes v1.33: Octarine apporte le support du flag –subresource, mais seulement pour 3 subresources pour l’instant status, scale and resize

Pas de solution de ce côté-là non plus…

Le prompt de réunion

J’avais cette idée en tête depuis l’incident. Lundi matin, au début d’une réunion (pendant que les gens faisaient encore des blagues), j’ai lancé OpenCode avec Claude Opus et j’ai tapé un prompt qui décrivait :

Le problème : kubectl debug ne monte pas les volumes PVC s’ils sont en RWO
La procédure manuelle que je faisais à la main (les étapes douloureuses décrites un peu plus haut)
Ce que je voulais : un outil qui automatise tout ça

OpenCode + Opus m’ont posé 2 questions (et j’ai ajouté une consigne) :

“Quel langage ?” → Go (je persiste)
“CLI seule ou TUI ?” → Les deux (mode non-interactif pour le scripting, TUI pour l’usage quotidien)
Et je lui ai demandé de toujours vérifier à chaque fois qu’il estime avoir fini de lancer le linter golangci-lint (trauma de mon précédent test avec opencode)

Il est parti de lui-même sur l’idée d’une TUI avec Bubble Tea. Puis j’ai arrêté de regarder & j’ai suivi ma réunion.

~30 minutes plus tard, fin de la réunion, j’ai regardé le résultat. Le POC était fonctionnel.

Ce qu’Opus a produit en 30 minutes

Sans aucune intervention de ma part, le LLM a scaffoldé un projet Go complet :

Structure propre : cmd/ pour le CLI Cobra, pkg/k8s/ pour toute l’interaction Kubernetes, pkg/tui/ pour la TUI Bubble Tea
Le coeur du sujet : un appel direct à l’API Kubernetes pour patcher le subresource ephemeralcontainers du pod avec un strategic merge patch incluant les volumeMounts
Mode non-interactif : -n namespace -p pod -v volume:/mount/path, prêt pour le scripting
TUI complète : navigation vim-style (j/k), filtrage fuzzy (/), multi-sélection de volumes, spinner de chargement…
Makefile avec tout un tas de targets (vet, lint, test, build, install)

Ce que je lui ai demandé d’ajouter :

Discovery intelligente : au lieu de scanner tous les pods de tous les namespaces (lent sur un de mes gros cluster), l’outil liste d’abord les PVCs cluster-wide (un seul appel API) pour identifier les namespaces pertinents, PUIS les pods dans le namespace sélectionné. On réduit drastiquement le nombre d’appels à l’API server de kube et la TUI ne montre que les namespaces et pods qui ont des volumes PVC
Héritage du SecurityContext : le conteneur éphémère copie le securityContext du conteneur cible, ce qui lui permet de passer les PodSecurity policies (restricted, baseline…). C’est un cas que je n’avais pas envisagé dans mon prompt initial et qui a planté immédiatement sur un cluster bien configuré.

Sans ces petites améliorations le tool était déjà utilisable (sauf pour le cas où vous avez configuré des SecurityContext), mais c’est nettement plus confortable à l’usage (parce que oui, je l’utilise).

Le code de la mécanique centrale (le patch de l’API) fait quelques centaines de lignes de Go propre. Il récupère le pod, construit le patch JSON avec le conteneur éphémère et ses volumeMounts, l’applique via Patch() sur le subresource, attend que le conteneur soit Running, puis lance kubectl attach. Rien de sorcier, c’est juste ce qu’il faut, bien fait du premier coup.

 ephemeralContainer := corev1.EphemeralContainer{
 EphemeralContainerCommon: corev1.EphemeralContainerCommon{
 Name: containerName,
 Image: opts.Image,
 Command: []string{"/bin/sh"},
 Stdin: true,
 TTY: true,
 VolumeMounts: mounts,
 SecurityContext: targetSecurityContext,
 },
 TargetContainerName: targetContainer,
 }
...
 _, err = c.Clientset.CoreV1().Pods(opts.Namespace).Patch(
 ctx,
 opts.PodName,
 types.StrategicMergePatchType,
 patchBytes,
 metav1.PatchOptions{},
 "ephemeralcontainers",
 )

Les itérations suivantes (30 minutes-ish)

Une fois le POC validé, j’ai enchaîné quelques prompts ciblés. Je lui ai demandé ce qu’on pouvait améliorer. Il a proposé (et implémenté) :

quelques corrections mineures de code qu’il avait mal codé (mais non bloquant)
Warnings : si le SecurityContext hérité a readOnlyRootFilesystem, runAsNonRoot, ou autre mesure de sécurité, l’outil prévient l’utilisateur avant l’attach
Ajouté une CI complète à base de goreleaser et de github actions
Ajouté de la documentation

La cerise sur le Macdo : publication sur Krew

Une fois que j’avais une version propre, j’ai demandé à Opus comment faciliter l’installation du plugin. Il m’a proposé brew, ou alors Krew, le gestionnaire de plugins kubectl.

Je lui ai demandé si le processus d’acceptation du plugin était complexe. Il a dit que non, je lui ai dit “chiche !”.

Il a réalisé l’intégralité du processus :

Création d’un fork de krew-index
Rédaction du manifeste Krew (le fichier .yaml qui décrit le plugin)
Prise en compte de toutes les bonnes pratiques demandées par les maintainers de krew-index (format des URLs de téléchargement, descriptions courtes, checksums SHA256, etc.)
Préparation de la PR, directement sur krew-index

J’ai juste regardé. La PR a été mergée 12 heures plus tard par les mainteneurs.

Résultat : kubectl krew install debug-pvc fonctionne.

Mini échec - déléguer aussi la démo

Fort de ce succès avec la PR pour krew-index, je me suis demandé si on ne pourrait pas faire une démo visuelle (un GIF à ajouter dans le README.md du projet qui montre comment ça fonctionne) avec le LLM.

Je lui ai demandé s’il pouvait le faire avec asciinema et le LLM m’a répondu que “oui” (oui, je discute avec le LLM comme avec mes collègues). Banco, on a essayé.

Le résultat était presque bon, j’aurais pu m’en contenter si j’étais pas quelqu’un de pénible : c’était un poil lent. J’ai l’impression la réactivité du LLM dans ses actions était inégale, ce qui rendait le rendu un peu désagréable au visionnage. J’aurais pu insister jusqu’à avoir quelque chose de correct, mais j’ai finalement enregistré moi-même une vidéo, convertie en GIF avec ffmpeg. C’était plus fluide et plus rapide que d’itérer.

Le diff avec PodSweeper

La différence de ressenti entre ce projet et PodSweeper est frappante. Là où PodSweeper était un combat constant (race conditions, amnésie du LLM, fonctionnalités hors-spécifications), kubectl-debug-pvc s’est déroulé sans accroc notable.

Pourquoi ? Je pense que ça tient à la nature du projet :

Une seule chose à faire, clairement définie : patcher un subresource Kubernetes avec des volumeMounts
Pas de logique concurrente : on fait une requête API, on attend, on s’attache
Un domaine bien documenté : l’API Kubernetes, Cobra, Bubble Tea. Le LLM connaît tout ça par coeur
Pas d’état partagé complexe : pas de goroutines qui se marchent dessus, pas de graceful shutdown à gérer, de microservices multiples
Scope limité : le projet entier tient dans une quinzaine de fichiers, CI et documentation incluses

C’est probablement le terrain de jeu idéal pour un LLM. Un problème bien cadré, un domaine technique bien balisé, une solution linéaire.

Qu’est-ce que j’en pense ?

Objectivement, ce genre de projet “simple” (une chose à faire, simple à comprendre) marche vraiment super bien avec OpenCode + Opus. Je pense que c’est ce genre à cause (grâce) de ce genre de petits projets que la hype est tellement forte autour du développement agentique. On a une idée en tête qu’on avait la flemme de dev, on teste, ça marche. “WOW”.

Mais je ne veux pas non plus minimiser le travail réalisé. Le fait qu’un outil fonctionnel, propre, publié sur Krew et utilisable par n’importe qui ait pu émerger d’un prompt lancé en début de réunion, c’est quand même assez dingue.

Un peu flippant aussi, de se dire qu’un nombre hallucinant de micro tools vont apparaître dans les prochains mois, avec un niveau de qualité probablement inégal.

Le projet

Le code est disponible ici :

https://github.com/zwindler/kubectl-debug-pvc

Installation :

# Via Krew (recommandé)
kubectl krew install debug-pvc

# Utilisation interactive (TUI)
kubectl debug-pvc

# Utilisation non-interactive
kubectl debug-pvc -n my-namespace -p my-pod-0 -v data:/debug/data

Si vous aussi vous avez déjà galéré à inspecter un PVC sur un pod sans shell, essayez. Et si vous trouvez des bugs, vous pourrez blâmer le LLM 😄.

GenAI et développement logiciel : retour d'expérience avec PodSweeper

Sun, 08 Mar 2026 18:00:00 +0200

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 :

ça ne coûte quasiment rien en temps de dev (ça va tellement vite à générer)
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 !