---
title: "Panduan Claude Code Loop Engineering: 4 Loop dan Desain Otomatisasi yang Aman"
locale: id
category: tutorial
category_name: "Tutorial"
translation_status: machine
license: cc_by
author: "Injoys Admin"
source_url: https://injoys.com/en/articles/claude-code-loop-engineering-guide
published_at: 2026-07-17T09:40:17+09:00
---

# Panduan Claude Code Loop Engineering: 4 Loop dan Desain Otomatisasi yang Aman

> Loop dalam Claude Code adalah struktur kontrol yang membuat Agent mengulangi observasi, tindakan, dan verifikasi hingga kondisi akhir tercapai. Panduan ini menjelaskan perbedaan empat jenis Loop serta metode desain praktis yang mencakup bukti verifikasi, Hard stop, idempotensi, biaya, dan hak akses minimum.

## Key Points

- Loop dalam Claude Code bukanlah perulangan kode, melainkan struktur eksekusi agen yang mengulangi observasi, tindakan, dan verifikasi hingga kondisi akhir tercapai.
- Turn-based menyerahkan prosedur verifikasi, Goal-based menyerahkan penilaian akhir, Time-based menyerahkan waktu eksekusi ulang, dan Proactive menyerahkan awal pekerjaan serta orkestrasi kepada sistem.
- Loop yang baik harus memiliki kondisi penyelesaian yang dapat diukur, bukti verifikasi eksternal, penghentian paksa, idempotensi, dan hak akses minimum.
- Model evaluasi `/goal` hanya menilai bukti yang muncul dalam percakapan, sehingga output pengujian, kode keluar, dan cakupan perubahan harus dilaporkan dengan jelas.
- Transformasi deterministik harus ditangani dengan Script, sedangkan Dynamic Workflow dan banyak Agent hanya boleh diterapkan pada pekerjaan berskala besar yang benar-benar membutuhkan paralelisme.

Loop pada Claude Code bukan sekadar fitur untuk menjalankan model lebih lama. Intinya adalah menempatkan **Trigger, Verifier, Success condition, Hard stop, Permission boundary** di sekitar AI Agent yang bertindak secara probabilistik agar pekerjaan berulang menjadi sistem yang dapat dikendalikan. Tulisan ini merangkum sekaligus perbedaan antara Turn-based, Goal-based, Time-based, dan Proactive Loop serta prinsip desain praktisnya.

## 1. Apa itu Loop dalam Claude Code

Loop di sini bukan pernyataan `for` atau `while` dalam bahasa pemrograman. Loop yang dijelaskan oleh tim Claude Code adalah struktur eksekusi di mana Agent mengamati status saat ini, bertindak, memverifikasi hasil, lalu bekerja lagi sampai kondisi selesai terpenuhi.

```text
Mulai pekerjaan
  ↓
Memahami status dan kode
  ↓
Menyusun rencana
  ↓
Mengubah kode atau menjalankan tool
  ↓
Tes·verifikasi
  ↓
Kondisi selesai terpenuhi?
  ├─ Tidak: iterasi berikutnya
  └─ Ya: selesai dan laporkan hasil
```

Saat membedakan Loop, empat pertanyaan berikut berguna.

1. Apa yang memulai pekerjaan?
2. Apa yang mengakhiri pekerjaan?
3. Fitur Claude Code apa yang mengendalikan pengulangan?
4. Jenis pekerjaan apa yang cocok?

Tidak semua pekerjaan perlu dijadikan Loop yang kompleks. Untuk pekerjaan yang hasilnya langsung dapat dikonfirmasi, seperti memperbaiki typo pada satu file atau mengganti nama sederhana, Prompt biasa lebih efisien. Loop sebaiknya dipilih hanya ketika beberapa kali observasi·perbaikan·verifikasi memang benar-benar diperlukan.

## 2. Perbandingan empat jenis Loop

| Jenis | Kondisi mulai | Kondisi selesai | Fitur yang terutama digunakan | Pekerjaan yang cocok | Tanggung jawab yang diserahkan manusia |
|---|---|---|---|---|---|
| Turn-based | Prompt pengguna | Saat Claude menilai selesai atau membutuhkan informasi tambahan | Percakapan umum, Skills, tool tes·browser | Implementasi·perbaikan singkat dan sekali jalan | Prosedur verifikasi berulang |
| Goal-based | Pengguna menetapkan kondisi selesai | Model evaluasi mengonfirmasi kondisi terpenuhi atau pengguna menghentikan | `/goal`, Auto mode jika perlu | Pekerjaan dengan status selesai yang dapat diukur seperti tes·build·migrasi | Penilaian selesai |
| Time-based | Waktu·interval·jadwal yang ditentukan | Pengguna membatalkan atau pekerjaan eksternal selesai | `/loop`, `/schedule` | Pemantauan PR·CI·deployment, ringkasan berkala, Polling status | Waktu eksekusi berikutnya |
| Proactive | Jadwal, API, event GitHub, dll. | Tujuan masing-masing pekerjaan terpenuhi, Routine dinonaktifkan | Routines, `/goal`, Skills, Dynamic Workflows, Auto mode | Pekerjaan berkelanjutan seperti klasifikasi isu, penanganan bug, migrasi skala besar | Penemuan pekerjaan, eksekusi Prompt, orkestrasi |

Inti dari klasifikasi ini bukan “seberapa pintar AI”, melainkan **tanggung jawab kontrol apa yang diserahkan manusia kepada sistem**. Dalam Turn-based, manusia membuat Prompt berikutnya; dalam Goal-based, manusia menyerahkan penilaian selesai; dalam Time-based, manusia menyerahkan waktu eksekusi ulang. Pada tahap Proactive, bahkan tanggung jawab mendeteksi munculnya pekerjaan dan menjalankan Prompt yang sesuai berpindah ke sistem.

