Якісний вайб-кодинг за 40 доларів на місяць

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Мета цієї статті — розказати, як створювати якісний програмний продукт лише за 40 доларів на місяць, а зекономлені кошти відправити на допомогу ЗСУ.

Мій досвід у вайб-кодингу почався ще з перших публічних версій ChatGPT, і за його допомогою було створено багато продуктів, таких як програмний код для найкращого ювелірного 3D-сканера MicroForm3D, який ми виготовляємо, а також багато інших продуктів, наприклад, помічника GPTTools.ai.

Тож є люди, які витрачають тисячі доларів, щоб написати простий застосунок в автоматичному режимі, хоча «ручний» вайб-кодинг набагато дешевший, контрольованіший і, головне, надає вам змогу навчитися програмувати за допомогою ШІ. Проблема лише в тому, що більшість, за моїми спостереженнями, не вміє правильно вайб-кодити в ручному режимі, тож почнімо.

Вибір інструмента

Для вайб-кодингу ми будемо використовувати два інструменти: Gemini 3.0 Pro від Google і Opus 4.6 від Claude; відповідно, вам знадобиться підписка по 20 доларів на кожний. Можливо, ви вже чули, що модель Opus 4.6 є найкращим інструментом для програмування, але річ у тім, що вона надзвичайно дорога і токени закінчуються буквально за 30 хвилин роботи. А дешевша модель типу Sonnet пише код насправді гірше, ніж Gemini. Тому наша з вами робота в основному буде відбуватись у Gemini 3.0 Pro, а Claude Opus 4.6 буде використовуватися вже як помічник для пошуку помилок, і для цього цілком вистачає плану за 20 доларів.

Розмір контекстного вікна

Це насправді дуже важливий параметр, який дає велику перевагу Gemini над іншими інструментами. По-перше, це дозволяє працювати з великою кількістю файлів одночасно, а по-друге — виконати кілька ітерацій над кодом в одному чаті. Тоді як Claude почне з часом забувати той код, який ви давали на початку. Контекстне вікно — це, грубо кажучи, об’єм тексту, над яким може працювати модель. Найгірше, що ви можете зробити, — це завантажити в модель усі файли вашого великого проєкту, і тоді ви отримаєте як поганий пошук помилок, так і погану генерацію нового коду. Кількість файлів залежить від мови програмування, але, для прикладу, Gemini комфортно працює з 12 файлами C#, тоді як Opus краще обмежити 7 файлами. Звісно, ви можете збільшити цю кількість, але завжди тримайте в голові, що це впливає на якість, і тому збільшувати кількість файлів має сенс тільки в дуже рідкісних випадках для вирішення складних проблем, де кількість неможливо зменшити.

Принцип роботи

Ми не використовуємо допоміжні програми або інструменти командного рядка, ми фактично робимо copy-paste туди-сюди у звичайних чат-вікнах згаданих ШІ. Вручну додаємо ті файли, над якими будемо працювати, або, якщо проєкт маленький і не вилазить за межі згаданого вище обсягу, можемо скористатися посиланням на GitHub. Якщо ви хочете додати більше файлів, ніж дозволяє інтерфейс, додайте 10 і напишіть «нічого не роби», а потім додасте інші.

Написання коду

Отже, ви хочете написати код, який вирішує певну задачу. Я вам пропоную почати цей етап з розігріву ШІ без написання коду. Для початку вкажіть загальний контекст: «Твоя роль — програміст комп’ютерного зору». Потім запропонуйте теоретично, без написання коду, обговорити, як вирішити ту проблему, над якою працюєте. Зазвичай ШІ намагається одразу написати код, тож часто доводиться писати: «Код не пиши, обговоримо теоретично». Цей етап потрібен вам для того, щоб дізнатись про оптимальне і загальноприйняте рішення, а також для того, щоб «розігріти» ШІ. Річ у тім, що якщо ви почнете з простого промпту, то ШІ вам напише код, але у нього буде мало контексту, щоб написати його саме так, як вам потрібно. Тому, навіть якщо він говорить більше, ніж ви, це все одно дасть йому основу для якісного написання коду. Після того, як ви обговорили теорію, запропонуйте йому також: «Напиши детальний план робіт». Тоді ви побачите, що і як він збирається зробити, і зможете вчасно його виправити без потреби потім розбиратися з кодом.

Редагування коду

