tunaFlow adalah klien desktop yang mengorkestrasi agen CLI seperti Claude, Codex, dan Gemini dalam satu aplikasi. Kami belum merilis ini secara publik dan saat ini sedang mengembangkannya sebagai proyek pengujian pribadi.
Seri ini berbagi pertimbangan teknis dan keputusan desain yang dihadapi selama proses tersebut. Kami harap ini bisa menjadi referensi 0.1 bagi mereka yang mengembangkan ke arah yang sama. Jika ada sanggahan, kalian semua benar. 😁
Artikel ini adalah bagian pertama dari seri ini (total 10+ bagian), yang membahas tentang "mengapa lapisan orkestrasi diperlukan".
---
## Bukankah Claude Code saja sudah cukup?
Jujur saja, Anda bisa melakukan banyak hal hanya dengan satu agen. Jika Anda membuka proyek di Claude Code dan berkata "buatkan ini", hasilnya cukup baik. Begitu juga dengan Codex dan Gemini CLI.
Namun ketika proyek menjadi sedikit lebih besar, situasi seperti ini muncul.
Saya: "Refaktor middleware autentikasi"
Claude: (langsung mulai menulis kode)
Saya: "Tunggu, mari kita desain dulu"
Claude: "Baik, saya usulkan desain berikut..." (sudah memodifikasi 3 file)
Saya: "Tolong review juga"
Claude: (mereview kode yang dia tulis sendiri) "Sepertinya sudah bagus ✅"
Mereview kode yang Anda tulis sendiri adalah hal yang sulit bahkan untuk manusia. Hal yang sama berlaku untuk agen. Sulit untuk memberikan review objektif karena konteks dan penilaian pribadi sudah tertanam di dalamnya.
Ini bukan masalah kemampuan agen, melainkan ketiadaan proses. Tidak ada struktur yang menerapkan proses pengembangan dasar seperti desain → implementasi → review → perbaikan pada agen.
Kesadaran masalah ini terinspirasi besar dari artikel blog Stavros Korokithakis. Saat melihat alur kerja yang secara alami terbentuk saat mengerjakan proyek dengan Claude Code—alur kerja di mana rencana ditetapkan lebih dulu (opus), disetujui, kemudian diimplementasikan (sonnet), dan hasilnya direview (codex)—saya berpikir "bukankah alat harus mendukung ini?" Itulah yang menjadi titik awal dari pipeline alur kerja orkestrasi tunaFlow.
---
## Jadi kami membuat: Lapisan Orkestrasi
tunaFlow bukan membuat agen sendiri, melainkan mengoordinasikan agen yang sudah ada (Claude Code, Codex, Gemini CLI, dll) dalam suatu proses.
Penggunaan umum:
Pengguna ↔ Claude Code (percakapan 1:1)
tunaFlow:
Pengguna ↔ tunaFlow ↔ Claude Code Opus (peran Arsitektur)
↔ Claude Code sonnet (peran Pengembang)
↔ Codex 5.4 (peran Reviewer)
↔ Gemini (peserta diskusi RT atau hakim buta)
Inti dari konsep ini adalah bukan memperbaiki agen itu sendiri, melainkan menciptakan proses bagi agen untuk bekerja.
### Mengapa tidak membuat agen sendiri
tunaFlow tidak memanggil LLM API secara langsung. Kami memanggil Claude Code CLI, Codex CLI, dan Gemini CLI sebagai subprocess.
// Kode sebenarnya (claude.rs)
let mut cmd = Command::new("claude");
cmd.arg("-p")
.arg(&input.prompt)
.arg("--output-format").arg("stream-json")
.arg("--model").arg(model);
Dengan cara ini, kami dapat memanfaatkan fitur-fitur yang dimiliki setiap CLI (pengeditan file, eksekusi terminal, integrasi MCP, dll) sepenuhnya. Jika memanggil API secara langsung melalui SDK, kami hanya bisa mengobrol, sementara mengubah file atau menjalankan tes harus diimplementasikan sepenuhnya sendiri.
Ada trade-off. Metode CLI subprocess berarti kami tidak bisa melihat ke dalam agen. Sulit mengetahui tool apa yang dipanggil atau apa yang dipikirkan di tengah proses (meskipun sedikit terlihat). Sebagai gantinya, kami mendapatkan semua fitur setiap CLI secara gratis.
---
## Arsitektur apa itu
Struktur keseluruhan tunaFlow seperti ini.
┌─ Desktop App (Tauri 2) ──────────────────────────────┐
│ │
│ React Frontend ←──Tauri IPC──→ Rust Backend │
│ ├── Chat (percakapan utama) ├── Agent Adapters │
│ ├── Workflow (Plan/Review) │ ├── claude.rs │
│ ├── Branch (pemisahan percak.) │ ├── codex.rs │
│ ├── RT (diskusi agen) │ ├── gemini.rs │
│ ├── Artifacts (hasil kerja) │ ├── openai_compat│
│ └── Trace (pelacakan eksekusi) │ └── ... │
│ ├── ContextPack │
│ ├── SQLite (WAL) │
│ └── rawq, CRG │
└──────────────────────────────────────────────────────┘
↓ subprocess
┌─────────┬──────────┬──────────┐
│ claude │ codex │ gemini │ ← setiap agen CLI
└─────────┴──────────┴──────────┘
Aplikasi desktop yang dibangun di atas Tauri 2 dengan React + Rust. Saat ini berskala Rust 25.894 baris, TypeScript 24.419 baris, 406 tes (Rust 230 + Frontend 176).
### 5 Fitur Inti
Kami akan memperkenalkan killer feature tunaFlow secara singkat. Masing-masing akan dibahas secara detail di bagian selanjutnya dari seri ini.
1. Pipeline Alur Kerja (→ detail di bagian 2)
Chat → Naik Rencana → Persetujuan Pengguna → Eksekusi Developer → Review RT → Selesai
↑ orang ↑ orang
Arsitektur membuat Rencana, pengguna menyetujui, Developer mengimplementasikan, Reviewer memvalidasi. Hal penting di sini adalah titik persetujuan sangat jelas. Bukan struktur di mana agen melakukan segalanya sendiri. (Jika melakukan semuanya sendiri, akan ada masalah besar 😇)
2. Branch (pemisahan percakapan) (→ detail di bagian 3)
Memisahkan dari tengah percakapan untuk bereksperimen secara independen, dan jika hasilnya bagus, gabungkan kembali ke percakapan utama. Konsep yang mirip dengan git branch diterapkan pada percakapan.
3. Roundtable (diskusi agen) (→ detail di bagian 4)
Beberapa agen berdiskusi tentang topik yang sama. Claude, Codex, dan Gemini masing-masing memberikan pendapat, dan pengguna membuat keputusan. Kesepakatan bukan dari agen, tetapi dari manusia.
4. ContextPack (perakitan konteks) (→ lihat postingan yang sudah diterbitkan)
Setiap permintaan, kami merakit informasi yang dibutuhkan agen (informasi proyek, rencana, hasil pencarian kode, memori jangka panjang, dll) dan mengirimkannya. 4 mesin menerima konteks dengan kualitas yang sama.
5. Sistem Jaminan Kualitas (→ detail di bagian 9)
Jika agen mengulangi kesalahan yang sama, sistem secara otomatis mendeteksi dan melakukan eskalasi. Jika review gagal 5 kali, kami memberitahu orang "sepertinya perlu meninjau desain dari awal".
---
## "Human with Agent" — Manusia membuat keputusan, agen melaksanakan
Filosofi desain tunaFlow dapat dirangkum dalam satu kalimat.
> Manusia menentukan arah, dan agen melaksanakan keputusan itu dalam kondisi optimal.
Bukan "agen melakukan segalanya untuk Anda". Agen sangat baik dalam eksekusi, tetapi memutuskan apa yang harus dilakukan masih lebih baik dilakukan manusia. Terutama dalam bidang berikut:
- Keputusan arsitektur: Data pelatihan agen mencakup pola baik dan buruk yang tercampur
- Apa yang tidak dilakukan: Agen tidak pandai mengatakan "Tidak". Jika diminta, hampir selalu melakukannya
- Penilaian dalam konteks keseluruhan: Agen hanya melihat konteks percakapan saat ini. Konteks bisnis, situasi tim, jadwal—agen tidak tahu ini
Itulah mengapa di setiap titik kritis tunaFlow ada gerbang di mana manusia terlibat.
Persetujuan Rencana: "Mau ke arah ini?" → Pengguna setuju/tolak/minta revisi
Penilaian Review: "Hasil review:" → Pengguna konfirmasi akhir
Penilaian Roundtable: "Hasil diskusi:" → Pengguna lanjutkan/akhiri/putuskan
Penilaian Rework: "Gagal 3 kali:" → Pengguna ubah arah
Ini adalah perbedaan mendasar dengan "agen melakukan segalanya secara otomatis". Kecepatannya sedikit lebih lambat, tetapi kami dapat menghindari berlari ke arah yang salah. (Namun jika kecerdasan manusia berlari ke arah yang salah, tidak ada yang bisa dilakukan)
---
## Arsitektur Mesin: Satu juga bisa, banyak juga bisa
tunaFlow dapat menggabungkan mesin (agen) mulai dari minimal 1 hingga maksimal 4-5.
Konfigurasi | Mesin | Biaya |
Pemula | Claude (Pro) | $20/bulan |
Dasar | Claude (Pro) + Codex(Plus) | $40/bulan |
Lengkap | Claude (Pro / Max) + Codex(Plus) + Gemini(Pro) | $60(150~)/bulan |
Yang penting adalah seluruh alur kerja dapat berjalan hanya dengan Claude Pro seharga $20. Bahkan dengan model Claude Sonnet yang sama, kami dapat menjalankan Arsitektur/Developer/Reviewer, dan ContextPack serta Persona yang berbeda memisahkan peran.
Arsitektur: claude --model claude-sonnet-4-6 + Persona Arsitektur
Developer: claude --model claude-sonnet-4-6 + Persona Developer
Reviewer: claude --model claude-sonnet-4-6 + Persona Reviewer
→ Model yang sama tetapi prompt berbeda per peran sehingga perilaku berbeda
Tentu saja, memisahkan mesin lebih baik. Jika Claude merancang dan Codex mengimplementasikan, masing-masing dapat memanfaatkan kekuatan mereka, dan biaya juga terdistribusi. Namun menurunkan hambatan masuk juga penting.
---
## Yang Telah Kami Pelajari Sejauh Ini
Beberapa kesimpulan sementara yang kami dapatkan saat membuat tunaFlow.
### 1. Kualitas konteks lebih penting daripada kualitas model
> "A lot of apparent 'model quality' is really context quality." — Sebastian Raschka
Bahkan dengan model dan pertanyaan yang sama, hasilnya berbeda jauh tergantung pada konteks apa yang Anda sertakan. Jika Anda merakit ContextPack dengan baik, Sonnet dapat memberikan hasil yang lebih baik daripada Opus yang diberikan dengan asal-asalan. Ini bukan berlebihan, tetapi pengalaman nyata yang kami alami berkali-kali.
### 2. Otomasi dan otonomi adalah hal yang berbeda
Mengotomatiskan alur kerja dan memberikan otonomi kepada agen adalah hal yang berbeda. tunaFlow mengotomatisasi proses, tetapi penilaian tetap dari manusia. Persetujuan Rencana, Penilaian Review, Keputusan Rework—manusia terlibat di ketiga titik ini.
Awalnya saya berpikir "bukankah seluruhnya otomatis lebih baik?", tetapi masalah segera terbukti dalam penggunaan nyata. Jika agen berlari ke arah yang salah, biaya untuk mengembalikan jauh lebih besar daripada memiliki orang yang memeriksa dari awal.
### 3. Agen harus diberikan proses
Claude Code tidak kurang mampu. Claude Code sangat pandai menjalankan alat. Yang kurang adalah proses. Struktur yang menerapkan alur pengembangan dasar pada agen: desain → persetujuan → implementasi → review → perbaikan.
Memberikan model yang lebih baik kepada agen mengubah hasil lebih sedikit daripada memberikan proses yang lebih baik.
---
## Keterbatasan
Jujur saja, masih banyak keterbatasan.
- Keterbatasan metode CLI subprocess: Kami tidak bisa mengamati tool call di dalam agen. Kami hanya bisa memperkirakan dari stdout/stderr apa yang sedang dilakukan
- Biaya token: Jika banyak menggunakan multi-agen, biaya naik dengan cepat. Jika 3 orang berdiskusi 2 ronde, sekali saja sekitar ~30K token
- Overhead proses: Bahkan untuk perubahan kecil, harus melalui Plan → Setuju → Dev → Review mungkin berlebihan. Diperlukan fleksibilitas untuk melewati proses tergantung situasi
- Keterbatasan kesepakatan RT: Bahkan jika agen berdiskusi, "kesepakatan" sejati tidak sering terjadi. Pada akhirnya manusia harus mengoordinasikan
Bagaimana kami mengatasi keterbatasan ini (atau masih belum bisa) akan dibahas di bagian-bagian selanjutnya dari seri ini.
---
## Arah Selanjutnya: Meta-agen
Saat ini, manajemen proses di tunaFlow dilakukan oleh pengguna. "Apa yang harus dilakukan selanjutnya", "Apakah akan Rework atau mengubah arah", "Agen mana yang cocok"—orang membuat penilaian ini.
Ke depannya, kami berencana memperkenalkan meta-agen yang membantu manajemen proses itu sendiri. Namun ada pembedaan penting di sini. Meta-agen bukan atasan Arsitektur.
- Arsitektur merancang "bagaimana cara membuatnya" (dekomposisi teknis)
- Meta-agen menyarankan "apa yang harus dilakukan sekarang" (penilaian proses)
Sebagai contoh perbedaannya seperti ini.
Meta-agen: "Rasio Rework Plan terkait auth 40%.
Bagaimana kalau kita tinjau ulang desainnya?"
→ Analisis status proyek + saran prioritas
Arsitektur: "Saya akan mengubah middleware autentikasi ke OAuth2 PKCE.
Saya akan membaginya menjadi 3 subtask."
→ Desain teknis + dekomposisi
Meta-agen mungkin dapat menyarankan "tinjau ulang desain", tetapi benar-benar memodifikasi Rencana adalah tanggung jawab Arsitektur, dan menyetujui modifikasi itu adalah tanggung jawab manusia. Hanya saran saja. Keputusan dari manusia. Prinsip "Human with Agent" tunaFlow juga berlaku sama untuk meta-agen.
Diskusi detail tentang hierarki ini akan dibahas di bagian selanjutnya dari seri ini.
---
## Pratinjau Bagian Selanjutnya
Bagian 2: "Plan → Dev → Review" — Catatan Implementasi Pipeline Alur Kerja
Kami membahas keputusan desain dalam memisahkan peran agen menjadi Arsitektur/Developer/Reviewer, menambahkan gerbang persetujuan, dan membuat loop Rework. "Di mana titik keterlibatan manusia ditempatkan?" adalah kunci utamanya.
---
## Daftar Seri
1. Berikan Proses kepada Agen — Apa yang Dipelajari dari Membangun AOC (artikel ini)
2. Plan → Dev → Review — Catatan Implementasi Pipeline Alur Kerja
3. Memisahkan Percakapan — Desain dan Penggunaan Branch
4. Membuat Agen Berdiskusi — Desain dan Keterbatasan Roundtable
5. Ketika Percakapan Panjang — Catatan Implementasi Memori Jangka Panjang Agen
6. Menjalankan Alur Kerja dengan Claude $20 — Arsitektur Mesin
7. Memberitahu Agen Struktur Kode — rawq + code-review-graph
8. Dari 246 Keterampilan, Hanya yang Diperlukan — Catatan Implementasi Aplikasi Keterampilan Otomatis
9. Ketika Agen Mengulangi Kesalahan yang Sama — Desain Jaminan Kualitas
10. Memutar Siklus Lengkap dengan tunaFlow — Resensi Tes Alur Kerja Praktis
+ [Sudah Diterbitkan] ContextPack — Desain Konteks Pengorkestra Multi-agen
---
## Referensi
- Stavros Korokithakis — Alur kerja yang secara alami terbentuk saat mengerjakan proyek dengan Claude Code (Plan → persetujuan → implementasi → review) menjadi inspirasi fundamental untuk pipeline alur kerja orkestrasi tunaFlow.
https://www.stavros.io/posts/building-with-claude-code/
- Sebastian Raschka — "Components of a Coding Agent" (2025): Analisis 6 komponen inti agen coding. Sumber kutipan "model quality = context quality".
https://magazine.sebastianraschka.com/p/components-of-a-coding-agent
- Addy Osmani — "Orchestrating Coding Agents" (2025): Pola orkestrasi multi-agen, penskalaan, dan gerbang kontrol kualitas yang komprehensif.
https://addyosmani.com/blog/code-agent-orchestra/
- Dokumen internal tunaFlow
- CLAUDE.md — Dokumen penyerahan proyek (sesi saat ini 22, DB v30)
- docs/ideas/techPostSeriesIdea.md — Dokumen perencanaan seri
