Sebelum memberi tugas ke AI agent, siapkan repo agar hasilnya mudah ditinjau

Buat reviewer memahami keputusan tanpa menebak

Ukuran keberhasilannya ialah reviewer dapat membaca tujuan, melihat bagian yang berubah, dan membandingkan hasil dengan syarat yang disepakati. Persiapan ini berguna saat bekerja sendiri maupun dalam tim: pemilik proyek berikutnya tidak perlu mengandalkan ingatan percakapan untuk memahami alasan sebuah perubahan. Agent pun mempunyai tempat untuk mencatat pertanyaan yang belum terjawab, sehingga ketidakpastian tidak berubah diam-diam menjadi perilaku aplikasi.

Brief yang kecil perlu menjawab persoalan nyata

Pada contoh ekspor katalog, kata “laporan” masih terlalu luas. Apakah hasilnya mengikuti filter layar atau memuat seluruh produk? Apakah harga berupa angka rupiah atau teks dengan simbol mata uang? Pertanyaan ini memengaruhi hasil yang diterima pemilik toko. Jawabannya perlu masuk brief, bukan hanya tersimpan dalam obrolan dengan agent.

Perubahan dapat tetap kecil tanpa mengabaikan kebutuhan. Jika ekspor memakai fungsi pengambilan data yang sudah ada, rencana perlu menjelaskan hubungan tersebut. Jika ternyata fungsi itu hanya tersedia di bagian admin, agent sebaiknya mengungkapkan hambatannya sebelum mengusulkan pembukaan akses baru. Kecepatan implementasi tidak menyelesaikan keputusan siapa yang boleh melihat data.

Minta penyerahan yang menjawab apa yang berubah, alasan pendekatannya, dan bukti yang menyertai. Perintah pemeriksaan yang gagal perlu ditulis sebagai gagal. Pemeriksaan yang belum berjalan perlu dicatat beserta alasannya. Menyatukan keduanya menjadi “sudah dites” membuat pemilik kehilangan informasi untuk menentukan langkah berikutnya.

Aturan di berkas tidak sama dengan pembatasan akses

Instruksi repository dapat menerangkan kebiasaan proyek dan permintaan agar agent berhenti sebelum deploy. Namun, tulisan itu sendiri tidak mencabut izin token, menghilangkan akses produksi, atau mengubah pengaturan hosting. Cocokkan akses yang diberikan dengan pekerjaan yang disepakati; tugas pada data buatan tidak memerlukan kredensial pelanggan.

Dokumentasi GitHub menjelaskan bahwa branch protection dapat mensyaratkan review dan status checks sebelum perubahan masuk. Pengaturan bawaan mempunyai pengecualian bagi admin atau peran yang dapat melewati perlindungan, kecuali pembatasan tersebut ikut diterapkan. Periksa pula persetujuan yang kedaluwarsa ketika isi perubahan bertambah; ada opsi untuk meminta penilaian ulang atas perubahan terbaru.

Artinya, melihat adanya aturan belum cukup. Untuk repository percobaan, pengelola dapat memeriksa apakah PR yang belum disetujui memang tertahan sesuai rancangan. Jangan mencoba melewati aturan pada proyek produksi untuk membuktikannya. Bukti yang dicari ialah bahwa alur yang disepakati berjalan dengan peran dan akun yang benar.

Penanggung jawab perlu hadir ketika hasil siap dibaca

CODEOWNERS menetapkan orang atau tim penanggung jawab berdasarkan bagian berkas. Menurut dokumentasi GitHub, pemilik kode otomatis dimintai review ketika PR yang relevan siap ditinjau, bukan ketika masih berstatus draft. Berkas tersebut perlu ada pada base branch, yaitu branch tujuan PR. Mewajibkan persetujuan pemilik kode memerlukan pengaturan required reviews yang sesuai.

Gunakan pembagian itu untuk memperjelas keputusan, bukan sekadar menambah nama. Pada ekspor katalog, developer dapat menilai implementasi, sementara pemilik toko memeriksa apakah kolom dan isinya memenuhi kebutuhan. Jika salah satu memberi masukan yang mengubah perilaku, catat keputusan tersebut pada PR agar percakapan berikutnya mempunyai acuan yang sama.

Siapkan jalan kembali sebelum pekerjaan dimulai

Ruang kerja terpisah membantu orang membedakan hasil tugas agent dari pekerjaan lain yang belum selesai. Sebelum mulai, catat perubahan yang sudah ada dan versi dasar yang dipakai. Jika agent menemukan berkas yang sedang dikerjakan rekan, ia perlu mengungkapkan hubungan tersebut. Menghapus atau menimpa pekerjaan agar pemeriksaan mudah dijalankan justru menghilangkan bahan yang perlu dipertahankan.

