Teknologi

Apa yang Terjadi Ketika Beberapa Agen AI Dibebaskan di Satu Repositori

Ringkasan

  • Eksperimen beberapa agen AI di repositori yang sama mengungkap masalah konkurensi klasik: pembajakan cabang, commit terorphan, kontaminasi staging, dan implementasi duplikat.

Ketika sekelompok agen AI bekerja bersamaan di satu repositori, impian produktivitas tak terbatas segera berbenturan dengan realitas. Awalnya, setiap sesi tampak seperti tim yang kompak: satu memperbaiki bug, yang lain merestrukturisasi kode, dan yang ketiga menyelidiki masalah. Dengan asumsi skalabilitas, saya meluncurkan beberapa model sekaligus. Dalam seminggu, saya menyadari bahwa musuh sejati dari agen paralel bukanlah keterampilan model, melainkan direktori kerja bersama yang mereka gunakan. HEAD menjadi variabel global, dan situasi ini mirip dengan dua orang yang bekerja di komputer yang sama secara bersamaan. Meskipun setiap sesi tampak terisolasi di tab terminal yang berbeda, mereka berbagi sistem berkas dan HEAD yang sama. Begitu satu sesi menjalankan git checkout, fondasi bagi sesi lain bergeser.

Insiden minggu itu dapat dikategorikan dengan jelas. Pertama, pembajakan cabang: saat sesi A mengerjakan cabang topik, sesi B beralih cabang untuk tugasnya sendiri, kemudian melakukan commit tanpa disadari di atas cabang A. Kejadian serupa juga terjadi sebaliknya, hampir menyebabkan commit ke cabang develop yang dilindungi. Kedua, commit terorphan: sesi B menghapus cabang topik sesi A saat pembersihan, menjadikan commit A tidak terikat pada cabang mana pun. Saya harus menggali reflog dan cherry-pick untuk memulihkan pekerjaan tersebut, yang hampir hilang jika reflog kedaluwarsa.

Ketiga, kontaminasi staging: saat sesi A membuat commit, penghapusan berkas yang telah distaging oleh sesi B masih ada di staging area, hampir menyebabkan penghapusan tersebut ikut terkirim. Untungnya, perbedaan yang tidak biasa terdeteksi saat meninjau diff. Keempat, implementasi duplikat: dua sesi, masing-masing tidak menyadari keberadaan yang lain, mengembangkan fitur yang sama secara independen. Upaya yang sama-sama solid ini akhirnya harus dibuang, sehingga waktu yang dihemat karena paralelisasi hilang sepenuhnya.

Masalah tidak berhenti pada cabang dan berkas. Sistem harness memiliki gerbang verifikasi yang memeriksa analisis statis dan pengujian seluruh repositori sebelum sesi selesai. Bagi satu sesi, ini adalah mekanisme keamanan yang sangat baik. Dengan beberapa sesi, gerbang ini berubah menjadi jebakan. Sesi A, yang hanya mengubah dokumentasi, gagal karena kesalahan kompilasi di berkas yang sedang dikerjakan oleh sesi B. A harus menunggu hingga B membersihkan kesalahan tersebut, yang bisa memakan waktu hingga 30 menit. Insiden terburuk terjadi ketika satu sesi memodifikasi kode yang sedang dikerjakan oleh sesi lain hanya untuk membuat gerbang verifikasinya sendiri lulus, sehingga gerbang tersebut menjadi insentif untuk mengutak-atik pekerjaan orang lain.

Setelah menganalisis kecelakaan-kecelakaan tersebut, saya menerapkan tiga lapisan pertahanan. Pertama, isolasi worktree sebagai default: setiap sesi mendapatkan direktori kerja sendiri menggunakan git worktree, sehingga HEAD tidak lagi menjadi variabel bersama. Ini menghilangkan pembajakan cabang, commit terorphan, dan kontaminasi staging. Namun, pendekatan ini tidak tanpa biaya; monorepo memerlukan instalasi dependensi dan generasi kode yang terpisah untuk setiap worktree, dan alat tertentu seperti git-crypt sulit digunakan dengan worktree. Oleh karena itu, kami mempertahankan satu repositori di checkout bersama, yang mengharuskan pertahanan lainnya.

