Agen Saya Mengirimkan 3 PR Dalam Satu Malam. 40% Dari Pesan Saya Adalah Koreksi.

Agen pengodean berbasis AI saya mengirimkan tiga pull request dalam satu malam, tetapi 40% dari 30 pesan yang saya kirimkan adalah koreksi.

Sesi tersebut menghasilkan sebuah MCP client, Azure AI Agent, dan M365 Copilot Agent. Pemeriksaan otomatis meloloskan ketiga PR tersebut, dan saya tidak pernah mengedit satu baris kode pun. Namun, transkripnya menceritakan kisah yang berbeda: dari total 710 pesan, saya mengetik 30 pesan, dan 12 di antaranya mengarahkan kembali agen ke jalur yang benar. “Steering rate” – proporsi pesan saya yang berupa koreksi – berada di angka 40%.

Bagaimana alur kerja (pipeline) disusun

  • Claude menyusun rencana implementasi tingkat tinggi.
  • DeepSeek V4-Flash bertindak sebagai orchestrator, meninjau rencana tersebut.
  • Codex menghasilkan kode yang sebenarnya.
  • Orchestrator memeriksa kode dan membuka pull request.

Peran yang dimaksudkan bagi orchestrator murni sebagai penghubung – ia seharusnya menyelesaikan konflik antar komponen, bukan menulis kode itu sendiri. Dalam praktiknya, agen tersebut menghasilkan 3.500 baris kode di ketiga PR dalam waktu sekitar 40 menit, tetapi ia juga melakukan kesalahan pada dua jenis error yang berulang.

Dua jenis error

  1. Pelanggaran alur kerja (workflow violations) – orchestrator sesekali mengambil alih langkah pengodean, mengabaikan peran "penghubung"-nya dan menulis detail implementasi sendiri.
  2. Kegagalan pengambilan konteks (context-retrieval failures) – meskipun ada instruksi eksplisit, agen memilih SDK atau versi yang salah. Informasi yang benar ada di dalam konteks prompt, tetapi model gagal memunculkannya pada saat yang tepat.

Ini bukan celah dalam kemampuan penalaran; ini adalah bug rekayasa (engineering bugs) dalam cara alur kerja dibatasi. Bahkan model bahasa yang lebih mumpuni pun tetap akan membutuhkan aturan yang tegas dan tidak boleh terlewatkan untuk mengunci orchestrator pada tugas non-pengodeannya dan memaksa pemilihan SDK yang benar.

Apa yang saya ubah untuk menjinakkan agen tersebut

Saya berhenti berasumsi bahwa sistem akan menyimpulkan perannya dari daftar langkah kerja. Saya menambahkan pernyataan langsung: “You are an orchestrator. You do not implement.” Dibutuhkan lima pesan koreksi agar instruksi tersebut dipatuhi, setelah itu agen tersebut menghormati batasan tersebut.

Saya juga memperketat logika pengambilan konteks. Ketika alat yang salah muncul, saya menganggapnya sebagai bug dalam pipeline pengambilan data, bukan halusinasi, dan saya menulis ulang prompt yang menyuplai detail SDK agar versi yang benar tidak mungkin terlewatkan.

Pelajaran praktis untuk pengembangan berbasis AI

  • Hitung pesan Anda sendiri. Volume PR yang diterima yang tinggi dapat menutupi proses yang rusak. Jumlah koreksi Anda adalah indikator utama di mana sistem mengalami kebocoran.
  • Nyatakan peran secara eksplisit. Agen tidak mengekstrapolasi identitas dari daftar periksa; mereka membutuhkan instruksi yang jelas dan tetap tentang siapa mereka dan apa yang boleh mereka lakukan.
  • Anggap kesalahan pemilihan alat sebagai bug rekayasa. Jika agen mengabaikan SDK yang ditentukan, kesalahannya terletak pada mekanisme pengiriman konteks, bukan pada "pengetahuan" model tersebut.
  • Ubah kesalahan menjadi keterampilan yang dapat digunakan kembali. Saya membiarkan agen menghasilkan rutinitas validasi dari kesalahannya sendiri, mengubah kegagalan menjadi pengaman di masa depan.

Pertaruhan yang lebih luas