---
title: "Masalah Struktural Proyek Vibe Coding dan Sprint Pemulihan 4 Jam"
locale: id
category: how_to
category_name: "Panduan"
translation_status: reviewed
license: cc_by
author: "injoys"
source_url: https://injoys.com/en/articles/vibe-coding-project-architecture-and-four-hour-rescue-sprint
published_at: 2026-07-30T13:43:49+09:00
---

# Masalah Struktural Proyek Vibe Coding dan Sprint Pemulihan 4 Jam

> Penyebab proyek vibe coding terhambat tepat sebelum peluncuran mungkin bukan kemampuan membuat prompt, melainkan struktur yang tidak jelas, kode yang tidak konsisten, dan batas antarlayanan eksternal. Pemulihan 4 jam bukanlah metode yang menjamin penyelesaian seluruh layanan, tetapi harus dipahami sebagai sprint bersyarat untuk menetapkan cakupan, mengimplementasikan ulang alur inti, dan membuat tolok ukur dasar yang dapat dijalankan.

## Key Points

- React, Next.js, dan Supabase sendiri bukanlah masalah; kompleksitas meningkat dengan cepat ketika ketiganya digabungkan tanpa batas tanggung jawab dan aturan implementasi.
- Karena AI tidak secara otomatis mempertahankan maksud desain dan kondisi operasional seluruh repositori, fungsi yang sama dapat diimplementasikan dengan pola yang berbeda.
- Ruby on Rails mengurangi pilihan melalui konvensi dan komponen yang terintegrasi, tetapi tidak otomatis menyelesaikan pembayaran, verifikasi keamanan, maupun kesiapan operasional.
- Pemulihan 4 jam adalah pekerjaan rekonstruksi awal atau stabilisasi yang memungkinkan jika persyaratan sudah ditetapkan, cakupan inti sempit, akun dan infrastruktur siap, serta dikerjakan oleh tenaga berpengalaman.
- Keputusan untuk terus memperbaiki kode yang ada atau membuatnya kembali harus diambil dengan membandingkan bukan hanya kondisi kode, tetapi juga migrasi data, integrasi eksternal, pengujian, kemampuan tim, dan risiko peluncuran.

Vibe coding adalah cara kerja yang memanfaatkan instruksi bahasa alami dan alat coding AI untuk mengimplementasikan aplikasi dengan cepat. Pada tahap awal, layar dan fitur bertambah dengan cepat, tetapi menjelang peluncuran, masalah yang melintasi berbagai lapisan seperti autentikasi, data, pembayaran, dan deployment cenderung mulai terlihat.

Fenomena ini tidak boleh dijelaskan hanya sebagai kelemahan stack teknologi tertentu atau kemampuan prompt pengguna. Intinya adalah **siapa yang mengendalikan konsistensi struktural**, **apakah tanggung jawab setiap komponen sudah jelas**, dan **apakah tersedia pengujian untuk memverifikasi bahwa pekerjaan telah selesai**.

## Alasan proyek vibe coding mengalami kebuntuan pada tahap akhir

### Penyelesaian layar berbeda dengan penyelesaian layanan

Dalam pengembangan awal, hasil yang terlihat seperti tombol, formulir input, dan daftar dapat dibuat dengan cepat. Namun, layanan nyata memerlukan kondisi tak terlihat berikut ini.

- Pemeriksaan izin agar pengguna hanya dapat mengakses datanya sendiri
- Pemrosesan data yang tahan terhadap permintaan duplikat dan percobaan ulang jaringan
- Keberhasilan, kegagalan, pembatalan, dan pengembalian dana pembayaran serta verifikasi webhook
- Validasi nilai input dan pemulihan dari kesalahan
- Perubahan database dan migrasi data lama
- Pengelolaan secret key, log, pemantauan, pencadangan, dan pemulihan
- Pengujian otomatis yang memastikan fungsi inti tetap berjalan setelah deployment

Fakta bahwa layar berfungsi tidak berarti kondisi-kondisi tersebut telah terpenuhi. Cacat yang ditemukan pada tahap akhir bukanlah muncul secara tiba-tiba, tetapi sering kali merupakan akumulasi dari hal-hal yang tidak diverifikasi dalam implementasi awal.

