Cara Membuat Loop dengan Claude Code: Panduan Praktis untuk Otomatisasi Agen #2

 

2. Kapan Anda Harus — dan Tidak Boleh — Membangun Loop

Sebelum membangun Claude loop, ada baiknya bertanya apakah tugas tersebut benar-benar membutuhkannya. Loop menambah struktur, persistensi, verifikasi, dan otomatisasi, tetapi juga menambah biaya dan kompleksitas operasional. Untuk banyak tugas, satu prompt yang ditulis dengan baik tetap merupakan pilihan yang lebih baik.

Loop berguna ketika tugas bersifat repetitif, berstatus, dan dapat diperiksa. Berulang berarti tugas ini cukup sering terjadi sehingga otomatisasi sepadan untuk disiapkan. Stateful berarti setiap run mendapat manfaat dari mengingat apa yang terjadi pada run sebelumnya. Dapat diperiksa berarti ada cara konkret untuk memutuskan apakah hasil tersebut dapat diterima.

Misalnya, siklus tinjauan proyek harian adalah kandidat yang baik. Tugas ini terjadi berulang, loop harus mengingat kemajuan sebelumnya, dan output dapat diperiksa dengan struktur sederhana: file ditinjau, perubahan diringkas, pemblokir didaftarkan, dan PROGRESS.md diperbarui. Sesi brainstorming sekali saja, di sisi lain, biasanya bukan kandidat yang baik. Mungkin berharga, tetapi tidak memerlukan otomatisasi yang terus-menerus.

Claude loop paling berguna ketika tugas diulang, output dapat diperiksa, dan run berikutnya mendapat manfaat dari apa yang terjadi pada run sebelumnya. Tanpa ketiga kondisi tersebut, loop sering menjadi versi yang lebih mahal dari prompt biasa.

 Cara praktis untuk mengevaluasi tugas adalah dengan melakukan pemeriksaan kesiapan loop yang sederhana.

Pemeriksaan Kesiapan Loop

Sebelum mengubah tugas menjadi Claude loop, ajukan lima pertanyaan:

1. Apakah tugas ini terulang?
   Jika tugas tidak dilakukan secara rutin, biaya pemasangan mungkin tidak sepadan. Loop bekerja paling baik jika berjalan setiap hari, mingguan, pada setiap pull request, setelah setiap pertemuan, atau setelah acara berulang tertentu.
2. Apakah hasilnya dapat diverifikasi?
   Loop ini butuh cara untuk menolak output yang buruk. Dalam alur kerja kode, ini bisa berupa test suite, type checker, linter, atau perintah build. Dalam alur kerja dokumen, bisa berupa daftar periksa, format output yang diperlukan, konvensi penamaan, atau aturan tinjauan.
3. Apakah Claude punya cukup konteks untuk bertindak?
   Loop harus memiliki akses ke file, instruksi, log, tiket, dokumen, atau konektor yang dibutuhkan untuk menyelesaikan tugas. Jika Claude tidak dapat memeriksa lingkungan terkait, loop akan beroperasi dari konteks yang tidak lengkap.
4. Apakah ada kondisi berhenti yang jelas?
   Loop harus tahu kapan harus berhenti, mengulang, atau meningkat. "Lanjutkan sampai terlihat bagus" terlalu samar. Kondisi berhenti yang lebih baik meliputi "file output sudah ada," "semua bagian yang diperlukan telah terisi," "tes lulus," atau "masalah ditandai untuk ditinjau manusia."
5. Apakah ada titik tinjauan yang aman?
   Setiap loop yang dapat memodifikasi file, membuka pull request, mengirim pesan, memperbarui tiket, atau menyentuh sistem eksternal harus memiliki checkpoint manusia di awal. Otomatisasi sebaiknya dimulai dengan draf dan laporan sebelum beralih ke tindakan langsung.

Daftar periksa ini berguna karena banyak ide loop gagal sebelum implementasi. Masalahnya bukan pada kemampuan Claude. Masalahnya adalah tugas ini tidak memiliki trigger yang stabil, tidak ada langkah verifikasi yang andal, atau tidak ada definisi yang jelas tentang selesai.

Pertimbangkan perbedaan antara dua contoh ini:

