Код, который вы не читали

Девять файлов за сорок секунд

До сих пор схема работы была такой: вы описываете, что хотите, агент делает, вы смотрите на результат в браузере. Пока проект помещался в пару файлов, этого хватало. Теперь представьте вечер третьего дня. Вы просите: «добавь в заметки тёмную тему». Агент шуршит секунд сорок и отчитывается: изменено девять файлов.

Девять. Вы открываете приложение — тёмная тема на месте, выглядит прилично. И тут появляется неприятная мысль: а что ещё он поменял в этих девяти файлах? После урока про ошибки вы знаете, что ломается не всегда сразу: правка в одном месте аукается в другом через день.

Варианта, кажется, два. Первый — прочитать все девять файлов от начала до конца. Это сотни строк, на них уйдёт вечер, и половину вы пока не поймёте. Второй — поверить на слово. Тогда проект держится на честном слове программы, которая, как мы видели в первом уроке, уверенно продолжает текст, а не читает ваши мысли.

Есть третий вариант, и им пользуются все разработчики без исключения: не читать всё — читать только то, что изменилось.

Дифф: список изменений

Diff (дифф) — список изменений: какие строки убраны из файлов, какие добавлены. Агент трогал девять файлов, но в каждом поменял по нескольку строк — остальное осталось как было. Дифф показывает только эти строки, поэтому он обычно в десятки раз короче самих файлов.

Прочитаем один дифф вместе. Вы просили: после сохранения заметки показывать сообщение «Сохранено». Вот что сделал агент:

 function saveNote(text) {
-  localStorage.setItem("note", text);
+  localStorage.setItem("note", text.trim());
+  showMessage("Заметка сохранена");
 }
 saveNote(input.value);

Шесть строк. Правила чтения:

• строка с - (в редакторе она красная) — так было, этой строки больше нет;
• строка с + (зелёная) — так стало, эта строка добавлена;
• строка без знака не менялась — она здесь для контекста, чтобы было видно, где именно случилась правка.

Что произошло? Одну строку агент заменил похожей: было text, стало text.trim(). И добавил новую: showMessage("Заметка сохранена") — это ровно то, что вы просили. Даже не зная, что такое localStorage, вы видите рисунок правки: маленькое изменение в строке сохранения плюс одна новая строка с сообщением. Масштаб соответствует просьбе.

А вот trim() вы не просили. Что это? Здесь работает правило, которое стоит запомнить первым: не понимаете правку — спросите агента «объясни этот дифф». Он ответит: trim() убирает пробелы по краям текста, чтобы заметка из одних пробелов не считалась настоящей. Звучит разумно — и теперь это правка, которую вы приняли осознанно, а не пропустили не глядя.

Настораживать должен не непонятный код, а несоответствие масштаба. Вы просили добавить сообщение, а в диффе исчезли тридцать строк? Такое бывает: агент решил «заодно навести порядок». Заметить это по диффу — секунды. По самим файлам — никогда.

Все инструменты — Claude Code, Cursor, Copilot — показывают дифф перед правкой или сразу после: интерфейсы разные, зелёное и красное везде одни и те же.

Дифф отвечает на вопрос «что изменилось». Но предположим, ответ вам не понравился: правка плохая, приложение сломалось. Дифф — только просмотр, отменить он ничего не может. Нужна кнопка «вернуть, как было вчера».

Git: машина времени

Git — программа, которая ведёт историю проекта. Она стоит за кулисами почти каждого проекта в мире, и агенты отлично умеют с ней работать. Новичку из неё нужны два понятия.

Commit (коммит) — именованный снимок всего проекта в конкретный момент. Не одного файла — всех сразу. Ближайшая аналогия — сохранение в игре: прошли сложное место, нажали «сохранить», и что бы ни случилось дальше, к этой точке можно вернуться. У снимка есть подпись, которую вы пишете сами: «заметки сохраняются», «тёмная тема готова». По подписям потом читается вся история проекта.

Ветка — параллельная вселенная для эксперимента. Вы говорите «создай ветку experiment», и дальше правки живут в ней, а основная версия (её обычно зовут main) стоит нетронутой. Эксперимент удался — ветку вливают в основную. Провалился — ветку выбрасывают целиком, и main даже не узнает, что что-то происходило.

Запустите сценарий на схеме внизу и посмотрите, как две идеи развиваются параллельно от одного снимка и не мешают друг другу.

