AI Agent Perbaiki Bug: Cara Membangun yang Mampu Mereproduksi Bug Terlebih Dahulu

Sebuah agen AI yang memperbaiki bug secara mandiri akan bekerja jika mengikuti satu aturan: tanpa reproduksi, tanpa perbaikan. Agen mengubah laporan bug menjadi tes yang gagal saat ini, mem-patch kode di branch yang terisolasi, menjalankan ulang tes tersebut beserta seluruh suite, dan hanya melapor kembali ketika semuanya hijau. Manusia tetap yang melakukan merge. Jika tidak bisa mereproduksi bug, ia diam saja.

Coba Apidog hari ini

Tim DeepSeek Harness memaparkan ide ini di hadapan audiens besar pada 1 November 2026, dalam sebuah esai tentang desain super-agent. Panduan ini mengubahnya menjadi pipeline yang bisa Anda bangun minggu ini, dengan reproduksi yang ditulis sebagai tes API yang dibuat dan dijalankan agen Anda langsung dari terminal.

Mengapa "agent, perbaiki ini" gagal tanpa repro

Minta agen coding untuk memperbaiki laporan bug dan biasanya Anda akan mendapat diff yang tampak percaya diri. Anda tak bisa memastikan apakah itu memperbaiki bug Anda, bug yang dibayangkannya sendiri, atau sama sekali tidak ada.

Tanpa langkah reproduksi, tiga hal akan salah:

• Agen menebak penyebabnya. Ia memilih baris yang paling mungkin dari pesan error dan mengeditnya.
• "Selesai" tidak punya definisi. Satu-satunya bukti adalah ringkasan dari agen itu sendiri.
• Regressi menyusup. Patch pada validator bersama bisa memperbaiki satu endpoint dan merusak empat lainnya.

Tes yang gagal menyelesaikan ketiganya: ia mengunci bug, mendefinisikan "selesai", dan tetap berada di suite Anda sebagai pemeriksa regressi.

Dari mana "diam-diam mereproduksi dan memperbaiki" berasal

Dalam "Exploring Super-agent Design", tim DeepSeek Harness menguraikan kebijakan dari grup pengguna mereka sendiri: ketika seseorang melaporkan bug, sebuah agen mencoba mereproduksinya di latar belakang. Ia hanya bersuara dengan perbaikan sederhana yang terkonfirmasi. Jika tidak, ia tidak mengatakan apa pun.

Esai itu menyebutnya speculative execution dan memasangkannya dengan dua komponen yang akan Anda pakai kembali di sini. Workers mendapat satu sesi terisolasi per tugas, akses penuh ke tools dan model terkuat, serta melapor ke router alih-alih berbicara dengan manusia. Watchdog adalah sesi terpisah yang memeriksa apakah setiap worker sedang berkembang atau justru menyimpang.

Satu catatan: esai tersebut menggambarkan sebuah arsitektur, bukan fitur DeepSeek Harness yang sudah dirilis. Sebagian ada di plugin prototipe, dsh-superagent-prototype, yang menurut para penulisnya bukan produk resmi DeepSeek. Untuk gambaran router dan worker, lihat cara membangun super-agent.

Pipeline agen perbaikan bug lima langkah

Agen yang memperbaiki dirinya sendiri menjalankan loop yang sama setiap kali, dengan dua gerbang:

1. Intake: kumpulkan laporan, request yang gagal, dan respons yang diterima.
2. Reproduksi: tulis tes yang gagal dengan alasan yang dilaporkan. Tanpa tes yang gagal, tanpa perbaikan.
3. Perbaiki: patch kode di branch atau worktree yang terisolasi.
4. Jalankan ulang: tes baru harus lulus, begitu juga suite yang sudah ada.
5. Serahkan: buka pull request beserta buktinya, atau diam saja.

Langkah 1: Terima laporan bug

Agen Anda tidak bisa mereproduksi "checkout-nya rusak lagi". Beri intake format yang baku:

Kolom	Contoh	Mengapa penting
Endpoint	POST /orders	Handler mana yang perlu dibaca
Request	Body dengan "coupon": null	Input persis yang memicunya
Respons aktual	500, {"error":"internal"}	Apa yang harus terlihat gagal di tes
Respons yang diharapkan	201 dengan id order	Apa yang dites
Lingkungan	staging	Di mana repro dijalankan

Jika ada kolom yang kurang, agen bertanya sekali atau menarik request dari log. Error body yang mengikuti RFC 9457 problem details membantu, karena tipe error datang dalam bentuk yang bisa diprediksi.

