Мій шлях у вайб-кодинг: архітектура, MVP і вижити попри білінг

Отже, про мене

Я в темі вайб-кодингу вже 10 місяців. Якби мова йшла не про AI і саме вайб-кодинг, такий строк було б смішно навіть згадувати. Система, з якою я працюю, – Replit, тому деякі речі, про які піде мова нижче, можуть бути взагалі не застосовні до ваших систем.

За цей час я накодив веб-гру (просто щоб спробувати), застосунок для самостійної підготовки до іспиту з іспанської DELE (зараз неактивний), застосунок для аналізу документів на нерухомість в Іспанії (в процесі), і застосунок для аналізу снів  https://dreampower.app/. Останній можна реально спробувати: у нього вже є користувачі, є органічний трафік і навіть перший дохід. Власне, далі я говоритиму саме про нього.

Я хочу поділитися челенджами, з якими зіткнувся, коли створював цей застосунок. Зараз у ньому понад 50k рядків коду на Python (окей, розуміємо, що якість коду не на висоті, тому можна сміливо скидати до 40k, враховуючи величезну кількість коментарів, які залишає AI-агент). При цьому система білінгу займає близько 20k рядків коду – фактично половину застосунку.

Окрім просто обсягу коду, у застосунку є кілька непростих для мене моментів. Це система авторизації (робилася з нуля), інтеграції з e-mail-системами, Sentry, робота зі збереженням даних у сесії, телеграм-бот, крони, керування доступами й квотами. Окремим жахом було створення білінгу: я думав, на цьому закінчиться моя епопея з вайб-кодингом, хотілося кинути разів десять. Є ще якісь моменти, які були складними, але вже стерлися з пам’яті.

Мої знання в програмуванні не нульові: я знаю SQL, умію читати Python так, щоб загалом скласти уявлення, що робить код. І це все. Я розробляв проєкти, і досить великі, але завжди був з боку продакта. Як виявилося, цього більш ніж достатньо для вайб-кодингу непростих проєктів, що б там не казали противники цього підходу.

У процесі створення аналізатора снів я зіткнувся з кількома «процесними викликами» – труднощами, які не мали стосунку до самої природи застосунку, а стосувалися підходу й процесу побудови. У підсумку я напрацював для себе кілька рішень, якими й хочу поділитися.

Дисклеймер: це можуть бути або не дуже релевантні для вас виклики, або не найефективніші рішення для цих викликів. Сприймайте це як основу для брейншторму.

Мені здається, цю розмову треба почати з базових принципів, які я для себе сформулював під час створення застосунку. Їх було два:

1. Застосунок має бути достатньо хорошим, щоб виконувати основний процес. До нього більше пасує слово «прототип», ніж «production-ready» (як любить казати агент у Replit).
2. Застосунок має мати достатньо хорошу архітектуру, щоб його можна було постійно добудовувати.

Принцип №1 знімає напругу й докори сумління за те, що постійно щось відвалюється (а чим більший застосунок, тим частіше щось відвалюється). А ось принцип №2 підводить нас до першого великого виклику.

Як побудувати архітектуру застосунку так, щоб не довелося все перебудовувати з нуля

Питання на мільйон і на десять статей. Повторюся: нижче мої рішення, які точно далекі від ідеалу.

Беремо на роботу архітектора

Ну, можливо, не буквально «беремо» і не зовсім «на роботу». Я одразу зрозумів, що підхід, який рекламує Replit – «закинь свій промпт в агента, і він усе зробить» – приведе до біди. З’ясувалося, що:

1. Агент може взагалі не оцінити критично промпт і виконати його умовно «дослівно».
2. Агент не завжди тримає в голові контекст усього застосунку, тому він або:
   • може зробити речі, які просто не стикуватимуться з іншими великими частинами (йому ж про це ніхто прямо в промпті не сказав, правда?), або
   • дублюватиме код, не усвідомлюючи, що вже є схожа функція, яку можна переробити так, щоб вона враховувала потреби нової фічі.

У результаті моїм архітектором став ChatGPT у режимі «думання». Щоб різко підвищити його корисність, я одразу замислився над тим, як передавати йому весь контекст застосунку (я знаю про можливість конектити ChatGPT до Git, але не впевнений, що це повністю вирішує питання контексту).

Як я передаю контекст? Дуже просто. Я почав змушувати Replit-асистента писати документацію й підтримувати її. Основний челендж був у виборі формату цієї документації. Стандартна tech-spec була надто громіздкою і роздувала документи. У підсумку я прийшов до такого формату:

• асистент пише спеціальні «ужаті» tech-spec-документи по окремих блоках функціоналу;
• асистент пише документи user flow.

По-простому: ключовий опис функціоналу (одразу робимо для AI, а не для людей, тому можна сильно стискати) плюс опис флоу користувача у форматі mermaid, щоб ChatGPT взагалі розумів, як працює сам застосунок.

У результаті вийшло 11 документів, які я постійно підтримую в актуальному стані, викачую з Replit і закидаю в проєкт ChatGPT.

