Cara Mengembangkan Aplikasi Buatan AI Tanpa Merusaknya

Untuk mengembangkan aplikasi buatan AI tanpa merusaknya, ubah satu hal per prompt, periksa di pratinjau, dan simpan checkpoint sebelum melanjutkan. Jelaskan apa yang Anda lihat, bukan apa yang Anda kira ada di kode, rencanakan perubahan besar sebelum membangunnya, dan saat sebuah perubahan gagal, kembali ke versi terakhir yang baik alih-alih meminta AI memperbaiki perbaikannya sendiri.

Versi pertama aplikasi sering kali selesai dalam hitungan menit. Bagian yang sulit adalah perubahan kelima puluh, saat setiap prompt baru berisiko merusak sesuatu yang sudah berfungsi. Panduan ini adalah siklus yang mencegah hal itu terjadi.

Siklus pengembangan

1. Pilih satu perubahan. Satu fitur, satu bug, atau satu halaman.
2. Jelaskan dari sudut pandang apa yang dilihat dan dilakukan pengguna.
3. Untuk perubahan besar, rencanakan dulu. Minta rencana, baca, lalu bangun.
4. Periksa hasilnya di pratinjau: perubahan itu dan alur di sekitarnya.
5. Simpan checkpoint atau commit.
6. Ulangi.

Setiap langkah ada untuk menjaga perubahan tetap kecil dan bisa dibatalkan.

Langkah 1: Simpan daftar pendek

Sebelum memberi prompt, tuliskan apa yang ingin Anda ubah, diurutkan dari yang paling penting. Ini mencegah Anda mengirim satu paragraf berisi sepuluh keinginan dalam satu pesan, dan memberi Anda cara untuk berkata "nanti dulu" pada ide yang muncul di tengah jalan.

Jika sebuah perubahan besar, pecah menjadi bagian-bagian. "Tambahkan akun tim" menjadi: membuat tim, mengundang anggota, berpindah antar tim, membatasi data pada tim saat ini. Masing-masing adalah prompt tersendiri. Menulis user story adalah cara yang baik untuk melakukan ini.

Langkah 2: Jelaskan apa yang Anda lihat

AI tidak bisa melihat layar Anda kecuali Anda memberitahunya. Tunjuk hal yang spesifik, dan katakan apa yang seharusnya terjadi:

Di halaman harga di ponsel, tombol kartu Pro terpotong di tepi kanan. Pertahankan tata letak desktop seperti semula; di layar di bawah 640px, susun kartu secara vertikal dan buat tombol selebar penuh.

Bandingkan dengan "halaman harga terlihat buruk di mobile". Yang pertama bisa dikerjakan dan diperiksa sekaligus; yang kedua mengundang desain ulang yang tidak Anda minta.

Tangkapan layar membantu. Jika builder Anda menerima gambar, lampirkan satu dan lingkari masalahnya.

Langkah 3: Rencanakan sebelum perubahan besar

Untuk apa pun yang menyentuh beberapa bagian aplikasi, seperti model data baru, pembayaran, atau peran pengguna, minta rencana sebelum kode berubah:

Jangan ubah kode dulu. Saya ingin pengguna tergabung dalam tim dan hanya melihat proyek timnya sendiri. Susun rencana perubahannya: tabel, halaman, dan rute API mana yang berubah, apa yang terjadi pada data pengguna yang sudah ada, dan urutan pembangunannya.

Baca rencananya. Jika salah, mengoreksi rencana jauh lebih murah daripada membatalkan pembangunan.

Langkah 4: Katakan apa yang tidak boleh berubah

Alat AI kadang "merapikan" hal yang tidak Anda minta. Lindungi apa yang sudah berfungsi:

Tambahkan filter tanggal ke tabel pesanan. Jangan ubah kolom, gaya, atau tombol ekspor pada tabel.

Untuk aturan yang berlaku di mana-mana, seperti warna merek, nada bahasa, atau "jangan pernah menghapus data tanpa konfirmasi", simpan di file catatan proyek atau pengaturan pengetahuan yang dibaca AI setiap saat, alih-alih mengulanginya.

Langkah 5: Periksa lebih dari sekadar perubahannya

Setelah setiap prompt, uji:

• Perubahannya sendiri. Apakah sudah melakukan yang Anda minta, di desktop dan ponsel?
• Tetangganya. Hal-hal di halaman yang sama, dan alur yang memakai data yang sama.
• Jalur kritis. Daftar, masuk, aksi utama, pembayaran. Pemeriksaan tiga puluh detik setelah setiap perubahan besar menangkap sebagian besar kerusakan lebih awal.

