Module 8 — Workflow Research → Plan → Implement — Context Engineering — le pack Praktik

Objectif

À la fin de ce module, tu auras une méthode de production éprouvée pour travailler sur des codebases brownfield avec des agents de codage.

Le workflow en 3 étapes

Research → Plan → Implement
   ↑         ↑         ↓
  Human    Human    Agent (+ human review)

Principe : L’humain review le research et le plan (levier max). L’agent implémente. Pas l’inverse.

Étape 1 : Research

Objectif : Comprendre le codebase, identifier les fichiers pertinents, et formuler des hypothèses.

Prompt type (à adapter selon ton agent) :

# Research Task

## Goal
[Description claire du bug ou de la feature]

## Context
- Codebase : [langage, framework, taille approximative]
- Entry points connus : [si applicable]
- Contraintes : [ne pas casser X, maintenir compatibilité Y]

## Deliverable
Un document de recherche structuré avec :
1. Fichiers pertinents identifiés
2. Flow d'information tracé
3. Hypothèses de cause (pour un bug) ou d'approche (pour une feature)
4. Recommandation sur par où commencer

Durée : 15-45 min selon la complexité Output : Document markdown structuré

Étape 2 : Plan

Objectif : Décrire les étapes exactes, les fichiers à modifier, et les tests par phase.

Prompt type :

# Implementation Plan

## Based on Research
[Insérer le document de research]

## Plan
Phase 1 : [Action concrète]
- Files : [liste]
- Tests : [comment vérifier]

Phase 2 : [Action concrète]
- Files : [liste]
- Tests : [comment vérifier]

## Verification
[Comment valider que tout fonctionne à la fin]

Durée : 10-30 min Output : Plan markdown avec phases numérotées

Étape 3 : Implement

Objectif : Exécuter le plan phase par phase.

Prompt type :

# Implementation

## Plan
[Insérer le plan approuvé]

## Current Phase
Phase N : [la phase en cours]

## Instructions
- Implémenter cette phase uniquement
- Ne pas passer à la phase suivante sans validation
- Après chaque phase, mettre à jour le fichier de status

Durée : Variable (5 min à 2h par phase) Output : Code + tests + fichier de status mis à jour

La compaction entre phases

Après chaque phase vérifiée, compacter le status :

## Status Update (après Phase 1)

### Completed
- [x] auth/controller.ts : fix regex email
- [x] tests/auth.test.ts : 3 nouveaux cas de test

### Current State
- 17 tests passants, 0 échouant

### Next
Phase 2 : Ajouter retry logic sur Redis

Pourquoi ça marche

Étape	Levier humain	Pourquoi c’est critique
Research	Haut	Une mauvaise compréhension = mauvais plan = mauvais code
Plan	Haut	Une mauvaise ligne dans le plan = centaines de lignes de code mauvaises
Implement	Bas	Le code est facile à corriger si le plan est bon

Citation clé :

“Une mauvaise ligne de code est… une mauvaise ligne de code. Mais une mauvaise ligne de plan peut entraîner des centaines de mauvaises lignes de code. Et une mauvaise ligne de research peut t’envoyer dans une direction complètement fausse.”

Exemple concret : BAML (300K LOC Rust)

Contexte : Amateur Rust, jamais touché le codebase.

Research (30 min) :

Exploration des fichiers liés au bug
Traçage du flow d’assertions
Hypothèse : regex de validation trop stricte

Plan (15 min) :

Phase 1 : Localiser et corriger la regex
Phase 2 : Ajouter des cas de test edge cases
Phase 3 : Vérifier la rétrocompatibilité

Implement (30 min) :

Exécution phase par phase
PR approuvée le lendemain matin

Résultat : Bugfix merged en 1h de travail effectif.

Checklist de validation

J’ai un document de research structuré avant de planifier
Mon plan a des phases avec fichiers et tests explicites
Je compacte le status après chaque phase vérifiée
Je review le research et le plan avant d’implémenter
Je ne laisse pas l’agent improviser hors du plan

Sauter le research pour aller plus vite. → Dexter Horthy a essayé : “J’ai lancé un plan sans research pour voir. Le plan avec research a corrigé le bug au bon endroit avec les bonnes conventions de test. L’autre plan aurait marché aussi, mais moins bien.” 30 min de research = 2h de refacto en moins.

Prochaine étape

→ Module 9 (Context engineering par modèle) pour adapter selon Claude vs Codex