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 di ruang publik. Repositori GitHub cobusgreyling/loop-engineering mencapai 9,600 star dalam waktu kurang dari dua bulan sejak pertama kali muncul (per Juli 2026) dan menunjukkan sekitar 11,600 star pada 2026-10-27, dengan slogan "Jangan lagi menulis prompt. Rancang loop. Dapatkan skor." Pada Juli 2026, README-nya mengelompokkan perubahan tersebut ke dalam enam blok pembangun: penjadwalan, worktree, skill, plugin dan konektor, sub-agent, serta memori persisten yang disimpan di luar percakapan. README saat ini tidak lagi memuat daftar tersebut (diperiksa pada 2026-10-27), tetapi masih menyimpan status loop dalam file di luar percakapan.

Repositori tersebut mencantumkan Boris Cherny, pemimpin Claude Code di Anthropic, sebagai salah satu sumber inspirasinya. Pernyataannya yang banyak diberitakan adalah:

Saya tidak lagi menulis prompt untuk Claude. Saya menjalankan loop yang menulis prompt untuk Claude.

Repositori kedua, AI-Builder-Club/skills, memiliki hampir 1,300 star (per 2026-10-27) 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 ketika menerima trigger, menjalankan pekerjaan, lalu menulis hasil pembelajarannya ke 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 tiket sudah memahami bentuknya. Hal yang baru adalah worker di dalam loop kini bersifat nondeterministik, sehingga mengubah tugas yang harus dilakukan oleh mekanisme 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 baik daripada cron untuk keperluan ini karena mencatat log, melakukan percobaan ulang sesuai aturan Anda, dan tidak memulai salinan kedua dari unit yang masih berjalan. Properti terakhir tersebut menghilangkan bug overlap yang paling umum pada loop agent: dua eksekusi mengedit branch yang sama.

Buat user khusus untuk agent terlebih dahulu. User tersebut merupakan bagian dari batas isolasi, sehingga hanya memiliki /srv/agent:

sudo useradd --system --home-dir /srv/agent --shell /usr/sbin/nologin agent
sudo chown -R agent:agent /srv/agent

Kemudian 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

Lalu 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 seharusnya 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. Service Type=oneshot dianggap masih dalam proses start sampai script-nya selesai. systemd menonaktifkan timeout start untuk unit oneshot secara default. Tanpa baris ini, agent yang macet saat menunggu input akan membuat unit tetap berada dalam status activating selamanya. Setiap tick timer berikutnya akan mendapati unit masih berjalan dan tidak memulai apa pun. Dengan baris tersebut, systemd menghentikan eksekusi setelah 30 menit dan menandainya sebagai failed. Jika Anda mengubah unit menjadi Type=simple default, TimeoutStartSec tidak lagi mencakup eksekusinya. RuntimeMaxSec= adalah pengaturan yang membatasi durasinya. Baca hasil eksekusi dengan journalctl -u agent-loop.service -n 50.

Jika Anda menjalankan loop melalui cron, tambahkan guard overlap sendiri karena cron akan tetap memulai salinan kedua:

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

flock -n langsung keluar dengan status 1 ketika lock sedang digunakan. Dengan demikian, eksekusi kedua berhenti tanpa suara dan tidak berpacu dengan eksekusi pertama. Penyiapan systemd service dan timer yang sama berlaku untuk semua job yang berjalan lama pada server, baik menggunakan agent maupun tidak.

Batas: berikan salinan terpisah untuk setiap eksekusi

Agen yang mengedit working tree Anda dapat menghilangkan pekerjaan yang belum di-commit. Git worktree mengatasi masalah ini dengan biaya rendah: setiap eksekusi mendapatkan direktori dan branch-nya sendiri, dengan 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 menampilkan satu baris untuk setiap tree, beserta path, commit, dan branch-nya. Saat eksekusi selesai, git worktree remove /srv/agent/work/triage-01 menghapus worktree, tetapi hanya worktree yang bersih. Jika tree berisi file yang belum dilacak atau file terlacak yang telah diubah, atau berisi submodule, git menolak penghapusan hingga Anda menambahkan --force. Karena itu, skrip gate di bawah hanya memaksa penghapusan pada path yang akan dibuang setelah eksekusi. git worktree prune menghapus entri yang direktorinya sudah tidak ada. Loop paralel menjadi aman pada tahap ini karena dua agen yang bekerja pada dua branch di dua direktori tidak dapat saling menimpa.

Batas ini juga mencakup kredensial. Loop yang berjalan tanpa pengawasan menyimpan token berumur panjang, dan setiap eksekusi berpotensi membocorkannya ke log, commit, atau konteks model. Batasi cakupan token ke satu repository yang disentuh loop tersebut. Jika memungkinkan, jangan letakkan token di environment yang dapat dilihat oleh shell milik agen. Baca cara menjaga rahasia agar tidak masuk ke agen AI sebelum memberikan akses produksi kepada loop. Untuk batas yang lebih kuat, jalankan seluruh loop pada VM sementara yang dapat Anda hancurkan setelah setiap eksekusi. Tool yang Anda gunakan juga menentukan sebagian batas tersebut sebelum Anda menulis apa pun. Karena itu, baca perbandingan sandbox terkelola Cowork dengan Claude Code di 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, git fetch yang gagal akan diabaikan dan eksekusi berlanjut menggunakan origin/main yang sudah tidak terbaru. Tanpa -u, kesalahan pengetikan nama variabel akan diperluas menjadi string kosong. Proses cleanup kemudian berjalan pada path yang salah, bukan gagal dengan pesan error yang jelas. Baris terakhir sengaja tidak memiliki --force. Jika eksekusi meninggalkan file yang belum dilacak atau belum di-commit dalam tree, git menolak menghapusnya. -e kemudian mengakhiri eksekusi dengan error setelah push, bukan menghapus pekerjaan yang belum di-commit secara diam-diam.