## 3. Turn-based Loop: menyerahkan prosedur verifikasi

Turn-based Loop adalah bentuk dasar yang digunakan sebagian besar developer saat memakai Claude Code.

```text
Human → Claude → Human → Claude
```

Ketika pengguna meminta sesuatu, Claude mencari file terkait, mengubah kode, melakukan tes, dan melaporkan hasil. Secara internal, observasi·tindakan·verifikasi dapat terjadi beberapa kali, tetapi wewenang untuk memulai pekerjaan berikutnya tetap berada pada pengguna.

### Mengubah kode dan menyelesaikan fitur itu berbeda

Meskipun Claude melaporkan “implementasi dan tes selesai”, dalam produk nyata masalah berikut masih bisa tersisa.

- Status tidak berubah setelah tombol diklik.
- Terjadi error di konsol browser.
- Layout mobile rusak.
- Atribut aksesibilitas hilang.
- Tes lulus, tetapi alur browser nyata gagal.
- File yang tidak terkait perubahan ikut dimodifikasi.

Karena itu, kriteria selesai seharusnya bukan “kode telah diubah”, melainkan “perilaku telah dikonfirmasi dengan bukti eksternal”.

### Menggunakan kembali verifikasi dengan `SKILL.md`

Skill adalah cara menyimpan instruksi dan prosedur yang digunakan berulang kali di `SKILL.md`. Claude dapat memuatnya otomatis dengan menilai relevansinya, atau menjalankannya langsung dengan `/skill-name`. Daripada selalu memasukkan prosedur operasi yang panjang ke `CLAUDE.md`, memisahkannya agar Skill hanya dimuat saat diperlukan dapat menggunakan konteks dengan lebih efisien.

```markdown
---
name: verify-ui-change
description: Memverifikasi perubahan UI di lingkungan eksekusi nyata sebelum dianggap selesai.
---

# Verifikasi perubahan UI

1. Jalankan server pengembangan.
2. Buka layar yang diubah di browser.
3. Operasikan kontrol baru secara nyata.
4. Pastikan perubahan status yang diharapkan terjadi.
5. Periksa error dan peringatan baru di konsol browser.
6. Periksa aksesibilitas dan metrik performa utama.
7. Jika gagal, perbaiki lalu verifikasi ulang dari awal.
8. Laporkan bukti seperti perintah yang dijalankan, hasil, screenshot, dll.
```

Skill yang baik berisi checklist yang dapat dieksekusi, bukan imbauan abstrak. “Periksa dengan lebih hati-hati” jauh lebih lemah daripada aturan “pastikan `npm test` berakhir dengan kode keluar 0”.

### Kekuatan bukti verifikasi

| Bukti | Keandalan | Alasan |
|---|---:|---|
| Penjelasan Agent seperti “tampaknya normal” | Rendah | Hanya inferensi, bukan hasil eksekusi |
| Diff kode dan peninjauan statis | Sedang | Perubahan terlihat, tetapi perilaku Runtime tidak terkonfirmasi |
| Output tes nyata dan kode keluar | Tinggi | Ada hasil eksternal yang dapat direproduksi |
| Interaksi browser, screenshot, hasil konsol·performa | Sangat tinggi | Memverifikasi langsung jalur pengguna dan status Runtime |
| Review Agent independen dan CI mencapai kesimpulan yang sama | Sangat tinggi | Mengurangi bias konfirmasi diri dari Agent implementasi |

Dokumen resmi Claude Code juga menjelaskan bundled Skill seperti `/run` untuk memeriksa aplikasi yang sedang berjalan dan `/verify` untuk memverifikasi perubahan di lingkungan eksekusi nyata. Jika cara menjalankan proyek kompleks, lebih aman mencatat perintah start yang tepat, variabel lingkungan, dan prosedur persiapan data dalam Skill khusus tim.

## 4. Goal-based Loop: menyerahkan penilaian selesai

Goal-based Loop tidak membuat pengguna memutuskan setiap kali “apakah perlu bekerja sekali lagi”. Pengguna mendefinisikan status selesai, dan Claude melanjutkan beberapa Turn sampai kondisi tersebut terpenuhi.

```text
Pengguna menetapkan Goal
  ↓
Turn kerja Claude
  ↓
Model evaluasi terpisah memeriksa kondisi selesai
  ├─ Belum terpenuhi: menyampaikan alasannya ke Turn berikutnya
  └─ Terpenuhi: Goal selesai
```

`/goal` didokumentasikan dapat digunakan pada Claude Code v2.1.139 atau lebih baru. Dalam satu sesi, hanya satu Goal yang dapat aktif.

### Apa yang sebenarnya dilihat model evaluasi

Setelah setiap Turn selesai, small fast model terpisah melihat kondisi selesai dan isi percakapan, lalu menilai `terpenuhi` atau `belum terpenuhi`. Pengaturan default adalah model evaluasi keluarga Haiku. Batasan pentingnya adalah model evaluasi tidak membaca file secara langsung atau menjalankan tes terpisah.

Karena itu, Claude yang menjalankan pekerjaan harus meninggalkan bukti berikut dengan jelas dalam percakapan.

- Perintah yang dijalankan
- Jumlah tes dan hasil lulus·gagal
- Kode keluar
- Hasil build
- Daftar file yang diubah
- Penyebab kegagalan yang tersisa
- Hasil konfirmasi bahwa batasan cakupan dipatuhi

Model evaluasi menilai bukan “apa yang benar-benar terjadi”, melainkan “bukti apa yang terlihat dalam percakapan”.

### Empat elemen Goal yang baik

