Vibe Coding. Полное руководство

DRY — или как не утонуть в копиях

DRY — Don’t Repeat Yourself — самый простой и самый нарушаемый принцип в мире vibe coding.

Вот что происходит. Ты просишь ИИ: «Сделай страницу регистрации». Он делает. Работает. Ты просишь: «Теперь сделай страницу входа». Он делает. Тоже работает. Ты просишь: «Добавь восстановление пароля». Сделано.

Три страницы. Три формы. И в каждой — своя копия валидации email. Своя копия обработки ошибок. Своя копия стилей кнопок. Не потому что ИИ глуп. А потому что ИИ решает каждую задачу изолированно, если ты не скажешь ему иначе.

Через месяц ты меняешь дизайн кнопок. Меняешь в одном месте. Забываешь про два других. Пользователь видит три разных кнопки на трёх разных страницах. Продукт выглядит так, будто его делали три разных человека в трёх разных настроениях.

Принцип DRY в эпоху vibe coding означает: прежде чем просить ИИ создать что-то новое, спроси себя — нет ли уже чего-то похожего в проекте? И если есть — скажи ИИ использовать существующее, а не генерировать с нуля.

Это звучит просто. На практике это требует дисциплины, которой у большинства «вайб-кодеров» нет, потому что генерировать новое — приятно, а поддерживать существующее — скучно.

Модульность: стены, которые спасают

Модульность — это когда систему можно разделить на независимые части, каждая из которых делает одну вещь и делает её хорошо. Если одна часть сломается — остальные продолжают работать.

В обычной разработке модульность — это хорошая практика. В vibe coding — это вопрос выживания.

Почему? Потому что ИИ работает с контекстом. Чем больше кода ты скармливаешь ему в одном запросе, тем менее точным становится результат. Монолитный файл на 3000 строк — это кошмар для ИИ. Он теряет нить. Путает функции. Вносит изменения не туда.

Модульный проект — 20 файлов по 150 строк — это мечта. ИИ видит маленький, понятный модуль. Меняет только его. Не трогает остальное. Результат предсказуем.

Модульность в vibe coding — это не про «красивый код». Это про управляемость. Ты создаёшь стены между частями системы, чтобы ИИ не мог случайно снести несущую конструкцию, ремонтируя ванную.

Практическое правило: если файл больше 200 строк — разбей. Если функция делает больше одной вещи — раздели. Если модуль знает слишком много о другом модуле — изолируй. Не потому что так написано в учебнике. А потому что иначе ИИ превратит твой проект в карточный домик.

Роль Главного Редактора

Здесь нужно зафиксировать сдвиг мышления, который определяет всё остальное в этой книге.

Ты больше не программист. Ты — главный редактор.

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

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

Твоя работа — знать.

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

— Этот модуль делает одну вещь или десять? — Он дублирует что-то, что уже есть? — Он использует данные, к которым не должен иметь доступа? — Если я уберу его, сломается ли что-то ещё?

Это и есть «аудит ИИ-кода» — и это навык, который отделяет тех, кто строит реальные продукты, от тех, кто строит демо для Twitter.

Внутренняя библиотека суждений

Хороший редактор отличается от плохого одним: у него есть внутренняя библиотека суждений. Он читал достаточно текстов, чтобы мгновенно чувствовать — «это хорошо» или «что-то не так».

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

Как строить эту библиотеку, если ты не писал код десять лет?

Читай чужой код. Не для того, чтобы копировать — для того, чтобы видеть паттерны. Открой любой популярный open-source проект на GitHub. Посмотри на структуру. Как разделены файлы? Как названы функции? Где лежат тесты? Ты не обязан всё понимать. Ты тренируешь глаз.

Ломай свои проекты нарочно. Возьми рабочий проект и удали один файл. Что сломалось? Всё — значит, архитектура хрупкая. Только один экран — значит, модульность работает.

Проси ИИ объяснить. Это самый недооценённый приём: вместо «напиши мне код» скажи «объясни мне этот код как архитектор». ИИ расскажет, где связи сильные, где слабые, где потенциальные точки отказа. Ты не будешь писать — но ты будешь понимать.

Со временем эта библиотека суждений становится твоим главным активом. Не промпты. Не шаблоны. Не «секретные техники». А натренированное чутьё на то, что работает и что рухнет.

Инженерия как форма уважения

Последнее, что стоит сказать об инженерии, и это не про код.

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

Vibe coding снял барьер входа. Это великая вещь. Но снятый барьер входа — не отмена ответственности. Напротив: когда создавать софт может каждый, качество становится тем, что отличает серьёзный продукт от игрушки.

Инженерная дисциплина — это не противоположность вайбам. Это фундамент, на котором вайбы работают.

Глава 3. Роль Главного Редактора

Есть старая шутка про программистов: их работа — превращать кофе в код. Два монитора, механическая клавиатура, 14 часов печатания, стек технологий в резюме длиной в два экрана.

Эта эпоха закончилась. Не шутка — реальность.

Человек, который сегодня создаёт софт через ИИ, не печатает код. Он делает нечто принципиально иное: формулирует намерение, оценивает результат, корректирует направление. Снова и снова, с каждой итерацией сужая зазор между тем, что он хочет, и тем, что получает.

Это не программирование. Это редактура.

И разница между плохим и хорошим редактором — та же, что между человеком, который принимает первый черновик ИИ, и человеком, который доводит результат до точности.

Прежде чем говорить о том, как редактировать хорошо, разберём, как это делают плохо.

Типичный промпт новичка: «Сделай мне приложение для трекинга привычек».

ИИ послушно создаёт что-то. Экран. Кнопки. Какую-то логику. Это даже работает. Новичок восхищён.

Проблема в том, что ИИ принял за тебя 200 решений, о которых ты даже не подумал. Какая структура данных? Он выбрал. Где хранить? Он решил. Как выглядит «привычка» — с повторением, без, с напоминаниями, с аналитикой? Он додумал. Какой фреймворк? Он взял привычный.

Ты получил не свой продукт. Ты получил статистически среднее представление ИИ о том, что такое «трекер привычек». Это как попросить редактора журнала: «напиши статью про что-нибудь интересное». Он напишет. Но это будет его статья, не твоя.

Хороший промпт — это не описание результата. Это передача контекста и ограничений.

Управление ИИ как редактор работает на трёх уровнях. Каждый следующий — глубже, точнее и даёт лучший результат.

Уровень 1: Что. Большинство людей застревают здесь. «Сделай форму входа». «Добавь корзину». «Создай дашборд». Это уровень заказа в ресторане. Ты получишь что-то съедобное, но шеф-повар решает всё остальное.

Уровень 2: Что + Почему. «Сделай форму входа. Наша аудитория — люди старше 50, которые не доверяют технологиям. Поэтому форма должна быть максимально простой, с крупными элементами и без отвлекающих элементов». Теперь ИИ не просто выполняет задачу — он принимает решения в заданном направлении. Размер шрифта. Количество полей. Тон текста на кнопке. Всё выстраивается вокруг «почему».

Уровень 3: Что + Почему + Как не надо. «Сделай форму входа для людей старше 50. Не используй плейсхолдеры вместо лейблов — они исчезают и путают. Не делай пароль скрытым по умолчанию. Не добавляй OAuth-кнопки — „войти через Google“ пугает эту аудиторию». Это уровень, на котором ты закрываешь пространство для ошибок. Ты говоришь ИИ не только куда идти, но и куда не надо.

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