Masalah 70%: Kenapa Proyek AI Mentok di Tengah

Pola ini sangat sering terjadi pada proyek yang dibangun dengan AI. Di hari-hari pertama, kemajuannya luar biasa: halaman demi halaman jadi dalam hitungan menit. Lalu, tanpa terasa, semuanya melambat. Memperbaiki satu bug memunculkan dua bug baru. AI minta maaf, mengubah sesuatu, lalu bug lama kembali. Proyek yang tadinya “hampir selesai” terasa tidak pernah selesai.

Fenomena ini sering disebut masalah 70%. Artikel ini menjelaskan kenapa itu terjadi, tanda-tanda kamu sedang mengalaminya, dan cara melewatinya.

Asal istilahnya

Istilah the 70% problem dipopulerkan oleh Addy Osmani, engineer Google, lewat esainya pada akhir 2024. Esai itu kemudian dikembangkan menjadi satu bab dalam bukunya, Beyond Vibe Coding (O’Reilly, 2025). Pengamatannya: tool AI bisa membawamu ke sekitar 70% jalan dengan sangat cepat, tapi 30% terakhir (bagian yang membuat aplikasi benar-benar siap dipakai) justru lebih lama, dan membutuhkan penilaian yang belum bisa diandalkan dari AI saja.

Perlu diingat, angka 70% di sini adalah gambaran, bukan hasil pengukuran. Di proyekmu, temboknya bisa muncul di 50% atau 90%. Yang konsisten adalah polanya: cepat di awal, mentok di akhir.

Kenapa ini terjadi

Bagian awal adalah pola yang umum. Halaman login, form, daftar, dan tabel sudah ditulis jutaan kali di internet, sehingga AI sangat mahir membuatnya. Bagian akhir berisi hal-hal yang khas proyekmu: aturan bisnis yang unik, kasus tepi, integrasi dengan layanan lain, keamanan, dan performa. Di sini AI tidak bisa lagi mengandalkan pola umum.

Kompleksitas tumbuh diam-diam. Setiap fitur baru menambah hubungan dengan fitur lama. Tanpa kebiasaan satu fitur sekali jalan, perubahan besar menumpuk, dan tidak ada yang tahu persis bagian mana bergantung pada bagian mana.

AI kehilangan gambaran besar. Makin besar proyek dan makin panjang percakapan, makin sulit bagi AI untuk memegang seluruh konteks. Ia mulai memperbaiki gejala di satu tempat sambil merusak asumsi di tempat lain.

Kamu tidak bisa membantu AI keluar. Ini penyebab yang paling menentukan. Kalau kamu tidak memahami kodenya, kamu hanya bisa berkata “masih error”. Developer yang paham bisa berkata “masalahnya di urutan penyimpanan data, periksa fungsi itu”, dan arahan seperti itu yang membuat AI keluar dari lingkaran.

Tanda-tanda kamu sudah menabrak tembok

• Bug yang sama kembali lagi setelah dinyatakan beres.
• Setiap perbaikan merusak sesuatu yang tadinya jalan.
• AI mulai berputar: mencoba solusi A, lalu B, lalu kembali ke A.
• Perubahan untuk masalah kecil makin besar, dengan banyak file tersentuh.
• Kamu mulai takut menyentuh bagian tertentu, karena tidak tahu apa yang akan rusak.
• Kamu tidak bisa lagi menjelaskan cara kerja aplikasimu sendiri.

Kalau dua atau lebih tanda ini muncul, berhenti dulu. Terus menambal sambil berharap justru membuat temboknya makin tinggi.

Cara melewatinya

1. Berhenti dan kembali ke titik aman

Jangan menumpuk perbaikan di atas kode yang sudah berantakan. Kembali ke commit terakhir yang jalan dengan git restore . (untuk perubahan yang belum di-commit), lalu mulai lagi dari sana. Kalau proyekmu belum memakai Git, ini saat yang tepat untuk mulai: Git dan GitHub untuk kerja tim.

2. Pahami masalahnya sebelum memperbaikinya

Minta diagnosis, bukan perbaikan:

Jangan ubah kode dulu. Bug-nya: [yang kamu lakukan], [yang diharapkan], [yang terjadi],
[pesan error, kalau ada].