### AI tidak selalu dapat mempertahankan maksud desain seluruh repositori

Alat coding AI menghasilkan usulan perubahan berdasarkan file yang diberikan, konteks percakapan, kode yang ditemukan, dan instruksi. Jika aturan proyek tidak didokumentasikan, ketidakkonsistenan berikut dapat terjadi.

- Mengimplementasikan pengambilan data yang sama secara berbeda di komponen server, rute API, dan kode browser
- Mengelola status autentikasi secara redundan di cookie, status klien, dan SDK eksternal
- Menuliskan aturan validasi yang sama secara berbeda di layar dan server
- Hanya menambahkan penanganan pengecualian atau pernyataan kondisi tanpa menyelesaikan akar masalah
- Berulang kali membuat fungsi dan model data serupa karena tidak menemukan abstraksi yang sudah ada

Dalam kondisi ini, memperbaiki kesalahan baru di satu lapisan dapat merusak asumsi di lapisan lain. Pengguna mungkin merasa AI terus berputar-putar di tempat yang sama, tetapi situasi sebenarnya bisa jadi tidak ada satu struktur dan standar verifikasi tunggal yang harus diikuti AI.

## Memahami kombinasi React·Next.js·Supabase secara akurat

Mendefinisikan React, Next.js, dan Supabase semata-mata sebagai stack rakitan yang buruk bukanlah penilaian yang akurat. Setiap teknologi memiliki peran independen dan keunggulan yang digunakan secara luas.

| Teknologi | Peran dasar | Hal yang harus diputuskan dalam proyek |
|---|---|---|
| React | Library untuk membangun antarmuka pengguna | Pengelolaan status, permintaan data, batas komponen |
| Next.js | Framework web full-stack berbasis React | Metode rendering, batas server·klien, konfigurasi cache dan API |
| Supabase | Platform backend yang menyediakan PostgreSQL, autentikasi, penyimpanan, dan lainnya | Kebijakan akses, model data, pemrosesan sesi, izin layanan |
| Ruby on Rails | Framework aplikasi web terintegrasi yang berpusat pada server | Model, controller, job, email, dan konfigurasi deployment dalam konvensi Rails |

Next.js bukan sekadar alat yang menangani layar, tetapi juga menyediakan fungsi server. Supabase juga bukan sekadar database, melainkan dapat mencakup autentikasi, penyimpanan, dan lainnya. Masalah muncul ketika penggunaan banyak fungsi dilakukan tanpa menentukan **di mana letak tanggung jawab akhir atas izin dan aturan bisnis**.

Sebagai contoh, jika aturan pembuatan pesanan tersebar di kode browser, rute server Next.js, dan kebijakan database Supabase, kesalahan akan sulit dilacak. Sebaliknya, jika ditetapkan aturan bahwa operasi tulis harus melalui lapisan layanan server dan kebijakan database digunakan sebagai garis pertahanan terakhir, stack yang sama pun dapat dioperasikan secara stabil.

## Alasan Ruby on Rails dapat menjadi alternatif

### Mengurangi pilihan dengan mengutamakan konvensi

Prinsip utama Ruby on Rails, yaitu mengutamakan konvensi, menyatukan keputusan struktural yang harus dibuat berulang kali ke dalam aturan dasar framework. Lokasi dan cara menghubungkan model, controller, perubahan database, job, email, dan pengujian menjadi relatif mudah diprediksi.

Dalam coding AI, keterprediksian ini sangat berguna. Mengikuti konvensi yang jelas mengurangi kemungkinan AI menambahkan fitur baru dengan pola yang sama sekali berbeda dan memudahkan manusia meninjau perubahan.

### Menangani fungsi umum layanan web dalam satu sistem

Rails menyediakan komponen dan jalur resmi untuk akses database, routing, rendering server, job asinkron, email, komunikasi real-time, pengujian, dan deployment. Dengan demikian, titik sambungan antaralat terpisah dapat dikurangi.

