Kelas 11. Cara Menyelamatkan App Vibe Coding yang Rusak

Tips utama — inilah yang perlu kamu ketahui

App-mu rusak. Login yang berfungsi kemarin sekarang tidak bisa. Pembayaran ditarik dua kali. Setiap kali menyentuh kode, bagian lain ikut rusak. Ketika kamu minta AI untuk “perbaiki”, malah semakin parah.

Jangan bangun ulang dari nol. Bahkan jika dibangun ulang, akan rusak di tempat yang sama setelah 3 bulan. Kunci kondisi saat ini terlebih dahulu.

Ada tiga alat struktural:

• codistill — Diagnosis. Mengekstrak secara otomatis endpoint API, skema database, dan alur autentikasi dari kode yang ada.
• huma — Penguncian. Memasang regression test di semua endpoint untuk melindungi perilaku saat ini.
• yongol — Konversi. Menghasilkan backend baru dari SSOT dan membuktikan perilaku yang sama dengan test yang sudah ada.

Alurnya dari kiri ke kanan: diagnosa dengan codistill, kunci dengan huma, dan ketika siap, konversi dengan yongol.

Ke agen: “Jalankan codist scan untuk mengekstrak endpoint, skema database, dan alur autentikasi proyek ini.”

Kondisi saat ini muncul. Kamu bisa melihat dari 25 endpoint, berapa yang masih hidup dan berapa yang mati.

Ke agen: “Jalankan huma verify untuk memeriksa status semua endpoint, dan tulis test Hurl untuk setiap yang masih hidup.”

Inilah regression test. Kunci apa yang bekerja sekarang. Selama test ini lolos, perilaku yang ada tidak akan rusak meskipun agen memodifikasi kode.

Ke agen: “Sekarang perbaiki bug login. Tapi semua test Hurl harus lolos.”

Perbaiki bug tanpa merusak bagian lain. Perbaikan dilakukan dengan ratchet terkunci.

Pengalaman awal

Kamu bisa mencoba meski tanpa app yang rusak. Rasakan proses “buat → rusak → selamatkan” dalam 3 menit.

Langkah 1 — Buat app-nya

Di Claude Code:

“Buat API daftar tugas sederhana. 5 endpoint: lihat daftar tugas, tambah tugas, edit tugas, hapus tugas, tandai tugas selesai. Jalankan server-nya.”

Langkah 2 — Diagnosa dengan codist

“Jalankan codist scan untuk mengekstrak daftar endpoint dari proyek ini.”

codist secara otomatis mengambil path, method, dan parameter dari 5 endpoint tersebut. Inilah peta saat ini.

Langkah 3 — Kunci dengan huma

“Jalankan huma verify dan tulis test Hurl untuk semua endpoint.”

File Hurl dibuat untuk masing-masing dari 5 endpoint. Perilaku saat ini sudah terkunci.

Langkah 4 — Sengaja rusak

“Ubah format respons endpoint edit tugas. Ganti nama field title menjadi name.”

Setelah perubahan:

“Jalankan test Hurl.”

Test gagal. “Diharapkan title, tapi yang datang name.” Drift terdeteksi. Ratchet bekerja.

Langkah 5 — Perbaiki dengan ratchet terkunci

“Modifikasi agar semua test Hurl lolos. Tapi fitur baru yang menggunakan field name juga harus tetap ada.”

Agen mempertahankan kompatibilitas mundur saat memodifikasi. Hurl lolos berarti perilaku yang ada telah dipertahankan.

Inilah versi mini dari codistill → huma → perbaiki. Pada app yang benar-benar rusak, proses ini meluas menjadi 25, 50, atau 200 endpoint, tapi prinsipnya sama.

Mengapa kamu harus bekerja dengan cara ini

Pendahuluan: alasan sebenarnya app-mu rusak

Pada 2025, database dari 170 app yang dibuat dengan Lovable terekspos seluruhnya di internet. Email, API key, data pembayaran. Penyebabnya bukan bug kode. AI membuat app-app itu tanpa kebijakan keamanan, dan tidak ada yang memverifikasi.

Pada Januari 2026, 1,5 juta token API bocor dari jejaring sosial AI Moltbook. Penyebab yang sama. AI membangun, manusia tidak memeriksa.

