Apa Itu Rekayasa Loop? Definisi dan Cara Kerjanya

Apa yang dimaksud dengan rekayasa loop

Rekayasa loop adalah praktik merancang siklus berulang yang dijalankan agen AI: apa yang memicunya, apa yang boleh diaksesnya, bagaimana output-nya diperiksa, dan apa yang menghentikannya. Rekayasa prompt membentuk satu pesan untuk model. Rekayasa loop membentuk proses yang mengirim ribuan pesan saat Anda tidur. Unit pekerjaan bergeser dari prompt ke loop.

Versi singkatnya: Anda berhenti menulis instruksi dan mulai menulis sistem kontrol. Agen tetap memerlukan instruksi yang baik, tetapi instruksi tersebut menjadi salah satu komponen dalam siklus yang berjalan sesuai jadwal, bekerja pada salinan kode yang terisolasi, membuktikan hasilnya sendiri melalui pengujian, dan berhenti ketika anggaran habis.

Mengapa istilah ini muncul pada 2026

Nama ini sedang ditetapkan secara publik. Repositori GitHub cobusgreyling/loop-engineering mencapai 9.600 stars dalam dua bulan sejak pertama kali muncul (per Juli 2026), dengan slogan "Stop prompting. Design the loop. Get a score." Repositori ini merangkum perubahan tersebut ke dalam enam building block: scheduling, worktrees, skills, plugins dan connectors, sub-agents, serta durable memory yang disimpan di luar percakapan.

Repositori ini mengutip Boris Cherny, yang memimpin Claude Code di Anthropic:

I don't prompt Claude anymore. I have loops running that prompt Claude.

Repositori kedua, AI-Builder-Club/skills, memiliki hampir 1.100 stars (per Juli 2026) dan menyebutkan kedua peran tersebut secara langsung: "codebase harness" yang membuat repositori aman bagi agent untuk menjalankan pengujian dan deployment, serta "loop engineer" yang membangun workflow yang aktif berdasarkan trigger, menjalankan tugas, lalu menulis hasil yang dipelajarinya ke dalam file bersama agar dapat dibaca oleh loop berikutnya.

Tidak satu pun dari kedua repositori tersebut menciptakan praktik ini. Siapa pun yang pernah menjalankan nightly build, linter dalam continuous integration, atau cron job yang membuka ticket sudah mengenali bentuknya. Hal yang baru adalah worker di dalam loop kini bersifat non-deterministic. Perubahan ini memengaruhi fungsi yang harus dijalankan oleh machinery di sekitarnya.

Empat bagian dalam loop

Setiap loop yang berfungsi memiliki empat bagian ini. Loop yang mengabaikan salah satunya dapat membangunkan Anda pada pukul 3 dini hari.

• Pemicu. Peristiwa yang memulai satu eksekusi: timer, webhook, pull request baru, atau alert.
• Batas. File, kredensial, dan jaringan yang dapat diakses agent selama eksekusi tersebut.
• Verifikasi. Pemeriksaan dengan exit code yang menentukan apakah output eksekusi dipertahankan atau dibuang.
• Anggaran. Batas token, waktu, dan biaya yang mengakhiri eksekusi, baik eksekusi tersebut berhasil maupun tidak.

Baca kembali keempat bagian tersebut sebagai pertanyaan. Dengan demikian, Anda memiliki tinjauan desain untuk setiap agent yang akan dibiarkan berjalan.

Pemicu: apa yang membangunkan agent

Timer adalah pemicu yang paling sederhana. Pada server Linux, systemd timer lebih unggul daripada cron karena mencatat log, dapat melakukan percobaan ulang sesuai pengaturan Anda, dan tidak akan memulai salinan kedua dari unit yang masih berjalan. Properti terakhir ini menghilangkan bug tumpang tindih yang paling umum pada loop agent: dua eksekusi mengubah branch yang sama.

Tulis unit di /etc/systemd/system/agent-loop.service:

[Unit]
Description=Agent loop: triage open issues
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
User=agent
WorkingDirectory=/srv/agent/repo
ExecStart=/srv/agent/bin/loop.sh
TimeoutStartSec=1800

Tulis timer di /etc/systemd/system/agent-loop.timer:

[Unit]
Description=Run the triage loop every 30 minutes

[Timer]
OnBootSec=5min
OnUnitActiveSec=30min
Unit=agent-loop.service

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now agent-loop.timer
systemctl list-timers agent-loop.timer