Namun, batasan berikut juga jelas.

- Pemrosesan pembayaran tetap memerlukan penyedia pembayaran eksternal seperti Stripe.
- Halaman admin tidak otomatis selesai dalam bentuk yang sesuai dengan semua kebutuhan.
- Meskipun fungsi autentikasi dibuat atau dikonfigurasi menggunakan library, desain izin dan tinjauan keamanan tetap merupakan pekerjaan terpisah.
- Antarmuka real-time yang kompleks atau API seluler independen memerlukan desain tambahan.
- Jika tim tidak memiliki pengalaman dengan Rails, akan timbul biaya pembelajaran dan perekrutan.

Oleh karena itu, Rails bukanlah alat yang membuat AI menyelesaikan semua masalah, melainkan **pilihan yang mempersempit jalur dasar yang harus diikuti AI dan manusia**.

## Apa yang dapat diselesaikan dalam 4 jam

Tidak ada dasar universal untuk menyatakan bahwa layanan apa pun yang mencakup login, pembayaran, fungsi admin, migrasi data, tinjauan keamanan, dan deployment operasional dapat diselesaikan dalam 4 jam. Sasaran realistis untuk 4 jam adalah sebagai berikut.

- Memahami struktur saat ini dan titik kegagalan.
- Memilih antara pemeliharaan dan implementasi ulang.
- Membuat satu alur pengguna terpenting berfungsi.
- Membuat baseline baru yang dapat diuji.
- Jika memungkinkan, melakukan deployment ke lingkungan staging.
- Mencatat risiko yang tersisa dan pekerjaan lanjutan.

### Kondisi yang memungkinkan implementasi ulang dalam 4 jam

Semakin banyak kondisi berikut terpenuhi, semakin memungkinkan implementasi ulang dalam waktu singkat.

1. Layar dan alur pengguna yang diperlukan sudah ditetapkan.
2. Item data inti dan relasinya sudah dirapikan.
3. Layar yang ada dapat dijadikan referensi tanpa perlu membahas ulang desain.
4. Repositori, domain, lingkungan deployment, dan akun layanan eksternal dapat segera diakses.
5. Migrasi data lama dapat dilewati atau cukup memindahkan sampel kecil.
6. Pembayaran dibatasi pada cakupan sempit, seperti alur keberhasilan dasar di sandbox.
7. Pekerja yang memahami Rails dan lingkungan deployment meninjau output AI.

Di sinilah proyek lama yang telah berjalan selama beberapa bulan dapat membantu. Jika selama periode tersebut alur pengguna, field wajib, kasus kegagalan, dan prioritas telah diperjelas, waktu eksplorasi dapat dikurangi. Namun, ini tidak berarti perencanaan otomatis menjadi sempurna, dan hanya persyaratan yang telah terverifikasi dalam proyek lama yang boleh digunakan kembali.

## Sprint pemulihan praktis selama 4 jam

| Waktu | Pekerjaan | Output minimum |
|---|---|---|
| 0:00~0:30 | Mempertahankan repositori dan status operasional, menyelidiki stack teknologi | Cadangan, daftar komponen, pemeriksaan paparan informasi rahasia |
| 0:30~1:00 | Menetapkan alur inti dan model data, memutuskan perbaikan·implementasi ulang | Cakupan satu kalimat, kriteria penyelesaian, daftar risiko |
| 1:00~2:00 | Baseline Rails atau perbaikan struktural proyek lama | Aplikasi yang dapat dijalankan, model data, kerangka autentikasi |
| 2:00~3:15 | Implementasi vertikal alur pengguna inti | Satu alur yang terhubung dari layar hingga penyimpanan data beserta pengujian |
| 3:15~3:45 | Konfigurasi minimum integrasi eksternal dan deployment staging | Integrasi sandbox, URL deployment, konfigurasi variabel lingkungan |
| 3:45~4:00 | Smoke test dan serah terima | Hasil keberhasilan·kegagalan, item yang belum selesai, urutan pekerjaan berikutnya |

### Langkah 1: Pertahankan sumber asli