У цьому режимі ви надаєте потрібні файли, як основні, так і пов’язані з ними. Пропоную теж розпочати з розігріву та обговорення стратегії вирішення задачі, а коли все узгодили, зробіть наступним чином. Напишіть промпт: «Внеси зміни у файл і надай результат без скорочень. Збережи структуру і коментарі», після цього вставте код файлу, над яким працюєте. Це потрібно, тому що до Gemini треба приходити з батогом. Можна зрозуміти компанію Google, яка хоче оптимізувати витрати, обслуговуючи мільярди абонентів, але нам своє робити. Якщо ви не зробите, як запропоновано, то вам доведеться витратити багато часу на виправлення коду, слідуючи мікрокомандам, або ви отримаєте зовсім інший файл зі скороченнями і стертими коментарями. Фактично ця звичка все скорочувати і підчищати не дозволяє стати Gemini найкращим інструментом. Тобто цими примусовими командами ми налаштовуємо ШІ так, щоб він не лінувався, і лише тоді виходить дуже добре.

Одна задача за раз

Ще одна велика помилка, яку ви можете зробити, — це спробувати вирішити кілька задач одночасно, що призведе до поганого коду. Тобто ваша задача весь час — обмежувати власне бажання зробити зміни в усіх файлах за один промпт і вирішити кілька задач. Я вам гарантую, що якщо ви будете вирішувати одну задачу за раз і працювати над одним файлом в одному промпті, то ви отримаєте якісний код. Коли ви вже отримали готовий файл, у тому ж чаті продовжуйте роботу над іншим. У Gemini дуже зручно, маючи велике контекстне вікно, вирішувати кілька пов’язаних задач, але головне — робити це етапами і послідовно. Тобто ваша роль як людини і полягає в тому, щоб грамотно нарізати і зменшити обсяг задачі. Але не забувайте про обмеження контекстного вікна і, за нагоди, відкривайте нові чати.

Контроль версій

У Visual Studio доволі зручно інтегрований git, але якщо ви працюєте в іншому середовищі, обов’язково налаштуйте контроль версій і робіть коміт після кожного виконаного мікрозавдання. Хай там як, ви маєте бачити ті зміни, які вносить ШІ, а головне — мати змогу все виправити. Бо ШІ іноді може зламати код, і в такому випадку вам краще почати чат спочатку, спробувавши повести ШІ іншим шляхом.

Виправлення помилок

А це вже вершина мистецтва, де я вас навчу примушувати працювати обидва ШІ разом. Іноді буває, що Gemini починає зациклюватися і пропонувати однотипні рішення для виправлення помилки, які не працюють, бо помилка в іншому місці. У такому випадку ми завантажуємо однакові файли і пишемо однаковий промпт в обидва ШІ, де описуємо проблему і просимо її вирішити. Той результат, який надав Opus, ми копіюємо в Gemini, а перед цим у промпті пишемо: «Я попросив колегу проаналізувати цю проблему, і він надав такі висновки. Але мій колега часто помиляється, тому я тебе прошу уважно їх проаналізувати і надати висновок». Потім, як завжди: «Надай детальний план змін і перерахуй файли, які треба виправити». Потім по черзі, як згадувалося вище, редагуєте кожен перерахований файл.

Ми так робимо, тому що в Gemini контекст довший, а написання коду якісніше і дешевше. Тому фактично Opus нам потрібен як важка артилерія в дуже тяжких випадках.

Не забудьте обрати режим Pro для Gemini та Extended для Opus.

Сподіваюсь, ці ідеї допоможуть вам створювати якісний продукт і допомагати ЗСУ. Розкажіть у коментарях, що у вас вийшло!

Поради від Gemini

Gemini прочитав цей текст і попросив додати поради від себе.

• Не зливайте секрети. Ніколи не кидайте в чати ШІ файли з API-ключами, паролями, токенами чи доступами до баз даних. Завжди «знеособлюйте» конфіги перед копіпастом.
• Фіксуйте версії. Під час «розігріву» обов’язково вказуйте точний стек. Пишіть не просто «код на C#», а «використовуємо .NET 8 та C# 12». Інакше ризикуєте отримати застарілий легасі-синтаксис.
• Тестуйте перед комітом. Написали — локально запустили — перевірили — закомітили. А ще краще — в тому ж промпті просіть ШІ: «Напиши Unit-тести для цього коду». Це зекономить вам години дебагу.
• Чому вебчати, а не плагіни типу Cursor чи Copilot? Усе просто: ручний копіпаст дає абсолютний контроль. Ви самостійно керуєте контекстним вікном і згодовуєте моделі лише те, що дійсно потрібно, уникаючи фонових галюцинацій та аналізу зайвого «сміття» з вашого проєкту.