systemctl list-timers harus menampilkan kolom NEXT dengan waktu pada masa mendatang dan kolom LEFT yang menghitung mundur. Hasil kosong berarti timer belum diaktifkan, karena enable tanpa --now hanya menjadwalkannya untuk boot berikutnya. TimeoutStartSec=1800 lebih penting daripada yang terlihat: agent yang macet karena menunggu input akan membuat unit tetap aktif selamanya, sehingga timer tidak akan terpicu lagi. Baca hasil eksekusi dengan journalctl -u agent-loop.service -n 50.

Jika Anda menjalankan loop dari cron, tambahkan mekanisme pencegah tumpang tindih sendiri karena cron akan langsung memulai salinan kedua:

*/30 * * * * /usr/bin/flock -n /tmp/agent-loop.lock /srv/agent/bin/loop.sh

flock -n langsung keluar dengan status 1 saat lock sedang digunakan. Dengan demikian, eksekusi kedua berhenti tanpa pesan, alih-alih berjalan bersamaan dengan eksekusi pertama. Penyiapan systemd service dan timer yang sama berlaku untuk semua job yang berjalan lama di server, baik agent maupun bukan.

Batas: berikan salinan tersendiri untuk setiap proses

Agen yang mengedit working tree Anda dapat menghapus pekerjaan yang belum Anda commit. Git worktree menyelesaikan masalah ini dengan biaya rendah: setiap proses mendapatkan direktori dan branch tersendiri, tetapi tetap berbagi satu object store.

cd /srv/agent/repo
git worktree add -b loop/triage-01 /srv/agent/work/triage-01 origin/main
git worktree list

git worktree list mencetak satu baris untuk setiap tree yang berisi path, commit, dan branch. Setelah proses selesai, git worktree remove /srv/agent/work/triage-01 menghapus direktori tersebut, sedangkan git worktree prune menghapus entri yang direktorinya sudah tidak ada. Loop paralel aman digunakan pada tahap ini karena dua agen pada dua branch dan dua direktori tidak dapat saling menimpa.

Batas ini juga mencakup kredensial. Loop yang berjalan tanpa pengawasan menyimpan token berumur panjang, dan setiap proses dapat membocorkan token tersebut ke log, commit, atau konteks model. Batasi token hanya untuk satu repository yang digunakan loop. Jika memungkinkan, jangan letakkan token di environment yang dapat dilihat oleh shell agen itu sendiri. Baca cara mencegah secrets masuk ke AI agents sebelum memberikan akses production kepada loop. Untuk isolasi yang lebih kuat, jalankan seluruh loop pada VM disposable yang dapat Anda hapus setelah setiap proses. Tool yang Anda jalankan juga menentukan sebagian dari batas ini sebelum Anda menulis konfigurasinya. Karena itu, baca perbandingan managed sandbox Cowork dengan Claude Code pada mesin Anda sendiri sebelum menentukan tingkat isolasi yang perlu Anda bangun sendiri.

Verifikasi: gerbang yang membuat loop aman

Bagian ini membedakan loop dari cron job yang hanya mengetikkan perintah. Output agent adalah proposal. Gerbang yang menentukan.

#!/usr/bin/env bash
set -euo pipefail

repo=/srv/agent/repo
branch="loop/$(date -u +%Y%m%dT%H%M%SZ)"
tree="/srv/agent/work/$(basename "$branch")"

cd "$repo"
git fetch --quiet origin
git worktree add -b "$branch" "$tree" origin/main
cd "$tree"

# the agent's own command runs here, in non-interactive mode

if ! npm test; then
  echo "gate failed: discarding $branch" >&2
  cd "$repo"
  git worktree remove --force "$tree"
  exit 1
fi

git push origin "$branch"
cd "$repo"
git worktree remove "$tree"

set -euo pipefail menjalankan fungsi penting dalam skrip tersebut. Tanpa -e, kegagalan git fetch diabaikan dan eksekusi berlanjut menggunakan origin/main yang sudah kedaluwarsa. Tanpa -u, kesalahan ketik pada nama variabel diperluas menjadi string kosong, lalu proses cleanup berjalan pada path yang salah, bukan gagal secara jelas.

