Vibe coding vs agentic engineering & le Core 4

Au chapitre 1, vous avez posé le plan de l’usine. Avant de la construire, il faut savoir ce qu’elle devra battre. Aujourd’hui vous faites naître Plume, la petite application d’écriture qui sert de banc d’essai à tout le livre, de la manière la plus directe qui soit : une spec, un prompt, un agent, un shot. C’est du vibe coding assumé, et c’est votre baseline. Chaque chiffre de ce run, coût, durée et taux de réussite, devient le point de comparaison des vingt-cinq chapitres suivants. En chemin, vous découvrez les quatre curseurs qui déterminent ce qu’un agent produit : le Core 4.

Vibe coding vs agentic engineering

L’idée en une phrase

Le vibe coding est une conversation exploratoire avec un agent : rapide, créative, jetable. L’agentic engineering est la construction d’un système où les agents sont des composants bornés : reproductible, mesurable, possédé. La différence n’est pas la qualité du résultat d’un run, c’est qui possède la boucle. Dans le premier cas l’agent, dans le second votre code.

Points clés

• Le vibe coding est légitime : pour explorer une idée, prototyper une interface ou apprendre une bibliothèque, une session libre est l’outil le plus rapide qui existe. Ce livre ne le condamne pas, il s’en sert dès aujourd’hui.
• Le critère de bascule est la deuxième exécution. Dès qu’un résultat doit être obtenu à nouveau, demain, par un collègue ou par un cron, la session libre devient un passif : rien de ce qu’elle a appris ne survit à sa fenêtre de contexte.
• L’agentic engineering ne signifie pas « plus d’agents » mais des agents mieux bornés : chaque appel reçoit une entrée définie, produit une sortie vérifiable, et c’est du code qui décide de la suite.
• Une baseline de vibe coding est un instrument de mesure : sans elle, vous ne saurez jamais si l’usine vaut son coût de construction. La vôtre naît dans le TP du jour.

Exemple concret

Le TP de ce chapitre vous fera générer Plume en un shot : une spec d’environ quarante lignes, un prompt d’une phrase, et un agent qui écrit seul six à huit fichiers, tests compris. Attendez-vous à un run de quelques minutes et de l’ordre de quelques dizaines de centimes à un ou deux dollars selon le modèle. Quand la suite passe, le résultat est réel : l’application fonctionne. Relancez le même prompt trois fois et vous obtiendrez trois arborescences différentes, trois styles de code, parfois une suite rouge. Le run réussi ne vous a rien appris de réutilisable. C’est cette asymétrie, valeur du résultat, perte du procédé, que l’usine corrige.

Deux régimes de travail

Critère	Vibe coding	Agentic engineering
Objectif	explorer, prototyper	produire, répéter
Qui possède la boucle	l’agent, dans sa session	votre code, entre les sessions
« Fini » veut dire	l’agent s’est tu	une gate est passée
Trace d’un run	un transcript à relire	des phases nommées, interrogeables
Coût de la 2e exécution	tout re-prompter, résultat variable	relancer un script, résultat comparable

Commande — le one-shot assumé

Les deux harnais du livre savent jouer ce coup. C’est la commande du TP du jour : du vibe coding outillé, lancé en connaissance de cause.

# version pi — un tour non interactif, l'agent lit la spec et implémente
pi -p "Lis specs/plume-baseline.md et implemente Plume dans apps/plume. Fais passer bun test."

# version Claude Code — même énoncé, même régime
claude -p "Lis specs/plume-baseline.md et implemente Plume dans apps/plume. Fais passer bun test."

Piège courant : « le vibe coding, c’est mal » est une lecture paresseuse. Le vibe coding est un excellent outil d’exploration. L’erreur est de lui demander de la production. Le symptôme qui doit vous alerter n’est pas « j’ai prompté librement », c’est « je reprompte la même chose chaque semaine et j’obtiens chaque fois autre chose ».

---

Le Core 4 : Context, Model, Prompt, Tools

L’idée en une phrase

Chaque appel d’agent est déterminé par quatre curseurs : le contexte qu’il voit, le modèle qui le motorise, le prompt qui le dirige et les outils qu’il a le droit d’utiliser. L’usine ne fait rien d’autre que rendre ces quatre curseurs explicites, versionnés et réglables phase par phase, là où une session libre les laisse implicites. Le roster de l’usine, que vous écrirez au chapitre 10, règle le Core 4 de chaque agent.

