Читай код, который не писал

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

Вот переосмысление. Чтобы владеть своим продуктом, не нужно писать код руками. Но нужно уметь его читать — хотя бы настолько, чтобы ориентироваться. Чтение — гораздо более низкая планка, чем письмо, и это разница между «рулить продуктом» и «быть в нём пассажиром».

Почему это важно, хотя пишет ИИ

Инструменты, которые просто выплёвывают приложения, тихо ставят на то, что ты никогда не заглянешь внутрь. Это работает до того дня, когда нужно изменение, которое инструмент не сделает, или баг, который он не видит. В этот момент те, кто умеет читать свой код, едут дальше, а те, кто не умеет, застревают в ожидании, что инструмент их спасёт.

Понимание — это и есть твоё преимущество. ИИ берёт на себя печать; твоя задача — знать, что ты строишь, достаточно хорошо, чтобы им управлять.

Сначала карта, потом детали

Не начинай с чтения первой строки первого файла. Начни с карты. Спроси ИИ:

«Проведи мне экскурсию по проекту. Какие тут основные папки, что делает каждая и где начинается и заканчивается пользовательский запрос?»

Ты строишь ментальную модель: эта папка — экраны, эта — данные, тут живёт логин. Файлы читать пока не нужно — нужно знать, какой файл открыть, когда сломается что-то конкретное.

Читай форму, а не каждое слово

Когда открываешь файл, ты не вычитываешь его. Ты ищешь форму:

• Названия. Функция с именем sendWelcomeEmail говорит, что делает, без чтения тела. Хорошие имена — бесплатная документация.
• Структура. Где файл начинается, какие у него основные куски, где заканчивается? Отступы показывают скелет.
• Края. Что файл принимает на вход и что отдаёт? Обычно этого хватает, чтобы понять, как он встроен.

Ты можешь понять, что делает кусок кода, задолго до того, как поймёшь как. Для управления продуктом «что» обычно достаточно.

Используй ИИ как переводчик

Суперсила вайбкодинга в том, что у тебя есть бесконечно терпеливый объясняющий. Вставь любой непонятный кусок и спроси:

«Объясни простым языком, что это делает. Я не программист».

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

Три вопроса, строящие настоящее понимание

Когда хочешь реально учиться у своего проекта, а не просто выживать в нём, спрашивай:

1. «Что сломается, если я это удалю?» — показывает, за что отвечает кусок.
2. «Откуда берутся эти данные и куда уходят?» — прослеживает поток, а это большая часть понимания.
3. «Есть ли способ проще?» — иногда ответ «да», и ты узнаёшь почему было сделано исходно.

Это превращает пассивное чтение в разговор, и понимание закрепляется.

Ты учишь город, а не зубришь карту

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

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