OpenClaw + Claude Code Tutorial yang Sangat Kuat: Satu Orang Bisa Membangun Tim Pengembang Lengkap!

2/26/2026
10 min read

OpenClaw + Claude Code Tutorial yang Sangat Kuat: Satu Orang Bisa Membangun Tim Pengembang Lengkap!

Hari ini saya akan membagikan sebuah kasus praktik yang sangat mengesankan. (Tutorial ada di akhir)

Seorang pengembang independen, menggunakan OpenClaw + Codex/CC, telah membangun sebuah sistem AI Agent. Apa hasil yang dicapainya?

AI Agent sistem efek

Dalam satu hari, dia melakukan 94 kali pengiriman, menyelesaikan 7 PR dalam 30 menit, dan pada hari itu dia juga mengadakan 3 rapat dengan klien, tanpa pernah membuka editor.

Ini adalah kejadian nyata yang terjadi pada Januari 2026. Penulis telah mempublikasikan seluruh arsitektur sistem, alur kerja, dan konfigurasi kode, dan setelah melihatnya, saya merasa bahwa pemikiran ini sangat layak untuk dipelajari, jadi saya menyusunnya menjadi artikel ini untuk dibagikan kepada Anda.

Jika Anda juga menggunakan Codex atau Claude Code, atau tertarik dengan OpenClaw, artikel ini akan memberikan banyak inspirasi.

Satu Orang, 94 Pengiriman Kode dalam Satu Hari

Mari kita lihat beberapa data untuk merasakan kekuatan sistem ini:

  • Pengiriman tertinggi dalam satu hari adalah 94 kali (rata-rata 50 kali pengiriman per hari)
  • Menyelesaikan 7 PR dalam waktu 30 menit
  • Kecepatan dari ide hingga peluncuran sangat cepat sehingga bisa "mengirimkan kebutuhan klien pada hari yang sama"
Penulis menggunakan sistem ini untuk mengembangkan produk B2B SaaS yang nyata, bekerja sama dengan penjualan langsung dari pendiri, sebagian besar kebutuhan fungsional dapat diselesaikan dalam satu hari. Seberapa cepat? Ketika klien mengajukan permintaan, mereka dapat melihat hasilnya pada hari yang sama, langsung beralih menjadi pengguna berbayar.

Biaya? Setiap bulan $190 (Claude $100 + Codex $90), pemula bisa mulai dengan $20.

Anda mungkin bertanya: Apakah ini hanya menumpuk banyak alat AI, lalu menghasilkan kode sampah secara gila-gilaan?

Tidak. Riwayat Git penulis terlihat seperti "baru saja merekrut tim pengembang", tetapi sebenarnya hanya dia seorang. Perubahan kunci adalah: dia beralih dari "mengelola Claude Code" menjadi "mengelola seorang pengurus AI, yang kemudian mengelola sekelompok Claude Code".

  • Sebelum Januari: langsung menggunakan Codex atau Claude Code untuk menulis kode
  • Setelah Januari: menggunakan OpenClaw sebagai lapisan pengatur, membiarkannya menjadwalkan Codex/Claude Code/Gemini
Efek dari perubahan ini adalah: sistem dapat secara otomatis menyelesaikan hampir semua tugas kecil hingga menengah tanpa perlu campur tangan manusia.

Mengapa Codex dan Claude Code Sendiri Tidak Cukup Baik?

Saat ini, Anda mungkin berpikir: Codex dan Claude Code sudah sangat kuat, mengapa perlu menambahkan satu lapisan pengatur?

Jawaban penulis sangat langsung: Codex dan Claude Code hampir tidak tahu apa-apa tentang bisnis Anda. Mereka hanya melihat kode, tidak melihat gambaran bisnis secara keseluruhan.

Ada batasan mendasar di sini: jendela konteks adalah tetap, Anda hanya bisa memilih satu dari dua.