Команд для старта достаточно трёх:

git status     # что изменилось с последнего снимка
git add -A && git commit -m "заметки сохраняются"   # сделать снимок
git restore .  # вернуть все файлы к последнему снимку

Зубрить их не нужно: агент наберёт за вас. Понимать нужно другое — что просить. Просьбы формулируются словами, а не командами:

• «покажи, что изменилось с последнего коммита» — статус и дифф;
• «сделай коммит с подписью такой-то» — снимок;
• «откати всё к последнему коммиту» — возврат к снимку;
• «создай ветку для эксперимента» — параллельная вселенная.

Итак, инструмент есть. Но инструмент без привычки не защищает: ремень безопасности работает, только если пристёгиваться до поездки, а не во время аварии. Осталось договориться, когда именно делать снимки.

Золотое правило вайбкодинга

Снимок до сессии агента. Снимок после того, как вы проверили результат. Всё правило.

Цикл целиком выглядит так: коммит «всё работает» — просьба агенту — читаем дифф — проверяем руками в браузере — если хорошо, коммит с понятной подписью; если плохо — «откати к последнему коммиту», и вы потеряли одну просьбу, а не вечер.

Сессия без снимка — игра без сохранений. Пока всё идёт гладко, разницы не видно. Разница проявляется при первой серьёзной поломке: со снимком вы теряете десять минут, без снимка — всё, что наработали с начала проекта.

Запустите сценарий — это безопасная сессия от начала до конца: снимок, работа агента, проверка, снимок.

Обратите внимание, где в цикле стоит проверка: перед вторым снимком, а не после. Коммит фиксирует состояние «проверено, работает», а не «агент сказал, что готово». Снимок непроверенного кода — сохранение в игре за секунду до пропасти: формально сохранились, а возвращаться некуда.

Правило звучит просто и, возможно, занудно. Цену этого занудства лучше один раз увидеть на чужом проекте, чем на своём.

Вечер, когда проект исчез

Типичная история. Заметки работали: сохранялись, открывались, тёмная тема на месте. Вечером пришла идея: пусть заметок будет много, со списком. Просьба агенту — тот переписывает шесть файлов. Список появился, но сохранение отвалилось. «Почини сохранение» — агент правит ещё четыре файла, теперь пропал и список. Ещё просьба, ещё волна правок. Через час не работает ничего, а главное — работавшей версии больше не существует. Она была набором файлов, и эти файлы агент трижды переписал поверх. Ctrl+Z не спасает: отмена в редакторе отматывает по одной правке в одном файле, а тут три волны изменений в десяти файлах — не отмена, а археология.

Точка невозврата пряталась в самом начале вечера: рабочая версия существовала в единственном экземпляре, и первая же правка начала её затирать.

Теперь та же история со снимком. Перед идеей со списком — коммит «одна заметка, всё работает». Дальше те же неудачные правки, тот же час мучений, но в любой момент доступна фраза: «откати всё к последнему коммиту». Секунда — и рабочая версия на месте, как будто вечера не было. Потерян только неудачный эксперимент — ровно то, что и должно быть потеряно.

Запустите сценарий: серия неудачных правок и возврат к снимку одной командой.

А ветка experiment сделала бы вечер ещё дешевле. Все правки со списком жили бы в параллельной вселенной, main остался бы нетронутым — и откатывать было бы вообще нечего. Для рискованных затей это лучший вариант: сначала ветка, потом эксперименты.

Теперь у вас есть кнопка отмены

Страх «агент всё переписал» держался на двух вещах: правок не видно и их не отменить. Обе закрыты. Дифф делает правки видимыми — читать его вы уже умеете, а непонятное просите объяснить. Git делает правки обратимыми — снимок до сессии, снимок после проверки, ветка для рискованного. Просьбы «покажи дифф» и «сделай коммит» становятся такой же частью разговора с агентом, как сама постановка задачи.

Но посмотрите, на чём держится золотое правило: второй снимок делается после проверки. А как вы проверяли заметки до сих пор? Открыли, потыкали, вроде сохраняет. «Не сломалось» — ещё не значит «работает»: пустую заметку оно переживёт? А заметку в тысячу строк? А два сохранения подряд? Проверять это руками после каждой правки не будет никто, включая вас. В следующем уроке мы заведём проверки, которые запускаются сами, — тесты — и перестанем верить на слово даже себе.