Setiap agen pengodean AI dapat mengeluarkan diff. Masalah sebenarnya adalah mengetahui apakah diff tersebut berasal dari proses yang terfokus dan terencana—atau hasil pemindaian panik di seluruh repositori Anda yang kebetulan menemukan kebenaran. Saat ini, sebagian besar tim tidak dapat membedakan keduanya.

Ini bukan keterbatasan teknis. Ini adalah masalah visibilitas.

Ketika sebuah agen menulis tiga baris kode produksi, ia mungkin telah membaca tiga file dan menjalankan pengujian. Atau ia mungkin telah menyentuh empat puluh file yang tidak terkait, mengeksekusi selusin perintah yang gagal, melewati rangkaian pengujian Anda karena instalasi dependensi rusak, dan menagih biaya untuk semua itu. Diff tersebut terlihat identik dalam kedua skenario. Tanpa catatan perjalanan, Anda hanya bisa menebak-nebak kualitas hasil akhirnya.

Mengapa Log Chat Bukanlah Resi

Banyak alat menawarkan transkrip obrolan sebagai bukti kerja. Transkrip bukanlah sebuah resi. Transkrip hanyalah sekotak suku cadang yang ditumpahkan ke meja Anda. Ia berisi setiap putaran pemikiran, setiap upaya yang gagal, setiap system prompt, dan setiap panggilan alat yang tidak relevan. Jika Anda perlu membaca seribu baris percakapan untuk memvalidasi sebuah patch tiga baris, alur kerja peninjauan (review workflow) Anda sudah rusak.

Perhatian manusia itu terbatas. Tujuan dari sebuah agen adalah untuk menghemat upaya kognitif, bukan untuk memberikan pekerjaan rumah. Transkrip menuntut peninjau untuk menjadi detektif. Resi memberikan jawaban secara sekilas.

Resi yang berguna adalah ringkasan praktis. Ia memberi tahu Anda apa yang diminta untuk dilakukan oleh agen, apa yang sebenarnya ia lakukan, dan bagaimana ia mencapai kesimpulannya. Ia tidak menyembunyikan kegagalan. Ia justru menonjolkannya.

Seperti Apa Resi yang Baik Itu

Resi yang dapat ditinjau harus menjawab pertanyaan-pertanyaan spesifik tanpa perlu menggali lebih dalam:

  • Apa tugasnya? Deskripsi yang jelas tentang perubahan yang dimaksudkan, bukan sekadar pengulangan prompt yang samar.
  • File mana saja yang dibaca? Agar Anda dapat menilai apakah agen membangun konteks dari sumber yang tepat.
  • File mana saja yang diedit? Jejak akhir dari perubahan tersebut.
  • Perintah mana saja yang dijalankan? Langkah build, linter, formatter, atau skrip kustom yang dipanggil oleh agen.
  • Perintah mana saja yang gagal? Bukan hanya keberhasilan. Kegagalan mengungkapkan di mana agen harus berimprovisasi atau di mana ia menyerah.
  • Pengujian apa yang berhasil atau dilewati? Pengujian yang dilewati adalah tanda bahaya (red flag). Resi harus menyatakan mengapa pengujian tersebut dilewati.
  • Berapa total biayanya? Token, panggilan API, dan waktu komputasi. Ini mencakup harga arsitektur Anda, bukan hanya modelnya.

Format ini mengubah peninjauan dari penggalian arkeologi menjadi pemeriksaan kewarasan (sanity check) yang cepat. Seorang insinyur senior seharusnya dapat memindai resi tersebut dan mengatakan "ini masuk akal" atau "ini terlihat mencurigakan" dalam waktu kurang dari satu menit.

Baca Jejaknya, Bukan Hanya Riwayatnya

Jejak dari jalannya sebuah agen menunjukkan bentuk pekerjaannya. Apakah agen tetap berada dalam batasan tiket? Atau apakah ia berkelana ke modul yang tidak terkait dan mengubah hal-hal yang tidak diminta oleh siapa pun? Resi yang mencantumkan "Files Edited" di samping "Files Read" membuat hal ini menjadi jelas.

Jejak tersebut juga mengungkapkan pengulangan. Agen yang terus-menerus menemui jalan buntu yang sama—membaca file konfigurasi yang sama tiga kali, atau menjalankan pengujian yang gagal berulang kali—membuang-buang komputasi dan context window. Pola tersebut harus terlihat. Jika sebuah agen membutuhkan sembilan kali percobaan untuk menjalankan skrip migrasi, resi harus menyatakannya. Informasi tersebut mengubah cara Anda mengevaluasi hasilnya. Sebuah diff "benar" yang dihasilkan melalui kekacauan brute-force tidaklah sama dengan diff benar yang dihasilkan secara bersih.

