Verdict Cepat: Tool coding AI sekarang bukan cuma asisten yang kasih saran satu baris. Beberapa proyek open source membiarkan pengguna menjalankan “tim kecil” di laptop sendiri, lengkap dengan perencana, coder, dan reviewer yang kerja berurutan. Semua jalan di mesin lokal, pakai langganan AI yang sudah dimiliki. Artikel ini bedah tiga opsi dan cara mulai tanpa kirim kode ke server pihak lain.
Setahun lalu, kalau mau bikin fitur pakai AI, pilihan praktisnya cuma dua: autocomplete di dalam editor, atau kirim prompt ke layanan cloud lalu salin hasilnya balik ke repo. Dua opsi itu masih ada dan berguna. Tapi muncul gelombang tool baru yang posisinya di tengah: agentic harness. Ia bukan chatbot, bukan juga pustaka untuk menyusun graf agent sendiri. Ia adalah sistem siap pakai yang mengambil daftar tugas, lalu menjalankan loop coder, reviewer, dan tester sampai tugas selesai dan siap di-merge.
Autocomplete menunggu pengguna mengetik, lalu menebak baris berikutnya. Ia tidak tahu konteks tugas luas. Agentic harness sebaliknya memegang daftar tugas, memutuskan urutan, dan menjalankan langkah sampai selesai. Konsep ini berbeda dari panduan Claude Code CLI untuk pemula yang fokus ke satu agen di terminal. Ia bisa buka branch sendiri, tulis kode, jalankan test, lalu minta reviewer memeriksa diff. Campur tangan manusia terjadi di titik keputusan, bukan di setiap baris.
Perbedaan kedua ada di lokasi eksekusi. Banyak tool sejenis ini berjalan di mesin pengguna sendiri. Kode tidak harus keluar ke server penyedia. Hal ini penting bagi siapa pun yang menangani repo klien atau data sensitif. Arsitekturnya memang dibuat lokal, bukan cuma pengaturan privasi tambahan.
Perbedaan ketiga ada di biaya. Sebagian harness memakai CLI langganan yang sudah dibayar, seperti Claude Code atau Codex. Ia menjalankan proses tersebut sebagai sub-proses, bukan memanggil API metered per token. Jadi tagihan Anthropic atau OpenAI tetap satu, tanpa markup per kursi dari layanan ketiga.
Poin penting: harness tidak menggantikan proses berpikir pemilik repo. Ia mengeksekusi tugas yang sudah dirumuskan jelas. Semakin tajam deskripsi tugas, semakin akurat hasil akhirnya. Alat ini memindahkan kerja mekanis ke mesin, bukan mengambil alih keputusan produk.
Shreni adalah contoh harness lokal yang ringkas. Ia membentuk tim agent: satu orchestrator mengawasi daftar tugas, satu coding agent menulis implementasi dan unit test, satu reviewer agent memeriksa hasil terhadap kriteria terima, lalu test agent menambah coverage. Seluruh alur berjalan tanpa campur tangan di dalamnya. Arahan diberikan lewat hasil: verdict review, health gate yang menolak build rusak, dan commit yang sudah merge.
Keunikan Shreni ada di kebijakan merge. Ia menjawab pertanyaan menakutkan sejak awal: apakah bot boleh push ke main? Pemilik repo yang tentukan. Mode auto-merge cocok untuk loop solo berisi kepercayaan tinggi. Mode PR gate cocok untuk tim yang ingin tanda tangan manusia sebelum merge. Keduanya tetap mewajibkan review otomatis coder dan reviewer lolos dulu.
Sisi praktisnya: Shreni butuh satu provider CLI yang sudah terautentikasi, GitHub CLI (gh) untuk membuka PR, dan Node 20 ke atas. Orchestrator-nya memeriksa proyek setiap 30 detik. Saat tugas siap dan dependensi terpenuhi, loop coder dan reviewer berjalan hingga disetujui atau ditandai untuk pemilik. Recovery juga ada: kalau mesin mati tengah jalan, status tugas dipulihkan bersih.
Kalau Shreni terasa seperti tim kecil, Karajan lebih mirip pabrik peran. Ia menjalankan pipeline hingga 24 tahap dengan berbagai peran: triage yang mengklasifikasi kompleksitas, coder yang menulis test dulu sebelum implementasi, reviewer dengan profil ketat, security audit OWASP, hingga supervisor bernama Solomon yang menilai setiap penolakan reviewer.
Salah satu fitur kuat Karajan adalah TDD secara default. Framework test terdeteksi otomatis untuk 12 bahasa, mulai vitest, jest, JUnit, pytest, hingga go test. Ia juga bisa memulai SonarQube di container Docker sendiri untuk static analysis. Artinya quality gate masuk ke alur, bukan sekadar pemikirian belakangan.
Karajan berjalan sebagai MCP server di dalam agent AI, atau langsung lewat CLI. Ukurannya kecil, sekitar 5 MB untuk base CLI. Komponen berat seperti Ollama untuk RAG lokal atau SonarQube hanya ditarik kalau diminta. Multi-provider routing memungkinkan Claude jadi coder dan Codex jadi reviewer, atau kombinasi lain sesuai selera.
Forge mengambil sudut berbeda: ia bukan asisten, melainkan runtime engineering. Ia membawa scheduler sendiri, sandbox, sistem permission, state machine, agentic loop, dan plugin ecosystem dalam satu CLI Node. Pemilik yang pilih modelnya, baik lewat Ollama, LM Studio, vLLM, llama.cpp, maupun model cloud opsional. Semuanya bisa diperiksa dan diputar ulang.
Forge mendukung 9 mode eksplisit, masing-masing membawa budget yang bisa dipaksa: jumlah maksimal executor turn, maksimal validation retry, allowMutations, hingga maxAutoRisk. Tiap aksi diklasifikasikan berdasar risiko, side-effect, dan sensitivitas, lalu digate oleh permission system. Cold-start forge doctor hanya 173 milidetik, dan UI shell-nya satu file JavaScript 90 KB tanpa CDN.
Untuk tim yang ingin kontrol penuh, Forge cocok karena tidak ada telemetry dan tidak ada phoning home. Seluruh stack didapat. Kelemahannya: setup awal lebih berat dibanding harness yang cuma butuh satu CLI terautentikasi. Tapi untuk eksperimen model lokal di berbagai hardware, fleksibilitasnya tinggi.
| Aspek | Shreni | Karajan | Forge |
|---|---|---|---|
| Fokus utama | Tim agent lokal task-driven | Orchestrator pipeline peran | Runtime engineering lokal |
| Model yang dipakai | Provider CLI (Claude default) | Multi-provider routing | Ollama sampai cloud opsional |
| Kebijakan merge | Auto-merge atau PR gate | Committer opsional | Permission per aksi |
| Quality gate | Reviewer + test agent | SonarQube + TDD + OWASP | Mode dengan budget terikat |
| Setup awal | Ringan (1 CLI + gh) | Sedang (Node + Docker opsional) | Lebih berat (runtime lengkap) |
| Cocok untuk | Solo dev dan tim kecil | Tim yang peduli mutu kode | Eksplorasi model lokal |
Langkah pertama, pilih satu harness yang paling dekat dengan kebutuhan. Solo dev yang ingin leverage tanpa serah repo ke layanan hosted bisa mulai dari Shreni di mode PR. Tim yang peduli mutu kode dan ingin TDD plus audit keamanan otomatis lebih cocok dengan Karajan. Eksplorator model lokal dengan berbagai hardware lebih tertarik ke Forge.
Langkah kedua, siapkan provider CLI yang sudah terautentikasi. Shreni butuh ANTHROPIC_API_KEY dan gh terautentikasi. Karajan butuh agent CLI terpasang lalu auto-detect saat init. Forge butuh satu sumber model, minimal Ollama lokal atau API key cloud. Jangan lewat dari langkah ini, karena harness tidak menyediakan model untuk pemakai.
Langkah ketiga, mulai dari tugas kecil. Jangan langsung suruh agent menulis fitur besar. Beri tugas seperti “perbaiki fungsi validasi ini dan tambah test” supaya cara reviewer bekerja dan cara merge gate berlaku terlihat. Setelah percaya, naikkan ke refactor modul atau fitur baru di branch terpisah.
Langkah keempat, tetapkan kebijakan merge sejak awal. Tim kecil berisi kepercayaan tinggi boleh auto-merge. Tim dengan orang lain sebaiknya pakai PR gate supaya ada tanda tangan manusia. Kebijakan ini mengubah seberapa sering campur tangan diperlukan.
Kesalahan pertama: memberi tugas terlalu luas di hari pertama. Agent bisa mengejutkan, tapi tanpa batas ia akan membuat keputusan arsitektur yang tidak disetujui. Mulai sempit, lalu perluas saat loop sudah terbukti.
Kesalahan kedua: abaikan health gate. Beberapa harness menolak memulai tugas baru kalau build rusak. Bila base dibiarkan merah, antrean tugas akan stagnan. Pastikan base selalu hijau sebelum melempar tugas berikutnya.
Kesalahan ketiga: tidak mengatur permission. Forge dan harness lain punya sistem izin untuk file, shell, network, dan MCP. Beri izin rutin secara session, tapi pertanyakan aksi berisiko tinggi. Jangan nyalakan skip-permissions lalu tinggal tidur. Pola izin ini serupa dengan pembahasan di perbandingan OpenCode vs Claude Code.
Kesalahan keempat: mengira agent tahu konteks bisnis. Reviewer memeriksa kriteria teknis, bukan tujuan produk. Tulis acceptance criteria dengan jelas di tugas supaya hasilnya sesuai harapan, bukan cuma lulus test.
Tool ini masuk akal untuk solo dev yang ingin leverage tanpa menyerahkan codebase ke agent hosted. Arahkan repo, pilih mode PR, lalu biarkan ia buka pull request yang sudah direview untuk tim merge. CI, gate, dan mesin tetap milik pemakai.
Tool ini juga masuk akal untuk siapa pun yang mempelajari sistem multi-agent sungguhan. Shreni misalnya punya loop orchestrator, coder, reviewer, tester dengan recovery dan watchdog, plus 800 lebih test. Fork, instrument, dan pelajari. Ia bukan demo mainan, melainkan harness yang bisa dibaca.
Tool ini kurang pas kalau cuma butuh saran satu baris saat mengetik. Autocomplete tetap lebih cepat untuk kerja harian. Agentic harness menang saat ada tugas berulang yang bisa diantrekan menjadi PR, bukan potongan kode satu per satu. Untuk setup multi-agent tanpa tabrakan file, teknik git worktree untuk beberapa AI coding agent layak dipelajari.
Apakah kode keluar dari laptop? Pada harness lokal seperti Shreni dan Forge, arsitekturnya memang lokal. Kode tinggal di mesin, kecuali pemakai sendiri yang menghubungkan provider cloud. Karajan juga lokal-first dengan kunci dan mesin milik pemakai.
Apakah butuh API key sendiri? Ya. Harness tidak menyediakan model. Mereka menjalankan CLI atau runtime yang sudah diautentikasi. Itu sebabnya tagihan tetap satu, tanpa markup per kursi.
Apakah aman untuk tim? Aman kalau pakai PR gate dan izin ketat. Jangan nyalakan auto-merge untuk repo bersama sebelum trust terbangun. Biarkan review otomatis jalan, lalu manusia tanda tangan di akhir.
Tim agent coding lokal bukan pengganti programmer. Ia mengubah cara kerja: dari mengetik baris demi baris menjadi mengarahkan tim kecil yang mengerjakan antrean tugas di mesin sendiri. Pilih harness yang cocok, mulai dari tugas sempit, tetapkan kebijakan merge, dan biarkan quality gate bekerja. Hasilnya bukan keajaiban, melainkan alur kerja berulang yang bisa dipercaya karena seluruhnya berjalan di depan mata.
Silakan bagikan pengalaman di kolom komentar, terutama soal cara mengatur kebijakan merge dan permission.