Cara menskalakan agen coding AI di seluruh tim developer

Satu developer dengan satu agen coding adalah cerita produktivitas. Mudah diceritakan, bagus untuk demo, dan memang benar adanya.

Lima developer dengan dua puluh agen adalah hal yang sama sekali berbeda. Itu masalah koordinasi, dan masalah koordinasi tidak selesai oleh alat yang menciptakannya. Bagian inilah yang jarang ditulis orang, karena baru muncul setelah fase euforia lewat: keuntungan individual itu nyata, datangnya langsung, lalu di sekitar developer ketiga atau keempat tim mulai menghabiskan kecepatan barunya untuk membereskan kekacauannya sendiri.

Berikut urutan kegagalannya. Bukan daftar praktik terbaik yang mengawang, melainkan urutan nyata bagaimana segala sesuatu rusak, karena memperbaikinya dengan urutan yang salah membuang satu kuartal.

Yang rusak pertama: konteks bersama

Setiap developer yang menjalankan agen diam-diam mengajari agennya versi codebase miliknya sendiri.

Satu orang memberi tahu agennya bahwa proyek memakai server actions dan tidak pernah API routes. Yang lain tidak pernah menyebutkannya, jadi agennya menulis API routes. Yang ketiga menyebutkannya sekali, di sesi yang berakhir tiga hari lalu. Tidak ada yang salah, tidak ada yang berbohong, dan repositori kini berisi tiga tafsir atas konvensi yang sama. Anda akan menyadarinya di antrean review, dan itu tempat yang salah untuk menyadarinya: saat itu kodenya sudah telanjur ada.

Perbaikannya membosankan dan justru itu hal paling berdampak di halaman ini. Tulis konvensinya di sebuah file, lalu commit file itu.

CLAUDE.md untuk Claude Code, AGENTS.md untuk Codex dan sebagian besar agen CLI lain, dan pada praktiknya banyak tim memilih satu file konteks yang portabel daripada memelihara dua file yang lama-lama saling menyimpang. Mekanismenya lebih penting daripada nama filenya: instruksi itu hidup di repositori, jadi ia datang lewat git pull, bukan lewat siapa pun yang kebetulan sedang ada di ruangan.

Yang layak masuk ke dalamnya:

• Konvensi yang tidak bisa disimpulkan agen hanya dengan membaca kode, terutama yang di beberapa tempat justru dilanggar oleh codebase saat ini
• Perintah-perintahnya: cara menjalankan tes, build, linter, dan mana di antaranya yang boleh dijalankan otomatis
• Bagian repo yang berbahaya untuk disentuh, beserta alasannya
• Apa yang tidak diinginkan tim: refactor yang tidak diminta siapa pun, dependensi yang tidak boleh ditambahkan, pola yang sedang ditinggalkan

Yang tidak layak masuk, dan di sinilah tim biasanya kena batunya: apa pun yang khas satu mesin. Path absolut, token API pribadi, port lokal, editor favorit seseorang. Begitu nilai khas satu mesin mendarat di file konteks yang di-commit, setiap developer lain mewarisi setelan yang salah bagi mereka, dan agen sangat pandai mengikuti dengan setia instruksi yang sudah tidak berlaku.

Satu tes yang berguna sebelum menambahkan baris: kalau rekan tim menarik baris ini, apakah itu menolong mereka atau justru merusak kerja mereka?

Yang rusak kedua: dua agen, satu file

Agen tidak bernegosiasi. Mereka tidak mengecek apakah ada orang lain yang sedang mengedit. Dua agen yang diarahkan ke modul yang sama akan saling menimpa, dan tidak satu pun akan menyebutkannya, karena dari sudut pandang masing-masing pekerjaan selesai dengan sukses.

Ketika bekerja sendirian, ini tidak terlihat. Anda menjalankan satu agen dalam satu waktu, atau menjalankan beberapa dan kebetulan mereka menyentuh hal yang berbeda. Di dalam tim, ini menjadi struktural, dan menghasilkan kelas bug terburuk: pekerjaan yang lenyap diam-diam di antara dua uji coba yang sama-sama hijau.

Dua mekanisme memperbaikinya, dan Anda butuh keduanya.

Isolasi. Git worktrees memberi setiap tugas checkout repositorinya sendiri, sehingga agen yang berjalan paralel secara fisik tidak bisa bertabrakan. Ini separuh solusi yang murah dan tidak ada alasan untuk tidak melakukannya.

