{"content_id":"z9qcc6lzi3","slug":"claude-code-loop-engineering-guide","locale":"id","schema_type":"TechArticle","category":"tutorial","category_name":"Tutorial","title":"Panduan Claude Code Loop Engineering: 4 Loop dan Desain Otomatisasi yang Aman","summary":"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.","author":{"name":"Injoys Admin","url":"https://injoys.com/ko/about"},"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."],"content_markdown":"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.\n\n## 1. Apa itu Loop dalam Claude Code\n\nLoop 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.\n\n```text\nMulai pekerjaan\n  ↓\nMemahami status dan kode\n  ↓\nMenyusun rencana\n  ↓\nMengubah kode atau menjalankan tool\n  ↓\nTes·verifikasi\n  ↓\nKondisi selesai terpenuhi?\n  ├─ Tidak: iterasi berikutnya\n  └─ Ya: selesai dan laporkan hasil\n```\n\nSaat membedakan Loop, empat pertanyaan berikut berguna.\n\n1. Apa yang memulai pekerjaan?\n2. Apa yang mengakhiri pekerjaan?\n3. Fitur Claude Code apa yang mengendalikan pengulangan?\n4. Jenis pekerjaan apa yang cocok?\n\nTidak 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.\n\n## 2. Perbandingan empat jenis Loop\n\n| Jenis | Kondisi mulai | Kondisi selesai | Fitur yang terutama digunakan | Pekerjaan yang cocok | Tanggung jawab yang diserahkan manusia |\n|---|---|---|---|---|---|\n| 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 |\n| 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 |\n| 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 |\n| 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 |\n\nInti 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.\n\n## 3. Turn-based Loop: menyerahkan prosedur verifikasi\n\nTurn-based Loop adalah bentuk dasar yang digunakan sebagian besar developer saat memakai Claude Code.\n\n```text\nHuman → Claude → Human → Claude\n```\n\nKetika 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.\n\n### Mengubah kode dan menyelesaikan fitur itu berbeda\n\nMeskipun Claude melaporkan “implementasi dan tes selesai”, dalam produk nyata masalah berikut masih bisa tersisa.\n\n- Status tidak berubah setelah tombol diklik.\n- Terjadi error di konsol browser.\n- Layout mobile rusak.\n- Atribut aksesibilitas hilang.\n- Tes lulus, tetapi alur browser nyata gagal.\n- File yang tidak terkait perubahan ikut dimodifikasi.\n\nKarena itu, kriteria selesai seharusnya bukan “kode telah diubah”, melainkan “perilaku telah dikonfirmasi dengan bukti eksternal”.\n\n### Menggunakan kembali verifikasi dengan `SKILL.md`\n\nSkill 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.\n\n```markdown\n---\nname: verify-ui-change\ndescription: Memverifikasi perubahan UI di lingkungan eksekusi nyata sebelum dianggap selesai.\n---\n\n# Verifikasi perubahan UI\n\n1. Jalankan server pengembangan.\n2. Buka layar yang diubah di browser.\n3. Operasikan kontrol baru secara nyata.\n4. Pastikan perubahan status yang diharapkan terjadi.\n5. Periksa error dan peringatan baru di konsol browser.\n6. Periksa aksesibilitas dan metrik performa utama.\n7. Jika gagal, perbaiki lalu verifikasi ulang dari awal.\n8. Laporkan bukti seperti perintah yang dijalankan, hasil, screenshot, dll.\n```\n\nSkill 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”.\n\n### Kekuatan bukti verifikasi\n\n| Bukti | Keandalan | Alasan |\n|---|---:|---|\n| Penjelasan Agent seperti “tampaknya normal” | Rendah | Hanya inferensi, bukan hasil eksekusi |\n| Diff kode dan peninjauan statis | Sedang | Perubahan terlihat, tetapi perilaku Runtime tidak terkonfirmasi |\n| Output tes nyata dan kode keluar | Tinggi | Ada hasil eksternal yang dapat direproduksi |\n| Interaksi browser, screenshot, hasil konsol·performa | Sangat tinggi | Memverifikasi langsung jalur pengguna dan status Runtime |\n| Review Agent independen dan CI mencapai kesimpulan yang sama | Sangat tinggi | Mengurangi bias konfirmasi diri dari Agent implementasi |\n\nDokumen 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.\n\n## 4. Goal-based Loop: menyerahkan penilaian selesai\n\nGoal-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.\n\n```text\nPengguna menetapkan Goal\n  ↓\nTurn kerja Claude\n  ↓\nModel evaluasi terpisah memeriksa kondisi selesai\n  ├─ Belum terpenuhi: menyampaikan alasannya ke Turn berikutnya\n  └─ Terpenuhi: Goal selesai\n```\n\n`/goal` didokumentasikan dapat digunakan pada Claude Code v2.1.139 atau lebih baru. Dalam satu sesi, hanya satu Goal yang dapat aktif.\n\n### Apa yang sebenarnya dilihat model evaluasi\n\nSetelah 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.\n\nKarena itu, Claude yang menjalankan pekerjaan harus meninggalkan bukti berikut dengan jelas dalam percakapan.\n\n- Perintah yang dijalankan\n- Jumlah tes dan hasil lulus·gagal\n- Kode keluar\n- Hasil build\n- Daftar file yang diubah\n- Penyebab kegagalan yang tersisa\n- Hasil konfirmasi bahwa batasan cakupan dipatuhi\n\nModel evaluasi menilai bukan “apa yang benar-benar terjadi”, melainkan “bukti apa yang terlihat dalam percakapan”.\n\n### Empat elemen Goal yang baik\n\nGoal yang baik mencakup empat elemen berikut.\n\n1. **Kondisi sukses yang terukur**: tes lulus, build sukses, antrean kosong, ambang skor tercapai\n2. **Metode verifikasi**: menyatakan perintah atau tool apa yang membuktikan sukses\n3. **Batasan cakupan perubahan**: direktori yang boleh diubah, file yang dilarang, efek samping yang diizinkan\n4. **Kondisi penghentian paksa**: jumlah Turn maksimum, waktu maksimum, jumlah kegagalan beruntun, berhenti saat error izin\n\n```text\n/goal Semua tes dan lint terkait auth berhasil,\ndan git diff hanya boleh mencakup src/auth serta file tes terkait.\nLaporkan hasil eksekusi dan kode keluar pada setiap Turn.\nJika mencapai maksimal 12 turn atau 45 menit, hentikan dan rangkum kegagalan yang tersisa.\n```\n\nKondisi 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.\n\n### Kondisi yang baik dan buruk\n\n| Kondisi baik | Kondisi buruk |\n|---|---|\n| `npm test` berakhir dengan kode keluar 0 | Membuat kode sempurna |\n| Semua 48 tes terkait autentikasi lulus | Meningkatkan pengalaman pengguna semaksimal mungkin |\n| Semua titik pemanggilan API diubah ke interface baru dan build berhasil | Melakukan refactoring ke struktur yang lebih baik |\n| Antrean isu target pemrosesan kosong dan hasil dicatat pada tiap isu | Menangani isu sebanyak mungkin |\n\nTujuan yang ambigu dapat berhenti terlalu cepat atau mengulang perbaikan tanpa akhir.\n\n### Pemeriksaan status dan penghentian\n\n- `/goal`: memeriksa kondisi aktif, waktu eksekusi, jumlah Turn evaluasi, penggunaan token, alasan evaluasi terbaru\n- `/goal clear`: menghentikan Goal aktif\n- Menetapkan Goal baru: mengganti Goal yang ada\n- `--resume` atau `--continue`: dapat memulihkan Goal yang belum selesai\n\nSaat dilanjutkan, kondisi tetap dipertahankan, tetapi baseline jumlah Turn, waktu, dan token dapat direset, sehingga sebaiknya Hard stop dikelola bersama metrik operasional.\n\n### `/goal` dan izin adalah hal terpisah\n\n`/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.\n\nUntuk 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.\n\n## 5. Time-based Loop: menyerahkan waktu eksekusi ulang\n\nJika Goal-based Loop menangani “kapan berhenti”, Time-based Loop menangani “kapan menjalankan lagi”. Ini cocok untuk pekerjaan yang status sistem eksternalnya berubah seiring waktu.\n\n- Memeriksa apakah ada review baru pada PR\n- Memeriksa apakah CI atau deployment selesai\n- Memeriksa status build berdurasi panjang\n- Meringkas pesan Slack setiap hari\n- Memeriksa item baru pada antrean isu\n\n### `/loop`: eksekusi berulang dalam sesi saat ini\n\n```text\n/loop 10m Periksa PR saat ini dan terapkan review baru,\nlalu jika ada CI yang gagal, analisis penyebabnya dan perbaiki.\n```\n\nBentuk utama yang dijelaskan dalam dokumen saat ini adalah sebagai berikut.\n\n| Input | Perilaku |\n|---|---|\n| `/loop 5m \u003cprompt\u003e` | Menjalankan Prompt pada interval tetap yang ditentukan |\n| `/loop \u003cprompt\u003e` | Claude memilih interval pada setiap pengulangan |\n| `/loop` | Menjalankan Prompt pemeliharaan built-in atau `loop.md` proyek |\n| `/loop 20m /review-pr 1234` | Menjalankan ulang Skill yang diizinkan pada interval yang ditentukan |\n\n`/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.\n\nKarena Jitter dapat diterapkan pada Scheduler sesi, ini mungkin tidak cocok untuk kebutuhan operasional yang “harus berjalan tepat pada jam tertentu”.\n\n### `/schedule`: Cloud Routine yang dikelola Anthropic\n\n`/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.\n\nTrigger yang didukung Routine adalah sebagai berikut.\n\n- Jadwal berulang\n- Jadwal sekali jalan pada waktu tertentu di masa depan\n- Panggilan API terautentikasi\n- Event GitHub Pull request atau Release\n\nBeberapa Trigger dapat dihubungkan ke satu Routine. Misalnya, PR Review Routine dapat dijalankan setiap malam sekaligus merespons event `pull_request.opened`.\n\n### Perbandingan `/loop` dan `/schedule`\n\n| Kategori | `/loop` | `/schedule` Routine |\n|---|---|---|\n| Lokasi eksekusi | Komputer dan sesi saat ini | Cloud yang dikelola Anthropic |\n| Eksekusi setelah komputer mati | Umumnya tidak bisa | Bisa |\n| Perlu sesi terbuka | Perlu | Tidak perlu |\n| File lokal yang belum di-commit | Dapat diakses | Tidak dapat diakses, Repository di-Clone ulang setiap eksekusi |\n| Interval minimum | 1 menit menurut dokumen resmi | 1 jam menurut dokumen resmi |\n| Persistensi | Berpusat pada sesi, pekerjaan berulang kedaluwarsa 7 hari | Routine yang disimpan di akun |\n| Prompt izin | Mewarisi kebijakan sesi saat ini | Eksekusi otonom tanpa persetujuan interaktif |\n| Penggunaan yang cocok | Pemantauan PR·deployment singkat | Otomasi operasional berkelanjutan |\n\n### Ketika Event lebih baik daripada Polling\n\nJika 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.\n\n```text\nCI gagal atau PR diperbarui\n  ↓\nGitHub Trigger atau Routine API\n  ↓\nClaude berjalan hanya saat diperlukan\n```\n\nDesain 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.\n\n### Syarat wajib pekerjaan berbasis waktu\n\n1. **Idempotensi**: meskipun event yang sama diterima beberapa kali, komentar duplikat, PR duplikat, atau deployment duplikat tidak boleh terjadi.\n2. **Status pemrosesan**: Last processed Event ID, Commit SHA, Review Comment ID, dll. harus dicatat.\n3. **Status selesai**: harus bisa menilai selesai seperti PR merge·close, Queue empty, Deploy success·rollback.\n4. **Cakupan penulisan**: efek samping harus dibatasi, misalnya komentar diizinkan, Merge dilarang, hanya Branch `claude/*` yang boleh Push.\n5. **Penanganan kegagalan**: diperlukan aturan retry dan Escalation saat layanan eksternal bermasalah, autentikasi kedaluwarsa, Rate limit, atau izin kurang.\n\n## 6. Proactive Loop: menyerahkan penemuan pekerjaan dan orkestrasi\n\nProactive Loop bukan satu perintah, melainkan arsitektur otomasi selalu aktif yang menggabungkan beberapa fitur.\n\n```text\nTrigger\n+ Goal\n+ Skills\n+ Dynamic Workflow\n+ Auto mode\n+ Tool Repository·Connector·Browser·CI\n```\n\nMeski manusia tidak memasukkan Prompt secara real-time, pekerjaan baru terdeteksi, diproses, diverifikasi, dan hasilnya dilaporkan.\n\n### Contoh: penanganan otomatis feedback bug\n\n```text\nMenerima GitHub Issue atau feedback Slack\n  ↓\nKlasifikasi duplikasi·prioritas·kemungkinan reproduksi\n  ↓\nMembuat tes reproduksi\n  ↓\nMenjelajahi kandidat solusi\n  ↓\nMengimplementasikan solusi yang dipilih\n  ↓\nReview Agent independen mencari contoh tandingan\n  ↓\nVerifikasi tes·build·keamanan\n  ↓\nDraft PR dan laporan hasil\n```\n\nTanggung jawab tiap komponen adalah sebagai berikut.\n\n| Komponen | Tanggung jawab |\n|---|---|\n| Trigger atau `/schedule` | Menentukan kapan pekerjaan baru dimulai |\n| `/goal` | Mendefinisikan apa status selesai pada eksekusi ini |\n| Skill | Menstandarkan prosedur reproduksi, implementasi, verifikasi, pelaporan |\n| Dynamic Workflow | Eksekusi paralel banyak Subagent dan percabangan kondisi |\n| Auto mode | Menjalankan pemanggilan tool yang diizinkan tanpa menunggu persetujuan |\n| Permission policy | Mengunci cakupan larangan·persetujuan·izin otomatis |\n\n### Dynamic Workflow dan Worktree\n\nDynamic 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.\n\n```text\nWorkflow Script\n  ├─ Agent A: Analisis kebutuhan\n  ├─ Agent B: Desain tes\n  ├─ Agent C: Eksplorasi kandidat implementasi\n  ├─ Agent D: Review keamanan\n  └─ Judge: Perbandingan berbasis bukti\n```\n\nKarena 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.\n\nJika perlu menguji beberapa kandidat implementasi secara bersamaan, ruang kerja dapat dipisahkan dengan Git Worktree.\n\n```text\nrepo/\nworktree-solution-a/\nworktree-solution-b/\nworktree-solution-c/\n```\n\nJika 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.\n\n### Lebih banyak Agent tidak selalu lebih baik\n\nJika 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.\n\nDynamic Workflow cocok dalam kasus berikut.\n\n- Migration yang menerapkan transformasi sama pada ratusan file\n- Audit keamanan·kualitas seluruh codebase\n- Perbandingan Plan dari beberapa perspektif independen\n- Research yang harus memproses banyak item secara terbagi dan diverifikasi silang\n- Pekerjaan yang sulit memuat semua hasil antara dalam Context satu Agent\n\nUntuk perbaikan bug kecil, refactoring satu file, atau penambahan tes sederhana, Turn-based Loop biasa atau `/goal` lebih baik.\n\n## 7. Sistem untuk menjaga kualitas kode dalam Loop\n\nKualitas hasil Loop sangat dipengaruhi bukan hanya oleh model itu sendiri, tetapi juga oleh sistem verifikasi di sekitar model.\n\n### 7.1 Merapikan codebase\n\nClaude 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.\n\nFondasi wajibnya adalah sebagai berikut.\n\n- Formatter dan lint\n- Batas direktori dan modul yang jelas\n- Unit·Integration·E2E Test yang dapat dipercaya\n- Pembedaan antara API yang digunakan dan Deprecated API\n- Aturan pengembangan per proyek\n- Lingkungan Build·Dev yang dapat direproduksi\n\n### 7.2 Membuat Definition of Done berdasarkan jenis perubahan\n\n| Jenis perubahan | Verifikasi minimum |\n|---|---|\n| API | Tes kontrak, kompatibilitas mundur, pembaruan contoh Schema·dokumen |\n| Frontend | Operasi browser nyata, error konsol, aksesibilitas, layar responsif |\n| Database | Forward·Rollback Migration, cakupan Lock, rencana eksekusi |\n| Dependency | Build, tes regresi utama, pemeriksaan License·Security |\n| Infrastructure | Plan Diff, izin minimum, Rollback, pemeriksaan paparan informasi rahasia |\n\nDaripada mengulang panjang kriteria ini dalam Prompt setiap kali, lebih baik menguncinya sebagai Skill, Hook, Script, atau CI Rule.\n\n### 7.3 Menyediakan dokumen terbaru dan versi yang akurat\n\nLoop 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.\n\n### 7.4 Memisahkan Agent implementasi dan Review Agent\n\nAgent yang mengimplementasikan sudah dipengaruhi oleh desain dan penalaran yang dipilihnya. Review Agent dengan Context baru dapat mengajukan pertanyaan berikut secara lebih independen.\n\n- Apakah tes dilemahkan agar lulus?\n- Apakah file di luar cakupan diubah?\n- Apakah batas keamanan rusak?\n- Apakah tes jalur gagal dan nilai batas terlewat?\n- Apakah muncul regresi pada fitur yang sudah ada?\n\nReview 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”.\n\n### 7.5 Menghubungkan kegagalan individual ke perbaikan sistem\n\nJika error yang sama berulang, tidak cukup hanya memperbaiki hasil tersebut. Agar jenis kegagalan itu sulit terulang, salah satu hal berikut harus diubah.\n\n- Menambahkan Regression Test\n- Memperkuat prosedur verifikasi Skill\n- Menambahkan aturan `CLAUDE.md`\n- Menambahkan Hook atau lint Rule\n- Menambahkan aturan Deny izin\n- Memperkuat kondisi selesai Goal\n- Melengkapi Review Checklist\n\nLoop Engineering yang baik bukan pekerjaan memperbaiki satu kegagalan, melainkan **pekerjaan membangun sistem yang membuat jenis kegagalan itu sulit muncul kembali**.\n\n## 8. Pengelolaan Token dan biaya\n\nBiaya Loop dapat meningkat jauh lebih besar daripada Prompt tunggal.\n\n```text\nTotal biaya ≈\nBiaya Turn Agent utama\n+ Biaya evaluasi Goal\n+ Biaya Subagent\n+ Biaya iterasi Workflow\n+ Biaya Context untuk membaca hasil tool\n+ Frekuensi eksekusi berbasis waktu\n```\n\nPenagihan yang tepat berbeda tergantung Plan, Model, dan Provider, tetapi prinsip yang menentukan struktur biaya sama.\n\n### Prinsip praktis untuk mengurangi biaya\n\n1. **Jangan memakai Loop untuk pekerjaan kecil.** Typo, perubahan nama, dan error tipe pada satu file ditangani dengan satu Turn.\n2. **Tetapkan kondisi sukses bersama Hard stop.** Pertimbangkan sukses, maksimum Turn, maksimum waktu, kegagalan beruntun, dan error izin.\n3. **Uji Workflow skala besar pada cakupan kecil.** Verifikasi biaya dan kualitas dengan 5 file, satu direktori, atau sebagian Issue, lalu perluas.\n4. **Tangani pekerjaan deterministik dengan Script.** Penggantian AST, transformasi JSON, Formatting, dan pembuatan format tetap lebih murah dan dapat direproduksi dengan Script yang terverifikasi.\n5. **Sesuaikan siklus Polling dengan frekuensi perubahan nyata.** Gunakan Event Trigger jika memungkinkan.\n6. **Amati penggunaan saat berjalan.** Periksa penggunaan Skill·Subagent·MCP·Turn·Token di `/usage`, `/goal`, `/workflows`.\n7. **Jika error yang sama berulang, jangan terus mencoba ulang.** Tetapkan batas kegagalan beruntun dan lakukan Escalation ke manusia.\n\n### Model dan Effort adalah tuas yang berbeda\n\n- **Model** mengubah kemampuan penalaran dasar dan cakupan masalah yang dapat diselesaikan.\n- **Effort** mengubah jumlah file yang dibaca, jumlah tool yang digunakan, luas verifikasi, dan sejauh mana pekerjaan multi-tahap didorong sampai selesai.\n\nJika 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.\n\n## 9. Izin dan batas keamanan\n\nDesain paling berbahaya dalam Proactive Loop adalah memberi Agent izin luas dan menetapkan kondisi sukses serta kondisi berhenti secara longgar.\n\nAuto 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.\n\n### Contoh lapisan izin\n\n| Level | Contoh |\n|---|---|\n| Diizinkan otomatis | Membaca kode, tes·lint·Build, analisis, membuat Branch `claude/*`, membuat Draft PR |\n| Persetujuan manusia | Menerapkan ke Default Branch, deployment produksi, menerapkan DB Migration, mengirim pesan pelanggan eksternal |\n| Selalu dilarang | Force push, menampilkan Secret, menghapus data produksi, bypass izin, menghapus audit log |\n\nLebih aman menguncinya sebagai Rule `ask`·`deny` permanen daripada sekali berkata “jangan Push” dalam percakapan. Aturan percakapan dapat melemah karena kompresi Context atau perubahan sesi.\n\nCloud Routine melakukan Clone Repository baru pada setiap eksekusi dan bekerja dengan izin GitHub·Connector yang terhubung. Cakupan berikut harus diminimalkan.\n\n- Repository dan Branch yang dapat diakses\n- Network Domain yang diizinkan\n- Connector yang digunakan\n- Variabel lingkungan dan Secret\n- Izin tulis ke sistem eksternal\n- Cakupan pembuatan PR·Push·Merge\n\nStatus “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.\n\n## 10. Template desain Loop untuk proyek pengembangan\n\nYAML berikut bukan sintaks Claude Code nyata, melainkan Template untuk review desain.\n\n```yaml\ntrigger:\n  type: manual | interval | schedule | github_event | api_event\n\nscope:\n  repositories:\n    - target-repository\n  allowed_paths:\n    - src/**\n    - tests/**\n  prohibited_paths:\n    - production/**\n    - secrets/**\n\ntask:\n  objective: tujuan yang akan diubah atau diproses\n  input: Issue, Event, File, atau status yang baru masuk\n\nverification:\n  commands:\n    - unit-test\n    - integration-test\n    - lint\n    - build\n  runtime_checks:\n    - browser-interaction\n    - console-errors\n    - accessibility\n  evidence:\n    - command-output\n    - exit-code\n    - test-summary\n    - screenshots\n\nsuccess:\n  condition: status selesai yang dapat dinilai benar atau salah\n\nstop:\n  max_turns: 12\n  max_duration_minutes: 45\n  max_consecutive_failures: 3\n  stop_on_permission_error: true\n  escalate_on_external_outage: true\n\nside_effects:\n  idempotency_key: event-id-or-commit-sha\n  allow_branch_push: claude/*\n  require_human_for_merge: true\n  require_human_for_deploy: true\n\nreview:\n  independent_agent: true\n  adversarial_review: true\n\nobservability:\n  report_progress: true\n  report_token_usage: true\n  report_changed_files: true\n  report_remaining_failures: true\n```\n\nItem terpenting bukan kalimat Prompt itu sendiri, melainkan lima hal berikut.\n\n```text\nTrigger\nVerifier\nSuccess condition\nHard stop\nPermission boundary\n```\n\n## 11. Loop mana yang harus dipilih\n\n| Situasi | Metode yang disarankan |\n|---|---|\n| Pekerjaan yang selesai dengan satu perbaikan dan verifikasi | Turn-based |\n| Pekerjaan yang perlu dicoba beberapa kali tetapi status selesai jelas | `/goal` |\n| Pekerjaan yang perlu menunggu sebentar status CI·PR·deployment eksternal | `/loop` |\n| Pekerjaan yang harus tetap berjalan berulang meski laptop ditutup | `/schedule` Routine |\n| Pekerjaan yang harus segera merespons event GitHub atau Alert | Event-triggered Routine |\n| Pekerjaan yang harus memproses ratusan item secara paralel dan diverifikasi silang | Dynamic Workflow |\n| Transformasi dengan aturan input dan output yang sepenuhnya deterministik | Script atau CI Job |\n\nUrutan pemilihan harus berdasarkan “struktur kontrol paling sederhana yang mencapai tujuan”, bukan “fitur paling kuat”.\n\n## 12. Urutan adopsi yang aman\n\n1. Pilih satu pekerjaan bottleneck yang berulang kali diperiksa manusia.\n2. Pertama buat prosedur verifikasi sebagai Skill, Script, atau CI.\n3. Stabilkan kualitas verifikasi dengan cara Turn-based.\n4. Jika status selesai jelas, tambahkan `/goal`.\n5. Gunakan `/loop` hanya saat perlu menunggu status eksternal.\n6. Jika perlu eksekusi jangka panjang, pindahkan ke `/schedule` Routine.\n7. Perluas ke Dynamic Workflow dan Proactive Loop hanya setelah idempotensi, izin, dan biaya terverifikasi.\n\n## 13. Kesalahpahaman yang sering terjadi\n\n| Kesalahpahaman | Interpretasi yang tepat |\n|---|---|\n| Loop adalah eksekusi tanpa batas | Struktur iterasi terbatas yang memiliki kondisi sukses dan Hard stop |\n| Laporan selesai dari Agent adalah verifikasi | Dibutuhkan output perintah eksternal, kode keluar, dan hasil Runtime |\n| `/goal` otomatis mengizinkan semua izin | Hanya memulai Turn berikutnya secara otomatis; kebijakan izin terpisah |\n| `/loop` adalah Scheduler operasional jangka panjang | Berpusat pada sesi, dengan kedaluwarsa 7 hari dan batasan lingkungan eksekusi |\n| Semakin banyak Agent, hasilnya semakin baik | Nilai paralelisasi muncul hanya ketika peran·perspektif·verifikasi berbeda |\n| Semua pekerjaan berulang harus dilakukan LLM | Bagian deterministik lebih murah dan lebih dapat direproduksi dengan Script |\n\n## Kesimpulan\n\nLoop 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**.\n\nLLM 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.","content_html":"\u003cp\u003eLoop pada Claude Code bukan sekadar fitur untuk menjalankan model lebih lama. Intinya adalah menempatkan \u003cstrong\u003eTrigger, Verifier, Success condition, Hard stop, Permission boundary\u003c/strong\u003e 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.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#1-apa-itu-loop-dalam-claude-code\" class=\"anchor\" id=\"1-apa-itu-loop-dalam-claude-code\"\u003e\u003c/a\u003e1. Apa itu Loop dalam Claude Code\u003c/h2\u003e\n\u003cp\u003eLoop di sini bukan pernyataan \u003ccode\u003efor\u003c/code\u003e atau \u003ccode\u003ewhile\u003c/code\u003e 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.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eMulai pekerjaan\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eMemahami status dan kode\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eMenyusun rencana\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eMengubah kode atau menjalankan tool\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eTes·verifikasi\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eKondisi selesai terpenuhi?\n\u003c/span\u003e\u003cspan\u003e  ├─ Tidak: iterasi berikutnya\n\u003c/span\u003e\u003cspan\u003e  └─ Ya: selesai dan laporkan hasil\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eSaat membedakan Loop, empat pertanyaan berikut berguna.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eApa yang memulai pekerjaan?\u003c/li\u003e\n\u003cli\u003eApa yang mengakhiri pekerjaan?\u003c/li\u003e\n\u003cli\u003eFitur Claude Code apa yang mengendalikan pengulangan?\u003c/li\u003e\n\u003cli\u003eJenis pekerjaan apa yang cocok?\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eTidak 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.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#2-perbandingan-empat-jenis-loop\" class=\"anchor\" id=\"2-perbandingan-empat-jenis-loop\"\u003e\u003c/a\u003e2. Perbandingan empat jenis Loop\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eJenis\u003c/th\u003e\n\u003cth\u003eKondisi mulai\u003c/th\u003e\n\u003cth\u003eKondisi selesai\u003c/th\u003e\n\u003cth\u003eFitur yang terutama digunakan\u003c/th\u003e\n\u003cth\u003ePekerjaan yang cocok\u003c/th\u003e\n\u003cth\u003eTanggung jawab yang diserahkan manusia\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eTurn-based\u003c/td\u003e\n\u003ctd\u003ePrompt pengguna\u003c/td\u003e\n\u003ctd\u003eSaat Claude menilai selesai atau membutuhkan informasi tambahan\u003c/td\u003e\n\u003ctd\u003ePercakapan umum, Skills, tool tes·browser\u003c/td\u003e\n\u003ctd\u003eImplementasi·perbaikan singkat dan sekali jalan\u003c/td\u003e\n\u003ctd\u003eProsedur verifikasi berulang\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eGoal-based\u003c/td\u003e\n\u003ctd\u003ePengguna menetapkan kondisi selesai\u003c/td\u003e\n\u003ctd\u003eModel evaluasi mengonfirmasi kondisi terpenuhi atau pengguna menghentikan\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e/goal\u003c/code\u003e, Auto mode jika perlu\u003c/td\u003e\n\u003ctd\u003ePekerjaan dengan status selesai yang dapat diukur seperti tes·build·migrasi\u003c/td\u003e\n\u003ctd\u003ePenilaian selesai\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eTime-based\u003c/td\u003e\n\u003ctd\u003eWaktu·interval·jadwal yang ditentukan\u003c/td\u003e\n\u003ctd\u003ePengguna membatalkan atau pekerjaan eksternal selesai\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e/loop\u003c/code\u003e, \u003ccode\u003e/schedule\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003ePemantauan PR·CI·deployment, ringkasan berkala, Polling status\u003c/td\u003e\n\u003ctd\u003eWaktu eksekusi berikutnya\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eProactive\u003c/td\u003e\n\u003ctd\u003eJadwal, API, event GitHub, dll.\u003c/td\u003e\n\u003ctd\u003eTujuan masing-masing pekerjaan terpenuhi, Routine dinonaktifkan\u003c/td\u003e\n\u003ctd\u003eRoutines, \u003ccode\u003e/goal\u003c/code\u003e, Skills, Dynamic Workflows, Auto mode\u003c/td\u003e\n\u003ctd\u003ePekerjaan berkelanjutan seperti klasifikasi isu, penanganan bug, migrasi skala besar\u003c/td\u003e\n\u003ctd\u003ePenemuan pekerjaan, eksekusi Prompt, orkestrasi\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eInti dari klasifikasi ini bukan “seberapa pintar AI”, melainkan \u003cstrong\u003etanggung jawab kontrol apa yang diserahkan manusia kepada sistem\u003c/strong\u003e. 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.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#3-turn-based-loop-menyerahkan-prosedur-verifikasi\" class=\"anchor\" id=\"3-turn-based-loop-menyerahkan-prosedur-verifikasi\"\u003e\u003c/a\u003e3. Turn-based Loop: menyerahkan prosedur verifikasi\u003c/h2\u003e\n\u003cp\u003eTurn-based Loop adalah bentuk dasar yang digunakan sebagian besar developer saat memakai Claude Code.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eHuman → Claude → Human → Claude\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eKetika 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.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#mengubah-kode-dan-menyelesaikan-fitur-itu-berbeda\" class=\"anchor\" id=\"mengubah-kode-dan-menyelesaikan-fitur-itu-berbeda\"\u003e\u003c/a\u003eMengubah kode dan menyelesaikan fitur itu berbeda\u003c/h3\u003e\n\u003cp\u003eMeskipun Claude melaporkan “implementasi dan tes selesai”, dalam produk nyata masalah berikut masih bisa tersisa.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eStatus tidak berubah setelah tombol diklik.\u003c/li\u003e\n\u003cli\u003eTerjadi error di konsol browser.\u003c/li\u003e\n\u003cli\u003eLayout mobile rusak.\u003c/li\u003e\n\u003cli\u003eAtribut aksesibilitas hilang.\u003c/li\u003e\n\u003cli\u003eTes lulus, tetapi alur browser nyata gagal.\u003c/li\u003e\n\u003cli\u003eFile yang tidak terkait perubahan ikut dimodifikasi.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eKarena itu, kriteria selesai seharusnya bukan “kode telah diubah”, melainkan “perilaku telah dikonfirmasi dengan bukti eksternal”.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#menggunakan-kembali-verifikasi-dengan-skillmd\" class=\"anchor\" id=\"menggunakan-kembali-verifikasi-dengan-skillmd\"\u003e\u003c/a\u003eMenggunakan kembali verifikasi dengan \u003ccode\u003eSKILL.md\u003c/code\u003e\u003c/h3\u003e\n\u003cp\u003eSkill adalah cara menyimpan instruksi dan prosedur yang digunakan berulang kali di \u003ccode\u003eSKILL.md\u003c/code\u003e. Claude dapat memuatnya otomatis dengan menilai relevansinya, atau menjalankannya langsung dengan \u003ccode\u003e/skill-name\u003c/code\u003e. Daripada selalu memasukkan prosedur operasi yang panjang ke \u003ccode\u003eCLAUDE.md\u003c/code\u003e, memisahkannya agar Skill hanya dimuat saat diperlukan dapat menggunakan konteks dengan lebih efisien.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e---\n\u003c/span\u003e\u003cspan\u003ename: verify-ui-change\n\u003c/span\u003e\u003cspan\u003edescription: Memverifikasi perubahan UI di lingkungan eksekusi nyata sebelum dianggap selesai.\n\u003c/span\u003e\u003cspan\u003e---\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e# Verifikasi perubahan UI\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e1. Jalankan server pengembangan.\n\u003c/span\u003e\u003cspan\u003e2. Buka layar yang diubah di browser.\n\u003c/span\u003e\u003cspan\u003e3. Operasikan kontrol baru secara nyata.\n\u003c/span\u003e\u003cspan\u003e4. Pastikan perubahan status yang diharapkan terjadi.\n\u003c/span\u003e\u003cspan\u003e5. Periksa error dan peringatan baru di konsol browser.\n\u003c/span\u003e\u003cspan\u003e6. Periksa aksesibilitas dan metrik performa utama.\n\u003c/span\u003e\u003cspan\u003e7. Jika gagal, perbaiki lalu verifikasi ulang dari awal.\n\u003c/span\u003e\u003cspan\u003e8. Laporkan bukti seperti perintah yang dijalankan, hasil, screenshot, dll.\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eSkill yang baik berisi checklist yang dapat dieksekusi, bukan imbauan abstrak. “Periksa dengan lebih hati-hati” jauh lebih lemah daripada aturan “pastikan \u003ccode\u003enpm test\u003c/code\u003e berakhir dengan kode keluar 0”.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#kekuatan-bukti-verifikasi\" class=\"anchor\" id=\"kekuatan-bukti-verifikasi\"\u003e\u003c/a\u003eKekuatan bukti verifikasi\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eBukti\u003c/th\u003e\n\u003cth\u003eKeandalan\u003c/th\u003e\n\u003cth\u003eAlasan\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003ePenjelasan Agent seperti “tampaknya normal”\u003c/td\u003e\n\u003ctd\u003eRendah\u003c/td\u003e\n\u003ctd\u003eHanya inferensi, bukan hasil eksekusi\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eDiff kode dan peninjauan statis\u003c/td\u003e\n\u003ctd\u003eSedang\u003c/td\u003e\n\u003ctd\u003ePerubahan terlihat, tetapi perilaku Runtime tidak terkonfirmasi\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eOutput tes nyata dan kode keluar\u003c/td\u003e\n\u003ctd\u003eTinggi\u003c/td\u003e\n\u003ctd\u003eAda hasil eksternal yang dapat direproduksi\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eInteraksi browser, screenshot, hasil konsol·performa\u003c/td\u003e\n\u003ctd\u003eSangat tinggi\u003c/td\u003e\n\u003ctd\u003eMemverifikasi langsung jalur pengguna dan status Runtime\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eReview Agent independen dan CI mencapai kesimpulan yang sama\u003c/td\u003e\n\u003ctd\u003eSangat tinggi\u003c/td\u003e\n\u003ctd\u003eMengurangi bias konfirmasi diri dari Agent implementasi\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eDokumen resmi Claude Code juga menjelaskan bundled Skill seperti \u003ccode\u003e/run\u003c/code\u003e untuk memeriksa aplikasi yang sedang berjalan dan \u003ccode\u003e/verify\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#4-goal-based-loop-menyerahkan-penilaian-selesai\" class=\"anchor\" id=\"4-goal-based-loop-menyerahkan-penilaian-selesai\"\u003e\u003c/a\u003e4. Goal-based Loop: menyerahkan penilaian selesai\u003c/h2\u003e\n\u003cp\u003eGoal-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.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003ePengguna menetapkan Goal\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eTurn kerja Claude\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eModel evaluasi terpisah memeriksa kondisi selesai\n\u003c/span\u003e\u003cspan\u003e  ├─ Belum terpenuhi: menyampaikan alasannya ke Turn berikutnya\n\u003c/span\u003e\u003cspan\u003e  └─ Terpenuhi: Goal selesai\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e\u003ccode\u003e/goal\u003c/code\u003e didokumentasikan dapat digunakan pada Claude Code v2.1.139 atau lebih baru. Dalam satu sesi, hanya satu Goal yang dapat aktif.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#apa-yang-sebenarnya-dilihat-model-evaluasi\" class=\"anchor\" id=\"apa-yang-sebenarnya-dilihat-model-evaluasi\"\u003e\u003c/a\u003eApa yang sebenarnya dilihat model evaluasi\u003c/h3\u003e\n\u003cp\u003eSetelah setiap Turn selesai, small fast model terpisah melihat kondisi selesai dan isi percakapan, lalu menilai \u003ccode\u003eterpenuhi\u003c/code\u003e atau \u003ccode\u003ebelum terpenuhi\u003c/code\u003e. Pengaturan default adalah model evaluasi keluarga Haiku. Batasan pentingnya adalah model evaluasi tidak membaca file secara langsung atau menjalankan tes terpisah.\u003c/p\u003e\n\u003cp\u003eKarena itu, Claude yang menjalankan pekerjaan harus meninggalkan bukti berikut dengan jelas dalam percakapan.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003ePerintah yang dijalankan\u003c/li\u003e\n\u003cli\u003eJumlah tes dan hasil lulus·gagal\u003c/li\u003e\n\u003cli\u003eKode keluar\u003c/li\u003e\n\u003cli\u003eHasil build\u003c/li\u003e\n\u003cli\u003eDaftar file yang diubah\u003c/li\u003e\n\u003cli\u003ePenyebab kegagalan yang tersisa\u003c/li\u003e\n\u003cli\u003eHasil konfirmasi bahwa batasan cakupan dipatuhi\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eModel evaluasi menilai bukan “apa yang benar-benar terjadi”, melainkan “bukti apa yang terlihat dalam percakapan”.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#empat-elemen-goal-yang-baik\" class=\"anchor\" id=\"empat-elemen-goal-yang-baik\"\u003e\u003c/a\u003eEmpat elemen Goal yang baik\u003c/h3\u003e\n\u003cp\u003eGoal yang baik mencakup empat elemen berikut.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eKondisi sukses yang terukur\u003c/strong\u003e: tes lulus, build sukses, antrean kosong, ambang skor tercapai\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMetode verifikasi\u003c/strong\u003e: menyatakan perintah atau tool apa yang membuktikan sukses\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eBatasan cakupan perubahan\u003c/strong\u003e: direktori yang boleh diubah, file yang dilarang, efek samping yang diizinkan\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eKondisi penghentian paksa\u003c/strong\u003e: jumlah Turn maksimum, waktu maksimum, jumlah kegagalan beruntun, berhenti saat error izin\u003c/li\u003e\n\u003c/ol\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e/goal Semua tes dan lint terkait auth berhasil,\n\u003c/span\u003e\u003cspan\u003edan git diff hanya boleh mencakup src/auth serta file tes terkait.\n\u003c/span\u003e\u003cspan\u003eLaporkan hasil eksekusi dan kode keluar pada setiap Turn.\n\u003c/span\u003e\u003cspan\u003eJika mencapai maksimal 12 turn atau 45 menit, hentikan dan rangkum kegagalan yang tersisa.\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eKondisi selesai inti dari \u003ccode\u003e/goal\u003c/code\u003e itu sendiri adalah penilaian sukses dari model evaluasi atau \u003ccode\u003e/goal clear\u003c/code\u003e dari pengguna. Jika ingin memaksa batas Turn·waktu, batas tersebut harus dinyatakan di dalam kondisi Goal.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#kondisi-yang-baik-dan-buruk\" class=\"anchor\" id=\"kondisi-yang-baik-dan-buruk\"\u003e\u003c/a\u003eKondisi yang baik dan buruk\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eKondisi baik\u003c/th\u003e\n\u003cth\u003eKondisi buruk\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003enpm test\u003c/code\u003e berakhir dengan kode keluar 0\u003c/td\u003e\n\u003ctd\u003eMembuat kode sempurna\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eSemua 48 tes terkait autentikasi lulus\u003c/td\u003e\n\u003ctd\u003eMeningkatkan pengalaman pengguna semaksimal mungkin\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eSemua titik pemanggilan API diubah ke interface baru dan build berhasil\u003c/td\u003e\n\u003ctd\u003eMelakukan refactoring ke struktur yang lebih baik\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eAntrean isu target pemrosesan kosong dan hasil dicatat pada tiap isu\u003c/td\u003e\n\u003ctd\u003eMenangani isu sebanyak mungkin\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eTujuan yang ambigu dapat berhenti terlalu cepat atau mengulang perbaikan tanpa akhir.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#pemeriksaan-status-dan-penghentian\" class=\"anchor\" id=\"pemeriksaan-status-dan-penghentian\"\u003e\u003c/a\u003ePemeriksaan status dan penghentian\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ccode\u003e/goal\u003c/code\u003e: memeriksa kondisi aktif, waktu eksekusi, jumlah Turn evaluasi, penggunaan token, alasan evaluasi terbaru\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003e/goal clear\u003c/code\u003e: menghentikan Goal aktif\u003c/li\u003e\n\u003cli\u003eMenetapkan Goal baru: mengganti Goal yang ada\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003e--resume\u003c/code\u003e atau \u003ccode\u003e--continue\u003c/code\u003e: dapat memulihkan Goal yang belum selesai\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eSaat dilanjutkan, kondisi tetap dipertahankan, tetapi baseline jumlah Turn, waktu, dan token dapat direset, sehingga sebaiknya Hard stop dikelola bersama metrik operasional.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#goal-dan-izin-adalah-hal-terpisah\" class=\"anchor\" id=\"goal-dan-izin-adalah-hal-terpisah\"\u003e\u003c/a\u003e\u003ccode\u003e/goal\u003c/code\u003e dan izin adalah hal terpisah\u003c/h3\u003e\n\u003cp\u003e\u003ccode\u003e/goal\u003c/code\u003e 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.\u003c/p\u003e\n\u003cp\u003eUntuk 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 \u003ccode\u003eask\u003c/code\u003e serta \u003ccode\u003edeny\u003c/code\u003e yang eksplisit diterapkan sebelum classifier.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#5-time-based-loop-menyerahkan-waktu-eksekusi-ulang\" class=\"anchor\" id=\"5-time-based-loop-menyerahkan-waktu-eksekusi-ulang\"\u003e\u003c/a\u003e5. Time-based Loop: menyerahkan waktu eksekusi ulang\u003c/h2\u003e\n\u003cp\u003eJika Goal-based Loop menangani “kapan berhenti”, Time-based Loop menangani “kapan menjalankan lagi”. Ini cocok untuk pekerjaan yang status sistem eksternalnya berubah seiring waktu.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eMemeriksa apakah ada review baru pada PR\u003c/li\u003e\n\u003cli\u003eMemeriksa apakah CI atau deployment selesai\u003c/li\u003e\n\u003cli\u003eMemeriksa status build berdurasi panjang\u003c/li\u003e\n\u003cli\u003eMeringkas pesan Slack setiap hari\u003c/li\u003e\n\u003cli\u003eMemeriksa item baru pada antrean isu\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\u003ca href=\"#loop-eksekusi-berulang-dalam-sesi-saat-ini\" class=\"anchor\" id=\"loop-eksekusi-berulang-dalam-sesi-saat-ini\"\u003e\u003c/a\u003e\u003ccode\u003e/loop\u003c/code\u003e: eksekusi berulang dalam sesi saat ini\u003c/h3\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e/loop 10m Periksa PR saat ini dan terapkan review baru,\n\u003c/span\u003e\u003cspan\u003elalu jika ada CI yang gagal, analisis penyebabnya dan perbaiki.\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eBentuk utama yang dijelaskan dalam dokumen saat ini adalah sebagai berikut.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eInput\u003c/th\u003e\n\u003cth\u003ePerilaku\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/loop 5m \u0026lt;prompt\u0026gt;\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eMenjalankan Prompt pada interval tetap yang ditentukan\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/loop \u0026lt;prompt\u0026gt;\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eClaude memilih interval pada setiap pengulangan\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/loop\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eMenjalankan Prompt pemeliharaan built-in atau \u003ccode\u003eloop.md\u003c/code\u003e proyek\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/loop 20m /review-pr 1234\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eMenjalankan ulang Skill yang diizinkan pada interval yang ditentukan\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e\u003ccode\u003e/loop\u003c/code\u003e 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 \u003ccode\u003e--resume\u003c/code\u003e atau \u003ccode\u003e--continue\u003c/code\u003e, tetapi pekerjaan berulang pada dasarnya kedaluwarsa 7 hari setelah dibuat. Siklus yang terlewat juga tidak dijalankan mundur semuanya.\u003c/p\u003e\n\u003cp\u003eKarena Jitter dapat diterapkan pada Scheduler sesi, ini mungkin tidak cocok untuk kebutuhan operasional yang “harus berjalan tepat pada jam tertentu”.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#schedule-cloud-routine-yang-dikelola-anthropic\" class=\"anchor\" id=\"schedule-cloud-routine-yang-dikelola-anthropic\"\u003e\u003c/a\u003e\u003ccode\u003e/schedule\u003c/code\u003e: Cloud Routine yang dikelola Anthropic\u003c/h3\u003e\n\u003cp\u003e\u003ccode\u003e/schedule\u003c/code\u003e 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.\u003c/p\u003e\n\u003cp\u003eTrigger yang didukung Routine adalah sebagai berikut.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eJadwal berulang\u003c/li\u003e\n\u003cli\u003eJadwal sekali jalan pada waktu tertentu di masa depan\u003c/li\u003e\n\u003cli\u003ePanggilan API terautentikasi\u003c/li\u003e\n\u003cli\u003eEvent GitHub Pull request atau Release\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eBeberapa Trigger dapat dihubungkan ke satu Routine. Misalnya, PR Review Routine dapat dijalankan setiap malam sekaligus merespons event \u003ccode\u003epull_request.opened\u003c/code\u003e.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#perbandingan-loop-dan-schedule\" class=\"anchor\" id=\"perbandingan-loop-dan-schedule\"\u003e\u003c/a\u003ePerbandingan \u003ccode\u003e/loop\u003c/code\u003e dan \u003ccode\u003e/schedule\u003c/code\u003e\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eKategori\u003c/th\u003e\n\u003cth\u003e\u003ccode\u003e/loop\u003c/code\u003e\u003c/th\u003e\n\u003cth\u003e\u003ccode\u003e/schedule\u003c/code\u003e Routine\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eLokasi eksekusi\u003c/td\u003e\n\u003ctd\u003eKomputer dan sesi saat ini\u003c/td\u003e\n\u003ctd\u003eCloud yang dikelola Anthropic\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eEksekusi setelah komputer mati\u003c/td\u003e\n\u003ctd\u003eUmumnya tidak bisa\u003c/td\u003e\n\u003ctd\u003eBisa\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003ePerlu sesi terbuka\u003c/td\u003e\n\u003ctd\u003ePerlu\u003c/td\u003e\n\u003ctd\u003eTidak perlu\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eFile lokal yang belum di-commit\u003c/td\u003e\n\u003ctd\u003eDapat diakses\u003c/td\u003e\n\u003ctd\u003eTidak dapat diakses, Repository di-Clone ulang setiap eksekusi\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eInterval minimum\u003c/td\u003e\n\u003ctd\u003e1 menit menurut dokumen resmi\u003c/td\u003e\n\u003ctd\u003e1 jam menurut dokumen resmi\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003ePersistensi\u003c/td\u003e\n\u003ctd\u003eBerpusat pada sesi, pekerjaan berulang kedaluwarsa 7 hari\u003c/td\u003e\n\u003ctd\u003eRoutine yang disimpan di akun\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003ePrompt izin\u003c/td\u003e\n\u003ctd\u003eMewarisi kebijakan sesi saat ini\u003c/td\u003e\n\u003ctd\u003eEksekusi otonom tanpa persetujuan interaktif\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003ePenggunaan yang cocok\u003c/td\u003e\n\u003ctd\u003ePemantauan PR·deployment singkat\u003c/td\u003e\n\u003ctd\u003eOtomasi operasional berkelanjutan\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch3\u003e\u003ca href=\"#ketika-event-lebih-baik-daripada-polling\" class=\"anchor\" id=\"ketika-event-lebih-baik-daripada-polling\"\u003e\u003c/a\u003eKetika Event lebih baik daripada Polling\u003c/h3\u003e\n\u003cp\u003eJika 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.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eCI gagal atau PR diperbarui\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eGitHub Trigger atau Routine API\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eClaude berjalan hanya saat diperlukan\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eDesain 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.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#syarat-wajib-pekerjaan-berbasis-waktu\" class=\"anchor\" id=\"syarat-wajib-pekerjaan-berbasis-waktu\"\u003e\u003c/a\u003eSyarat wajib pekerjaan berbasis waktu\u003c/h3\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eIdempotensi\u003c/strong\u003e: meskipun event yang sama diterima beberapa kali, komentar duplikat, PR duplikat, atau deployment duplikat tidak boleh terjadi.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eStatus pemrosesan\u003c/strong\u003e: Last processed Event ID, Commit SHA, Review Comment ID, dll. harus dicatat.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eStatus selesai\u003c/strong\u003e: harus bisa menilai selesai seperti PR merge·close, Queue empty, Deploy success·rollback.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCakupan penulisan\u003c/strong\u003e: efek samping harus dibatasi, misalnya komentar diizinkan, Merge dilarang, hanya Branch \u003ccode\u003eclaude/*\u003c/code\u003e yang boleh Push.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePenanganan kegagalan\u003c/strong\u003e: diperlukan aturan retry dan Escalation saat layanan eksternal bermasalah, autentikasi kedaluwarsa, Rate limit, atau izin kurang.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2\u003e\u003ca href=\"#6-proactive-loop-menyerahkan-penemuan-pekerjaan-dan-orkestrasi\" class=\"anchor\" id=\"6-proactive-loop-menyerahkan-penemuan-pekerjaan-dan-orkestrasi\"\u003e\u003c/a\u003e6. Proactive Loop: menyerahkan penemuan pekerjaan dan orkestrasi\u003c/h2\u003e\n\u003cp\u003eProactive Loop bukan satu perintah, melainkan arsitektur otomasi selalu aktif yang menggabungkan beberapa fitur.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eTrigger\n\u003c/span\u003e\u003cspan\u003e+ Goal\n\u003c/span\u003e\u003cspan\u003e+ Skills\n\u003c/span\u003e\u003cspan\u003e+ Dynamic Workflow\n\u003c/span\u003e\u003cspan\u003e+ Auto mode\n\u003c/span\u003e\u003cspan\u003e+ Tool Repository·Connector·Browser·CI\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eMeski manusia tidak memasukkan Prompt secara real-time, pekerjaan baru terdeteksi, diproses, diverifikasi, dan hasilnya dilaporkan.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#contoh-penanganan-otomatis-feedback-bug\" class=\"anchor\" id=\"contoh-penanganan-otomatis-feedback-bug\"\u003e\u003c/a\u003eContoh: penanganan otomatis feedback bug\u003c/h3\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eMenerima GitHub Issue atau feedback Slack\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eKlasifikasi duplikasi·prioritas·kemungkinan reproduksi\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eMembuat tes reproduksi\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eMenjelajahi kandidat solusi\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eMengimplementasikan solusi yang dipilih\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eReview Agent independen mencari contoh tandingan\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eVerifikasi tes·build·keamanan\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eDraft PR dan laporan hasil\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eTanggung jawab tiap komponen adalah sebagai berikut.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eKomponen\u003c/th\u003e\n\u003cth\u003eTanggung jawab\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eTrigger atau \u003ccode\u003e/schedule\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eMenentukan kapan pekerjaan baru dimulai\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/goal\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eMendefinisikan apa status selesai pada eksekusi ini\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eSkill\u003c/td\u003e\n\u003ctd\u003eMenstandarkan prosedur reproduksi, implementasi, verifikasi, pelaporan\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eDynamic Workflow\u003c/td\u003e\n\u003ctd\u003eEksekusi paralel banyak Subagent dan percabangan kondisi\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eAuto mode\u003c/td\u003e\n\u003ctd\u003eMenjalankan pemanggilan tool yang diizinkan tanpa menunggu persetujuan\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003ePermission policy\u003c/td\u003e\n\u003ctd\u003eMengunci cakupan larangan·persetujuan·izin otomatis\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch3\u003e\u003ca href=\"#dynamic-workflow-dan-worktree\" class=\"anchor\" id=\"dynamic-workflow-dan-worktree\"\u003e\u003c/a\u003eDynamic Workflow dan Worktree\u003c/h3\u003e\n\u003cp\u003eDynamic 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.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eWorkflow Script\n\u003c/span\u003e\u003cspan\u003e  ├─ Agent A: Analisis kebutuhan\n\u003c/span\u003e\u003cspan\u003e  ├─ Agent B: Desain tes\n\u003c/span\u003e\u003cspan\u003e  ├─ Agent C: Eksplorasi kandidat implementasi\n\u003c/span\u003e\u003cspan\u003e  ├─ Agent D: Review keamanan\n\u003c/span\u003e\u003cspan\u003e  └─ Judge: Perbandingan berbasis bukti\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eKarena 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.\u003c/p\u003e\n\u003cp\u003eJika perlu menguji beberapa kandidat implementasi secara bersamaan, ruang kerja dapat dipisahkan dengan Git Worktree.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003erepo/\n\u003c/span\u003e\u003cspan\u003eworktree-solution-a/\n\u003c/span\u003e\u003cspan\u003eworktree-solution-b/\n\u003c/span\u003e\u003cspan\u003eworktree-solution-c/\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eJika 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.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#lebih-banyak-agent-tidak-selalu-lebih-baik\" class=\"anchor\" id=\"lebih-banyak-agent-tidak-selalu-lebih-baik\"\u003e\u003c/a\u003eLebih banyak Agent tidak selalu lebih baik\u003c/h3\u003e\n\u003cp\u003eJika 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.\u003c/p\u003e\n\u003cp\u003eDynamic Workflow cocok dalam kasus berikut.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eMigration yang menerapkan transformasi sama pada ratusan file\u003c/li\u003e\n\u003cli\u003eAudit keamanan·kualitas seluruh codebase\u003c/li\u003e\n\u003cli\u003ePerbandingan Plan dari beberapa perspektif independen\u003c/li\u003e\n\u003cli\u003eResearch yang harus memproses banyak item secara terbagi dan diverifikasi silang\u003c/li\u003e\n\u003cli\u003ePekerjaan yang sulit memuat semua hasil antara dalam Context satu Agent\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eUntuk perbaikan bug kecil, refactoring satu file, atau penambahan tes sederhana, Turn-based Loop biasa atau \u003ccode\u003e/goal\u003c/code\u003e lebih baik.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#7-sistem-untuk-menjaga-kualitas-kode-dalam-loop\" class=\"anchor\" id=\"7-sistem-untuk-menjaga-kualitas-kode-dalam-loop\"\u003e\u003c/a\u003e7. Sistem untuk menjaga kualitas kode dalam Loop\u003c/h2\u003e\n\u003cp\u003eKualitas hasil Loop sangat dipengaruhi bukan hanya oleh model itu sendiri, tetapi juga oleh sistem verifikasi di sekitar model.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#71-merapikan-codebase\" class=\"anchor\" id=\"71-merapikan-codebase\"\u003e\u003c/a\u003e7.1 Merapikan codebase\u003c/h3\u003e\n\u003cp\u003eClaude 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.\u003c/p\u003e\n\u003cp\u003eFondasi wajibnya adalah sebagai berikut.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eFormatter dan lint\u003c/li\u003e\n\u003cli\u003eBatas direktori dan modul yang jelas\u003c/li\u003e\n\u003cli\u003eUnit·Integration·E2E Test yang dapat dipercaya\u003c/li\u003e\n\u003cli\u003ePembedaan antara API yang digunakan dan Deprecated API\u003c/li\u003e\n\u003cli\u003eAturan pengembangan per proyek\u003c/li\u003e\n\u003cli\u003eLingkungan Build·Dev yang dapat direproduksi\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\u003ca href=\"#72-membuat-definition-of-done-berdasarkan-jenis-perubahan\" class=\"anchor\" id=\"72-membuat-definition-of-done-berdasarkan-jenis-perubahan\"\u003e\u003c/a\u003e7.2 Membuat Definition of Done berdasarkan jenis perubahan\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eJenis perubahan\u003c/th\u003e\n\u003cth\u003eVerifikasi minimum\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eAPI\u003c/td\u003e\n\u003ctd\u003eTes kontrak, kompatibilitas mundur, pembaruan contoh Schema·dokumen\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eFrontend\u003c/td\u003e\n\u003ctd\u003eOperasi browser nyata, error konsol, aksesibilitas, layar responsif\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eDatabase\u003c/td\u003e\n\u003ctd\u003eForward·Rollback Migration, cakupan Lock, rencana eksekusi\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eDependency\u003c/td\u003e\n\u003ctd\u003eBuild, tes regresi utama, pemeriksaan License·Security\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eInfrastructure\u003c/td\u003e\n\u003ctd\u003ePlan Diff, izin minimum, Rollback, pemeriksaan paparan informasi rahasia\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eDaripada mengulang panjang kriteria ini dalam Prompt setiap kali, lebih baik menguncinya sebagai Skill, Hook, Script, atau CI Rule.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#73-menyediakan-dokumen-terbaru-dan-versi-yang-akurat\" class=\"anchor\" id=\"73-menyediakan-dokumen-terbaru-dan-versi-yang-akurat\"\u003e\u003c/a\u003e7.3 Menyediakan dokumen terbaru dan versi yang akurat\u003c/h3\u003e\n\u003cp\u003eLoop 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.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#74-memisahkan-agent-implementasi-dan-review-agent\" class=\"anchor\" id=\"74-memisahkan-agent-implementasi-dan-review-agent\"\u003e\u003c/a\u003e7.4 Memisahkan Agent implementasi dan Review Agent\u003c/h3\u003e\n\u003cp\u003eAgent yang mengimplementasikan sudah dipengaruhi oleh desain dan penalaran yang dipilihnya. Review Agent dengan Context baru dapat mengajukan pertanyaan berikut secara lebih independen.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eApakah tes dilemahkan agar lulus?\u003c/li\u003e\n\u003cli\u003eApakah file di luar cakupan diubah?\u003c/li\u003e\n\u003cli\u003eApakah batas keamanan rusak?\u003c/li\u003e\n\u003cli\u003eApakah tes jalur gagal dan nilai batas terlewat?\u003c/li\u003e\n\u003cli\u003eApakah muncul regresi pada fitur yang sudah ada?\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eReview 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”.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#75-menghubungkan-kegagalan-individual-ke-perbaikan-sistem\" class=\"anchor\" id=\"75-menghubungkan-kegagalan-individual-ke-perbaikan-sistem\"\u003e\u003c/a\u003e7.5 Menghubungkan kegagalan individual ke perbaikan sistem\u003c/h3\u003e\n\u003cp\u003eJika error yang sama berulang, tidak cukup hanya memperbaiki hasil tersebut. Agar jenis kegagalan itu sulit terulang, salah satu hal berikut harus diubah.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eMenambahkan Regression Test\u003c/li\u003e\n\u003cli\u003eMemperkuat prosedur verifikasi Skill\u003c/li\u003e\n\u003cli\u003eMenambahkan aturan \u003ccode\u003eCLAUDE.md\u003c/code\u003e\u003c/li\u003e\n\u003cli\u003eMenambahkan Hook atau lint Rule\u003c/li\u003e\n\u003cli\u003eMenambahkan aturan Deny izin\u003c/li\u003e\n\u003cli\u003eMemperkuat kondisi selesai Goal\u003c/li\u003e\n\u003cli\u003eMelengkapi Review Checklist\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eLoop Engineering yang baik bukan pekerjaan memperbaiki satu kegagalan, melainkan \u003cstrong\u003epekerjaan membangun sistem yang membuat jenis kegagalan itu sulit muncul kembali\u003c/strong\u003e.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#8-pengelolaan-token-dan-biaya\" class=\"anchor\" id=\"8-pengelolaan-token-dan-biaya\"\u003e\u003c/a\u003e8. Pengelolaan Token dan biaya\u003c/h2\u003e\n\u003cp\u003eBiaya Loop dapat meningkat jauh lebih besar daripada Prompt tunggal.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eTotal biaya ≈\n\u003c/span\u003e\u003cspan\u003eBiaya Turn Agent utama\n\u003c/span\u003e\u003cspan\u003e+ Biaya evaluasi Goal\n\u003c/span\u003e\u003cspan\u003e+ Biaya Subagent\n\u003c/span\u003e\u003cspan\u003e+ Biaya iterasi Workflow\n\u003c/span\u003e\u003cspan\u003e+ Biaya Context untuk membaca hasil tool\n\u003c/span\u003e\u003cspan\u003e+ Frekuensi eksekusi berbasis waktu\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003ePenagihan yang tepat berbeda tergantung Plan, Model, dan Provider, tetapi prinsip yang menentukan struktur biaya sama.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#prinsip-praktis-untuk-mengurangi-biaya\" class=\"anchor\" id=\"prinsip-praktis-untuk-mengurangi-biaya\"\u003e\u003c/a\u003ePrinsip praktis untuk mengurangi biaya\u003c/h3\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eJangan memakai Loop untuk pekerjaan kecil.\u003c/strong\u003e Typo, perubahan nama, dan error tipe pada satu file ditangani dengan satu Turn.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTetapkan kondisi sukses bersama Hard stop.\u003c/strong\u003e Pertimbangkan sukses, maksimum Turn, maksimum waktu, kegagalan beruntun, dan error izin.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eUji Workflow skala besar pada cakupan kecil.\u003c/strong\u003e Verifikasi biaya dan kualitas dengan 5 file, satu direktori, atau sebagian Issue, lalu perluas.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTangani pekerjaan deterministik dengan Script.\u003c/strong\u003e Penggantian AST, transformasi JSON, Formatting, dan pembuatan format tetap lebih murah dan dapat direproduksi dengan Script yang terverifikasi.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSesuaikan siklus Polling dengan frekuensi perubahan nyata.\u003c/strong\u003e Gunakan Event Trigger jika memungkinkan.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAmati penggunaan saat berjalan.\u003c/strong\u003e Periksa penggunaan Skill·Subagent·MCP·Turn·Token di \u003ccode\u003e/usage\u003c/code\u003e, \u003ccode\u003e/goal\u003c/code\u003e, \u003ccode\u003e/workflows\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eJika error yang sama berulang, jangan terus mencoba ulang.\u003c/strong\u003e Tetapkan batas kegagalan beruntun dan lakukan Escalation ke manusia.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch3\u003e\u003ca href=\"#model-dan-effort-adalah-tuas-yang-berbeda\" class=\"anchor\" id=\"model-dan-effort-adalah-tuas-yang-berbeda\"\u003e\u003c/a\u003eModel dan Effort adalah tuas yang berbeda\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eModel\u003c/strong\u003e mengubah kemampuan penalaran dasar dan cakupan masalah yang dapat diselesaikan.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eEffort\u003c/strong\u003e mengubah jumlah file yang dibaca, jumlah tool yang digunakan, luas verifikasi, dan sejauh mana pekerjaan multi-tahap didorong sampai selesai.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eJika 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.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#9-izin-dan-batas-keamanan\" class=\"anchor\" id=\"9-izin-dan-batas-keamanan\"\u003e\u003c/a\u003e9. Izin dan batas keamanan\u003c/h2\u003e\n\u003cp\u003eDesain paling berbahaya dalam Proactive Loop adalah memberi Agent izin luas dan menetapkan kondisi sukses serta kondisi berhenti secara longgar.\u003c/p\u003e\n\u003cp\u003eAuto mode mengurangi Prompt izin umum, tetapi classifier dapat memblokir Tool call yang sulit dibatalkan, destruktif, atau menargetkan luar batas kepercayaan. Selain itu, \u003ccode\u003epermissions.ask\u003c/code\u003e dan \u003ccode\u003epermissions.deny\u003c/code\u003e yang eksplisit diprioritaskan di atas Auto mode.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#contoh-lapisan-izin\" class=\"anchor\" id=\"contoh-lapisan-izin\"\u003e\u003c/a\u003eContoh lapisan izin\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eLevel\u003c/th\u003e\n\u003cth\u003eContoh\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eDiizinkan otomatis\u003c/td\u003e\n\u003ctd\u003eMembaca kode, tes·lint·Build, analisis, membuat Branch \u003ccode\u003eclaude/*\u003c/code\u003e, membuat Draft PR\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003ePersetujuan manusia\u003c/td\u003e\n\u003ctd\u003eMenerapkan ke Default Branch, deployment produksi, menerapkan DB Migration, mengirim pesan pelanggan eksternal\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eSelalu dilarang\u003c/td\u003e\n\u003ctd\u003eForce push, menampilkan Secret, menghapus data produksi, bypass izin, menghapus audit log\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eLebih aman menguncinya sebagai Rule \u003ccode\u003eask\u003c/code\u003e·\u003ccode\u003edeny\u003c/code\u003e permanen daripada sekali berkata “jangan Push” dalam percakapan. Aturan percakapan dapat melemah karena kompresi Context atau perubahan sesi.\u003c/p\u003e\n\u003cp\u003eCloud Routine melakukan Clone Repository baru pada setiap eksekusi dan bekerja dengan izin GitHub·Connector yang terhubung. Cakupan berikut harus diminimalkan.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eRepository dan Branch yang dapat diakses\u003c/li\u003e\n\u003cli\u003eNetwork Domain yang diizinkan\u003c/li\u003e\n\u003cli\u003eConnector yang digunakan\u003c/li\u003e\n\u003cli\u003eVariabel lingkungan dan Secret\u003c/li\u003e\n\u003cli\u003eIzin tulis ke sistem eksternal\u003c/li\u003e\n\u003cli\u003eCakupan pembuatan PR·Push·Merge\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eStatus “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.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#10-template-desain-loop-untuk-proyek-pengembangan\" class=\"anchor\" id=\"10-template-desain-loop-untuk-proyek-pengembangan\"\u003e\u003c/a\u003e10. Template desain Loop untuk proyek pengembangan\u003c/h2\u003e\n\u003cp\u003eYAML berikut bukan sintaks Claude Code nyata, melainkan Template untuk review desain.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003etrigger\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003etype\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003emanual | interval | schedule | github_event | api_event\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003escope\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003erepositories\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003etarget-repository\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eallowed_paths\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003esrc/**\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003etests/**\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eprohibited_paths\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eproduction/**\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003esecrets/**\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003etask\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eobjective\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etujuan yang akan diubah atau diproses\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003einput\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003eIssue, Event, File, atau status yang baru masuk\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003everification\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003ecommands\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eunit-test\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eintegration-test\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003elint\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003ebuild\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eruntime_checks\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003ebrowser-interaction\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003econsole-errors\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eaccessibility\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eevidence\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003ecommand-output\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eexit-code\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003etest-summary\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003escreenshots\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003esuccess\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003econdition\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003estatus selesai yang dapat dinilai benar atau salah\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003estop\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003emax_turns\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003e12\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003emax_duration_minutes\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003e45\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003emax_consecutive_failures\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003e3\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003estop_on_permission_error\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eescalate_on_external_outage\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003eside_effects\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eidempotency_key\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003eevent-id-or-commit-sha\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eallow_branch_push\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003eclaude/*\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003erequire_human_for_merge\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003erequire_human_for_deploy\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003ereview\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eindependent_agent\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eadversarial_review\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003eobservability\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003ereport_progress\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003ereport_token_usage\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003ereport_changed_files\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003ereport_remaining_failures\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eItem terpenting bukan kalimat Prompt itu sendiri, melainkan lima hal berikut.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eTrigger\n\u003c/span\u003e\u003cspan\u003eVerifier\n\u003c/span\u003e\u003cspan\u003eSuccess condition\n\u003c/span\u003e\u003cspan\u003eHard stop\n\u003c/span\u003e\u003cspan\u003ePermission boundary\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003ch2\u003e\u003ca href=\"#11-loop-mana-yang-harus-dipilih\" class=\"anchor\" id=\"11-loop-mana-yang-harus-dipilih\"\u003e\u003c/a\u003e11. Loop mana yang harus dipilih\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eSituasi\u003c/th\u003e\n\u003cth\u003eMetode yang disarankan\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003ePekerjaan yang selesai dengan satu perbaikan dan verifikasi\u003c/td\u003e\n\u003ctd\u003eTurn-based\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003ePekerjaan yang perlu dicoba beberapa kali tetapi status selesai jelas\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e/goal\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003ePekerjaan yang perlu menunggu sebentar status CI·PR·deployment eksternal\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e/loop\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003ePekerjaan yang harus tetap berjalan berulang meski laptop ditutup\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e/schedule\u003c/code\u003e Routine\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003ePekerjaan yang harus segera merespons event GitHub atau Alert\u003c/td\u003e\n\u003ctd\u003eEvent-triggered Routine\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003ePekerjaan yang harus memproses ratusan item secara paralel dan diverifikasi silang\u003c/td\u003e\n\u003ctd\u003eDynamic Workflow\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eTransformasi dengan aturan input dan output yang sepenuhnya deterministik\u003c/td\u003e\n\u003ctd\u003eScript atau CI Job\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eUrutan pemilihan harus berdasarkan “struktur kontrol paling sederhana yang mencapai tujuan”, bukan “fitur paling kuat”.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#12-urutan-adopsi-yang-aman\" class=\"anchor\" id=\"12-urutan-adopsi-yang-aman\"\u003e\u003c/a\u003e12. Urutan adopsi yang aman\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003ePilih satu pekerjaan bottleneck yang berulang kali diperiksa manusia.\u003c/li\u003e\n\u003cli\u003ePertama buat prosedur verifikasi sebagai Skill, Script, atau CI.\u003c/li\u003e\n\u003cli\u003eStabilkan kualitas verifikasi dengan cara Turn-based.\u003c/li\u003e\n\u003cli\u003eJika status selesai jelas, tambahkan \u003ccode\u003e/goal\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eGunakan \u003ccode\u003e/loop\u003c/code\u003e hanya saat perlu menunggu status eksternal.\u003c/li\u003e\n\u003cli\u003eJika perlu eksekusi jangka panjang, pindahkan ke \u003ccode\u003e/schedule\u003c/code\u003e Routine.\u003c/li\u003e\n\u003cli\u003ePerluas ke Dynamic Workflow dan Proactive Loop hanya setelah idempotensi, izin, dan biaya terverifikasi.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2\u003e\u003ca href=\"#13-kesalahpahaman-yang-sering-terjadi\" class=\"anchor\" id=\"13-kesalahpahaman-yang-sering-terjadi\"\u003e\u003c/a\u003e13. Kesalahpahaman yang sering terjadi\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eKesalahpahaman\u003c/th\u003e\n\u003cth\u003eInterpretasi yang tepat\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eLoop adalah eksekusi tanpa batas\u003c/td\u003e\n\u003ctd\u003eStruktur iterasi terbatas yang memiliki kondisi sukses dan Hard stop\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eLaporan selesai dari Agent adalah verifikasi\u003c/td\u003e\n\u003ctd\u003eDibutuhkan output perintah eksternal, kode keluar, dan hasil Runtime\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/goal\u003c/code\u003e otomatis mengizinkan semua izin\u003c/td\u003e\n\u003ctd\u003eHanya memulai Turn berikutnya secara otomatis; kebijakan izin terpisah\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/loop\u003c/code\u003e adalah Scheduler operasional jangka panjang\u003c/td\u003e\n\u003ctd\u003eBerpusat pada sesi, dengan kedaluwarsa 7 hari dan batasan lingkungan eksekusi\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eSemakin banyak Agent, hasilnya semakin baik\u003c/td\u003e\n\u003ctd\u003eNilai paralelisasi muncul hanya ketika peran·perspektif·verifikasi berbeda\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eSemua pekerjaan berulang harus dilakukan LLM\u003c/td\u003e\n\u003ctd\u003eBagian deterministik lebih murah dan lebih dapat direproduksi dengan Script\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\u003ca href=\"#kesimpulan\" class=\"anchor\" id=\"kesimpulan\"\u003e\u003c/a\u003eKesimpulan\u003c/h2\u003e\n\u003cp\u003eLoop Engineering bukan teknologi untuk menjalankan AI lebih lama, melainkan \u003cstrong\u003edesain sistem kontrol yang membuat AI menemukan sendiri saat ia salah, memperbaiki dalam batas biaya, dan berhenti pada titik yang berisiko\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003eLLM 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.\u003c/p\u003e\n","tags":["Claude Code","Rekayasa loop","Agen AI","Otomatisasi pengembangan","Alur kerja agen"],"faqs":[{"question":"Apa perbedaan Loop pada Claude Code dengan perulangan for·while biasa?","answer":"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."},{"question":"Kapan Turn-based Loop paling sesuai digunakan?","answer":"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."},{"question":"Apakah model evaluasi `/goal` memeriksa file dan hasil pengujian secara langsung?","answer":"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."},{"question":"Apa saja yang harus ada dalam kondisi `/goal` yang baik?","answer":"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'."},{"question":"Apakah `/goal` memiliki Turn maksimum atau batas waktu otomatis?","answer":"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'."},{"question":"Jika menggunakan `/goal`, apakah izin alat juga otomatis diizinkan?","answer":"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`."},{"question":"Apa perbedaan terbesar antara `/loop` dan `/schedule`?","answer":"`/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."},{"question":"Jika komputer dimatikan, apakah `/loop` terus berjalan?","answer":"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."},{"question":"Mengapa Event Trigger lebih baik daripada Polling berbasis waktu?","answer":"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."},{"question":"Mengapa prosedur verifikasi ditempatkan di `SKILL.md`, bukan di `CLAUDE.md`?","answer":"`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."},{"question":"Apa perbedaan Dynamic Workflow dengan pemanggilan Subagent biasa?","answer":"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."},{"question":"Apakah menggunakan beberapa Agent selalu meningkatkan kualitas?","answer":"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."},{"question":"Bagaimana mencegah pekerjaan duplikat dalam Time-based atau Proactive Loop?","answer":"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."},{"question":"Loop seperti apa yang baik untuk diautomatisasi pertama kali?","answer":"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":[{"url":"https://claude.com/blog/getting-started-with-loops","title":"Rekayasa loop: Memulai dengan loop | Claude oleh Anthropic","type":"source"},{"url":"https://code.claude.com/docs/en/skills","title":"Perluas Claude dengan keterampilan - Dokumentasi Claude Code","type":"source"},{"url":"https://code.claude.com/docs/en/goal","title":"Jaga agar Claude tetap bekerja menuju suatu tujuan - Dokumentasi Claude Code","type":"source"},{"url":"https://code.claude.com/docs/en/scheduled-tasks","title":"Jalankan prompt sesuai jadwal - Dokumentasi Claude Code","type":"source"},{"url":"https://code.claude.com/docs/en/routines","title":"Otomatiskan pekerjaan dengan rutinitas - Dokumentasi Claude Code","type":"source"},{"url":"https://code.claude.com/docs/en/workflows","title":"Orkestrasi subagen dalam skala besar dengan alur kerja dinamis - Dokumentasi Claude Code","type":"source"},{"url":"https://claude.com/blog/claude-model-and-effort-level-in-claude-code","title":"Memilih model Claude dan tingkat upaya di Claude Code | Claude oleh Anthropic","type":"source"},{"url":"https://code.claude.com/docs/en/auto-mode-config","title":"Konfigurasikan mode otomatis - Dokumentasi Claude Code","type":"source"}],"images":[{"id":195,"url":"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","is_representative":true,"generation_method":"upload","mime_type":"image/webp","original_filename":"ChatGPT Image 2026년 7월 16일 오후 06_56_28.png","translations":{"ko":{"alt":"AI 로봇과 코드 화면을 중심으로 반복 화살표, 목표·시간·보안·비용 아이콘이 연결된 자동화 구조","caption":"관찰·실행·검증을 반복하는 AI 에이전트와 목표, 일정, 권한, 강제 종료, 비용 제어 요소를 함께 보여준다.","description":null},"en":{"alt":"AI robot and code dashboard surrounded by loop arrows, goal, schedule, security, and cost control icons","caption":"The illustration shows an AI agent repeating observation, action, and verification within goal, timing, permission, stop, and cost controls.","description":null},"ja":{"alt":"AIロボットとコード画面を中心に、循環矢印、目標、時間、安全、コスト管理のアイコンが連結された構成","caption":"観察・実行・検証を繰り返すAIエージェントを、目標、実行時期、権限、停止、コストの制御要素とともに示している。","description":null},"es":{"alt":"Robot de IA y panel de código rodeados por flechas de ciclo e iconos de objetivo, tiempo, seguridad y coste","caption":"La ilustración muestra un agente de IA que repite observación, acción y verificación bajo controles de objetivo, tiempo, permisos, parada y coste.","description":null},"id":{"alt":"Robot AI dan dasbor kode dikelilingi panah loop serta ikon tujuan, waktu, keamanan, dan biaya","caption":"Ilustrasi menampilkan agen AI yang mengulang observasi, tindakan, dan verifikasi dengan kontrol tujuan, waktu, izin, penghentian, dan biaya.","description":null},"pt":{"alt":"Robô de IA e painel de código cercados por setas de ciclo e ícones de meta, tempo, segurança e custo","caption":"A ilustração mostra um agente de IA repetindo observação, ação e verificação sob controles de objetivo, tempo, permissão, parada e custo.","description":null},"zh-hant":{"alt":"AI 機器人與程式碼面板置於循環箭頭中央，周圍連結目標、時間、安全與成本控制圖示","caption":"圖中呈現 AI 代理在目標、排程、權限、強制停止與成本控制下反覆觀察、執行與驗證。","description":null}}},{"id":196,"url":"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","is_representative":false,"generation_method":"upload","mime_type":"image/webp","original_filename":"ChatGPT Image 2026년 7월 16일 오후 07_02_56.png","translations":{"ko":{"alt":"보호 울타리 안의 AI 에이전트가 검증, 중단 장치, 권한 게이트와 비용 계측을 거쳐 작업하는 자동화 구조","caption":"트리거부터 검증과 강제 중단, 자원 관리, 승인된 결과 출력까지 안전하게 통제되는 에이전트 워크플로를 보여준다.","description":null},"en":{"alt":"AI agent inside a guarded workspace with verification, stop controls, permission gates, and resource monitoring","caption":"The illustration shows an agent workflow controlled from triggers through validation, hard stops, resource checks, and approved output.","description":null},"ja":{"alt":"検証、強制停止、権限ゲート、資源監視に囲まれた保護領域内のAIエージェント","caption":"トリガーから検証、停止制御、コスト管理、承認済み出力まで安全に統制されたエージェント処理を表している。","description":null},"es":{"alt":"Agente de IA en un entorno protegido con verificación, parada forzada, permisos y control de recursos","caption":"La ilustración muestra un flujo de agente controlado desde los disparadores hasta la validación, los límites y la salida aprobada.","description":null},"id":{"alt":"Agen AI dalam area terlindungi dengan verifikasi, penghentian paksa, gerbang izin, dan pemantauan sumber daya","caption":"Ilustrasi ini menunjukkan alur agen yang dikendalikan dari pemicu hingga validasi, batas aman, pemantauan biaya, dan keluaran yang disetujui.","description":null},"pt":{"alt":"Agente de IA em área protegida com verificação, parada forçada, controle de permissões e monitoramento de recursos","caption":"A ilustração mostra um fluxo de agente controlado desde os gatilhos até a validação, os limites de segurança e a saída aprovada.","description":null},"zh-hant":{"alt":"受保護工作區中的AI代理，周圍設有驗證、強制停止、權限閘門與資源監控","caption":"圖中呈現從觸發、驗證、停止控制與成本監測，到核准輸出的安全代理工作流程。","description":null}}}],"published_at":"2026-07-17T09:40:17+09:00","updated_at":"2026-07-17T09:40:17+09:00","license":"cc_by","translation_status":"machine","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant"],"url":"https://injoys.com/en/articles/claude-code-loop-engineering-guide"}