Langkah 2: Reproduksi bug sebagai tes API yang gagal

Ini gerbangnya. Agen mengubah catatan intake menjadi test case dengan dua asersi — kode status yang diharapkan dan sebuah field yang seharusnya ada di respons — lalu menjalankannya terhadap lingkungan sungguhan. Ada tiga kemungkinan hasil:

• Gagal dengan alasan yang dilaporkan. Anda punya repro. Lanjutkan.
• Lulus. Bug tidak bisa direproduksi seperti yang dijelaskan. Catat di log dan berhenti.
• Gagal dengan alasan lain (error autentikasi, data hilang, timeout). Itu repro yang rusak, bukan bug yang terkonfirmasi. Berhenti.

Hanya yang pertama yang membuka pintu perbaikan. Itulah makna praktis dari "diam-diam": dua hasil lainnya hanya menghasilkan entri log untuk penanggung jawab antrean, bukan pesan di chat pengguna.

Tulis repro sebagai tes API, bukan unit test: agen menghantam antarmuka yang sama dengan yang dihantam pengguna, sehingga ia tak bisa tak sengaja mereproduksi bug yang berbeda.

Langkah 3: Perbaiki kode di branch terisolasi

Setelah repro berwarna merah, worker mendapat salinan kodenya sendiri. Git worktree adalah pilihan paling ringan: direktori kerja kedua di branch baru, sehingga suntingan agen tidak pernah menyentuh checkout Anda. Jalankan layar dari sana dan arahkan lingkungan tes ke sana.

Jaga dua kendala tetap ketat. Perbaikan harus kecil: tetapkan batas, misalnya 3 file atau 50 baris berubah, dan perlakukan apa pun yang lebih besar sebagai laporan untuk manusia. Dan harus menyasar repro: tanpa refactor, rename, atau rapikan-rapikan, karena setiap perubahan ekstra adalah sesuatu yang harus diperiksa reviewer Anda.

Langkah 4: Jalankan ulang repro dan seluruh suite

Gerbang kedua punya dua bagian. Pertama, agen menjalankan ulang test case yang sama dari langkah 2, tanpa diubah, dan harus lulus. Jika agen mengedit asersi untuk mencapainya, perbaikan itu gagal; pipeline Anda menangkapnya dengan membandingkan (diff) file tes sebelum dan sesudah.

Kedua, suite yang sudah ada harus tetap hijau. Perbaikan yang membuat satu tes hijau dan tiga merah kembali ke langkah 3. Beri batas waktu pada loop, misalnya 3 percobaan atau 20 menit, lalu berhenti dan catat apa saja yang sudah dicoba. Di sinilah watchdog membuktikan keberadaannya: ia bisa menghentikan worker yang terus mengedit baris yang sama atau menyimpang ke file yang tidak pernah disentuh repro.

Langkah 5: Serahkan hanya perbaikan sederhana yang terkonfirmasi

Ketika kedua gerbang hijau, agen membuka pull request berisi bukti, bukan cerita: laporan, hasil run yang gagal, diff, dan run yang lulus beserta hasil suite. Manusia yang mereview dan melakukan merge. Protected branches memastikan token agen bisa mendorong branch tapi tidak pernah merge ke main. Jika ada gerbang yang gagal, pelapor tidak mendengar apa pun; agen menulis satu baris log dan melanjutkan.

Pagar pengaman untuk agen AI yang memperbaiki diri sendiri

Pasang pagar-pagar ini sebelum run tanpa pengawasan pertama:

Guardrail	Pengaturan	Yang dicegah
Lingkup	Maksimum file dan baris per perbaikan	Rewrite yang dibungkus sebagai perbaikan
Batas waktu	Maksimum percobaan dan menit per bug	Loop liar yang membakar token
Kredensial	Staging saja, tanpa kunci produksi	Repro yang menulis order sungguhan
Hak merge	Push branch, tidak pernah merge	Kode tanpa review masuk ke main
Integritas tes	Diff file tes sebelum dan sesudah	Asersi yang diedit agar lulus
Keheningan	Tidak ada pesan ke pengguna saat gagal	Kebisingan dan klaim setengah terkonfirmasi

Kredensial paling penting: repro menghantam API secara sungguhan, jadi gunakan staging atau data lokal yang di-seed.

Biar agen coding Anda membangun repro dengan Apidog CLI

Langkah 2 adalah jantung pipeline, dan itulah alasan Apidog CLI dibuat. Agen coding Anda (Claude Code, Codex, Cursor, atau OpenCode) menulis test case sebagai JSON, membuatnya di proyek Apidog Anda, dan menjalankannya dari terminal. Anda cukup menulis satu prompt.

