Artikel
Jangan Asal Fan-out: Arsitektur Orkestrasi Empat Lapisan Claude Haiku 5.5 dalam Praktik
Claude Haiku 5.5 memang cepat dan murah, tetapi melempar semua tugas secara paralel ke model ini hanya akan memperbesar salah tafsir, bias evaluasi, dan risiko Supply Chain. Artikel ini membedah arsitektur bertingkat: Fable untuk pertimbangan, Opus untuk orkestrasi, Sonnet dan Haiku untuk implementasi, verifikasi CI, serta validasi Opus—sekaligus membahas tugas seperti apa yang benar-benar layak di-Fan-out.
· 7 menit baca
Claude Haiku 5.5 dirilis pada 7 Oktober 2026. Untuk prompt di bawah 100,000 tokens, harganya hanya seperdua puluh dari Sonnet 5.5, dan latensinya merupakan yang tercepat di antara generasi Claude saat ini.
Murah dan cepat sering kali menggoda kita untuk melakukan ini: memecah semua tugas coding, lalu melemparnya secara paralel ke sekumpulan Haiku sampai selesai.
Untuk tahap prototipe, cara ini mungkin masih berhasil. Namun begitu masuk ke lingkungan rekayasa produksi, Anda akan segera membentur tiga masalah:
- Model kecil tidak cocok menangani ambiguitas. Posisi resmi Haiku 5.5 adalah untuk tugas-tugas bervolume tinggi dengan latensi rendah seperti klasifikasi, ekstraksi, routing, dan subagent. Ketika kebutuhan masih mengandung ambiguitas bisnis dan membutuhkan konteks sistem secara menyeluruh, model ini sangat mudah menghasilkan output yang tampak lengkap, padahal sebenarnya salah arah.
- Membiarkan model memilih jawaban memicu bias evaluasi. Menyodorkan puluhan hasil ke model besar untuk dinilai membuatnya cenderung memilih versi yang "tampak rapi secara arsitektur", bukan versi yang logika dan eksekusinya benar-benar tepat.
- Hak akses membesar seiring bertambahnya jumlah Worker. Jika subagent paralel diizinkan memasang paket dependensi secara otomatis atau mengubah konfigurasi, membuka N Worker berarti menambah N celah potensial masuknya paket berbahaya.
Karena itu, saya beralih menggunakan Hierarchical Orchestration (orkestrasi bertingkat): setiap lapisan hanya mengerjakan apa yang menjadi keahliannya, dan kemampuan pemrosesan paralel Haiku hanya dipakai saat benar-benar dibutuhkan.
Kesimpulannya terlebih dahulu: Fable bertugas mematangkan konsep, Opus bertugas mendistribusikan tugas dan melakukan validasi, Sonnet menangani implementasi utama, sedangkan Haiku hanya mengerjakan tugas mekanis dan tugas eksplorasi yang bisa diverifikasi otomatis. Solusi kandidat harus lolos CI terlebih dahulu sebelum diserahkan ke model.
Arsitektur Empat Lapisan: Pertimbangan, Orkestrasi, Verifikasi, Validasi#
Input Kebutuhan
│
▼
[Lapisan Pertimbangan] Fable: Keputusan arsitektur, pemecahan tugas, Acceptance Criteria
│
▼
[Lapisan Orkestrasi] Opus Main Session: Hanya mendistribusikan, tidak memecah ulang
├─► Jalur A: Kompleks tapi batasannya jelas ──► Implementasi oleh Sonnet
├─► Jalur B: Tugas mekanis ──► Satu Haiku
├─► Jalur C: Eksplorasi, multi-solusi ──► Beberapa Haiku, masing-masing satu Git Worktree
│
▼
[Lapisan Verifikasi] Build, Type Check, Test, Benchmark (Jalur C hanya menyisakan 2–3 teratas)
│
▼
[Lapisan Validasi] Opus melakukan konvergensi berdasarkan Acceptance Criteria
Jika gagal, lakukan eskalasi: Haiku coba perbaiki 2 kali tetap gagal ➔ Sonnet ➔ Kembalikan ke Opus
Penempatan setiap model pada lapisannya ditentukan berdasarkan positioning resmi dan harganya. Berikut adalah angka dari dokumentasi resmi Anthropic per 8 Oktober 2026, dengan satuan harga dalam USD per satu juta token:
| Model |
Posisi Resmi |
Latensi |
Harga Input / Output |
| Claude Fable 5.1 |
Penalaran tingkat tinggi dan pekerjaan agentic berdurasi panjang |
Lebih lambat |
$10 / $50 |
| Claude Opus 5.5 |
Agentic coding berdurasi panjang dan pekerjaan berbasis pengetahuan |
Menengah |
$4 / $20 |
| Claude Sonnet 5.5 |
Kombinasi terbaik antara kecepatan dan kapabilitas |
Cepat |
$2 / $10 |
| Claude Haiku 5.5 |
Tugas klasifikasi, ekstraksi, routing, dan subagent bervolume tinggi dengan latensi rendah |
Paling cepat |
Mulai $0.10 / $0.50 |
Harga Haiku 5.5 terbagi dalam dua tier: saat prompt melebihi 100,000 tokens, harganya menjadi $0.50 / $2.50.
Lapisan Pertimbangan: Fable Bertanggung Jawab atas Keputusan Arsitektur dan Acceptance Criteria#
Tidak semua kebutuhan memerlukan Fable. Ini adalah lapisan termahal dan paling lambat; saya hanya menggunakannya saat kebutuhan masih ambigu, melibatkan integrasi lintas sistem, atau saat harus mengambil keputusan arsitektur inti.
Fable harus menghasilkan tiga hal:
- Desain solusi
- Pemecahan tugas
- Acceptance Criteria untuk setiap sub-tugas yang dapat diverifikasi melalui pengujian
Penalaran dan pemecahan tugas harus diselesaikan oleh lapisan yang sama. Lapisan yang mampu memikirkan blind spot sistem secara matang adalah satu-satunya lapisan yang bisa membagi sub-tugas dengan batasan yang bersih. Jika urusan arsitektur diserahkan ke A dan pemecahan tugas ke B, definisi antarmukanya biasanya akan menjadi kabur.
Tugas keamanan adalah pengecualian. Generasi model Claude saat ini dilengkapi dengan security classifier; ketika sebuah permintaan diblokir, model akan mengembalikan stop_reason: "refusal", sehingga pekerjaan keamanan yang sah pun berisiko salah diblokir. Classifier pada Fable 5.1 mencakup sebagian besar konten keamanan, dan dokumentasi resminya menyatakan bahwa model ini tidak dirancang khusus untuk ranah keamanan siber; sebaliknya, Opus 5.5 mengizinkan pencarian kerentanan di dalam source code. Oleh karena itu, untuk kebutuhan perbaikan celah keamanan, analisis tahap awal langsung saya serahkan ke Opus.
Lapisan Orkestrasi: Opus Hanya Mendistribusikan, Tidak Memecah Ulang#
Opus bertindak sebagai Main Session yang bertanggung jawab atas routing dan pembagian kerja. Lapisan ini tidak merombak arsitektur maupun melakukan pemecahan tugas untuk kedua kalinya.
- Jalur A, kompleks tetapi batasannya jelas: Tugas dengan logika rumit namun batasan antarmukanya sudah terdefinisi dengan jelas diserahkan ke Sonnet. Model ini adalah tulang punggung implementasi.
- Jalur B, tugas mekanis sederhana: Kode Boilerplate, penggantian nama variabel, penambahan unit test sederhana, dan pembaruan dokumentasi ditangani oleh satu Haiku.
- Jalur C, tugas eksplorasi dan optimasi: Tuning performa, eksplorasi berbagai pendekatan penulisan SQL atau Regex yang kompleks, serta investigasi Flaky Test barulah memicu Fan-out: kerahkan beberapa Haiku, masing-masing mencoba solusi berbeda di dalam Git Worktree yang terisolasi.
Jalur mana pun yang diambil, seluruh output harus masuk ke lapisan verifikasi.
Lapisan Verifikasi: Dahulukan Mesin, Baru Model#
Praktik yang sangat umum adalah melempar seluruh kode hasil generasi paralel ke Opus atau Sonnet, lalu memintanya melakukan review lewat prompt.
Masalahnya, saat membaca kode, model mudah terpikat oleh jawaban dengan format yang rapi dan deklarasi tipe data yang lengkap, padahal itu bukan jaminan kodenya lolos pengujian kasus batas. Oleh karena itu, solusi kandidat harus melewati tahap mesin terlebih dahulu:
- Build dan Type Check: bisa dikompilasi, tipe data valid
- Unit / Integration Tests: unit test dan integration test lolos
- Benchmark / Profiling: performa dan penggunaan memori terukur
Kode yang tidak lolos pengujian otomatis langsung dieliminasi. Untuk kandidat dari Jalur C, Opus hanya akan meninjau 2–3 kandidat teratas yang lolos pengujian dengan metrik terbaik, yang sekaligus menghemat context window dan token.
Lapisan Validasi: Konvergensi oleh Opus, Eskalasi jika Gagal#
Tahap akhir dilakukan oleh Opus yang mengonvergensikan hasil berdasarkan Acceptance Criteria dari lapisan pertimbangan. Jika Worker mengalami jalan buntu, proses dialihkan sesuai jalur eskalasi (Escalation Path):
- Jika Haiku gagal dan perbaikan otomatis selama 2 kali tetap tidak lolos, hentikan percobaan ulang.
- Alihkan penanganan ke Sonnet untuk melakukan perbaikan.
- Jika Sonnet juga tidak mampu memenuhi validasi, ini biasanya menandakan adanya kontradiksi dalam pemecahan tugas atau asumsi awal. Tugas dikembalikan ke Opus, lalu Opus yang memutuskan apakah perlu dikirim balik ke Fable untuk dipecah ulang.
Tiga Aturan Sebelum Masuk ke Lingkungan Produksi#
Jangan Asal Fan-out#
Tugas sederhana tidak memerlukan banyak Worker, sedangkan tugas yang sangat ambigu tidak akan bisa diselesaikan oleh model kecil. Hanya tugas eksploratif dengan "ruang solusi yang luas" dan "dapat diverifikasi secara cepat melalui pengujian otomatis" yang layak dijalankan secara paralel menggunakan banyak Haiku.
Isolasi Lingkungan, Kunci Lockfile#
Git Worktree mengisolasi perubahan kode agar Worker yang berjalan paralel tidak saling menimpa berkas; fitur ini tidak membatasi akses jaringan maupun jangkauan akses program. Untuk mencegah Supply Chain Attack, sandbox tetap diperlukan, disertai larangan bagi Worker untuk memasang paket yang belum ditinjau atau mengubah Lockfile secara mandiri. Membuka izin instalasi secara bebas sama saja dengan membiarkan Agent memasukkan paket dan skrip yang tidak jelas asal-usulnya ke dalam repositori.
Validasi Menggunakan Metrik Terukur, Bukan Komentar Model#
Hasil pengujian, coverage, konsumsi memori, dan latensi adalah dasar yang dapat direproduksi dan dibandingkan secara objektif. Komentar tekstual dari model boleh dijadikan referensi, tetapi tidak boleh dijadikan acuan tunggal untuk memvalidasi kualitas kode.
Gunakan Model Murah pada Tempat yang Tepat#
Haiku 5.5 membuat eksekusi paralel menjadi murah, tetapi pemrosesan paralel itu sendiri tidak otomatis membuat hasilnya benar. Pisahkan terlebih dahulu proses pertimbangan, orkestrasi, verifikasi, dan validasi; barulah efisiensi biaya dan kecepatan akan menjadi keunggulan yang nyata.
Skema bertingkat ini pada dasarnya adalah Graph yang saya bahas dalam AI Agent Sejatinya Adalah Tim Agile: siapa yang mengerjakan lebih dulu, kepada siapa hasilnya diserahkan setelah selesai, dan ke mana masalah dieskalasi saat terjadi kendala.