TL;DR: Routing adalah menentukan agen coding mana yang menangani suatu tugas. Lakukan routing berdasarkan properti tugas, bukan berdasarkan peringkat minggu lalu: apa yang diubahnya, seberapa mudah dikembalikan ke kondisi semula, apakah file yang disentuhnya bertabrakan dengan file yang sedang dikerjakan agen lain, berapa lama ia berjalan tanpa pengawasan, dan langganan mana yang menanggungnya. Cocokkan hal-hal itu dengan agen yang perilakunya di basis kode Anda paling sesuai. Cara ini masih bisa Anda simpan di kepala saat hanya ada satu atau dua agen. Lewat dari tiga, keputusan routing perlu tempat bersama untuk bersandar. Panduan ini memberi Anda aturannya dan sebuah daftar periksa.
Anda punya Claude Code di satu terminal, Codex di terminal lain, mungkin Gemini CLI di terminal ketiga. Lalu datang sebuah tugas: perbaiki tes yang flaky, tambahkan endpoint, lakukan refactor pada modul yang diimpor tiga file lain. Agen mana yang mendapatkannya? Sebagian besar dari kita menjawab berdasarkan kebiasaan, atau berdasarkan jendela yang kebetulan sedang aktif. Cara itu bertahan sampai Anda tidak lagi ingat agen mana yang Anda serahi tugas migrasi, atau sampai dua agen mengedit file yang sama.
Memilih agen "terbaik" adalah keputusan sekali pakai yang langsung usang begitu model baru dirilis. Menentukan agen mana yang mendapat tugas ini adalah keputusan yang Anda ambil puluhan kali dalam sepekan, dan jauh lebih bergantung pada tugasnya ketimbang pada peringkatnya. Begitu Anda punya lebih dari satu agen, routing-lah tempat waktu Anda habis.
Sharkly dibangun di sekitar keputusan itu. Sharkly adalah platform command dan manajemen Agent serba-ada: Anda menghubungkan Komputer Anda sendiri, mendefinisikan Agent sekali sebagai peran yang terikat pada sebuah runtime, lalu menetapkan sebuah Task kepadanya. Sharkly berada di atas agen coding yang sudah Anda jalankan, bukan di sampingnya. Artikel ini membahas cara melakukan routing tugas dengan baik, pertama sebagai aturan yang Anda terapkan secara manual, lalu sampai pada titik ketika keputusan routing butuh tempat bersama untuk bersandar.
Routing adalah keputusan, bukan preferensi
Mulai dari definisi yang bersih. Routing adalah mencocokkan tugas dengan agen yang seharusnya mengeksekusinya. Ini tidak sama dengan memilih agen favorit Anda, dan tidak sama dengan memilih model. Model mana untuk tugas coding mana adalah pertanyaan terpisah yang lebih sempit, satu lapis di bawahnya; di sini kita memutuskan agen mana (Claude Code, Codex, Gemini CLI, OpenCode, dan lainnya) yang menerima pekerjaan itu.
Sebuah tugas membawa properti yang menentukan rutenya sebelum kemampuan agen ikut diperhitungkan:
- Apa yang diubahnya. Perbaikan satu file, refactor lintas bagian, fitur baru dari nol, tes, dokumentasi. Masing-masing punya radius dampak yang berbeda.
- Seberapa mudah dikembalikan. Perbaikan typo dan migrasi database sama-sama menghasilkan diff. Hanya satu di antaranya yang bisa merusak sore Anda jika agen salah melakukannya.
- Tumpang tindih file. Apakah tugas ini menyentuh file yang sedang diedit agen lain saat ini?
- Horizon otonomi. Edit interaktif yang singkat, atau eksekusi panjang tanpa pengawasan yang harus merencanakan, mengeksekusi, dan memeriksa sendiri hasilnya.
- Batas biaya. Langganan atau anggaran API mana yang sebaiknya menanggungnya.
Baca sebuah tugas melalui kelima properti itu dan rutenya biasanya terpilih dengan sendirinya. Kesalahannya adalah melompat langsung ke "agen mana yang terbaik", pertanyaan yang tidak punya jawaban tetap dan berubah setiap kali sebuah lab merilis sesuatu.
Lakukan routing berdasarkan bentuk tugas, sebelum berdasarkan kemampuan
Agen coding memang berbeda satu sama lain. Satu mungkin bagus dalam merencanakan tugas multi-langkah yang panjang; yang lain mungkin lebih tajam dalam edit bedah atau lebih cepat pada iterasi singkat. Tapi versi jujurnya begini: mereka berbeda di basis kode Anda, dan satu-satunya cara untuk mengetahuinya adalah mengamati mereka bekerja di sana. Benchmark mengukur sekumpulan masalah tetap pada momen yang tetap, yang bukan repositori Anda dan bukan bulan depan. Bandingkan agen di basis kode Anda sendiri sebelum Anda memercayai sebuah peringkat.
Jadi lakukan routing berdasarkan bentuk tugas terlebih dahulu. Sebuah pasangan keputusan untuk menjadi patokan: gunakan agen interaktif yang cepat saat tugasnya kecil, cakupannya jelas, dan Anda akan mengawasinya; pilih agen yang lebih otonom saat tugasnya cukup besar sehingga Anda lebih memilih mendeskripsikannya sekali lalu meninjau hasilnya ketimbang mengawal setiap langkah.
| Bentuk tugas | Arahkan ke | Alasan |
|---|---|---|
| Kecil, cakupannya jelas, Anda mengawasi | Agen interaktif tercepat Anda | Overhead rendah, iterasi ketat |
| Besar, multi-langkah, deskripsikan sekali | Agen otonom paling andal Anda | Ia merencanakan dan memeriksa sendiri tanpa pengawasan |
| Menyentuh file yang sedang dibuka agen lain | Agen mana pun, di worktree terisolasi | Menghindari tabrakan merge |
| Berisiko tinggi atau tidak dapat dikembalikan | Agen yang outputnya Anda tinjau ketat, dengan izin yang sempit | Radius dampak, bukan kecepatan, yang dominan |
| Murah dan repetitif | Apa pun yang lebih disukai anggaran Anda | Batas biaya yang menentukan |
Tidak ada satu pun dari itu yang menyebut pemenang, karena memang tidak ada. Yang ada adalah kecocokan antara sebuah tugas dan perilaku agen yang teramati, dan kecocokan itulah yang menjadi dasar routing Anda.
Batasan yang menentukan routing sebelum kemampuan ikut menentukan
Dua batasan selalu mengalahkan kemampuan, dan keduanya soal koordinasi, bukan keahlian.
Yang pertama adalah tumpang tindih file. Lima agen mengedit satu repositori terdengar efisien sampai dua di antaranya menyentuh file yang sama dan Anda harus menyelesaikan konflik merge yang sengaja Anda ciptakan sendiri. Solusinya adalah isolasi: beri setiap tugas checkout-nya sendiri agar agen tidak bisa bertabrakan. Worktree agen coding, satu checkout per tugas membahas mekanismenya, dan menjalankan beberapa agen dalam satu repositori membahas apa yang rusak tanpa itu. Ketika dua tugas akan menyentuh file yang sama, rutenya bukan "agen yang lebih baik", melainkan "agen mana pun, di worktree terpisah."
Yang kedua adalah risiko. Tugas yang memigrasikan data, mengubah autentikasi, atau menulis ulang jalur kritis harus diarahkan ke tempat peninjauan Anda paling ketat dan izin agen paling sempit, terlepas dari agen mana yang secara teknis paling kuat. Agen meneliti, mengeksekusi, menguji, dan melaporkan. Manusia menetapkan arah, memberi wewenang, dan menerima hasilnya. Mengarahkan tugas berisiko ke agen tercepat berarti mengoptimalkan variabel yang salah.
Ketika routing di kepala Anda berhenti diskalakan
Dengan satu agen, tidak ada masalah routing. Dengan dua, Anda menyimpan tabelnya di kepala dan itu baik-baik saja. Masalahnya mulai muncul sekitar tiga agen dengan beberapa tugas terbuka: keputusan routing tidak punya tempat untuk bersandar selain memori jangka pendek Anda.
Anda tidak bisa mengingat agen mana yang mendapat tugas migrasi. Eksekusi yang sudah selesai tergulir ke atas terminal sebelum Anda sempat membacanya. Anda memutuskan ulang rute yang sama tiga kali karena tidak ada catatan bahwa Anda pernah memutuskannya sekali. Dua agen mengedit file yang sama karena tidak ada yang memberi tahu keduanya bahwa yang lain ada di sana. Semua itu bukan kegagalan agen. Itu biaya menyimpan tabel routing di kepala Anda sementara terminal terus bertambah. Terlalu banyak terminal adalah biaya nyata, dan routing adalah tempat biaya itu pertama kali muncul.
Di sinilah papan tugas layak dipertahankan, karena ia memindahkan keputusan routing keluar dari kepala Anda dan ke dalam catatan bersama. Sharkly melakukannya dengan tiga kata benda. Sebuah Task adalah unit kerja bersama. Sebuah Agent adalah peran yang terikat pada sebuah runtime, didefinisikan sekali sehingga keputusan routing menjadi dapat dipakai ulang alih-alih dibuat ulang di setiap terminal. Anda menetapkan sebuah Task ke sebuah Agent, dan eksekusi, penghambat, serta hasil kembali ke Task itu alih-alih tergulir menjauh. Anda melihat agen mana mengerjakan apa tanpa berpindah jendela, dan diff serta output tes menunggu peninjauan Anda di satu tempat. Menetapkan, melacak, dan meninjau pekerjaan agen adalah hal yang menggantikan permainan mengandalkan ingatan ini.
Anda tidak perlu semua ini untuk menjalankan satu agen dengan baik. Anda juga bisa menjalankan Claude Code dan Codex bersamaan di satu basis kode secara manual, dan untuk dua agen itu wajar. Persamaannya berubah ketika keputusan routing melebihi apa yang bisa Anda simpan di kepala: banyak agen, banyak tugas, banyak repositori, sebuah tim yang perlu melihat papan yang sama.
Daftar periksa routing yang bisa Anda jalankan hari ini
Sebelum Anda menyerahkan sebuah tugas ke agen, lewati dulu hal-hal berikut:
- Sebutkan bentuk tugasnya. Perbaikan satu file, refactor, fitur baru, tes, atau dokumentasi? Ini menetapkan radius dampaknya.
- Periksa seberapa mudah dikembalikan. Sulit dibatalkan? Arahkan ke peninjauan terketat dan izin tersempit, bukan ke agen tercepat Anda.
- Periksa tumpang tindih file. Apakah agen lain sudah ada di file-file ini? Jika ya, isolasikan dulu tugas ini di worktree-nya sendiri.
- Cocokkan horizon otonominya. Singkat dan diawasi, atau panjang tanpa pengawasan? Arahkan ke agen yang perilakunya cocok di repositori Anda.
- Tetapkan batas biayanya. Putuskan langganan atau anggaran mana yang menanggung eksekusi itu.
- Catat rutenya di tempat bersama. Lewat dari dua agen, tuliskan di tempat yang bisa Anda dan tim Anda lihat: sebuah Task, bukan terminal yang akan Anda tutup.
- Kembalikan hasilnya ke satu tempat. Diff, output tes, dan peninjauan harus kembali ke catatan tugas, bukan berserakan di berbagai jendela.
Lakukan routing berdasarkan tugasnya, bukan peringkatnya. Agen terbaik untuk sebuah tugas adalah agen yang bentuknya cocok dengan pekerjaan di depan Anda, dan keputusan routing hanya tetap murah jika ia bersandar di tempat yang bisa Anda lihat.
Jika Anda sudah menjalankan beberapa agen coding, Sharkly memberi Anda satu tempat untuk merutekan tugas-tugas mereka dan membaca hasilnya. Anda bisa mengunduh Sharkly dan menghubungkan agen yang Anda gunakan.
FAQ
Apakah routing sama dengan memilih agen coding terbaik? Tidak. Memilih agen terbaik adalah penilaian sekali pakai yang cepat usang. Routing adalah memutuskan agen mana yang menangani setiap tugas, berdasarkan bentuknya, risikonya, tumpang tindih file, dan horizon otonominya. Anda melakukan routing puluhan kali untuk setiap satu kali Anda memilih.
Apa bedanya dengan memilih model? Memilih model terjadi satu lapis di bawahnya, di dalam agen. Routing memutuskan agen mana yang mendapat tugas; pertanyaan model memutuskan apa yang berjalan di dalam sesi agen tersebut. Lihat model mana untuk tugas coding mana untuk keputusan yang lebih sempit ini.
Kapan saya benar-benar butuh alat untuk ini? Ketika keputusan routing melebihi apa yang bisa Anda lacak di kepala, biasanya sekitar tiga agen dengan beberapa tugas terbuka, atau ketika sebuah tim perlu melihat keputusan yang sama. Untuk satu atau dua agen, tabel di kepala dan terminal terpisah sudah cukup.
Apakah Sharkly menggantikan Claude Code atau Codex? Tidak. Sharkly bukan pengganti Claude Code, Codex, atau alat eksekusi lainnya. Ia menambahkan lapisan task, Computer, konteks, dan peninjauan bersama di sekitar agen coding yang sudah dipakai tim Anda.