Pasang sekali saja:

npm install -g apidog-cli@latest
apidog auth login --with-token <YOUR_TOKEN>
npx -y skills add https://apidog.com   # pick your agent when prompted

Lalu serahkan laporan bug dan prompt ini kepada agen Anda:

Here is a bug report for POST /orders in Apidog project <projectId>.
Turn it into an Apidog test case that fails today: assert status 201
and that $.id exists. Run it against staging and confirm it fails for
the reported reason. If it does, fix the handler on a new worktree
branch until the same test passes, run the endpoint's other cases, and
open a PR with both JSON reports. If it doesn't reproduce, stop and log why.

Agen tidak membuat payload dari ingatan. Ia membaca schema, mencari kategori, memvalidasi filenya, dan baru kemudian membuat case:

apidog cli-schema get test-case-create
apidog test-case category --project <projectId>
apidog cli-schema validate test-case-create --file repro-orders.json
apidog test-case create --project <projectId> --file repro-orders.json

File yang ia tulis terlihat seperti ini (ID berasal dari proyek Anda):

{
  "name": "Repro: POST /orders with null coupon returns 500",
  "apiDetailId": 123456,
  "categoryId": 1,
  "method": "post",
  "path": "/orders",
  "parameters": {},
  "commonParameters": {},
  "requestBody": {
    "type": "application/json",
    "data": "{\"items\":[{\"sku\":\"A-100\",\"qty\":1}],\"coupon\":null}"
  },
  "postProcessors": [
    { "type": "assertion", "defaultEnable": true, "enable": true,
      "data": { "name": "status is 201", "subject": "httpCode", "comparison": "equal", "path": "", "value": "201" } },
    { "type": "assertion", "defaultEnable": true, "enable": true,
      "data": { "name": "order id exists", "subject": "responseJson", "comparison": "exists", "path": "$.id" } }
  ]
}

Sekarang run merah yang membuktikan bug-nya:

apidog run --test-case <caseId> --project <projectId> -e <stagingEnvId> -r cli,json --out-file repro-before

Reporter CLI menunjukkan asersi status gagal pada 500, dan repro-before.json mendarat di apidog-reports/. Setelah perbaikan, agen menjalankan perintah yang identik dengan --out-file repro-after dan kedua asersi lulus. Dua file itulah bukti di pull request. Untuk langkah 4, ia menjalankan semua case di endpoint agar perbaikan tidak diam-diam merusak tetangganya:

apidog test-case run --project <projectId> --endpoint <endpointId> -e <stagingEnvId> -r cli,json

Tambahkan --upload-report untuk menampilkan run di aplikasi Apidog. Setelah merge, case repro tetap ada di proyek Anda sebagai tes regressi, dan apidog run yang sama dengan -r junit bisa langsung masuk ke CI, seperti ditunjukkan di menjalankan Apidog CLI dalam pipeline CI/CD. Untuk konfigurasi lainnya, lihat workflow agen Apidog CLI dan Apidog CLI di Claude Code. Apidog Free mencakup hingga 4 pengguna, jadi Anda bisa mencoba seluruh loop ini tanpa paket berbayar.

FAQ

Apakah agen AI benar-benar bisa memperbaiki bug tanpa manusia?

Ia bisa mereproduksi, mem-patch, dan membuktikan banyak bug sederhana secara mandiri, tapi ia tidak seharusnya melakukan merge. Pertahankan manusia pada tahap merge, dan biarkan branch protection menegakkannya.

Bagaimana jika agen tidak bisa mereproduksi bug?

Ia berhenti dan mencatat apa saja yang sudah dicoba. Bug yang tak bisa direproduksi adalah perbaikan yang tak bisa dikonfirmasi, sehingga patch apa pun hanyalah tebakan. Manusia kemudian menambahkan detail pada laporan atau menutupnya.

Bagaimana mencegah agen mengedit tes agar lulus?

Simpan salinan atau hash test case saat pertama kali gagal dan bandingkan sebelum menerima perbaikan. Letakkan file tes di luar jalur yang boleh diedit worker.

Apakah saya butuh DeepSeek Harness untuk membangun ini?

Tidak. Esai tersebut menggambarkan sebuah desain, dan plugin prototipenya bukan produk resmi DeepSeek. Agen coding apa pun yang bisa menjalankan perintah shell akan bekerja, termasuk Claude Code di GitHub Actions. Lihat apa itu DeepSeek Harness jika Anda ingin mencobanya di sana.