Kepemilikan. Isolasi menghentikan penimpaan, tapi ia tidak menghentikan dua orang menyelesaikan masalah yang sama dua kali, di dua branch, dengan dua cara yang tidak kompatibel. Yang itu diselesaikan saat penugasan, dengan membatasi setiap tugas ke sekumpulan file dan menuliskannya di tugas itu sendiri. Bukan "perbaiki alur checkout" melainkan "ubah langkah pembayaran, di tiga file ini, jangan sentuh keranjang".

Separuh kedua inilah yang sering dilewati tim, dan itulah yang menentukan apakah merge cuma formalitas atau menghabiskan satu sore penuh.

Yang rusak ketiga: review

Semua soal review pada skala tim berangkat dari satu angka: berapa banyak diff yang tiba per jam.

Satu developer yang membaca setiap baris jelas sanggup. Lima developer yang masing-masing menjalankan empat agen menghasilkan lebih banyak diff per hari daripada yang bisa dibaca tim, dan hasil jujurnya bukan review yang cermat, melainkan sandiwara persetujuan. Manusia yang membaca sekilas diff sembilan ratus baris pada jam enam sore menghasilkan tanda tangan tanpa menghasilkan pengetahuan, dan itu lebih buruk daripada tidak me-review sama sekali, karena ia memproduksi rasa aman yang tidak ada dasarnya.

Kebijakan yang bertahan bukan "review semuanya" dan bukan pula "percayakan saja pada agen". Kebijakan itu memindahkan review ke dua batas pekerjaan: baca rencananya sebelum agen mulai, karena rencana yang salah yang dieksekusi dengan sempurna adalah mode kegagalan termahal yang ada, lalu baca diff-nya sebanding dengan apa yang bisa dirusak perubahan itu. Copy marketing dan CSS cukup dibaca sekilas. Auth, pembayaran, izin, data pribadi dan migrasi dibaca baris demi baris oleh manusia, setiap kali, sebersih apa pun tampilan diff-nya.

Ini pantas dibahas tersendiri, dan kami sudah menulisnya terpisah: apakah Anda tetap harus me-review kode agen AI Anda membahas sepuluh tanda objektif bahwa sebuah perubahan melenceng, plus tabel blast radius yang bisa diadopsi tim apa adanya.

Satu tambahan yang khas tim. Ketika beberapa agen berbagi satu repositori, review butuh atribusi: agen mana, tugas mana, developer mana. Tanpa itu, sebuah diff tidak punya penulis dan review berubah menjadi arkeologi. Ini hal paling berguna untuk dibereskan di setup Anda begitu Anda melewati tiga atau empat agen yang berjalan bersamaan.

Yang rusak keempat: biaya, dan percakapan tentang biaya

Belanja token berhenti menjadi urusan pribadi begitu ia muncul di tagihan tim.

Jebakannya, tagihan itu bulanan dan agregat, jadi percakapan yang dihasilkannya pun bulanan dan agregat, artinya ia melahirkan kebijakan alih-alih perbaikan. Seseorang mengusulkan model yang lebih murah untuk semua orang. Yang lain mengusulkan pembatasan sesi. Keduanya cuma tebakan.

Distribusi sebenarnya hampir tidak pernah merata. Ia berupa sejumlah kecil sesi panjang, di satu atau dua proyek, dengan konteks yang membengkak sepanjang hari dan tidak pernah direset. Itu perilaku yang bisa diperbaiki, dan Anda hanya bisa memperbaikinya kalau bisa melihat belanja per sesi dan per proyek, bukan per bulan. Kami sudah membahas mekanismenya di cara memeriksa penggunaan token dan cara menekannya tanpa memperlambat kerja.

Buat angkanya terlihat oleh orang yang menghasilkannya, sebelum ia menjadi topik manajemen. Developer yang bisa melihat bahwa satu sesi menghabiskan lebih banyak daripada seluruh harinya kemarin akan mengubah kebiasaannya sendiri, dan itu tidak memakan ongkos politik apa pun bagi tim.

Yang benar-benar berubah pada ritual tim

Tiga hal, menurut pengalaman kami dan menurut yang dilaporkan tim-tim lain.

Standup bergeser dari status ke membuka jalan. Apa yang dikerjakan setiap orang kemarin sebagian besar sudah terlihat di branch. Yang layak lima menit adalah agen mana yang macet, dan macet di bagian apa.

Prompt menjadi aset bersama. Instruksi yang memberi hasil bagus bagi satu developer lebih berharga bagi tim daripada kode yang dihasilkannya, dan itu persis jenis hal yang menguap di riwayat terminal pribadi. Tim yang menyimpan pustaka prompt bersama di repositori berhenti menemukan ulang rumusan yang sama setiap minggu.