Ini bukan cerita orang lain. Siapa saja yang membangun app dengan vibe coding duduk di atas struktur yang sama.

“Buat login” — 30 detik. “Tambah pembayaran” — 2 menit. “Tambah dashboard admin” — 5 menit. Setelah 3 bulan AI “merapikan” logika pembayaran dan mengubah kalkulasi diskon, menambah fitur baru memutus autentikasi, dan halaman yang berfungsi kemarin hari ini mengembalikan error 500.

Kamu ada di hadapan dua pilihan:

1. Bangun ulang
2. Selamatkan

Membangun ulang bisa dilakukan 3 bulan lalu. Masalahnya adalah pola yang sama berulang meski dibangun ulang. Drift adalah masalah struktural, bukan masalah kode.

Kamu harus belajar cara menyelamatkan.

Metode penyelamatan mandiri korban — 5 tahap

Menyelamatkan app yang rusak seperti menangani keadaan darurat dalam pendakian gunung. Jangan berlari. Tentukan posisi saat ini, amankan diri, dan bergerak selangkah demi selangkah.

Tahap 1. Diagnosis — apa yang masih hidup?

Hal pertama yang harus dilakukan bukan memperbaiki kode. Tapi memahami kondisi saat ini.

Ke agen: "Scan semua endpoint API dalam proyek ini.
Kirim permintaan nyata ke setiap endpoint
dan catat kode status respons-nya.
Susun hasilnya dalam tabel: path, method, kode status, waktu respons."

Jika 18 dari 25 endpoint mengembalikan 200, 4 mengembalikan 401, dan 3 mengembalikan 500 — inilah peta saat ini. Memulai perbaikan tanpa peta akan membuat yang diperbaiki merusak bagian lain.

codist scan dari codistill mengotomatisasi pekerjaan ini. Mengekstrak dari kode yang ada endpoint, model data, dan alur autentikasi.

Tahap 2. Penguncian — lindungi yang hidup terlebih dahulu

Setelah diagnosis selesai, kunci endpoint yang masih hidup.

Ke agen: "Tulis test Hurl untuk masing-masing
dari 18 endpoint yang mengembalikan 200.
Gunakan respons saat ini sebagai nilai yang diharapkan.
Untuk yang memerlukan autentikasi, jalankan
urutan login terlebih dahulu untuk mendapatkan token."

18 file Hurl ini adalah jaring pengaman. Apapun modifikasi yang dilakukan setelahnya, jika test ini lolos, perilaku yang ada telah dipertahankan.

huma verify dari huma mengatur proses ini. Melacak status per endpoint dan menilai PASS/IMPROVE/FAIL.

Penting: penguncian parsial tidak dibolehkan. Mengunci hanya 10 dari 18 berarti 8 sisanya bisa rusak saat perbaikan tanpa kamu tahu. Penguncian penuh adalah prinsipnya.

Tahap 3. Perbaikan — perbaiki dengan ratchet terkunci

Jaring pengaman sudah siap, sekarang saatnya memperbaiki bug.

Ke agen: "Cari penyebab login gagal dan perbaiki.
Tapi semua test Hurl harus lolos.
Kalau ada yang gagal, batalkan modifikasinya."

Inilah penerapan praktis dari Ratchet Pattern yang kamu pelajari di Kelas 6. Perbaiki tanpa merusak. Jalankan Hurl setelah setiap perbaikan. Jika lolos, lanjut ke bug berikutnya. Jika gagal, batalkan.

3 endpoint yang mengembalikan 500 diperbaiki dengan cara yang sama. Setelah perbaikan, test Hurl baru ditambahkan. Ratchet mengunci satu gigi lagi.

Tahap 4. Ekstraksi — keluarkan logika dari kotak hitam

Di sinilah inti masalahnya. Penyebab mendasar app rusak biasanya ada di sini.

Jika kamu menggunakan Supabase:

• Kebijakan RLS hanya ada di dashboard, tidak ada di kode
• Logika bisnis tersembunyi di Edge Functions
• Logika autentikasi terikat di Supabase Auth

Jika kamu menggunakan Firebase:

• Security Rules hanya ada di konsol
• Logika tersebar di Cloud Functions

Apapun BaaS yang digunakan, strukturnya sama. Logika bisnis berada di luar codebase.