Anda harus memilih apa yang akan dimasukkan:

  • Penuh dengan kode → Tidak ada ruang untuk konteks bisnis
  • Penuh dengan sejarah klien → Tidak ada ruang untuk repositori kode
Jadi saat menggunakan Codex atau Claude Code secara terpisah, Anda akan menghadapi masalah ini:

  • Mereka tidak tahu fungsi ini untuk klien mana
  • Mereka tidak tahu mengapa permintaan serupa sebelumnya gagal
  • Mereka tidak tahu posisi produk dan prinsip desain Anda
  • Mereka hanya dapat bekerja berdasarkan kode saat ini dan prompt Anda
OpenClaw mengubah persamaan ini.

Ia berfungsi sebagai lapisan pengatur, berada di antara Anda dan semua alat AI. Perannya adalah:

  • Menyimpan semua konteks bisnis (data klien, catatan rapat, keputusan sejarah, kasus sukses/gagal)
  • Menerjemahkan konteks bisnis menjadi prompt yang tepat, diberikan kepada agen tertentu
  • Membiarkan agen-agen ini fokus pada apa yang mereka kuasai: menulis kode
Mari kita analogikan:

  • Codex/Claude Code = Koki profesional, hanya fokus memasak
  • OpenClaw = Koki utama, tahu selera klien, stok bahan, dan penempatan menu, memberikan instruksi yang tepat kepada setiap koki
Inilah mengapa sistem dua lapis diperlukan: melalui pembagian kerja yang profesional dalam konteks, bukan hanya mengganti model yang lebih kuat.

Arsitektur Sistem Dua Lapis yang Spesifik: Lapisan Pengatur + Lapisan Eksekusi

Mari kita lihat arsitektur spesifik dari sistem ini.双层系统架构

Dua tingkat, masing-masing menjalankan tugasnya:

OpenClaw架构图

Apa yang bisa dilakukan OpenClaw (Lapisan Orkestrasi)?

  • Membaca semua catatan rapat dalam catatan Obsidian (sinkronisasi otomatis)
  • Mengakses database produksi (izin baca saja) untuk mendapatkan konfigurasi pelanggan
  • Memiliki izin API administrator, dapat langsung mengisi ulang dan menghapus blokir untuk pelanggan
  • Memilih agen yang sesuai berdasarkan jenis tugas
  • Memantau kemajuan semua agen, jika gagal akan menganalisis penyebab dan menyesuaikan prompt untuk mencoba lagi
  • Setelah selesai, memberi tahu penulis melalui Telegram

Apa yang bisa dilakukan Agent (Lapisan Eksekusi)?

  • Membaca dan menulis repositori kode
  • Menjalankan pengujian dan membangun
  • Mengirimkan kode dan membuat PR
  • Menanggapi umpan balik dari tinjauan kode
Poin kunci: Agent di lapisan eksekusi tidak pernah mengakses database produksi dan tidak akan melihat informasi sensitif pelanggan. Mereka hanya mendapatkan "konteks minimum yang perlu diketahui untuk menyelesaikan tugas ini".

安全边界

Desain ini sangat cerdas: batas keamanan jelas, sambil memastikan efisiensi.

Alur Kerja Lengkap: 8 Langkah dari Permintaan Pelanggan hingga Penggabungan PR

Sekarang kita masuk ke bagian inti. Menggunakan kasus nyata penulis minggu lalu, saya akan membawa Anda melalui proses lengkap.

Latar belakang: Seorang pelanggan perusahaan menelepon, mengatakan mereka ingin dapat menggunakan kembali pengaturan yang telah mereka konfigurasi dan berbagi di dalam tim.

Langkah 1: Permintaan Pelanggan → OpenClaw Memahami dan Menguraikan

Setelah panggilan selesai, penulis dan Zoe (OpenClaw-nya) berbicara tentang permintaan ini.

