За допомогою вайбкодингу можна дуже швидко пройти шлях від ідеї до працюючого застосунку. Ви описуєте завдання, AI створює код, ви перевіряєте результат і просите внести наступну зміну.
Спочатку все може працювати добре. Але з часом виникають характерні проблеми:
- одна зміна ламає іншу функцію;
- AI повторює код у різних частинах проєкту;
- структура файлів стає незрозумілою;
- виправлення однієї помилки створює кілька нових;
- ніхто вже не впевнений, які частини коду справді використовуються;
- додавати нові функції стає дедалі складніше.
Це не завжди означає, що проєкт потрібно створювати заново. Можливо, йому потрібен vibe coding cleanup.
Що таке vibe coding cleanup
Vibe coding cleanup - це перевірка та впорядкування проєкту, значна частина якого була створена за допомогою AI.
Його мета не в тому, щоб переписати весь застосунок або змінити його функції. Мета cleanup - зробити проєкт:
- зрозумілим;
- стабільним;
- перевірюваним;
- безпечнішим;
- придатним до подальших змін;
- зручним для передачі іншій людині.
Простіше кажучи, застосунок має не лише працювати сьогодні. Потрібно, щоб у ньому можна було безпечно щось змінити через місяць або пів року.
Cleanup може включати code review, рефакторинг, видалення зайвого коду, створення тестів, перевірку структури бази даних, документування та базову перевірку безпеки.
Чому робочий AI-код може потребувати очищення
Головна перевага AI-розробки - швидкість. Але рішення, які допомагають швидко отримати результат, не завжди є найкращими для довгострокового розвитку проєкту.
AI зазвичай розв’язує конкретне завдання, яке отримав зараз:
Додай форму реєстрації.
Створи новий тип користувача.
Виправ помилку в оплаті.
Додай ще одне поле до профілю.
Кожне окреме рішення може працювати. Але після десятків таких змін у проєкті можуть з’явитися:
- кілька способів виконувати одну й ту саму дію;
- функції, які більше не використовуються;
- різні правила обробки однакових даних;
- залежності між частинами системи, про які AI не знає;
- тимчасові рішення, які стали постійними;
- надмірно великі файли та функції;
- код, який важко перевірити окремо.
У програмній розробці такі накопичені проблеми часто описують як технічний борг.
Мартін Фаулер пояснює технічний борг через фінансову метафору: недоліки внутрішньої структури системи змушують витрачати більше зусиль на кожну наступну зміну. Ці додаткові витрати працюють як відсотки за боргом.
Тому головна ознака технічного боргу - не те, що код виглядає неідеально. Головна ознака - кожну нову функцію стає довше, дорожче та небезпечніше додавати.
«Працює» не завжди означає «готове до розвитку»
У вайбкодингу легко перевірити видиму частину результату:
- сторінка відкривається;
- кнопка працює;
- користувач може зареєструватися;
- дані зберігаються;
- оплата проходить.
Але за працюючим інтерфейсом можуть залишатися питання:
- Чи не дублюється логіка?
- Чи правильно розмежований доступ до даних?
- Чи можна безпечно змінити структуру бази?
- Чи є резервна копія?
- Чи зрозуміє інший розробник структуру проєкту?
- Чи перевіряються критичні сценарії автоматичними тестами?
- Чи не зберігаються секретні ключі безпосередньо в коді?
- Чи можна відновити останню робочу версію?
GitHub у своєму керівництві з перевірки AI-generated code рекомендує поєднувати функціональну перевірку, автоматичні інструменти та людське рев’ю. Особливо важлива така перевірка для великих змін і старих кодових баз, де одна правка може впливати на багато інших частин системи.
Ознаки, що проєкту потрібен cleanup
Не кожен застосунок після вайбкодингу потребує окремого очищення. Якщо це маленький особистий інструмент, який стабільно виконує одну функцію, cleanup може бути зайвим.
Але варто задуматися про нього, якщо з’являються такі ознаки.
1. Одна зміна постійно ламає іншу
Ви просите AI додати нове поле до профілю, а після цього перестає працювати реєстрація. Виправляєте реєстрацію - зникають дані в кабінеті.
Це може свідчити про надто сильну залежність між різними частинами системи.
2. AI зациклюється на одній помилці
Агент кілька разів виправляє ту саму проблему, але вона повертається. Або кожне виправлення створює нову помилку.
У такій ситуації наступний промпт не завжди допоможе. Спочатку потрібно зрозуміти справжню причину проблеми.
3. Одна логіка існує в кількох місцях
Наприклад, статус підписки перевіряється окремо:
- на сторінці профілю;
- у платіжному webhook;
- в API;
- у панелі адміністратора.
Якщо правила трохи відрізняються, система починає поводитися непередбачувано.
4. У проєкті багато файлів, призначення яких незрозуміле
AI може створити новий файл замість зміни наявного, залишити стару реалізацію або додати альтернативний компонент.
З часом стає незрозуміло, який код використовується, а який залишився від попередніх ітерацій.
5. Нові функції займають дедалі більше часу
Спочатку новий екран створювався за один вечір. Тепер навіть маленька зміна потребує багатьох спроб, відкатів і виправлень.
Це одна з найпомітніших ознак накопичення технічного боргу.
6. Ви боїтеся торкатися робочих частин застосунку
Якщо будь-яка зміна викликає страх, що весь проєкт перестане працювати, проблема вже не тільки в окремій помилці. Проєкту бракує контрольованості.
7. Проєкт неможливо передати іншій людині
Інший розробник не розуміє:
- як влаштована система;
- де знаходиться основна бізнес-логіка;
- як запустити проєкт;
- які сервіси підключені;
- де описана структура бази;
- які частини критичні.
У такому стані кожна передача проєкту починається з дорогого розслідування.
Що входить у vibe coding cleanup
Cleanup не зводиться до команди:
Clean up my code.
Безпечне очищення складається з кількох окремих етапів.
1. Фіксація поточного стану
Перед будь-якими змінами потрібно:
- зберегти резервну копію;
- зафіксувати останню робочу версію;
- перевірити, що код збережений у Git;
- записати, які функції зараз працюють;
- зберегти копію важливих даних.
Починати cleanup без можливості відкотитися небезпечно.
2. Карта проєкту
Потрібно зрозуміти:
- з яких частин складається застосунок;
- де знаходиться frontend;
- де працює backend;
- де зберігаються дані;
- як реалізована авторизація;
- які зовнішні сервіси використовуються;
- як відбувається публікація;
- де знаходиться основна бізнес-логіка.
Результатом може бути короткий технічний документ або проста схема.
3. Code review
Code review допомагає не відразу змінювати код, а спочатку визначити його стан.
Google у своїх інженерних рекомендаціях пропонує під час рев’ю звертати увагу на загальний дизайн, функціональність, складність, зрозумілість назв, тести та відповідність змін реальному завданню.
Для вайбкодинг-проєкту варто перевірити:
- чи зрозуміла структура;
- чи немає зайвої складності;
- чи не дублюється логіка;
- чи використовуються всі файли та функції;
- чи зрозумілі назви;
- чи не створив AI функціональність, якої ніхто не просив;
- чи можна тестувати критичні частини окремо.
4. Видалення непотрібного коду
У проєкті можуть залишатися:
- старі компоненти;
- невикористані API endpoints;
- дублікати функцій;
- тимчасові скрипти;
- зайві залежності;
- закоментовані версії попереднього коду;
- експериментальні функції, які більше не потрібні.
Видаляти їх потрібно поступово, перевіряючи поведінку застосунку після кожного кроку.
5. Усунення дублювання
Якщо однакове правило описано в кількох місцях, його бажано винести в одну контрольовану функцію або сервіс.
Наприклад, замість п’яти різних перевірок доступу до платного функціоналу має існувати одне зрозуміле правило.
6. Спрощення складних частин
Cleanup може включати:
- поділ великого файлу на менші модулі;
- поділ надто великої функції;
- зменшення вкладеності умов;
- спрощення передачі даних;
- виділення повторюваної логіки;
- видалення зайвих рівнів абстракції.
Важливо не зробити систему «архітектурно ідеальною», а зробити її зрозумілішою за поточний стан.
7. Додавання тестів
Особливо важливо перевіряти сценарії, втрата яких буде дорогою:
- реєстрація;
- вхід;
- відновлення пароля;
- платежі;
- зміна статусу підписки;
- права доступу;
- створення та видалення даних;
- адміністративні функції.
Тести створюють захисну сітку. Вони допомагають зрозуміти, чи не зламала внутрішня перебудова зовнішню поведінку застосунку.
8. Документування
Мінімальна документація має пояснювати:
- як запустити проєкт;
- як його опублікувати;
- які змінні середовища потрібні;
- які зовнішні сервіси підключені;
- де знаходиться ключова логіка;
- як створюються резервні копії;
- як безпечно вносити зміни.
Документація потрібна не лише майбутньому розробнику. Вона також допомагає давати AI точніший контекст.
9. Базова перевірка безпеки
Під час cleanup варто перевірити:
- чи немає API keys у відкритому коді;
- чи правильно розмежований доступ;
- чи не може один користувач побачити дані іншого;
- чи перевіряються дані на сервері;
- чи оновлені критичні залежності;
- чи захищені адміністративні функції;
- чи не потрапляють персональні дані в логи.
NIST рекомендує поєднувати code review з автоматичним аналізом коду та фіксувати виявлені проблеми для подальшого виправлення.
Водночас cleanup не дорівнює повному security audit. Якщо застосунок працює з платежами, медичними даними, документами або іншою чутливою інформацією, може знадобитися окрема професійна перевірка безпеки.
Cleanup, code review, rescue і rewrite: у чому різниця
Ці терміни описують різні стани проєкту.
Code review
Проєкт перевіряють, щоб зрозуміти:
- як він побудований;
- де знаходяться ризики;
- що варто виправити;
- чи готовий він до запуску або розвитку.
Code review передує змінам.
Cleanup
Проєкт переважно працює, але його внутрішню структуру потрібно привести до ладу.
Cleanup може включати рефакторинг, тести, документацію, видалення зайвого коду та усунення дублювання.
Rescue
Проєкт уже частково зламаний або вийшов з-під контролю:
- AI не може завершити виправлення;
- немає зрозумілої робочої версії;
- зміни конфліктують між собою;
- власник не розуміє, що можна безпечно змінювати.
Спочатку потрібно відновити стабільний стан, а вже потім проводити cleanup.
Rewrite
Значну частину застосунку створюють заново.
Це найдорожчий варіант. Він потрібен не тому, що код неідеальний, а коли поточну структуру неможливо безпечно адаптувати до реального завдання.
Чи можна зробити cleanup за допомогою AI
Так, AI може суттєво допомогти:
- пояснити структуру файлу;
- знайти дублювання;
- визначити невикористані функції;
- запропонувати поділ великої функції;
- написати тести;
- створити документацію;
- перевірити залежності;
- запропонувати послідовність рефакторингу.
Але небезпечно давати загальну команду:
Перепиши весь проєкт правильно.
Велика неконтрольована зміна може створити більше проблем, ніж вирішити.
Краще працювати маленькими кроками:
- Проаналізуй цей модуль, але нічого не змінюй.
- Поясни, які проблеми ти бачиш.
- Запропонуй план із невеликих кроків.
- Визнач, які тести потрібні перед змінами.
- Виконай лише перший крок.
- Не змінюй інші файли.
- Покажи точний список змін.
- Перевір тести.
AI добре допомагає виконувати cleanup. Але рішення про те, що можна видалити, яка поведінка є правильною і які ризики прийнятні, має приймати людина.
Безпечний порядок cleanup
Практичний порядок може виглядати так.
Крок 1. Зупинити додавання нових функцій
Якщо система вже нестабільна, нові функції лише збільшують кількість невідомих.
Крок 2. Зберегти робочу версію
Потрібні Git, backup бази та копія змінних середовища.
Крок 3. Описати поточну поведінку
Потрібно зафіксувати, що саме має працювати для користувача.
Крок 4. Перевірити критичні сценарії
Перед внутрішніми змінами варто додати тести хоча б для авторизації, даних, платежів і прав доступу.
Крок 5. Скласти список проблем
Не потрібно виправляти все одночасно. Проблеми можна розділити на:
- критичні;
- пов’язані з безпекою;
- ті, що блокують розвиток;
- косметичні;
- необов’язкові.
Крок 6. Вносити невеликі зміни
Кожна зміна має бути зрозумілою, обмеженою та перевірюваною.
Крок 7. Перевіряти результат після кожного кроку
Якщо щось перестало працювати, має бути легко визначити, яка саме зміна це спричинила.
Крок 8. Оновити документацію
Після cleanup потрібно зафіксувати нову структуру та правила роботи з проєктом.
Коли cleanup не потрібен
Не потрібно перетворювати кожен маленький AI-проєкт на корпоративну систему.
Cleanup може бути зайвим, якщо:
- застосунок використовує одна людина;
- він виконує просту некритичну функцію;
- дані легко відновити;
- проєкт не планують розвивати;
- зміни вносяться рідко;
- помилка не матиме серйозних наслідків.
Внутрішня якість особливо важлива тоді, коли застосунок потрібно регулярно змінювати. Google формулює головну мету code review як поступове покращення загального стану кодової бази.
Тому обсяг cleanup має відповідати реальним планам проєкту.
Коли cleanup уже недостатньо
Іноді поступове впорядкування буде дорожчим за часткове або повне переписування.
Це можливо, якщо:
- поточна архітектура не відповідає основному завданню;
- невідомо, які дані є правильними;
- неможливо відновити робочу версію;
- критичні частини не можна перевірити окремо;
- проєкт повністю залежить від недоступної платформи;
- одна й та сама логіка існує в багатьох несумісних версіях;
- безпеку неможливо виправити локальними змінами;
- вартість розуміння старої системи вища за створення нової.
Але рішення про rewrite краще приймати після code review, а не в момент найбільшого роздратування.
Чекліст перед cleanup
Перед початком перевірте:
- Код збережений у Git.
- Є остання стабільна версія.
- Створена резервна копія бази.
- Відомо, які функції мають працювати.
- Є список підключених сервісів.
- API keys зберігаються у змінних середовища.
- Визначені критичні сценарії.
- Cleanup розбитий на невеликі кроки.
- Після кожного кроку можна запустити перевірку.
- Зрозуміло, хто приймає рішення про правильну поведінку системи.
Висновок
Vibe coding cleanup - це не покарання за використання AI і не доказ того, що вайбкодинг не працює.
Вайбкодинг допомагає дуже швидко перевірити ідею та створити першу версію продукту. Cleanup потрібен тоді, коли цей продукт починає жити довше за перший експеримент:
- отримує реальних користувачів;
- працює з важливими даними;
- приймає платежі;
- регулярно змінюється;
- передається іншій людині;
- перетворюється з прототипу на постійний інструмент.
Головна мета cleanup - не зробити код ідеальним. Вона полягає в тому, щоб повернути контроль над проєктом і зробити наступні зміни зрозумілими та безпечними.