Goal yang baik mencakup empat elemen berikut.

1. **Kondisi sukses yang terukur**: tes lulus, build sukses, antrean kosong, ambang skor tercapai
2. **Metode verifikasi**: menyatakan perintah atau tool apa yang membuktikan sukses
3. **Batasan cakupan perubahan**: direktori yang boleh diubah, file yang dilarang, efek samping yang diizinkan
4. **Kondisi penghentian paksa**: jumlah Turn maksimum, waktu maksimum, jumlah kegagalan beruntun, berhenti saat error izin

```text
/goal Semua tes dan lint terkait auth berhasil,
dan git diff hanya boleh mencakup src/auth serta file tes terkait.
Laporkan hasil eksekusi dan kode keluar pada setiap Turn.
Jika mencapai maksimal 12 turn atau 45 menit, hentikan dan rangkum kegagalan yang tersisa.
```

Kondisi selesai inti dari `/goal` itu sendiri adalah penilaian sukses dari model evaluasi atau `/goal clear` dari pengguna. Jika ingin memaksa batas Turn·waktu, batas tersebut harus dinyatakan di dalam kondisi Goal.

### Kondisi yang baik dan buruk

| Kondisi baik | Kondisi buruk |
|---|---|
| `npm test` berakhir dengan kode keluar 0 | Membuat kode sempurna |
| Semua 48 tes terkait autentikasi lulus | Meningkatkan pengalaman pengguna semaksimal mungkin |
| Semua titik pemanggilan API diubah ke interface baru dan build berhasil | Melakukan refactoring ke struktur yang lebih baik |
| Antrean isu target pemrosesan kosong dan hasil dicatat pada tiap isu | Menangani isu sebanyak mungkin |

Tujuan yang ambigu dapat berhenti terlalu cepat atau mengulang perbaikan tanpa akhir.

### Pemeriksaan status dan penghentian

- `/goal`: memeriksa kondisi aktif, waktu eksekusi, jumlah Turn evaluasi, penggunaan token, alasan evaluasi terbaru
- `/goal clear`: menghentikan Goal aktif
- Menetapkan Goal baru: mengganti Goal yang ada
- `--resume` atau `--continue`: dapat memulihkan Goal yang belum selesai

Saat dilanjutkan, kondisi tetap dipertahankan, tetapi baseline jumlah Turn, waktu, dan token dapat direset, sehingga sebaiknya Hard stop dikelola bersama metrik operasional.

### `/goal` dan izin adalah hal terpisah

`/goal` hanya memulai Turn berikutnya secara otomatis, bukan memperluas izin tool. Jika penulisan file, perintah tes, atau pekerjaan Git memerlukan persetujuan, persetujuan tetap dapat diperlukan selama Goal berjalan.

Untuk eksekusi tanpa pengawasan, Auto mode dapat digunakan bersama, tetapi Auto mode bukan fitur yang “mengizinkan semua tool tanpa syarat”. Classifier memblokir pekerjaan yang bersifat destruktif, sulit dibatalkan, atau menargetkan luar batas kepercayaan, dan aturan `ask` serta `deny` yang eksplisit diterapkan sebelum classifier.

## 5. Time-based Loop: menyerahkan waktu eksekusi ulang

Jika Goal-based Loop menangani “kapan berhenti”, Time-based Loop menangani “kapan menjalankan lagi”. Ini cocok untuk pekerjaan yang status sistem eksternalnya berubah seiring waktu.

- Memeriksa apakah ada review baru pada PR
- Memeriksa apakah CI atau deployment selesai
- Memeriksa status build berdurasi panjang
- Meringkas pesan Slack setiap hari
- Memeriksa item baru pada antrean isu

### `/loop`: eksekusi berulang dalam sesi saat ini

```text
/loop 10m Periksa PR saat ini dan terapkan review baru,
lalu jika ada CI yang gagal, analisis penyebabnya dan perbaiki.
```

Bentuk utama yang dijelaskan dalam dokumen saat ini adalah sebagai berikut.

| Input | Perilaku |
|---|---|
| `/loop 5m <prompt>` | Menjalankan Prompt pada interval tetap yang ditentukan |
| `/loop <prompt>` | Claude memilih interval pada setiap pengulangan |
| `/loop` | Menjalankan Prompt pemeliharaan built-in atau `loop.md` proyek |
| `/loop 20m /review-pr 1234` | Menjalankan ulang Skill yang diizinkan pada interval yang ditentukan |

`/loop` bergantung pada sesi Claude Code saat ini. Komputer dan sesi harus tetap berjalan, dan jika percakapan baru dimulai, pekerjaan dalam cakupan sesi akan hilang. Pekerjaan yang belum kedaluwarsa dapat dipulihkan dengan `--resume` atau `--continue`, tetapi pekerjaan berulang pada dasarnya kedaluwarsa 7 hari setelah dibuat. Siklus yang terlewat juga tidak dijalankan mundur semuanya.

Karena Jitter dapat diterapkan pada Scheduler sesi, ini mungkin tidak cocok untuk kebutuhan operasional yang “harus berjalan tepat pada jam tertentu”.

### `/schedule`: Cloud Routine yang dikelola Anthropic

`/schedule` membuat Routine yang menggabungkan Prompt, Repository, Connector, dan Trigger untuk dijalankan pada infrastruktur yang dikelola Anthropic. Ini dapat berjalan meskipun laptop ditutup, dan dalam dokumen resmi diperkenalkan sebagai Research Preview.

Trigger yang didukung Routine adalah sebagai berikut.

- Jadwal berulang
- Jadwal sekali jalan pada waktu tertentu di masa depan
- Panggilan API terautentikasi
- Event GitHub Pull request atau Release

