Loop Engineering - Merancang Sistem yang Mem-prompt Agen

• Mengakhiri cara lama yang mem-prompt coding agent secara langsung di setiap giliran, lalu beralih ke cara kerja merancang sistem yang mem-prompt agen sebagai pengganti kita
• Loop adalah tujuan rekursif yang membuat AI berulang hingga tujuan selesai setelah kita mendefinisikannya, dan terdiri dari sekitar lima komponen
• Lima komponennya adalah Automations, Worktrees, Skills, Plugins·connectors, Sub-agents, dan baik Claude Code maupun Codex saat ini sama-sama memiliki kelimanya
• Komponen keenam, memory, adalah file markdown atau papan Linear yang menyimpan status di luar satu percakapan, untuk melengkapi model yang lupa pada tiap eksekusi
• Masih pada tahap awal, sehingga biaya token wajib diperhatikan, dan verifikasi·pemahaman tetap menjadi tugas manusia (build the loop, stay the engineer)

---

Definisi loop engineering dan latar kemunculannya

• Loop engineering adalah mengganti posisi orang yang mem-prompt agen dari diri sendiri menjadi sistem, lalu merancang sendiri sistem yang melakukan pekerjaan itu
  • Loop adalah tujuan rekursif (recursive goal) yang terus berulang hingga AI menyelesaikan tujuan yang telah didefinisikan
  • Ini bisa menjadi cara kerja masa depan bersama coding agent, tetapi masih tahap awal, dan biaya token wajib diperhatikan (pola penggunaan akan sangat berbeda tergantung apakah kaya token atau miskin token)
• Kutipan
  • Peter Steinberger: "Jangan lagi mem-prompt coding agent; rancanglah loop yang mem-prompt agen."
  • Boris Cherny (kepala Claude Code di Anthropic): "Sekarang saya tidak lagi mem-prompt Claude, tetapi menjalankan loop yang mem-prompt Claude dan menentukan apa yang harus dilakukan. Pekerjaan saya adalah menulis loop."
• Sekitar dua tahun terakhir, caranya adalah memberi prompt yang baik dan konteks yang cukup, lalu bertukar satu giliran demi satu giliran sambil memegang agen secara langsung sebagai alat; tetapi cara itu sedang berakhir
• Sekarang, kita membuat sistem kecil yang mencari dan membagi pekerjaan, memverifikasi, mencatat yang sudah selesai, dan menentukan tugas berikutnya, lalu membiarkan sistem itu memicu agen
  • Ini berada di atas tulisan sebelumnya tentang agent harness engineering (lingkungan tempat satu agen berjalan) dan factory model (sistem yang membuat software)
  • Sebuah harness yang berjalan dengan timer, membuat helper kecil, dan memberi makan dirinya sendiri
• Ini bukan lagi soal alat — setahun lalu, jika ingin loop, kita harus menulis dan memelihara sendiri bash dummy; sekarang komponennya sudah tertanam langsung di dalam produk
  • Daftar Steinberger hampir persis cocok dengan aplikasi Codex dan juga hampir sama dengan Claude Code, jadi alih-alih berdebat soal alat mana, lebih baik merancang loop yang bekerja di keduanya

Lima komponen loop dan memory

• Loop membutuhkan lima hal, lalu ditambah satu tempat untuk mengingat status
  • Automations — dipicu sesuai jadwal untuk melakukan penemuan dan triage sendiri
  • Worktrees — mencegah dua agen yang bekerja paralel saling bertabrakan
  • Skills — menyimpan pengetahuan proyek yang jika tidak ada akan diisi agen dengan tebakan
  • Plugins·connectors — menghubungkan agen ke alat yang sudah digunakan
  • Sub-agents — satu pihak menghasilkan ide dan pihak lain memverifikasinya
• Yang keenam adalah memory, seperti file markdown atau papan Linear, yang hidup di luar satu percakapan dan menyimpan apa yang sudah selesai serta apa yang harus dilakukan berikutnya
  • Ini terlihat terlalu sederhana, tetapi merupakan trik yang sama yang diandalkan semua agen yang berjalan jangka panjang (tulisan sebelumnya tentang long-running agents)
  • Model melupakan segalanya di antara eksekusi, jadi memory harus berada di disk, bukan hanya di konteks — agen boleh lupa, tetapi repo tidak lupa