Blok if ! npm test memuat inti pendekatan ini. Exit code dari pemeriksaan yang sudah Anda percayai, yaitu test suite atau type checker, menentukan apakah branch di-push atau dihapus. Loop tanpa gerbang menghasilkan pekerjaan yang tidak sempat ditinjau siapa pun. Kondisi ini lebih buruk daripada tidak menghasilkan pekerjaan. Loop dengan gerbang menghasilkan branch yang sudah melewati standar yang sama dengan branch kontributor manusia. Gerbang berstatus hijau 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. Dengan demikian, diff tetap cukup kecil sehingga peninjauannya tidak memerlukan banyak waktu.

Pilih gerbang yang gagal secara akurat. Test suite yang lulus saat diff kosong mengajarkan loop bahwa tidak melakukan apa pun adalah keberhasilan. Repository dengan test yang lemah akan menghasilkan loop yang lemah. Karena itu, repository yang sedang populer menempatkan "menjadikan codebase siap digunakan agent" sebelum "menulis loop". Jika Anda ingin mengetahui apakah suite benar-benar dapat menemukan regresi, bukan sekadar mengeksekusi baris kode, mutation testing adalah pemeriksaan yang dapat menjawabnya. agent yang mengembalikan laporan bukti yang dapat dijalankan ulang, bukan meminta Anda membaca diff-nya mengubah jawaban tersebut menjadi sesuatu yang dapat Anda konfirmasi 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 dibakukan oleh repositori yang sedang populer

Repositori loop engineering mencantumkan delapan pola produksi (per 2026-10-27), dan pola tersebut lebih baik dibaca sebagai pilihan daripada manifesto. Triage harian. Loop tipis yang berjalan sebagai GitHub Action dan tidak menyimpan file status. Pull-request babysitter yang memantau komentar review dan menjawabnya. Sweeper continuous integration yang mengambil build yang gagal. Dependency sweeper. Penyusun draf changelog. Pembersihan setelah merge. Triage issue.

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

Pola-pola tersebut juga memiliki catatan tertulis. Kedua repositori memindahkan status dari percakapan ke file dalam repositori: apa yang dijalankan, apa yang ditemukan, dan apa yang diputuskan. File tersebut adalah memori loop, dan itulah alasan loop kedua dapat melanjutkan pekerjaan loop pertama tanpa menemukannya kembali. File tersebut juga memungkinkan Anda mengaudit agent setelah pekerjaan selesai, karena konteks model hilang segera setelah eksekusi berakhir. Koordinasi langsung menggunakan kanal terpisah, dan satu sesi Claude Code dapat menyerahkan pekerjaan kepada sesi lain pada host yang sama saat keduanya masih berjalan, tetapi 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 rekayasa loop berbeda dari rekayasa prompt?

Rekayasa prompt mengoptimalkan satu pesan: pilihan kata, contoh, dan format output. Rekayasa loop mengoptimalkan siklus di sekitar pesan tersebut: pemicu yang memulai eksekusi, sandbox tempat eksekusi berlangsung, pemeriksaan yang menerima atau menolak output, serta anggaran yang mengakhirinya. Anda tetap memerlukan prompt yang baik di dalam loop. Namun, prompt bukan lagi bagian yang perlu Anda sesuaikan setiap hari karena gate dan pemicu lebih memengaruhi hasil.

Apakah saya memerlukan framework untuk membangun loop agent?

Tidak. systemd timer, git worktree untuk setiap eksekusi, shell script yang diakhiri dengan perintah pengujian, dan batas pengeluaran pada akun provider sudah mencakup semua bagian definisinya. Framework menambahkan antarmuka penjadwalan, format shared memory, dan routing multi-agent. Semua itu berguna setelah Anda menjalankan beberapa loop. Namun, framework bukan prasyarat untuk loop pertama.

Apa yang dimaksud dengan codebase harness?

Codebase harness adalah sekumpulan hal yang memungkinkan agent bekerja dalam 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 pratinjau perubahan. Istilah ini muncul dalam gelombang repository yang sama pada 2026 seperti rekayasa loop. Pengujian praktisnya sederhana: jika kontributor manusia baru tidak dapat berpindah dari clone ke test yang berhasil dengan satu perintah, agent juga tidak dapat melakukannya.

Bagaimana cara mencegah loop agent menimbulkan tagihan besar?

Batasi pada tiga tempat. Tetapkan TimeoutStartSec pada unit systemd Type=oneshot seperti contoh di atas agar eksekusi yang macet dihentikan. Pada service Type=simple, padanannya adalah RuntimeMaxSec. Batasi jumlah percobaan ulang di dalam script, bukan dengan melakukan loop sampai berhasil. Tetapkan batas pengeluaran yang tegas pada akun API karena hanya batas inilah yang tidak dapat dilampaui agent melalui argumen. Kemudian catat biaya setiap eksekusi. Loop yang biayanya berlipat ganda biasanya merupakan loop yang cakupannya diam-diam melebar.

Job mana yang sebaiknya pertama kali diubah menjadi loop?

Pilih job dengan kondisi keberhasilan yang dapat dibaca mesin dan dampak kegagalan yang kecil. Memperbaiki build yang gagal, memperbarui dependency, dan membuat ulang changelog memenuhi kriteria tersebut karena test suite atau diff dapat membuktikan hasilnya. Pekerjaan terbuka seperti refactoring atau desain belum memenuhi kriteria karena belum ada hal yang dapat diperiksa oleh gate. Loop tanpa gate adalah cara mahal untuk menghasilkan pekerjaan review tambahan.