Spesialisasi berpindah dari orang ke peran. Begitu agen menangani penulisan kode, pertanyaan menariknya adalah siapa me-review apa, dan tim secara alami bergeser ke pemberian peran kepada agen persis seperti mereka memberi peran kepada orang: satu untuk implementasi, satu untuk review, satu untuk tes. Itulah ide di balik Agent Teams, tempat sebuah tugas diserahkan dari peran Dev ke peran QA lengkap dengan diff, risiko dan petunjuk pengujiannya, dan gerbang kualitas ditentukan oleh test suite Anda, bukan oleh pendapat agen tentang hasil kerjanya sendiri.

Setup yang bertahan

Ringkasnya, dalam urutan yang penting:

Empat yang pertama tidak butuh biaya, cuma kesepakatan. Dua yang terakhir adalah alasan sebuah tim akhirnya menginginkan sesuatu di atas terminal: bukan karena terminal itu buruk, melainkan karena terminal hanya menampilkan satu agen dalam satu waktu dan tidak memberi Anda cara untuk menjawab "siapa menjalankan apa, di proyek mana, saat ini juga".

Itulah masalah yang menjadi dasar AgentsRoom untuk tim: semua agen di semua proyek dalam satu tampilan, lengkap dengan peran, status dan biayanya, plus pendamping mobile untuk saat tim sedang tidak di meja kerja. Ia bekerja dengan cara yang sama bersama Claude Code maupun Codex, dan itu lebih penting daripada kedengarannya: kebanyakan tim pada akhirnya menjalankan keduanya, dan setup yang mengandaikan satu provider diam-diam menjadi hal berikutnya yang rusak.

Tapi mulailah dari file konteks. Gratis, cukup satu sore, dan ia menghilangkan lebih banyak gesekan daripada alat apa pun yang bisa Anda pasang kuartal ini.

Pertanyaan yang sering diajukan

Bagaimana cara memakai agen coding di seluruh tim engineering?

Mulailah dari konteksnya, bukan dari toolingnya. Commit satu file instruksi bersama (CLAUDE.md atau AGENTS.md) ke repositori supaya setiap agen di setiap mesin membaca konvensi yang sama. Lalu tentukan file mana yang dimiliki setiap tugas, sehingga dua agen tidak pernah mengedit modul yang sama sekaligus. Pilihan alat jauh kurang penting dibanding dua keputusan itu.

Apakah CLAUDE.md atau AGENTS.md harus di-commit ke repositori?

Ya. Justru itu intinya: rekan tim baru, atau agen baru, mewarisi konvensi tim tanpa perlu bertanya kepada siapa pun. Jauhkan nilai yang khas satu mesin dari file itu: path absolut, token pribadi, port lokal dan preferensi individual tempatnya di file lokal yang tidak dilacak, bukan di file bersama.

Bagaimana cara mencegah dua agen mengedit file yang sama?

Beri setiap tugas working tree-nya sendiri dengan git worktrees, dan batasi setiap tugas ke sekumpulan file saat penugasan. Agen tidak bernegosiasi satu sama lain, jadi kalau dua di antaranya bisa menjangkau modul yang sama, cepat atau lambat mereka akan saling menimpa pekerjaan dengan cara yang tidak dilaporkan keduanya.

Apakah code review berubah ketika tim menjalankan agen coding?

Volumenya berubah, jadi kebijakannya harus ikut berubah. Membaca setiap baris tidak bertahan menghadapi lima agen yang berjalan paralel. Tim yang tetap terkendali me-review rencana sebelum pekerjaan dimulai, lalu me-review diff sebanding dengan apa yang bisa dirusak perubahan itu, memusatkan perhatian pada auth, pembayaran, izin, data pribadi dan migrasi.

Bagaimana cara melacak biaya agen coding AI per developer?

Per sesi dan per proyek, bukan per bulan. Tagihan bulanan memberi tahu Anda totalnya dan tidak ada yang bisa ditindaklanjuti. Yang Anda butuhkan adalah proyek mana dan jenis tugas mana yang melahap token, karena jawabannya biasanya sejumlah kecil sesi panjang dengan konteks yang membengkak, bukan tim secara keseluruhan.

Apa yang rusak pertama ketika sebuah tim menskalakan agen coding?

Konteks bersama, sebelum hal lain apa pun. Setiap developer menumpuk konvensi lokal di kepalanya sendiri dan di prompt-nya sendiri, sehingga repositori yang sama mendapat tiga tafsir yang tidak kompatibel tentang cara mengerjakan sesuatu. Antrean code review adalah tempat Anda menyadarinya, tapi penyebabnya ada di hulu.