• Kedua produk saat ini sudah memiliki kelima komponen tersebut; hanya namanya sedikit berbeda, kemampuannya sama

Automations — detak jantung loop

• Automations adalah komponen yang membuat loop menjadi loop sungguhan, bukan sekadar satu kali eksekusi
  • Di aplikasi Codex, ini dibuat di tab Automations, dengan memilih proyek, prompt yang akan dijalankan, interval, dan apakah memakai checkout lokal atau background worktree
  • Eksekusi yang menemukan sesuatu akan masuk ke Triage inbox, dan eksekusi yang tidak menemukan apa pun akan mengarsipkan dirinya sendiri
  • OpenAI memakainya secara internal untuk pekerjaan membosankan seperti triage issue harian, ringkasan kegagalan CI, menulis briefing commit, dan memburu bug yang ditambahkan minggu lalu
  • Automation dapat memanggil skill, sehingga alih-alih menempel dinding instruksi yang besar, kita bisa memicu $skill-name agar pekerjaan berulang tetap mudah dipelihara
• Claude Code mencapai titik yang sama melalui scheduling dan hooks
  • Dengan /loop, ia bisa menjalankan prompt atau perintah pada interval tertentu, menjadwalkan pekerjaan cron, dan menembakkan perintah shell dengan hooks pada titik tertentu dalam lifecycle agen
  • Jika ingin tetap berjalan setelah laptop ditutup, seluruhnya bisa dipindahkan ke GitHub Actions
• Ada primitive kedua di dalam sesi yang sangat dekat dengan inti tulisan ini
  • /loop menjalankan ulang pada interval yang ditentukan
  • /goal terus berjalan sampai kondisi yang kita tulis benar-benar terpenuhi, dan setelah tiap giliran model kecil terpisah memeriksa apakah tugas sudah selesai, agar agen yang menulis kode tidak sekaligus menjadi penilai
    • Contoh: memberi kondisi seperti "semua tes di test/auth lulus, lint clean" lalu meninggalkannya bekerja
  • Codex juga menyediakan /goal dengan cara yang sama, bekerja sambil berpindah giliran sampai kondisi berhenti yang bisa diverifikasi terpenuhi, serta mendukung pause·resume·clear

Worktrees — agar paralel tidak berubah jadi kekacauan

• Begitu menjalankan lebih dari satu agen, file mulai saling bertabrakan; di sinilah kegagalan biasanya terjadi
  • Dua agen yang menulis file yang sama sama memusingkannya seperti dua engineer yang meng-commit baris yang sama tanpa saling bicara
  • git worktree menyelesaikannya — masing-masing punya direktori kerja terpisah di atas branch sendiri sambil tetap berbagi riwayat repo yang sama, sehingga edit dari satu agen tidak menyentuh checkout agen lain
• Codex memiliki dukungan worktree bawaan, sehingga banyak thread bisa menyentuh satu repo secara bersamaan tanpa bentrok
• Claude Code memberi isolasi yang sama melalui git worktree, flag --worktree yang membuka sesi di checkout-nya sendiri, serta pengaturan isolation: worktree yang ditempelkan ke subagent (setiap helper mendapat checkout baru yang membersihkan dirinya sendiri saat selesai)
• Worktree menghilangkan benturan mekanis, tetapi batas atasnya tetap Anda sendiri — jumlah yang realistis untuk dijalankan ditentukan bukan oleh alat, melainkan oleh bandwidth review Anda (tulisan sebelumnya tentang the orchestration tax)

Skills — agar tidak perlu menjelaskan proyek dari awal setiap saat

• Skill adalah cara untuk berhenti mengulang penjelasan konteks proyek yang sama di setiap sesi seperti ikan mas yang terus lupa
  • Kedua alat memakai format yang sama — folder berisi SKILL.md yang memuat instruksi dan metadata, plus skrip·referensi·aset opsional
  • Codex dapat dipanggil dengan $ atau /skills, atau menjalankannya sendiri bila pekerjaan cocok dengan deskripsi skill, sehingga deskripsi yang ringkas dan membosankan justru lebih baik daripada deskripsi yang terlalu pintar
  • Claude Code juga bekerja dengan cara yang sama (tulisan sebelumnya tentang agent skills)