Blok if ! npm test adalah inti seluruh pendekatan ini. Kode keluar dari pemeriksaan yang sudah Anda percayai, baik test suite maupun type checker, menentukan apakah branch di-push atau dihapus. Loop tanpa gerbang menghasilkan pekerjaan yang tidak sempat ditinjau siapa pun, dan itu lebih buruk daripada tidak menghasilkan pekerjaan sama sekali. Loop dengan gerbang menghasilkan branch yang sudah memenuhi standar yang sama dengan branch dari kontributor manusia. Gerbang berstatus green tidak menunjukkan seberapa banyak kode yang diubah agent untuk mencapainya. Karena itu, padukan pemeriksaan tersebut dengan instruksi tetap seperti aturan yang membuat agent mengambil perubahan terkecil yang berfungsi, agar diff tetap cukup kecil sehingga peninjauannya tidak memerlukan banyak waktu.

Pilih gerbang yang gagal secara jujur. Test suite yang berhasil pada diff kosong mengajarkan loop bahwa tidak melakukan apa pun adalah keberhasilan. Repository dengan pengujian yang lemah menghasilkan loop yang lemah. Karena itu, repository yang sedang populer menempatkan "membuat codebase siap digunakan agent" sebelum "menulis loop". Jika ingin mengetahui apakah suite Anda benar-benar dapat mendeteksi regresi, bukan sekadar mengeksekusi baris kode, mutation testing adalah pemeriksaan yang memberikan jawabannya. Agent yang mengembalikan laporan bukti yang dapat dijalankan ulang, bukan meminta Anda membaca diff-nya, mengubah jawaban tersebut menjadi sesuatu yang dapat Anda verifikasi sendiri.

Anggaran: batas yang menghentikan eksekusi

Agen yang mencoba lagi tanpa batas akan menimbulkan biaya yang tidak terbatas. Tetapkan batas waktu berdasarkan jam dinding untuk setiap loop dan terapkan melalui TimeoutStartSec di atas; tetapkan jumlah percobaan ulang dalam skrip; serta tetapkan batas pengeluaran melalui akun provider. Kemudian, catat biaya setiap eksekusi agar Anda dapat melihat loop mulai menyimpang sebelum tagihan menunjukkannya. Pengendalian biaya untuk VPS agen yang selalu aktif membahas sisi pencatatan biaya, sedangkan mengelola konteks yang dibawa agen antar-turn membahas faktor tunggal terbesar yang memengaruhi biaya per eksekusi, karena loop yang membaca ulang repository yang sama setiap 30 menit akan membayarnya setiap 30 menit.

Biaya adalah alasan loop biasanya lebih baik daripada satu sesi panjang. Eksekusi yang dimulai dari awal, menjalankan satu tugas yang terfokus, lalu berhenti akan menjaga konteks tetap kecil. Sesi yang dibiarkan terbuka selama delapan jam membawa setiap kesalahan sebelumnya dalam riwayatnya dan membayar seluruh transkrip pada setiap turn.

Pola yang dikodifikasikan oleh repositori yang sedang tren

Repositori loop-engineering mencantumkan tujuh pola produksi, dan pola-pola tersebut layak dibaca sebagai daftar pilihan, bukan sebagai manifesto. Triage harian. Pengawas pull request yang memantau komentar review dan menanggapinya. Penyapu continuous integration yang mengambil build berstatus gagal. Penyapu dependensi. Penyusun draf changelog. Pembersihan pascagabung. Triage issue.

Kesamaan pola-pola tersebut adalah tugas yang sempit dengan gate yang jelas. "Perbaiki build yang gagal" memiliki kondisi lulus yang dapat dibaca mesin. "Sempurnakan codebase" tidak memilikinya, sehingga tidak pernah menjadi loop. Tugas itu berubah menjadi kekacauan yang memiliki jadwal.

Pola-pola tersebut juga memiliki catatan tertulis. Kedua repositori memindahkan status dari percakapan ke file di dalam repositori: apa yang dijalankan, apa yang ditemukan, dan apa yang diputuskan. File tersebut adalah memori loop. Inilah alasan loop kedua dapat melanjutkan pekerjaan loop pertama, bukan menemukannya kembali. File tersebut juga memungkinkan Anda mengaudit agent setelah proses selesai, karena konteks model hilang segera setelah proses berakhir. Koordinasi langsung adalah channel terpisah, dan satu sesi Claude Code dapat menyerahkan pekerjaan kepada sesi lain pada host yang sama saat keduanya masih berjalan. Namun, tidak ada bagian dari pertukaran tersebut yang bertahan setelah salah satu sesi berakhir, sehingga file tetap menjadi bagian yang dapat Anda baca kembali nanti.

Kegagalan loop

Kegagalannya sederhana dan berulang di berbagai tim.

