Kalau agen menulis kode untukmu, hasilnya tetap perlu dipahami oleh orang yang akan memeriksanya. Agen pembantu pemrograman, atau coding agent, bisa mengubah banyak berkas dalam beberapa menit. Cepatnya perubahan belum menjawab apakah hasilnya sesuai kebutuhan dan tetap menjaga pekerjaan orang lain.
Kita akan mengikuti satu tugas dalam kumpulan kode proyek, atau repositori: memahami masalah, membatasi perubahan, memeriksa hasil, lalu menyerahkannya ke tim. Keberhasilan dinilai dari perubahan yang diterima dengan bukti bahwa perilakunya sudah sesuai. Contoh kesepakatan tugas di sini bersifat fiktif; dukungan petunjuk dan alat bisa berbeda pada setiap agen.
Jelaskan perilaku yang ingin kamu perbaiki
Sebelum menulis petunjuk panjang untuk agen, atau prompt, sepakati dulu masalahnya. Permintaan “Perbaiki checkout” terlalu luas. Kalimat “Tombol kirim tidak boleh membuat dua pesanan ketika ditekan ulang selama permintaan berjalan” memberi batas yang bisa diuji.
Tuliskan keadaan awal, hasil yang diharapkan, bagian yang boleh diubah, dan bukti untuk menerima hasilnya. Sebutkan juga hal yang belum diketahui agar dugaan tidak berubah menjadi fakta. Izin menyunting kode perlu dibedakan dari izin menjalankan pembayaran, memindahkan data, atau menerbitkan sesuatu.
Kesepakatan seperti ini bisa dicatat sebagai kontrak tugas. Contoh berikut menjelaskan perilaku yang ingin dicapai:
{
"task_id": "TASK-042",
"problem": "Formulir dapat dikirim dua kali saat koneksi lambat.",
"expected": [
"Satu permintaan aktif pada satu waktu",
"Isian dipertahankan ketika server gagal",
"Tombol dapat dipakai ulang setelah kegagalan"
],
"scope": ["formulir", "penanganan status", "tes perilaku"],
"evidence": ["kasus sukses", "kasus gagal", "submit berulang"]
}Kontrak tadi masih memberi ruang untuk memilih cara pengerjaan. Orang yang memeriksa perubahan, atau reviewer, bisa menilai apakah solusi yang lebih sederhana sudah memenuhi perilaku yang sama. Daftar nama fungsi yang terlalu cepat ditetapkan bisa mengunci solusi sebelum masalahnya dipahami.
Beri agen petunjuk tentang proyekmu
Dokumentasi AGENTS.md OpenAI menjelaskan cara memberi petunjuk proyek kepada agen yang mendukungnya. Isinya bisa memuat perintah tes, susunan folder, dan kebiasaan tim. Periksa dukungan serta urutan penerapannya pada aplikasi agen yang kamu pakai.
Petunjuk yang berguna mengarah ke rujukan proyek: perintah dalam paket, lokasi bagian kode, dan cara memeriksa hasil. Kamu tidak perlu menyalin semua dokumentasi ke setiap prompt. Salinan aturan mudah tertinggal saat proyek berubah.
Agen juga akan membaca komentar kode, catatan proses, dan dokumen yang mungkin menyerupai perintah. Perlakukan bahan itu sesuai tingkat kepercayaannya. Pesan kesalahan di terminal yang meminta pengunggahan kunci akses belum menjadi perintah yang sah.
Catat keadaan awal sebelum mengubah berkas
Mulai dari status pencatatan versi Git, petunjuk yang berlaku, dan kode yang berkaitan dengan masalah. Catat perubahan yang sudah ada di ruang kerja. Pada proyek bersama, tindakan “mengembalikan semua berkas” bisa menghapus pekerjaan orang lain.
Ikuti juga jalur kode yang memanggil bagian bermasalah. Kesalahan formulir bisa berasal dari pencatat interaksi yang terpasang ganda, bagian penanganan permintaan HTTP, atau percobaan ulang oleh aplikasi pemanggil. Temukan buktinya sebelum menambah pemeriksaan pengaman di banyak tempat.
Untuk tugas besar, bagi perubahan menjadi bagian yang bisa diperiksa sendiri-sendiri. Jika memakai salinan kerja terpisah, tentukan penanda revisi awal atau commit dan cara memindahkan hasilnya. Pemisahan berkas membantu koordinasi, tetapi kesesuaian rancangan dan kesepakatan antarbagian tetap perlu dijaga.
Baca perubahan sedikit demi sedikit
Perbandingan isi sebelum dan sesudah perubahan disebut diff. Dokumentasi Git diff menjelaskan cara memeriksa isi, ringkasan perubahan, serta spasi dan baris kosong. Perintah baca berikut bisa dijalankan pada repositori di komputermu:
git status --short
git diff --stat
git diff --check
git diff -- src/components/CheckoutForm.jsAlamat berkas pada perintah terakhir hanyalah contoh. Ganti dengan berkas yang memang kamu ubah. Perintah itu membantu menemukan berkas yang ikut berubah tanpa sengaja, penghapusan besar, atau pengaturan format yang menyamarkan perubahan logika.
Membaca diff belum menjalankan tes perilaku dan belum membuktikan perubahan aman. Pisahkan pula penataan ulang kode yang tidak dibutuhkan, atau refactor, dari perbaikan perilaku. Jika refactor memang perlu, jelaskan kaitannya dengan solusi.
Misalnya, mengganti nama seluruh bagian kode sambil memperbaiki satu status menunggu membuat reviewer menilai dua jenis perubahan sekaligus. Perubahan yang lebih terarah memudahkan pemeriksaan maksudnya.
Tes perilaku yang benar-benar dirasakan pengguna
Untuk kasus formulir terkirim ganda, mengecek apakah variabel isLoading ada belum cukup. Tes yang lebih berguna mengirim dua interaksi ketika permintaan pertama masih berjalan, lalu menghitung jumlah panggilan. Dengan begitu, tes memeriksa perilaku yang ingin diperbaiki.
Coba juga koneksi terputus, jawaban yang tidak mengikuti format data JSON, pemeriksaan isian, dan tombol yang harus bisa dipakai lagi setelah gagal. Periksa apakah isian pengguna tetap tersimpan. Jawaban berhasil dari server belum cukup kalau tampilan sudah membuang data sebelum mengetahui hasilnya.
Bukti yang kamu kumpulkan bisa berasal dari beberapa pemeriksaan. Pilih yang sesuai dengan dampak perubahan:
| Bukti pemeriksaan | Yang ingin kamu pastikan |
|---|---|
| Tes perilaku | Sudahkah masalah yang dilaporkan tertangani? |
| Pemeriksaan jenis data dan proses pembuatan aplikasi | Bisakah kode diterjemahkan dan dikemas menjadi aplikasi? |
| Pemeriksaan diff | Adakah perubahan di luar tujuan tugas? |
| Pemeriksaan tampilan | Bisakah pengguna memahami status dan cara berinteraksinya? |
| Catatan keterbatasan | Apa yang belum diuji atau belum tersedia? |
Tidak semua perubahan membutuhkan semua jenis tes. Mengubah kalimat tidak memerlukan kumpulan tes baru yang hanya mengecek kalimat itu sendiri. Perubahan transaksi membutuhkan bukti yang lebih kuat.
Serahkan hasil bersama konteks yang dibutuhkan tim
Saat menyerahkan pekerjaan, atau handoff, sebutkan masalah, perilaku setelah perubahan, alasan pilihan solusi, dan pemeriksaan yang benar-benar dijalankan. Bedakan laporan “perintah selesai” dari “tes lulus”. Bila layanan belum tersedia sehingga pemeriksaan tidak bisa berjalan, simpan rujukan penyebabnya dan jelaskan batas hasilmu.
Sebutkan risiko yang berpengaruh, misalnya pemindahan data yang belum dijalankan atau sambungan layanan yang baru diuji dengan tiruan, atau mock. Proses pembuatan paket aplikasi, yang disebut build, bisa berhasil meski sebagian kebutuhan lingkungan belum terpenuhi. Jadi, laporan “siap produksi” tetap membutuhkan bukti yang sesuai.
Untuk latihan, beri agen tugas yang sama dengan petunjuk kabur dan dengan kontrak perilaku. Tetapkan panduan penilaian sebelum melihat hasil, lalu bandingkan waktu pemeriksaan dan perbaikannya. Kalau kamu ingin melanjutkan pekerjaan setelah persetujuan tanpa kehilangan jejak versi, baca serah terima manusia dan agen.
