Comment empêcher les réseaux de neurones d'écrire du mauvais code Go

Quiconque a essayé de générer du code Go via Cursor, Claude Code ou Copilot a probablement rencontré leurs particularités spécifiques. Les réseaux de neurones s'acharnent à importer des patterns Java dans Go, oublient d'encapsuler les erreurs avec %w, ignorent les conditions de course dans les goroutines, et génèrent des structures monstrueuses là où une simple fonction suffirait.

Demander manuellement au modèle à chaque fois est un plaisir douteux. Vous voulez donner à l'assistant un ensemble approprié de règles une seule fois et oublier les corrections constantes dans la revue de code. C'est exactement pour cela que le développeur français Samuel Berthe (auteur de la populaire bibliothèque samber/lo) a créé le projet cc-skills-golang.

Que sont les Agent Skills et pourquoi en avez-vous besoin

Le concept d'Agent Skills est né d'un problème simple : le prompt système d'un réseau de neurones n'est pas infini. Si vous chargez un guide de style détaillé, des règles de sécurité, les spécificités des opérations de base de données et les fonctionnalités du framework dans le contexte, le modèle n'aura simplement plus de place pour votre code réel. Les réponses seront plus lentes et la qualité de génération diminuera.

Les Skills résolvent ce problème par le chargement paresseux. Le projet est une collection de petits fichiers Markdown. Au début d'une session, seul un résumé bref de chaque module (environ 100 jetons par skill) est chargé dans la mémoire du LLM. Dès que vous demandez à l'assistant d'« écrire un benchmark pour cette fonction » ou d'« ajouter la gestion des erreurs au handler gRPC », le modèle voit le déclencheur correspondant et charge le document détaillé avec les instructions spécifiquement pour cette tâche.

Pas de pollution IA

Le détail principal dans le README du dépôt est l'avertissement honnête de l'auteur : « Pas de pollution IA ici. »

Aujourd'hui, GitHub est inondé de bases de connaissances générées automatiquement qui font plus de mal que de bien. Samuel a fait les choses différemment. Il a bien utilisé Claude pour la distillation initiale des règles à partir de ses commits dans de vrais projets Go, mais il a ensuite réécrit, modifié et testé manuellement chaque instruction.

L'auteur a même effectué des mesures de précision sur un ensemble de tests :

• Sans les skills enfichables, le modèle de langage a correctement terminé les tâches de test 56 % du temps.
• Avec l'ensemble de règles activé, le score est passé à 98 %.

Des améliorations de précision particulièrement fortes ont été observées sur des sujets spécifiques : la modernisation de l'ancien code pour les nouvelles fonctionnalités de Go (range-over-int, itérateurs), l'écriture de benchmarks et la gestion des erreurs.

Ce qu'il y a dans le dépôt

Toutes les instructions sont divisées en deux grandes catégories : les règles générales du langage et le travail avec des bibliothèques spécifiques.

Règles générales du langage et architecture

Les modules couvrent presque tout le cycle de développement Go :

• Qualité et style du code : conventions de nommage, opérations sûres avec nil et les slices, prévention des fuites mémoire, documentation appropriée et configuration golangci-lint.
• Architecture et patterns : gestion du context, concurrence sans fuites de goroutines, conception de structures et interfaces, patterns de refactoring via gopls.
• Tests et débogage : tests table-driven, détection de race, profilage via pprof, configuration d'OpenTelemetry et collecte de métriques.
• Configuration du projet : structure de répertoires idiomatique (cmd/internal/pkg), pipelines CI/CD et gestion des modules.

Support des bibliothèques populaires

Au-delà des standards du langage lui-même, le dépôt intègre des règles pour travailler avec les outils courants :

• CLI et configs : spf13/cobra et spf13/viper.
• Injection de dépendances : google/wire, uber/dig, uber/fx et leur propre conteneur samber/do.
• Protocoles réseau : gRPC, GraphQL (gqlgen) et OpenAPI/Swagger.
• Écosystème samber : helpers fonctionnels samber/lo, monades samber/mo, logging samber/slog et chaînage d'erreurs samber/oops.

Un point intéressant : les skills sont conçus pour ne pas se chevaucher. Si une règle de gestion des erreurs affecte le logging, elle est décrite dans le module golang-error-handling, et le module golang-observability y fait simplement référence. Cela économise des jetons.

Comment installer

Le projet prend en charge presque tous les outils populaires qui fonctionnent avec le standard Agent Skills.

La méthode la plus universelle est l'utilitaire skills :

npx skills add https://github.com/samber/cc-skills-golang --all

Si vous travaillez dans Cursor, clonez simplement le dépôt dans le dossier des skills :

git clone https://github.com/samber/cc-skills-golang.git ~/.cursor/skills/cc-skills-golang

Pour Claude Code, l'installation se fait avec la commande standard du plugin :

/plugin marketplace add samber/cc
/plugin install cc-skills-golang@samber

Copilot, Gemini CLI, OpenCode et Codex d'OpenAI sont pris en charge de la même manière.

Utilisation sur CI pour l'auto-review

Un cas d'utilisation intéressant décrit par l'auteur est l'exécution d'agents IA en tant que reviewers sur GitHub Actions.

Les linters réguliers sont excellents pour détecter les problèmes de formatage ou les variables non utilisées. Cependant, ils sont impuissants si un réseau de neurones casse discrètement la cohésion architecturale pendant un refactoring ou oublie d'annuler le context lors de la sortie d'une fonction. Un agent connecté à la PR avec cet ensemble de skills vérifie spécifiquement la conformité idiomatique Go du code et signale les problèmes architecturaux avant que la PR n'arrive chez vos collègues.

Cela vaut-il le coup d'essayer

Si vous utilisez activement les réseaux de neurones dans le développement Go et que vous êtes fatigué de corriger leurs erreurs triviales, installer cet ensemble vaut définitivement le coup. Cela ne transformera pas l'IA en architecte senior, mais cela réduira considérablement le nombre de coquilles stupides et de code non idiomatique.

C'est particulièrement agréable que le projet ne tente pas de surcharger le contexte et laisse la possibilité de remplacer n'importe quel skill par les règles de votre entreprise. Créez simplement votre propre module interne et spécifiez qu'il a la priorité sur le module standard.