Points clés

• Context : ce que l’agent voit, fichiers, historique de session, résultats précédents. C’est un budget, pas un sac sans fond : chaque token de contexte se paie, en dollars et en attention du modèle.
• Model : chaque modèle occupe un point du triangle coût-vitesse-qualité. La bonne question n’est plus « quel est le meilleur modèle ? » mais « quel modèle est juste pour cette phase ? ». Un éclaireur n’a pas besoin du cerveau d’un architecte.
• Prompt : dans l’usine, les prompts sont des fichiers du repo, un system.md et un user.md par agent, versionnés, diffables, améliorables. Un prompt tapé dans un terminal est un réglage perdu.
• Tools : la liste des outils autorisés est votre levier de sécurité. Un agent de reconnaissance en lecture seule ne peut pas casser ce qu’il n’a pas le droit d’écrire.

Exemple concret

Prenez la même tâche, « résume l’état de ce dépôt », avec deux réglages du Core 4. Réglage large : tout le repo en contexte, un modèle frontier, un prompt improvisé, tous les outils. Comptez plusieurs centaines de milliers de tokens et quelques dollars, pour un résumé. Réglage juste : les seuls fichiers utiles, un petit modèle rapide, un prompt écrit une fois pour toutes, la lecture seule. Le même résumé tombe pour environ un centime en quelques dizaines de secondes, soit un facteur cent sans perte de qualité perceptible sur cette tâche. Aucun des deux réglages n’est « le bon » dans l’absolu. Le Core 4 se règle par phase, et c’est le roster du chapitre 10 qui l’écrira noir sur blanc.

Les quatre curseurs

Curseur	La question qu’il règle	En session libre	Dans l’usine
Context	que voit l’agent ?	tout ce qui s’accumule	borné par phase, transmis en enveloppe
Model	quel cerveau, à quel prix ?	celui par défaut	choisi par agent dans le roster (ch. 10)
Prompt	quelle mission ?	tapé, puis perdu	system.md + user.md versionnés
Tools	quels droits ?	tous	allowlist par agent (ch. 10)

Config — le Core 4, écrit noir sur blanc

Extrait simplifié d’un roster, le vôtre naîtra au chapitre 10. Chaque entrée répond à une question : qui est cet agent ? Un agent, un prompt, un but, quatre curseurs réglés.

# Chaque agent du roster règle son Core 4 : le modèle vient du roster,
# le prompt vit dans le repo, les outils sont une allowlist explicite.
defaults:
  model: "un-modele-intermediaire"   # exemple : vérifiez les modèles du jour sur openrouter.ai/models
agents:
  scout:
    purpose: "reconnaissance en lecture seule"
    prompt: adws/prompts/scout       # system.md + user.md — versionnés
    tools: [read, grep, glob]        # pas d'écriture : un éclaireur ne construit pas
  builder:
    purpose: "implémenter le plan"
    model: "un-modele-frontier"      # la phase qui mérite le gros cerveau
    tools: [read, write, edit, bash]

Piège courant : « le modèle est le seul curseur qui compte ». En pratique, les trois autres pèsent souvent davantage : un contexte deux fois trop gros double le coût de chaque tour, un prompt non versionné rend toute amélioration impossible à mesurer, et des outils trop ouverts transforment une erreur bénigne en git push --force. Changer de modèle est le réglage le plus visible, pas le plus rentable.

---

Fil rouge — la pièce posée aujourd’hui

La pièce du jour est double. La spec de Plume (specs/plume-baseline.md) vit dans votre lane : c’est un document d’intention, comme PLAN.md. Plume elle-même (apps/plume/) est générée en un shot par le harnais. La frontière code/agent est ici à son état le plus brut : vous proposez une spec, l’agent propose une implémentation, et une seule vérification déterministe tranche, bun test. Pas de phases, pas d’enveloppes, pas de reprise. C’est ce dénuement que les chapitres suivants vont combler, en connaissant désormais son prix. Comptez quelques dizaines de centimes à deux dollars et quelques minutes pour le run. Notez vos chiffres réels : ils sont votre baseline, et l’usine devra faire mieux.

---

Travaux pratiques — la pièce du jour