Beberapa Trigger dapat dihubungkan ke satu Routine. Misalnya, PR Review Routine dapat dijalankan setiap malam sekaligus merespons event `pull_request.opened`.

### Perbandingan `/loop` dan `/schedule`

| Kategori | `/loop` | `/schedule` Routine |
|---|---|---|
| Lokasi eksekusi | Komputer dan sesi saat ini | Cloud yang dikelola Anthropic |
| Eksekusi setelah komputer mati | Umumnya tidak bisa | Bisa |
| Perlu sesi terbuka | Perlu | Tidak perlu |
| File lokal yang belum di-commit | Dapat diakses | Tidak dapat diakses, Repository di-Clone ulang setiap eksekusi |
| Interval minimum | 1 menit menurut dokumen resmi | 1 jam menurut dokumen resmi |
| Persistensi | Berpusat pada sesi, pekerjaan berulang kedaluwarsa 7 hari | Routine yang disimpan di akun |
| Prompt izin | Mewarisi kebijakan sesi saat ini | Eksekusi otonom tanpa persetujuan interaktif |
| Penggunaan yang cocok | Pemantauan PR·deployment singkat | Otomasi operasional berkelanjutan |

### Ketika Event lebih baik daripada Polling

Jika PR yang jarang berubah diperiksa setiap 1 menit, sebagian besar eksekusi akan selesai tanpa melakukan apa pun. Jika sistem eksternal dapat mengirim event, struktur berikut lebih efisien.

```text
CI gagal atau PR diperbarui
  ↓
GitHub Trigger atau Routine API
  ↓
Claude berjalan hanya saat diperlukan
```

Desain berbasis Event mengurangi latensi serta panggilan model dan konsumsi token yang tidak perlu. Jika Polling tidak dapat dihindari, interval sebaiknya diperpanjang sesuai frekuensi perubahan nyata, dan Backoff diterapkan saat tidak ada perubahan dalam waktu lama.

### Syarat wajib pekerjaan berbasis waktu

1. **Idempotensi**: meskipun event yang sama diterima beberapa kali, komentar duplikat, PR duplikat, atau deployment duplikat tidak boleh terjadi.
2. **Status pemrosesan**: Last processed Event ID, Commit SHA, Review Comment ID, dll. harus dicatat.
3. **Status selesai**: harus bisa menilai selesai seperti PR merge·close, Queue empty, Deploy success·rollback.
4. **Cakupan penulisan**: efek samping harus dibatasi, misalnya komentar diizinkan, Merge dilarang, hanya Branch `claude/*` yang boleh Push.
5. **Penanganan kegagalan**: diperlukan aturan retry dan Escalation saat layanan eksternal bermasalah, autentikasi kedaluwarsa, Rate limit, atau izin kurang.

## 6. Proactive Loop: menyerahkan penemuan pekerjaan dan orkestrasi

Proactive Loop bukan satu perintah, melainkan arsitektur otomasi selalu aktif yang menggabungkan beberapa fitur.

```text
Trigger
+ Goal
+ Skills
+ Dynamic Workflow
+ Auto mode
+ Tool Repository·Connector·Browser·CI
```

Meski manusia tidak memasukkan Prompt secara real-time, pekerjaan baru terdeteksi, diproses, diverifikasi, dan hasilnya dilaporkan.

### Contoh: penanganan otomatis feedback bug

```text
Menerima GitHub Issue atau feedback Slack
  ↓
Klasifikasi duplikasi·prioritas·kemungkinan reproduksi
  ↓
Membuat tes reproduksi
  ↓
Menjelajahi kandidat solusi
  ↓
Mengimplementasikan solusi yang dipilih
  ↓
Review Agent independen mencari contoh tandingan
  ↓
Verifikasi tes·build·keamanan
  ↓
Draft PR dan laporan hasil
```

Tanggung jawab tiap komponen adalah sebagai berikut.

| Komponen | Tanggung jawab |
|---|---|
| Trigger atau `/schedule` | Menentukan kapan pekerjaan baru dimulai |
| `/goal` | Mendefinisikan apa status selesai pada eksekusi ini |
| Skill | Menstandarkan prosedur reproduksi, implementasi, verifikasi, pelaporan |
| Dynamic Workflow | Eksekusi paralel banyak Subagent dan percabangan kondisi |
| Auto mode | Menjalankan pemanggilan tool yang diizinkan tanpa menunggu persetujuan |
| Permission policy | Mengunci cakupan larangan·persetujuan·izin otomatis |

### Dynamic Workflow dan Worktree

Dynamic Workflow adalah struktur di mana Runtime menjalankan Script orkestrasi JavaScript yang ditulis Claude. Pada pemanggilan Subagent biasa, Claude memilih Agent berikutnya pada setiap Turn, tetapi dalam Workflow, Loop, pemrosesan paralel, percabangan, dan penyimpanan hasil antara berpindah ke Script.

```text
Workflow Script
  ├─ Agent A: Analisis kebutuhan
  ├─ Agent B: Desain tes
  ├─ Agent C: Eksplorasi kandidat implementasi
  ├─ Agent D: Review keamanan
  └─ Judge: Perbandingan berbasis bukti
```

Karena hasil antara tersisa di variabel Script, bukan di Context percakapan utama, pekerjaan skala besar dapat diorganisasi dengan lebih dapat direproduksi. Dokumen saat ini menyatakan batas Runtime maksimal 16 Agent secara bersamaan dan maksimal 1,000 Agent per eksekusi, tetapi batas pada tahap Preview produk dapat berubah.

Jika perlu menguji beberapa kandidat implementasi secara bersamaan, ruang kerja dapat dipisahkan dengan Git Worktree.