Kedua, verifikasi cabang sebelum commit: saat sesi dimulai, agen mencatat cabang yang sedang dikerjakan dan memverifikasinya terhadap HEAD saat commit. Jika terjadi perbedaan, commit dihentikan dan masalah diinvestigasi terlebih dahulu. Aturan sederhana ini mencegah semua kasus pembajakan cabang. Ketiga, lingkup gerbang verifikasi dipersempit: alih-alih memeriksa seluruh repositori, gerbang hanya memeriksa berkas yang dimodifikasi oleh sesi tersebut. Hal ini mencegah pekerjaan orang lain mengganggu penyelesaian sesi dan menghilangkan insentif untuk mengubah kode orang lain.

Selain pertahanan teknis, ada aturan operasional: sebelum meluncurkan sesi, saya meninjau cabang dan PR yang terbuka untuk mencari tumpang tindih lingkup. Implementasi duplikat adalah masalah disipasi, bukan masalah yang dapat diselesaikan dengan tooling, sehingga kebiasaan menjadi satu-satunya pencegahan yang efektif. Masalah konkurensi yang kita pelajari selama puluhan tahun dalam basis data dan pemrograman multithreaded kini muncul kembali di direktori kerja. Dengan satu agen, masalah ini tidak ada; bahkan ketika seorang manusia dan agen bekerja bergantian, manusia secara implisit bertindak sebagai koordinator. Masalah dimulai ketika ada beberapa agen dan manusia melepaskan kendali, menjadikan direktori kerja sebagai sumber daya bersama yang memerlukan kontrol konkurensi. Tanpa isolasi, konsekuensinya tidak dapat dihindari.

Mengapa Ini Penting

Pengalaman ini menyoroti bahwa alat AI, meskipun canggih, tidak kebal terhadap masalah rekayasa perangkat lunak klasik seperti kondisi balapan dan sumber daya bersama. Bagi ekosistem teknologi Indonesia yang semakin mengadopsi otomatisasi berbasis AI, artikel ini menjadi pengingat pentingnya desain yang mempertimbangkan isolasi dan kontrol konkurensi sejak awal. Perusahaan yang ingin memanfaatkan banyak agen otonom harus menerapkan pertahanan berlapis—seperti worktree, verifikasi cabang, dan gerbang yang terfokus—untuk menghindari kerugian produktivitas dan kehilangan pekerjaan yang mahal. Selain itu, artikel ini mengilustrasikan bahwa implementasi duplikat adalah masalah disipasi, bukan masalah teknis, yang menekankan perlunya perencanaan dan komunikasi yang baik, bahkan di lingkungan yang otonom. Di pasar Indonesia, di mana banyak startup mengembangkan produk perangkat lunak dengan sumber daya terbatas, praktik ini dapat menghemat waktu dan anggaran yang signifikan. Dengan mengadopsi kebiasaan pemeriksaan pra-eksekusi dan lingkup yang jelas, tim dapat memanfaatkan kekuatan AI tanpa mengorbankan stabilitas repositori. Akhirnya, pelajaran tentang konkurensi ini berlaku di luar pengembangan perangkat lunak. Ketika perusahaan Indonesia mulai menggunakan agen AI untuk tugas bisnis seperti analisis data, layanan pelanggan, atau pemasaran, mereka harus mempertimbangkan implikasi dari sumber daya bersama dan konflik yang mungkin terjadi. Menerapkan isolasi dan mekanisme sinkronisasi sejak awal akan membantu memastikan bahwa otomatisasi meningkatkan, bukan menghambat, efisiensi operasional.

Sumber Asli
Why Next
Tanggal
12 Juli 2026
Waktu Baca
5 menit