Ke agen: "Ekstrak semua kebijakan RLS dari Supabase.
Simpan kebijakan SELECT, INSERT, UPDATE, dan DELETE
setiap tabel ke file SQL. Commit ke git."

Ke agen: "Analisis logika bisnis di Edge Functions.
Dokumentasikan fungsi mana yang mengimplementasikan aturan bisnis apa."

Tujuannya memindahkan logika dari dalam kotak hitam ke codebase. Setelah dipindahkan, agen bisa membacanya, mengujinya, dan menguncinya dengan ratchet.

codist ddl dari codistill mengekstrak DDL dari database yang ada. codist scan mengekstrak SSOT dari kode. Ini adalah alat yang memindahkan dari kotak hitam ke lapisan deklaratif.

Tahap 5. Konversi — hanya ketika siap

Setelah menyelesaikan tahap 1-4, app berada dalam kondisi ini:

• Semua endpoint memiliki regression test Hurl
• Bug telah diperbaiki
• Logika kotak hitam telah didokumentasikan dalam codebase
• Ratchet terkunci sehingga modifikasi baru tidak merusak perilaku yang ada

Dalam kondisi ini kamu memutuskan konversi. Dari Supabase ke backend sendiri, dari Deno ke Go, apapun itu.

Jaring pengaman konversi adalah test Hurl yang ditulis di Tahap 2. Jalankan Hurl yang sama di server baru, dan jika semua lolos — terbukti bahwa ia bekerja sama dengan legacy.

Ke agen: "Jalankan yongol generate untuk membuat backend Go+Gin.
Lulus semua test Hurl yang ada."

Konversi adalah Tahap 5, bukan Tahap 1. Mencoba konversi di Tahap 1 akan gagal. Ini adalah pelajaran yang dikonfirmasi dari insiden onboarding nyata.

Cara keluar dari Supabase

Kasus paling sering di Kelas 11 adalah Supabase. Orang mulai dengan vibe coding, all-in di Supabase, dan setelah 3 bulan semuanya runtuh.

Urutan keluar:

1. Pertahankan database dan hanya pasang ratchet

Gunakan PostgreSQL Supabase apa adanya. Mengubah database adalah yang terakhir.

codist ddl → ekstrak DDL dari tabel yang ada
huma verify → pahami kondisi endpoint saat ini
hurl → kunci penuh semua API yang hidup

2. Pindahkan logika ke kode

Kebijakan RLS → file Rego. Edge Functions → anotasi SSaC. Dari dashboard ke codebase.

3. Pisahkan autentikasi

Supabase Auth adalah yang terakhir dipisahkan. Karena hash password dari auth.users tidak bisa diekstrak, jika masih tahap awal (tanpa pelanggan) langsung konversi, jika sudah ada pelanggan jalankan periode autentikasi ganda.

4. Naikkan server baru dan validasi dengan Hurl

yongol generate → buat backend Go+Gin
jalankan Hurl sepenuhnya → buktikan perilaku identik dengan legacy

Jika Hurl semua lolos, alihkan trafik.

Mengapa tidak boleh membangun ulang dari nol

“Bukankah lebih mudah membangun ulang saja?”

Tidak. Tiga alasan:

1. Pola yang sama berulang

Drift adalah masalah struktural, bukan masalah kode. Membangun ulang tanpa ratchet akan runtuh di titik yang sama setelah 3 bulan.

2. Pengetahuan terkubur di legacy

Aturan bisnis yang terakumulasi selama 3 bulan vibe coding ada di dalam kode. Membangun ulang berarti merekonstruksi aturan-aturan ini dari ingatan. Dan ingatan bisa salah.

3. Mungkin sudah ada pelanggan

Ada momen ketika prototipe menjadi produksi. Jika sudah ada 1 pengguna saja, “membangun ulang” berarti migrasi data, konversi autentikasi, dan downtime.

Belajar menyelamatkan lebih berharga daripada belajar membangun ulang. Karena kode legacy selalu ada, dan kode baru pun menjadi legacy dalam 6 bulan.

Hubungan antara yang kamu pelajari di Kelas 1-10 dan Kelas 11