Sebelum melakukan perubahan, buat branch terpisah atau salinan repositori dan cadangkan database. Jangan menempelkan API key, kata sandi database, atau informasi identitas pribadi ke dalam percakapan AI. Jika sudah terpapar, lebih aman mencabut informasi rahasia tersebut dan menerbitkan yang baru.

### Langkah 2: Selidiki stack teknologi disertai bukti

Jangan hanya meminta AI menebak stack teknologi, tetapi minta AI memeriksa materi berikut.

- Manifest dan lock file yang mencatat paket serta versinya
- Skema database dan migrasi
- File yang menangani autentikasi dan sesi
- Rute API dan fungsi server
- Konfigurasi deployment, nama variabel lingkungan, dan SDK layanan eksternal
- Pengujian otomatis dan konfigurasi integrasi berkelanjutan

Contoh permintaan yang dapat digunakan adalah sebagai berikut.

> Baca repositori dan susun frontend, server, database, autentikasi, penyimpanan, pembayaran, deployment, serta alat pengujian dalam bentuk tabel. Cantumkan jalur file yang menjadi dasar setiap penilaian, lalu tandai lokasi tempat aturan bisnis diduplikasi dan kemungkinan pelanggaran batas server·klien. Jangan ubah kode terlebih dahulu dan jangan tampilkan nilai rahasia.

### Langkah 3: Pilih hanya satu alur vertikal inti

Alur vertikal adalah satu jalur lengkap yang terhubung dari layar hingga logika server dan penyimpanan data. Contohnya adalah sebagai berikut.

- Pendaftaran anggota → login → melihat profil
- Memilih produk → membuat pesanan → persetujuan sandbox pembayaran
- Login admin → menulis postingan → tampil di halaman publik

Daripada membuat banyak layar sekaligus, memverifikasi satu alur inti dalam kondisi berhasil, tanpa izin, dan input tidak valid akan mengungkap risiko struktural lebih cepat.

### Langkah 4: Tetapkan kriteria penyelesaian melalui pengujian

Jika AI hanya diminta mengimplementasikan fungsi, kode yang dihasilkan mungkin hanya disesuaikan dengan kasus keberhasilan yang terlihat di layar. Setidaknya, tetapkan kondisi berikut sebagai pengujian otomatis atau daftar periksa yang dapat diulang.

- Pengguna yang valid dapat menyelesaikan pekerjaan.
- Pengguna yang belum login tidak dapat mengakses data yang dilindungi.
- Meskipun memasukkan pengenal pengguna lain, data pengguna tersebut tidak dapat diakses.
- Input yang tidak valid tidak disimpan dan mengembalikan pesan kesalahan yang dapat dipahami.
- Permintaan pembayaran atau penulisan yang sama tidak diproses secara duplikat meskipun diulang.

### Langkah 5: Lakukan deployment hanya sampai staging

Deployment dalam sprint 4 jam umumnya lebih aman dianggap sebagai verifikasi staging, bukan konfirmasi untuk operasional. Sebelum menerima pengguna dan pembayaran sungguhan, keamanan, migrasi data, pemulihan cadangan, pemantauan, dan respons insiden harus diperiksa secara terpisah.

## Kriteria untuk memutuskan apakah proyek lama diperbaiki atau dibuat ulang

| Situasi | Mempertahankan·memperbaiki struktur lama | Mempertimbangkan implementasi ulang dengan Rails dan lainnya |
|---|---|---|
| Fungsi inti dan pengujian | Sebagian besar berfungsi dan tersedia pengujian | Bahkan alur inti berulang kali rusak |
| Data | Data operasional banyak dan risiko migrasi besar | Tidak ada data atau cakupan migrasi kecil |
| Struktur | Batas tanggung jawab dan pola umumnya konsisten | Fungsi yang sama diduplikasi di berbagai lapisan |
| Kebutuhan frontend | Interaksi kompleks dan aset React lama penting | CRUD berpusat pada server dan alur kerja menjadi fokus utama |
| Kapabilitas tim | Ada tenaga yang dapat mengoperasikan stack saat ini | Konvensi Rails lebih sesuai dengan cara kerja tim |
| Integrasi eksternal | Banyak integrasi stabil sudah beroperasi | Integrasi masih pada tahap awal atau dapat diganti |

