Mengapa Tim Multi-Agen yang Besar Sering Macet
Ketika agen LLM mulai digunakan secara massal dalam pengembangan, banyak tim mengambil jalur yang logis, tetapi tidak selalu berhasil: merekrut sebanyak mungkin "spesialis" algoritmik dan memberi mereka peran. Satu menulis kode, yang lain mencari kerentanan, yang ketiga memeriksa skenario. Masalahnya, setiap agen baru memberikan semakin sedikit manfaat: pada tugas tingkat repositori, biaya koordinasi dengan cepat melebihi keuntungan dari "tambahan tenaga".
Reaksi terhadap hal ini adalah gerakan ke arah yang berlawanan: agen diubah menjadi sub-agen — alat yang patuh, yang dipanggil berdasarkan permintaan dan tidak terlibat dalam dialog. Pendekatan ini menghilangkan kekacauan, tetapi sekaligus menghancurkan sumber daya utama kerja kolektif: tidak ada lagi yang menentang keputusan orang lain, dan akibatnya, kesalahan lolos tanpa disadari.
Titik Keseimbangan: Kooperasi Minimal
Eric S. Qiu dan Joyce Gill meneliti jalan tengah ini dalam karya «Adversarial Review: Structured Disagreement for Grounded Agentic Code Review» (arXiv:2608.18167, kategori cs.AI dan cs.SE; diajukan pada 16 Agustus 2026, diterima di ICML 2026 Workshop on DL4C). Hipotesis mereka sederhana: kita dapat mempertahankan kesederhanaan arsitektur sub-agen, tetapi menambahkan kooperasi minimal ke dalamnya — satu titik di mana pendapat agen sengaja dipertemukan.
Hasilnya adalah protokol Adversarial Review (AR). Para penulis sengaja tidak membangun hierarki yang rumit dan tidak menciptakan banyak peran. Sebagai gantinya, tiga partisipan bekerja:
- agen pengkode menyiapkan perubahan pada kode;
- peninjau mengevaluasi seberapa benar perubahan tersebut;
- kritikus mengaudit bukan kodenya, melainkan tinjauan itu sendiri dan menemukan kelemahan di dalamnya.
Kritikus tidak hanya mengatakan "saya tidak setuju" — ia mengajukan ketidaksepakatan terstruktur: menunjukkan fragmen kode spesifik yang tidak mendukung kesimpulan peninjau. Dan hanya ketika siklus ini selesai, agen utama mendapatkan izin untuk melakukan perbaikan.
Apa yang Ditunjukkan oleh Pengujian
Efek ketidaksepakatan terlihat jelas pada hasil tolok ukur.
Pada LiveCodeBench, AR menunjukkan persentase keberhasilan tertinggi di antara semua metode yang diuji. Detail penting: untuk ini, tiga agen sudah cukup, sedangkan varian dasar yang dikalahkan AR menggunakan lima agen.
Pada SWE-PRBench, segalanya menjadi lebih menarik. Versi protokol yang naif secara tak terduga mengungkap mode kegagalan yang oleh para penulis disebut konsensus palsu: agen-agen mencapai kesepakatan tanpa memiliki cukup bukti. Artinya, bahkan ketidaksepakatan yang dibangun secara khusus pun dapat merosot menjadi "setuju dengan semua orang" yang formal. Ini diperbaiki dengan satu iterasi prompt, di mana persyaratan untuk berdebat dan membenarkan ketidaksetujuan dituliskan secara eksplisit — setelah penyempurnaan tersebut, metode ini menempati posisi pertama dalam F1.
Terakhir, pada SWE-bench Verified, AR kembali meningkatkan hasil pendekatan dasar. Ini penting karena tugas tingkat repositori adalah skala kompleksitas yang sangat berbeda dari fungsi yang terisolasi: perubahan di satu modul dapat merusak puluhan modul di sekitarnya.
Kesimpulan: Kekuatan Berasal dari Hak untuk Menolak, Bukan dari Jumlah Suara
Para penulis sampai pada kesimpulan yang kontraintuitif, tetapi terbukti secara eksperimental: peninjauan kode yang efektif tidak memerlukan tim besar atau skema komunikasi yang rumit. Cukup jika ketidaksepakatan itu:
- minimal — satu titik konflik, bukan obrolan tanpa akhir;
- terstruktur — setiap partisipan memiliki fungsi yang jelas;
- berbasis bukti — keberatan didasarkan pada fakta dalam kode, bukan pada preferensi selera.
Pelajaran praktis bagi semua orang yang membangun pipeline agen: jangan mencoba memecahkan masalah dengan menambah peran. Lebih baik tanamkan tahap keraguan yang wajib ke dalam proses — dan izinkan satu agen untuk secara resmi menentang kesimpulan agen lain. Nilai tinjauan tidak ditentukan oleh jumlah suara, tetapi oleh keberadaan seseorang yang mampu menolak secara substansial.