• Tanpa gate. Output terus bertambah, tidak ada yang meninjaunya, kepercayaan menurun, lalu loop dinonaktifkan.
• Tumpang tindih. Dua proses berjalan pada satu branch, atau dua agent bekerja di satu working tree, sehingga muncul konflik yang kemudian coba diselesaikan oleh agent.
• Drift yang tidak terlihat. Loop terus berhasil karena pemeriksaannya terlalu lemah untuk menghasilkan kegagalan.
• Cakupan tidak terbatas. Trigger yang berjalan pada setiap commit di repository yang aktif dapat berubah menjadi masalah biaya dalam satu hari.

Semua masalah ini memiliki solusi yang sama: perkecil job, perjelas pemeriksaan, dan catat setiap proses. Jika Anda tidak dapat menjelaskan kondisi keberhasilan dalam satu kalimat, job tersebut belum siap diotomatisasi.

Memulai tanpa kosakata khusus

Anda tidak memerlukan framework. Server Linux kecil yang selalu aktif, repositori git yang test suite-nya gagal saat seharusnya gagal, satu systemd timer, dan satu shell script yang berisi if sudah membentuk loop lengkap. Di sinilah sebagian besar orang sebaiknya memulai, karena pertanyaan desain terjawab dengan menjalankan sistem tersebut, bukan dengan memilih tool. Setelah satu loop stabil, menjalankan loop kedua umumnya hanya memerlukan timer lain dan worktree lain. Lihat cara menjalankan coding AI agent pada VPS untuk setup dasar, dan opsi AI agent self-hosted saat ini jika Anda ingin agent tersebut berjalan pada hardware yang Anda kendalikan.

FAQ

Apakah loop engineering berbeda dari prompt engineering?

Prompt engineering mengoptimalkan satu pesan: susunan kata, contoh, dan format output. Loop engineering mengoptimalkan siklus di sekitar pesan tersebut: pemicu yang memulai proses, sandbox tempat proses berjalan, pemeriksaan yang menerima atau menolak output, serta anggaran yang mengakhirinya. Anda tetap memerlukan prompt yang baik di dalam loop. Namun, prompt bukan lagi hal utama yang perlu disesuaikan setiap hari, karena gate dan pemicu lebih memengaruhi hasil.

Apakah saya memerlukan framework untuk membangun agent loop?

Tidak. systemd timer, satu git worktree untuk setiap proses, shell script yang diakhiri dengan perintah test, dan batas pengeluaran pada akun provider sudah mencakup seluruh bagian definisi tersebut. Framework menambahkan interface penjadwalan, format shared memory, dan routing multi-agent. Semua itu berguna setelah Anda menjalankan beberapa loop. Namun, framework bukan syarat awal untuk loop pertama.

Apa yang dimaksud dengan codebase harness?

Codebase harness adalah sekumpulan hal yang memungkinkan agent bekerja di repository tanpa kehadiran manusia: setup dengan satu perintah, test yang berjalan secara non-interaktif dan gagal dengan jelas, linter, serta cara untuk men-deploy atau melihat preview perubahan. Istilah ini muncul dalam gelombang repository yang sama pada 2026 seperti loop engineering. Pengujian praktisnya sederhana: jika kontributor manusia baru tidak dapat berpindah dari clone ke test yang berhasil dengan satu perintah, agent juga tidak akan dapat melakukannya.

Bagaimana cara mencegah agent loop menimbulkan tagihan besar?

Batasi di tiga tempat. Tetapkan TimeoutStartSec pada unit systemd agar proses yang macet dihentikan. Batasi jumlah retry di dalam script, bukan mengulang sampai berhasil. Tetapkan hard spend limit pada akun API, karena hanya batas inilah yang tidak dapat dilewati agent melalui argumen. Selanjutnya, catat biaya setiap proses, karena loop yang biayanya berlipat ganda biasanya merupakan loop yang cakupannya diam-diam meluas.

Pekerjaan apa yang sebaiknya pertama kali diubah menjadi loop?

Pilih pekerjaan dengan kondisi lulus yang dapat dibaca mesin dan blast radius yang kecil. Memperbaiki build yang gagal, memperbarui dependency, dan membuat ulang changelog termasuk pekerjaan yang sesuai, karena test suite atau diff dapat membuktikan hasilnya. Pekerjaan terbuka seperti refactoring atau desain belum sesuai, karena belum ada hal yang dapat diperiksa oleh gate. Loop tanpa gate hanya menjadi cara mahal untuk menambah review debt.