• Skill adalah tempat agar intent tidak menjadi biaya berulang
  • Agen memulai setiap sesi dari keadaan dingin dan mengisi celah intent dengan tebakan percaya diri (tulisan sebelumnya tentang the intent debt)
  • Skill adalah intent yang ditulis di luar agen — konvensi, langkah build, atau hal seperti "karena kejadian itu, kita tidak melakukannya dengan cara ini"; cukup ditulis sekali dan agen akan membacanya di setiap eksekusi
  • Tanpa skill, loop harus menyimpulkan ulang seluruh proyek dari nol pada setiap siklus; dengan skill, ia menumpuk dan berbunga majemuk
• Skill adalah format penulisan, dan plugin adalah cara distribusinya — jika ingin dibagikan atau dibundel ke banyak repo, ia dikemas sebagai plugin (sama pada Codex maupun Claude Code)

Plugins·connectors — agar loop menyentuh alat yang nyata

• Loop yang hanya bisa melihat filesystem adalah loop yang kecil
  • Connector berbasis MCP memungkinkan agen membaca issue tracker, menjalankan query DB, memanggil staging API, dan mengirim pesan Slack
  • Codex dan Claude Code sama-sama berbicara dalam MCP, sehingga connector untuk salah satunya biasanya juga langsung berjalan di yang lain
  • Plugin membundel connector dan skill sehingga rekan kerja bisa memasangnya sekaligus tanpa harus membangun ulang seluruhnya dari ingatan
• Inilah perbedaan antara agen yang berkata "ini ada usulan perbaikan" dan loop yang membuka PR, menghubungkan tiket Linear, lalu mengirim ping ke channel saat CI sudah hijau
  • Connector adalah alasan loop tidak hanya berhenti pada kemungkinan, tetapi benar-benar bertindak di dalam lingkungan nyata

Sub-agents — memisahkan pihak yang membuat dan yang memeriksa

• Struktur yang paling berguna di dalam loop adalah memisahkan pihak yang menulis kode dan pihak yang memeriksanya
  • Model yang menulis kode terlalu murah hati saat menilai pekerjaannya sendiri
  • Agen kedua, dengan instruksi berbeda dan kadang model berbeda, menangkap hal-hal yang sudah telanjur diyakini oleh agen pertama
• Codex membuat subagent hanya saat diminta, menjalankannya secara bersamaan, lalu menggabungkan hasilnya menjadi satu jawaban
  • Ia mendefinisikan agen kustom sebagai file TOML di .codex/agents/ (name·description·instructions, dengan model·reasoning effort opsional)
  • Contoh: reviewer keamanan memakai model kuat dengan effort tinggi, sementara explorer memakai model cepat yang read-only
• Claude Code menangani hal yang sama dengan subagents di .claude/agents/ dan agent teams yang saling melempar tugas
  • Pembagian kerja yang umum di kedua alat adalah satu agen untuk eksplorasi, satu untuk implementasi, dan satu untuk verifikasi terhadap spesifikasi (tulisan sebelumnya tentang the code agent orchestra dan adversarial code review)
• Karena loop berjalan saat kita tidak melihat, ia membutuhkan verifier yang bisa dipercaya agar kita berani meninggalkannya
  • Subagent masing-masing menjalankan model dan pekerjaan alatnya sendiri, sehingga menghabiskan lebih banyak token; jadi gunakan saat opini kedua benar-benar bernilai
  • Inilah juga yang dilakukan /goal di Claude Code secara internal — model baru menilai apakah pekerjaan selesai alih-alih pihak yang mengerjakan, sehingga pemisahan maker·checker diterapkan bahkan pada kondisi berhentinya sendiri

Seperti apa satu loop itu