```text
repo/
worktree-solution-a/
worktree-solution-b/
worktree-solution-c/
```

Jika setiap Agent bekerja pada Branch dan direktori independen, masalah saling menimpa file yang sama secara bersamaan dapat dikurangi. Judge Agent harus membandingkan kandidat berdasarkan pemenuhan kebutuhan, hasil tes, risiko regresi, cakupan perubahan, kompleksitas, performa, keamanan, dan konsistensi dengan arsitektur yang ada.

### Lebih banyak Agent tidak selalu lebih baik

Jika jumlah Agent hanya ditambah pada pekerjaan yang tidak memiliki paralelisme, biaya dan latensi meningkat. Jika beberapa Agent berbagi asumsi keliru yang sama, error juga dapat membesar.

Dynamic Workflow cocok dalam kasus berikut.

- Migration yang menerapkan transformasi sama pada ratusan file
- Audit keamanan·kualitas seluruh codebase
- Perbandingan Plan dari beberapa perspektif independen
- Research yang harus memproses banyak item secara terbagi dan diverifikasi silang
- Pekerjaan yang sulit memuat semua hasil antara dalam Context satu Agent

Untuk perbaikan bug kecil, refactoring satu file, atau penambahan tes sederhana, Turn-based Loop biasa atau `/goal` lebih baik.

## 7. Sistem untuk menjaga kualitas kode dalam Loop

Kualitas hasil Loop sangat dipengaruhi bukan hanya oleh model itu sendiri, tetapi juga oleh sistem verifikasi di sekitar model.

### 7.1 Merapikan codebase

Claude sangat mengikuti pola kode yang ada. Jika ada API lama, implementasi duplikat, struktur tes yang tidak jelas, modul raksasa, atau aturan penanganan exception yang tidak konsisten, Loop dapat dengan cepat mereplikasi masalah tersebut.

Fondasi wajibnya adalah sebagai berikut.

- Formatter dan lint
- Batas direktori dan modul yang jelas
- Unit·Integration·E2E Test yang dapat dipercaya
- Pembedaan antara API yang digunakan dan Deprecated API
- Aturan pengembangan per proyek
- Lingkungan Build·Dev yang dapat direproduksi

### 7.2 Membuat Definition of Done berdasarkan jenis perubahan

| Jenis perubahan | Verifikasi minimum |
|---|---|
| API | Tes kontrak, kompatibilitas mundur, pembaruan contoh Schema·dokumen |
| Frontend | Operasi browser nyata, error konsol, aksesibilitas, layar responsif |
| Database | Forward·Rollback Migration, cakupan Lock, rencana eksekusi |
| Dependency | Build, tes regresi utama, pemeriksaan License·Security |
| Infrastructure | Plan Diff, izin minimum, Rollback, pemeriksaan paparan informasi rahasia |

Daripada mengulang panjang kriteria ini dalam Prompt setiap kali, lebih baik menguncinya sebagai Skill, Hook, Script, atau CI Rule.

### 7.3 Menyediakan dokumen terbaru dan versi yang akurat

Loop dapat mengulang asumsi keliru beberapa kali. Versi persis yang digunakan proyek, dokumen resmi, dokumen Architecture internal, spesifikasi API, Migration Guide, dan contoh yang disetujui harus mudah ditemukan.

### 7.4 Memisahkan Agent implementasi dan Review Agent

Agent yang mengimplementasikan sudah dipengaruhi oleh desain dan penalaran yang dipilihnya. Review Agent dengan Context baru dapat mengajukan pertanyaan berikut secara lebih independen.

- Apakah tes dilemahkan agar lulus?
- Apakah file di luar cakupan diubah?
- Apakah batas keamanan rusak?
- Apakah tes jalur gagal dan nilai batas terlewat?
- Apakah muncul regresi pada fitur yang sudah ada?

Review Prompt lebih efektif jika ditulis seperti “dengan asumsi implementasi ini salah, cari contoh tandingan dan lampirkan bukti reproduksi pada setiap temuan” daripada “rangkum hal baiknya”.

### 7.5 Menghubungkan kegagalan individual ke perbaikan sistem

Jika error yang sama berulang, tidak cukup hanya memperbaiki hasil tersebut. Agar jenis kegagalan itu sulit terulang, salah satu hal berikut harus diubah.

- Menambahkan Regression Test
- Memperkuat prosedur verifikasi Skill
- Menambahkan aturan `CLAUDE.md`
- Menambahkan Hook atau lint Rule
- Menambahkan aturan Deny izin
- Memperkuat kondisi selesai Goal
- Melengkapi Review Checklist

Loop Engineering yang baik bukan pekerjaan memperbaiki satu kegagalan, melainkan **pekerjaan membangun sistem yang membuat jenis kegagalan itu sulit muncul kembali**.

## 8. Pengelolaan Token dan biaya

Biaya Loop dapat meningkat jauh lebih besar daripada Prompt tunggal.

```text
Total biaya ≈
Biaya Turn Agent utama
+ Biaya evaluasi Goal
+ Biaya Subagent
+ Biaya iterasi Workflow
+ Biaya Context untuk membaca hasil tool
+ Frekuensi eksekusi berbasis waktu
```

Penagihan yang tepat berbeda tergantung Plan, Model, dan Provider, tetapi prinsip yang menentukan struktur biaya sama.

### Prinsip praktis untuk mengurangi biaya

