AI agent yang kelihatan sibuk belum tentu lagi maju. Kadang dia cuma kebanyakan oper-operan kerja, kebanyakan tool call, dan akhirnya bikin lu nunggu lebih lama.
Artikel ini ngebahas kenapa delegasi subagent bukan tombol ajaib buat semua task coding. Dari update GitHub Copilot CLI, ada pelajaran praktis: agent yang bagus bukan cuma yang bisa membagi kerja, tapi yang tahu kapan harus berhenti membagi kerjaan dan mulai eksekusi sendiri. Buat developer yang mulai pakai Claude Code, Codex, Copilot CLI, atau Hermes Agent, ini penting karena terlalu banyak handoff bisa bikin workflow lebih lambat, lebih mahal, dan lebih susah direview.
Apa Itu Delegasi Subagent?
Delegasi subagent adalah pola ketika AI agent utama menyerahkan sebagian pekerjaan ke agent lain yang lebih kecil atau lebih spesifik. Misalnya agent utama diminta memperbaiki bug, lalu dia mendelegasikan pencarian file, analisis error, atau editing kode ke subagent terpisah.
Secara konsep, ini masuk akal. Di dunia kerja manusia, lu juga nggak selalu ngerjain semua hal sendiri. Ada task yang lebih cepat kalau dibagi: satu orang baca dokumentasi, satu orang cek log, satu orang bikin test. Masalahnya, di AI agent, setiap delegasi punya biaya: konteks harus dikemas ulang, hasil harus dibaca ulang, tool bisa gagal, dan keputusan bisa makin jauh dari tujuan awal.
Kenapa Update GitHub Copilot CLI Ini Menarik?
GitHub baru menjelaskan bagaimana mereka membuat GitHub Copilot CLI lebih selektif saat mendelegasikan pekerjaan. Mereka menyebut perubahan ini sudah rollout ke production traffic, dan dalam A/B test internal, tool failures per session turun 23%, search tool failures turun 27%, edit tool failures turun 18%, serta total user wait time membaik 5% di P95.
Angka itu tetap perlu dibaca hati-hati karena sumbernya dari GitHub sendiri. Tapi arahnya menarik: problem-nya bukan “agent kurang mampu delegasi”, melainkan “agent perlu lebih pintar memilih kapan delegasi itu benar-benar worth it”.
Menurut gua, ini sinyal penting buat semua builder yang lagi mengandalkan coding agent. Kita sering terlalu cepat menganggap agent yang punya banyak mode, banyak worker, dan banyak handoff pasti lebih canggih. Padahal buat kerja harian, hasil yang paling valuable sering justru datang dari alur yang sederhana: pahami masalah, bikin rencana kecil, tulis test, ubah minimal, verifikasi.
Delegasi Itu Punya Biaya Tersembunyi
Masalah terbesar dari delegasi berlebihan adalah lu sulit melihat mana kerja yang benar-benar produktif dan mana yang cuma “aktivitas”. Agent bisa terlihat aktif karena banyak membaca file, membuka tool, atau memanggil subagent. Tapi progress nyata tetap harus diukur dari artifact: test yang gagal lalu pass, diff yang kecil dan relevan, bug yang tereproduksi, atau dokumentasi yang benar-benar menjawab problem.
Ada beberapa biaya tersembunyi yang sering nggak kelihatan:
- Biaya konteks: setiap subagent perlu diberi konteks. Kalau konteksnya kurang, hasilnya dangkal. Kalau konteksnya kebanyakan, dia bisa tersesat.
- Biaya sinkronisasi: agent utama harus membaca hasil subagent, menilai kualitasnya, lalu menggabungkan keputusan.
- Biaya latency: makin banyak handoff, makin banyak waktu tunggu, apalagi kalau tool call atau pencarian file gagal.
- Biaya review: hasil dari beberapa agent bisa membuat diff lebih besar dan reasoning lebih susah dilacak.
- Biaya token: buat workflow AI, operasi yang kelihatan kecil tetap bisa jadi mahal kalau berulang dalam loop.
Ini bukan berarti subagent jelek. Subagent bisa sangat berguna. Tapi dia harus dipakai seperti alat tajam, bukan seperti default mode buat semua request.
Kapan AI Agent Perlu Delegasi?
Delegasi paling masuk akal ketika task punya bagian yang bisa berjalan paralel dan hasilnya mudah diverifikasi. Contohnya, saat lu perlu membandingkan beberapa pendekatan, membaca dokumentasi dari beberapa sumber, atau melakukan review independen terhadap diff yang sudah jelas.
Dalam workflow gua, delegasi biasanya lebih aman untuk hal seperti ini:
- Research terpisah: satu agent cari dokumentasi resmi, agent lain cek contoh implementasi.
- Code review: setelah diff ada, reviewer independen mengecek security, convention, dan edge case.
- Spike pendek: eksperimen throwaway untuk membuktikan apakah pendekatan teknis layak.
- Task paralel yang independen: misalnya update copy di halaman A dan audit komponen di halaman B, selama tidak saling bergantung.
Kuncinya: output subagent harus bisa diverifikasi. Kalau lu nggak bisa mengecek hasilnya dengan test, diff, log, atau sumber yang jelas, delegasi cuma memindahkan ketidakpastian ke tempat lain.
Kapan Agent Sebaiknya Tidak Delegasi?
Agent sebaiknya tidak delegasi kalau task-nya kecil, linear, atau butuh konteks yang sangat lokal. Misalnya mengganti nama prop di satu komponen, memperbaiki typo dokumentasi, atau menambahkan test kecil untuk utility function. Untuk task seperti ini, handoff sering lebih mahal daripada eksekusi langsung.
Delegasi juga rawan kalau problem belum jelas. Kalau root cause bug belum ketemu, menyuruh beberapa subagent langsung “cari fix” bisa bikin hasilnya makin kacau. Lebih baik mulai dari debugging sistematis: baca error, reproduksi, cek perubahan terakhir, trace data flow, baru pilih satu hipotesis.
Menurut gua, tanda agent kebanyakan delegasi itu biasanya begini:
- Dia bikin banyak rangkuman, tapi diff nyata belum ada.
- Dia membuka banyak jalur investigasi, tapi tidak mengunci satu hipotesis.
- Dia menghasilkan solusi besar untuk bug kecil.
- Dia butuh review panjang karena keputusan tersebar di banyak output.
- Dia gagal menjelaskan “kenapa perubahan ini cukup”.
Checklist Praktis Buat Workflow Coding Agent
Kalau lu mulai pakai coding agent secara serius, coba pakai checklist kecil ini sebelum mengizinkan delegasi:
- Definisikan done: apa bukti task selesai? Test pass, build pass, screenshot, atau API response?
- Batasi scope: tulis file mana yang boleh disentuh dan apa yang tidak perlu diubah.
- Delegasi hanya kalau paralel: kalau task harus berurutan, agent utama biasanya lebih aman eksekusi sendiri.
- Wajib ada artifact: jangan puas dengan summary. Minta diff, log, benchmark, atau referensi.
- Review independen: setelah agent mengubah kode, cek lagi dari sudut spec, kualitas, security, dan test.
- Stop kalau sudah tiga kali gagal: kalau agent muter-muter, kemungkinan problem-nya ada di arsitektur, konteks, atau instruksi.
Checklist ini sederhana, tapi efeknya lumayan besar. Lu jadi tidak menilai agent dari seberapa ramai prosesnya, melainkan dari seberapa jelas output dan verifikasinya.
Pelajaran Buat Developer Indonesia yang Mulai Pakai AI Agent
Banyak developer sekarang lagi masuk fase “semua hal dicoba pakai AI”. Itu wajar. Gua juga ngerasain AI agent bisa mempercepat kerja, terutama buat research, refactor kecil, drafting, dan automation. Tapi makin sering dipakai, makin kelihatan bahwa problem utamanya bukan cuma kemampuan model.
Problem besarnya adalah workflow. Kalau workflow lu berantakan, AI agent akan mempercepat berantakannya. Kalau scope lu nggak jelas, agent bisa menambah fitur yang nggak diminta. Kalau tidak ada test, agent bisa terlihat benar sampai bug-nya muncul belakangan. Kalau tidak ada review gate, hasil agent bisa masuk codebase tanpa jejak reasoning yang cukup.
Makanya gua lebih percaya kombinasi ini: plan kecil, test dulu, minimal diff, review independen, dan baru commit. Subagent boleh masuk, tapi sebagai leverage yang disengaja, bukan reflex setiap kali agent bingung.
Takeaway yang Bisa Langsung Dipakai
- AI agent yang sibuk belum tentu produktif.
- Delegasi bagus untuk task paralel, research, spike, dan review; buruk untuk task kecil yang linear.
- Handoff punya biaya konteks, latency, review, dan token.
- Output agent harus dinilai dari artifact yang bisa diverifikasi, bukan dari panjangnya proses.
- Workflow yang rapi lebih penting daripada sekadar model yang lebih pintar.
FAQ Singkat
Apakah subagent selalu buruk?
Nggak. Subagent berguna kalau pekerjaannya bisa dipisah, hasilnya bisa dicek, dan agent utama tetap punya kontrol keputusan akhir.
Apakah developer pemula perlu pakai banyak agent?
Menurut gua, mulai dari satu agent dulu. Biasakan bikin scope kecil, test, dan review. Setelah itu baru pakai subagent untuk research atau review independen.
Apa metrik paling sederhana buat menilai agent?
Lihat apakah dia menghasilkan artifact yang jelas: test pass, diff minimal, bug tereproduksi, atau referensi valid. Kalau cuma summary panjang, belum tentu progress.
Penutup
AI coding agent makin kuat, tapi kekuatan itu tetap butuh rem. Update GitHub Copilot CLI ngasih sinyal yang menarik: bahkan tool besar pun mulai belajar bahwa lebih banyak delegasi tidak selalu berarti lebih baik.
Buat gua, ini pelajaran yang sangat praktis. Kalau lu mau pakai AI agent buat kerja beneran, jangan cuma tanya “agent ini bisa ngapain?” Tanya juga: “kapan agent ini harus diam, nggak delegasi, dan cukup bikin perubahan kecil yang bisa diverifikasi?”
Kalau artikel ini relate, simpan sebagai checklist kecil sebelum lu kasih coding agent akses ke repo yang serius. Dan kalau lu pernah ngalamin agent yang terlalu rajin sampai bikin codebase makin ribet, itu bisa jadi bahan diskusi yang menarik banget.