Keajaiban di sini: biaya penjelasan nol. Karena semua catatan rapat disinkronkan secara otomatis ke Obsidian, Zoe sudah membaca isi panggilan, tahu siapa pelanggan, skenario bisnis mereka, dan konfigurasi yang ada.

Penulis dan Zoe bersama-sama menguraikan permintaan menjadi: membuat sistem template, agar pengguna dapat menyimpan dan mengedit konfigurasi yang ada.

Kemudian Zoe melakukan tiga hal:

  • Mengisi ulang pelanggan — menggunakan API administrator untuk segera menghapus batasan penggunaan pelanggan
  • Mengambil konfigurasi pelanggan — mendapatkan pengaturan yang ada dari database produksi (baca saja)
  • Menghasilkan prompt dan memulai agen — mengemas semua konteks dan memberikannya ke Codex

Langkah 2: Memulai Agen

Zoe membuat untuk tugas ini:

  • Sebuah git worktree independen (lingkungan cabang terisolasi)
  • Sebuah sesi tmux (agar Agent berjalan di latar belakang)
# 创建 worktree + 启动代理 git worktree add ../feat-custom-templates -b feat/custom-templates origin/main cd ../feat-custom-templates && pnpm install

tmux new-session -d -s "codex-templates" \ -c "/Users/elvis/Documents/GitHub/medialyst-worktrees/feat-custom-templates" \ "$HOME/.codex-agent/run-agent.sh templates gpt-5.3-codex high Kenapa menggunakan tmux? Karena bisa melakukan intervensi di tengah jalan.

Jika AI menyimpang, tidak perlu membunuh dan memulai lagi, cukup kirim perintah di tmux:

# 代理方向错了 tmux send-keys -t codex-templates "停一下。先做 API 层,别管 UI。" Enter

代理需要更多上下文

tmux send-keys -t codex-templates "类型定义在 src/types/template.ts,用那个。" Enter Sementara itu, tugas akan dicatat dalam sebuah file JSON:[[HTMLPLACEHOLDER0]] [[HTMLPLACEHOLDER1]] [[HTMLPLACEHOLDER2]] [[HTMLPLACEHOLDER3]] [[HTMLPLACEHOLDER4]] [[HTMLPLACEHOLDER5]] [[HTMLPLACEHOLDER6]] [[HTMLPLACEHOLDER7]] [[HTMLPLACEHOLDER8]] [[HTMLPLACEHOLDER9]] [[HTMLPLACEHOLDER10]] [[HTMLPLACEHOLDER11]] [[HTMLPLACEHOLDER12]] [[HTMLPLACEHOLDER13]] [[HTMLPLACEHOLDER14]] [[HTMLPLACEHOLDER15]] [[HTMLPLACEHOLDER16]] [[HTMLPLACEHOLDER17]] [[HTMLPLACEHOLDER18]] [[HTMLPLACEHOLDER19]] [[HTMLPLACEHOLDER20]] [[HTMLPLACEHOLDER21]] [[HTMLPLACEHOLDER22]] [[HTMLPLACEHOLDER23]] [[HTMLPLACEHOLDER24]] [[HTMLPLACEHOLDER25]] [[HTMLPLACEHOLDER26]] [[HTMLPLACEHOLDER27]] [[HTMLPLACEHOLDER28]]Proses lengkap berjalan dari kebutuhan pelanggan hingga kode diluncurkan, mungkin hanya memakan waktu 1-2 jam, sementara investasi aktual penulis mungkin hanya 10 menit.

Tiga Mekanisme untuk Membuat Sistem Lebih Cerdas

Mekanisme 1: Ralph Loop yang Ditingkatkan — Tidak Hanya Mengulangi, Tapi Belajar

Anda mungkin pernah mendengar tentang Ralph Loop: menarik konteks dari memori → menghasilkan output → mengevaluasi hasil → menyimpan pembelajaran.

Namun, sebagian besar implementasi memiliki satu masalah: prompt yang digunakan setiap kali siklus adalah sama. Apa yang dipelajari meningkatkan pencarian di masa depan, tetapi prompt itu sendiri bersifat statis.