Une pièce complète à poser dans le repo compagnon plume-factory, qui devient, chapitre après chapitre, votre usine logicielle agentique. Aujourd’hui : la spec de Plume, puis Plume en un shot.

Pièce — specs/plume-baseline.md

La spec que l’agent va lire. Elle vit de votre côté de la frontière : c’est l’intention, écrite une fois, réutilisable pour chaque nouvelle tentative de génération. Le dossier specs/ accueillera plus tard les plans produits par adw_plan (ch. 11). Cette première spec-là est de votre main.

# Plume — spec v1 (baseline un shot)

Plume est une application d'écriture minimaliste. Elle sert de payload à une usine logicielle :
elle doit rester PETITE (6 à 8 fichiers source, tests compris) et entièrement testable.

## Stack imposée

- Bun + TypeScript vanilla. Aucun framework, aucune dépendance externe.
- Tests avec `bun test`. Serveur avec `Bun.serve`, port 4500.
- Tout le code vit dans `apps/plume/`.

## Modèle de données

Un document : `id` (string), `title` (string), `body` (string), `updatedAt` (ISO 8601).

## Fonctionnalités exigées

1. Un store en mémoire avec persistance JSON sur disque :
   `createDocument(title)`, `updateDocument(id, patch)`, `getDocument(id)`, `listDocuments()`.
   Le chemin du fichier de persistance est un paramètre du store (les tests utilisent un
   répertoire temporaire).
2. Des statistiques pures : `stats(body)` retourne le nombre de mots, de caractères et une
   durée de lecture estimée (200 mots/minute, arrondie à la minute supérieure).
3. Une API HTTP JSON : `GET /api/docs`, `POST /api/docs`, `GET /api/docs/:id`,
   `PUT /api/docs/:id`. Codes d'erreur corrects (404 sur id inconnu, 400 sur payload invalide).
4. Une page d'accueil `GET /` qui liste les documents et permet d'en créer un (HTML minimal,
   sans framework ni build).

## Critères d'acceptation

- `bun test` passe, avec au moins 8 tests couvrant le store (création, mise à jour,
  persistance) et les statistiques (texte vide, texte long, arrondi de la durée de lecture).
- `bun run apps/plume/server.ts` démarre et `curl localhost:4500/api/docs` répond `[]`
  sur une base vide.
- Aucune dépendance dans package.json en dehors des types Bun.

Générer Plume — le one-shot

Prérequis : Bun doit être installé, vérifiez avec bun --version, car c’est lui qui exécutera Plume et ses tests. Puis, depuis la racine de plume-factory, avec l’un OU l’autre harnais (le chapitre 7 les mettra derrière un port commun, aujourd’hui l’appel direct est encore permis) :

# version pi
pi -p "Lis specs/plume-baseline.md et implemente Plume dans apps/plume. Fais passer bun test."

# version Claude Code — en mode -p (non interactif), aucun droit n'est accordé par défaut :
# on autorise explicitement l'écriture de fichiers et les commandes bun, rien d'autre
claude -p "Lis specs/plume-baseline.md et implemente Plume dans apps/plume. Fais passer bun test." --permission-mode acceptEdits --allowedTools "Bash(bun:*)"

En session interactive, Claude Code vous aurait demandé ces droits un par un. En mode -p, personne n’est là pour répondre : sans ces deux options, le run se bloque avant d’écrire le moindre fichier. --permission-mode acceptEdits accepte les écritures, et --allowedTools "Bash(bun:*)" n’ouvre le shell qu’aux commandes bun. C’est le curseur tools du Core 4, déjà à l’œuvre : des droits explicites, bornés à la tâche du jour.

Si la suite sort rouge ou incomplète, c’est une donnée, pas un échec du TP. Notez-le, relancez une fois, gardez les deux observations. C’est le comportement de référence que l’usine doit battre. Quand la suite passe, commitez, puis cochez le jalon « ch. 2 » dans PLAN.md.

La gate du TP

cd apps/plume && bun test

# et le serveur répond
bun run server.ts &
sleep 1 && curl -s localhost:4500/api/docs
kill %1

Attendu : au moins 8 tests verts et [] en réponse du serveur sur base vide. Coût du run de génération : de quelques dizaines de centimes à ~2 $, quelques minutes selon le modèle. Sur un petit modèle rapide, le même shot descend sous les dix centimes, au prix de plus de reprises. Notez vos chiffres réels : ils sont votre baseline.

---