Jangan melakukan penulisan ulang total hanya karena jumlah file banyak atau terdapat kesalahan. Penulisan ulang dapat menghilangkan penanganan kasus khusus yang sebelumnya telah diselesaikan dan menciptakan cacat baru. Sebaiknya implementasikan terlebih dahulu satu alur vertikal kecil dengan kedua pendekatan, lalu bandingkan kecepatan pengembangan, kemampuan pengujian, kemudahan memahami kode, dan risiko deployment.

## Item yang harus diperiksa secara terpisah sebelum peluncuran

Meskipun baseline 4 jam telah dibuat, item berikut mungkin masih tersisa.

- Tinjauan model izin dan konfigurasi keamanan Rails
- Tanda tangan webhook pembayaran, pencegahan duplikasi, serta pemrosesan pembatalan dan pengembalian dana
- Migrasi data operasional serta verifikasi jumlah data·total
- Pencadangan database dan pengujian pemulihan aktual
- Pelacakan kesalahan, retensi log, dan pemantauan ketersediaan
- Pengujian beban dan estimasi biaya
- Pemrosesan informasi pribadi, ketentuan penggunaan, dan tinjauan hukum terkait
- Pemeriksaan aksesibilitas, browser, dan lingkungan seluler
- Prosedur rollback saat terjadi gangguan dan penunjukan penanggung jawab

## Kesimpulan

Kebuntuan pada tahap akhir proyek vibe coding tidak dapat dijelaskan hanya oleh kemampuan coding AI. Jika aturan, batas tanggung jawab, pengujian, dan standar operasional tidak ditetapkan dalam konfigurasi dengan tingkat kebebasan tinggi, solusi lokal yang dibuat AI akan mudah saling bertentangan.

Ruby on Rails dapat menjadi alternatif praktis yang mengurangi tingkat kebebasan tersebut melalui konvensi dan struktur terintegrasi. Namun, membuat ulang setiap proyek dengan Rails bukanlah jawaban yang selalu benar. Pertama-tama, selidiki stack saat ini berdasarkan bukti, tentukan alur inti, lalu gunakan 4 jam sebagai **waktu untuk memverifikasi struktur dan membuat baseline yang dapat dipulihkan, bukan sebagai waktu untuk membuat produk jadi**.

## FAQ

### Mengapa proyek vibe coding berjalan cepat pada awalnya, tetapi melambat pada tahap akhir?
Pada tahap awal, banyak pekerjaan berfokus pada pembuatan alur normal yang terlihat, tetapi pada tahap akhir, masalah yang menghubungkan berbagai lapisan seperti otorisasi, konsistensi data, pemulihan kegagalan, pembayaran, deployment, dan keamanan menjadi terkonsentrasi. Tanpa aturan struktur dan pengujian, perbaikan lokal yang ditambahkan AI dapat berbenturan dengan kode yang sudah ada sehingga kecepatannya semakin menurun.

### Apakah penggunaan kombinasi React, Next.js, dan Supabase pasti menghasilkan kode spageti?
Tidak. Ketiga teknologi tersebut merupakan alat dengan peran yang jelas masing-masing, dan tim yang berpengalaman dapat membangun layanan yang stabil. Yang menjadi masalah adalah cara mengimplementasikan fungsi yang sama secara berulang di berbagai lapisan tanpa menetapkan tanggung jawab atas akses data, autentikasi, aturan bisnis, dan penanganan kesalahan.

### Apakah beralih ke Ruby on Rails menghilangkan kebutuhan akan semua layanan eksternal?
Tidak. Rails dapat menangani akses data, pemrosesan tugas, email, komunikasi waktu nyata, pengujian, dan deployment dalam sistem yang konsisten, tetapi layanan eksternal seperti penyedia pembayaran, infrastruktur pengiriman email, hosting cloud, dan pemantauan mungkin masih diperlukan.

