Kredit Lovable, Bolt, dan Cursor Cepat Habis Padahal Fitur Belum Jadi — Ini Sebabnya

Baru tanggal belasan dan kreditmu sudah habis. Halaman langganan bilang jatah berikutnya turun dua minggu lagi. Sementara itu aplikasimu masih setengah jadi: tombol simpan kadang jalan kadang enggak, halaman laporan belum ada, tampilan di HP masih berantakan.

Yang bikin kesal biasanya bukan kreditnya habis. Tapi kamu nggak tahu habisnya ke mana. Rasanya baru kemarin isi ulang, dan yang kamu ingat cuma bolak-balik nyuruh AI benerin satu error yang itu-itu juga.

Aku mau bahas ke mana perginya. Ini bukan soal Lovable, Bolt, atau Cursor yang curang, karena cara mereka menagih sebetulnya masuk akal dari sisi mereka. Yang perlu kamu tahu itu cara hitungnya. Begitu paham, kamu bakal lihat kebiasaanmu sendiri yang diam-diam bikin tagihan membengkak.

Kamu bayar per percobaan, bukan per fitur jadi

Ini yang paling sering salah dipahami. Waktu kamu bayar paket bulanan, yang kamu beli bukan "satu aplikasi jadi". Yang kamu beli itu jatah kerja mesin. Tiap kali kamu tekan enter, model membaca konteks proyekmu, mikir, lalu nulis. Hasilnya benar atau ngaco, kerjanya tetap dihitung.

Jadi kalau satu fitur butuh dua belas kali percobaan sebelum benar, kamu bayar dua belas kali untuk satu fitur. Orang lain yang bikin fitur serupa dalam tiga percobaan bayar seperempatnya. Kode akhirnya bisa mirip. Ongkosnya jauh beda.

Angka di atas disalin dari halaman resmi masing-masing pada tanggal yang tertulis: halaman harga Bolt, halaman harga Cursor, halaman harga Lovable, dan dokumentasi batas pesan Lovable. Semuanya tidak menyebut harga rupiah, jadi hitung sendiri kurs dan pajaknya waktu menyusun anggaran.

Putaran benerin yang nggak selesai-selesai

Ini penyedot terbesar, dan hampir semua orang pernah kejebak. Polanya begini. Kamu minta satu fitur. Hasilnya error. Kamu tempel pesan errornya, minta dibetulkan. AI minta maaf, ganti kode, muncul error baru. Kamu tempel lagi. Tiga jam kemudian kamu di putaran entah ke berapa, dan errornya balik ke yang pertama.

Kenapa bisa muter? Karena AI nggak benar-benar tahu apa yang salah. Dia lihat pesan error, menebak sebabnya, lalu nambal. Kalau tebakannya meleset, tambalannya bikin masalah baru di tempat lain. Tiap putaran dihitung penuh. Dan putaran-putaran belakangan justru yang paling mahal, karena percakapannya sudah panjang dan proyeknya sudah lebih berat dibaca.

Tandanya gampang dikenali. AI bilang "sekarang sudah pasti benar" tiga kali berturut-turut. Atau dia mengembalikan kode yang dua langkah lalu dia buang sendiri. Begitu kamu lihat itu, berhenti. Nambah percobaan cuma nambah tagihan, bukan nambah kemajuan.

Yang lebih murah itu mundur. Balikkan ke versi terakhir yang jalan, lalu mulai lagi dengan penjelasan yang lebih lengkap: apa yang seharusnya terjadi, apa yang benar-benar terjadi, dan data apa yang kamu pakai waktu itu. Satu penjelasan utuh sekali kirim biasanya menyelesaikan hal yang sepuluh tempelan error gagal selesaikan. Pola instruksinya aku bahas di panduan prompt untuk AI coding.

Instruksi kabur bikin AI menebak

"Bikin halaman pesanan" terdengar jelas di kepalamu. Di kepala AI, kalimat itu punya seratus versi. Kolomnya apa saja? Statusnya apa saja? Status boleh mundur nggak? Yang boleh lihat siapa? Karena kamu nggak sebut, dia pilih sendiri.

Kalau tebakannya kebetulan cocok, kamu hemat. Kalau meleset, kamu bayar dua kali: sekali buat bikin yang salah, sekali lagi buat mengubahnya jadi yang kamu mau. Dan mengubah biasanya lebih mahal daripada bikin dari nol, karena AI harus baca dulu semua yang sudah ada sebelum menyentuhnya.

// Kabur: AI harus nebak enam hal sekaligus
"bikin halaman pesanan"

// Jelas: nggak ada yang perlu ditebak
"Halaman daftar pesanan.
Kolom: nomor pesanan, nama pembeli, tanggal, total, status.
Status: baru, dibayar, dikirim, selesai, batal.
Status cuma boleh maju. Setelah dikirim, tidak bisa dibatalkan.
Total tampil format rupiah tanpa desimal.
Kalau belum ada pesanan, tampilkan tulisan 'Belum ada pesanan'."

Yang panjang itu kelihatan boros karena hurufnya banyak. Kenyataannya kebalikannya. Instruksi panjang sekali jalan hampir selalu lebih murah daripada instruksi pendek yang disusul lima kali revisi, karena tiap revisi menyeret ongkos baca proyek dari awal lagi.

Minta satu-satu padahal muat sekali jalan

Kebiasaan yang kelihatan rapi tapi diam-diam mahal: mengubah satu hal per pesan. "Tombolnya bikin biru." Kirim. "Ukurannya kegedean." Kirim. "Geser ke kanan." Kirim. Tiga pesan, tiga tagihan, padahal ketiganya soal satu tombol yang sama.