Jika ada yang tidak beres, laporkan dengan tepat. Lihat cara menulis laporan bug yang baik.

Langkah 6: Kembali, jangan menumpuk

Ketika sebuah perubahan merusak sesuatu dan perbaikan pertama tidak berhasil, berhentilah. Setiap "perbaikan" tambahan dibangun di atas keadaan yang rusak, dan masalahnya semakin bertumpuk.

Sebagai gantinya:

1. Kembali ke versi terakhir yang berfungsi (checkpoint atau commit Git).
2. Cari tahu apa yang tidak jelas dalam prompt.
3. Coba lagi dengan permintaan yang lebih kecil atau lebih jelas.

Perubahan tadi merusak penyimpanan draf. Saya sudah kembali. Kali ini: tambahkan indikator simpan otomatis saja, sebagai teks di header. Jangan ubah cara draf disimpan.

Langkah 7: Ketahui kapan membangun ulang itu tepat

Membangun ulang dari awal membuang banyak detail yang sudah berfungsi. Itu hanya layak dilakukan saat:

• Ide produknya sudah sepenuhnya berubah.
• Struktur dasarnya tidak bisa mendukung apa yang sekarang Anda butuhkan, misalnya dibangun sebagai situs statis tetapi sekarang membutuhkan akun dan database.
• Proyeknya masih mendekati kosong.

Saat Anda membangun ulang, buat daftar apa yang dipertahankan: nama, warna, teks, dan bagian-bagian yang disukai pengguna.

Contoh prompt

Sebelum kita lanjut, ringkas cara kerja aplikasi saat ini: halaman, data yang disimpan, dan hal-hal yang menurut Anda rapuh.

Saya ingin menambahkan pemesanan berulang. Apa versi terkecil yang akan berguna? Sarankan dalam tiga perubahan terpisah yang bisa kita lakukan satu per satu.

Tinjau tiga perubahan terakhir untuk hal apa pun yang mungkin merusak alur checkout. Jangan edit dulu.

Kesalahan umum

• Sepuluh permintaan dalam satu prompt. Beberapa selesai, beberapa setengah jadi, dan Anda tidak bisa tahu mana yang mana.
• Umpan balik yang samar. "Ini rusak" atau "buat lebih bagus" menghasilkan tebakan.
• Tidak pernah memeriksa tetangganya. Perubahan pada komponen bersama merusak tiga halaman lain.
• Memperbaiki perbaikan. Jika sudah empat prompt dalam menangani satu bug, kembalilah.
• Mengulangi konteks setiap kali alih-alih menyimpan aturan tetap di catatan proyek.
• Membangun ulang saat buntu. Sebagian besar momen "mulai dari awal" sebenarnya berarti "kembali dua langkah".

Daftar periksa

• Satu tujuan per prompt.
• Saya menjelaskan apa yang saya lihat dan apa yang seharusnya terjadi.
• Perubahan besar mendapat rencana sebelum ada kode.
• Saya menyebutkan apa yang tidak boleh berubah.
• Setelah setiap perubahan, saya menguji perubahan itu, tetangganya, dan jalur kritis.
• Saya menyimpan checkpoint atau commit setelah setiap perubahan yang berfungsi.
• Saat perbaikan gagal, saya kembali alih-alih menumpuk perbaikan.
• Aturan tetap disimpan di catatan proyek yang dibaca AI setiap saat.

Mengembangkan di Mythex

Mythex dibangun di sekitar siklus ini:

• Mode Plan, Build, dan Ask. Plan membahas pendekatan sebelum mengedit; Ask menjawab tanpa mengubah kode; Build membuat perubahan. Lihat Chat.
• Checkpoint. Setelah setiap giliran yang berhasil, Mythex menyimpan checkpoint git; Revert to this point mengembalikannya. Anda juga bisa mengedit pesan sebelumnya dan Discard & resend untuk mencoba prompt lain dari titik itu. Lihat Kembangkan tanpa membangun ulang.
• Knowledge. Pengaturan proyek → Knowledge menyimpan catatan tetap yang diikuti agen di setiap pesan.
• /test meminta agen mengklik pratinjau seperti pengguna setelah perubahan besar.

Permintaan yang lebih kecil juga menghabiskan lebih sedikit kredit. Untuk menulis prompt itu sendiri, lihat cara menulis prompt untuk pembuat aplikasi AI; saat ada yang rusak, lihat cara men-debug aplikasi buatan AI.

Pertanyaan