### Apakah seluruh aplikasi benar-benar dapat dibuat ulang hanya dalam 4 jam?
Hal itu tidak dapat dijamin secara umum. Jika persyaratan dan model data telah ditetapkan, alur inti sangat terbatas, akun eksternal dan lingkungan deployment telah siap, serta tenaga ahli meninjau hasil AI, sebuah baseline yang dapat dijalankan atau MVP kecil dapat dibuat. Keamanan tingkat operasional, penanganan pengecualian pembayaran, migrasi data, dan respons terhadap gangguan biasanya memerlukan waktu tambahan.

### Apa saja tanda bahwa kode yang ada harus dibuang dan ditulis ulang?
Implementasi ulang dapat dipertimbangkan jika aturan bisnis inti diduplikasi di berbagai lokasi, perubahan kecil terus merusak fungsi yang tidak terkait, tidak ada pengujian otomatis, dan jumlah data masih sedikit sehingga biaya migrasinya rendah. Jika terdapat banyak data operasional dan integrasi eksternal yang stabil, atau struktur saat ini memiliki pengujian, perbaikan bertahap mungkin lebih aman.

### Bagaimana cara meminta AI menyelidiki tech stack proyek saat ini?
Mintalah AI membaca file paket, file lock, skema basis data, kode autentikasi, rute API, konfigurasi deployment, dan file pengujian, lalu membuat tabel yang memuat peran setiap teknologi beserta file yang menjadi dasarnya. Sebaiknya minta AI agar tidak langsung mengubah kode, tidak menampilkan nilai rahasia, serta menandai aturan bisnis yang diduplikasi dan kemungkinan pelanggaran batas antarlapisan.

### Fungsi apa yang harus diimplementasikan terlebih dahulu dalam pekerjaan pemulihan selama 4 jam?
Pilih satu alur pengguna inti yang mewakili nilai layanan. Jangan hanya membuat tampilan, tetapi hubungkan hingga autentikasi, validasi server, penyimpanan data, dan penanganan kegagalan, lalu uji kondisi pengguna yang sah dan pengguna yang tidak berwenang agar kelayakan strukturnya dapat dinilai dengan cepat.

### Apakah penggunaan Rails secara otomatis menyelesaikan masalah keamanan?
Tidak. Rails menyediakan berbagai pengaturan default dan fitur perlindungan keamanan, tetapi tidak secara otomatis mencegah otorisasi yang terlewat, kebocoran informasi rahasia, integrasi eksternal yang rentan, maupun konfigurasi deployment yang keliru. Panduan keamanan framework harus diikuti, dan otorisasi serta alur data khusus setiap aplikasi harus ditinjau secara terpisah.

## Sources

- [Belajar React](https://react.dev/learn)
- [Dokumentasi Next.js](https://nextjs.org/docs)
- [Dokumentasi Supabase](https://supabase.com/docs)
- [Doktrin Rails](https://rubyonrails.org/doctrine)
- [Panduan Ruby on Rails](https://guides.rubyonrails.org/)
- [Dasar-Dasar Active Job](https://guides.rubyonrails.org/active_job_basics.html)
- [Dasar-Dasar Action Mailer](https://guides.rubyonrails.org/action_mailer_basics.html)
- [Ikhtisar Action Cable](https://guides.rubyonrails.org/action_cable_overview.html)
- [Panduan Keamanan Ruby on Rails](https://guides.rubyonrails.org/security.html)
- [Panduan untuk Menguji Aplikasi Rails](https://guides.rubyonrails.org/testing.html)

## Images

![Pengembang berdiri di antara koneksi sistem kusut dan arsitektur berlapis yang rapi](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6NDI0OSwicHVyIjoiYmxvYl9pZCJ9fQ==--671c6671ab2b4dd55a12c8db4a32cd95021e1402/ai-ff797ac5.webp)
![Pengembang memperbaiki jembatan antara tebing retak dan platform kokoh dengan ikon keamanan dan deployment](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6NDI1NSwicHVyIjoiYmxvYl9pZCJ9fQ==--dd1b9b18b3b924f01625710e0b4bafd8fbbd0002/ai-74d32191.webp)