Alat yang sama, arah berlawanan. Jika Kelas 1-10 adalah “dari atas ke bawah” (deklarasi → generasi), Kelas 11 adalah “dari bawah ke atas” (kode yang ada → ekstraksi → deklarasi).

codistill mengotomatisasi “dari bawah ke atas” ini. Memeras SSOT dari kode yang ada.

Dari korban menjadi penyelamat

Setelah menyelesaikan proses ini, kamu memiliki dua kemampuan:

1. Cara membangun dari awal (Kelas 1-10) — deklarasikan, validasi, kunci, pertahankan
2. Cara menyelamatkan yang gagal (Kelas 11) — diagnosis, kunci, perbaiki, ekstrak, konversi

Sebagian besar kode di dunia adalah legacy. Proyek yang dibangun dari awal itu langka. Kemampuan menyelamatkan lebih sering digunakan.

Vibe coding belum berakhir. Kamu telah belajar cara memegang kendalinya.

Artikel terkait

• Supabase adalah jebakan vibe coding — Latar belakang teoritis Kelas 11. Mengapa BaaS bisa runtuh?
• Hurl mencegah drift vibe coding — Detail langkah penguncian di Tahap 2.
• codistill — memeras SSOT dari kode yang ada — Alat diagnosis di Tahap 1 dan ekstraksi di Tahap 4.
• huma — ratchet yang tidak melewatkan satu endpoint pun — Alat penguncian di Tahap 2.
• yongol — lunas SaaS coding AI — Alat konversi di Tahap 5. Menghasilkan fullstack dari SSOT.
• Codebase yang bisa dioperasikan agen — Prinsip mengubah kotak hitam menjadi pabrik.
• tsma — garis pertahanan regresi untuk kode legacy — Cara memperbaiki dengan ratchet terkunci.
• Membangun sistem yang bisa dioperasikan agen — Cara membuat legacy yang terkunci bisa dijangkau agen.

Semua kelas Reins Engineering

Sumber

• Feathers, M. (2004). Working Effectively with Legacy Code. Prentice Hall. — Characterization testing의 원전. 레거시 코드에 테스트를 감싸서 현재 동작을 잠그는 기법. 11강 2단계의 이론적 기초.
• CVE-2025-48757 (2025). Lovable 생성 앱 170+ RLS 누락으로 Supabase DB 노출. ameeba.com
• OG William (2026). “Moltbook Hack: Supabase Vibe Coding.” 1.5M API 토큰 노출. blog.ogwilliam.com
• Cursino, D. et al. (2026). “Speed at the Cost of Quality? The Impact of AI Coding on Software.” MSR 2026. arxiv.org/abs/2511.04427 — Cursor 도입 후 코드 복잡도 41.6% 영구 증가. 바이브 코딩이 터지는 정량적 근거.
• Liu, Z. et al. (2026). “Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild.” arxiv.org/abs/2603.28592 — 6,299개 리포지토리, 302,600건 AI 커밋 분석. 미해결 기술 부채가 2025년 초 수백 건에서 2026년 2월 110,000건 이상으로 급증.
• Storey, M.-A. (2026). “From Technical Debt to Cognitive and Intent Debt.” arxiv.org/abs/2603.22106 — 드리프트의 근본 원인을 “인지 부채”(공유 이해 침식)와 “의도 부채”(근거의 미외부화)로 이론화.
• Nguyen, H. et al. (2025). “Vibe Coding in Practice: Flow, Technical Debt, and Guidelines for Sustainable Use.” arxiv.org/abs/2512.11922 — 바이브 코딩의 flow-debt 트레이드오프를 문서화한 최초의 학술 논문.
• Cloud Security Alliance (2026). “Vibe Coding Security Crisis: Credential Sprawl and SDLC Debt.” labs.cloudsecurityalliance.org — AI 생성 코드의 45%가 OWASP Top 10 취약점 포함. AI 커밋의 시크릿 노출률 2배.
• GitClear (2025). “AI Copilot Code Quality 2025.” gitclear.com — 2.11억 라인 분석. 코드 중복 4배 증가, 리팩토링 비율 25% → 10% 감소.
• Encore (2026). “Backend as a Service (BaaS) in 2026: Providers, Tradeoffs, and Migration Paths.” encore.dev — BaaS 이탈은 포팅이 아니라 백엔드 재작성.