Pada contoh ekspor katalog, rencana pembatalannya dapat berupa pengembalian perubahan kode yang menambahkan ekspor, tanpa memengaruhi daftar produk. Apabila implementasi ternyata membutuhkan migrasi data atau pengiriman berkas ke layanan lain, rencana awal sudah tidak cukup. Pisahkan keputusan tersebut dan minta penilaian tambahan sebelum melanjutkan; membatalkan antarmuka tidak otomatis mengembalikan data yang sudah berubah atau terkirim.

Catatan ini sebaiknya mengikuti usulan kode, sehingga pembaca PR berikutnya melihat versi kebutuhan yang sama. Dengan begitu, ketika tugas diteruskan ke agent atau developer lain, yang diwariskan adalah keputusan yang dapat diperiksa, bukan hanya kesan bahwa sesi sebelumnya sudah selesai.

Brief buatan: ekspor katalog yang sedang ditampilkan

Contoh buatan Nalarku, bukan hasil uji produk.

Bahan

Data latihan buatan toko: P001, Mug Hijau, kategori Keramik, harga 25000 rupiah; P002, Buku Catatan, kategori ATK, harga 15000 rupiah; P003, Mug Biru, kategori Keramik, harga 30000 rupiah. Filter kategori aktif adalah Keramik. Ekspor mencakup semua hasil filter, termasuk halaman berikutnya.

Hasil yang diperiksa

Hasil yang diharapkan memuat P001 dan P003, dengan kolom kode, nama, harga. Harga berupa 25000 dan 30000 sebagai bilangan bulat rupiah. P002 tidak masuk hasil. Ini rancangan hasil untuk bahan buatan, bukan keluaran agent yang telah diuji.

Cara memeriksa

• Seluruh hasil filter Keramik, termasuk halaman berikutnya, masuk; P002 dari kategori ATK tidak ikut.
• Hasil dibaca di aplikasi spreadsheet yang disepakati, tanpa mengklaim semua aplikasi telah diuji.
• Pemeriksaan menunjuk commit yang sama dengan usulan yang akan diputuskan.

Satu brief tugas dan satu rancangan pull request yang dapat ditinjau sebelum kode digabungkan.

Tingkat: Teknis

Bahan latihan

• Salinan kerja atau branch khusus tugas
• Perintah pemeriksaan proyek yang telah diketahui
• Contoh data buatan tanpa informasi pelanggan
• Nama penanggung jawab keputusan dan ruang lingkup akses

Instruksi yang bisa dicoba

Baca instruksi repository dan jelaskan alur terkait sebelum mengedit. Tugas: buat ekspor CSV untuk seluruh produk yang cocok dengan filter kategori aktif, termasuk hasil pada halaman berikutnya. Gunakan kolom kode, nama, dan harga dalam bilangan bulat rupiah tanpa simbol mata uang. Gunakan data buatan. Jangan mengubah autentikasi, skema database, atau proses deploy. Susun rencana beserta daftar berkas yang perlu diubah dan pertanyaan yang belum terjawab; tunggu keputusan pemilik sebelum implementasi. Setelah diizinkan, buat perubahan pada branch tugas. Laporkan versi kode, ringkasan perubahan, perintah pemeriksaan dan hasil sebenarnya, batas pengujian, serta langkah membatalkan perubahan. Jangan memberi persetujuan atas hasilmu sendiri atau melakukan merge.

Langkah yang bisa kamu ikuti

1. Tulis satu hasil yang dapat diamati dan bagian yang boleh diubah. Pisahkan keputusan produk yang belum jelas dari pekerjaan implementasi.
2. Catat cara menjalankan proyek serta pemeriksaan yang relevan. Siapkan data latihan buatan dan ruang kerja terpisah dari perubahan lain.
3. Tetapkan orang yang memeriksa perilaku, perubahan kode, dan keputusan rilis. Periksa aturan repository yang benar-benar berlaku untuk branch tujuan.
4. Minta agent mengajukan rencana sebelum implementasi. Bila kebutuhan merambat ke izin, database, atau layanan baru, hentikan bagian terkait dan putuskan lingkupnya.
5. Sesudah implementasi, cocokkan perubahan dengan brief dan bukti pemeriksaan pada commit terbaru. Keputusan menerima, menggabungkan, serta merilis tetap dibuat sesuai kewenangan pengelola.

Sumber dan referensi

Analisis menggabungkan fakta bersumber dan penafsiran Nalarku.

Sumber diperiksa 12 Nov 2026, 19.17 WIB. Disusun dengan bantuan AI dan review editor.

Proses editorial dan penggunaan AI · Usulkan koreksi