Better Harness Qoder: Mengaudit Sistem Kerja di Balik Agen Coding AI

Better Harness adalah proyek open source dari Qoder untuk meninjau dan memperbaiki workflow di sekitar agen coding AI. Jadi, yang diperiksa bukan hanya satu jawaban model atau satu code diff, melainkan instruksi proyek, kontrol eksekusi, jalur validasi, konfigurasi agen, serta—bila tersedia—rekaman dari sesi kerja nyata. Tujuannya adalah menemukan celah workflow, mengusulkan perbaikan yang ruang lingkupnya jelas, lalu memeriksa hasilnya kembali pada peninjauan berikutnya. 124

Menurut laporan saat peluncuran, Qoder mengumumkan proyek ini sebagai open source di GitHub pada 28 Juli 2026. 5

Fokusnya: menilai harness, bukan hanya model

Agen coding tidak bekerja di ruang hampa. Ia bergantung pada instruksi repositori, spesifikasi, alat, izin akses, skrip, pengujian, ketentuan review, pemeriksaan rilis, serta serah-terima dengan manusia. Qoder menyebut lingkungan pendukung tersebut sebagai harness. Dalam dokumentasinya, harness dapat mencakup instruksi repositori, rules, skills, hooks, plugin, connector, skrip, perintah tes, pemeriksaan rilis, dan langkah review oleh manusia. 2

Pembedaan ini penting. Model yang mumpuni pun dapat memberi hasil yang tidak konsisten bila workflow di sekitarnya kabur atau minim pengamatan. Sebuah proyek mungkin memiliki perintah tes, tetapi tidak memberi petunjuk yang jelas kapan agen wajib menjalankannya. Bisa juga ada file aturan yang tidak pernah dipakai agen, atau pelajaran dari kegagalan tugas tidak pernah disimpan sebagai pengetahuan proyek yang dapat digunakan lagi. Better Harness dirancang untuk menemukan kelemahan operasional semacam itu—bukan menganggap keberadaan satu file konfigurasi sebagai bukti bahwa prosesnya sudah berjalan baik. 145

Tiga lapisan dalam Better Harness

Better Harness diposisikan sebagai kerangka tiga lapisan yang menghubungkan praktik rekayasa, model evaluasi, dan implementasi yang bisa dijalankan. 5

1. Praktik Harness Engineering

Lapisan pertama mencakup mekanisme praktis yang membentuk cara agen bekerja: pola sesi dan CLI, observabilitas, rules, skills, konfigurasi MCP, memori, hooks, dan otomasi. 5

Secara praktis, lapisan ini menjawab pertanyaan seperti:

• Apakah agen menerima tujuan, batasan, dan konteks repositori yang jelas?
• Apakah jalur eksekusi serta izinnya dikendalikan secara tepat?
• Apakah tes, pemeriksaan, dan review benar-benar terhubung dengan pekerjaan agen?
• Apakah pelajaran penting dapat menjadi aset proyek yang dipelihara, bukan hilang saat sesi berakhir?

Better Harness memulai prosesnya dengan memetakan harness yang ada: tujuan, konteks, titik masuk eksekusi, loop umpan balik, mekanisme pengiriman, dan cara pembelajaran ditangkap. 1

2. Evaluasi Agent Work Loop

Lapisan kedua menerjemahkan praktik tadi menjadi evaluasi atas lima dimensi pengiriman yang saling terkait: pemahaman tugas, eksekusi terkendali, validasi perubahan, pengiriman yang andal, dan penangkapan pembelajaran. 14

Dengan begitu, pertanyaannya bergeser dari “apakah agen menghasilkan kode yang tampak masuk akal?” menjadi pertanyaan yang lebih berguna secara operasional: apakah workflow ujung ke ujung dapat berulang kali menghasilkan perubahan yang dipahami, terkendali, tervalidasi, siap dikirim, dan memanfaatkan pembelajaran sebelumnya?

Model ini ditujukan untuk mencari titik putus dalam loop tersebut—misalnya mekanisme yang belum ada, integrasi yang terputus, tahap yang tak pernah benar-benar dijalankan, atau bukti hasil yang belum memadai. 1

3. Implementasi yang dapat dijalankan

Lapisan ketiga membuat praktik dan model evaluasi itu bisa diterapkan pada proyek nyata, bukan berhenti sebagai panduan konseptual. Better Harness berjalan melalui agen coding, mengumpulkan bukti dari proyek dan sesi bila didukung, lalu menghasilkan langkah perbaikan yang diprioritaskan dan dapat diverifikasi. 4

Materi proyek Qoder saat ini menyebut dukungan untuk sepuluh host adapter. Laporan peluncuran secara khusus menyebut Claude Code, Codex, Qoder, dan Cursor sebagai lingkungan agen coding yang didukung. 56

Cakupan adapter dapat berubah. Karena itu, dukungan terhadap host tertentu sebaiknya selalu dicek pada dokumentasi adapter terbaru. Sumber yang tersedia juga belum membuktikan adanya dukungan untuk OpenClaw.

Tiga jenis bukti yang dikumpulkan

Salah satu ciri utama pendekatan ini adalah pemisahan antara pengumpulan bukti dan penilaian akhir. Qoder menyatakan bahwa alur analisis utamanya mengumpulkan data mentah terlebih dahulu, lalu menyerahkannya kepada tiga sub-agen independen dalam mode hanya-baca sebelum hasilnya digabungkan. 1