• Kandidat loop buruk: Setiap hari, tingkatkan dokumen strategi produk hingga terasa lebih kuat.

Ini samar. Loop ini tidak memiliki kondisi berhenti objektif dan tidak ada sinyal verifikasi yang jelas. Hasilnya sangat bergantung pada penilaian. Claude mungkin menghasilkan saran yang berguna, tetapi prosesnya harus tetap dipimpin manusia.

Versi yang lebih baik adalah:

• Kandidat loop yang lebih baik: Setiap Jumat, tinjau dokumen strategi produk, identifikasi bagian yang berubah selama minggu kerja, cantumkan asumsi yang belum terselesaikan, dan tulis catatan tinjauan terstruktur ke outputs/strategy-review.md. Jangan mengedit dokumen strategi secara langsung.

Versi ini lebih cocok untuk loop karena memiliki jadwal, cakupan terbatas, file output yang dapat diprediksi, dan batas izin yang lebih aman. Claude tidak diminta untuk membuat keputusan strategis secara otomatis. Lembaga ini diminta untuk memeriksa, merangkum, dan menyiapkan materi untuk ditinjau oleh manusia.

Putaran Pertama yang Baik

Putaran pertama terbaik adalah kecil dan berisiko rendah. Mereka harus menghasilkan output yang mudah diperiksa dan aman diabaikan jika salah. Loop pertama yang berguna biasanya harus menulis laporan, memperbarui file status, atau menyusun rekomendasi. Seharusnya tidak terjadi perubahan yang tidak dapat diubah.

Contoh pertama yang baik meliputi:

Example #1: Daily project review:
Read the project folder every morning, summarize what changed, identify blockers, update PROGRESS.md, and write a report to outputs/daily-review.md.

Example #2: Meeting follow-up loop:
After a meeting notes file is added, extract action items, owners, deadlines, and unresolved questions into outputs/follow-up.md.

Example #3: Folder cleanup planning loop:
Inspect a messy folder, classify files by type, propose a cleanup plan, and write the plan to outputs/cleanup-plan.md. Do not move or rename files yet.

Example #4:CI failure triage loop:
When CI fails, read the logs, classify the failure, identify likely causes, and draft a report. Do not change code until a human approves the suggested fix.

Tugas-tugas ini adalah titik awal yang baik karena lingkaran bisa dibatasi. Ia membaca input yang diketahui, menghasilkan output yang diketahui, dan memperbarui status di tempat yang dapat diprediksi. Loop bisa berguna bahkan sebelum diizinkan melakukan perubahan langsung.

Loop pertama biasanya harus banyak membaca dan ringan untuk menulis. Biarkan Claude memeriksa, meringkas, mengklasifikasikan, dan membuat draf sebelum membiarkannya memodifikasi file penting atau sistem eksternal.

 

Putaran Pertama yang Buruk

Loop pertama yang buruk cenderung luas, samar, berisiko tinggi, atau sulit diverifikasi. Biasanya terdengar menarik karena menjanjikan peningkatan otomatisasi besar, tapi gagal karena loop tidak dapat memutuskan secara andal apakah mereka melakukan hal yang benar.

Contoh loop pertama yang buruk meliputi:

Example #1: Rewrite the entire backend architecture.

Example #2: Improve our product direction every week.

Example #3: Automatically modify authentication and payment code until all issues are fixed.

Example #4: Deploy changes to production when Claude thinks they are ready.

Example #5: Clean my whole computer and reorganize all files automatically.

Masalah umum bukanlah Claude tidak bisa membantu tugas-tugas ini. Claude dapat membantu dalam perencanaan, peninjauan, penyusunan, dan analisis. Masalahnya adalah tugas-tugas ini melibatkan penilaian tinggi, dampak tinggi, atau verifikasi yang tidak jelas. Masalah ini harus ditangani melalui alur kerja yang diawasi, bukan loop tanpa pengawasan.

Misalnya, "bersihkan seluruh komputer saya secara otomatis" terlalu luas untuk loop pertama. Versi yang lebih aman adalah: "periksa folder Downloads, kelompokkan file berdasarkan jenis, dan tulis rencana pembersihan yang diusulkan tanpa memindahkan apa pun." Setelah rencana dapat diandalkan selama beberapa kali berjalan, loop dapat diperluas untuk mengganti nama atau memindahkan file ke dalam folder sandbox yang dikendalikan.