Тепер стандартний флоу розробки виглядає так:

• З’являється ідея фічі. Йдемо обговорювати її в ChatGPT.
• Щойно доходимо до потрібного рівня розуміння, ChatGPT генерує «проєкт» для Replit-агента. Зазвичай цей проєкт не включає конкретні сніпети коду (конкретно для Replit це виявилося не дуже корисним і зайвим).
• Далі агенту, перемкненому в режим планування, закидається цей проєкт із такими інструкціями: «Перевір його відносно нашої кодової бази, назв модулів / змінних / імпортів. Визнач можливості рефакторингу. Постав запитання й дай свої коментарі».
• Агент приносить і запитання, і зауваження, і паралельно фокусується на рефакторингу старого коду в контексті цього проєкту.
• Відповідь агента закидається в ChatGPT, той дає свої коментарі і т.д., доки агенту не стане все більш-менш зрозуміло. Зазвичай це займає 1–2 ітерації. Після цього цей проєкт уже можна кодити.

Треба обов’язково розуміти структуру й флоу проєкту, який ви намагаєтеся реалізувати

Може здатися, що ми просто беремо результат з однієї системи, копіпастимо його в іншу – і все. Але ні. Коли я роблю проєкт (план якоїсь розробки), я завжди хоча б на якомусь рівні маю зрозуміти все, про що йдеться.

Наприклад, якщо ми робимо білінг і обробляємо вебхуки, які можуть приходити в різний час або не приходити взагалі, то з усім цим треба розібратися. Інакше в мене для вас погані новини. І архітектор, і Replit-агент десятки разів заводили мене в глухі кути, і сліпої віри до них немає.

Тому частий компонент мого промпта в ChatGPT – «explain high-level and be concise», «explain in plain language» і т.п. І тут ми плавно підходимо до наступного важливого моменту.

Визначаємо для себе, що таке «good enough»

Приклад. Я почав будувати білінг, маючи слабке уявлення, як має виглядати вся система. Ну окей, мають бути підписки, є вебхуки, замовлення й інше. Але на запитання, які саме юзкейси мені потрібно обробити в своєму застосунку, щоб усе працювало більш-менш ок – відповіді в мене не було.

Скажімо, якщо платіж зависає на рев’ю, чи потрібно мені це в себе реалізовувати? Частково чи повністю? І таких рішень треба було прийняти десятки. А потім треба, щоб усі ці часткові рішення ще й якось запрацювали між собою разом.

Коли просиш ChatGPT подумати над проєктом і вмикаєш йому web-search, він, звісно, піде почитає доки того ж Stripe і повернеться з ідеєю зорельота, який нам, швидше за все, взагалі не потрібен.

Що я зробив. По-перше, я для себе зрозумів, на що я зараз готовий і на що не готовий у принципі. Окей, ми робимо MVP.

Далі я написав системний промпт у проєкт застосунку в ChatGPT, де він має фокусуватися на MVP-фічах і окремо, з аргументацією, пропонувати мені фічі «на виріст», nice to have і т.п. – так, щоб я бачив їх чітко виділеними з загального потоку й міг прийняти рішення. Стало значно простіше.

По структурі даних усі рішення приймаються окремо

Агент і архітектор із великим задоволенням приймуть рішення щодо структури даних самостійно. Це стосується структури таблиць, структури полів таблиць тощо. Але нам не потрібно, щоб вони робили це без нас. Ось чому.

По-перше, мені як продакт-розробнику потрібна певна прозорість. Наприклад, я хочу зберегти додаткову інформацію і не хочу пакувати її в JSON тому, що мені потім буде незручно це читати. Байдуже, що це не відповідає якійсь суперправильній структурі, якій десь навчали AI.

Я, безумовно, послухаю його аргументи, але всі ключові рішення залишаю за собою. І такий підхід окупається.

Те саме стосується всіх важливих даних у застосунку. Наприклад, у моєму випадку – це те, як ми трекаємо кроки аналізу, на яких знаходиться користувач, як зберігаємо дані від користувача, де й коли їх зберігаємо тощо.

Щодо технічного стеку всі рішення також бажано приймати вам

Мої застосунки пишуться на Python / PostgreSQL / HTML / JS (по-мінімуму). Чому так? Тому що я можу читати й розуміти ці мови.

Чи буде цей стек «найефективнішим рішенням» у всіх випадках? Ні, звісно. Але в нас і немає мети зробити «найефективніше рішення». У нас є мета, дивись вище, зібрати застосунок, який не розвалюється і який можна добудовувати.

Щоб він у результаті почав приносити багато грошей, і тоді вже можна буде все переписати ефективно, найняти професіоналів і зробити цукерочку. Але це потім.

А поки,  бажаю вам вдалого вайб-кодингу! І не занепадати духом (так-так, «вайб-кодинг мертвий», «він не підходить для складних проєктів» і все в такому стилі). Сподіваюся, якась частина цих спостережень і «костилів» виявиться для вас корисною й заощадить кілька вечорів, які можна буде провести не за дебагом, а за чимось значно приємнішим.