Biaya Tersembunyi dari Desain yang Buruk

Biaya bukan sekadar harga per token. Alur kerja yang dirancang dengan buruk membuat agen menjadi mahal bahkan sebelum ia menghasilkan satu karakter pun. Skema alat yang membengkak, pengindeksan file yang tidak perlu, dan system prompt yang terlalu luas semuanya memperbesar context window. Resi harus mengungkap beban tambahan (overhead) ini.

Jika pembuatan (generation) menjadi lebih murah tetapi peninjauan menjadi lebih sulit, Anda tidak mendapatkan apa pun. Anda hanya memindahkan hambatan (bottleneck). Waktu insinyur biasanya merupakan sumber daya yang paling langka dalam sebuah tim. Menghemat lima dolar dalam biaya API sambil menambah tiga puluh menit waktu peninjauan per pull request adalah pertukaran yang buruk. Resi membantu Anda mengaudit pertukaran ini secara langsung.

Kejujuran Adalah Sebuah Fitur

Resi yang berguna harus terasa tidak nyaman jika diperlukan. Ia harus melaporkan fakta-fakta yang membuat agen terlihat tidak efisien, karena kejujuran tersebut membuat keputusan manusia berikutnya menjadi lebih cepat dan lebih baik.

Contoh itu penting:

  • "Membaca 37 file untuk perubahan satu baris."
  • "Melewati pengujian karena npm install gagal akibat konflik peer dependency."
  • "Mengedit utils.py di luar cakupan yang diminta untuk memperbaiki import yang diperkenalkan oleh agen."
  • "Menjalankan linter 4 kali; tiga pertama gagal karena kesalahan konfigurasi path."

Ini bukanlah bug dalam tanda terima (receipt). Ini adalah sinyal. Sinyal ini memberi tahu peninjau di mana harus memfokuskan skeptisisme. Ini juga memberi tahu tim platform di bagian mana alur kerja itu sendiri perlu diperketat.

Eksekusi Lebih Kecil, Pengawasan Lebih Jelas

Ada godaan alami untuk membiarkan agen bekerja tanpa kendali pada cakupan yang luas. Satu prompt raksasa untuk melakukan refactor pada seluruh layanan terasa cepat. Padahal tidak. Hal itu menciptakan tumpukan pekerjaan yang tidak dapat ditinjau. Waktu sore Anda akan habis hanya untuk melacak file mana dari delapan puluh file yang berubah yang memang disengaja.

Eksekusi yang kecil dan dapat diperiksa jauh lebih baik. Tentukan batasan yang jelas untuk tugas tersebut. Pisahkan daftar file yang boleh dibaca agen dari daftar file yang boleh ditulisnya. Catat riwayat perintah yang gagal agar jalan buntu terlihat jelas. Tandai verifikasi yang dilewati secara eksplisit. Catat setiap penggunaan alat eksternal, mulai dari API pencarian hingga test runner.

Tujuannya bukanlah otonomi total. Otonomi total yang tidak dapat diverifikasi oleh manusia hanyalah otomatisasi yang membawa risiko (liability). Tujuan sebenarnya adalah ketertinjauan (reviewability). Setiap output agen harus mudah disetujui atau mudah ditolak. Tidak boleh ada area abu-abu yang ambigu di mana Anda menerima kode hanya karena Anda terlalu lelah untuk menyelidikinya.

Ujian bagi Agen Coding Apa Pun

Sebelum mengadopsi agen atau platform apa pun, ajukan satu pertanyaan: Bisakah ia meninggalkan bukti yang cukup bagi manusia untuk menyetujui langkah berikutnya dengan percaya diri?

Jika jawabannya ya, alat tersebut cocok ke dalam alur kerja profesional. Jika jawabannya tidak, Anda tidak sedang membeli produktivitas. Anda sedang membeli sebuah misteri yang sesekali bisa dikompilasi. Itu tidak masalah untuk proyek sampingan di akhir pekan. Namun, itu tidak dapat diterima untuk rekayasa produksi (production engineering).

Tim yang memperlakukan output agen sebagai hadiah tanpa diperiksa pada akhirnya akan merilis bug halus yang disebabkan oleh scope creep yang tidak terdeteksi. Perbedaan kodenya (diff) akan terlihat tidak berbahaya. Padahal, tanda terima (receipt) tersebut seharusnya sudah mengatakan yang sebenarnya.

Wajibkan tanda terima (receipt). Rancang untuk ditinjau. Kepercayaan bukanlah sebuah strategi. Bukti adalah strateginya.

Untuk diskusi lebih mendalam seputar alat AI dan alur kerja pengembang, Anda dapat bergabung dengan komunitas di GyaanSetu on Telegram.