Tekan enter atau klik untuk melihat gambar dalam ukuran penuh

Tangga Izin

Cara yang berguna untuk memikirkan desain loop adalah melalui tangga izin. Anda tidak perlu memulai dengan otonomi penuh. Faktanya, sebagian besar loop seharusnya dimulai dengan izin yang sangat terbatas.

Progresi yang aman terlihat seperti ini:

Level 1 — Read-only analysis
Claude reads files and writes a summary.

Level 2 — Draft output
Claude writes reports, plans, or suggested changes in an outputs/ folder.

Level 3 — Sandbox edits
Claude modifies files only inside a controlled sandbox or draft branch.

Level 4 — Draft external action
Claude opens a draft pull request, draft message, or draft ticket update.

Level 5 — Human-approved action
Claude applies changes only after explicit approval.

Level 6 — Fully automated low-risk action
Claude completes the task automatically, with logs, limits, and rollback options.

Sebagian besar loop pertama sebaiknya tetap di Level 1 atau Level 2. Itu sudah cukup untuk membuktikan apakah loop tersebut berguna. Anda dapat memeriksa output, memperbaiki instruksi, memperbaiki file status, dan memeriksa apakah Claude melakukan kesalahan yang sama berulang kali.

Hanya setelah loop menjadi andal, Anda harus menaikkannya ke tangga. Hal ini sangat penting ketika loop memiliki akses ke kode, data pelanggan, sistem produksi, dokumen pribadi, atau alat komunikasi.

Biaya dan kebisingan juga penting

Loop bisa gagal meskipun secara teknis berfungsi. Proses ini mungkin berjalan terlalu sering, menghasilkan output terlalu banyak, mengonsumsi terlalu banyak token, atau membuat pekerjaan review yang lebih besar dari tugas yang seharusnya diotomatisasi.

Inilah sebabnya lingkaran pertama harus memiliki cakupan terbatas dan output yang dapat diprediksi. Sebelum menjadwalkan, jalankan secara manual beberapa kali. Periksa seberapa banyak konteks yang dibaca, berapa panjang outputnya, dan apakah hasilnya cukup berguna untuk ditinjau berulang kali.

Loop yang baik seharusnya mengurangi beban kognitif. Seharusnya tidak membuat kotak masuk baru penuh dengan laporan bernilai rendah. Run yang tidak menemukan hal penting sebaiknya memperbarui status secara diam-diam atau menulis catatan singkat "tidak ada perubahan berarti". Run yang menemukan sesuatu yang penting harus menjelaskan alasannya.

Loop tidak berhasil karena berjalan secara otomatis. Metode ini berhasil jika menghasilkan pekerjaan yang berguna dengan pengawasan yang lebih sedikit dibandingkan dengan arahan manual, sambil tetap dalam batasan biaya, izin, dan tinjauan yang jelas.

 

Aturan sederhana untuk memilih loop pertama

Untuk implementasi pertama, pilih tugas yang berguna meskipun Claude hanya membuat laporan. Ini menjaga risiko tetap rendah dan tetap menunjukkan pola inti loop: trigger, konteks, tindakan, verifikasi, pembaruan status, dan keputusan.

Loop pertama yang baik mungkin adalah:

Every morning, review this project folder, compare it with the previous state, summarize changes, identify blockers, update PROGRESS.md, and write a daily report to outputs/daily-review.md.

Tugas ini praktis, dapat diulang, dan mudah diperpanjang. Nanti, Anda bisa menambahkan lebih banyak kemampuan: memeriksa riwayat Git, membaca pelacak masalah, terhubung ke Slack, membuka tiket draft, atau menyarankan perubahan kode. Namun versi pertama harus membuktikan model operasi sebelum menambah otonomi lebih banyak.

Pada bagian berikutnya, kita akan membangun loop Claude minimum yang layak di sekitar ide ini: satu tugas, satu file status, satu folder output, satu langkah verifikasi, dan satu run terkontrol.