Myślenie przez Git Diff (Sztuka weryfikacji zmian)

1. Przegląd koncepcji i problem systemowy

Przez dekady kluczową umiejętnością programisty była szybkość pisania: ile setek linii kodu potrafiłeś wystukać na klawiaturze w ciągu zmiany.

W erze autonomicznych agentów i vibe-codingu ta mechaniczna umiejętność straciła na wartości. Każdy model językowy generuje 1000 linii kodu w 8 sekund. Tym samym główną wartością inżyniera stało się sztuka szybkiej analizy diffów (Diff-First Mindset).

Nie jesteś już autorem każdego pojedynczego znaku — jesteś Redaktorem Naczelnym i Architektem. Twoja praca polega na tym, by spojrzeć na ekran z czerwono-zielonymi zmianami i w 10 sekund podjąć deterministyczną decyzję:

• „Zielony kod jest poprawny, ale czerwony usunął krytyczną walidację sesji – odrzucam!”
• „Zmiany są czyste, architektura nie została złamana – commitujemy!”

Model mentalny: podobnie jak redaktor naczelny magazynu nie pisze wszystkich felietonów sam, lecz koryguje odbitki przed drukiem, tak senior engineer filtruje dane wyjściowe agentów przez sito Git Diff.

┌─────────────────────────────────────────────────────────────┐
│                 ARCHITEKTURA FILTRU DIFF                    │
├─────────────────────────────────────────────────────────────┤
│ 1. PROMPT DO AGENTA:                                        │
│    „Dodaj buforowanie sesji przez Redis w module auth.ts”   │
├─────────────────────────────────────────────────────────────┤
│                          │                                  │
│                          ▼ Autonomiczna generacja           │
├─────────────────────────────────────────────────────────────┤
│ 2. NIEPREZENTOWALNY SUROWY WYJŚCIE (zmieniono 4 pliki)      │
├─────────────────────────────────────────────────────────────┤
│                          │                                  │
│                          ▼ Bramka kontrolna DIFF-REVIEW     │
├─────────────────────────────────────────────────────────────┤
│ 🛑 TAKSONOMIA SPRAWDZENIA:                                  │
│    • CZERWONE LINIE (-): Czy nie usunięto logowania i typów?│
│    • ZIELONE LINIE (+): Czy nie ma halucynowanych pakietów? │
│    • STATYSTYKA: Jeśli proszono o 5 linii, a zmieniono 120 —│
│      NATYCHMIASTOWE ODRZUCENIE!                             │
└─────────────────────────────────────────────────────────────┘

2. Przykład inżynierski: anatomia prawidłowego diffu

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);
 }

Patrząc na ten fragment, doświadczony inżynier od razu weryfikuje trzy rzeczy:

1. Czerwony minus: Usunięto dokładnie dług techniczny (tymczasowy hack), zgodnie z wymaganiami ticketu.
2. Zielony plus: Wywołanie getSubscriptionDiscount jest asynchroniczne i dodano await.
3. Kontrakt: Typ zwracanej wartości pozostaje liczbowy, brak efektów ubocznych wpływających na sąsiednie metody. Można pewnie kliknąć Accept.

3. Praktyczne komendy CLI do inspekcji diffu w terminalu

Wszystkie nowoczesne IDE (Cursor, VS Code, Windsurf) posiadają graficzne UI dla diffów, ale prawdziwa kontrola uzyskiwana jest w terminalu za pomocą precyzyjnych flag Git:

# 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. Cztery złote zasady higieny czytania Diff

1. Fokus na czerwonym (Red First): Nowy kod (zielony) prawie zawsze wygląda gładko. Najgroźniejsze regresje i luki bezpieczeństwa zawsze kryją się w usuniętych czerwonych liniach.
2. Sprawdzanie importów: Zwróć uwagę na pierwsze 10 linii pliku. Czy agent nie dodał zewnętrznej biblioteki (np. lodash czy axios), jeśli projekt posiada już natywne narzędzia?
3. Reguła limitu objętości (Diff Budget): Jeśli prosiłeś model o zmianę jednej walidacji formularza, a diff pokazuje +180 -95 linii w 5 plikach – nie próbuj tego czytać. Kliknij Reject i uruchom ponownie prompt ze sztywnym ograniczeniem: "Zmień tylko funkcję validateForm w pliku Form.tsx, nie dotykaj reszty kodu".
4. Akceptacja linia po linii: Unikaj przycisku „Accept All” w skomplikowanych plikach. Akceptuj zmiany blokami (Hunk by Hunk).

5. Podsumowanie inżynierskie

Diff-First Mindset to kluczowa umiejętność przetrwania w 2026 roku. Chroni ona Twoją bazę kodu przed degradacją i syntetycznym śmieciem, przekształcając szaleńczą szybkość sieci neuronowych w stabilny i niezawodny wynik biznesowy.