Sistem ini berbeda.

Ketika Agent gagal, Zoe tidak akan memulai ulang dengan prompt yang sama. Dia akan membawa konteks bisnis yang lengkap, menganalisis alasan kegagalan, lalu menulis ulang prompt:

❌ Contoh Buruk (prompt statis): { "Implementasikan fungsi template kustom" }

✅ Contoh Baik (penyesuaian dinamis): { "Berhenti. Apa yang diminta pelanggan adalah X, bukan Y. Ini adalah kata-kata mereka dalam rapat: Kami ingin menyimpan konfigurasi yang ada, bukan membuat yang baru dari awal. Fokus pada penggunaan kembali konfigurasi, jangan buat proses baru." }Zoe dapat melakukan penyesuaian ini karena dia memiliki konteks yang tidak dimiliki oleh Agent:

  • Apa yang dikatakan pelanggan dalam rapat
  • Apa yang dilakukan perusahaan ini
  • Mengapa permintaan serupa sebelumnya gagal
Lebih jauh lagi, Zoe tidak akan menunggu Anda untuk menetapkan tugas, dia akan proaktif mencari pekerjaan:

  • Pagi: memindai Sentry → menemukan 4 kesalahan baru → memulai 4 Agent untuk menyelidiki dan memperbaiki
  • Setelah rapat: memindai catatan rapat → menemukan 3 permintaan fitur yang disebutkan pelanggan → memulai 3 Codex
  • Malam: memindai git log → memulai Claude Code untuk memperbarui changelog dan dokumentasi pelanggan
Penulis kembali dari berjalan-jalan, Telegram menunjukkan: "7 PR sudah siap. 3 fitur baru, 4 perbaikan bug."

Polanya yang berhasil akan dicatat:

  • "Struktur prompt ini sangat efektif untuk fungsi tagihan"
  • "Codex perlu mendapatkan definisi tipe sebelumnya"
  • "Selalu harus menyertakan jalur file pengujian"
Sinyal penghargaan adalah: CI lulus, tiga tinjauan kode lulus, penggabungan manual. Setiap kegagalan akan memicu siklus.

Semakin lama, prompt yang ditulis Zoe semakin baik, karena dia ingat apa yang bisa berhasil.

Mekanisme 2: Strategi Pemilihan Agent — Mencari Ahli yang Berbeda untuk Tugas yang Berbeda

Tidak semua Agent memiliki kekuatan yang sama. Penulis merangkum strategi pemilihan:

  • Codex(gpt-5.3-codex) — Andalan- logika backend, bug kompleks, refactoring multi-file, tugas yang memerlukan penalaran lintas repositori kode
  • Lambat tetapi menyeluruh
  • Mencakup 90% tugas

  • Claude Code(claude-opus-4.5) — Peserta cepat- pekerjaan frontend
  • Masalah izin sedikit, cocok untuk operasi git
  • (Penulis sebelumnya lebih sering menggunakan, tetapi setelah Codex 5.3 keluar, dia beralih)

  • Gemini — Desainer- memiliki estetika desain
  • Untuk UI yang menarik, pertama biarkan Gemini menghasilkan spesifikasi HTML/CSS, lalu serahkan kepada Claude Code untuk mengimplementasikannya dalam sistem komponen
  • Gemini mendesain, Claude membangun
Zoe akan secara otomatis memilih Agent berdasarkan jenis tugas, dan mentransfer output di antara mereka. Bug sistem tagihan diberikan kepada Codex, perbaikan gaya tombol diberikan kepada Claude Code, desain dasbor baru terlebih dahulu diberikan kepada Gemini.

Mekanisme 3: Di Mana Bottleneck? RAM

Ada batasan yang tidak terduga di sini: bukan biaya token, bukan laju API, tetapi memori.

