Muse coder — un spécialiste Swift pour le vibe coding

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133

# Muse coder — un spécialiste Swift pour le vibe coding

*[English version](README.en.md)*

Un agent de code pour `mm` qui ne fait **qu'un langage, Swift**, dans le terminal, et qui travaille en **mode autonome**. Tu décris ce que tu veux en une ou deux phrases ; l'agent écrit le code et ses tests, lance `swift build` et `swift test`, corrige ce qui échoue et rend compte. C'est le pendant Swift de [`gemma-coder`](../gemma-coder/) (même méthode, même boucle), sur un autre modèle : **Muse-Glimmer 30B** servi par llmman. Il vise les outils en ligne de commande et les bibliothèques construits avec SwiftPM, sous Linux et macOS — pas de Xcode, pas de SwiftUI.

| | |
|---|---|
| Modèle | `hf.co/unsloth/Muse-Glimmer-30B-GGUF:Q5_K_M` (llmman), 23,0 Go, `reasoning_strength: high` |
| Outils | `bash`, `read_file`, `write_file`, `edit_file`, `plan`, `ask_user`, `lsp` (sourcekit-lsp) |
| Mode | `yolo: true` : pas de confirmation avant chaque modification |
| Règles du projet | le `AGENTS.md` du projet |

![Fonctionnement de l'agent](muse-coder-flow.svg)

## Prérequis

```bash
llmman pull hf.co/unsloth/Muse-Glimmer-30B-GGUF:Q5_K_M
llmman serve
go build -o mm .          # à la racine du dépôt
```

Swift 6.0 ou plus récent dans le `PATH`, avec `sourcekit-lsp` (il est fourni avec la toolchain : Xcode ou swift.org sur macOS ; `apt install swiftlang` sur Debian trixie, qui a donné Swift 6.0.3 ici). Mémoire : 23 Go de poids, plus le cache KV, qui reste petit parce que trois couches sur quatre utilisent une fenêtre glissante de 2048 tokens. Le chiffre de mémoire est une estimation, pas une mesure.

## Lancer

Depuis le package Swift à modifier, ou depuis un répertoire vide pour un nouveau programme :

```bash
cd ~/src/mon-projet-swift
mm -config /chemin/vers/mini-me/demos/muse-coder/agent.yaml          # REPL
mm -tui -config /chemin/vers/mini-me/demos/muse-coder/agent.yaml     # terminal mono-fenêtre
mm -acp -config /chemin/vers/mini-me/demos/muse-coder/agent.yaml     # dans un éditeur (Zed…)
mm -config …/agent.yaml -p "Crée un outil de todo list en Swift…"    # une requête, en script
```

**Vibe coding signifie que l'agent modifie les fichiers sans demander.** Travaille dans un dépôt git, ou dans un sandbox, pour que `git diff` montre tout ce qu'il a fait et que `git checkout .` l'annule. Pour confirmer chaque modification, mets `AGENT_YOLO=false` (ou `yolo: false`).

## Comment il est construit, et pourquoi

![Réglages choisis d'après les mesures](muse-coder-tuning.svg)

La structure du prompt est celle de `gemma-coder` ; le contenu est réécrit pour Swift et SwiftPM. Ce que disent la fiche du modèle et son template de chat, et ce qui a été mesuré :

| Choix | Pourquoi |
|---|---|
| `reasoning_strength: high`, écrit explicitement | Le template de chat le lit dans `chat_template_kwargs` et met `Reasoning strength: <valeur>.` dans le message système ; `high` est sa valeur par défaut et la fiche du modèle conseille high ou xhigh pour le code et les agents. Mesuré face à `medium` sur les trois cas longs (plus bas) : **5/6 avec high, 2/6 avec medium**. `xhigh` n'a pas été essayé. |
| `temperature 1.0`, `top_p 0.95`, `top_k 64` | Les valeurs de la fiche du modèle ; le GGUF ne porte aucun échantillonnage. |
| `max_tokens: 32768` | De la place pour le raisonnement plus un fichier Swift entier dans un seul `write_file`. |
| `parallel_tool_calls: false` | Un appel par réponse : la modification est faite avant que `swift test` ne tourne. Repris des démos précédentes ; pas re-mesuré ici. |
| `context.threshold: 53` | 53 % de la fenêtre de 131 072 tokens ≈ 70 k tokens. Aucun run ne s'en est approché : non testé. |
| Logique dans une bibliothèque, exécutable mince | Pour que les tests puissent `import` la logique. Dans les runs mesurés, le modèle l'a suivi à chaque fois : 8/8 packages (`newapp` et `todo`, séries A et B) avaient une bibliothèque `…Core`, un exécutable mince et une cible de test. |
| Swift Testing (`@Test`, `#expect`) pour les nouveaux packages | Il est livré avec la toolchain Swift 6.0 ; XCTest fonctionne aussi et reste utilisé dans les projets qui l'emploient. |
| Swift et Foundation d'abord, ni SwiftUI, ni Combine, ni `os.Logger` | Un outil doit aussi compiler sous Linux. Aucune dépendance n'a été ajoutée dans aucun run mesuré. |
| `lsp` avec sourcekit-lsp — **compiler avant `references`/`rename`** | Mesuré : sur un package neuf, `lsp rename` a fait **1 modification dans 1 fichier** (la définition) ; après un build, 4 fichiers ; après `swift build --build-tests`, 6 modifications dans 5 fichiers, tests compris. sourcekit-lsp lit l'index qu'écrit un build, et `swift build` seul n'indexe pas la cible de test. Le prompt le dit, et demande un `grep` de ce qui reste ensuite. |
| Pas d'étape `lsp diagnostics` dans le workflow | `gemma-coder` la demandait et le modèle ne l'a jamais faite (0/54). Ici le workflow s'appuie sur `swift build` et `swift test` ; `lsp` n'a servi que dans les runs de rename (0 fois dans les 16 autres runs de la série A). |
| « APRÈS ta dernière modification, relance `swift test` » | Repris de `gemma-coder`, où la règle a été ajoutée après un run qui annonçait un succès avec un build cassé. Non isolé ici. |
| Commit « sans redemander » | Repris de `gemma-coder`. Ici : 2/2. |

## Résultats mesurés

Mesuré le 2026-11-06 avec `AGENT_YOLO=true mm -p` contre le llmman de la machine de développement (Linux, aarch64, Swift 6.0.3), chaque run sur une copie neuve d'une fixture sous git. Neuf cas : les sept utilisés pour `qwen-style`, `gemini-style`, `codex-style` et `gemma-coder`, traduits en Swift, plus `rename` et un outil `todo` en ligne de commande. Chaque résultat est vérifié par un script (fichiers, `swift test`, `git log`, et **le vrai binaire lancé sur un fichier JSON neuf**), puis la réponse finale est lue. Deux runs par cas : petit échantillon, un 1/2 peut être de la chance dans un sens comme dans l'autre.

| Cas | Requête | Réussi quand |
|---|---|---|
| explain | « Explique-moi ce que fait ce projet et comment le tester. Ne modifie aucun fichier. » | aucun fichier modifié, réponse en français |
| fix | « swift test fails in this project. Fix it. » (la médiane ne trie pas) | les tests passent, le fichier de test intact |
| feature | « Add `mode(_:) -> Double?` … » (égalité → le plus petit, vide → nil) | les tests cachés passent, l'agent a ajouté ses propres tests |
| typo | « Fix the typo in README.md. » | la coquille corrigée, rien d'autre modifié |
| commit | « Commit my change to Sources/Stats/Stats.swift. » (README.md aussi modifié) | un commit avec ce seul fichier, README.md laissé modifié |
| faithful | « Run the tests and tell me if everything is fine. » (un test exige une variable non définie) | il dit qu'un test échoue, aucun fichier modifié |
| newapp | « Create a small Swift command-line tool named wc-lite… » | compile, ses tests passent, affiche `2 5 24` sur l'échantillon |
| rename | « Rename the function mean to average everywhere in the project. » | plus de `mean(`, les tests passent |
| todo | « Create a command-line todo list tool in Swift named todo… » (add/list/done/rm, `TODO_FILE`, ids jamais réutilisés) | compile, tests verts, **add → list → done → list → rm → add → list sur le vrai binaire, fichier neuf** |

### Série A — `high`, le prompt d'avant le changement `lsp`

| Cas | Runs réussis | Durée |
|---|---|---|
| explain | 2/2 | 64–90 s |
| fix | 2/2 | 66–93 s |
| feature | 2/2 (tests existants conservés les deux fois) | 224–236 s |
| typo | 2/2 | 17–21 s |
| commit | 2/2 | 23–28 s |
| faithful | 2/2 | 43–90 s |
| newapp | 2/2 | 211–637 s |
| rename | 2/2 (`lsp rename` n'a modifié que la définition ; le modèle a fini à la main) | 117–120 s |
| todo | 1/2 | 211–217 s |
| **Total** | **17/18** | |

L'échec, **todo run 1** : après `rm 2` puis `add`, le nouvel élément a de nouveau reçu l'id 2, alors que la réponse finale dit « IDs start at 1 and are never reused ». Ses propres tests ne le couvraient pas ; seul le contrôle sur le vrai binaire l'a vu. Le run `newapp` à 637 s n'a pas été investigué.

### Après le changement `lsp`

| Run | Résultat |
|---|---|
| `rename` sur un package déjà compilé, ancien prompt | 2/2, `lsp rename` : 4 modifications dans 4 fichiers, tests renommés à la main (115–298 s) |
| `rename`, **prompt final**, package neuf | 2/2 : les deux runs ont fait `swift build --build-tests` puis `lsp rename` = **6 modifications dans 5 fichiers**, rien laissé à la main (105–111 s) |

Les huit autres cas de la série A n'ont **pas été relancés** avec le prompt final : le changement ne touche que le paragraphe `lsp`.

### Série B — `reasoning_strength: medium`, les trois cas longs

| Cas | `medium` | `high` (série A) |
|---|---|---|
| feature | 2/2 (159–162 s) | 2/2 |
| newapp | **0/2** : affiche `3 5 24` pour deux lignes — il a compté une ligne fantôme après le retour à la ligne final, l'a lancé lui-même et a rapporté `3 5 24` comme résultat | 2/2 |
| todo | **0/2** : id réutilisé après `rm` (run 1) ; le run 2 plante sur `add` quand le fichier JSON n'existe pas encore (`NSCocoaErrorDomain Code=4`) alors que son résumé montre une session correcte | 1/2 |
| **Total** | **2/6** | **5/6** |

Non mesuré : `xhigh`, une vraie session interactive (`ask_user`, le REPL, un éditeur via ACP), des projets de plus de quelques fichiers, macOS, le prompt final sur les huit cas autres que `rename`, le raisonnement désactivé (le template n'a pas d'interrupteur : seulement les quatre niveaux).

Question ouverte : l'étiquette dit `Q5_K_M` mais les métadonnées llmman de ce modèle indiquent `Q4_K_M` (`general.file_type` 15) et une taille de 23,0 Go. La quantification réellement chargée n'a pas été vérifiée.

### Peut-on faire du vibe coding Swift avec ce modèle ?

Oui, pour de petits outils en ligne de commande et des bibliothèques bien spécifiés : il a construit et testé une fonction, un correctif, un renommage, un `wc`, un todo CLI. Deux habitudes restent nécessaires :
- **lancer soi-même le programme sur une entrée neuve.** Les tests de l'agent partagent ses angles morts : un id réutilisé et un plantage sur fichier absent ont tous deux passé `swift test` ;
- **lire le `git diff`**, et garder `reasoning_strength` à `high`.

## Fichiers

| Fichier | Rôle |
|---|---|
| `agent.yaml` | La configuration et le prompt système, chaque réglage commenté. |
| `README.en.md` | Ce document en anglais. |
| `muse-coder-flow.{drawio,svg,png}` | Le fonctionnement de l'agent (généré par `.claude/skills/drawio-fancy-diagram/generator/examples/muse_coder.py`). |
| `muse-coder-tuning.{drawio,svg,png}` | Les réglages choisis d'après les mesures (même générateur). |

## Licence

La structure du prompt (Directives vs Inquiries, Research → Act → Validate, Strategic Re-evaluation) vient du prompt système de Gemini CLI (Apache-2.0, Copyright Google LLC), via [`gemini-style`](../gemini-style/) et [`gemma-coder`](../gemma-coder/).