Jelaskan 3 kemungkinan penyebab, dari yang paling mungkin. Untuk setiap kemungkinan,
sebutkan cara saya membuktikannya, misalnya dengan menambah console.log atau
menjalankan langkah tertentu.

Buktikan penyebabnya dulu, baru minta perbaikan untuk penyebab yang sudah terbukti. Cara ini jauh lebih cepat daripada lima kali mencoba perbaikan secara acak.

3. Perkecil masalahnya

Cari langkah sesingkat mungkin yang memunculkan bug itu. “Kalau saya menambah catatan lalu langsung menghapusnya, totalnya salah” jauh lebih berguna daripada “totalnya kadang salah”. Masalah yang bisa diulang dengan pasti hampir selalu bisa diperbaiki.

4. Mulai sesi baru dengan konteks yang bersih

Percakapan yang panjang penuh dengan solusi yang gagal, dan AI bisa terpengaruh olehnya. Mulai percakapan baru dengan ringkasan singkat: tujuan aplikasi, peta proyek (lihat memahami kode buatan AI), bug yang sedang dikerjakan, dan apa saja yang sudah dicoba dan gagal.

5. Pelajari konsep di balik masalahnya

Sering kali tembok itu adalah konsep yang belum kamu pahami: bagaimana data disimpan, bagaimana login bekerja, kenapa sesuatu berjalan tidak berurutan. Luangkan satu sesi untuk mempelajari konsep itu saja. Setelah paham, instruksimu ke AI jadi jauh lebih tepat. Ini juga alasan jalur belajar kami tidak berhenti di “minta AI membuatkan”.

6. Tahu kapan perlu bantuan orang

Kalau sudah mencoba semua langkah di atas dan tetap mentok, terutama untuk bagian yang menyangkut data pengguna, pembayaran, atau keamanan, itu saat yang tepat untuk meminta developer meninjaunya. Peta proyek dan daftar uji yang sudah kamu buat akan menghemat banyak waktu mereka.

Mencegah lebih baik daripada menabrak

Kebiasaan dari artikel-artikel sebelumnya di jalur ini adalah pencegahannya:

Proyek yang dibangun dengan kebiasaan ini tetap akan menemui bagian sulit, tapi kamu menemuinya satu per satu, bukan semuanya sekaligus.

Pertanyaan yang sering diajukan

Apakah tool AI yang lebih baru akan menghilangkan masalah ini?

Tool AI terus membaik, dan temboknya bisa bergeser lebih jauh. Tapi bagian terakhir dari sebuah aplikasi selalu berisi keputusan yang khas proyekmu: apa yang benar untuk penggunamu, risiko apa yang bisa diterima, dan bagaimana menangani kasus tepi. Tanggung jawab atas keputusan itu, dan atas pemahaman yang dibutuhkan untuk membuatnya, tetap ada di tanganmu.

Apakah ini berarti vibe coding tidak berguna untuk proyek serius?

Tidak. Yang berubah adalah cara memakainya. Untuk proyek serius, AI paling berguna sebagai rekan yang mempercepat pekerjaan, dengan kamu yang memegang arah, memeriksa, dan memahami hasilnya. Itulah peralihan yang dibahas sepanjang jalur ini.

Bagaimana tahu proyekku sudah benar-benar “selesai”?

Kembali ke kriteria “selesai jika” di spesifikasimu, ditambah checklist keamanan. Kalau semua kriteria terpenuhi, semua uji lulus, dan checklist keamanannya sudah diperiksa, aplikasimu siap untuk tahap berikutnya: rilis ke internet.

Kesimpulan

Masalah 70% adalah pola yang umum: AI cepat menyelesaikan bagian yang umum, lalu melambat di bagian yang khas proyekmu. Tanda-tandanya: bug yang terus kembali dan perbaikan yang merusak hal lain. Jalan keluarnya: berhenti dan kembali ke titik aman, pahami penyebabnya sebelum memperbaiki, perkecil masalahnya, mulai sesi baru yang bersih, dan pelajari konsep yang menghalangimu.

Dengan ini Level 2 jalur Vibe Coding selesai. Level berikutnya membawa aplikasimu dari prototipe menjadi produk: rilis, keamanan, biaya, dan kapan perlu developer.