Setiap Agent membutuhkan:

  • worktree sendiri
  • nodemodules sendiri
  • menjalankan build, pemeriksaan tipe, pengujian
5 Agent berjalan bersamaan = 5 compiler TypeScript paralel + 5 penguji berjalan + 5 set dependensi dimuat ke dalam memori.

Mac Mini penulis (16GB RAM) paling banyak dapat menjalankan 4-5 Agent secara bersamaan, lebih dari itu mulai melakukan swap, dan harus berdoa agar mereka tidak membangun secara bersamaan.Jadi dia membeli Mac Studio M4 Max (128GB RAM, $3500), yang akan tiba pada akhir Maret. Dia mengatakan bahwa dia akan membagikan apakah itu sepadan atau tidak.

Anda Juga Dapat Membangun: Dari Nol hingga Beroperasi Hanya Dalam 10 Menit

Ingin mencoba sistem ini?

Cara termudah:

Salin seluruh artikel ini ke OpenClaw, beri tahu dia: "Berdasarkan arsitektur ini, buatkan sistem kluster Agent untuk repositori kode saya."

Kemudian, dia akan:

  • Membaca desain arsitektur
  • Membuat skrip
  • Mengatur struktur direktori
  • Mengonfigurasi pemantauan cron
Selesai dalam 10 menit.

Anda perlu menyiapkan:

  • Akun OpenClaw
  • Akses API Codex dan/atau Claude Code
  • Sebuah repositori git
  • (Opsional) Obsidian untuk menyimpan konteks bisnis

2026: Perusahaan Jutaan Dolar Satu Orang

Penulis mengatakan sebuah kalimat di akhir yang saya rasa sangat inspiratif:

"Kita akan melihat banyak perusahaan jutaan dolar satu orang muncul mulai tahun 2026. Leverage-nya sangat besar, milik mereka yang memahami bagaimana membangun sistem AI yang dapat memperbaiki diri secara rekursif."

Ini adalah gambaran seperti ini:

  • Seorang AI Orkestrator sebagai perpanjangan Anda (seperti Zoe bagi penulis)
  • Mendelegasikan pekerjaan kepada Agent khusus, menangani fungsi bisnis yang berbeda
  • Rekayasa, dukungan pelanggan, operasi, pemasaran
  • Setiap Agent fokus pada apa yang mereka kuasai
  • Anda tetap fokus dan sepenuhnya mengendalikan
Generasi pengusaha berikutnya tidak akan mempekerjakan 10 orang untuk melakukan apa yang bisa dilakukan satu orang dengan satu sistem. Mereka akan membangun seperti ini—tetap kecil, bergerak cepat, merilis setiap hari.

Sekarang konten sampah yang dihasilkan AI terlalu banyak. Berbagai hype, berbagai demo "pusat kontrol tugas" yang mewah, tetapi tidak ada yang benar-benar berguna.

Penulis mengatakan dia ingin melakukan hal yang sebaliknya: lebih sedikit hype, lebih banyak mencatat proses pembangunan yang nyata. Pelanggan nyata, pendapatan nyata, pengiriman nyata ke lingkungan produksi, juga ada kegagalan nyata.

Artikel ini sampai di sini.

Tinjauan poin inti:

  • Arsitektur dua lapis: lapisan orkestrasi memegang konteks bisnis, lapisan eksekusi fokus pada kode
  • Automasi lengkap: proses 8 langkah dari kebutuhan hingga PR, sebagian besar tugas berhasil dalam satu kali
  • Pembelajaran dinamis: bukan eksekusi berulang, tetapi menyesuaikan strategi berdasarkan alasan kegagalan
  • Biaya terkontrol: mulai dari $20/bulan, penggunaan berat $190/bulan
Jika Anda juga sedang menjelajahi aplikasi praktis otomatisasi AI, semoga kasus ini dapat memberikan Anda beberapa inspirasi.

Referensi:[[HTMLPLACEHOLDER_29]]

Published in Technology

You Might Also Like