Vibe coding или AI Программирование: как начать с нуля и не потерять контроль над проектом

Раньше всё было довольно линейно. Хочешь сделать программу — сначала учишь язык, потом фреймворк, базы данных, Git, архитектуру, отладку. И только потом пытаешься собрать что-то своё. Сейчас порядок изменился. Можно открыть ChatGPT, Claude, Cursor или другой инструмент и просто описать идею:
«Мне нужно приложение, которое делает вот это».
→ Через несколько минут появляется первая версия.
→ Потом интерфейс.
→ Авторизация.
→ База.
→ Настройки.

И человек, который ещё вчера не считал себя программистом, внезапно понимает: «Я реально могу делать софт». И это, пожалуй, главное достоинство вайбкодинга.
ㅤ ㅤ

Пока проект маленький, всё выглядит почти идеально.
— Сделай кнопку.
— Готово.
— Добавь авторизацию.
— Сделано.
— Исправь ошибку.
— Исправлено.
Но проходит несколько недель. В проекте уже десятки или сотни файлов. Появляются обновления, сервер, реальные пользователи, несколько веток разработки. И однажды ИИ предлагает вам решение.
Вы смотрите на него и понимаете: мы уже делали это три дня назад.
Причём модель совершенно уверена, что предлагает что-то новое.
Именно здесь многие решают: «Ну понятно. Вайбкодинг подходит только для игрушек». Но проблема немного в другом. Проект просто стал слишком большим для режима бесконечного разговора с ИИ.
ㅤ

Мы делали Flow Bridge. Сначала задача была довольно понятной: автоматизировать нужный сценарий запуска Google Flow через Chrome. Пока программа работала только у меня, всё было относительно просто. Потом появились реальные установки. Около 50 пользователей. И сразу выяснилось, что: «работает у меня» и «работает как продукт» — совершенно разные вещи.
ㅤ ㅤ
- У одного человека после входа Google Flow не открывался.
- У другого запуск происходил только со второй попытки.
- У третьего программа повторно спрашивала ключ, хотя не должна была.
- На моём компьютере при этом всё продолжало работать.
И вот здесь запрос: «Исправь запуск» уже становится опасным. Потому что ИИ может исправить один сценарий и случайно сломать три работающих.
ㅤ ㅤ
Нам пришлось начать фиксировать:
- что сейчас является рабочим состоянием;
- какое поведение считается правильным;
- что разрешено менять;
- что менять нельзя;
- как мы докажем, что исправление действительно работает.
ㅤ ㅤ

Это был ещё один полезный момент.
158 тестов — PASS.
Вроде бы отличный результат. Можно закрывать задачу. Но дополнительная проверка обнаружила критические ошибки.
После этого у меня окончательно закрепилось правило:
1) «ИИ сказал, что готово» — это не доказательство.
2) Даже если: «Тесты прошли» — не всегда достаточное доказательство.
ㅤ ㅤ
Если сервис должен запуститься — проверяем запуск. Если файл должен появиться — проверяем файл. Если версия должна исправлять конкретный сценарий — воспроизводим именно этот сценарий. И фиксируем результат.
ㅤ ㅤ

И вот здесь произошёл самый важный сдвиг. Раньше большая часть истории проекта существовала внутри чатов.
Почему приняли определённое решение?
Почему этот участок нельзя менять?
Что уже проверяли?
Почему предыдущий подход отвергли?
Если контекст терялся, модель начинала достраивать историю самостоятельно. Мы же пошли от обратного. Если информация важна для проекта — она не должна жить только в голове человека или внутри чата. Так постепенно появился наш подход. Состояние проекта выносится наружу. Решения фиксируются.
ㅤ ㅤ
● У задачи есть конкретные границы.
● Есть текущее состояние репозитория.
● Есть критерии приёмки.
● Есть PASS или FAIL.
● Есть доказательства того, что реально произошло.
● А уже после этого ИИ получает следующую задачу.
ㅤ ㅤ
Упрощённо схема выглядит так:
текущее состояние → конкретная задача → ограничения → реализация → проверка → PASS/FAIL → фиксация результата → следующая задача
Никакой магии. Просто ИИ больше не приходится угадывать, что происходило десять чатов назад.
ㅤ ㅤ

Раньше всё выглядело примерно так:
работаем → чат растёт → решений становится слишком много → модель начинает путаться → появляются странные исправления
Теперь новый агент или новый чат получает не историю разговоров на сотни тысяч символов, а состояние проекта:
● Вот что уже сделано.
● Вот принятые решения.
● Вот что менять нельзя.
● Вот текущая задача.
● Вот критерий завершения.
Качество работы оказалось намного стабильнее.
Поэтому со временем мы начали оформлять этот подход уже не как набор личных привычек, а как отдельную систему работы с ИИ-разработкой.
ㅤ ㅤ

Если вы только хотите попробовать вайбкодинг — не надо сначала неделю изучать архитектурные контракты и CI.
Просто начните делать…
Соберите маленькую программу. Пусть большую часть кода пишет ИИ. А дальше реальные проблемы сами покажут, чему нужно научиться.
ㅤ ㅤ
Сломали рабочую версию
— поймёте, зачем Git. ИИ забыл решение
— поймёте, зачем его фиксировать. Одно изменение сломало другое
— поймёте ценность тестов. Несколько агентов начали тянуть проект в разные стороны
— станет понятно, зачем нужны границы и контракты.
ㅤ ㅤ
Теперь инженерным практикам можно учиться не абстрактно.
Вы сначала сталкиваетесь с проблемой, а потом понимаете, зачем существует инструмент для её решения.
ㅤ ㅤ

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

Я продолжаю использовать эту систему в собственных проектах и постепенно оформляю её в более понятный метод работы:
- как вести длинную разработку с ИИ;
- как фиксировать состояние;
- как разделять реализацию и проверку;
- как не терять проект между чатами и агентами.
ㅤ ㅤ
Без идеи: «Вот секретный промт, который всё решит».
Наоборот. Цель — сделать так, чтобы результат как можно меньше зависел от памяти конкретного чата и от того, насколько уверенно сегодня отвечает модель. Я периодически выкладываю реальные эксперименты, ошибки, схемы работы и то, как развивается этот подход, в группе:[ ссылка на группу ]
ㅤ ㅤ
Если вы только начинаете вайбкодить — возможно, половина этих вещей вам пока вообще не понадобится.
Но если маленький проект внезапно начнёт расти, довольно быстро станет понятно, зачем всё это существует. Вайбкодинг действительно позволяет начать разработку почти с нуля.
И это огромная перемена.