Мислення через Git Diff (Мистецтво перевірки правок)(Мислення через Git Diff: як стати головним інженерним редактором згенерованого коду)

1. Огляд концепції та системна проблема

Десятиліттями головною навичкою програміста вважалася швидкість набору тексту: скільки сотень рядків коду за зміну ви можете вистукати пальцями по клавіатурі.

В еру автономних агентів та вайбкодингу ця механічна навичка девальвувала. Будь-яка мовна модель генерує 1 000 рядків коду за 8 секунд. Відтак головною цінністю інженера стало мистецтво швидкого аналізу дифу (Diff-First Mindset).

Ви більше не автор кожного окремого символу — ви Головний Редактор та Архітектор. Ваша робота полягає в тому, щоб поглянути на екран із червоно-зеленими змінами і за 10 секунд прийняти детерміноване рішення:

• «Зелений код коректний, але червоний видалив критичну перевірку сесії — відхиляю!»
• «Зміни чисті, архітектура не зламана — коммітимо!»

Ментальна модель: як головний редактор журналу не пише всі колонки сам, а вичитує гранки перед друком, так і senior-інженер фільтрує вихідні дані агентів через сито Git Diff.

┌─────────────────────────────────────────────────────────────┐
│                 АРХІТЕКТУРА ДИФ-ФІЛЬТРАЦІЇ                  │
├─────────────────────────────────────────────────────────────┤
│ 1. ПРОМПТ ДО АГЕНТА:                                        │
│    «Додай кешування сесій через Redis у модуль auth.ts»     │
├─────────────────────────────────────────────────────────────┤
│                          │                                  │
│                          ▼ Автономна генерація              │
├─────────────────────────────────────────────────────────────┤
│ 2. НЕПРЕЗЕНТАБЕЛЬНИЙ СИРИЙ ВИХІД (4 файли змінено)         │
├─────────────────────────────────────────────────────────────┤
│                          │                                  │
│                          ▼ Контрольний шлюз DIFF-REVIEW     │
├─────────────────────────────────────────────────────────────┤
│ 🛑 ТАКСОНОМІЯ ПЕРЕВІРКИ:                                    │
│    • ЧЕРВОНІ РЯДКИ (-): Чи не стерто логування та типи?    │
│    • ЗЕЛЕНІ РЯДКИ (+): Чи немає галюцинованих пакетів?     │
│    • СТАТИСТИКА: Якщо просили 5 рядків, а змінилося 120 —   │
│      НЕГАЙНИЙ REJECT!                                       │
└─────────────────────────────────────────────────────────────┘

2. Інженерний приклад: анатомія правильного дифу

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

Дивлячись на цей фрагмент, досвідчений інженер одразу верифікує три речі:

1. Червоний мінус: Видалено саме технічний борг (тимчасовий хак), як і вимагалося в тікеті.
2. Зелений плюс: Виклик getSubscriptionDiscount є асинхронним і додано await.
3. Контракт: Тип поверненого значення залишається числовим, побічних ефектів на сусідні методи немає. Можна впевнено натискати Accept.

3. Практичні CLI-команди для інспекції дифу в терміналі

Усі сучасні IDE (Cursor, VS Code, Windsurf) мають графічні UI для дифу, але справжній контроль досягається в терміналі через точні прапорці 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. Чотири золоті правила гігієни читання Diff

1. Фокус на червоному (Red First): Новий код (зелений) майже завжди виглядає гладко. Найнебезпечніші регресії та дірки в безпеці завжди ховаються у видалених червоних рядках.
2. Перевірка імпортів: Зверніть увагу на перші 10 рядків файлу. Чи не додав агент сторонню бібліотеку (наприклад, lodash чи axios), якщо у проекті вже є нативні інструменти?
3. Правило ліміту обсягу (Diff Budget): Якщо ви просили модель змінити одну валідацію форми, а дифф показує +180 -95 рядків у 5 файлах — не намагайтеся його вичитувати. Натисніть Reject і перезапустіть промпт із жорстким обмеженням: "Зміни тільки функцію validateForm у файлі Form.tsx, не чіпай решту коду".
4. Line-by-line Accept: Уникайте кнопки «Accept All» у складних файлах. Приймайте зміни окремими блоками (Hunk by Hunk).

5. Підсумковий інженерний висновок

Diff-First Mindset — це головна навичка виживання у 2026 році. Вона захищає вашу кодову базу від поступової деградації та синтетичного сміття, перетворюючи шалену швидкість нейромереж на стабільний та надійний бізнес-результат.