• Jika digabungkan, satu thread berubah menjadi panel kontrol kecil; berikut satu bentuk yang sering dipakai berulang
  • Sebuah automation berjalan setiap pagi di repo, dan prompt-nya memanggil skill triage untuk membaca kegagalan CI kemarin, issue yang terbuka, dan commit terbaru, lalu menuliskan hasilnya ke file markdown atau papan Linear
  • Untuk setiap item yang layak dikerjakan, thread membuka worktree yang terisolasi dan menugaskan draf perbaikan ke sub-agent, lalu sub-agent kedua meninjau draf itu terhadap skill proyek dan tes yang sudah ada
  • Connector memungkinkan loop membuka PR dan memperbarui tiket, sedangkan hal yang tidak bisa ditangani loop masuk ke triage inbox
  • State file adalah tulang punggung semuanya — mengingat apa yang sudah dicoba, apa yang sudah lolos, dan apa yang masih terbuka, sehingga eksekusi pagi berikutnya melanjutkan dari titik berhenti hari ini
• Intinya, tak satu pun dari langkah-langkah itu di-prompt satu per satu; semuanya dirancang sekali — entah memakai Codex atau Claude Code, loop-nya tetap sama karena komponennya sama

Hal-hal yang tetap tidak digantikan oleh loop

• Loop mengubah pekerjaan, bukan menghapus manusia, dan justru ada tiga masalah yang makin tajam ketika loop makin bagus
• Verifikasi tetap tugas Anda
  • Loop tanpa pengawasan juga merupakan loop yang bisa salah tanpa pengawasan
  • Alasan verifier sub-agent dipisahkan dari maker adalah agar kata "selesai" dalam loop punya arti, tetapi tetap saja "done" adalah klaim, bukan bukti (tulisan sebelumnya tentang code review in the age of AI — tugasnya adalah mengirim kode yang sudah dipastikan bekerja)
• Pemahaman akan membusuk jika dibiarkan
  • Semakin cepat loop mengirim kode yang tidak Anda tulis sendiri, semakin lebar jarak antara apa yang ada dan apa yang benar-benar Anda pahami
  • Inilah comprehension debt; loop yang mulus akan memperlebar jarak itu lebih cepat jika Anda tidak membaca apa yang dihasilkannya
• Sikap yang nyaman adalah sikap yang berbahaya
  • Ketika loop berjalan sendiri, kita mudah berhenti punya pendapat dan menerima begitu saja apa yang dikembalikan (cognitive surrender)
  • Merancang loop adalah obat jika dilakukan dengan pertimbangan; tetapi menjadi akseleran jika dilakukan untuk menghindari berpikir — tindakan yang sama, hasil yang sepenuhnya berlawanan

Bangun loop, tetapi tetaplah engineer

• Ini tampak seperti cuplikan awal dari evolusi cara kerja, tetapi jika tidak meninjau kode secara langsung atau hanya bergantung pada loop otomatis, kualitas produk bisa turun dan Anda terjebak dalam spiral menurun yang semakin dalam
• Siapkan loop, tetapi mem-prompt agen secara langsung tetap efektif, dan kuncinya adalah menemukan keseimbangan yang tepat
• Loop bisa memberi hasil yang sepenuhnya berlawanan pada dua orang — dari dua orang yang membuat loop yang sama, satu memakainya untuk bergerak lebih cepat pada hal yang dipahami secara mendalam, sementara yang lain memakainya agar tidak perlu memahami pekerjaan itu
  • Loop tidak tahu perbedaannya, tetapi Anda tahu
• Inilah alasan mengapa merancang loop tidak lebih mudah daripada prompt engineering, bahkan lebih sulit — inti poin Cherny bukan bahwa pekerjaan menjadi lebih mudah, melainkan bahwa titik leverage telah berpindah
• Kesimpulannya: bangun loop, tetapi bangunlah seperti seseorang yang akan tetap menjadi engineer, bukan sekadar orang yang menekan tombol start

[shakespeares]

Verifikasi tetap menjadi tanggung jawab kita sendiri

Pemahaman akan membusuk jika dibiarkan

Posisi yang nyaman adalah posisi yang berbahaya

=> Pada akhirnya, kita perlu memeriksa langsung dan membuat prompt untuk meminimalkan pekerjaan berulang.