Penser en Git Diff (L'art de la revue de code)

1. Vue d'ensemble du concept et problème systémique

Pendant des décennies, la compétence principale d'un développeur était considérée comme la vitesse de frappe : combien de centaines de lignes de code vous pouvez taper par shift sur un clavier.

À l'ère des agents autonomes et du vibe coding, cette compétence mécanique a perdu toute valeur. N'importe quel modèle de langage génère 1 000 lignes de code en 8 secondes. Dès lors, la valeur principale de l'ingénieur est devenue l'art de l'analyse rapide des diffs (Diff-First Mindset).

Vous n'êtes plus l'auteur de chaque caractère individuel — vous êtes Rédacteur en Chef et Architecte. Votre travail consiste à regarder l'écran avec ses changements rouges et verts et à prendre une décision déterministe en 10 secondes :

• « Le code vert est correct, mais le rouge a supprimé une vérification critique de session — je rejette ! »
• « Les modifications sont propres, l'architecture n'est pas cassée — on commit ! »

Modèle mental : tout comme un rédacteur en chef de magazine ne rédige pas toutes les colonnes lui-même, mais relit les épreuves avant impression, l'ingénieur senior filtre les sorties des agents à travers le tamis du Git Diff.

┌─────────────────────────────────────────────────────────────┐
│                 ARCHITECTURE DU FILTRE DIFF                  │
├─────────────────────────────────────────────────────────────┤
│ 1. PROMPT POUR L'AGENT :                                    │
│    « Ajoute une mise en cache des sessions via Redis dans   │
│      le module auth.ts »                                    │
├─────────────────────────────────────────────────────────────┤
│                          │                                  │
│                          ▼ Génération autonome              │
├─────────────────────────────────────────────────────────────┤
│ 2. SORTIE BRUTE NON PRÉSENTABLE (4 fichiers modifiés)       │
├─────────────────────────────────────────────────────────────┤
│                          │                                  │
│                          ▼ Passerelle de contrôle DIFF-REVIEW│
├─────────────────────────────────────────────────────────────┤
│ 🛑 TAXONOMIE DE VÉRIFICATION :                              │
│    • LIGNES ROUGES (-) : Les logs et les types ont-ils été  │
│      supprimés ?                                            │
│    • LIGNES VERTES (+) : Y a-t-il des paquets hallucinés ?  │
│    • STATISTIQUES : Si 5 lignes étaient demandées mais que  │
│      120 ont changé — REJET IMMÉDIAT !                      │
└─────────────────────────────────────────────────────────────┘

2. Exemple d'ingénierie : anatomie d'un diff correct

diff --git a/src/services/billing.ts b/src/services/billing.ts
--- a/src/services/billing.ts
+++ b/src/services/billing.ts
@@ -42,7 +42,9 @@ export async function calculateInvoice(user: UserProfile) {
-  // Тимчасовий хак: фіксована знижка для тестів
-  return user.cartTotal * 0.95;
+  // Перевірка активної підписки перед розрахунком
+  const discountRate = await getSubscriptionDiscount(user.id);
+  return user.cartTotal * (1 - discountRate);
 }

En regardant ce fragment, un ingénieur expérimenté vérifie immédiatement trois choses :

1. Le moins rouge : La dette technique spécifique (le hack temporaire) a été supprimée, comme requis dans le ticket.
2. Le plus vert : L'appel getSubscriptionDiscount est asynchrone et await a été ajouté.
3. Le contrat : Le type de retour reste numérique, sans effets secondaires sur les méthodes voisines. On peut appuyer en confiance sur Accept.

3. Commandes CLI pratiques pour l'inspection des diffs dans le terminal

Tous les IDE modernes (Cursor, VS Code, Windsurf) disposent d'une interface graphique pour les diffs, mais le véritable contrôle s'exerce dans le terminal via des flags Git précis :

# 1. Швидка зведена статистика: скільки рядків додано/видалено у кожному файлі
git diff --stat

# 2. Перегляд змін лише для конкретного файлу без стороннього шуму
git diff src/lib/auth.ts

# 3. Перегляд змін, які вже додані до staging (перед git commit)
git diff --staged

# 4. Інтерактивний покроковий розбір (Patch Mode): дозволяє приймати або відхиляти шматки файлу (hunk) по черзі
git checkout -p

# 5. Ігнорування змін пробілів та форматування, щоб побачити чисту логіку
git diff -w --ignore-blank-lines

4. Les quatre règles d'or de l'hygiène de lecture des Diffs

1. Focus sur le rouge (Red First) : Le nouveau code (vert) semble presque toujours fluide. Les régressions les plus dangereuses et les failles de sécurité se cachent toujours dans les lignes rouges supprimées.
2. Vérification des imports : Prêtez attention aux 10 premières lignes du fichier. L'agent a-t-il ajouté une bibliothèque tierce (par exemple, lodash ou axios) alors que le projet dispose déjà d'outils natifs ?
3. Règle du budget de diff (Diff Budget) : Si vous avez demandé au modèle de modifier une seule validation de formulaire, mais que le diff affiche +180 -95 lignes dans 5 fichiers — n'essayez pas de tout relire. Cliquez sur Reject et relancez le prompt avec une contrainte stricte : "Modifie uniquement la fonction validateForm dans le fichier Form.tsx, ne touche pas au reste du code".
4. Acceptation ligne par ligne : Évitez le bouton « Accept All » dans les fichiers complexes. Validez les modifications bloc par bloc (Hunk by Hunk).

5. Conclusion d'ingénierie finale

Le Diff-First Mindset est la compétence de survie primordiale en 2026. Elle protège votre base de code contre la dégradation progressive et le bruit synthétique, transformant la vitesse effrénée des réseaux neuronaux en une stabilité fiable et en résultats business solides.