1. **Jangan memakai Loop untuk pekerjaan kecil.** Typo, perubahan nama, dan error tipe pada satu file ditangani dengan satu Turn.
2. **Tetapkan kondisi sukses bersama Hard stop.** Pertimbangkan sukses, maksimum Turn, maksimum waktu, kegagalan beruntun, dan error izin.
3. **Uji Workflow skala besar pada cakupan kecil.** Verifikasi biaya dan kualitas dengan 5 file, satu direktori, atau sebagian Issue, lalu perluas.
4. **Tangani pekerjaan deterministik dengan Script.** Penggantian AST, transformasi JSON, Formatting, dan pembuatan format tetap lebih murah dan dapat direproduksi dengan Script yang terverifikasi.
5. **Sesuaikan siklus Polling dengan frekuensi perubahan nyata.** Gunakan Event Trigger jika memungkinkan.
6. **Amati penggunaan saat berjalan.** Periksa penggunaan Skill·Subagent·MCP·Turn·Token di `/usage`, `/goal`, `/workflows`.
7. **Jika error yang sama berulang, jangan terus mencoba ulang.** Tetapkan batas kegagalan beruntun dan lakukan Escalation ke manusia.

### Model dan Effort adalah tuas yang berbeda

- **Model** mengubah kemampuan penalaran dasar dan cakupan masalah yang dapat diselesaikan.
- **Effort** mengubah jumlah file yang dibaca, jumlah tool yang digunakan, luas verifikasi, dan sejauh mana pekerjaan multi-tahap didorong sampai selesai.

Jika Claude sudah memeriksa semua file dan tes yang diperlukan tetapi penilaiannya sendiri terus salah, Model yang lebih kuat mungkin diperlukan. Sebaliknya, jika file penting tidak dibaca, tes dilewati, atau refactoring berhenti di tengah, menaikkan Effort mungkin lebih tepat.

## 9. Izin dan batas keamanan

Desain paling berbahaya dalam Proactive Loop adalah memberi Agent izin luas dan menetapkan kondisi sukses serta kondisi berhenti secara longgar.

Auto mode mengurangi Prompt izin umum, tetapi classifier dapat memblokir Tool call yang sulit dibatalkan, destruktif, atau menargetkan luar batas kepercayaan. Selain itu, `permissions.ask` dan `permissions.deny` yang eksplisit diprioritaskan di atas Auto mode.

### Contoh lapisan izin

| Level | Contoh |
|---|---|
| Diizinkan otomatis | Membaca kode, tes·lint·Build, analisis, membuat Branch `claude/*`, membuat Draft PR |
| Persetujuan manusia | Menerapkan ke Default Branch, deployment produksi, menerapkan DB Migration, mengirim pesan pelanggan eksternal |
| Selalu dilarang | Force push, menampilkan Secret, menghapus data produksi, bypass izin, menghapus audit log |

Lebih aman menguncinya sebagai Rule `ask`·`deny` permanen daripada sekali berkata “jangan Push” dalam percakapan. Aturan percakapan dapat melemah karena kompresi Context atau perubahan sesi.

Cloud Routine melakukan Clone Repository baru pada setiap eksekusi dan bekerja dengan izin GitHub·Connector yang terhubung. Cakupan berikut harus diminimalkan.

- Repository dan Branch yang dapat diakses
- Network Domain yang diizinkan
- Connector yang digunakan
- Variabel lingkungan dan Secret
- Izin tulis ke sistem eksternal
- Cakupan pembuatan PR·Push·Merge

Status “selesai normal” pada daftar eksekusi Routine dapat berarti Session berakhir tanpa error Infrastructure, dan bukan jaminan bahwa tujuan pekerjaan berhasil. Transcript, Test evidence, dan Diff yang dihasilkan harus ditinjau secara terpisah.

## 10. Template desain Loop untuk proyek pengembangan

YAML berikut bukan sintaks Claude Code nyata, melainkan Template untuk review desain.

```yaml
trigger:
  type: manual | interval | schedule | github_event | api_event

scope:
  repositories:
    - target-repository
  allowed_paths:
    - src/**
    - tests/**
  prohibited_paths:
    - production/**
    - secrets/**

task:
  objective: tujuan yang akan diubah atau diproses
  input: Issue, Event, File, atau status yang baru masuk

verification:
  commands:
    - unit-test
    - integration-test
    - lint
    - build
  runtime_checks:
    - browser-interaction
    - console-errors
    - accessibility
  evidence:
    - command-output
    - exit-code
    - test-summary
    - screenshots

success:
  condition: status selesai yang dapat dinilai benar atau salah

stop:
  max_turns: 12
  max_duration_minutes: 45
  max_consecutive_failures: 3
  stop_on_permission_error: true
  escalate_on_external_outage: true

side_effects:
  idempotency_key: event-id-or-commit-sha
  allow_branch_push: claude/*
  require_human_for_merge: true
  require_human_for_deploy: true

review:
  independent_agent: true
  adversarial_review: true

observability:
  report_progress: true
  report_token_usage: true
  report_changed_files: true
  report_remaining_failures: true
```

Item terpenting bukan kalimat Prompt itu sendiri, melainkan lima hal berikut.

```text
Trigger
Verifier
Success condition
Hard stop
Permission boundary
```

## 11. Loop mana yang harus dipilih

| Situasi | Metode yang disarankan |
|---|---|
| Pekerjaan yang selesai dengan satu perbaikan dan verifikasi | Turn-based |
| Pekerjaan yang perlu dicoba beberapa kali tetapi status selesai jelas | `/goal` |
| Pekerjaan yang perlu menunggu sebentar status CI·PR·deployment eksternal | `/loop` |
| Pekerjaan yang harus tetap berjalan berulang meski laptop ditutup | `/schedule` Routine |
| Pekerjaan yang harus segera merespons event GitHub atau Alert | Event-triggered Routine |
| Pekerjaan yang harus memproses ratusan item secara paralel dan diverifikasi silang | Dynamic Workflow |
| Transformasi dengan aturan input dan output yang sepenuhnya deterministik | Script atau CI Job |

