Дневник космонавта-вайб-кодера

Как всё началось: последняя неделя в режиме "после ОБЫЧНОЙ работы → НОРМАЛЬНЫЙ вайб-кодинг"

Каждый вечер выглядел одинаково:

«О, чуть свободного времени → ну надо повайб-кодить».

Фокус миссии был четкий: собрать внутренний фин-инструмент под компанию, который умеет:

показывать запросы клиентов (читать сервер лицензии) и как они превращаются в деньги (нетривиальные формулы в договоре)
аккуратно раскладывать расходы по категориям
крутить зарплаты и премии по месяцам
сводить сервисы из разных валют в одну
дружить с банковскими выписками (загрузил → разложилось по категориям)
жрать клиентские договоры, вытаскивать оттуда условия и складывать всё в базу
google auth для доступа с корп почты.

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

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

Дрейф: как цель растворилась в процессе

Каждая итерация превращалась в:

«А давай ещё вот это…» → «о, а сюда бы ещё слой логики…» → «блять, а вот тут красиво ща сделаю…»

Последние пару дней я кодил ради самого факта процесса. Цель где-то там, далеко, как звезда в тумане.

И это подводит к главному парадоксу моей недели...

Парадокс: анти-vibe в мире vibe coding

В параллельной вселенной живет термин vibe coding:

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

Парадокс: всё что я делал эту неделю — это максимально анти-vibe coding.

А как это выглядело на самом деле?

Хроники «вайб-запоя»: 7 открытий

1. Девайсы офф после 23:00 — единственное спасение от бесконечного дрейфа

У нас с женой есть семейный протокол: после 23:00 — девайсы офф.

Внутри этот протокол превратился в мини-войну:

22:40 — я в Supabase ковыряю схему
22:55 — в голове всплывает ещё идея, стараюсь запустить пару агентов делать её пока сплю, чтобы утром встать и посмотреть результат
23:00 — девайсы должны быть выключены

Маркер того, что тебя реально унесло: когда семейные протоколы становятся техническим ограничением проекта.

2. Битва моделей в космосе: Gemini 3 vs Opus 4.5

Параллельно выкатились новые модели, и я решил протестировать их в боевых условиях.

Gemini 3 гонял на всём:

старте задач
фиксе багов
доках
фронте
внутренних тулах

Ощущение было, что модель либо очень херово встроена в Cursor, либо очень плохо заточена под кодинг.

Opus 4.5 на этом фоне выстрелил прямо сильно лучше:

сложный контекст ✓
фин-логика ✓
странные внутренние тулзы и схемы БД ✓

Перешел на него в 80% случаев (20% — на GPT 5.1).

3. Анти-вайб реальность: я оказался инженером, а не вайб-кодером

Мой реальный флоу вообще не похож на классику вайб-кодинга:

пишу доку вместе с GPT 5 Pro
загружаю форматы данных, примеры выписок, договоры
выжимаю оттуда нормальное словесное описание системы в md
руками упрощаю до адекватной схемы БД
только после этого подпускаю ИИ к разработке и миграциям
придумываю каждую итерацию и как буду её тестировать

4. Схема базы — это не то, что можно отдать на откуп моделям

Иначе получишь:

кучу таблиц
полустранные связи
nullable-поля, о назначении которых не знает никто

Правило: если ты сам не можешь нарисовать (или хотя бы перерисовать со слов GPT и понять) схему БД — скорее всего, она слишком сложная для твоей реальной жизни и ты не сможешь ее поддерживать.

5. Supabase как идеальный спутник в космическом дрейфе

На фоне всех экспериментов Supabase оказался прям удачный выбор:

легко обновлять схемы через MCP
миграции не ощущаются пыткой
удобно смотреть данные и запросы
легко делаются авторизации/оплаты (добавил Google авторизацию для внутреннего домена за 10 минут)
можно перейти с облака на селф хостет

6. Закон пяти сущностей и неизбежность хаоса

Обнаружился жёсткий закон:

Как только в системе больше 5 элементов — фикся пятый, отвалится первый

(Кстати, без тестирования закон справедлив и для обычных продуктов)

Мой план выживания:

заранее режу проект на маленькие итерации
каждый шаг тестирую руками
как только что-то стабильно — прошу модель дописать автотесты и обложить критичные куски проверками

7. Система как расширение памяти: рулы в Cursor + дока и лог багов

Что реально важно в правилах из работы с доков:

общая дока, которую модель обязана обновлять (если нет правила - будет забывать 100%).
файл с багами, где фиксируем:

1) как проявилось

2) из-за чего

3) как починили

Когда вылезает новый баг, я не говорю «Почини».

Я говорю:

«Сначала посмотри файл с багами, может, мы это уже ловили»

Эпилог: как научить этому других?

Пока всё это происходит со мной, я думаю — как можно этому научить?

В этом 100% есть просто тонна потенциала, но ощущается, что это превратится в полугодовой курс по основам разработки, а не вайб лернингу.

Корабль продолжает дрейф. Туманность Supabase медленно меняет цвета. Модели по-прежнему пытаются наебать, но теперь это часть игры.