Loop Engineering.
Penulis asli: Addy Osmani
Diterjemahkan oleh: Peggy, BlockBeats

Editor's Note: Cara penggunaan AI coding agent sedang berpindah dari "manusia menulis Prompt secara manual dan mendorong tugas langkah demi langkah" menjadi "manusia merancang siklus, memungkinkan sistem mengoordinasikan agent secara berkelanjutan". Loop Engineering yang disebutkan oleh Addy Osmani intinya adalah membangun alur kerja yang dapat secara otomatis menemukan tugas, mendistribusikan tugas, memeriksa hasil, mencatat kemajuan, dan menentukan langkah selanjutnya.

Siklus ini terdiri sekitar lima modul: Automations (menemukan dan triase tugas secara terjadwal), Worktrees (mengisolasi beberapa lingkungan pengembangan paralel), Skills (mengakumulasi pengetahuan proyek dan praktik tim), Plugins/Connectors (mengintegrasikan alat nyata seperti GitHub, Linear, Slack, database), Sub-agents (memisahkan pelaksana dan pemeriksa), ditambah lapisan memori eksternal, seperti file Markdown atau papan Linear, untuk menyimpan status dan kemajuan.

Artikel tersebut mengingatkan bahwa makna Loop Engineering bukan hanya "membiarkan AI menjalankan lebih banyak putaran", tetapi mempercepat penilaian insinyur ke dalam desain sistem. Loop dapat secara signifikan memperbesar efisiensi kerja pengembang, tetapi tidak akan menggantikan verifikasi, pemahaman, dan penilaian. Risiko sejati bukan terletak pada penggunaan loop, melainkan pada menjadikan loop sebagai alasan untuk menghindari pemahaman terhadap kode dan sistem. Kemampuan kunci dalam berkolaborasi dengan AI dalam pemrograman di masa depan mungkin bukan lagi hanya menulis Prompt yang baik, tetapi merancang alur kerja Agent yang andal, dapat diverifikasi, dan dapat dijalankan secara berkelanjutan.

Berikut adalah teks aslinya:

Loop engineering (循环工程) sedang menggantikan peran Anda sebagai "orang yang menulis petunjuk untuk agen". Anda harus merancang sistem yang akan menggantikan Anda dalam memberikan petunjuk kepada agen. Di sini, loop (siklus) dapat dipahami sebagai tujuan rekursif: Anda mendefinisikan sebuah tujuan, dan AI akan terus beriterasi hingga tugas selesai. Sistem ini terdiri dari lima komponen utama, dan Claude Code serta Codex kini telah memiliki kelima komponen tersebut.

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

@steipete baru-baru ini mengatakan: "Anda seharusnya tidak lagi menulis petunjuk untuk agen pemrograman. Anda harus merancang beberapa siklus yang akan memberi petunjuk kepada agen Anda." Secara serupa, @bcherny, pemimpin Claude Code dari Anthropic, juga mengatakan: "Saat ini saya tidak lagi memberi petunjuk kepada Claude. Saya memiliki sejumlah siklus yang berjalan, yang akan memberi petunjuk kepada Claude dan menentukan sendiri langkah selanjutnya. Pekerjaan saya hanyalah menulis siklus."

Then, what does this actually mean?

Dalam dua tahun terakhir, cara dasar untuk membuat agen pemrograman melakukan sesuatu adalah dengan menulis petunjuk yang baik dan menyediakan konteks yang cukup. Anda memasukkan satu kalimat, membaca hasilnya, lalu memasukkan kalimat berikutnya. Agen tersebut adalah alat, dan Anda terus memegang alat ini, mendorongnya satu putaran setelah putaran lainnya. Tahap ini某种程度上已经结束了，至少有些人认为它即将结束。

Sekarang, Anda membangun sebuah sistem kecil: sistem ini akan menemukan pekerjaan sendiri, mendistribusikan tugas, memeriksa hasil, mencatat pencapaian, lalu menentukan langkah selanjutnya. Dengan kata lain, Anda membuat sistem ini yang menggerakkan agen, bukan Anda yang terus-menerus memberikan petunjuk secara manual. Saya sebelumnya pernah menulis «kerabat dekat»-nya—agent harness engineering (rekayasa kerangka kerja agen), yaitu membangun lingkungan operasional untuk satu agen; serta factory model (model pabrik), yaitu sistem yang membangun perangkat lunak. Loop engineering berada di atas level harness. Ia seperti harness, tetapi berjalan berdasarkan timer, menghasilkan asisten kecil, dan mampu memperbarui dirinya sendiri.

Yang mengejutkan saya, ini sekarang sudah tidak lagi menjadi masalah di tingkat "alat". Setahun yang lalu, jika Anda ingin membuat loop, Anda harus menulis banyak skrip bash, lalu selamanya memelihara kumpulan skrip itu. Itu adalah milik Anda sendiri, dan hanya milik Anda sendiri. Sekarang, komponen-komponen ini sudah secara langsung terintegrasi ke dalam produk. Kemampuan yang dirinci Steinberger hampir dapat dipetakan satu per satu ke aplikasi Codex, dan juga hampir sama persis ke Claude Code. Begitu Anda menyadari bahwa bentuknya sama, Anda tidak akan lagi bingung harus menggunakan alat mana, tetapi akan mulai merancang sebuah loop: di mana pun Anda duduk di dalam alat apa pun, loop itu tetap berjalan.

Lima komponen, serta beberapa penjelasan

Sebuah loop memerlukan lima hal, ditambah satu tempat untuk mengingat informasi. Saya akan daftarkan terlebih dahulu, lalu sesuaikan satu per satu.

Pertama, Automations (tugas otomatis): dipicu sesuai jadwal, secara otomatis melakukan penemuan dan pengalihan.

Kedua, Worktrees: memastikan dua agen yang bekerja secara paralel tidak saling menimpa file satu sama lain.

Ketiga, Keterampilan: Tuliskan pengetahuan proyek untuk menghindari agen harus menebak setiap kali.

Keempat, Plugins and connectors: Memungkinkan agen terhubung ke alat yang sudah Anda gunakan.

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

Lalu ada hal keenam: memory (memori). Ini bisa berupa file Markdown, papan Linear, atau tempat independen lainnya yang mampu menyimpan "tugas yang telah selesai" dan "tugas selanjutnya" di luar percakapan tunggal. Terdengar sederhana hingga tampak tidak penting, tetapi ini adalah trik yang sama yang digunakan oleh setiap agen jangka panjang. Saya juga telah menulisnya secara mendalam dalam agen jangka panjang: model akan lupa di antara setiap run, jadi memori harus disimpan di disk, bukan di konteks. Agen akan lupa, tetapi repositori kode tidak akan.

Sekarang, kedua produk tersebut telah memiliki lima komponen ini.

Nama-namanya berbeda di beberapa tempat, tetapi kemampuannya pada dasarnya sama. Saya akan jelaskan satu per satu, karena sejujurnya, apakah sebuah loop berjalan stabil atau bocor diam-diam di mana-mana, kuncinya ada pada detailnya.

Automations adalah apa yang membuat loop benar-benar menjadi loop, bukan sekadar tugas satu kali yang Anda jalankan secara manual. Di aplikasi Codex, Anda dapat membuat tugas otomasi di tab Automations, memilih proyek, prompt yang akan dijalankan, frekuensi eksekusi, serta apakah tugas tersebut berjalan di local checkout Anda atau di worktree latar belakang. Hasil eksekusi yang menemukan masalah akan masuk ke Triage inbox, sementara eksekusi tanpa masalah akan diarsipkan secara otomatis—ini sangat bagus. OpenAI sendiri juga menggunakannya untuk tugas-tugas membosankan namun penting, seperti分流 isu harian, merangkum penyebab kegagalan CI, menulis ringkasan commit, dan melacak bug yang diperkenalkan minggu lalu. Tugas otomasi juga dapat memanggil skill, sehingga Anda dapat menjaga tugas berulang tetap mudah dipelihara: memicu $skill-name, bukan menempelkan seluruh daftar instruksi ke dalam jadwal yang tidak akan pernah diperbarui lagi.

Claude Code juga dapat mencapai efek yang sama, hanya dengan jalur yang berbeda: ia mencapainya melalui penjadwalan dan hook. Anda dapat menjalankan prompt atau perintah secara berkala dengan /loop, menjadwalkan tugas cron, atau memicu perintah shell pada titik-titik tertentu dalam siklus hidup agen menggunakan hook. Jika Anda ingin ia terus berjalan setelah Anda menutup laptop, Anda juga dapat mendorong seluruh sistem ke GitHub Actions. Gagasan dasarnya sama: Anda mendefinisikan tugas otonom, memberinya ritme, dan membiarkan hasil temuan datang kepada Anda, bukan Anda yang harus terus-menerus memeriksanya.

Ada satu primitif sesi lain yang perlu diketahui, yang lebih dekat dengan inti sebenarnya yang dibahas dalam artikel ini. /loop akan berjalan berulang kali sesuai ritme; /goal akan terus berjalan hingga kondisi tertentu yang Anda tulis benar-benar terpenuhi. Setiap putaran, sebuah model kecil terpisah akan menilai apakah tugas telah selesai, sehingga agen yang menulis kode bukanlah yang memberi penilaian pada dirinya sendiri. Anda dapat memberikan kondisi seperti “semua pengujian di test/auth berhasil dan lint bersih”, lalu pergi. Codex juga memiliki kemampuan yang sama, yang juga disebut /goal. Ia akan terus bekerja lintas putaran hingga kondisi berhenti yang dapat diverifikasi terpenuhi, dan mendukung jeda, pemulihan, dan pembersihan. Primitif yang sama, dimiliki oleh kedua alat ini. Ini pada dasarnya adalah pola yang berulang kali muncul dalam artikel ini.

Jadi, Automations bertanggung jawab untuk membawa pekerjaan ke permukaan. Sisanya dari loop, bertanggung jawab untuk menangani pekerjaan tersebut.

Saat Anda menjalankan lebih dari satu agen, konflik file menjadi titik kegagalan. Dua agen yang menulis file yang sama secara bersamaan pada dasarnya sebanding dengan dua insinyur yang mengubah baris kode yang sama tanpa komunikasi. Git worktree dapat menyelesaikan masalah ini. Ini adalah direktori kerja terpisah di cabang terpisah, tetapi berbagi riwayat repositori kode yang sama, sehingga perubahan satu agen secara fisik tidak akan pernah menyentuh checkout agen lainnya.

Codex secara langsung memiliki dukungan worktree, sehingga beberapa thread dapat memproses repositori yang sama secara bersamaan tanpa saling bertabrakan. Claude Code juga dapat mencapai isolasi yang sama melalui git worktree: Anda dapat membuka sesi di checkout terpisah dengan flag --worktree, atau mengatur isolation: worktree pada subagent, sehingga setiap agen kecil mendapatkan checkout baru dan membersihkannya secara otomatis setelah selesai. Saya pernah menulis tentang sisi manusia dari hal ini di the orchestration tax: worktrees dapat menghilangkan konflik di tingkat mekanis, tetapi Anda tetap menjadi batasannya. Yang benar-benar menentukan berapa banyak agen yang dapat Anda jalankan secara bersamaan bukanlah alatnya, melainkan review bandwidth Anda.

Skill adalah mekanisme yang memungkinkan Anda tidak perlu menjelaskan kembali konteks proyek yang sama setiap sesi seperti ikan mas. Kedua alat ini menggunakan format yang sama: sebuah folder yang berisi file SKILL.md untuk menyimpan instruksi dan metadata; selain itu, juga dapat menyertakan skrip opsional, referensi, dan file sumber daya. Codex akan menjalankan skill saat Anda memanggilnya dengan $ atau /skills, serta akan menjalankannya secara otomatis ketika tugas Anda sesuai dengan deskripsi skill tersebut. Inilah mengapa deskripsi yang ringkas dan sederhana seringkali lebih baik daripada deskripsi yang cerdas dan berlebihan. Pendekatan Claude Code juga sama, dan saya telah menulis pola ini di agent skills.

Keterampilan juga merupakan tempat di mana niat tidak lagi terus-menerus menghabiskan energi Anda. Saya telah membahas dalam intent debt bahwa setiap sesi percakapan agen dimulai dari awal, dan selama ada kekosongan dalam niat Anda, ia akan mengisi kekosongan itu dengan tebakan yang percaya diri. Keterampilan adalah cara untuk menuliskan niat ini secara eksternal: perjanjian proyek, langkah-langkah pembangunan, “kita tidak melakukan ini karena kecelakaan itu pernah terjadi sebelumnya,” dan sebagainya, ditulis sekali saja di lokasi yang akan dibaca oleh agen setiap kali dijalankan. Tanpa keterampilan, setiap putaran loop harus merekonstruksi seluruh proyek Anda dari nol; dengan keterampilan, ia menjadi semacam pertumbuhan bunga majemuk.

Ada satu hal yang perlu dibedakan: skill adalah format penulisan, sedangkan plugin adalah cara distribusi. Ketika Anda ingin berbagi satu skill di antara beberapa repositori kode, atau menggabungkan beberapa skill menjadi satu paket, Anda akan membungkusnya menjadi sebuah plugin. Codex begitu pula Claude Code.

Sebuah loop yang hanya dapat melihat sistem file adalah loop yang sangat kecil. Connector dibangun berdasarkan MCP, memungkinkan agen membaca issue tracker Anda, mengquery database, memanggil API staging, atau mengirim pesan di Slack. Codex dan Claude Code keduanya mendukung MCP, sehingga connector yang Anda tulis untuk salah satunya biasanya juga dapat digunakan di yang lainnya. Plugin menggabungkan connector dan skill agar rekan tim Anda dapat menginstal konfigurasi lengkap sekaligus, bukan mencoba merekonstruksi seluruhnya dari ingatan.

Ini adalah perbedaan antara «sebuah agen memberi tahu Anda 'ini solusi perbaikannya'» dan «sebuah loop yang secara otomatis membuka PR, mengaitkan ticket Linear, serta memberi notifikasi ke saluran setelah CI berhasil». Connectors penting karena memungkinkan loop untuk bertindak di lingkungan nyata Anda, bukan hanya mengatakan «jika saya bisa, saya akan melakukannya».

Dalam sebuah loop, desain struktural paling berguna adalah memisahkan «penulis» dan «pemeriksa». Model yang menulis kode terlalu mudah bersikap terlalu permisif saat menilai pekerjaannya sendiri. Agen lain dengan instruksi berbeda, bahkan terkadang menggunakan model yang berbeda, dapat menangkap masalah yang diabaikan oleh agen pertama setelah meyakinkan dirinya sendiri.

Codex hanya akan menghasilkan subagent saat Anda meminta, yang akan berjalan secara paralel, lalu menggabungkan hasilnya menjadi satu jawaban. Anda dapat mendefinisikan agent sendiri dalam file TOML di .codex/agents/: setiap agent memiliki nama, deskripsi, instruksi, serta model dan intensitas penalaran opsional. Oleh karena itu, pemeriksa keamanan Anda bisa menjadi model kuat dengan intensitas penalaran tinggi, sementara penjelajah Anda bisa menjadi model ringan yang cepat dan hanya-baca. Claude Code juga menyediakan kemampuan serupa melalui subagent dan tim agent di .claude/agents/, memungkinkan beberapa agent saling mentransfer pekerjaan. Pembagian tugas paling umum di kedua platform adalah: satu agent menjelajahi, satu agent mewujudkan, dan satu agent memverifikasi sesuai spesifikasi.

Saya telah menyampaikan pandangan ini dua kali: sekali di code agent orchestra, dan sekali di adversarial code review. Ini sangat penting dalam loop, karena loop akan berjalan saat Anda tidak mengawasi, sehingga verifier (pembuat verifikasi) yang benar-benar Anda percaya adalah satu-satunya alasan Anda berani pergi. Subagents memang menghabiskan lebih banyak token, karena setiap agent melakukan panggilan model dan panggilan alat sendiri, jadi Anda sebaiknya menggunakannya di tempat-tempat di mana 'pendapat kedua' layak dibayar. Ini pada dasarnya juga apa yang dilakukan /goal Claude Code di tingkat bawah: menggunakan model baru untuk menilai apakah loop telah selesai, bukan membiarkan model yang melakukan pekerjaan itu menilainya. Dengan kata lain, ia menerapkan pemisahan antara 'pembuat' dan 'pemeriksa' pada kondisi penghentian itu sendiri.

Seperti apa bentuk sebuah loop

Menyatukan hal-hal ini, satu thread tunggal akan berubah menjadi panel kontrol kecil. Di bawah ini adalah struktur yang sering saya gunakan.

Setiap pagi, sebuah otomasi berjalan di repositori kode. Promp-nya memanggil keterampilan triage, membaca kegagalan CI kemarin, isu yang masih terbuka, dan commit terbaru, lalu mencatat temuan tersebut ke dalam file Markdown atau papan Linear. Untuk setiap masalah yang layak ditangani, thread akan membuka worktree terisolasi, mengirim sub-agent untuk merancang solusi perbaikan, lalu mengirim sub-agent kedua untuk meninjau solusi tersebut berdasarkan keterampilan proyek dan pengujian yang sudah ada.

Connector memungkinkan loop ini membuka PR secara otomatis dan memperbarui tiket. Segala sesuatu yang tidak dapat ditangani oleh loop akan masuk ke inbox triage untuk saya tangani. File status adalah tulang punggung seluruh sistem: ia mengingat apa yang sudah dicoba, apa yang berhasil, dan apa yang masih belum selesai. Oleh karena itu, jalankan esok pagi akan melanjutkan dari titik di mana hari ini berhenti.

Perhatikan apa yang sebenarnya kamu lakukan. Kamu hanya merancang satu kali. Langkah-langkah tersebut bukanlah sesuatu yang kamu berikan secara satu per satu. Inilah versi nyata dari pernyataan Steinberger. Dan loop yang sama dapat dijalankan di Codex maupun di Claude Code, karena komponen-komponennya sendiri adalah rangkaian komponen yang sama.

Loop masih tidak akan melakukan apa-apa untukmu

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

Verifikasi masih bergantung pada Anda. Sebuah loop yang berjalan tanpa pengawasan juga bisa saja berjalan sambil melakukan kesalahan tanpa pengawasan. Alasan Anda memisahkan verifier sub-agent dan maker adalah agar loop dapat mengatakan "selesai" dengan sedikit makna. Meskipun demikian, "selesai" tetaplah sebuah klaim, bukan bukti. Saya terus mengulangi kalimat yang sama di code review in the age of AI: tanggung jawab Anda adalah menyerahkan kode yang telah Anda konfirmasi berfungsi dengan benar.

Jika Anda membiarkannya begitu saja, pemahaman Anda sendiri akan tetap membusuk. Semakin cepat Loop mengirimkan kode yang tidak Anda tulis sendiri, semakin besar kesenjangan antara apa yang benar-benar Anda pahami dan apa yang sebenarnya ada dalam sistem. Inilah yang disebut comprehension debt (utang pemahaman). Jika Anda tidak membaca apa yang dihasilkan Loop, sebuah loop yang lancar hanya akan mempercepat pertumbuhan utang ini.

Dan ya, postur yang paling nyaman kemungkinan besar juga merupakan postur yang paling berbahaya. Ketika loop dapat berjalan sendiri, Anda mudah berhenti membentuk penilaian sendiri dan hanya menerima apa pun yang dikembalikannya. Saya menyebut ini sebagai cognitive surrender (penyerahan kognitif). Jika Anda merancang loop dengan membawa penilaian, ia adalah obatnya; jika Anda merancang loop hanya untuk menghindari pemikiran, ia adalah akselerator. Tindakan yang sama dapat menghasilkan hasil yang sama sekali berlawanan.

Buat loop, tetapi tetap jadi insinyur

Saya percaya ini menandakan arah evolusi pekerjaan kita di masa depan. Namun demikian, jika saya tidak mengulas kode secara langsung, atau sepenuhnya mengandalkan loop otomatis untuk memperbaiki kode, kualitas produk saya akan terganggu. Saya sangat mungkin terjebak dalam spiral penurunan: terus-menerus menggali diri saya sendiri ke lubang yang lebih dalam.

Jadi, Anda tentu bisa membuat loop sendiri, tetapi jangan lupa bahwa memberikan petunjuk langsung kepada agen cerdas Anda masih efektif. Kuncinya adalah menemukan keseimbangan yang tepat.

Hasil Loop juga akan berbeda-beda antar individu. Dua orang dapat membuat loop yang identik, tetapi mendapatkan hasil yang sama sekali berlawanan. Satu orang menggunakannya untuk mempercepat pekerjaan yang sangat mereka pahami; orang lain menggunakannya untuk menghindari memahami pekerjaan itu sendiri. Loop tidak mengetahui perbedaan antara keduanya. Kamu yang tahu.

Inilah mengapa loop design lebih sulit daripada prompt engineering, bukan lebih mudah. Maksud Cherny bukanlah pekerjaan menjadi lebih ringan, tetapi titik tuasnya berpindah.

Bangun loop. Tetapi bangunlah seperti seorang yang masih berniat menjadi insinyur, bukan seperti seseorang yang hanya bertugas menekan tombol 'mulai'.

[Link asli]

Klik untuk mengetahui posisi yang sedang dibuka oleh BlockBeats

Selamat bergabung dengan komunitas resmi BlockBeats:

Grup langganan Telegram: https://t.me/theblockbeats

Grup Telegram: https://t.me/BlockBeats_App

Akun resmi Twitter: https://twitter.com/BlockBeatsAsia