Tanya Brian
Kalau nyuruh banyak agent AI kerja bareng, gimana kalau ada yang ngerusak?
Jawaban singkat
jalanin beberapa agent AI barengan di satu tempat, bukan bikin workspace terpisah buat tiap agent. Soal takut AI-nya ngerusak sesuatu, gw lebih milih benerin daripada rollback. Tapi buat risiko yang beneran besar, polanya bukan santai aja benerin, melainkan bikin sistem pengecek dua lapis sebelum sesuatu dianggap aman.
Ini pertanyaan yang muncul dari beberapa peserta sesi kemarin, soal workflow, multi-agent, dan yang paling bikin was-was, soal rollback kalau AI-nya kena risiko kritikal.
Multi-agent gak sesulit yang dibayangin
Salah satu peserta nanya, kalau nyuruh 4 agent kerja sekaligus, berarti harus bikin 4 workspace terpisah?
Jawabannya enggak. Kerja di satu tempat aja, satu branch, semua agent disuruh kerja di situ.
Gimana soal tabrakan, semua agent ngedit file yang sama bareng-bareng? Harusnya gak jadi masalah, karena mereka ngerjain hal yang beda-beda. Kalaupun akhirnya konflik, tinggal suruh salah satu agent resolve sendiri.
Gw kasih catatan jujur di sini: skenario tabrakan-edit ini belum pernah gw uji sengaja. Buat kerjaan kayak kita yang bukan ngedit satu logika yang sama persis di satu bagian aplikasi, gw belum pernah kena masalahnya. Kalau kerjaan lo justru yang model begitu, hati-hati, dan jangan pakai pengalaman gw sebagai jaminan.
Poin yang mau digarisbawahi, kekhawatiran orang soal multi-agent itu biasanya lebih rumit di kepala daripada di praktik. Bayangannya harus ada workspace terpisah dan koordinasi ketat antar agent, padahal jauh lebih sederhana kalau tugasnya udah dipecah jelas dari awal.
Kenapa harus multi-agent, bukan satu agent ngerjain semua
Alasannya soal efisiensi. Kerjaan narik data itu murah dan gak butuh mikir berat. Rugi kalau kerjaan semacam itu dikerjain sama model yang mahal.
Jadi polanya, model mahal nyebar beberapa agent kecil buat kerjaan harvest (narik dan baca data mentah), lalu model mahal itu cuma baca hasil ringkasannya. Kayak punya tim kecil-kecil yang masing-masing pegang bagian sendiri, dan yang mikir berat cuma satu yang paling mahal.
Cara mikirnya mirip kayak lo punya tim beneran. Lo gak bakal minta orang paling senior di tim buat baca ratusan baris data mentah satu-satu. Lo kasih itu ke yang junior, baru senior-nya baca ringkasan dan mutusin. Multi-agent kerjanya sama persis, cuma yang jadi "junior" dan "senior" itu sama-sama AI, bedanya di kapasitas dan ongkosnya.
Soal rollback, dan kenapa gw lebih milih benerin
Ini bagian yang paling sering ditanyain dengan nada khawatir. Sejauh ini, belum pernah kejadian sampai harus rollback beneran.
Gw lebih milih benerin daripada rollback. Kadang ada yang kesenggol pas lagi ngerjain sesuatu, dan itu emang beberapa kali kejadian. Abis benerin bagian A, eh bagian B-nya ikut kesenggol, ya dibenerin lagi. Sesimpel itu, disuruh kerjain, terus dites.
Penting digarisbawahi, ini bukan berarti sembarangan atau asal jalan aja tanpa kontrol. Yang bikin pola ini bisa dipakai adalah karena ada proses tes ulang tiap kali ada perbaikan, bukan cuma ditinggal jalan lalu berharap beres sendiri. Efeknya, urutan kerjanya jadi siklus pendek, ada yang kesenggol, dites, kelihatan, dibenerin, dites lagi, bukan sekali jalan besar yang baru dicek di ujung.
Buat risiko yang beneran besar, beda lagi ceritanya
Ini yang penting dipahami biar gak salah tangkap. Buat kerjaan yang risikonya kecil, benerin sambil jalan itu cukup. Tapi buat risiko yang beneran besar, misalnya hapus tabel database atau ubah data produksi, pola yang dipakai bukan sekadar baca kode AI baris per baris lalu berharap ketemu kesalahannya.
Pola yang dipakai justru bikin sistem pengecek dua lapis:
- Lapisan mekanis, deterministik. Aturan yang pasti dan tegas. Kalau suatu aksi kena area tertentu yang berisiko, langsung diblokir. Gak ada abu-abu di lapisan ini.
- Lapisan AI, probabilistik. Ada reviewer terpisah, agent lain, yang ngecek ulang hasil kerja agent pertama sebelum dianggap aman.
Kalau kena blokir di salah satu lapisan itu, AI-nya disuruh ngerjain ulang. Diulang terus sampai lolos kedua lapisan itu. Jadi buat area yang beneran kritikal, gerbangnya bukan cuma satu orang atau satu AI yang mutusin sendiri, tapi dua sistem yang saling ngecek. Ini yang bikin polanya tetap aman meskipun tetap lebih milih benerin daripada rollback.
Peran lo berubah jadi orkestrator
Yang berubah di sini bukan cuma cara ngerjain, tapi peran lo sendiri. Sekarang lo jadi orkestrator. Titel yang relevan di era AI itu orkestrator, bukan builder atau operator lagi.
Artinya kerjaan lo bukan lagi ngetik semua baris sendiri atau nungguin satu proses selesai baru mulai yang lain. Kerjaan lo ngatur beberapa agent, nentuin mana yang butuh lapisan pengecekan ketat dan mana yang cukup dites lalu dibenerin kalau ada yang meleset.
Kesimpulannya
Kalau lo baru mau coba jalanin beberapa agent sekaligus, gak perlu ribet bikin banyak workspace. Mulai dari satu tempat kerja yang sama, dan biarin mereka bagi tugas. Soal takut ngerusak sesuatu, ukur dulu risikonya. Kalau kecil, benerin sambil jalan itu udah cukup. Kalau besar, pastikan ada dua lapis pengecekan sebelum sesuatu dianggap aman, bukan cuma mengandalkan satu AI yang ngecek dirinya sendiri.
Kalau lo baru mau mulai, jangan langsung mikirin lima agent. Jalanin dua, di kerjaan yang kalau salah gak bikin kiamat, dan lihat gimana rasanya jadi orang yang ngawasin bukan yang ngerjain. Lapisan pengecek baru kepikiran setelah lo ngerasain sendiri di mana bocornya, dan bagian itu yang gw bedah di AI Circle.