--- name: vibe-to-agentic-framework description: Le cadre conceptuel derrière la présentation — ce que signifie "Vibe Coding to Agentic Engineering", pourquoi le parcours est structuré ainsi, et comment chaque slide s'inscrit dans l'arc narratif --- # Le framework "Vibe Coding to Agentic Engineering" Ce skill enseigne le **modèle conceptuel** derrière la présentation. Chaque slide et section existe pour raconter une seule histoire : comment un développeur passe progressivement du "vibe coding" non structuré (niveau Low) à l'agentic engineering de haut niveau (niveau High). ## Concept central **Vibe Coding (niveau Low)**, c'est quand un développeur utilise Claude Code sans structure — pas de contexte projet, pas de conventions, pas de connaissance réutilisable. Chaque prompt est un tirage à pile ou face. Claude peut créer des endpoints aléatoires, ignorer les patterns existants, sauter les tests et produire du code incohérent. La codebase dérive vers l'entropie à chaque interaction. **Agentic Engineering (niveau High)**, c'est quand Claude Code fonctionne comme un système d'ingénierie entièrement configuré. Il connaît l'architecture projet (CLAUDE.md), suit des conventions scopées (Rules), charge l'expertise de domaine à la demande (Skills), délègue à des travailleurs spécialisés (Agents), orchestre des workflows multi-étapes (Commands), automatise les événements de cycle de vie (Hooks) et se connecte aux outils externes (MCP Servers). Chaque prompt produit du code cohérent, testé et de qualité production. Le trajet entre ces deux extrêmes est **incrémental et cumulatif**. Chaque bonne pratique construit sur les précédentes, et la présentation les enseigne dans l'ordre où un développeur devrait les adopter. ## Le système de parcours à 4 niveaux La présentation utilise un système de scoring à 4 niveaux au lieu d'une barre de pourcentage : | Niveau | Ordre | Couleur | Hauteur Journey Bar | Description | |--------|-------|---------|---------------------|-------------| | Low | 1 | Rouge/orange (`hsl(0, 70%, 45%)`) | 25% | Territoire vibe coding — aucune structure | | Medium | 2 | Jaune (`hsl(40, 70%, 45%)`) | 50% | Workflows structurés, un peu d'automatisation | | High | 3 | Vert clair (`hsl(80, 70%, 45%)`) | 75% | Connaissance de domaine, skills, agents custom | | Pro | 4 | Vert profond (`hsl(120, 70%, 45%)`) | 100% | Agentic engineering complet, équipes multi-agents | La journey bar est masquée sur la slide 1 (title slide) et apparaît à partir de la slide 2. Les niveaux sont définis via les attributs `data-level` sur les slides de transition clés et hérités par les slides suivantes jusqu'au changement de niveau suivant. Un `.level-badge` est injecté par JS sur le `h1` de la slide quand le niveau change (ne pas le coder en dur dans le HTML). ## L'exemple fil rouge : monorepo TodoApp Chaque technique est démontrée sur un projet full-stack réaliste. La présentation montre la transformation d'un projet nu (vibe coding) vers un projet avec configuration Claude Code complète (agentic engineering) : **Avant (Vibe Coding) :** ``` todoapp/ ├── backend/ # FastAPI (Python) │ ├── main.py │ ├── routes/ │ ├── models/ │ └── tests/ └── frontend/ # Next.js (TypeScript) ├── components/ ├── pages/ └── lib/ ``` **Après (Agentic Engineering) :** ``` todoapp/ ├── .claude/ # Claude Code config │ ├── agents/ # Custom subagents │ ├── skills/ # Domain knowledge │ ├── commands/ # Slash commands │ ├── hooks/ # Lifecycle scripts │ ├── rules/ # Modular instructions │ ├── settings.json # Team settings │ └── settings.local.json # Personal settings ├── backend/ │ └── CLAUDE.md # Backend instructions ├── frontend/ │ └── CLAUDE.md # Frontend instructions ├── .mcp.json # Managed MCP servers └── CLAUDE.md # Project instructions ``` **Pourquoi TodoApp ?** C'est assez petit pour tenir sur des slides, mais assez complexe pour démontrer de vrais problèmes : un backend avec patterns de routes et conventions de tests, un frontend avec hiérarchie de composants et tokens de design, et une structure monorepo où les sujets transverses (comme ajouter une nouvelle fonctionnalité) exigent une coordination des deux côtés. TodoApp rend concret le problème du vibe coding : sans structure, demander à Claude "add a notes feature" produit un endpoint `/api/notes` aléatoire qui ne suit pas les patterns `routes/todos.py`, une page autonome sans navigation sidebar, et zéro test. Avec un setup agentique complet, la même demande produit une route suivant les patterns existants, une page intégrée à la sidebar, et des tests alignés avec le style `test_todos.py`. ## L'arc du parcours : pourquoi cet ordre La présentation suit une séquence pédagogique délibérée. Chaque section déverrouille une nouvelle couche de capacité : ### Part 0: Introduction (Slides 1–4, no weight) **Objectif :** poser le cadre. Introduire TodoApp, définir vibe coding et montrer la destination. - Title slide établit la métaphore du parcours - Example Project montre la transformation : comparaison avant/après de TodoApp — structure projet nue vs structure avec configuration Claude Code complète (.claude/, CLAUDE.md, .mcp.json, etc.) - "What is Vibe Coding?" crée la baseline 0% — le point de douleur - Journey Map fournit une TOC cliquable montrant tout le chemin à venir ### Part 1: Prerequisites (Slides 5–9, no weight) **Objectif :** installer Claude Code et le faire tourner. C'est purement logistique — pas encore de pratiques d'ingénierie. - Installation, authentification, première session, aperçu d'interface - Pas de poids, parce que savoir installer un outil n'améliore pas la qualité du code - La "first session" EST du vibe coding — c'est intentionnel, pour que le développeur fasse l'expérience directe de l'état 0% ### Part 2: Better Prompting (Slides 10–17, Level: Low) **Objectif :** première vraie amélioration. De meilleurs inputs produisent de meilleurs outputs, même sans configuration projet. - **Good vs Bad Prompts :** prompts spécifiques et scopés vs demandes vagues. L'amélioration la plus simple possible. - **Providing Context :** utiliser `@files` pour donner à Claude le code dont il a besoin. Réduit immédiatement les hallucinations. - **Context Window & /compact :** comprendre la fenêtre de contexte finie évite les réponses dégradées dans les longues sessions. - **Plan Mode :** `/plan` force la réflexion avant le code. Évite l'effort gaspillé sur de mauvaises approches. **Pourquoi niveau Low :** le prompting est fondamental mais limité. Il améliore les interactions individuelles, mais ne crée pas de connaissance projet durable. Chaque session repart de zéro. ### Part 3: Project Memory (Slides 18–24, Level: Medium) **Objectif :** le saut de la connaissance de session vers la connaissance projet. Claude se souvient maintenant entre les sessions. - **CLAUDE.md & /init :** le "README pour Claude" du projet. Établit architecture, stack technique et conventions. C'est le fichier le plus impactant. - **What to Include :** conseils pratiques pour écrire un contenu CLAUDE.md efficace (moins de 150 lignes, focus sur ce que Claude doit savoir). - **Rules :** conventions scopées par chemin dans `.claude/rules/`. Les règles sont un multiplicateur — elles s'appliquent automatiquement à chaque fichier correspondant, imposant la cohérence sans effort développeur. Une seule règle `backend-testing.md` garantit que chaque test suit le même pattern pour toujours. **Pourquoi niveau Medium :** la mémoire projet transforme Claude d'un outil stateless en collaborateur conscient du contexte. Mais la connaissance seule ne crée pas de workflows. ### Part 4: Structured Workflows (Slides 25–28, Level: Medium) **Objectif :** approches systématiques qui évitent l'effort gaspillé et améliorent la qualité d'exécution. - **Task Lists :** découper le travail complexe en étapes suivables. Évite le scope drift et garantit la complétude. - **Model Selection :** choisir le bon modèle (Opus pour l'architecture, Sonnet pour l'implémentation, Haiku pour les tâches rapides) optimise coût et qualité. **Pourquoi toujours Medium :** les workflows sont importants mais restent des concepts relativement simples. Ils construisent sur la mémoire projet de la Part 3 et l'utilisent plus systématiquement. Le passage à High arrive avec la connaissance de domaine. ### Part 5: Domain Knowledge (Slides 29–33, Level: High) **Objectif :** expertise réutilisable, à la demande. Les skills sont le pont entre mémoire statique (CLAUDE.md/Rules) et agents dynamiques. - **What Are Skills :** skills comme connaissance de domaine packagée que Claude charge quand c'est pertinent. Le concept de divulgation progressive. - **Creating Skills :** pratique : construire un skill `frontend-conventions` pour TodoApp qui enseigne tokens Tailwind, patterns de composants et intégration sidebar. - **Skill Frontmatter & Invocation :** détails techniques : frontmatter YAML, invocation manuelle vs auto-découverte, option `context: fork`. **Pourquoi niveau High :** les skills sont le premier concept "multiplicateur" — une définition de skill améliore chaque interaction future dans son domaine. Mais les skills sont de la connaissance passive ; ils ont besoin d'agents pour devenir actifs. ### Part 6: Agentic Engineering (Slides 34–46, Level: High) **Objectif :** la destination couverte dans cette présentation. Agents autonomes et spécialisés qui se coordonnent pour construire des fonctionnalités end-to-end. - **What Are Agents :** le concept de sous-agents spécialisés avec outils contraints et skills préchargés. - **Frontend Engineer Agent :** agent concret qui utilise les conventions frontend de TodoApp, ajoute les routes à la sidebar, suit les tokens de design. La comparaison avant/après montre la transformation. - **Backend Engineer Agent :** agent parallèle pour le backend — suit les patterns de routes FastAPI, modèles SQLAlchemy, écrit des tests alignés avec le style existant. - **Commands & Orchestration :** pattern capstone : Command → Agent → Skills. Une seule commande `/add-feature` coordonne agents frontend + backend, chacun avec ses skills, pour livrer une fonctionnalité complète. C'est le sommet architectural. - **Hooks & MCP :** automatisation de cycle de vie (pre-commit checks, notifications sonores) et intégration d'outils externes. La couche finale d'automatisation. - **Command → Agent → Skills :** diagramme d'architecture complet. Montre comment tout se connecte : les commandes invoquent les agents, les agents chargent les skills, les skills fournissent la connaissance. C'est la slide de compréhension "High level". **Pourquoi niveau High :** cette section couvre les pratiques à plus forte valeur enseignées dans cette présentation. Tout ce qui précède y mène. Orchestration et workflows agentiques représentent le plafond de ce cours — le Pro complet (équipes multi-agents, patterns d'orchestration avancés) est hors périmètre de cette présentation. ### La slide High Level (Slide 44) Le moment de célébration. Montre la configuration complète de TodoApp : - CLAUDE.md pour le contexte projet - Rules pour conventions scopées par chemin - Skills pour connaissance de domaine - Agents pour exécution cohérente - Commands pour workflows orchestrés - Hooks pour automatisation de cycle de vie - Serveurs MCP pour outils externes ### Appendix (Slides 47+, no weight) **Objectif :** matériel de référence. Chaque commande, paramètre et option de configuration. Pas de poids car ce sont des lookup de référence, pas des jalons du parcours. Inclut : usage des outils, toutes les commandes slash, workflows commit/PR, options de personnalisation, astuces de débogage et règles d'or. ## Comment utiliser ce framework lors de l'édition des slides Quand tu crées ou modifies des slides, considère : 1. **Où ce concept se situe-t-il dans le parcours ?** Une slide sur "meilleurs messages d'erreur dans les prompts" appartient à la Part 2 (prompting, niveau Low). Une slide sur "agent memory scopes" appartient à la Part 6 (agentic, niveau High). 2. **Quel est l'avant/après ?** Chaque slide significative doit montrer implicitement ou explicitement le contraste : ce qui se passe au niveau Low (vibe coding) vs avec cette technique. Utilise TodoApp pour rendre ça concret. 3. **L'assignation de niveau est-elle juste ?** Les transitions de niveau ont lieu aux frontières de sections Part. Les slides individuelles dans une section héritent du niveau de section. 4. **Est-ce que ça construit sur ce qui précède ?** Les Skills supposent que le développeur connaît déjà CLAUDE.md et Rules. Les Agents supposent qu'il connaît les Skills. Les Commands supposent qu'il connaît les Agents. Ne référence jamais un concept avant sa section. 5. **Utilise TodoApp.** Les explications abstraites perdent l'audience. Montre le vrai code `routes/todos.py`, le vrai composant `Sidebar.tsx`, le vrai contenu `CLAUDE.md`. L'exemple fil rouge est ce qui rend le framework tangible. ## Tableau de référence des transitions de niveau | Slide | Nom de slide | data-level | Label de niveau | |-------|--------------|------------|-----------------| | 10 | Better Prompting (section divider) | `data-level="low"` | Low | | 18 | Project Memory (section divider) | `data-level="medium"` | Medium | | 29 | Domain Knowledge (section divider) | `data-level="high"` | High | | 34 | Agentic Engineering (section divider) | `data-level="high"` | High | Toutes les autres slides héritent du niveau du dernier attribut `data-level` défini avant elles. Les slides 1–9 (Intro + Prerequisites) n'ont pas de niveau et gardent la barre masquée jusqu'à la slide 2, qui affiche "Low" (les slides 2–9 sont avant la première transition de niveau à la slide 10, donc la barre reste vide/zéro jusqu'à la slide 10). **Note :** la présentation principale (`presentation/index.html`) plafonne au niveau **High** — `data-level="pro"` n'est pas utilisé. Le tick Pro reste visible sur la journey bar comme plafond théorique, mais le remplissage ne l'atteint jamais. La présentation vidéo (`1-video-workflow.html`) plafonne au niveau **Medium**.