Tiga sudut pandang tersebut adalah:

• Project Harness: fondasi rekayasa repositori, seperti instruksi, skrip, pemeriksaan, dan kontrol pengiriman.
• Agent Customization: aturan, skills, hooks, dan konfigurasi khusus agen lainnya.
• Session Evidence: catatan mengenai tindakan agen saat mengerjakan tugas nyata, jika bukti tersebut tersedia.

Struktur ini membantu membedakan proses yang direncanakan dari proses yang benar-benar terjadi. Bukti proyek dan konfigurasi dapat menunjukkan bahwa sebuah kemampuan tersedia. Bukti sesi dapat membantu menunjukkan apakah kemampuan itu dipakai secara tepat dalam pekerjaan nyata. 14

Mengapa “ada” tidak sama dengan “berfungsi”

Prinsip paling penting dari kerangka ini adalah: keberadaan artefak bukan bukti efektivitas.

Contohnya, sebuah repositori memiliki rangkaian tes otomatis. Keberadaan tes itu menunjukkan potensi kemampuan, tetapi belum membuktikan bahwa agen menjalankan tes yang relevan setelah mengubah kode, menafsirkan hasilnya dengan tepat, atau menggunakan hasil tersebut untuk mencegah pengiriman yang buruk. Hal serupa berlaku untuk rules, hooks, skills, dan gerbang persetujuan. 15

Karena itu, Better Harness berupaya menjaga rantai bukti tetap eksplisit. Laporannya mengubah celah yang didukung bukti menjadi temuan prioritas (findings) yang memuat dampak, keluaran yang diharapkan, perbaikan dengan ruang lingkup terbatas, dan pemeriksaan penerimaan. Bukti yang belum ada tetap terlihat, alih-alih diam-diam diubah menjadi skor yang terdengar pasti. 46

Sebuah temuan idealnya memungkinkan tim memeriksa empat hal:

1. Apa yang diamati dalam proyek, konfigurasi, atau rekaman sesi.
2. Mengapa hal itu penting bagi loop pengiriman.
3. Perbaikan sempit apa yang diusulkan, misalnya rule, skill, hook, skrip, otomasi, atau langkah persetujuan manusia.
4. Bagaimana perbaikan itu diverifikasi setelah diterapkan.

Siklus perbaikannya: inspeksi, perbaikan, ukur ulang

Better Harness tidak diposisikan sebagai audit satu kali. Workflow-nya bersifat iteratif:

1. Memetakan harness saat ini.
2. Mengidentifikasi titik putus workflow dan kekosongan bukti.
3. Membuat tugas perbaikan dengan cakupan terbatas untuk temuan yang didukung.
4. Memvalidasi perbaikan berdasarkan pemeriksaan penerimaan yang telah ditetapkan.
5. Menjalankan peninjauan kembali untuk melihat bukti yang telah diperbarui. 14

Inilah dasar klaim perbaikan berkelanjutan dari Better Harness. Alat ini dapat menunjukkan bahwa workflow berubah dan apakah bukti baru mendukung penilaian yang lebih kuat. Namun, alat ini sendiri tidak membuktikan bahwa suatu perbaikan menyebabkan performa agen meningkat di semua proyek atau semua lingkungan host. Materi Qoder menekankan bukti yang diamati dan keterbatasan yang eksplisit, bukan perubahan skor sebagai bukti sebab-akibat. 46

Bagaimana membaca evaluasi awal atas 30 proyek GitHub

Laporan peluncuran menyebut kerangka ini digunakan dalam latihan awal yang melibatkan 30 proyek GitHub nyata. 5 Temuan itu lebih tepat dibaca sebagai penerapan eksploratif untuk melihat apakah kerangka mampu menemukan pola celah harness lintas repositori, bukan sebagai demonstrasi terkontrol bahwa Better Harness pasti meningkatkan semua agen coding atau semua proyek.

Dokumentasi primer yang tersedia mendukung model bukti, struktur temuan, dan workflow perbaikan iteratifnya. Namun, sumber yang diberikan belum memuat detail primer yang cukup untuk menilai secara independen cara pemilihan sampel, protokol penilaian, maupun hasil agregat dari 30 proyek tersebut. Batasan ini penting saat membandingkan Better Harness dengan benchmark formal atau membuat klaim performa yang luas. 14

Langkah menuju rekayasa agen yang lebih terukur

Gagasan yang lebih besar dari Qoder adalah menjadikan Harness Engineering sebagai infrastruktur mutu untuk pengembangan perangkat lunak berbantuan AI: kosakata bersama tentang kontrol workflow, bukti yang dapat diamati, dimensi pengiriman yang bisa dibandingkan, serta siklus perbaikan yang dapat diulang. 12

Better Harness menawarkan bentuk praktis dari gagasan tersebut. Tim dapat memeriksa kondisi di sekitar pekerjaan agen pada host yang didukung, mendiskusikan bukti alih-alih kesan semata, dan menguji apakah perbaikan workflow bertahan pada proses berikutnya. Nilainya bukan jaminan bahwa setiap perbaikan selalu meningkatkan hasil, melainkan cara yang lebih disiplin agar workflow agen dapat diperiksa, ditinjau, dan diuji kebenarannya. 46