11 Des 2025·7 menit
Jangan ubah pola prompt untuk iterasi kecil yang aman
Pelajari pola prompt 'jangan ubah' untuk membuat satu pembaruan kecil sambil membekukan alur UI utama, aturan bisnis, dan perilaku kritis agar tidak terjadi perubahan lain.
Pelajari pola prompt 'jangan ubah' untuk membuat satu pembaruan kecil sambil membekukan alur UI utama, aturan bisnis, dan perilaku kritis agar tidak terjadi perubahan lain.
Perubahan “kecil” jarang tetap kecil. Anda meminta mengubah satu label tombol, dan tiba-tiba tata letak halaman bergeser, sebuah formulir berhenti memvalidasi, atau sebuah langkah checkout berperilaku berbeda. Aplikasi adalah sistem yang saling terhubung. UI, logika, data, dan integrasi saling bergantung.
Penyebab umum adalah batasan yang tidak jelas. Jika sebuah permintaan mengatakan “buat pendaftaran lebih sederhana,” pembuat (manusia atau AI) harus menebak apa arti “lebih sederhana.” Menebak menghasilkan edit tambahan: menghapus field, mengubah langkah, menyesuaikan salinan, atau menulis ulang validasi. Penyebab lain adalah dependensi tersembunyi. Perubahan UI kecil bisa menggunakan kembali komponen yang muncul di lima layar lain.
Iterasi yang aman berarti Anda mendapatkan satu perbaikan yang dimaksud sementara semuanya yang lain tetap secara efektif identik. Untuk tim non-teknis, itu berarti alur kerja masih terasa sama bagi pengguna, skrip dukungan masih cocok dengan produk, dan pelaporan masih masuk akal. Untuk tim teknis, itu berarti tidak ada perubahan tak terduga pada rute, bentuk data, kontrak API, atau perilaku pada kasus tepi.
Untuk membuat itu mungkin, Anda harus membekukan apa yang tidak boleh berpindah. Dalam praktiknya, itu biasanya mencakup alur kritis (langkah tepat yang diambil pengguna), detail UI dan UX (tata letak, jarak, perilaku interaksi), aturan bisnis (harga, izin, validasi), perilaku data (apa yang disimpan dan kapan), dan integrasi (event analytics, email, pembayaran, API eksternal).
Pola prompt “jangan ubah” ini mengurangi risiko dengan menghilangkan asumsi dan menjaga lingkup perubahan. Ini bukan jaminan. Anda masih bisa mendapat drift jika perilaku asli kurang terdefinisi, jika perubahan menyentuh komponen bersama, atau jika Anda tidak memverifikasi hasilnya. Tujuannya adalah lebih sedikit kejutan dan persetujuan yang lebih cepat.
Pola prompt “jangan ubah” adalah cara sederhana untuk meminta satu pembaruan spesifik sambil jelas mengunci segala sesuatu yang lain. Anda menyebutkan satu perubahan yang Anda inginkan, lalu menulis daftar pembekuan singkat dari bagian-bagian yang harus tetap identik setelah pembaruan.
Ini penting karena model sering mencoba membantu dengan merombak, mengganti nama, mengatur ulang file, atau “membersihkan” logika saat menyentuh kode. Bahkan jika keluaran masih bekerja, perubahan tambahan itu dapat memperkenalkan bug, mengubah perilaku, atau membuat review lebih sulit.
Bandingkan dua permintaan ini:
“Buat halaman pengaturan lebih baik.” Ini mengundang perubahan desain, salinan baru, pergeseran tata letak, dan penyesuaian logika.
“Ubah hanya teks label dari ‘Phone’ menjadi ‘Mobile phone’. Jangan ubah tata letak, validasi, atau perilaku simpan.” Ini sempit, dapat diuji, dan lebih aman.
Daftar pembekuan yang solid biasanya mencakup tiga area:
Saat Anda memakai pola ini di alat build berbasis chat seperti Koder.ai, iterasi cenderung bergerak lebih cepat karena model fokus pada satu edit alih-alih melakukan “perbaikan” luas yang tidak Anda minta.
Pola ini bekerja paling baik ketika permintaan Anda dibaca seperti kontrak kecil: satu tujuan jelas, daftar pembekuan, dan beberapa pemeriksaan untuk mengonfirmasi hasil.
Salin template ini dan isi bagian dalam kurung. Jaga singkat, tapi spesifik.
Goal (one sentence):
- Change: [describe the one small change you want]
Context (1-3 sentences):
- Current behavior: [what happens today]
- Desired behavior: [what should happen after]
DO NOT CHANGE (must remain identical):
- Critical flows: [e.g., sign up -\u003e checkout -\u003e receipt stays the same]
- UI/UX that must not move: [e.g., button location, labels, navigation order]
- Business rules: [e.g., pricing, permissions, validation rules]
- Data behavior: [e.g., database schema, stored fields, migration rules]
Constraints (limit drift):
- Scope: [only this screen / only this endpoint / only this component]
- Files/modules (if known): [list a couple, or say “only touch what’s necessary”]
- No refactors: do not rename, reorganize folders, or change formatting beyond the touched lines
Acceptance checks (how I will verify):
1) [a simple before/after check]
2) [a user path that must still work]
3) [a rule that must still hold]
Output requested:
- Provide a brief diff-style summary: what changed, where, and why
- Call out any risk or unclear requirement before implementing
Contoh konkret: jika Anda ingin mengubah warna tombol checkout, tujuan Anda adalah “Perbarui warna tombol checkout utama menjadi #1A73E8.” Item DO NOT CHANGE Anda harus membekukan seluruh alur checkout, teks tombol, dan perhitungan harga.
Jika Anda menggunakan Koder.ai, format ini juga mempercepat review karena Anda bisa membandingkan acceptance checks dengan preview dan ringkasan perubahan sebelum menyetujui apapun.
Saat Anda meminta perubahan kecil, jangan hanya mengatakan “jangan rusak apa pun.” Sebutkan perjalanan pengguna yang tepat yang harus berperilaku sama, dari klik pertama hingga hasil akhir. Anda tidak membekukan seluruh aplikasi—Anda membekukan bagian yang jika berubah akan merugikan.
Mulailah dengan mencantumkan alur kritis dalam bahasa biasa: login (termasuk reset kata sandi), onboarding, checkout, pengaturan. Untuk setiap alur, nyatakan seperti apa “selesai”. Contoh: “Pengguna dapat login dengan email + kata sandi, tiba di Dashboard, dan tetap masuk setelah refresh.”
Lalu kunci kasus tepi yang sering terlupakan. Perilaku tombol kembali adalah sumber drift klasik: “Kembali dari Checkout kembali ke Cart (bukan Home), dan item di keranjang tetap ada.” Sebut juga keadaan error (“kata sandi salah menunjukkan pesan yang sama”), keadaan kosong (“tidak ada proyek menunjukkan salinan layar kosong yang sama”), dan keadaan loading (“spinner muncul dalam 200ms, tidak ada lompatan tata letak”).
Jika ekspektasi performa dan keamanan penting, bekukan itu juga. Jika Anda tidak menyebutkannya, model mungkin “memperbaiki” dengan menambahkan request ekstra, logging baru, atau mengubah pemeriksaan otentikasi.
Cara singkat untuk menentukannya tanpa menulis novel:
Jelaskan aliran data dalam satu kalimat per item. Misalnya: “Alamat disimpan hanya setelah menekan Simpan, tersimpan di record profil pengguna, dan harus bertahan setelah logout/login.” Tingkat detail itu mencegah autosave tak sengaja, field baru, atau perubahan timing yang merusak pengguna nyata.
Drift UI biasanya terjadi karena model “membantu” dengan membersihkan style, spasi, atau struktur komponen. Solusinya sama seperti dengan logika bisnis: sebutkan apa yang harus tetap identik, dan sebutkan satu hal yang boleh diubah.
Kunci struktur yang terlihat. Sebut tata letak (kolom/baris, posisi header dan footer), aturan spasi (padding, gap, alignment), dan perilaku komponen (hover, disabled, loading spinner, pesan error). Jika sebuah komponen punya nuansa khusus, katakan dengan jelas: “Ukuran tombol, radius, dan warna harus tetap persis sama.”
Perilaku responsif perlu aturan eksplisit. Jika Anda tidak menyebut mobile, alat mungkin “memperbaikinya.” Nyatakan breakpoint yang Anda pedulikan dan apa yang harus terjadi di masing-masing: urutan stacking, elemen tersembunyi, bar tetap, dan ukuran target tap.
Bekukan juga kata-katanya. Katakan bahwa semua copy, label, placeholder, dan helper text harus tetap tidak berubah, kecuali satu label yang sedang Anda edit. Ini mencegah penulisan ulang diam-diam yang mengubah arti.
Prompt ringkas yang bisa Anda tempel ke permintaan perubahan:
Jika bisa, minta screenshot before/after. Jika screenshot tak tersedia, minta deskripsi “UI diff” singkat (apa yang bergerak, apa yang berubah ukuran, apa yang berubah warna) sehingga Anda bisa menyetujui dengan percaya diri.
Aturan bisnis adalah salah satu tempat termudah di mana perubahan UI kecil dapat membuat regresi diam-diam. Update label dapat tanpa sengaja mengubah perhitungan, transisi status, atau siapa yang dapat melihat sebuah record. Perlakukan aturan dan perilaku data sebagai kontrak yang dibekukan.
Mulai dengan menamai beberapa aturan yang paling berisiko jika bergeser. Tulis seperti test: input, output, dan siapa yang diperbolehkan melakukan apa.
Daripada “pertahankan harga sama,” perjelas:
Tambahkan satu contoh numerik untuk menghilangkan interpretasi. Misalnya: “Subtotal pesanan $120, diskon 10% (berlaku sebelum pajak), pajak 8.25% pada jumlah setelah diskon. Total yang diharapkan = (120 - 12) * 1.0825 = $116.91. Pembulatan ke 2 desimal hanya pada total akhir.”
Sertakan visibilitas berbasis peran, bukan hanya aksi. Contoh: “Agen dukungan dapat melihat status pesanan dan email pelanggan, tetapi tidak boleh melihat detail kartu penuh. Hanya admin yang bisa mengeluarkan pengembalian dana.”
Jika validasi penting, bekukan secara eksplisit. Sebut pemicu dan pesan yang tampil ke pengguna: “Jika tanggal mulai setelah tanggal akhir, blokir simpan dan tampilkan: ‘End date must be after start date.’ Jangan ubah kata-kata ini.”
Jangan lupa efek samping di luar aplikasi. Jika Anda mengirim email, webhook, atau memanggil API pihak ketiga, bekukan apa yang harus tetap sama: nama event, field payload, timing (segera vs tertunda), dan perilaku idempoten (tidak mengirim duplikat saat retry).
Perlakukan pembaruan kecil seperti kontrak mini. Pola ini bekerja paling baik saat perubahan sempit dan semuanya lain dibekukan secara eksplisit.
Tulis perubahan sebagai satu kalimat yang dapat diuji. “Di halaman pengaturan, tambahkan toggle untuk mengaktifkan dark mode” dapat diuji. “Perbaiki UI pengaturan” tidak.
Tulis daftar pembekuan untuk bagian yang akan merugikan jika bergeser: alur pengguna, elemen UI utama, aturan bisnis, perilaku data, dan API atau tabel DB yang harus tetap sama.
Tambahkan acceptance checks plus rencana tes singkat. Di sinilah Anda mencegah “berfungsi di sisi saya” kejutan. Sertakan cek seperti: toggle baru muncul, pengaturan yang ada masih tersimpan, dan tidak ada bagian lain di halaman yang bergerak.
Sebelum menyunting, minta asisten mengulang batasan Anda kembali. Buat ia mengonfirmasi apa yang akan diubah dan apa yang harus tetap identik. Jika ringkasan tidak sesuai, perbaiki prompt sebelum mengizinkan perubahan.
Minta implementasi sekecil mungkin: tidak ada refactor, tidak ada penggantian nama, tidak ada format ulang, tidak ada upgrade dependency. Anda membeli satu perubahan, bukan makeover.
Daftar pemeriksaan tinjauan singkat:
Ini bekerja sangat baik di Koder.ai: tempel daftar pembekuan ke Planning Mode, minta asisten mengulang batasan, lalu hasilkan patch terkecil.
Sebagian besar edit “kecil” gagal karena alasan yang sama: permintaan melindungi tujuan, tetapi tidak perilaku. Model bisa mencapai tujuan Anda dengan cara baru yang diam-diam mengubah layar, logika, atau data.
Salah satu jebakan umum adalah membekukan hasil (“buat onboarding lebih mulus”) daripada langkah demi langkah yang diambil pengguna. Lainnya adalah menulis “pertahankan semuanya tetap sama” dan mengasumsikan sistem tahu maksud Anda.
Kesalahan yang paling sering menyebabkan drift:
Contoh kecil: Anda meminta “buat tombol lebih terlihat” dan membekukan warna, tapi lupa membekukan status disabled. Update mungkin selalu mengaktifkan tombol, mengubah perilaku secara tak terduga yang baru Anda sadari nanti.
Yang membantu adalah menjadi spesifik tentang apa yang tidak boleh bergerak. Sebelum menerima update, lakukan pemeriksaan regresi cepat:
Jika ada yang berbeda, berarti permintaan kekurangan detail pembekuan, bukan “kode buruk.”
Iterasi aman yang umum adalah polesan UI kecil di mana workflow tidak boleh berubah.
Skenario: seorang pendiri punya layar signup sederhana dengan form singkat (Name, Email, Company size) dan tombol utama yang mengirimkan form lalu mengarahkan pengguna ke dashboard.
Permintaan perubahan yang tepat (satu kalimat): “Ganti nama tombol utama dari 'Create account' menjadi 'Continue' dan ubah field 'Company size' dari input teks bebas menjadi dropdown.”
Terapkan pola dengan membekukan apa yang tidak boleh berubah:
Acceptance checks yang bisa Anda jalankan dalam beberapa menit:
Asisten yang baik harus mengulang item yang dibekukan, mengonfirmasi ambiguitas (misal: opsi dropdown tepatnya apa dan nilai apa yang disimpan), lalu hanya melakukan perubahan UI/kode minimal yang diperlukan. Ia juga harus menyebutkan apa yang sengaja tidak disentuh (routing, logika validasi, bentuk payload).
Sebelum menerima “perubahan kecil,” lakukan pemeriksaan cepat yang mencari drift diam-diam. Tujuannya bukan QA penuh. Tujuannya memastikan aplikasi tetap berperilaku sama di semua tempat yang Anda tulis “jangan ubah,” kecuali satu edit yang dimaksud.
Jalankan cek ini dengan urutan yang sama setiap kali. Ini menjaga review tetap tenang dan membuat regresi lebih mudah dideteksi.
Batalkan jika ada item yang dibekukan berubah, meskipun aplikasi “masih bekerja.” Label berubah, field baru, atau aturan sedikit beda adalah tanda model mengambil kebebasan ekstra.
Ajukan ulang permintaan dengan batasan lebih ketat: ulangi satu perubahan dalam satu kalimat, list alur dan layar yang dibekukan dengan nama, dan tambahkan “tidak ada perubahan skema, tidak ada perubahan endpoint, tidak ada perubahan perilaku di luar X.” Jika Anda menggunakan Koder.ai, membuat snapshot sebelum menguji membuat rollback menjadi langkah tunggal jika ada yang bergeser.
Jika Anda membangun di Koder.ai, pola prompt “jangan ubah” bekerja paling baik jika menjadi kebiasaan: satu perubahan kecil, semuanya lain terkunci, dan ada cara jelas kembali jika ada drift.
Sebelum meminta perubahan, beralih ke Planning Mode dan minta asisten merangkum ruang lingkup Anda dalam kata-kata sederhana. Minta ia mengulang dua hal: (1) perubahan tepatnya, dan (2) daftar pembekuan jelas (alur, detail UI, dan aturan bisnis yang tidak boleh berubah).
Prompt planning yang bekerja baik: “Ulangi permintaan saya. Lalu sebutkan apa yang tidak boleh berubah. Jika ada yang tidak jelas, tanyakan sebelum mengedit.”
Perlakukan setiap permintaan perubahan seperti checkpoint. Buat snapshot sebelum menerapkan update, lalu snapshot lagi setelah Anda memverifikasinya. Jika sesuatu rusak, rollback lebih cepat daripada mencoba menambal perubahan buruk.
Contoh alur sederhana:
Koder.ai dapat menghasilkan web (React), backend (Go + PostgreSQL), dan mobile (Flutter). Polanya tetap sama meskipun kodenya berbeda. Bekukan bagian yang mendefinisikan perilaku, bukan hanya file.
Jika Anda mengubah endpoint backend, bekukan bentuk request/response, aturan validasi, dan penulisan data. Jika mengubah layar mobile, bekukan urutan navigasi, default field, dan pesan error. Jika mengubah logika database, bekukan arti row yang ada dan jaga migrasi aman.
Salin template Anda, lakukan satu perubahan kecil hari ini, dan verifikasi dengan checklist sebelum menerima update. Simpan teks template dan gunakan lagi untuk permintaan perubahan berikutnya, satu per satu.
Gunakan kapan pun Anda menginginkan satu perubahan spesifik dan Anda peduli agar semuanya yang lain tetap sama. Ini sangat berguna untuk checkout, otentikasi, penagihan, atau alur lain di mana drift kecil bisa menyebabkan masalah pengguna nyata.
Karena bagian-bagian aplikasi berbagi komponen, data, dan aturan. Suntingan UI kecil bisa menggunakan kembali komponen yang sama, yang menggeser tata letak di tempat lain, mengubah validasi, atau merubah payload API tanpa Anda sadari sampai nanti.
Tulis satu tujuan yang jelas, lalu daftar apa yang harus tetap identik setelah perubahan. Intinya adalah membekukan perilaku (alur, aturan, data, integrasi) dan detail UI yang terlihat, bukan hanya mengatakan “jangan rusak apapun.”
Singkat tapi spesifik: alur kritis, detail UI/UX yang tidak boleh berubah, perilaku data, dan integrasi. Jika Anda tidak bisa menyebutkan apa yang harus tetap sama, model harus menebak, dan penebakan menyebabkan drift.
Batasi ke area terkecil yang masih melindungi Anda. Misalnya, bekukan alur checkout dan komponen bersamaannya, tapi jangan bekukan seluruh aplikasi jika Anda hanya mengubah label di satu layar.
Sebutkan perjalanan langkah demi langkah dan definisikan apa yang dimaksud dengan “selesai”. Tambahkan kasus tepi umum seperti perilaku tombol kembali, pesan kesalahan, keadaan kosong, dan perilaku refresh sehingga alurnya tetap identik di bagian yang paling dirasakan pengguna.
Bekukan struktur yang terlihat: tata letak, spasi, status komponen (hover/disabled/loading), dan semua teks kecuali satu string yang Anda ubah. Tanpa itu, model mungkin “membersihkan” gaya atau menulis ulang teks yang mengubah arti atau tata letak.
Bekukan kontrak: bentuk request/response, aturan validasi, izin, perhitungan, dan apa yang disimpan serta kapan. Tambahkan satu contoh numerik untuk aturan sensitif seperti harga agar tidak ada tafsiran selama implementasi.
Minta cek penerimaan yang bisa Anda jalankan cepat, plus ringkasan bergaya diff tentang apa yang berubah dan di mana. Kemudian verifikasi alur yang dibekukan secara end-to-end, picu setidaknya satu keadaan kesalahan, dan konfirmasi data/integrasi tidak berubah.
Buat snapshot sebelum perubahan, jalankan planning pass yang mengulangi ruang lingkup dan daftar pembekuan, lalu terapkan patch terkecil. Setelah diverifikasi, snapshot lagi sehingga rollback menjadi satu langkah jika terjadi drift.