` | Refaktor mekanis paralel | v2.1.63+ | Setiap unit mendapat git worktree sendiri |
`/goal` adalah perintah yang paling mirip dengan Ralph Loop. Di balik layar, model evaluator (Haiku secara default) memeriksa setiap giliran apakah tujuan sudah tercapai. Jika belum, iterasi berikutnya disertai petunjuk tentang hal yang perlu diperbaiki. Jika sudah, proses berhenti. Saya membahas `/goal` secara terperinci dalam panduan [menjalankan Claude Code secara otonom semalaman dengan /goal](https://ailoot.ai/blog/id/goal-mode-claude-code-codex/)—panduan itu mencakup skenario siap pakai untuk pekerjaan selama 14 jam.
`/batch` adalah perintah yang jarang digunakan tetapi ampuh. Ketika Anda perlu membuat perubahan yang sama di lebih dari 100 berkas (migrasi API, penggantian komponen, penggantian nama), `/batch` mengirim setiap berkas kepada subagen terpisah dalam git worktree miliknya sendiri. Perubahannya tidak berbenturan—setiap agen bekerja dalam salinan terisolasi. Untuk informasi selengkapnya tentang subagen, lihat panduan [subagen bertingkat](https://ailoot.ai/blog/id/claude-code-nested-subagents/).
Dalam penjelasan penulis tentang pendekatan ini, semuanya disebut sederhana:
Batas keras untuk `/loop` dan `/goal`:
- Tugas berjalan selama Claude Code tetap terbuka. Tutup terminal dan loop berhenti. Untuk siklus semalaman yang serius, gunakan server jarak jauh atau pembungkus shell Anda sendiri.
- Masa hidup maksimum tugas berulang adalah **7 hari** (setelah itu, tugas dihapus secara otomatis untuk melindungi dari loop yang terlupakan).
- Maksimal **50 tugas bersamaan** dalam satu sesi.
## Cara menjalankan loop otonom pertama Anda dalam 5 menit
Poin utama
Cara tercepat untuk memulai adalah dengan `/goal` bawaan. Buka Claude Code, masukkan perintah dengan tujuan dan kondisi berhenti yang dapat diverifikasi, lalu lanjutkan kesibukan Anda. Claude membuat kode, menjalankan pengujian, membaca kesalahan, memperbaikinya, lalu menjalankan pengujian lagi sampai semuanya lolos.
5 langkah:
1. ### Buka proyek di Claude Code
Buka direktori root proyek di terminal dan jalankan `claude`. Tunggu sampai Claude membaca `CLAUDE.md` dan mengindeks repositori.
2. ### Tetapkan tujuan dan kondisi berhenti
Tujuan adalah hal yang perlu dilakukan. Kondisi berhenti adalah cara Claude mengetahui bahwa tugas sudah selesai. Idealnya, kondisi ini berupa perintah yang mengembalikan 0 atau 1. Contoh: “Tujuan: semua 23 pengujian di `tests/api/*.test.ts` harus lolos. Berhenti saat `pnpm test` mengembalikan exit 0.”
3. ### Jalankan /goal
Perintah:
```
/goal Semua pengujian di tests/api/*.test.ts harus lolos. Jalankan pnpm test, baca kesalahannya, perbaiki, lalu jalankan lagi. Berhenti saat kode keluar = 0. Maksimal 20 iterasi.
```
Claude memulai loop: menjalankan pengujian—menemukan kegagalan—membuka berkas—memperbaikinya—menjalankan pengujian lagi.
4. ### Tetapkan batas anggaran
Di tab latar belakang, gunakan `/usage` untuk memantau penggunaan. Tetapkan batas token atau biaya untuk hari itu agar seluruh saldo Anda tidak habis dalam satu loop. Detail selengkapnya ada dalam panduan [cara agar batas Claude Code tidak cepat habis](https://ailoot.ai/blog/id/claude-code-token-limits-saving/).
5. ### Lanjutkan kesibukan Anda
Kembali dalam 30 menit. Jika tugasnya sederhana, Claude sudah akan menampilkan “DONE, semua pengujian lolos.” Jika lebih rumit, baca laporannya: “berhenti pada iterasi 20, alasan X.” Perbaiki sendiri hal yang tidak dapat diselesaikan loop, lalu mulai ulang.
Di balik layar, ini adalah loop yang dibangun dengan baik dan menggunakan pola verifier.
## Pola verifier: cara Claude memeriksa pekerjaannya sendiri dalam loop
Poin utama
Claude harus selalu memiliki cara untuk memeriksa pekerjaannya. Tanpa pemeriksaan, agen dalam loop mulai berhalusinasi—agen memutuskan bahwa tugas sudah selesai padahal semuanya sebenarnya rusak. Verifier adalah perintah (pengujian, lint, model evaluator, pemeriksaan khusus) yang mengembalikan status “selesai/belum selesai” secara tegas.
Ada tiga jenis verifier:
**1. Teknis (kode keluar)**—yang paling andal. `pnpm test`, `npm run lint`, `tsc --noEmit`, `playwright test`. Semuanya mengembalikan 0 atau 1, tanpa perlu interpretasi. `/goal` juga bekerja dengan cara ini—di balik layar ia menggunakan model evaluator Haiku, yang memeriksa pada setiap giliran apakah kondisi telah terpenuhi (hingga 4000 karakter).
**2. Model evaluator**—model kedua melihat hasil model pertama dan menilainya berdasarkan rubrik. Cocok untuk tugas tanpa pemeriksaan formal (“Apakah gaya tulisannya bagus?” “Apakah desainnya sesuai dengan merek?”). Di Anthropic, ini disebut `Claude Code Review`—mode ketika agen peninjau terpisah mencari kesalahan logika, kasus tepi, dan masalah keamanan dalam pekerjaan agen utama.
**3. Pemeriksaan khusus**—skrip shell yang Anda tulis sendiri. “Jika log tidak memuat kata ERROR, berarti selesai.” “Jika berkas `output.json` ada dan dapat diurai, berarti selesai.” “Jika halaman `/pricing` mengembalikan 200, berarti selesai.”
Dalam pendekatan penulis, keterampilan mencakup langkah adversarial terpisah untuk Claude setelah setiap tahap. Berikut templat prompt yang saya letakkan di `CLAUDE.md` atau dalam sebuah perintah:
```
# Temukan 10 alasan mengapa proyek ini mungkin sudah kacau balau.
Tempatkan diri Anda pada posisi bahwa sesuatu telah salah.
Saya bisa meninjau cerita ini berkali-kali -
sebelum merilisnya kepada publik.
```
Kesalahan pemula yang paling umum adalah **memulai loop tanpa verifier**. Agen berputar-putar: menulis kode, tidak memeriksanya, mengira tugasnya selesai, masuk ke iterasi berikutnya, lalu menulis ulang hal yang sudah dikerjakan. Tiga jam kemudian, semuanya berantakan dan tagihannya $200.
Aturan terbaik: **tulis verifier terlebih dahulu, lalu mulai loop**. Jika Anda tidak dapat menyatakan kondisi berhenti dalam satu baris, tugas tersebut belum siap untuk dijalankan secara otonom.
## Cara menghindari pengeluaran ribuan dolar semalaman: batas anggaran dan kondisi berhenti
Poin utama
Loop tanpa batas anggaran, kondisi berhenti biaya, atau verifier dapat menimbulkan tagihan besar sebelum ada yang menyadarinya. Tiga perlindungan dapat mencegahnya: batas iterasi, batas token atau biaya, dan pendeteksi stagnasi.
Tiga rem penting untuk setiap loop semalaman:
**1. Batas iterasi.** `--max-iterations 20`. Loop tidak dapat berjalan lebih dari N kali—meskipun verifier tidak terpicu. Jika kondisi berhenti belum tercapai setelah 20 iterasi, berarti tugas macet dan memerlukan campur tangan manusia.
**2. Batas token atau biaya.** `/usage limit 50`—maksimal $50 sehari. Saat mendekati batas, loop berhenti sendiri dan mengirim peringatan. Ini melindungi dari skenario tak terkendali.
**3. Pemeriksaan kemajuan dengan ketentuan eksplisit.** Perbandingan `HEAD` di bawah mendeteksi commit baru, bukan semua perubahan kode. Gunakan hanya pada worktree terisolasi tempat setiap iterasi yang mengubah kode mencatat commit checkpoint lokal sebelum perbandingan. Edit berguna yang belum di-commit tidak mengubah `HEAD`; tanpa ketentuan ini hash yang tidak berubah dapat menjadi sinyal stagnasi palsu. Simpan juga hasil verifier: commit baru membuktikan perubahan dicatat, bukan bahwa tugas membaik atau lolos.
Struktur pembungkus ilustratif dengan tiga pemeriksaan ini. Baris pelaporan biaya dan pemanggilan agen adalah contoh khusus runner, bukan resep instalasi CLI yang terverifikasi; pastikan antarmuka tersebut pada versi terpasang sebelum mengadaptasinya. Untuk pemeriksaan kemajuan berbasis commit, wajibkan commit checkpoint lokal pada setiap iterasi yang mengubah kode. Jika runner meninggalkan edit tanpa commit, berhenti untuk meninjaunya alih-alih menyebutnya “tidak ada kemajuan”.
```bash
#!/bin/bash
PROMPT="$1"
MAX_ITER=20
MAX_COST_USD=50
COMPLETION="DONE"
PREV_HASH=""
STAGNATION=0
for i in $(seq 1 $MAX_ITER); do
# Batas biaya
CURRENT_COST=$(claude usage --json | jq '.cost_usd')
if (( $(echo "$CURRENT_COST > $MAX_COST_USD" | bc -l) )); then
echo "STOP: budget cap $MAX_COST_USD reached"
break
fi
# Jalankan
OUTPUT=$(claude code -p "$PROMPT" --auto-accept)
# Pemeriksaan penyelesaian
if echo "$OUTPUT" | grep -q "$COMPLETION"; then
echo "STOP: completion signal"
break
fi
# Hanya kemajuan commit: setiap iterasi yang mengubah kode harus mencatat commit checkpoint.
# HEAD tidak mendeteksi edit berguna yang belum di-commit.
CURRENT_HASH=$(git rev-parse HEAD 2>/dev/null)
if [ "$CURRENT_HASH" = "$PREV_HASH" ]; then
STAGNATION=$((STAGNATION + 1))
if [ "$STAGNATION" -ge 3 ]; then
echo "STOP: stagnation 3 iterations"
break
fi
else
STAGNATION=0
fi
PREV_HASH="$CURRENT_HASH"
done
```
Validasi pemeriksaan kemajuan sebelum memperluas kerangka ini: edit tanpa commit harus diperlakukan sebagai pekerjaan yang belum dicatat; commit checkpoint mengubah `HEAD`; hanya verifier terpisah yang dapat membuktikan keberhasilan. Tiga perbandingan commit yang tidak berubah menunjukkan tidak ada perubahan tercatat sesuai ketentuan tadi, bukan bukti bahwa semua file kerja tidak berubah. Selanjutnya, Anda dapat menambahkan: peringatan Slack saat loop berhenti, laporan Telegram otomatis pada pagi hari, dan notifikasi push ketika anggaran mencapai 80%. Prinsipnya tetap sama: loop memerlukan **rem**, bukan hanya pedal gas.
## 5 skenario loop semalaman siap pakai
Poin utama
Tidak semua tugas cocok untuk loop otonom. Kandidat yang baik adalah tugas dengan verifier yang tegas dan dapat dikerjakan secara iteratif: pengujian, refaktor, pemantauan, alur kerja artikel, impor data. Kandidat yang buruk adalah tugas tanpa pemeriksaan formal atau yang memiliki banyak kriteria subjektif.
**Skenario 1: Membuat pengujian yang gagal menjadi lolos**
```
/goal Ada 47 pengujian yang gagal di direktori tests/. Tujuan: buat semuanya lolos.
Jalankan pnpm test, baca stderr, buka berkas yang bermasalah, perbaiki, lalu jalankan pnpm test lagi.
Berhenti saat kode keluar 0. Maksimal 30 iterasi.
```
**Skenario 2: Refaktor besar di 200 berkas**
```
/batch Ganti klien API lama apiV1 dengan apiV2 baru di semua berkas dalam src/**/*.ts.
Setiap berkas mendapat worktree sendiri. Setelah penggantian, jalankan tsc --noEmit; perbaiki semua kesalahan.
Gabungkan worktree pada akhirnya.
```
**Skenario 3: Pemantauan produksi semalaman**
```
/loop 30m Setiap 30 menit, periksa https://your-app.example.com/api/health.
Jika tidak mengembalikan 200, baca log, cari penyebabnya, perbaiki, lalu deploy ulang.
Catat setiap iterasi ke /tmp/night-monitor.log.
```
**Skenario 4: Mengimpor kumpulan data besar dengan deduplikasi**
```
/goal Impor berkas CSV /tmp/import.csv (12,000 baris) ke tabel clients.
Untuk setiap baris, periksa apakah ada duplikat berdasarkan email; jika tidak ada, masukkan; jika ada, perbarui.
Catat konflik ke /tmp/conflicts.log. Berhenti setelah baris terakhir diproses.
```
**Skenario 5: Alur kerja artikel (pengaturan umum)**
Untuk layanan daring atau agensi yang rutin memerlukan artikel SEO, skenarionya seperti ini:
```
/loop 8h Setiap 8 jam: buka berkas backlog untuk topik berstatus 'queued'.
Jika ada topik, jalankan skill untuk menulis panduan.
Terbitkan ke dev. Ubah status menjadi 'review'. Beri tahu penanggung jawab melalui Telegram.
```
## Hal yang perlu diberikan pada setiap iterasi: CLAUDE.md dan Second Brain sebagai state
Poin utama
Tanpa memori, Claude memulai setiap iterasi dari awal—membuka kembali proyek, membaca berkas, dan melupakan keputusan dari iterasi sebelumnya. Tanpa `CLAUDE.md`, Claude tidak mengetahui arsitekturnya; tanpa `business/` (Second Brain), Claude tidak mengetahui konteks produk; tanpa skill, Claude tidak mengingat aturan dan gaya Anda. State di antara iterasi disimpan dalam tiga lapisan berkas ini. Tanpanya, kualitas loop menurun pada iterasi ke-5.
Tiga lapisan “memori” proyek mengubah prompt sekali pakai menjadi loop terkendali:
**1. CLAUDE.md**—konstitusi proyek. Apa produknya, apa stack-nya, apa aturannya, dan apa yang tidak boleh dilakukan. Claude membaca berkas ini saat memulai setiap sesi dan setiap iterasi loop. Tanpanya, Claude harus “membuka kembali” proyek setiap saat—menghabiskan konteks dan meningkatkan risiko halusinasi. Temukan templat siap pakai dan 6 aturan dalam panduan [CLAUDE.md](https://ailoot.ai/blog/id/claude-md-template/).
**2. Second Brain**—folder berisi pengetahuan bisnis: produk, audiens, tujuan, ekonomi, pemasaran. Bukan kode—melainkan makna. Saat loop menulis artikel atau mencari jawaban untuk dukungan, loop membaca Second Brain dan merespons dengan konteks proyek, bukan dari ruang hampa.
**3. Context engineering**—apa tepatnya yang Anda berikan kepada Claude di setiap iterasi. Bukan seluruh folder Second Brain, bukan seluruh repositori—hanya yang relevan. Plan Mode membantu: Claude menentukan berkas mana yang diperlukan untuk tugas itu dan hanya membaca berkas tersebut. Detail selengkapnya ada dalam panduan [Plan Mode](https://ailoot.ai/blog/id/claude-code-plan-mode/).
Prinsip operasional utama yang harus saya tanamkan lewat berbagai kesalahan:
Tanpa ketiga lapisan ini, loop menjadi siklus tanpa akhir dengan tagihan yang terus bertambah.
Poin utama
Claude Code menggunakan lima tab terminal bernomor, masing-masing dengan git checkout sendiri. Selain itu, aplikasi Claude dapat menjalankan beberapa sesi melalui Remote Control di ponsel. Masing-masing sesi dapat memiliki tugas, verifier, dan loop sendiri.
Apa isi setiap sesi? Berbagai tugas: satu loop memperbaiki bug, loop lain menulis fitur baru, loop ketiga meninjau PR tim, loop keempat mengoptimalkan kinerja, dan loop kelima menyiapkan dokumentasi. Bukan satu agen serbaguna yang besar. Puluhan agen khusus, masing-masing dengan skill, tujuan, dan verifier sendiri.
Cara pandang ulang yang penting:
Bagi pengusaha tanpa programmer, ini berarti sesuatu yang konkret. Anda memiliki satu akun Claude seharga $200/bulan dan laptop biasa. Anda dapat menjalankan **5 loop secara paralel**—dukungan, artikel, metrik, pengujian produk baru, dan pemantauan pesaing. Masing-masing berjalan di tab Claude Code tersendiri. Pada pagi hari, Anda membaca ringkasannya. Ini sudah menjadi norma kerja pada musim panas 2026.
## Empat kegagalan umum loop otonom
Poin utama
Sebagian besar kegagalan loop otonom masuk ke dalam empat pola: tidak ada verifier—agen memutuskan sendiri bahwa tugasnya selesai; tidak ada batas anggaran—loop menghabiskan anggaran semalaman; tidak ada state antaritersi—keputusan saling bertentangan; kondisi berhenti yang samar—loop tidak tahu kapan harus berhenti.
**Kegagalan 1: “Loop halusinasi”**
Agen memutuskan bahwa tugasnya selesai meskipun verifier belum terpicu. Atau verifier sama sekali tidak ada. Tiga jam kemudian, Claude berkata, “Semuanya selesai!”—padahal pengujian gagal, halaman tidak bisa dibuka, dan tidak ada yang berfungsi. Anda sudah menghabiskan $80 untuk iterasi yang sia-sia.
**Perbaikan:** verifier ketat (perintah `exit code`), bukan pemeriksaan verbal.
**Kegagalan 2: “Anggaran habis semalaman”**
Tanpa batas anggaran, loop menjadi granat tanpa pin.
**Perbaikan:** `/usage limit` atau skrip eksternal yang menggunakan `claude usage --json` untuk menghentikan loop saat mencapai ambang batas.
**Kegagalan 3: “Loop kehilangan konteks di antara iterasi”**
Pada iterasi 1, Claude membuat keputusan arsitektur. Pada iterasi 7, Claude lupa lalu membuat keputusan yang berlawanan. Setelah 15 iterasi, kode menjadi berantakan.
**Perbaikan:** lapisan state melalui `CLAUDE.md` dan folder Second Brain. Loop **menulis** setiap keputusan arsitektur ke berkas yang dibaca pada iterasi berikutnya.
**Kegagalan 4: “Kondisi berhenti tidak jelas—loop berjalan selamanya”**
`/goal "Buat halaman ini indah"`—apa arti “indah”? Tanpa metrik yang tegas, loop tidak akan pernah berhenti. Loop akan terus berjalan sampai mencapai batas iterasi atau anggaran.
**Perbaikan:** kondisi berhenti harus selalu **terukur**. Bukan “indah,” melainkan “Lighthouse Performance ≥ 90, Accessibility ≥ 95.” Bukan “berfungsi,” melainkan “pengujian di `tests/pricing.test.ts` lolos.”
## Kapan loop engineering tidak diperlukan
Poin utama
Loop engineering adalah alat untuk tugas berulang yang dapat diverifikasi. Ini tidak diperlukan untuk tugas kreatif satu kali, tugas tanpa verifier formal, dan tugas yang memerlukan evaluasi subjektif. Memahami batasannya lebih penting daripada memahami tekniknya.
Tugas yang tidak cocok untuk loop otonom:
- **Tugas kreatif satu kali.** Satu situs web untuk produk baru, satu logo, satu memo strategis. Loop terlalu berlebihan; lebih mudah menulis satu prompt lalu menyempurnakan hasilnya secara manual.
- **Tugas tanpa verifier.** Jika Anda tidak dapat menyatakan kondisi berhenti sebagai kode keluar atau sinyal tegas, jangan mulai loop; jika tidak, loop akan menjadi api unggun tanpa akhir.
- **Tugas yang memerlukan evaluasi subjektif.** “Buat terdengar lebih baik,” “tingkatkan UX agar lebih menyenangkan”—tugas seperti ini membutuhkan Anda, bukan loop.
- **Bidang baru yang belum dikenal.** Jika Anda sendiri tidak memahami seperti apa hasil “selesai,” jangan jalankan Claude dalam loop. Pahami dahulu, baru otomatisasikan.
Dan aturan utama yang saya pelajari melalui berbagai kesalahan:
Pertanyaan utama sebelum memulai loop: **Bisakah saya menjelaskan dalam satu baris bagaimana saya akan tahu bahwa Claude sudah selesai?** Jika bisa, loop dapat membantu. Jika tidak, tetapkan dahulu kondisi yang dapat diverifikasi, lalu mulai.
### Sumber
- [Ralph Loop Claude Plugin - Anthropic](https://claude.com/plugins/ralph-loop) - plugin resmi
- [Ralph Wiggum plugin on GitHub - Anthropic](https://github.com/anthropics/claude-code/tree/main/plugins/ralph-wiggum) - kode sumber
- [Claude Code Review - Anthropic blog](https://claude.com/blog/code-review) - pratinjau riset peninjauan PR multiagen, tingkat temuan 84%
- [Documentation /goal - Claude Code Docs](https://code.claude.com/docs/en/goal) - dokumentasi resmi perintah
- [Documentation /loop scheduled tasks - Claude Code Docs](https://code.claude.com/docs/en/scheduled-tasks) - dokumentasi resmi
Loop engineering adalah lapisan di atas semua hal yang sudah Anda ketahui tentang Claude Code. Lanjutkan menjelajahi Ailoot di [ailoot.ai](https://ailoot.ai/).
## Pertanyaan tentang Claude Code semalaman: loop engineering dan Ralph Loop pada 2026
### Mengapa HEAD yang tidak berubah bisa keliru menunjukkan bahwa loop tidak membuat kemajuan?
HEAD menunjukkan sebuah commit. Edit berguna pada working tree tidak mengubahnya sampai di-commit. Karena itu detektor contoh memerlukan commit checkpoint lokal setelah setiap iterasi yang mengubah kode; tanpa ketentuan ini, jeda dan periksa pekerjaan yang belum di-commit alih-alih menyebutnya stagnasi.
### Apakah commit baru membuktikan loop memperbaiki hasil?
Tidak. Itu hanya membuktikan perubahan telah dicatat. Simpan hasil verifier bersama checkpoint, dan berhenti pada syarat penerimaan yang sebenarnya. Antarmuka pemanggilan dan biaya yang khusus untuk runner pada pembungkus harus divalidasi sebelum digunakan.
## Ailoot · Perusahaan dan portofolio proyeknya
Ailoot bertumpu pada pengalaman operasional yang teruji, basis pelanggan yang besar, layanan yang stabil, dan pemantauan KPI berkelanjutan.
Perusahaan dan portofolio proyeknya: jutaan pelanggan; penjualan miliaran setiap bulan.
Ailoot memanfaatkan pengalaman operasional ini untuk akses API ke fitur AI dalam produk pelanggan, agen, aplikasi, dan otomatisasi.