Masalahnya bukan cuma jumlah pesan. Tiap pesan, AI harus membaca ulang isi proyekmu dari awal. Bolt terang-terangan menulis di FAQ mereka bahwa sebagian besar pemakaian token habis untuk menyelaraskan berkas proyek ke AI. Artinya kamu bayar ongkos baca proyek tiga kali untuk pekerjaan yang muat dalam satu kali baca.

Kumpulkan dulu. Keliling aplikasimu sambil catat semua yang mengganjal, baru kirim sekali dalam satu pesan bernomor. Tapi jangan asal borong semuanya:

• Enak digabung: perbaikan tampilan, ganti teks, ubah warna, rapikan tata letak. Perubahan yang kalaupun salah, salahnya kelihatan langsung di layar.
• Lebih baik dipisah: apa pun yang menyentuh cara data disimpan. Kalau satu pesan mengubah tiga hal di database sekaligus dan hasilnya kacau, kamu susah tahu yang mana biang keroknya, dan kamu balik lagi ke putaran benerin.

Proyek makin besar, tiap pesan makin mahal

Ini yang bikin orang bingung: permintaan yang sama, di minggu pertama murah, di minggu keempat terasa mahal. Itu bukan perasaanmu.

Sebelum menjawab apa pun, AI harus tahu isi proyekmu. Waktu proyekmu masih beberapa berkas, membaca proyek itu murah. Waktu berkasnya sudah puluhan, tiap pesan bawa muatan yang jauh lebih berat. Tambah lagi riwayat percakapan yang ikut terbawa. Ongkos per pesan naik terus walaupun permintaanmu tetap sesederhana "ganti judulnya".

Dua kebiasaan yang menahan ini. Pertama, buka percakapan baru tiap ganti fitur, jangan satu chat raksasa dari awal proyek sampai selesai. Kedua, sebutkan bagian mana yang mau disentuh. "Benerin tampilan laporan" bikin AI keliling dulu mencari-cari. "Di halaman laporan, kolom tanggal formatnya salah" langsung mengarahkan dia ke satu tempat.

Memecah pekerjaan jadi potongan kecil yang jelas batasnya juga bikin tiap potongan lebih murah dikerjakan. Caranya ada di cara memecah fitur aplikasi jadi tugas untuk AI.

Akar keempatnya sama

Kalau empat sebab tadi ditarik ke belakang, ujungnya satu titik. Keputusan soal aplikasimu diambil di tengah jalan, satu per satu, sambil AI sudah mulai mengetik. Tiap hal yang belum kamu putuskan, dia putuskan sendiri. Tiap keputusan yang nggak cocok, kamu bayar lagi buat membatalkannya.

Orang yang kreditnya awet biasanya bukan yang lebih jago ngoding. Dia cuma sudah tahu jawabannya sebelum bertanya. Pola pemakaian yang bikin proyek non-programmer ambruk, termasuk kebiasaan satu chat panjang tadi, aku kumpulkan di 7 kesalahan non-programmer bikin aplikasi pakai AI.

Putuskan dulu, baru suruh AI mengetik

Yang perlu kamu putuskan sebelum menyuruh AI ngetik sebetulnya sedikit: siapa yang pakai aplikasinya, data apa yang disimpan dan kolomnya apa saja, alurnya bagaimana dari awal sampai selesai, aturan apa yang haram dilanggar, dan apa yang terjadi kalau ada yang tidak beres. Stok habis pas checkout, koneksi putus di tengah jalan, pengguna klik tombol simpan dua kali.

Lima kebiasaan yang paling terasa efeknya di tagihan:

1. Tulis dulu apa yang mau dibangun sebelum buka alatnya. Cukup satu halaman berisi daftar di atas, bukan dokumen tebal.
2. Kunci konvensi di berkas aturan yang otomatis dibaca tiap sesi, biar kamu berhenti mengetik ulang instruksi yang sama.
3. Satu fitur satu percakapan. Fitur baru, chat baru, kasih konteks singkat di awal.
4. Uji tiap satu fitur selesai. Menumpuk lima fitur baru lalu menemukan errornya berarti kamu harus bayar buat mencari sumbernya.
5. Kalau sudah tiga kali gagal di error yang sama, berhenti. Mundur ke versi yang jalan, tulis ulang penjelasannya dari nol, mulai bersih.

Poin kedua sering diremehkan padahal murah banget dipasang sekali. Bentuk berkasnya beda-beda per alat, dan isinya apa saja ada di panduan file rules Cursor dan CLAUDE.md.

Nulis dulu sebelum ngetik bukan berarti kamu balik ke gaya kerja lama yang berbulan-bulan bikin dokumen. Beda antara nge-prompt sambil jalan dan menentukan spesifikasi di depan aku kupas di vibe coding vs spec-driven development. Ringkasnya, satu jam yang kamu pakai buat memutuskan di depan itu jam paling murah di seluruh proyek, karena di situ belum ada kredit yang terbakar sama sekali.

Skematik dibikin untuk bagian ini. Dia nyusun keputusan-keputusan tadi jadi satu dokumen yang bisa kamu serahkan ke AI sebagai acuan, lengkap sampai ke aturan dan kasus yang gampang kelewat. Bukan supaya AI-nya jadi lebih pintar, tapi supaya dia berhenti menebak. Kredit paling banyak terbakar di tebakan yang salah, jadi di situ juga letak penghematannya.

Coba satu hal sebelum isi ulang kredit. Buka riwayat chat terakhirmu, lalu hitung: berapa pesan yang isinya membuat sesuatu yang baru, dan berapa yang isinya membetulkan sesuatu yang tadi salah dibuat. Perbandingan itu yang menentukan kreditmu bertahan sampai tanggal berapa.