AI та вайбкодинг для AI. Як завайбкодити продукт до релізу в магазин так, щоб не було соромно і боляче
Вітаю, я Дмитро Шерстобітов, зараз я працюю в компанії RigER як Software Developer. І сьогодні я хотів би підняти дві теми:
- Як це, вайбкодити?
- І про переклад відео на інші мови.
Зараз це, здається, не зовсім схожі теми, але далі я поясню. Тому якщо у вас є багато контенту однією мовою, а вам потрібно перекласти на іншу та зробити це не за всі гроші світу, і вам цікаво, при чому тут вайбкодинг — то велкам.
Почну трохи здалеку (ні, не про пєчєнєгів), але так буде більше контексту. Я дуже довго працював розробником на платформі 1С, понад 15 років, але постійно було якесь відчуття, що щось не те, бракує того самого «справжнього програмування». Я намагався перестрибнути на якусь іншу мову декілька разів, але коли ти заробляєш як середній сініор на будь-якій мові, то складно стрибнути на джуна.
І нещодавно я потрапив у компанію, де планувалась мобільна розробка. Там дуже багато сперечалися про те, що обрати. Пошук і діп сьорч поставили крапку для мене, але не для компанії. Я топив за Flutter. Але я не міг просто підійти та сказати це, адже я нічого про нього не знав. І тоді ще не було Cursor, а був лише ChatGPT 3.5 і тільки но вийшов 4.
І ось я почав курити його за допомогою OpenAI API, і зробив за 2 дні аплікейшн на мові, про яку я взагалі тільки почув. І це було неймовірно круто. Я це презентував і компанія обрала Flutter. Це була перша перемога AI над моїми потугами кудись відійти від свого колишнього середовища.
Все йшло як треба, але я так і не зміг попрацювати з Flutter. Тому що найняли людину, яка взяла на себе розробку на Flutter, а я працював з API для цього застосунку, тобто з серверною частиною.
Через деякий час я вже дізнався про Cursor і ми перейшли на нього. Це було найкрутіше, що ми бачили, тому що за його допомогою ми оновлювали нові метадані, створювали класи, валідації, і цим вже почав потрохи займатися і я.
Це дало дуже великий буст, тому що коли це робив розробник Flutter — він не до кінця розумів, що там за атрибути або які типи даних. При тому, що я навіть давав йому XSD-схему, де то все є.
За нашими розрахункам , коли я почав цим займатись, я робив це в
Своєю чергою, коли ми підключили Cursor до MCP Figma, то це прискорило і створення форм у кілька разів, і не так виснажувало. Тобто я почав приходити з роботи не на стільки виснажений, як раніше.
Це все мені дуже подобалось, але я все ще був на API більшу частину часу, і не розумів — як то може бути, якщо створити все з нуля.
І зараз ми плавно переходимо до локалізаціі відео. Десь пів року тому я з колегою почав холівар на тему мови, а саме — чому багато де російська мова залишається, і чому позбавитись її не так легко, як комусь здається. Одним з аргументів був легасі контент, а саме — навчальні відео, створені російською мовою, корпоративні відео, багато відео в універах, у шкіл, та й просто — у бізнесу.
І ніхто не буде їх переписувати, це нереально. Тоді ми зайшли в інет і пошукали — чим може допомогти AI з цим питанням. І знайшли багато ресурсів, такі як 11Lab, де відео можна конвертувати, робити генерацію звуку і все виглядало гарно. Тоді ми дійшли висновку, що якщо у компанії є російськомовні відео, і вона їх ще не переклала, то це суто їх вибір, тому що рішення вже є. Виглядає гарно, коштує небагато — все тіп-топ.
Але це все зовсім не так, як здавалось.
Потім до мене прийшов знайомий з питанням — як перекласти відео? Він звернувся до мене, тому що знав, що я вже вирішував питання з перекладом софта, і хотів проконсультуватися.
Я відправив його в інет і сказав, що вже все існує — тому йди туди й користуйся. І він пішов, а потім прийшов знову, і сказав, що все це для тих, у кого відео на 5 хвилин, хто перекладає більше для хайпу, і в кого бюджет бездонний, а ще для тих, в кого не має сек’юріті. Тому що вони не пропускали жодне відео на інші платформи.
В них все виглядало так — знімають аудіо, відправляють, потім намагаються натягнути його на відео, але звісно, нічого не виходить, бо таймінги різні. І так далі.
Тоді я зрозумів, що якщо навіть вони не змогли і їм не вистачило коштів, то з цим щось треба робити.
Тоді я вирішив зробити продукт на Flutter — на чистому вайбкодингу, з нуля. Він мав працювати через API, зберігати відео на комп’ютері користувача та дозволяти змішувати різних провайдерів голосів. В ідеалі я хотів би реалізувати все повністю офлайн (поки що цього не зробив). А найголовніше — завдяки API одна хвилина перекладу обходиться всього у кілька центів.
Забігаючи наперед — в мене вийшло. Я завайбкодив продукт на 100 000 рядків коду, де розв’язував такі питання:
- як на Flutter зробити роботу з підписками у Microsoft Store;
- як розробити візуал;
- як робити компоненти на C++, якого я боюсь, як полум’я;
- і як довести це все до релізу.
Тому я розповім, як це — вайбкодити. І не з позиції тих, хто розробив якусь фігню на тисячу рядків за п’ять хвилин і розказує, як все круто. А з позиції людини, яка пройшла всі кола пекла і таки вийшла звідти. І я ще раз кажу, що в мене немає досвіду роботи з цією мовою на такому рівні, щоб я навіть створив простий застосунок на тисячу рядків самостійно.
Моя подорож з AI
По-перше, треба зробити короткий опис того, що вам потрібно. Для цього ми пишемо чату — я хочу створити застосунок, який буде вміти те, те і те. Перераховуєте все, що потрібно від застосунку, і йдете вайбкодити...
Жартую, все виглядає зовсім не так.
Формуємо ТЗ для AI та для нас
- Відкриваємо Google Doc і починаємо переносити інфу про те, що це за застосунок, кому він потрібен, які питання він вирішує, які фічі потрібні й таке інше. Залишаємо документ на день-два, потім перечитуємо, правимо.
- Йдемо в інет (не ChatGPT, а саме в інет) і шукаємо щось подібне. Оновлюємо документ. Чому важливо не йти в AI — тому що це може звузити ваші ідеї, як би це не було сумно.
- Потім відкриваємо ChatGPT (саме його, інші щось не дуже), вставляємо все, що зробили, та структуруємо за його допомогою. Тут найважливіше — декілька раз звіритись. Тому що чат може просто відкинути якісь дуже цікаві ідеї. Або так їх перекрутити, що ви потім не згадаєте — що то було.
- Коли все це зроблено — переносимо в документ та залишаємо там. Воно вам знадобиться ще дуже і дуже багато разів. Тому тримайте поблизу.
- Далі створюємо проєкт в ChatGPT. Це важливо, щоб потім не шукати все. І робимо глибокий рісьорч за такими критеріями:
a. Перевір сумісність того, що я зробив. Пошукай, які є аналоги функціоналу. Дай мені 10 топ-доповнень до функціоналу.
b. Якщо є вже якісь аналоги, знайди коментарі про них.Пошукай, чого користувачам не вистачає, що їх бісить і так далі.
c. Дай повну і нищівну критику мого проєкту. Ти повинен довести мені, що те, що я планую робити, не буде працювати. Що ним ніхто не зможе користуватися. Зроби це за кожним пунктом окремо.
d. Зроби маркетинговий матеріал на цей продукт. Опиши всі його фічі для моїх інвесторів: чому вони мають обрати саме мене, чому мій продукт. Чим він здатен допомогти і так далі.
e. Які технічні труднощі будуть, якщо я це буду робити для ..., на ..., за допомогою стеку ... - Потім в ідеалі проганяємо це все в Claude Opus, теж на deep research, і можна ще один-два обрати.
Ви спитаєте — а де ТЗ? А його ще немає. Ми ще до нього не дійшли. Всі ці кроки потрібні, щоб насамперед ВИ зрозуміли — що саме ви плануєте робити.
Я дуже не полюбляю, коли пишуть такими аморфними тезами, тому спробую навести приклад.
ПЕРШЕ
Я хочу розробити онлайн-скрам-майстра, якого можна підключити до мітингу. Він стежитиме за тим, що говорить кожна людина, чи не відходить від теми. А якщо відходить, він буде голосом казати: «Колего... стуліть вже пельку!»
Ну що, перший кейс пройдено. Це і є те саме перше, що ми з вами зробили у пункті 1. Але якщо ви трохи подумаєте, то зрозумієте, що це нелегко. Тому що потрібно онлайн слухати, хто і що каже, якось відправляти час. Але з іншого боку, якщо ми вже слухаємо, то чому би не відкрити дошку, і не писати на ній тези за допомогою AI? Ось це вже схоже на те, що в нас була ідея, і ми її розвинули.
ДРУГЕ
Йдемо в інет, і бачимо, що зараз є дуже багато аналогів. Але все не те. Хтось робить тільки транскрибацію, хтось може писати текст. Тому думаємо — а що нам з цього потрібно? Наприклад — транскрибація, окей. Додали до нашого файлу.
ТРЕТЄ
Вставимо все це в чат, і чат видає таке:
Онлайн-скрам-майстер — це AI-асистент, який підключається до мітингів (Zoom, Google Meet, Teams і т.д.) та допомагає:
- Слідкувати за дисципліною обговорення — визначати, хто говорить, і чи відповідає його промова темі мітингу.
- Автоматично втручатися голосом, якщо людина сильно відходить від теми, використовуючи гумористичну фразу («Колего... стуліть вже пельку!»).
- Фіксувати ключові тези на інтерактивній дошці (Miro, Mural, власна whiteboard).
- Формувати коротке резюме зустрічі одразу після завершення.
І ще багато всього, що можна додати в функціонал. Але це багато тексту, придивімось поки що до нього. Дивіться, чат вже нам додав 4 пункт, де зовсім не те, що я хотів. Я казав про транскрибацію, а він вже каже щось про резюме. Тому важливо перевіряти ретельно — чи не зробив він підміну ідеї.
ЧЕТВЕРТЕ
Тут все просто — правимо все, що нам не подобається, і зберігаємо в окремому документі. Я б одразу це робив в Git в md форматі, щоб потім можна було повернутися до старих ідей та при коміті чітко бачити — що саме він додав, коли я вирішив доповнити все.
П’ЯТЕ
Копіюємо те, що отримали в (4). Ну, deep research я не буду запускати, але, це повинно виглядати так:
a. Додасть вам купу всього і потрібно буде зрозуміти — що там реально релевантне, а що ні. Правимо, і те що вийшло — беремо і йдемо до b.
b. Тут складно вигадати, але напевно скаже, що є окремо дошка, окремо транскрибація, а може вже і є аналоги. Знову опрацьовуємо, беремо те, що вийшло, і йдемо до c.
c. Він тут може розповісти багато чого, але, наприклад він каже — та ніхто не захоче робити міти і відправляти на якісь сервери, тому твій онлайн нікому не потрібен. Опа, і це ще одна ідея, а дійсно — хто таке захоче? Це означає, що потрібен офлайн. Допрацьовуємо і йдемо далі.
d. І тут він вже повинен вас нахвалювати. Це треба читати уважно, тому що він може знову таки вигадати багато чого, і треба аналізувати — чи можливо це трактувати по-різному? Або навпаки — можливо, щось важливе він не примітив.
e. Тут я напишу чату — я планую робити на Flutter, для Windows. Він може почати говорити, що тут ще потрібен буде докер, пітон, і так далі. Це все по суті ваш стек, це потрібно десь зберегти і проаналізувати.
ШОСТЕ
Все прогняємо десь в іншому місці, комбінуємо, виявляємо найкраще, компонуємо і кристалізуємо.
Після цих всіх кроків ми вже будемо чітко розуміти, що в нас є, що ми плануємо робити, як це буде виглядати, що потрібно буде для реалізаціі.
Медитуємо
Я вже відчуваю, як після цього всього ви вже три рази передумаєте це робити. І це ОК. Це дуже важливо, тому що якщо ви не змогли пройти цей бар’єр, то далі й починати не потрібно.
Тут ви починаєте вивчати стек, який вам буде потрібен, наприклад — як працює докер та інше. І може здатись, що ви вже працюєте над проєктом, але це не так. Ви підіймаєте свою кваліфікацію, щоб ви самі відповідали вимогам свого ж проєкту.
І це МЕГА КРУТО! Чому? Все просто, якщо ви просто так вирішили вивчити докер — я думаю, що не вийде. Ви або забудете все, що вивчили, або не будете розумітися, куди податися та що саме треба вивчати.
А тут ви маєте ТЗ для навчання. Тому перший пункт не обманював: ми вже отримали ТЗ, але не для продукту, а для вас, для вашого розвитку. І поки ви вивчаєте те, що потрібно, починає працювати ефект «жовтої машини». Тобто на мітингу ви вже починаєте приділяти увагу тому, як ви опрацюєте такий кейс і так далі.
І знову приходимо додому й починаємо оновлювати наш документ за тими 6 кроками. І так буде
Формуємо ТЗ
Коли ми працюємо з AI, потрібно розуміти, що завдання має бути чітким та маленьким. Тому вже зараз треба чітко розуміти, що у вас не повинно бути ніяких файлів більше ніж на
Тому коли ми будемо формувати документацію, за якою AI буде вести розробку, треба користуватись правилом:
Краще багато невеликих файлів, аніж один великий. Ідеал — файли по
Зараз нам треба декомпозувати все, що ми підготували, за такими принципами:
- Пріоритет фіч. Що саме і коли ми будемо робити. Тобто — яка фіча пріоритет, а яка — може і почекати.
- Що в нас зі складністю, наприклад, чи одразу ми будемо підтримувати офлайн-моделі, чи спочатку все зробимо на онлайні? Це принципово, бо інакше можна робити одну фічу тижнями, а це не дуже. Бо якщо не має ніякого візуала і того, що можна потикати — це може загнати в депресію...
- Які патерни й де ми будемо використовувати? Так, це дуже важливо, інакше — модель буде просто щось робити і все. Воно буде працювати, але чим далі ви будете йти — то складніше все це буде підтримувати. І звісно — перевіряти всі патерни, тому що модель може щось не те сказати. І на цій стадії я вивчив 5 дуже класних патернів :) Це ще важливо, тому що, якщо в нас буде, наприклад, в ТЗ підтримка OpenAI, то чат так і зробить. Але ми розуміємо, що тут потрібен патерн «стратегія», а також патерни щодо обробок помилок, десь щось має бути сінглтоном. І про це знати можете лише ви.
- І потім вже все це закидаємо і формуємо таски, тобто кажемо моделі: а зараз зроби нам таски та врахуй все, що ми тобі дали.
Я зроблю зараз все це з вами, але звісно видалю багато речей, бо інакше це буде багато тексту:
🥇 MVP (мінімально життєздатний продукт)
Основна цінність: AI-асистент слухає мітинг і контролює фокус.
- Аудіо-захоплення
a. Бот підключається до мітингу як учасник.
b. Веде запис або пряме прослуховування аудіо. - Багато іншого, видалив
🥈 Must-have (перші релізи після MVP)
Основна цінність: асистент допомагає ще й фіксувати результат.
- Автоматичні тези
a. Витяг основних пунктів (summary).
b. Короткий список «що вирішено / що робити». - Біла дошка (whiteboard)
a. Проста вебсторінка з автозаписом тез.
b. Можливість експорту у PDF / TXT. - Кастомізація стилю втручання
a. Варіанти: формальний, жартівливий, «жорсткий скрам-майстер».
b. Налаштування голосу (чоловічий/жіночий).
І так далі. Але, як бачите — він знову додав багато речей, хоча я йому сказав обробляти лише те, що я скинув. Але... Ну добре, вичищаємо все це і йдемо далі. Аналіз складності, звісно, залежить від стеку та від вашого досвіду. Там і без прикладів можливо розібратися.
Далі переходимо до патернів — тут ми визначаємо, як має бути структурований наш проєкт і як він працюватиме.
Я в чат відправляю все, що було раніше, і питаю:
Які патерни і де ми будемо використовувати? Які моделі створювати? І все це потрібно розробити за чистою архітектурою. Тому розпиши структуру проєкта, де які моделі, і де які патерни для Flutter.
Орієнтир: feature-first + clean architecture, DI через Riverpod/Provider, моделі через freezed/json_serializable, мережа — dio/retrofit.
lib/ core/ config/ # константи, env, фіче-флаги di/ # реєстрація залежностей (Riverpod providers) errors/ # Failure/Exception, ErrorMapper logger/ # логування, перехоплювачі utils/ # утиліти (Either, Result, throttling, etc.) platform/ # platform channels, permission helpers domain/ entities/ # чисті Entities & Value Objects
Архітектурні
- Clean Architecture — чіткі межі: domain (бізнес), data (I/O), features/*/application (координація), presentation (UI).
- CQRS (мʼяко) — usecases ділимо на Command (зміни) і Query (читання).
- Repository — для збереження/читання (MeetingRepository, TranscriptRepository, BoardRepository, AnalyticsRepository).
- Service (Domain Service) — складна бізнес-логіка не прив’язана до сутності (TopicClassifier, InterventionPlanner).
Інтеграційні
- Adapter — підключення різних провайдерів STT/TTS/діаризації/whiteboard/Jira:
SttService ⇄ WhisperSttAdapter / DeepgramSttAdapter
TtsService ⇄ EdgeTtsAdapter / ElevenLabsTtsAdapter
BoardGateway ⇄ MiroApiAdapter / LocalCanvasAdapter - Facade — MeetingOrchestrator як єдина точка керування потоками (STT→Moderation→TTS→Whiteboard).
- Strategy — змінні політики:
OffTopicDetectionStrategy (by-keyword / by-embedding / hybrid),
InterventionToneStrategy (formal/humorous/strict),
SummarizationStrategy (short/bullets/OKR-style). - Decorator — логування, ретраї, метрики поверх сервісів (напр. MetricsSttService).
- Factory / Abstract Factory — побудова конкретних адаптерів за конфігом (env, settings).
І тут ми маємо уважно все передивитися, тому що інакше потім буде боляче все це виправляти.
Далі ми вже все це разом із пріоритетами, фічами та архітектурою ще раз скидаємо і кажемо — зроби таски. Я роблю такий запит:
Тепер зроби мені повноцінні задачі, нічого не доповнюй.
Задача повинна мати завершений функціонал, який можна протестувати.
Порядок задач усередині пріоритету має бути за зростанням. Якщо задача залежить від іншої задачі — вказати це.
У кожній задачі повинно бути написано:
- назва;
- яку проблему задача вирішує;
- які об’єкти в ній треба створити;
- які патерни застосувати;
- як її протестувати після завершення.
Також повинна бути секція, де ШІ буде відмічати, які кроки цієї задачі були виконані (якщо це доречно).
І отримую від чату:
#1. Підключення бота до мітингу та захоплення аудіо
Проблема: немає каналу аудіо для аналізу в реальному часі.
Залежності: —
Створити:
- core/platform/meeting_audio_channel.dart (інтерфейс AudioInputChannel)
- data/datasources/zoom_audio_channel_adapter.dart (або заглушка FakeAudioChannelAdapter)
- features/meeting/application/meeting_controller.dart (початок/стоп сесії)
Патерни: Adapter (для платформи мітингу), Facade (через MeetingController).
Тестування (Accept): - Юніт: FakeAudioChannelAdapter віддає PCM-буфери з таймстампами.
- Інтеграційний: при start() стрім аудіо з’являється, при stop() — завершується. Прогрес:
- Ініціалізація каналу
- Стрім аудіо старт/стоп
- Обробка помилок (немає прав/пристрою)
Тут важлива опція — прогрес, тому що саме там чат має відмічати, що він робить. А коли ми будемо виконувати цю таску, то ми ще скажемо йому оновлювати прогрес та доповнювати таску, якщо треба.
Зараз ми маємо всі таски, і вже можна уявити, скільки часу нам потрібно на реалізацію. Можна попросити ШІ ще і зробити оцінку часу. І потім звіритись з нею 😊
Якщо ви думаєте, що це все, можна відкривати Cursor і робити, то... ні... Це лише початок.
Формуємо git
Якщо ви досі це робили десь в іншому місці — то прийшов час робити git.
Тут все просто — створюємо структуру доків, куди додаємо все, що маємо. Це важливо, бо коли все поруч — ви можете просити ШІ оновити документацію, якщо в цьому є необхідність. І коли він буде шукати, наприклад, клас, то він зможе потрапити до документаціі й оновити свої знання.
Наприклад — це може бути ось така структура:
project-root/
│
├── docs/ # Уся документація
│ ├── requirements/ # ТЗ, юз-кейси, feature list
│ │ ├── mvp.md
│ │ ├── must_have.md
│ │ └── backlog.md
│ ├── research/ # deep research, аналоги, критика
│ │ ├── competitors.md
│ │ ├── tech_stack.md
│ │ └── risks.md
│ ├── patterns/ # вибрані патерни (стратегія, фасад і т.д.)
│ ├── tasks/ # сформовані задачі для AI
│ │ ├── task_01.md
│ │ ├── task_02.md
│ │ └── progress.md
│ └── architecture.md # загальна схема проєкту
Тобто треба кожну таску створити як окремий файл, тому що одна таска — це одна ітерація.
Вайбкодинг-платформа
І знову, якщо ви вирішили, що вже можна, то ні, зараз треба розібратися з тим, а де ми будемо кодити.
Зараз є дуже багато всього, і клієнти від Claude і Gemini, і Codex від OpenAI, і v0.app, який вам зробить апку, бо він сам все оркеструє. Але ми з вами домовимося, що ми студенти й грошей в нас таких немає. Це по-перше, по-друге — я обираю те, що дає мені змогу контролювати процес і кошти, а також мій час.
Я почав працювати з Cursor, і це було круто. Він дійсно дуже крутий, в нього є моделі з роздумами, і він сам вміє собі ставити таски, і він, мабуть, найкращий, але... Ось вам те, скільки я заплатив, коли вони змінили модель:
Вам може здатися, що 130$ це не дуже багато за вайбкодинг. Але я в той час не робив нічого такого хардкодного, і зверніть увагу — це за 2 дні. Загалом я за тиждень віддав 300$ (але вони потім повернули все), і це я тоді не дуже і працював з нею. Тому так, це дуже крута штука, але таких грошей коштує, що ні, дякую.
Загалом якщо він вам саме допомагає програмувати, то так, це не дуже багато коштує, десь 20-30$ на місяць, але ж ми саме про вайбкодинг 😊
Тому я зупинився на Copilot https://github.com/features/copilot/plans, і тут в мене такі затрати були:
Тобто я за 10 годин нонстоп-розробки (це мій максимум був) заплатив 4$. Ніяких очікувань, таймінгів, просто робите те, що потрібно.
З мінусів — дуже тупий Tab, який частіше заважає. Добре, що його можна вирубити. Та те, що він не має моделей з роздумом. Тільки простий Claude 4, GPT-5 та інші.
Тому краще почати саме з Copilot, бо Cursor у вас закінчиться за день.
Якщо хтось думає, що він купить кредити на https://openrouter.ai, і вкаже його у Cursor, і тоді це буде значно дешевше, то це не так. Наприклад, я потикав модель Qwen3 Coder:
Яка коштує у десятки разів дешевше ніж Claude. Але ось що я отримав:
Увага — це був один єдиний запит щось зробити (на скріні тільки частина запитів), і він коштував мені більше ніж 1$.
Тому або ви працюєте з локальним сервером, і він повинен вміти працювати з вікном контексту — 100 000 токенів, або обираєте Copilot, де оплачуєте реквест фіксовано 0.04$.
У Microsoft є свої сервери, і тому вони можуть це дозволити, на відміну від Cursor.
Або ви обираєте Cursor, і там за 20$ ви будете витрачати 0.1$-2$ за реквест. А якщо помилково оберете модель Opus, то взагалі — 10$-20$ за реквест.
Далі ми будемо розглядати саме Copilot.
Обираємо модель
Тут все дуже складно. Все залежить від стека. Але я помітив наступне:
- Обираємо Claude 4, коли треба зробити щось складне, наприклад, розібратися з якимось багом.
- В інших кейсах дуже добре працює GPT-5. Він має короткі сесії порівняно з Claude, і це з одного боку мінус, бо ви оплачуєте кожен реквест. А з іншого — він не йде кудись в код по своїх справах і не чудить там такого, що потім доводиться довго шукати, де це все і що він накоїв.
- Gemini — коли вам потрібно зробити щось з великим вікном контексту, наприклад — проаналізувати всі класи й створити якусь документацію. По коду — він поганий навіть з Flutter, який Google і створив, що для мене було досить дивно.
- Ще є Grok 4, але не в Copilot, і він неймовірно крутий. Мені здалось, що він краще ніж Claude Sonet 4, але, він є тільки у Cursor, а там ціни...
Тому на старті можна обрати GPT-5, щоб усе було під контролем, а далі вже пробуйте інші моделі та грайтесь.
Налаштування IDE
О Боже, та коли вже буде вайбкодинг? Ось раніше — відкрив IDE і пішов собі код писати, а зараз...
Окей, налаштування це важливо, а саме Instuctions. Ви повинні їх продумати й створити одразу.
Є дуже корисна лінка — https://docs.github.com/en/copilot/how-tos/configure-custom-instructions/add-repository-instructions
Там є все, що потрібно знати, і цим не можна нехтувати.
Ви можете попросити Copilot самостійно згенерувати вам інструкції, а потім відредагувати.
Про що треба писати в інструкціях — про все, що Copilot робить не так (наприклад, використовує функції якісь криві, або постійно глючить на пакетах) і доповнювати це згодом. Але спочатку ми повинні йому дати всю інформацію про наш проєкт: яка має бути архітектура, що він має писати код і коменти англійською, навіть якщо ви питаєте його українською і так далі.
З іншого боку — що він більше, то менше в нього буде контексту для праці, тому не потрібно, щоб він був величезним. Уявіть це собі так, наче ви знайшли ще одну людину, і ви повинні їй розповісти про проєкт рівно стільки, щоб вона взагалі зрозуміла — що у вас там коїться.
Наприклад, немає сенсу писати про всі патерни або розповідати всі фічі. З іншого боку — треба було б сказати йому, де що шукати, де які моделі, які патерни ви взагалі використовуєте, а які — 100% ні.
Приклад:
Зменшити ймовірність відхилення PR через зламані збірки/валідації або некоректну поведінку. — Мінімізувати збої у bash-командах і скоротити час на пошук по коду/скриптах.
Інструкції мають уміщатися в межах двох сторінок.
Інструкції не повинні бути завдання-специфічними.
— Дайте
— Вкажіть тип проєкту, мови/фреймворки/рантайми та приблизний розмір репо.
— Для bootstrap, build, test, run, lint опишіть послідовність кроків і версії інструментів; зазначте передумови та очікувані результати.
— Занотуйте відомі помилки/таймаути та перевірені обхідні шляхи; явно позначайте команди, які «завжди слід запускати».
Стисло опишіть архітектурні блоки і шляхи до ключових файлів (конфіги лінтера/компіляції/тестів, налаштування).
Перелисліть CI/додаткові перевірки та як їх відтворити локально; додайте короткий список вмісту кореня та ключових піддиректорій.
Зробіть інвентаризацію: прочитайте README/CONTRIBUTING, скрипти, пайплайни, конфіги й пошукайте «HACK/TODO/WORKAROUND».
Для кожного релевантного файлу зафіксуйте робочі команди, порядок запуску, типові помилки й обхідні рішення; агент має довіряти цим інструкціям і шукати додатково лише якщо щось відсутнє або некоректне.
І ось як це може виглядати для нашого демо проєкту (це краще робити англійською):
— Always generate code that compiles and runs successfully in Flutter without additional fixes.
— Always ensure that changes respect existing architecture (Clean Architecture layers: domain, data, features, core).
— Always follow Dart/Flutter linting rules and formatting so that `flutter analyze` and `dart format .` pass without errors.
— Always minimize unnecessary searches or exploratory edits; use the instructions in this file as the primary source of truth.
— Do not invent new features or flows that are not already present in the repository structure.
— Do not write code outside the allowed languages/frameworks (Dart/Flutter only).
— Do not create instructions or steps longer than needed; keep responses concise and within 2 pages.
— Do not assume hidden dependencies — rely only on the ones listed in `pubspec.yaml` unless explicitly instructed.
— This repository implements an «AI Scrum Master» Flutter application that connects to online meetings, transcribes speech (STT), detects off-topic discussions, generates voice interventions (TTS), and maintains a live whiteboard with notes and action items.
— The project follows Clean Architecture with `domain`, `data`, and `features` layers. It is built with Dart/Flutter, uses Riverpod for DI, Freezed/JsonSerializable for models, Dio for networking, and can target both desktop and web runtimes.
— Always run `flutter pub get` before building to install dependencies.
— To build: `flutter build windows` or `flutter build web` depending on target.
— To run locally: `flutter run -d windows` (desktop) or `flutter run -d chrome` (web).
— To test: run `flutter test` (unit tests) and `flutter test —coverage` for coverage.
— Linting: run `flutter analyze` and `dart run dart_code_metrics:metrics analyze lib`.
— If build errors occur, clean with `flutter clean` then re-run `flutter pub get`.
— The root contains `pubspec.yaml` (dependencies), `analysis_options.yaml` (lint), and `/lib` with the main code.
— **Architecture**:
— `/lib/core` → config, DI, utils, error handling.
— `/lib/domain` → entities, value objects, repositories, services, usecases, specifications, policies.
— `/lib/data` → DTOs, adapters, repositories implementations, external service integrations (STT/TTS/whiteboard).
— `/lib/features/*` → application (state, controllers) and presentation (UI pages, widgets).
— `app.dart` and `main.dart` configure MaterialApp and navigation.
— CI: GitHub Actions workflows run `flutter analyze`, `flutter test`, and build checks.
— Validation: all PRs must pass analyzer and tests; failures typically come from missing imports, outdated generated code (`flutter pub run build_runner build —delete-conflicting-outputs`), or formatting (`dart format .`).
— Review `README.md` for a high-level overview of the app.
— Inspect `pubspec.yaml` for dependencies and versions, and `analysis_options.yaml` for lint rules.
— Search `lib/domain` for core entities, `lib/data` for adapters, and `lib/features` for application/presentation logic.
— Always run `flutter pub get` before any build or test step.
— Use `flutter clean` if build/test errors persist.
— Trust these instructions first; only search the codebase if information here is incomplete or out of date.
Це те, що я зробив за допомогою чату. І тут дуже добре можна побачити, як саме він би працював без інструкцій. На перший погляд все добре, але Copilot не вміє сам запускати термінал (на відміну від Cursor). Тобто кожен раз, коли він захоче зробити тести або сгенерувати файли, ви побачете таке вікно:
І це круто, бо він питає вас, тому що хоче зробити щось у терміналі, і це контроль. Але коли він буде виправляти тести і стартувати по 100500 разів на хвилину, то ця ейфорія дуже швидко мине... Повірте.
Та й коли він вас задедосить, то ви ж навіть читати не будете, а що він там взагалі робить. Тому це не захист, а знущання. Оскільки якщо він у 66 раз захоче грохнути базу, бо вирішить, що вона йому заважає, а ви на автопілоті натиснете ОК, то все, це вже ваша провина.
Тому нам треба додати у наше середовище Task і Build Task, тому що саме їх він може виконувати без запиту (якщо ви дозолите йому це один раз). І тоді ви лише бачитиме таке повідомлення:
Тобто він сам зможе все, що є в тасках, і без вашої допомоги. Для цього треба зробити отакі файли:
І все, далі все буде чудово.
А щоб він знав про них, то це йому треба в інструкціях і написати.
І останнє, що робимо — якщо ви працюєте у Windows, то треба зайти і змінити термінал за замовчуванням на bash, інакше він буде вам відавати такі обсяги глюків, що повириваєте все волосся на голові.
Вайбкодимо
Нарешті! А зараз нам треба створити сам проєкт, і далі даємо по одному таску. Дивимось, чи оновив він прогрес, і робимо коміт кожен раз, коли у нас щось працює.
Як це виглядає:
- Я пишу йому — роби таску. Надсилаю йому таску, патерни, та все інше, що, я вважаю, йому може знадобитися.
- Дивлюсь, що саме він робить. От зараз я пишу статтю, а він пише тести, і в мене поблизу його чат. Я дивлюсь, що там падає тест моделі проєкту. Падає тому, що модель проєкту за замовчуванням повертає ChatGPT-5, а в тестах ChatGPT-4.1. І що, ви гадаєте, він зробив? Так, пішов у модель, а не в тести, і там зробив за замовчуванням 4.1, а не 5. Тому вайбкодинг — це не просто натиснув і пішов пити кофе :)
- Інколи бісить, що він робить 20 ітерацій, а потім питає — продовжувати чи ні? На щастя, це можна виправити в налаштуваннях Copilot. Я задав йому 100 ітерацій, і для мене це ок.
- Лог. Нам потрібні логи, багато логів. Неймовірно багато логів. Чим більше логів — тим краще!
- Якщо щось йде не за планом — ми логи з терміналу копіюємо в якийсь файл, я його назвав дуже оригінально — log.log. Додаємо його в gitignore, туди копіюємо все, і виділяємо ті рядки, які нас цікавлять. Наприклад:
- Чому це важливо — якщо ви відішлете увесь лог — ви заб’єте контекст, і дуже часто будете бачити, що він робить самарі бесіди, а це не є добре. Але про це згодом.
- Далі чат щось фіксить або додає. Треба подивитися, що там він зробив, а потім вже тестувати.
- Якщо все ок, то йдемо у git клієнта і дивимося, що він там начудив. Якщо все добре, тоді робимо коміт. Коміти треба робити часто. Після кожного кроку, бо інакше — буде дуже боляче, коли він зламає файл і перезатре, а у вас не було коміта.
- Якщо чат зробив не дуже багато кроків й інша таска пов’язана з попередньою — то можна прям у цей чат додавати наступний крок. Але краще створити новий чат і відправляти туди.
І ось тут, якщо файли з описом і тестами перевищують
Чат буде шукати щось, а коли знайде — зупиниться і з великою імовірністю додумає інше.
Тому — ще одне правило:
Весь код повинен бути з коментарями, чим більше — тим краще.
Тому що інакше модель нічого не зрозуміє.
Те саме і про строгу типізацію, наприклад в Python. Якщо ви її не використовуєте, то модель буде витрачати значно більше часу на пошук рішення, і воно може буде не найкращим. Чому? Тому що ніхто з провайдерів не зацікавлений у тому, щоб модель дуже довго думала або шукала.
Коли вже довго працюєш з ними, починаєш розуміти — де модель глючить, а де є системній промпт. І ось я вже неодноразово зустрічав одну таку фразу від чату:
Оскільки в нас немає часу і відповідь мені треба дати якнайшвидше, то зараз...
І потім йде якась дичина. Наприклад:
- ... то зараз я видалю цей код і вставлю TODO, на потім;
- ... закоментим блок, і потім повернемося;
- ... видалю ці тести, бо тут треба дуже багато виправляти;
І в такому ж дусі. Тобто модель, якщо щось не розуміє, не дуже хоче з цим розбиратися.
Логи
О так, як я їх обожнюю. Без них вайбкодинг би не існував, і це не жарт. Бо тільки так модель може «бачити» вашу програму. Тому я пропоную взагалі починати з сервісу логів.
Що нам потрібно в логах? Час, Модуль, Група, безпосередньо лог. У мене логи виглядають так:
Ще я дуже часто прошу чат додати емодзі, вони дуже корисні. Тому що за ними можна фільтрувати й шукати лог, і місце вони не займають.
Тому в першу чергу зробіть сервіс логів, куди ви будете все відправляти, і одразу зробіть на нього тести. Подивіться, як воно виглядає.
Також одразу додайте типи логів, і обов’язково лог з рівнями. Тобто у вас функція повинна виглядати так:
«Модуль», «Метод, або якийсь блок», «Сам лог», 1000)де 1000 — це рівень логу. І на старті я вказую те, якій рівень лога мені потрібно виводити.
Я не рекомендую видаляти логи, краще їх відключати за рівнем або за типом. Бо вони вам будуть потрібні дуже часто, повірте.
Що таке контекст
Я гадаю, ви вже чули про контексти, і ще раз про це розповідати — таке собі. Але я все ж розповім трохи для тих, хто не розуміє до кінця саме прикладну суть контексту.
Отже, контекст — та вся ваша бесіда з чатом. Коли йому відправляється будь-яка інфа — вона цей контекст займає, а коли контексту залишається небагато, то ви побачите таке вікно:
І якщо ви його бачите, то це означає, що чат щось забув.
Уявимо собі це бесідою з чатом, у якого контекст 20 токенів.
Чат: Так, на вулиці дуже гарно! (5 токенів)
Я: А чи є сьогодні дощ?(4 токена)
Тобто зараз весь контекст — 19 токенів.
І тут чат бере і контекст весь стискає у: «Гарна погода, сьогодні, дощить, сяє сонечко» — а тут вже всього 5 токенів.
Я: А чи тепло?
Чат: Так!
І ось тут і є основна проблема. Тому що якщо ми подивимось на перше речення, там я написав, що тепло, і чат мені відповів — так, тепло. Здається, що все добре. Але ні. Він це вигадав, і так само він може вигадати, що не тепло.
Тобто він вже не «у контексті», він вже вигадує, і він це може робити дуже добре, а може і ні. Тому коли ви побачили, що він почав стискати контекст — знайте, ви щось втратили.
Як цьому запобігти? Ніяк, і коли ви бачите контекст у 200 000 токенів, ви повинні розуміти, що контекст має таку структуру:
- Контекст самого Copilot — ви не можете його виправляти, і він легко займає десятки тисяч токенів.
- Ваші інструкції — саме тому вони повинні бути не дуже великими, бо інакше дуже часто чат випадатиме з контексту.
- Те, що ви виділили або прикріпили у чат (не завжди все він тримає, але може сам обирати).
- Ваше повідомлення.
- Те, що він прочитав.
- Те, що він віддав на правки.
Це дуже поверхнево, але дає зрозуміти, що якщо ви відправите лог у 1000 токенів, він не зможе його позбутися (тільки самарі зробити, при чому саме з ним). А якщо скопіюєте у файл та відправите до нього лише те, де треба щось пофіксити (наприклад, виділите 20 рядків), то інше він сам зможе знайти, якщо йому треба.
Повернемося до цієї картинки:
Тут добре видно, як росте контекст. Був 46000, потім 49000, потім 50000. І це все одне питання, модель збагачує свій контекст за необхідності.
Тому наша ціль — знаходити баланс між тим, як його збагатити контекстом одразу, і як би його зберегти.
Дизайн
Якщо ви робите щось для користувачів, а не лише серверну частину, то, напевно, вам потрібен дизайн.
І якщо ви такий самий дизайнер, як і я, то мені дуже шкода 😊
Тому що мій перший дизайн був таким:
Як ви можете бачити, це просто крінж. Я і дизайн — ці слова ніколи не стояли в одному реченні.
І, що найцікавіше — люди користувались, і їм було ок, тому що інструмент розв’язував їхні проблеми.
Та так не можна було залишати все, тому я пішов у роздуми. Спробував купу всього, і один спосіб мені дійсно допоміг — я пішов у Claude Opus і попросив його:
І кинув йому скріни, що вище. Я нічого не казав про проєкт, лише ось це одне речення і скріни.
Через 57 ітерацій, де він домальовував або прибирав щось, я отримав таке:
І це було щось цікавіше. Тоді я йому сказав розписати мені увесь гайдлайн. І він це зробив — там була вся інфа щодо основних кольорів, структури й так далі.
Після цього я поклав цей HTML у git, поруч поклав дизайн системи, і сказав чатику — зробити так, як тут. Це було жахливо, але за два дні я вже отримав фінальний дизайн, який зараз виглядає так:
Так, звісно, можна і краще зробити. Але, думаю, ви погодитесь зі мною, що за два дні — і так буде ок. А потім вже можна і витрачати кошти на дизайн.
Головне, що мені дав чат — деякі цікаві штуки, як-от бейджі. Я чомусь взагалі про них не думав.
Завершення
Я не геній і не «сеньйор на всіх мовах». Я просто навчився: ставиш чату маленьку, чітку таску — отримуєш інкремент — фіксуєш логікою/тестом — комітиш. Так і народжується продукт.
Вайбкодинг — це не магія, це темп. ШІ як машина — вона їде, але кермо — в мене, і якщо я не туди поверну, то це означає, що я не вмію керувати.
Головне — реальна користь, прозора ціна, гарний настрій.
Ключові правила (крок за кроком, але коротко)
КРОК 0. Намір і рамки
-
1–2 речення «що роблю і для кого». - Як приймаю роботу: демо/тест/скрін.
- Чітко «не робити»: які файли/фреймворки/шляхи заборонені.
КРОК 1. Дві годинки без ШІ
- Гуглю аналоги, читаю коменти/біль користувачів, зберігаю в /docs/research/*.
- Оновлюю свій опис і вимоги.
КРОК 2. Б’ємо ідею об стіну (в ШІ)
- Прошу чат: «рознеси мою ідею», «де провалиться», «які ризики/вартості».
- Те, що болить, — виносимо у вимоги й таски.
КРОК 3. Єдине джерело правди, наш контракт з AI
/docs/requirements/*/docs/patterns/*/docs/tasks/task_XX<span>.</span>md # назва, контекст, тести приймання
КРОК 4. Декомпозиція до людського
- Файли
200–300 рядків. Ніяких «бог-класів». - Вказую шар і патерн: Strategy/Adapter/Facade/Repository.
- Кожна таска має очікуваний артефакт (файл/віджет/скрін).
КРОК 5. Правильна порція контексту
- Даю тільки потрібні фрагменти коду + уривки логів
20–40 рядків. - Форматую відповідь: «код-блоки + список команд + як перевірити».
КРОК 6. Промпт — це контракт
- «Роль» агента, «межі», «кроки», «формат виходу».
- Додаю міні-тести приймання в сам запит.
КРОК 7. Інструменти під мій гаманець і нерви
- На старті: Copilot (стабільна ціна за реквест, норм контроль).
- Модель: GPT-5 для темпу, Claude — коли треба розкопати складне, Gemini — коли велике вікно контексту на аналіз.
- Налаштовую Tasks/Build Tasks у IDE, щоб агент міг ганяти перевірки без DDoS-терміналу.
КРОК 8. Логи — очі агента
- Свій лог-сервіс: час, модуль, група, повідомлення, рівень.
- Емодзі-якорі в логах — швидкий фільтр.
- Логи не видаляю — вимикаю рівнями.
КРОК 9. Ритм і контроль
- «Одна таска — один коміт після зеленої перевірки».
- Якщо агент лізе міняти тести під код — стоп, розвертаємо: спочатку код до тестів.
- Бачу стиснення контексту — ділю таску ще дрібніше.
Фінал
Вайбкодинг — це «малими чіткими кроками, але щодня». Агент прискорює, та не думає замість нас.
Ми задаємо рамки, ритм і стандарт якості. Усе інше — справа техніки і логів.
Petro Petrenko
Mikhail Dubovskiy
sydir2025
Undisclosed User
Mykhailo Tsymbaliuk
Sergey Lysak
Дм
igor shaula
Ivan Solomichev
Volodymyr Lubenchenko
Volodymyr Verdysh
Roman Petrovich
Andrey
Володимир Корнійчук
Andriy Shevchenko
Петтинг Пудинга
Vitaliy Fedoriv
Vitaliy Kaplenko
Veronika Liashenko
Volodymyr Dvernytskyi
Serhii Vedmediev
Serhii Vedmediev
Nero Burning ROM
Yuri Glushko
Anton Martynenko
Valentyn Hlyvich
Артур Шевченко
172 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів