Catatan Editor: Cara penggunaan AI coding Agent, sedang beralih dari "manusia menulis Prompt secara manual, memajukan tugas putaran demi putaran", menjadi "manusia merancang loop, membiarkan sistem terus menjadwalkan Agent". Loop Engineering (rekayasa loop) yang disebutkan Addy Osmani, intinya adalah membangun alur kerja yang mampu secara otomatis menemukan tugas, mengalokasikan tugas, memeriksa hasil, mencatat kemajuan, dan menentukan langkah selanjutnya.

Loop ini kira-kira terdiri dari lima modul: Automations (menemukan dan triase tugas secara terjadwal), Worktrees (mengisolasi banyak lingkungan pengembangan paralel), Skills (mengendapkan pengetahuan proyek dan konvensi tim), Plugins/Connectors (menghubungkan alat-alat nyata seperti GitHub, Linear, Slack, database, dll), Sub-agents (memisahkan pelaksana dan pemeriksa), ditambah dengan lapisan memori eksternal, seperti file Markdown atau papan Linear, untuk menyimpan status dan kemajuan.

Artikel ini mengingatkan, arti Loop Engineering bukan hanya "membiarkan AI berjalan beberapa putaran lagi", melainkan menempatkan daya pertimbangan insinyur ke dalam desain sistem sejak awal. Loop dapat secara signifikan memperkuat leverage kerja pengembang, tetapi tidak akan menggantikan verifikasi, pemahaman, dan penilaian. Risiko sebenarnya, juga tidak terletak pada penggunaan loop, melainkan pada menjadikan loop sebagai alasan untuk menghindari memahami kode dan sistem. Kemampuan kunci untuk berkolaborasi dengan pemrograman AI di masa depan, mungkin bukan lagi hanya menulis Prompt yang baik, melainkan merancang alur kerja Agent yang andal, dapat diverifikasi, dan dapat berjalan berkelanjutan.

Berikut adalah teks asli:

Loop engineering (rekayasa loop) sedang mengambil alih peran Anda sebagai "orang yang menulis prompt untuk agen". Anda harus merancang sebuah sistem, yang akan memberi prompt kepada agen untuk Anda. Loop di sini dapat dipahami sebagai tujuan rekursif: Anda mendefinisikan sebuah tujuan, AI kemudian beriterasi terus-menerus, sampai tugas selesai. Loop ini kira-kira terdiri dari lima komponen, dan Claude Code serta Codex sekarang sudah memiliki kelima komponen ini.

Saya percaya, ini mungkin cara kita berkolaborasi dengan agen pemrograman di masa depan. Namun, semua ini masih dalam tahap awal, dan saya tetap skeptis. Anda benar-benar perlu berhati-hati dengan biaya token, karena perbedaan biaya dalam berbagai mode penggunaan bisa sangat besar, terutama tergantung apakah Anda "kaya token" atau "sulit token". Anda juga perlu memiliki mekanisme tertentu, untuk memastikan kualitas tidak menurun. Kekhawatiran tentang "output sampah AI" (slop) juga masuk akal. Meskipun demikian, mari kita lihat apa sebenarnya yang terjadi.

@steipete baru-baru ini mengatakan: "Anda seharusnya tidak lagi menulis prompt untuk agen pemrograman. Anda harus merancang beberapa loop, yang akan memberi prompt kepada agen Anda." Demikian pula, kepala Claude Code dari Anthropic @bcherny juga berkata: "Saya sekarang sudah tidak lagi memberi prompt kepada Claude. Saya punya banyak loop yang berjalan, mereka akan memberi prompt kepada Claude, dan menilai sendiri apa yang harus dilakukan selanjutnya. Pekerjaan saya adalah menulis loop."

Lalu, apa maksudnya ini?

Selama sekitar dua tahun terakhir, cara Anda ingin membuat agen pemrograman melakukan sesuatu, pada dasarnya adalah dengan menulis prompt yang bagus, dan memberikan konteks yang cukup. Anda memasukkan satu kalimat, membaca hasil yang dikembalikan, lalu memasukkan kalimat berikutnya. Agen adalah alat, dan Anda terus memegang alat ini, memajukannya putaran demi putaran. Tahap ini sampai batas tertentu sudah berakhir, setidaknya beberapa orang menganggapnya akan segera berakhir.

Sekarang, yang Anda bangun adalah sebuah sistem kecil: sistem ini akan menemukan pekerjaan sendiri, mengalokasikan tugas, memeriksa hasil, mencatat penyelesaian, lalu memutuskan apa yang harus dilakukan selanjutnya. Artinya, Anda membiarkan sistem ini menggerakkan agen, daripada Anda sendiri yang terus-menerus memberi prompt. Saya sebelumnya pernah menulis tentang "kerabat dekatnya" – agent harness engineering (rekayasa kerangka kerja operasi agen), yaitu membangun lingkungan operasi untuk satu agen; dan factory model (model pabrik), yaitu sistem yang membangun perangkat lunak. Loop engineering terletak satu tingkat di atas harness. Ia seperti harness, tetapi berjalan sesuai timer, menghasilkan asisten kecil, dan memberi makan dirinya sendiri.

Yang mengejutkan saya, sekarang ini sudah tidak lagi hanya masalah "tingkat alat". Setahun yang lalu, jika Anda menginginkan sebuah loop, Anda harus menulis banyak skrip bash, lalu memelihara tumpukan skrip itu selamanya. Itu adalah milik Anda sendiri, dan hanya milik Anda sendiri. Sekarang, komponen-komponen ini sudah langsung tertanam di dalam produk. Kemampuan yang disebutkan Steinberger hampir semuanya dapat disesuaikan satu per satu ke dalam aplikasi Codex, dan hampir sama halnya dengan Claude Code. Begitu Anda menyadari bentuknya sama, Anda tidak akan lagi bingung tentang alat mana yang harus digunakan, melainkan akan merancang sebuah loop: di mana pun Anda berada, di alat mana pun Anda duduk, ia akan terus berjalan.

Lima Komponen, dan Beberapa Penjelasan

Satu loop membutuhkan lima hal, ditambah satu tempat untuk mengingat informasi. Saya akan mendaftarkannya dulu, lalu menjelaskan satu per satu.

Pertama, Automations (otomatisasi tugas): Dijalankan sesuai jadwal, melakukan penemuan dan triase secara otomatis.

Kedua, Worktrees (pohon kerja): Membuat dua agen yang bekerja paralel tidak menginjak-injak file satu sama lain.

Ketiga, Skills (keterampilan): Menuliskan pengetahuan proyek, menghindari agen menebak setiap kali.

Keempat, Plugins and connectors (plugin dan konektor): Membiarkan agen terhubung ke alat yang sudah Anda gunakan.

Kelima, Sub-agents (sub-agen): Satu bertanggung jawab mengusulkan solusi, yang lain bertanggung jawab memeriksa solusi.

Kemudian hal keenam: memory (memori). Ia bisa berupa file Markdown, bisa juga papan Linear, atau apa pun yang terpisah dari percakapan tunggal, yang mampu menyimpan "hal yang sudah dilakukan" dan "hal berikutnya". Kedengarannya sederhana sampai tidak seperti hal penting, tetapi ini adalah trik yang sama yang diandalkan setiap agen yang berjalan lama. Saya juga telah menulis secara rinci di long-running agents: model akan melupakan di antara setiap eksekusi, jadi memori harus ditempatkan di disk, bukan di konteks. Agen akan lupa, tetapi repositori kode tidak.

Sekarang, kedua produk sudah memiliki kelima komponen ini.

Penamaannya ada beberapa perbedaan, tetapi kemampuan pada dasarnya adalah hal yang sama. Di bawah ini saya jelaskan satu per satu, karena sejujurnya, apakah sebuah loop akhirnya berjalan stabil, atau diam-diam bocor di mana-mana, kuncinya ada di detailnya.

Automations: Ini adalah detak jantung loop

Automations adalah hal yang membuat loop benar-benar menjadi loop, bukan tugas satu kali yang Anda jalankan secara manual. Di aplikasi Codex, Anda dapat membuat otomatisasi di tab Automations, memilih proyek, prompt yang akan dijalankannya, frekuensi berjalan, dan apakah ia berjalan di checkout lokal Anda, atau di worktree latar belakang. Hasil eksekusi yang menemukan masalah akan masuk ke Triage inbox (kotak masuk triase), sedangkan yang tidak menemukan masalah akan diarsipkan secara otomatis, ini cukup bagus. OpenAI internal juga menggunakannya untuk melakukan hal-hal membosankan tetapi perlu, seperti triase issue harian, meringkas penyebab kegagalan CI, menulis laporan singkat commit, melacak bug yang diperkenalkan seseorang minggu lalu. Otomatisasi tugas juga dapat memanggil skill, sehingga Anda dapat menjaga tugas yang berjalan berulang tetap dapat dipelihara: picu $skill-name, daripada menempelkan sepanjang dinding teks penjelasan ke dalam tugas terjadwal yang nanti tidak akan diperbarui siapa pun.

Claude Code juga dapat mencapai efek yang sama, hanya jalurnya berbeda: melalui penjadwalan dan hooks. Anda dapat menggunakan /loop untuk menjalankan prompt atau perintah pada interval tetap, Anda juga dapat menjadwalkan tugas cron, dan Anda dapat menggunakan hooks untuk memicu perintah shell pada titik-titik tertentu dalam siklus hidup agen. Jika Anda ingin ia terus berjalan setelah Anda menutup laptop, Anda juga dapat mendorong seluruh rangkaian ini ke GitHub Actions. Ide yang sepenuhnya sama: Anda mendefinisikan tugas otonom, memberinya ritme, membiarkan temuan datang kepada Anda, daripada Anda yang memeriksa ke mana-mana.

Ada juga primitif dalam sesi yang perlu diketahui, lebih dekat dengan inti yang benar-benar dibahas artikel ini. /loop akan berjalan berulang sesuai ritme; /goal akan terus dieksekusi, sampai suatu kondisi yang Anda tuliskan benar-benar terpenuhi. Setelah setiap putaran, akan ada model kecil terpisah yang menilai apakah tugas sudah selesai, jadi agen yang menulis kode bukanlah yang memberi nilai dirinya sendiri. Anda dapat memberinya kondisi, seperti "semua pengujian di test/auth lulus, dan lint bersih", lalu pergi. Codex juga memiliki kemampuan yang sama, disebut juga /goal. Ia akan terus bekerja melintasi putaran, sampai suatu kondisi berhenti yang dapat diverifikasi terpenuhi, dan mendukung jeda, lanjutkan, dan hapus. Primitif yang sama, dimiliki kedua alat. Ini pada dasarnya adalah pola yang muncul berulang di artikel ini.

Jadi, Automations bertanggung jawab membuat pekerjaan muncul ke permukaan. Sisa loop, bertanggung jawab menangani pekerjaan ini.

Worktrees: Membuat paralelisme tidak berubah menjadi kekacauan

Begitu Anda menjalankan lebih dari satu agen, konflik file akan menjadi titik kegagalan. Dua agen menulis file yang sama secara bersamaan, pada dasarnya sama merepotkannya dengan dua insinyur yang memodifikasi baris kode yang sama tanpa komunikasi. git worktree dapat menyelesaikan masalah ini. Ini adalah direktori kerja terpisah di cabang independen, tetapi berbagi riwayat repositori kode yang sama, sehingga modifikasi satu agen secara fisik tidak dapat menyentuh checkout agen lain.

Codex secara langsung memiliki dukungan worktree bawaan, sehingga beberapa thread dapat menangani repositori yang sama secara bersamaan tanpa saling bertabrakan. Claude Code juga dapat mencapai isolasi yang sama melalui git worktree: Anda dapat menggunakan flag --worktree untuk membuka sesi di checkout independen, atau mengatur isolation: worktree di subagent, memberi setiap asisten kecil checkout baru, dan membersihkannya secara otomatis setelah selesai. Saya telah menulis sisi manusia dari hal ini di the orchestration tax: worktrees dapat menghilangkan konflik di tingkat mekanis, tetapi Anda tetap menjadi batas atas. Yang benar-benar menentukan berapa banyak agen yang dapat Anda jalankan secara bersamaan, bukan alatnya, melainkan bandwidth review (bandwidth peninjauan) Anda.

Skills: Membuat Anda tidak harus menjelaskan ulang proyek setiap kali

Skill adalah mekanisme yang membuat Anda tidak harus menjelaskan ulang konteks proyek yang sama setiap sesi seperti ikan mas. Format yang digunakan kedua alat sama: sebuah folder, di dalamnya ada SKILL.md, menyimpan penjelasan dan metadata; selain itu juga dapat memiliki skrip opsional, referensi, dan file sumber daya. Codex akan menjalankan skill saat Anda memanggilnya dengan $ atau /skills, juga akan menjalankannya secara otomatis ketika tugas Anda cocok dengan deskripsi skill tersebut. Inilah mengapa deskripsi yang ringkas dan sederhana, seringkali lebih baik daripada deskripsi yang cerdik dan mewah. Claude Code melakukan hal yang sama, saya telah menulis pola ini di agent skills.

Skills juga adalah tempat di mana intent tidak lagi terus-menerus menguras Anda. Saya pernah bilang di intent debt, agen memulai setiap sesi dalam keadaan dingin, selama ada kekosongan dalam intent Anda, ia akan mengisinya dengan tebakan yang percaya diri. Skill adalah menulis intent ini di luar: konvensi proyek, langkah-langkah pembangunan, "kami tidak melakukan ini karena pernah ada kecelakaan itu" dan sebagainya, ditulis sekali di tempat yang dibaca setiap kali agen berjalan. Tanpa skills, loop setiap putaran harus menurunkan seluruh proyek Anda dari nol; dengan skills, ia agak seperti menghasilkan bunga majemuk.

Satu hal yang perlu dibedakan: skill adalah format penulisan, plugin adalah cara distribusi. Ketika Anda ingin berbagi skill di antara banyak repositori kode, atau membundel beberapa skill bersama-sama, Anda akan mengemasnya menjadi sebuah plugin. Codex demikian, Claude Code juga demikian.

Plugins and connectors: Membiarkan loop menyentuh alat nyata Anda

Sebuah loop yang hanya dapat melihat sistem file, adalah loop yang sangat kecil. Connectors dibangun di atas MCP, memungkinkan agen membaca pelacak issue Anda, mengkueri database, memanggil staging API, atau mengirim pesan di Slack. Codex dan Claude Code keduanya mendukung MCP, jadi connector yang Anda tulis untuk salah satunya, biasanya juga dapat digunakan di yang lain. Plugins akan membundel connectors dan skills bersama-sama, membuat rekan tim Anda menginstal konfigurasi lengkap sekaligus, daripada membangun ulang seluruh rangkaian itu berdasarkan ingatan.

Inilah perbedaan antara "seorang agen memberi tahu Anda 'ini adalah perbaikan'" dan "sebuah loop sendiri membuka PR, menghubungkan tiket Linear, dan memberi tahu saluran setelah CI lulus". Connectors penting karena mereka membiarkan loop bertindak di lingkungan nyata Anda, bukan hanya memberi tahu Anda "jika saya bisa melakukannya, saya akan melakukannya".

Sub-agents: Menjauhkan pembuat dari pemeriksa

Dalam sebuah loop, desain struktural yang paling berguna, jauh melampaui hanya memisahkan "orang yang menulis" dan "orang yang memeriksa". Model yang menulis kode terlalu mudah bersikap terlalu pemaaf saat memberi nilai pada pekerjaan sendiri. Seorang agen lain dengan instruksi berbeda, kadang-kadang bahkan menggunakan model yang berbeda, mampu menangkap masalah yang diabaikan agen pertama setelah meyakinkan dirinya sendiri.

Codex hanya akan menghasilkan subagents saat Anda memintanya, mereka akan berjalan secara paralel, lalu menggabungkan hasilnya kembali menjadi satu jawaban. Anda dapat mendefinisikan agents Anda sendiri di .codex/agents/ dengan file TOML: setiap agent memiliki nama, deskripsi, instruksi, dan opsional model dan kekuatan penalaran. Jadi, pemeriksa keamanan Anda bisa menjadi model kuat dengan penalaran intensitas tinggi, sedangkan penjelajah Anda bisa menjadi model ringan yang cepat dan hanya-baca. Claude Code juga mencapai kemampuan serupa melalui subagents dan agent teams di .claude/agents/, membuat banyak agent saling meneruskan pekerjaan. Pembagian kerja paling umum di kedua sisi adalah: satu agent menjelajah, satu agent mengimplementasikan, satu agent memverifikasi berdasarkan spesifikasi.

Saya telah dua kali menyampaikan pandangan ini: sekali di code agent orchestra, sekali lagi di adversarial code review. Ini sangat penting di loop, karena loop berjalan saat Anda tidak mengawasi, jadi seorang verifier (pemeriksa) yang benar-benar Anda percayai, adalah satu-satunya alasan Anda berani pergi. Subagents memang akan mengonsumsi lebih banyak token, karena setiap agent harus melakukan panggilan model dan alat sendiri, jadi Anda harus menggunakannya di tempat "pendapat kedua layak dibayar". Ini pada dasarnya juga yang dilakukan /goal Claude Code di lapisan bawah: model baru yang menilai apakah loop sudah selesai, bukan model yang menyelesaikan pekerjaan yang menilai. Artinya, ia menerapkan pemisahan "pembuat" dan "pemeriksa" pada kondisi berhenti itu sendiri.

Seperti Apa Bentuk Sebuah Loop

Menyatukan semua ini, satu thread tunggal akan berubah menjadi panel kontrol kecil. Berikut adalah struktur yang sering saya gunakan.

