Jawaban langsung: Hentikan fitur berikutnya. Catat 1 perilaku yang rusak, lalu tulis 1 uji yang gagal pada perilaku itu. Periksa 5 jejak: perintah uji, lebar diff, skema basis data, rahasia di kode, dan pemulihan cadangan. Pilih rescue bila fondasi masih dapat ditambah uji. Pilih rebuild bagian inti bila setiap tambalan merusak jalur lain.
Kondisi utama: Pemeriksaan ini untuk aplikasi yang sudah dipakai orang, lalu rusak setiap ada perubahan. Batas: Daftar ini tidak membuktikan aplikasi aman. Daftar ini juga tidak mengganti pentest. Angka harga di bawah adalah katalog Rama Digital pada 6 Oktober 2026, bukan survei pasar.
Asal bahan: Rama Digital membaca Fowler, OWASP, laporan DORA 2024, dan kutipan Karpathy pada 6 Oktober 2026. Diagram adalah usulan pemeriksaan. Contoh toko adalah simulasi data dummy. Kami tidak menguji aplikasi pelanggan untuk artikel ini.
Kenapa tambah fitur merusak yang kemarin jalan?
Anda minta kolom diskon. Besok, ongkir yang kemarin benar ikut hilang. Login yang kemarin masuk ikut gagal. Pola itu berulang karena tidak ada yang menghentikan perubahan saat perilaku lama pecah.
Andrej Karpathy menulis pada 2 Februari 2025 bahwa ia menerima semua diff tanpa membacanya, dan kode tumbuh melewati pemahamannya. Simon Willison mengutip tulisan itu pada 6 Februari 2025. Karpathy membatasi catatan itu pada proyek akhir pekan yang boleh dibuang. Aplikasi yang sudah memegang pesanan bukan proyek akhir pekan.
Martin Fowler, 1 Mei 2014, menulis sikap ini: anggap kode yang tidak sepele dan tidak punya uji sebagai kode yang rusak. Uji otomatis bekerja sebagai detektor. Detektor berbunyi saat seseorang memasukkan cacat. Tanpa detektor, tim baru tahu setelah pelanggan memakai jalur itu.
Fowler juga menulis spiral yang mengikuti rasa takut mengubah kode. Perbaikan kecil terasa berbahaya. Tim menunda rapikan struktur. Setiap perubahan berikut membuat perubahan selanjutnya lebih ditakuti. Uji yang lulus memutus spiral itu, karena kesalahan terlihat di perubahan terakhir.
Laporan DORA 2024 mengaitkan kenaikan adopsi AI sebesar 25% dengan perkiraan penurunan stabilitas 7,2%, pada lebih dari 39.000 responden. Angka itu bukan bukti bahwa AI menyebabkan setiap kerusakan Anda. Angka itu menunjukkan stabilitas tidak ikut naik hanya karena penulisan kode menjadi lebih cepat. Uraian angka yang sama ada di chaos engineering untuk vibe coder.
Sebelum fitur pertama, pakai alur Spec, Task, lalu Checklist. Artikel ini mulai setelah aplikasi sudah rusak berulang.
Apa yang bergerak saat 1 fitur ditambahkan?
Detektor tidak berbunyi
Fowler memisahkan uji yang ada dari cara uji itu ditulis. Uji sesudah kode tetap menghitung sebagai self-testing code. Syaratnya: pekerjaan belum selesai sebelum uji itu ada dan lulus. Reaksi tim yang memakai pola ini pada bug produksi: tulis uji yang memunculkan bug itu dahulu, baru perbaiki kodenya.
Artikel RED dalam TDD menunjukkan urutan yang sama pada 1 perilaku. RED yang berguna adalah uji yang gagal karena perilaku belum benar. Uji yang gagal karena perintah rusak belum memeriksa perilaku.
Jejak perubahan tidak dapat diulang
Skema yang diubah langsung di basis data live tidak punya berkas untuk lingkungan lain. Server kedua, laptop baru, atau pemulihan cadangan akan memakai bentuk data yang berbeda. Rekomendasi Rama Digital: simpan setiap perubahan tabel sebagai berkas migrasi yang dapat dijalankan ulang dari kosong.
Rahasia ikut tersimpan di repo
Lembar OWASP Secrets Management menyatakan banyak organisasi menaruh kredensial di kode sumber dalam teks polos. Lembar itu juga menyatakan rahasia tidak boleh ditanam di kode. Hapus baris itu dari commit terakhir belum menghapus riwayat git. Perlakukan kunci yang pernah masuk repo sebagai kunci yang bocor. Rotasi kunci itu, lalu simpan penggantinya di luar repo.
Lima gejala yang dapat Anda catat hari ini
Tabel ini adalah kerangka Rama Digital. Isi kolom bukti dari repo Anda. Jangan mengisi angka yang tidak Anda jalankan.
| Gejala | Perintah atau tempat | Bukti yang disimpan | Arti bila gejala ada |
|---|---|---|---|
| Tidak ada uji otomatis | Perintah uji di terminal. | Keluar lulus, gagal, atau perintah tidak ada. | Perubahan baru tidak punya detektor. |
| Diff melebar | Commit fitur terakhir. | Daftar berkas di luar permintaan. | Satu tugas mengubah bagian yang tidak diminta. |
| Skema menyimpang | Basis data live dan folder migrasi. | Nama tabel yang hanya ada di live. | Lingkungan lain tidak dapat mengulang bentuk data. |
| Rahasia di kode | Isi repo dan riwayat git. | Path temuan. Rotasi kunci setelahnya. | Kunci itu harus dianggap bocor. |
| Cadangan belum dipulihkan | Salinan, bukan produksi. | Waktu pulih dan cek 1 baris. | Jadwal cadangan belum terbukti. |
Siapkan ini sebelum pemeriksaan
- Akses baca ke repo dan ke 1 salinan basis data. Jangan memakai produksi untuk uji pulih.
- 1 identitas uji, bukan akun pelanggan.
- Nama pemilik yang boleh merotasi kunci.
- Perintah uji yang tim pakai, atau catatan tertulis bahwa perintah itu tidak ada.
- 1 commit fitur terakhir yang boleh Anda baca.
Langkah 1: Catat kerusakan terakhir
Buka riwayat git pada commit yang menambah fitur terakhir. Tulis 1 kalimat perilaku yang hilang, dengan data dummy bila pesan aslinya memuat nama pelanggan. Contoh kalimat: total checkout tidak lagi memuat ongkir setelah kolom diskon ditambah.
Verifikasi: kalimat itu menyebut jalur, masukan, dan hasil yang salah. Kalimat "aplikasinya rusak" belum dapat dijadikan uji. Simpan kalimat itu di tiket yang sama dengan commit.
Minta model menulis uji untuk kalimat itu. Baca diff uji sebelum Anda menerimanya. Catatan Karpathy menunjukkan risiko menerima diff tanpa baca. Di aplikasi yang sudah live, baca diff adalah bagian pemeriksaan, bukan langkah opsional.
Langkah 2: Jalankan 5 pemeriksaan dan simpan buktinya
Jalankan perintah uji di terminal. Catat kode keluar. Buka commit fitur terakhir dan tulis berkas yang tidak disebut di permintaan. Bandingkan tabel di salinan basis data dengan folder migrasi. Cari pola kunci pada repo. Pulihkan cadangan ke salinan, lalu baca 1 baris yang Anda kenali dari data dummy.
Verifikasi: tiap baris punya 1 bukti tersimpan. Temuan rahasia tidak boleh menempel di tiket publik. Simpan path di catatan pribadi, rotasi kunci, lalu tulis hanya status "kunci dirotasi" pada tiket.
OWASP memakai pemindaian rahasia sebagai kontrol. Perintah cari di editor dapat menjadi langkah pertama. Pemindaian itu tidak mengganti rotasi kunci yang sudah terlanjur masuk riwayat.
Langkah 3: Pilih rescue atau rebuild bagian inti
Baca catatan 5 baris itu bersama pemilik aplikasi. Pilih rescue bila uji masih dapat ditambah, kunci dapat dirotasi, 1 pemulihan berhasil, dan biaya perbaikan tetap di bawah rebuild. Pilih rebuild bagian inti bila bentuk data tidak aman ditambal di tempat dan setiap perbaikan merusak jalur lain. Simpan data yang masih valid.
Verifikasi: keputusan tertulis menyebut kondisi yang Anda lihat, bukan umur kode. Umur repositori tidak memilih jalur. Laporan audit forensik pada layanan Vibe Code Rescue memakai aturan yang sama: rescue saat fondasi masih aman diperbaiki bagian per bagian, rebuild terarah saat biaya perbaikan melebihi membangun ulang bagian inti.
Contoh kerja: toko latihan menambah diskon
Simulasi data dummy, 6 Oktober 2026. Toko Latihan punya 12 pesanan uji. Checkout kemarin menghitung barang Rp100.000 ditambah ongkir Rp15.000, total Rp115.000. Permintaan baru: kolom diskon 10% pada barang. Draf model mengubah fungsi total. Ongkir tidak lagi dijumlahkan. Angka ini kami susun untuk latihan. Angka ini bukan keluaran 1 model tertentu.
| Waktu WIB | Masukan | Pemeriksaan | Keluaran |
|---|---|---|---|
| 09.00 | Permintaan diskon 10%. | Tulis perilaku ongkir yang harus tetap ada. | 1 kalimat uji tersimpan. |
| 09.10 | Diff menyentuh total dan sesi login. | Tolak berkas di luar permintaan. | Hanya fungsi total yang tinggal. |
| 09.20 | Uji total tanpa ongkir. | Uji gagal, sesuai RED yang diharapkan. | Perbaikan mengembalikan ongkir. |
| 09.30 | Kunci database ada di berkas contoh. | Hapus dari cabang dan rotasi kunci. | Status tiket: kunci dirotasi. |
| 09.40 | Cadangan semalam. | Pulihkan ke salinan. Baca 1 pesanan uji. | Baris Rp115.000 kembali. |
Keputusan simulasi: rescue. Uji untuk ongkir sudah ada. Diff sudah dibatasi. Kunci sudah dirotasi. Pemulihan salinan berhasil. Rebuild tidak dipilih, karena bentuk tabel pesanan masih dapat dipakai.
Ganti pesanan dengan tiket, invoice, atau jadwal bila aplikasi Anda bukan toko. Pertahankan pemisahan antara perilaku lama, berkas yang boleh berubah, dan bukti pemulihan.
Checklist pemilik aplikasi
Pakai daftar ini pada 1 fitur sebelum Anda membuka fitur lain. Setiap baris punya pemilik dan bukti.
- Pemilik produk: tulis 1 perilaku yang rusak. Simpan kalimat itu di tiket.
- Pembuat: tambah 1 uji yang gagal pada perilaku itu. Simpan keluaran RED.
- Pembuat: batasi diff pada berkas permintaan. Simpan daftar berkas yang ditolak.
- Pemilik data: samakan tabel live dengan berkas migrasi. Simpan nama tabel yang hanya ada di live.
- Pemilik keamanan: cari rahasia di repo dan riwayat. Simpan status rotasi, bukan nilai kunci.
- Pemilik operasi: pulihkan cadangan ke salinan. Simpan waktu pulih dan 1 baris yang cocok.
- Pemilik aplikasi: tulis rescue atau rebuild beserta syaratnya. Simpan keputusan di tiket yang sama.
- Pemilik aplikasi: hentikan fitur berikutnya bila uji perilaku terakhir belum ada, atau cadangan belum pernah dipulihkan. Itu syarat berhenti.
Harga katalog bila Anda tidak memeriksa sendiri
Tabel ini membandingkan 3 jalur. Harga jalur berbayar dibaca dari definisi layanan Vibe Code Rescue pada 6 Oktober 2026. Jalur mandiri tidak punya harga pada katalog.
| Jalur | Yang Anda dapat | Harga katalog | Pilih bila |
|---|---|---|---|
| Pemeriksaan mandiri | 5 bukti pada tiket Anda. | Tidak ada di katalog. | Anda dapat menjalankan uji dan pemulihan salinan. |
| Audit forensik | Laporan kondisi kode, risiko, dan alasan rescue atau rebuild. | Rp 7,5 juta. Durasi 1 sampai 2 minggu. | Anda perlu keputusan tertulis sebelum memperbaiki. |
| Rescue | Perbaikan secret, uji, cadangan, dan log pada kode yang ada. | Mulai Rp 25 juta. | Fondasi masih aman diperbaiki bagian per bagian. |
| Rebuild terarah | Bagian inti dibangun ulang. Data lama yang layak tetap dipakai. | Mulai Rp 40 juta. | Biaya tambalan melebihi membangun ulang bagian inti. |
Rekomendasi Rama Digital: jalankan Langkah 1 sampai 3 dahulu bila Anda mampu membaca repo sendiri. Minta audit forensik bila 2 gejala atau lebih masih terbuka setelah 1 hari kerja, atau bila data pelanggan sudah tersimpan di aplikasi itu.
Pertanyaan yang sering muncul
Apakah setiap aplikasi hasil AI rusak saat ditambah fitur? Tidak. Aplikasi rusak berulang bila perilaku lama tidak punya uji yang gagal saat perilaku itu hilang. Aplikasi dengan detektor itu dapat menambah fitur tanpa mengulang jalur yang sudah lulus.
Apakah uji yang ditulis sesudah kode jadi masih berguna? Ya. Fowler menyebut uji sesudah kode tetap menghasilkan self-testing code, selama pekerjaan belum dianggap selesai sebelum uji itu lulus. Tulis uji yang memunculkan kerusakan terakhir sebelum Anda mengubah fungsi lagi.
Kapan rebuild lebih sesuai daripada rescue? Pilih rebuild bagian inti bila bentuk data tidak aman ditambal di tempat dan setiap perbaikan merusak jalur lain. Pilihan itu datang dari bukti pada kode dan data, bukan dari umur proyek.
Apakah rahasia aman setelah barisnya dihapus dari kode? Tidak aman hanya dengan menghapus baris. Riwayat git masih menyimpan nilai lama. Rotasi kunci itu, lalu simpan kunci baru di luar repo. OWASP memperlakukan kredensial di kode sumber sebagai kebocoran yang harus dikendalikan.
Apakah artikel chaos engineering mengganti daftar ini? Tidak. Artikel chaos engineering merencanakan kerusakan sengaja setelah fitur berdiri. Daftar ini dipakai saat fitur biasa sudah merusak perilaku lama. Kerjakan detektor uji dahulu. Lanjut ke chaos experiment setelah suite dasar lulus.
Apakah saya harus menghentikan semua pengembangan? Hentikan fitur baru sampai uji untuk kerusakan terakhir ada dan 1 pemulihan cadangan berhasil di salinan. Perbaikan pada jalur yang rusak boleh lanjut. Itu syarat berhenti pada checklist, bukan larangan memperbaiki.
Tindakan berikutnya
Checklist ini menata bukti. Checklist ini tidak merotasi kunci untuk Anda dan tidak memulihkan data produksi. Bila 2 gejala atau lebih masih terbuka, baca Vibe Code Rescue untuk cakupan audit, rescue, dan rebuild. Untuk menetapkan ruang lingkup sebelum penawaran, jadwalkan sesi scoping teknis. Bawa tiket gejala yang sudah disamarkan. Jangan kirim nilai kunci atau data pelanggan.
Sumber
Sumber berikut dibaca pada 6 Oktober 2026. Rekomendasi, diagram, checklist, dan simulasi adalah materi editorial Rama Digital.
