Empat. Itu kira-kira titik saat sebuah build pertama kali lolos verifikasinya sendiri dan menghasilkan sesuatu yang benar-benar berjalan — halaman yang berfungsi, endpoint yang berfungsi, alur login yang benar-benar bisa memasukkan seseorang. Sebelas adalah jumlah prompt median yang terkumpul saat sebuah build dianggap selesai dan dirilis. Enam puluh delapan persen adalah porsi dari semua prompt yang dikirim setelah versi pertama yang berfungsi itu, yang tidak mengubah apa pun dari logika inti yang akan disadari pengguna. Tiga puluh adalah titik saat kebanyakan orang diam-diam berhenti, bukan karena produknya sudah selesai, tapi karena mereka kehabisan hal untuk dikatakan tentangnya.
Keempat angka itu menggambarkan pola yang sama berulang kali: build cepat menjadi fungsional, lalu menghabiskan sebagian besar sisa umurnya untuk dibicarakan, bukan dibangun ulang.
Tembok itu tidak berada di tempat yang Anda kira
Jika Anda bertanya kepada saya sebelum saya mulai memperhatikan hal ini, di mana pembangun build biasanya macet, saya akan menebak integrasi — penyedia pembayaran, callback autentikasi, API SMS yang butuh ID pengirim terverifikasi. Itu memang titik gesekan yang nyata, tapi bukan tempat jumlah prompt membengkak. Biasanya hanya butuh satu atau dua giliran tambahan lalu selesai.
Tembok itu muncul belakangan, setelah sesuatu berfungsi. Sebuah build mencapai lolos verifikasi bersih pertamanya — halaman-halaman ter-render, alur inti berjalan dari ujung ke ujung, tidak ada error yang muncul — dan alih-alih berhenti, prompt terus mengalir. "Buat headernya lebih besar." "Coba warna aksen yang berbeda." "Bisa tombolnya sedikit lebih membulat." "Sebenarnya balik saja ke versi pertama tadi." Tak satu pun dari itu menyentuh model data, rute, atau pemeriksaan izin. Semuanya hanya permukaan.
Mengapa "selesai" tidak terasa seperti titik berhenti
Sebagian dari ini hanyalah bagaimana iterasi terasa dari dalam. Saat build rusak, Anda tahu persis apa yang harus diminta — perbaiki errornya, tambahkan field yang hilang, sambungkan yang belum tersambung. Saat sudah berfungsi, target itu menghilang. Tidak ada pesan error yang memberi tahu Anda bahwa nuansa birunya salah. Kini Anda membuat keputusan berdasarkan selera tanpa kebenaran dasar, dan keputusan selera bisa direvisi tanpa batas dengan cara yang tidak dimiliki bug.
Bagian lainnya adalah karena membuat prompt itu murah dan instan, sehingga biaya "coba satu hal lagi saja" terasa mendekati nol pada saat itu, walau tidak nol secara agregat. Selusin perubahan kosmetik masing-masing beberapa menit sama dengan satu sore penuh yang sungguhan, tapi tidak ada satu prompt pun di selusin itu yang terasa cukup mahal untuk dilewati.
Apa yang sebenarnya diubah oleh prompt-prompt belakangan
| Rentang prompt | Target khas | Perubahan fungsional? |
|---|---|---|
| 1–4 | Halaman inti, model data, alur utama | Ya — di sinilah produk sesungguhnya dibangun |
| 5–7 | Kasus tepi, kondisi error, field yang hilang | Biasanya ya — celah nyata yang ditemukan saat pemakaian |
| 8–15 | Tata letak, teks, warna, spasi, nuansa | Jarang |
| 16+ | Membatalkan atau mencoba ulang pilihan kosmetik sebelumnya | Hampir tidak pernah |
Baris ketiga itulah yang layak direnungkan. Bukan berarti polesan kosmetik itu sia-sia — build yang terlihat generik akan berkinerja lebih buruk daripada yang tidak, dan tahap desain memang penting. Masalahnya, polesan itu jarang butuh delapan sampai lima belas prompt terpisah untuk mendapatkan hasil yang tepat, dan alasan kenapa butuh sebanyak itu biasanya adalah keraguan, bukan iterasi. Anda tidak sedang menuju jawaban yang lebih baik setelah prompt kesebelas; Anda hanya bolak-balik antara dua jawaban yang sudah Anda hasilkan sejak prompt kesembilan.
Saya pernah melihat seseorang menghabiskan empat puluh menit memindahkan tombol call-to-action ke tiga posisi berbeda di halaman landing, memutuskan pada prompt keempat belas bahwa posisi pertama adalah yang terbaik, lalu meminta agen build untuk mengembalikannya. Agen itu tidak melakukan kesalahan apa pun di semua giliran tersebut. Tombolnya saja yang sebenarnya tidak pernah butuh empat belas opini.
Apa yang sebenarnya diungkapkan oleh selisih dua puluh versus tiga puluh prompt
Inilah bagian yang paling mengejutkan saya: build yang berhenti sekitar prompt kesebelas dan build yang berjalan lebih dari tiga puluh tidak menghasilkan kualitas yang berbeda secara berarti. Saya mencari-cari — pasti lebih banyak iterasi berarti produk yang lebih halus — dan sebagian besar tidak menemukannya. Yang saya temukan justru: builder yang berhenti lebih awal cenderung sudah membuat keputusan selera mereka sekali saja, di awal, langsung dalam prompt ("bersih, minimalis, satu warna aksen, tanpa foto stok") alih-alih menemukan selera mereka lewat dua puluh putaran coba-coba setelahnya.
Build yang berjalan paling lama bukanlah yang paling ambisius. Itu adalah build yang prompt awalnya paling banyak meninggalkan hal yang belum diputuskan — tanpa nuansa, tanpa titik acuan, tanpa audiens yang dinyatakan — sehingga setiap celah diisi satu prompt kecil demi satu prompt kecil, alih-alih sekali saja, secara tertulis, sebelum jalankan pertama.
Kesimpulan praktisnya
Jika Anda sudah di prompt keempat atau kelima dan semuanya berjalan, itu bukan titik pemeriksaan — itu berarti sebagian besar pekerjaan sebenarnya sudah selesai. Yang tersisa memang nyata tapi kecil: periksa kasus tepi yang belum sempat dijelaskan siapa pun, cek ulang teksnya, dan lakukan satu kali penyesuaian nuansa visual yang disengaja alih-alih selusin percobaan eksploratif. Dan jika Anda sadar di prompt kedua puluh masih mengutak-atik border-radius, itu bukan tanda build belum selesai. Itu biasanya tanda bahwa prompt sebelumnya seharusnya sudah menyatakan apa yang Anda inginkan sejak awal, dan perbaikannya ada di pesan pembuka build berikutnya, bukan di prompt keempat puluh build ini.