Urutan pemilihan harus berdasarkan “struktur kontrol paling sederhana yang mencapai tujuan”, bukan “fitur paling kuat”.

## 12. Urutan adopsi yang aman

1. Pilih satu pekerjaan bottleneck yang berulang kali diperiksa manusia.
2. Pertama buat prosedur verifikasi sebagai Skill, Script, atau CI.
3. Stabilkan kualitas verifikasi dengan cara Turn-based.
4. Jika status selesai jelas, tambahkan `/goal`.
5. Gunakan `/loop` hanya saat perlu menunggu status eksternal.
6. Jika perlu eksekusi jangka panjang, pindahkan ke `/schedule` Routine.
7. Perluas ke Dynamic Workflow dan Proactive Loop hanya setelah idempotensi, izin, dan biaya terverifikasi.

## 13. Kesalahpahaman yang sering terjadi

| Kesalahpahaman | Interpretasi yang tepat |
|---|---|
| Loop adalah eksekusi tanpa batas | Struktur iterasi terbatas yang memiliki kondisi sukses dan Hard stop |
| Laporan selesai dari Agent adalah verifikasi | Dibutuhkan output perintah eksternal, kode keluar, dan hasil Runtime |
| `/goal` otomatis mengizinkan semua izin | Hanya memulai Turn berikutnya secara otomatis; kebijakan izin terpisah |
| `/loop` adalah Scheduler operasional jangka panjang | Berpusat pada sesi, dengan kedaluwarsa 7 hari dan batasan lingkungan eksekusi |
| Semakin banyak Agent, hasilnya semakin baik | Nilai paralelisasi muncul hanya ketika peran·perspektif·verifikasi berbeda |
| Semua pekerjaan berulang harus dilakukan LLM | Bagian deterministik lebih murah dan lebih dapat direproduksi dengan Script |

## Kesimpulan

Loop Engineering bukan teknologi untuk menjalankan AI lebih lama, melainkan **desain sistem kontrol yang membuat AI menemukan sendiri saat ia salah, memperbaiki dalam batas biaya, dan berhenti pada titik yang berisiko**.

LLM kuat dalam eksplorasi, penalaran, implementasi, analisis exception, dan perbandingan alternatif. Sistem harus menangani waktu eksekusi, cakupan perubahan, metode verifikasi, kriteria selesai, batas biaya, dan batas persetujuan. Semakin jelas pembagian peran ini, otomasi Claude Code semakin mendekati sistem operasi pengembangan yang dapat direproduksi dan diaudit, melampaui sekadar tool pembuatan kode.

## FAQ

### Apa perbedaan Loop pada Claude Code dengan perulangan for·while biasa?
Perulangan biasa mengulang perintah yang didefinisikan dalam kode secara deterministik. Loop pada Claude Code adalah struktur kontrol agen tempat Agent mengamati kode dan keadaan eksternal, menalar tindakan berikutnya, menjalankan alat, memverifikasi hasil, lalu bekerja kembali sesuai kondisi penghentian.

### Kapan Turn-based Loop paling sesuai digunakan?
Cocok untuk tugas yang singkat, sekali jalan, dan hasilnya dapat segera ditinjau oleh pengguna. Namun, jika prosedur verifikasi berulang seperti UI, API, atau basis data, sebaiknya buat prosedur tersebut sebagai Skill atau Script agar Claude dapat melakukan verifikasi mandiri dengan standar yang sama.

### Apakah model evaluasi `/goal` memeriksa file dan hasil pengujian secara langsung?
Tidak. Model evaluasi tidak memanggil alat atau membaca file secara langsung, melainkan menilai kondisi Goal dan bukti yang terlihat dalam percakapan. Claude yang mengerjakan tugas harus mencantumkan perintah pengujian, kode keluar, file yang diubah, dan penyebab kegagalan dengan jelas dalam hasilnya.

### Apa saja yang harus ada dalam kondisi `/goal` yang baik?
Diperlukan status selesai yang dapat diukur, perintah atau alat untuk membuktikan status tersebut, cakupan yang boleh diubah dan cakupan yang dilarang, serta Hard stop seperti Turn, waktu, atau kegagalan beruntun maksimum. Kondisi seperti 'pengujian dan lint memiliki kode keluar 0 dan tidak ada Diff di luar jalur yang ditentukan' lebih baik daripada 'refactoring dengan rapi'.

### Apakah `/goal` memiliki Turn maksimum atau batas waktu otomatis?
Goal berlanjut hingga model evaluasi menentukan keberhasilan atau pengguna menghentikannya dengan `/goal clear`. Untuk membatasi anggaran eksekusi, Anda harus menyertakan klausul Turn atau waktu secara langsung dalam kondisi Goal, seperti 'hentikan setelah maksimum 12 turn atau 45 menit'.

### Jika menggunakan `/goal`, apakah izin alat juga otomatis diizinkan?
Tidak. `/goal` memulai Turn berikutnya secara otomatis, tetapi kebijakan izin untuk penulisan file, Shell, Git, dan Connector eksternal tetap berlaku. Jika perlu eksekusi tanpa pengawasan, pertimbangkan Auto mode, tetapi pekerjaan berisiko harus dikendalikan secara terpisah dengan aturan `ask` dan `deny`.

### Apa perbedaan terbesar antara `/loop` dan `/schedule`?
`/loop` adalah sarana Polling jangka pendek yang dijalankan berulang dalam sesi Claude Code dan komputer saat ini. `/schedule` menyimpan Prompt, Repository, Connector, dan Trigger sebagai Cloud Routine lalu menjalankannya di infrastruktur yang dikelola Anthropic, sehingga tidak memerlukan sesi terbuka atau laptop yang menyala.

