Jangan ubah pola prompt untuk iterasi kecil yang aman

Mengapa perubahan kecil sering merusak bagian 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.

Apa itu pola prompt “jangan ubah”

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:

• Alur (perjalanan pengguna): langkah yang pengguna ambil dan layar yang muncul.
• Detail UI dan UX: tata letak, jarak, urutan field, penempatan tombol, dan interaksi.
• Aturan bisnis dan perilaku data: aturan validasi, perhitungan harga, izin, penulisan database, dan respon API.

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.

Template dasar yang bisa Anda gunakan ulang

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.

Cara membekukan alur kritis tanpa menjadi kabur

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:

• Alur yang dibekukan: Login, Signup, Checkout, Settings (tidak ada langkah baru, tidak ada pengurutan ulang layar)
• Kasus tepi yang dibekukan: hasil tombol kembali, pesan kesalahan, keadaan kosong, perilaku refresh
• Perilaku data yang dibekukan: apa yang disimpan, kapan disimpan, dan di mana muncul setelah reload
• Keamanan yang dibekukan: izin, pemeriksaan otentikasi, rate limits, tidak ada endpoint publik baru
• Performa yang dibekukan: tidak ada panggilan API ekstra dalam alur ini, waktu respons tidak lebih buruk dari saat ini

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.

Cara membekukan detail UI dan UX

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:

• Tetap identik: rute/layar, urutan navigasi, dan perilaku tombol kembali
• Tetap identik: grid layout, spasi, font, warna, dan status komponen
• Tetap identik: semua teks dan label kecuali: <the one string>
• Aturan mobile: tetapkan perilaku saat ini pada <breakpoints>, jangan reflow bagian lain
• Output: jelaskan setiap perubahan UI yang Anda buat, dan daftar file/komponen yang disentuh

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.

Cara membekukan aturan bisnis dan perilaku data

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.

Jelaskan aturan yang tidak boleh berubah

Daripada “pertahankan harga sama,” perjelas:

• Harga: formula tepat, pembulatan (naik/turun), mata uang, perlakuan pajak/VAT, dan kapan diskon berlaku
• Izin: peran mana yang bisa membuat, mengedit, menghapus, menyetujui, mengembalikan uang, mengekspor, atau melihat field sensitif
• Status: status yang diperbolehkan dan transisi valid (dan apa yang memicunya)
• Perhitungan: total, komisi, kredit, batas, dan batasan minimum atau maksimum
• Penulisan data: tabel/record apa yang dibuat atau diperbarui, dan apa yang harus tetap tidak dapat diubah

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).

Langkah demi langkah: membuat permintaan perubahan yang aman

Perlakukan pembaruan kecil seperti kontrak mini. Pola ini bekerja paling baik saat perubahan sempit dan semuanya lain dibekukan secara eksplisit.

1. Tulis perubahan sebagai satu kalimat yang dapat diuji. “Di halaman pengaturan, tambahkan toggle untuk mengaktifkan dark mode” dapat diuji. “Perbaiki UI pengaturan” tidak.

2. 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.

3. 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.

4. 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.

5. 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:

• Hanya perilaku yang diminta berubah
• Alur dan layar yang dibekukan masih sesuai
• Aturan bisnis dan penulisan data tidak berubah
• Tes (atau langkah manual) lulus seperti tertulis
• Tidak ada commit “pembersihan” yang ikut terbawa

Ini bekerja sangat baik di Koder.ai: tempel daftar pembekuan ke Planning Mode, minta asisten mengulang batasan, lalu hasilkan patch terkecil.

Kesalahan umum yang masih menyebabkan drift

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:

• Bersikap abstrak: Anda melindungi niat, bukan alur klik demi klik dan hasil yang diharapkan.
• Melewatkan kasus tepi: keadaan kosong, loading, kesalahan validasi, izin ditolak, perilaku offline.
• Menggabungkan perubahan: dua atau tiga tweak dalam satu permintaan membuat tradeoff lebih mungkin dan regresi lebih sulit dideteksi.
• Tidak mendefinisikan “identik”: tata letak UI yang sama, panggilan API yang sama, penulisan database yang sama, email/notification yang sama, event analytics yang sama.
• Menyetujui berdasarkan kesan: “terlihat baik” tanpa memverifikasi jalur kunci.

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:

• Jalankan alur utama end-to-end (yang Anda bekukan).
• Picu setidaknya satu keadaan error dan satu keadaan kosong.
• Periksa izin (admin vs pengguna biasa) jika relevan.
• Konfirmasi efek samping: record dibuat/diperbarui, notifikasi terkirim, dan log/metric tidak berubah.

Jika ada yang berbeda, berarti permintaan kekurangan detail pembekuan, bukan “kode buruk.”

Contoh: sentuhan UI kecil tanpa mengubah workflow

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:

• Pembekuan alur: submit masih membuat akun, menampilkan pesan validasi yang sama, dan mengarahkan pengguna ke layar berikutnya yang sama.
• Pembekuan UI: tata letak halaman, spasi, warna, dan posisi tombol tetap sama.
• Pembekuan data: kunci payload backend dan tipe tidak berubah; nilai company size yang tersimpan tetap dalam format yang sama.
• Pembekuan aturan bisnis: field yang wajib tetap wajib, dan tombol tetap nonaktif sampai form valid.
• Pembekuan analytics: event tracking yang sama dipicu pada submit dan error validasi.

Acceptance checks yang bisa Anda jalankan dalam beberapa menit:

• Teks tombol menampilkan “Continue” di semua keadaan (default, loading, disabled).
• Company size adalah dropdown dengan default yang sama seperti sebelumnya.
• Submit masih mengarahkan ke dashboard dan akun dibuat.
• Pengguna lama yang mengedit profil masih melihat company size yang tersimpan dengan benar.
• Tidak ada peringatan baru atau tes yang gagal di area signup.

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).

Daftar cepat sebelum Anda menyetujui update

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.

5 cek cepat (10 menit)

Jalankan cek ini dengan urutan yang sama setiap kali. Ini menjaga review tetap tenang dan membuat regresi lebih mudah dideteksi.

• Alur kritis masih selesai end-to-end: Mulai dari titik masuk yang sama yang digunakan pengguna nyata (login, landing page, dashboard) dan selesaikan tugas utama.
• UI identik kecuali perubahan yang dimaksud: Buka layar kunci yang Anda bekukan. Periksa tata letak, label tombol, spasi, dan navigasi.
• Aturan bisnis masih sesuai kenyataan: Spot-check 2–3 kasus yang sering rusak, seperti perhitungan diskon, izin peran, atau transisi status.
• Bentuk data tidak berubah: Pastikan tidak ada field baru, field yang diganti nama, field dihapus, atau migrasi.
• Integrasi tidak disentuh: Pastikan tidak ada perubahan endpoint dan tidak ada perubahan payload (nama field, field wajib, kode status).

Kapan membatalkan dan mengajukan ulang prompt

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.

Langkah selanjutnya: terapkan di Koder.ai untuk iterasi yang lebih aman

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.

Mulai dengan planning pass singkat

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.”

Lindungi setiap iterasi dengan snapshot

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:

• Buat snapshot: “Before - change button label only”
• Jalankan planning pass dan konfirmasi daftar pembekuan
• Minta satu perubahan dan minta ringkasan bergaya diff singkat apa yang berubah
• Verifikasi dengan checklist (UI, alur, aturan, data)
• Buat snapshot: “After - verified”

Gunakan pola yang sama di seluruh stack

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.