Setiap pagi, sebuah automation berjalan di repositori kode. Prompt-nya akan memanggil skill triage, membaca kegagalan CI kemarin, issues yang terbuka, commit terbaru, dan menuliskan temuan ke file Markdown atau papan Linear. Untuk setiap masalah yang layak ditangani, thread akan membuka worktree terisolasi, mengirim sub-agent untuk menyusun draf perbaikan, lalu mengirim sub-agent kedua untuk meninjau draf ini berdasarkan skills proyek dan pengujian yang ada.

Connectors membiarkan loop ini sendiri membuka PR, dan memperbarui tiket. Apa pun yang tidak dapat ditangani loop, akan masuk ke triage inbox, diserahkan kepada saya. File status adalah tulang punggung seluruh sistem: ia mengingat apa yang telah dicoba, apa yang lolos, apa yang masih belum selesai. Oleh karena itu, eksekusi keesokan paginya akan melanjutkan dari tempat hari ini berhenti.

Perhatikan apa yang benar-benar Anda lakukan. Anda hanya merancang sekali. Langkah-langkah itu tidak Anda prompt sendiri secara manual baris per baris. Inilah versi nyata dari ucapan Steinberger. Dan, loop yang sama dapat berjalan di Codex, juga dapat berjalan di Claude Code, karena komponen itu sendiri adalah komponen yang sama.

Apa yang Tetap Tidak Akan Dilakukan Loop untuk Anda

Loop mengubah cara kerja, tetapi tidak menghapus Anda dari pekerjaan. Bahkan, seiring loop menjadi lebih kuat, tiga masalah ini akan menjadi lebih tajam, bukan lebih mudah.

Verifikasi tetap bergantung pada Anda. Sebuah loop yang berjalan tanpa pengawasan, juga bisa saja salah tanpa pengawasan. Alasan Anda memisahkan verifier sub-agent dan maker, adalah agar ucapan loop "selesai" itu agak ada artinya. Meskipun demikian, "selesai" tetap sebuah klaim, bukan bukti. Saya terus mengulangi kalimat yang sama di code review in the age of AI: tanggung jawab Anda adalah mengirimkan kode yang Anda konfirmasi efektif.

Pemahaman Anda sendiri tetap akan membusuk jika dibiarkan. Semakin cepat loop mengirimkan kode yang tidak Anda tulis sendiri, semakin besar kesenjangan antara apa yang sebenarnya Anda pahami dan apa yang benar-benar ada di dalam sistem. Inilah comprehension debt (utang pemahaman). Jika Anda tidak membaca hal-hal yang dihasilkan loop, sebuah loop yang lancar hanya akan membuat utang ini tumbuh lebih cepat.

Dan, ya, postur paling nyaman kemungkinan juga postur paling berbahaya. Ketika loop dapat berjalan sendiri, Anda mudah berhenti membentuk penilaian sendiri, hanya menerima apa pun yang dikembalikannya. Saya menyebut ini cognitive surrender (penyerahan kognitif). Jika Anda merancang loop dengan penilaian, itu adalah penawar racun; jika Anda merancang loop hanya untuk menghindari berpikir, itu adalah akselerator. Gerakan yang sama, menghasilkan hasil yang sepenuhnya berlawanan.

Membangun Loop, Tetap Menjadi Insinyur

Saya pikir, ini menandakan arah evolusi kerja kita di masa depan. Meskipun demikian, jika saya tidak meninjau kode sendiri, atau sepenuhnya bergantung pada loop otomatis untuk memperbaiki kode, kualitas produk saya akan terganggu. Saya kemungkinan besar akan terjebak dalam spiral ke bawah: terus menggali diri ke lubang yang lebih dalam.

Jadi, tentu saja Anda dapat membangun loop Anda sendiri, tetapi jangan lupa, langsung memprompt agen Anda tetap efektif. Kuncinya adalah menemukan keseimbangan yang tepat.

Hasil loop juga akan bervariasi dari orang ke orang. Dua orang dapat membangun loop yang persis sama, tetapi mendapatkan hasil yang sangat berlawanan. Satu orang menggunakannya untuk mempercepat pekerjaan yang ia pahami mendalam; orang lain menggunakannya untuk menghindari memahami pekerjaan itu sendiri. Loop tidak tahu perbedaan antara keduanya. Anda yang tahu.

Inilah mengapa loop design (desain loop) lebih sulit daripada prompt engineering (rekayasa prompt), bukan lebih mudah. Maksud Cherny bukan pekerjaan menjadi lebih ringan, melainkan titik leverage bergeser.

Bangun loop. Tetapi bangunlah seperti seseorang yang masih berencana menjadi insinyur, bukan seperti seseorang yang hanya bertanggung jawab menekan tombol "mulai".