### Jika komputer dimatikan, apakah `/loop` terus berjalan?
Umumnya tidak terus berjalan. `/loop` adalah pekerjaan dalam cakupan sesi dan Claude Code harus sedang berjalan. Untuk otomatisasi jangka panjang, gunakan Scheduler yang berkelanjutan seperti Cloud Routine, Desktop scheduled task, atau GitHub Actions.

### Mengapa Event Trigger lebih baik daripada Polling berbasis waktu?
Karena tidak membuat pemanggilan model yang tidak perlu saat tidak ada perubahan, dan dapat dijalankan segera setelah perubahan sebenarnya terjadi. Sistem yang dapat menerbitkan event seperti kegagalan CI, pembaruan PR, atau Alert lebih menguntungkan dari sisi biaya maupun latensi jika dihubungkan melalui GitHub Trigger atau Routine API.

### Mengapa prosedur verifikasi ditempatkan di `SKILL.md`, bukan di `CLAUDE.md`?
`CLAUDE.md` cocok untuk aturan singkat yang selalu diterapkan di seluruh proyek, sedangkan Skill cocok untuk mengelompokkan prosedur dan file pendukung yang hanya diperlukan pada tugas tertentu. Jika checklist verifikasi yang panjang dipisahkan sebagai Skill, ia hanya dimuat pada pekerjaan terkait dan dapat dijalankan ulang secara langsung.

### Apa perbedaan Dynamic Workflow dengan pemanggilan Subagent biasa?
Dalam metode Subagent biasa, Claude memilih pekerja berikutnya pada setiap Turn dan hasilnya menumpuk di Context. Dynamic Workflow memungkinkan JavaScript Script mengelola eksekusi paralel, percabangan, perulangan, dan hasil antara, sehingga Migration, Audit, dan verifikasi silang berskala besar dapat diorganisasi dengan lebih dapat direproduksi.

### Apakah menggunakan beberapa Agent selalu meningkatkan kualitas?
Tidak. Jika peran dan sudut pandangnya tumpang tindih, kesalahan yang sama dapat terulang dan hanya meningkatkan biaya. Nilai Agent paralel muncul ketika tanggung jawab dipisahkan seperti implementasi, desain pengujian, tinjauan keamanan, analisis regresi, dan Judge, serta setiap kesimpulan diwajibkan memiliki bukti independen.

### Bagaimana mencegah pekerjaan duplikat dalam Time-based atau Proactive Loop?
Anda harus menyimpan Idempotency key seperti Event ID, Commit SHA, Review Comment ID, serta status pemrosesan terakhir. Aturan untuk tidak memproses ulang pesan yang sudah dijawab, PR yang sudah dibuat, dan Commit yang sudah diproses harus disertakan dalam tahap verifikasi.

### Loop seperti apa yang baik untuk diautomatisasi pertama kali?
Pekerjaan yang diperiksa berulang kali oleh manusia, tetapi memiliki Side effect yang berisiko rendah dan status penyelesaiannya dapat diukur dengan jelas, adalah pilihan yang baik. Misalnya, aman untuk memulai dari ringkasan penyebab CI yang gagal pada PR, deteksi ketidaksesuaian antara dokumen dan kode, serta verifikasi test·lint yang telah ditentukan, lalu secara bertahap memperluas kewenangan untuk melakukan perbaikan dan Push.

## Sources

- [Rekayasa loop: Memulai dengan loop | Claude oleh Anthropic](https://claude.com/blog/getting-started-with-loops)
- [Perluas Claude dengan keterampilan - Dokumentasi Claude Code](https://code.claude.com/docs/en/skills)
- [Jaga agar Claude tetap bekerja menuju suatu tujuan - Dokumentasi Claude Code](https://code.claude.com/docs/en/goal)
- [Jalankan prompt sesuai jadwal - Dokumentasi Claude Code](https://code.claude.com/docs/en/scheduled-tasks)
- [Otomatiskan pekerjaan dengan rutinitas - Dokumentasi Claude Code](https://code.claude.com/docs/en/routines)
- [Orkestrasi subagen dalam skala besar dengan alur kerja dinamis - Dokumentasi Claude Code](https://code.claude.com/docs/en/workflows)
- [Memilih model Claude dan tingkat upaya di Claude Code | Claude oleh Anthropic](https://claude.com/blog/claude-model-and-effort-level-in-claude-code)
- [Konfigurasikan mode otomatis - Dokumentasi Claude Code](https://code.claude.com/docs/en/auto-mode-config)

## Images

![Robot AI dan dasbor kode dikelilingi panah loop serta ikon tujuan, waktu, keamanan, dan biaya](https://injoys.com/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsiZGF0YSI6MTg3OSwicHVyIjoiYmxvYl9pZCJ9fQ==--cac49ec584371c2261bd3272e7574ca38ecc1f85/ChatGPT%20Image%202026%E1%84%82%E1%85%A7%E1%86%AB%207%E1%84%8B%E1%85%AF%E1%86%AF%2016%E1%84%8B%E1%85%B5%E1%86%AF%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2006_56_28.webp)
![Agen AI dalam area terlindungi dengan verifikasi, penghentian paksa, gerbang izin, dan pemantauan sumber daya](https://injoys.com/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsiZGF0YSI6MTg4NiwicHVyIjoiYmxvYl9pZCJ9fQ==--e5ead4b7a604375b9c6a192eb3a981cf4c93b3c9/ChatGPT%20Image%202026%E1%84%82%E1%85%A7%E1%86%AB%207%E1%84%8B%E1%85%AF%E1%86%AF%2016%E1%84%8B%E1%85%B5%E1%86%AF%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2007_02_56.webp)